RFC 4475

Session Initiation Protocol (SIP) Torture Test Messages

📅 published May 2006, from ietf

RFC 4475: Session Initiation Protocol (SIP) Torture Test Messages 🎀

Okay bestie, this is RFC 4475, and it's a Request for Comments published in May 2006 🌸 It's categorised as Informational, which means it shares info for the Internet community but doesn't set any official standard. It's not a spec, it's a hype test kit 💅

The editor is R. Sparks, Ed. from Estacado Systems, and the co-authors are A. Hawrylyshen (Ditech Networks), A. Johnston (Avaya), J. Rosenberg (Cisco Systems), and H. Schulzrinne (Columbia University) 🫶 The header doesn't list any Obsoletes or Updates, so this RFC doesn't replace or change any other RFC 🦋

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice 🌈

Abstract 💜

This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation. Basically, it's a bunch of messages built to stress-test SIP software, and it's giving chaos in the best way 😭

Table of Contents 🍓

   1. Overview ........................................................3
   2. Document Conventions ............................................3
      2.1. Representing Long Lines ....................................4
      2.2. Representing Non-printable Characters ......................4
      2.3. Representing Long Repeating Strings ........................5
   3. SIP Test Messages ...............................................5
      3.1. Parser Tests (syntax) ......................................5
           3.1.1. Valid Messages ......................................5
                  3.1.1.1. A Short Tortuous INVITE ....................5
                  3.1.1.2. Wide Range of Valid Characters .............8
                  3.1.1.3. Valid Use of the % Escaping Mechanism ......9
                  3.1.1.4. Escaped Nulls in URIs .....................11
                  3.1.1.5. Use of % When It Is Not an Escape .........11
                  3.1.1.6. Message with No LWS between
                           Display Name and < ........................12

                  3.1.1.7. Long Values in Header Fields ..............12
                  3.1.1.8. Extra Trailing Octets in a UDP Datagram ...14
                  3.1.1.9. Semicolon-Separated Parameters in
                           URI User Part .............................16
                  3.1.1.10. Varied and Unknown Transport Types .......16
                  3.1.1.11. Multipart MIME Message ...................17
                  3.1.1.12. Unusual Reason Phrase ....................18
                  3.1.1.13. Empty Reason Phrase ......................19
           3.1.2. Invalid Messages ...................................20
                  3.1.2.1. Extraneous Header Field Separators ........20
                  3.1.2.2. Content Length Larger Than Message ........20
                  3.1.2.3. Negative Content-Length ...................21
                  3.1.2.4. Request Scalar Fields with
                           Overlarge Values ..........................22
                  3.1.2.5. Response Scalar Fields with
                           Overlarge Values ..........................23
                  3.1.2.6. Unterminated Quoted String in
                           Display Name ..............................24
                  3.1.2.7. <> Enclosing Request-URI ..................25
                  3.1.2.8. Malformed SIP Request-URI (embedded LWS) ..26
                  3.1.2.9. Multiple SP Separating
                           Request-Line Elements .....................27
                  3.1.2.10. SP Characters at End of Request-Line .....28
                  3.1.2.11. Escaped Headers in SIP Request-URI .......29
                  3.1.2.12. Invalid Timezone in Date Header Field ....30
                  3.1.2.13. Failure to Enclose name-addr URI in <> ...31
                  3.1.2.14. Spaces within addr-spec ..................31
                  3.1.2.15. Non-token Characters in Display Name .....32
                  3.1.2.16. Unknown Protocol Version .................32
                  3.1.2.17. Start Line and CSeq Method Mismatch ......33
                  3.1.2.18. Unknown Method with CSeq Method Mismatch .33
                  3.1.2.19. Overlarge Response Code ..................34
      3.2. Transaction Layer Semantics ...............................34
           3.2.1. Missing Transaction Identifier .....................34
      3.3. Application-Layer Semantics ...............................35
           3.3.1. Missing Required Header Fields .....................35
           3.3.2. Request-URI with Unknown Scheme ....................36
           3.3.3. Request-URI with Known but Atypical Scheme .........36
           3.3.4. Unknown URI Schemes in Header Fields ...............37
           3.3.5. Proxy-Require and Require ..........................37
           3.3.6. Unknown Content-Type ...............................38
           3.3.7. Unknown Authorization Scheme .......................38
           3.3.8. Multiple Values in Single Value Required Fields ....39
           3.3.9. Multiple Content-Length Values .....................40
           3.3.10. 200 OK Response with Broadcast Via Header
                   Field Value .......................................40
           3.3.11. Max-Forwards of Zero ..............................41
           3.3.12. REGISTER with a Contact Header Parameter ..........42
           3.3.13. REGISTER with a url-parameter .....................42
           3.3.14. REGISTER with a URL Escaped Header ................43
           3.3.15. Unacceptable Accept Offering ......................44
      3.4. Backward Compatibility ....................................44
           3.4.1. INVITE with RFC 2543 Syntax ........................44
   4. Security Considerations ........................................45
   5. Acknowledgements ...............................................46
   6. Informative References .........................................46
   Appendix A. Bit-Exact Archive of Each Test Message ................47
      A.1. Encoded Reference Messages ................................48

1. Overview ✨

This document is informational and is NOT NORMATIVE on any aspect of SIP. So nothing here is law, it's just vibes and test cases 💅

This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as, defined in [RFC3261]. Some messages exercise SIP's use of the Session Description Protocol (SDP), as described in [RFC3264].

These messages were developed and refined at the SIPIt interoperability test events 🧚

The test messages are organized into several sections. Some stress only a SIP parser, and others stress both the parser and the application above it. Some messages are valid, and some are not. Each example clearly calls out what makes any invalid messages incorrect 🔥

This document does not attempt to catalog every way to make an invalid message, nor does it attempt to be comprehensive in exploring unusual, but valid, messages. Instead, it tries to focus on areas that have caused interoperability problems or that have particularly unfavorable characteristics if they are handled improperly. This document is a seed for a test plan, not a test plan in itself 🌱

The messages are presented in the text using a set of markup conventions to avoid ambiguity and meet Internet-Draft layout requirements. To resolve any remaining ambiguity, a bit-accurate version of each message is encapsulated in an appendix 🦋

2. Document Conventions 🎀

This document contains many example SIP messages. Although SIP is a text-based protocol, many of these examples cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document defines and uses the markup defined in this section to remove that ambiguity. This markup uses the start and end tag conventions of XML but does not define any XML document type 💖

The appendix contains an encoded binary form of all the messages and the algorithm needed to decode them into files.

2.1. Representing Long Lines 🌸

Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.

The following represent the same string of bits:

   Header-name: first value, reallylongsecondvalue, third value

   <allOneLine>
   Header-name: first value,
    reallylongsecondvalue
   , third value
   </allOneLine>

   <allOneLine>
   Header-name: first value,
    reallylong
   second
   value,
    third value
   </allOneLine>

Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning. Not the same thing, bestie, so don't mix them up 🙈

2.2. Representing Non-printable Characters 🧚

Several examples contain binary message bodies or header field values containing non-ascii range UTF-8 encoded characters. These are rendered here as a pair of hexadecimal digits per octet between <hex/> tags. This rendering applies even inside quoted-strings.

The following represent the same string of bits:

   Header-name: value one
   Header-name: value<hex>206F6E</hex>e

The following is a Subject header field containing the euro symbol:

   Subject: <hex>E282AC</hex>

2.3. Representing Long Repeating Strings 🍓

Several examples contain very large data values created with repeating bit strings. Those will be rendered here using <repeat count=some_integer>value</repeat>. As with <hex>, this rendering applies even inside quoted strings.

For example, the value "abcabcabc" can be rendered as <repeat count=3>abc</repeat>. A display name of "1000000 bottles of beer" could be rendered as

   To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer"
       <sip:beer.example.com>

A Max-Forwards header field with a value of one google will be rendered here as

   Max-Forwards: 1<repeat count=100>0</repeat>

3. SIP Test Messages 💜

3.1. Parser Tests (syntax) 🦋

3.1.1. Valid Messages ✨

3.1.1.1. A Short Tortuous INVITE ✨

okay so this one is short and relatively human-readable, but it is PACKED 🎀 it's got:

line folding all over 🌀
escaped characters within quotes
an empty subject 🙈
LWS between colons, semicolons, header field values, and other fields
both comma separated and separately listed header field values
a mix of short and long form for the same header field name
an unknown Request-URI parameter
unknown header fields
an unknown header field with a value that would be syntactically invalid if it were defined in terms of generic-param 👀
unusual header field ordering
unusual header field name character case
unknown parameters of a known header field
a uri parameter with no value
a header parameter with no value
integer fields (Max-Forwards and CSeq) with leading zeros

all elements should treat this as a well-formed request 💖

the UnknownHeaderWithUnusualValue header field deserves special attention 🦋 if this header field were defined in terms of comma-separated values with semicolon-separated parameters (like a lot of the existing defined header fields), this would be invalid. however, since the receiving element doesn't know the definition of the syntax for this field, it must parse it as a header value. proxies would forward this header field unchanged, and endpoints would ignore the header field 🫶

Message Details : wsinv

INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO :
 sip:vivekg@chair-dnrc.example.com ;   tag    = 1918181833n
from   : "J Rosenberg \\\""       <sip:jdrosen@example.com>
  ;
  tag = 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: wsinv.ndaksdj@192.0.2.1
Content-Length   : 150
cseq: 0009
  INVITE
Via  : SIP  /   2.0
 /UDP
    192.0.2.2;branch=390skdjuw
s :
NewFangledHeader:   newfangled value
 continued newfangled value
UnknownHeaderWithUnusualValue: ;;,,;;,;
Content-Type: application/sdp
Route:
 <sip:services.example.com;lr;unknownwith=value;unknown-no-value>
v:  SIP  / 2.0  / TCP     spindle.example.com   ;
  branch  =   z9hG4bK9ikj8  ,
 SIP  /    2.0   / UDP  192.168.255.111   ; branch=
 z9hG4bK30239
m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam =
      newvalue ;
  secondparam ; q = 0.33

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.3
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.1.2. Wide Range of Valid Characters 🌈

this message exercises a wider range of characters in several key syntactic elements than implementations usually see 😭 notably:

the Method contains non-alpha characters from token. note that % is not an escape character for this field. a method of IN%56ITE is an unknown method, and it is not the same as a method of INVITE 💀
the Request-URI contains unusual, but legal, characters 🧚
a branch parameter contains all non-alphanum characters from token
the To header field value's quoted string contains quoted-pair expansions, including a quoted NULL character
the name part of name-addr in the From header field value contains multiple tokens (instead of a quoted string) with all non-alphanum characters from the token production rule. that value also has an unknown header parameter whose name contains the non-alphanum token characters and whose value is a non-ascii range UTF-8 encoded string. the tag parameter on this value contains the non-alphanum token characters
the Call-ID header field value contains the non-alphanum characters from word. notice that in this production:
- % is not an escape character. it's only an escape character in productions matching the rule "escaped"
- " does not start a quoted string. None of ',` or " imply that there will be a matching symbol later in the string
- the characters []{}()<> do not have any grouping semantics. they are not required to appear in balanced pairs
there is an unknown header field (matching extension-header) with non-alphanum token characters in its name and a UTF8-NONASCII value

if this unusual URI has been defined at a proxy, the proxy will forward this request normally. otherwise, a proxy will generate a 404. endpoints will generate a 501 listing the methods they understand in an Allow header field 🔥

Message Details : intmeth

<allOneLine>
!interesting-Method0123456789_*+`.%indeed'~
 sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)
@example.com SIP/2.0
</allOneLine>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~
<allOneLine>
To: "BEL:\<hex>07</hex> NUL:\<hex>00</hex> DEL:\<hex>7F</hex>"
 <sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
@example.com>
</allOneLine>
<allOneLine>
From: token1~` token2'+_ token3*%!.- <sip:mundane@example.com>
;fromParam''~+*_!.-%=
"<hex>D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9</hex>"
;tag=_token~1'+`*%!-.
</allOneLine>
Call-ID: intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{
CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~
Max-Forwards: 255
<allOneLine>
extensionHeader-!.%*+_`'~:
<hex>EFBBBFE5A4A7E5819CE99BBB</hex>
</allOneLine>
Content-Length: 0

3.1.1.3. Valid Use of the % Escaping Mechanism 🦋

this INVITE uses the % HEX HEX escaping mechanism in several places 💜 the request is syntactically valid, and the interesting bits are:

the request-URI has sips:user@example.com embedded in its userpart. what that might mean to example.net is beyond the scope of this document 🤷
the From and To URIs have escaped characters in their userparts
the Contact URI has escaped characters in the URI parameters. note that the "name" uri-parameter has a value of "value%41", which is not equivalent to "valueA" 👀. per [RFC3986], unescaping URI components is never performed recursively

a parser must accept this as a well-formed message ✨ the application using the message must treat the % HEX HEX expansions as equivalent to the character being encoded. the application must not try to interpret % as an escape character in those places where % HEX HEX ("escaped" in the grammar) is not a valid part of the construction. in [RFC3261], "escaped" only occurs in the expansions of SIP-URI, SIPS-URI, and Reason-Phrase 🌸

Message Details : esc01

INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0
To: sip:%75se%72@example.com
From: <sip:I%20have%20spaces@example.net>;tag=938
Max-Forwards: 87
i: esc01.239409asdfakjkn23onasd0-3234
CSeq: 234234 INVITE
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw
C: application/sdp
Contact:
  <sip:cal%6Cer@host5.example.net;%6C%72;n%61me=v%61lue%25%34%31>
Content-Length: 150

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.1.4. Escaped Nulls in URIs 🍓

this register request has several URIs with nulls in the userpart 🙈 the message is well formed, and parsers must accept this message. implementations must take special care when unescaping the Address-of-Record (AOR) in this request so as to not prematurely shorten the username 😤 this request registers two distinct contact URIs 💅

Message Details : escnull

REGISTER sip:example.com SIP/2.0
To: sip:null-%00-null@example.com
From: sip:null-%00-null@example.com;tag=839923423
Max-Forwards: 70
Call-ID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
Contact: <sip:%00@host5.example.com>
Contact: <sip:%00%00@host5.example.com>
L:0

3.1.1.5. Use of % When It Is Not an Escape 🧚

in most of the places % can appear in a SIP message, it is not an escape character. this can surprise the unwary implementor 😱 the following well-formed request has these properties:

the request method is unknown. it is not equivalent to REGISTER
the display name portion of the To and From header fields is "%Z%45". note that this is not the same as %ZE
this message has two Contact header field values, not three. <sip:alias2@host2.example.com> is a C%6Fntact header field value 🫣

a parser should accept this message as well formed. a proxy would forward or reject the message depending on what the Request-URI meant to it. an endpoint would reject this message with a 501 🙅‍♀️

Message Details : esc02

RE%47IST%45R sip:registrar.example.com SIP/2.0
To: "%Z%45" <sip:resource@example.com>
From: "%Z%45" <sip:resource@example.com>;tag=f232jadfj23
Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf
Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234
CSeq: 29344 RE%47IST%45R
Max-Forwards: 70
Contact: <sip:alias1@host1.example.com>
C%6Fntact: <sip:alias2@host2.example.com>
Contact: <sip:alias3@host3.example.com>
l: 0

3.1.1.6. Message with No LWS between Display Name and < 💔

this OPTIONS request isn't valid per the grammar in RFC 3261, since there is no LWS between the token in the display name and < in the From header field value 🙃 this has been identified as a specification bug that will be removed when RFC 3261 is revised. elements should accept this request as well formed 🫶

Message Details : lwsdisp

OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: caller<sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID: lwsdisp.1234abcd@funky.example.com
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw
l: 0

3.1.1.7. Long Values in Header Fields ✨

okay so this one is a well-formed request that's absolutely stuffed with header fields holding MANY values and VERY long values 😭🫶 it's giving overachiever. Here's what's serving:

The To header field has a long display name, and long uri parameter names and values.
The From header field has long header parameter names and values, in particular, a very long tag.
The Call-ID is one long token.

Message Details : longreq

INVITE sip:user@example.com SIP/2.0
<allOneLine>
To: "I have a user name of
 <repeat count=10>extreme</repeat> proportion"
<sip:user@example.com:6000;
unknownparam1=very<repeat count=20>long</repeat>value;
longparam<repeat count=25>name</repeat>=shortvalue;
very<repeat count=25>long</repeat>ParameterNameWithNoValue>
</allOneLine>
<allOneLine>
F: sip:
<repeat count=5>amazinglylongcallername</repeat>@example.net
;tag=12<repeat count=50>982</repeat>424
;unknownheaderparam<repeat count=20>name</repeat>=
unknowheaderparam<repeat count=15>value</repeat>
;unknownValueless<repeat count=10>paramname</repeat>
</allOneLine>
Call-ID: longreq.one<repeat count=20>really</repeat>longcallid
CSeq: 3882340 INVITE
<allOneLine>
Unknown-<repeat count=20>Long</repeat>-Name:
 unknown-<repeat count=20>long</repeat>-value;
 unknown-<repeat count=20>long</repeat>-parameter-name =
 unknown-<repeat count=20>long</repeat>-parameter-value
</allOneLine>
Via: SIP/2.0/TCP sip33.example.com
v: SIP/2.0/TCP sip32.example.com
V: SIP/2.0/TCP sip31.example.com
Via: SIP/2.0/TCP sip30.example.com
ViA: SIP/2.0/TCP sip29.example.com
VIa: SIP/2.0/TCP sip28.example.com
VIA: SIP/2.0/TCP sip27.example.com
via: SIP/2.0/TCP sip26.example.com
viA: SIP/2.0/TCP sip25.example.com
vIa: SIP/2.0/TCP sip24.example.com
vIA: SIP/2.0/TCP sip23.example.com
V :  SIP/2.0/TCP sip22.example.com
v :  SIP/2.0/TCP sip21.example.com
V  : SIP/2.0/TCP sip20.example.com
v  : SIP/2.0/TCP sip19.example.com
Via : SIP/2.0/TCP sip18.example.com
Via  : SIP/2.0/TCP sip17.example.com
Via: SIP/2.0/TCP sip16.example.com
Via: SIP/2.0/TCP sip15.example.com
Via: SIP/2.0/TCP sip14.example.com
Via: SIP/2.0/TCP sip13.example.com
Via: SIP/2.0/TCP sip12.example.com
Via: SIP/2.0/TCP sip11.example.com
Via: SIP/2.0/TCP sip10.example.com
Via: SIP/2.0/TCP sip9.example.com
Via: SIP/2.0/TCP sip8.example.com
Via: SIP/2.0/TCP sip7.example.com
Via: SIP/2.0/TCP sip6.example.com
Via: SIP/2.0/TCP sip5.example.com
Via: SIP/2.0/TCP sip4.example.com
Via: SIP/2.0/TCP sip3.example.com
Via: SIP/2.0/TCP sip2.example.com
Via: SIP/2.0/TCP sip1.example.com
<allOneLine>
Via: SIP/2.0/TCP
 host.example.com;received=192.0.2.5;
branch=very<repeat count=50>long</repeat>branchvalue
</allOneLine>
Max-Forwards: 70
<allOneLine>
Contact: <sip:
<repeat count=5>amazinglylongcallername</repeat>
@host5.example.net>
</allOneLine>
Content-Type: application/sdp
l: 150

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.1.8. Extra Trailing Octets in a UDP Datagram ✨

this message has a single SIP REGISTER request that supposedly arrived over UDP in one datagram 📦. The packet has extra octets sitting after the body (which, in this case, has zero length). Those extra octets happen to look like a SIP INVITE request, but (per section 18.3 of [RFC3261]) they are just spurious noise that must be ignored 🙈 total plot twist, but no, it's noise, bestie.

A SIP element receiving this datagram would handle the REGISTER request normally and ignore the extra bits that look like an INVITE request 💅. If the element is a proxy choosing to forward the REGISTER, the INVITE octets would not appear in the forwarded request 🫶.

Message Details : dblreq

REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=43251j3j324
Max-Forwards: 8
I: dblreq.0ha0isndaksdj99sdfafnl3lk233412
Contact: sip:j.user@host.example.com
CSeq: 8 REGISTER
Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492
Content-Length: 0

INVITE sip:joe@example.com SIP/2.0
t: sip:joe@example.com
From: sip:caller@example.net;tag=141334
Max-Forwards: 8
Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
Content-Type: application/sdp
Content-Length: 150

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m =video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.1.9. Semicolon-Separated Parameters in URI User Part ✨

this request has a semicolon-separated parameter tucked into the "user" part of the Request-URI 🎀, and the value has an escaped @ symbol in it. Receiving elements will accept this as a well-formed message 💖. The Request-URI parses so that the user part is "user;par=u@example.net" 🦋.

Message Details : semiuri

OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Call-ID: semiuri.0ha0isndaksdj
CSeq: 8 OPTIONS
Accept: application/sdp, application/pkcs7-mime,
        multipart/mixed, multipart/signed,
        message/sip, message/sipfrag
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw
l: 0

3.1.1.10. Varied and Unknown Transport Types ✨

this request is a Via party. It contains Via header field values with all the known transport types 🚌 and it exercises the transport extension mechanism 🌈. Parsers must accept this message as well formed 💅. Elements receiving it would process it exactly as if the 2nd and subsequent header field values specified UDP (or other transport) 🧚.

Message Details : transports

OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: <sip:caller@example.com>;tag=323
Max-Forwards: 70
Call-ID:  transports.kijh4akdnaqjkwendsasfdj
Accept: application/sdp
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw
Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf
Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj
Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en
Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee
l: 0

3.1.1.11. Multipart MIME Message ✨

this MESSAGE request has two body parts 📬. The second part is binary encoded and contains null (0x00) characters 🧃, so receivers must take care to frame the received message properly 🫶. Be careful, bestie.

Parsers must accept this message as well formed, even if the application above the parser does not support multipart/signed 💖.

Additional examples of multipart/mime messages, in particular S/MIME messages, are available in the security call flow examples document [SIP-SEC] 📚.

Message Details : mpart01

MESSAGE sip:kumiko@example.org SIP/2.0
<allOneLine>
Via: SIP/2.0/UDP 127.0.0.1:5070
;branch=z9hG4bK-d87543-4dade06d0bdb11ee-1--d87543-;rport
</allOneLine>
Max-Forwards: 70
Route: <sip:127.0.0.1:5080>
<allOneLine>
Identity: r5mwreLuyDRYBi/0TiPwEsY3rEVsk/G2WxhgTV1PF7hHuL
IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD+813gvYjcBUaZngQmXc9WNZSDN
GCzA+fWl9MEUHWIZo1CeJebdY/XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF
teeivUhkMWYUA=
</allOneLine>
Contact: <sip:fluffy@127.0.0.1:5070>
To: <sip:kumiko@example.org>
From: <sip:fluffy@example.com>;tag=2fb0dcc9
Call-ID: 3d9485ad0c49859b@Zmx1ZmZ5LW1hYy0xNi5sb2NhbA..
CSeq: 1 MESSAGE
Content-Transfer-Encoding: binary
Content-Type: multipart/mixed;boundary=7a9cbec02ceef655
Date: Sat, 15 Oct 2005 04:44:56 GMT
User-Agent: SIPimp.org/0.2.5 (curses)
Content-Length: 553

--7a9cbec02ceef655
Content-Type: text/plain
Content-Transfer-Encoding: binary

Hello
--7a9cbec02ceef655
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
<hex>
3082015206092A86
4886F70D010702A08201433082013F02
01013109300706052B0E03021A300B06
092A864886F70D010701318201203082
011C020101307C3070310B3009060355
04061302555331133011060355040813
0A43616C69666F726E69613111300F06
03550407130853616E204A6F7365310E
300C060355040A130573697069743129
3027060355040B132053697069742054
65737420436572746966696361746520
417574686F7269747902080195007102
330113300706052B0E03021A300D0609
2A864886F70D01010105000481808EF4
66F948F0522DD2E5978E9D95AAE9F2FE
15A06659716292E8DA2AA8D8350A68CE
FFAE3CBD2BFF1675DDD5648E593DD647
28F26220F7E941749E330D9A15EDABDB
93D10C42102E7B7289D29CC0C9AE2EFB
C7C0CFF9172F3B027E4FC027E1546DE4
B6AA3ABB3E66CCCB5DD6C64B8383149C
B8E6FF182D944FE57B65BC99D005
</hex>
--7a9cbec02ceef655--

3.1.1.12. Unusual Reason Phrase ✨

this 200 response has a reason phrase other than "OK" 🍓. The reason phrase is meant for humans to read, and it may contain any string produced by:

Reason-Phrase   =  *(reserved / unreserved / escaped
                   / UTF8-NONASCII / UTF8-CONT / SP / HTAB)

This particular response contains unreserved and non-ASCII UTF-8 characters 🌸. The response is well formed, and a parser must accept this message 💅.

Message Details : unreason

<allOneLine>
SIP/2.0 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5</hex>
</allOneLine>
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: unreason.1234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host198.example.com>

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.1.13. Empty Reason Phrase ✨

this well-formed response has no reason phrase at all 🫧. A parser must accept this message 💖. The space character after the reason code is required. If it were not present, this message could be rejected as invalid (a liberal receiver would accept it anyway) 🙈.

Message Details : noreason

SIP/2.0 100<hex>20</hex>
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: noreason.asndj203insdf99223ndf
CSeq: 35 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>

3.1.2. Invalid Messages ✨

this section is a collection of invalid messages 🥀. They reflect errors seen at interoperability events and explore important edge conditions that can be triggered by malformed messages 🔍. This section does not try to be a comprehensive list of every type of invalid message, so don't expect every possible mess to show up here 💀.

3.1.2.1. Extraneous Header Field Separators ✨

okay so this INVITE has way too many semicolons and commas 💅 the Via header has extra ; and , with no parameters or values, and the Contact header has extra semicolons with no parameters either. it is syntactically invalid, bestie 🙈

an element that gets this request should respond with a 400 Bad Request error 💀

Message Details: badinv01

INVITE sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=134161461246
Max-Forwards: 7
Call-ID: badinv01.0ha0isndaksdjasdf3234nas
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;;,;,,
Contact: "Joe" <sip:joe@example.org>;;;;
Content-Length: 152
Content-Type: application/sdp

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.2. Content Length Larger Than Message 🦋

this is a request whose Content-Length is bigger than the body that actually shows up 😭 the body is shorter than what the header promised, so it's giving incomplete

if this came in over UDP (which is what this message is pretending to be), the receiving element should respond with a 400 Bad Request error. but if it arrived over a stream-based transport like TCP, the receiver can't really do much except wait for more data on the stream, and close the connection if nothing shows up within a reasonable period of time. patience is a virtue, ngl 🫶

Message Details: clerr

INVITE sip:user@example.com SIP/2.0
Max-Forwards: 80
To: sip:j.user@example.com
From: sip:caller@example.net;tag=93942939o2
Contact: <sip:caller@hungry.example.net>
Call-ID: clerr.0ha0isndaksdjweiafasdk3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
Content-Type: application/sdp
Content-Length: 9999

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.155
s=-
c=IN IP4 192.0.2.155
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.3. Negative Content-Length 🌈

this request has a negative value for Content-Length 💀 literally who does this

an element that gets this message should respond with an error. since it came in over UDP, the rest of the datagram can just be discarded 🗑️ if a request like this shows up over TCP, the framing error can't be recovered from, so the connection should be closed. the same goes for messages where the Content-Length header doesn't have a numeric value at all, like this one:

Content-Length: five

implementors, pls take extra precautions if the way you turn this ASCII field into an integer can come out negative 👑 the result must not be used as a counter or array index, periodt.

Message Details: ncl

INVITE sip:user@example.com SIP/2.0
Max-Forwards: 254
To: sip:j.user@example.com
From: sip:caller@example.net;tag=32394234
Call-ID: ncl.0ha0isndaksdj2193423r542w35
CSeq: 0 INVITE
Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
Contact: <sip:caller@example53.example.net>
Content-Type: application/sdp
Content-Length: -999

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.53
s=-
c=IN IP4 192.0.2.53
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.4. Request Scalar Fields with Overlarge Values 🎀

this request has a bunch of scalar header field values that are way outside their legal range, and it's a whole mess 😭 the problems are:

the CSeq sequence number is >2**32-1.
the Max-Forwards value is >255.
the Expires value is >2**32-1.
the Contact expires parameter value is >2**32-1.

an element that gets this request should respond with a 400 Bad Request because of the CSeq error. if only the Max-Forwards field was wrong, the element could choose to process the request as if that field weren't there at all. and if only the expiry values were wrong, the element could treat them as the default expiration values instead (3600 in this case) 🧚

other scalar request fields that might have weird values include, but aren't limited to, the Contact q value, the Timestamp value, and the Via ttl parameter. so many places to mess up, iykyk 🙈

Message Details: scalar02

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
To: <sip:user@example.com>
From: <sip:user@example.com>;tag=239232jh3
CSeq: 36893488147419103232 REGISTER
Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32
Max-Forwards: 300
Expires: 1<repeat count=100>0</repeat>
Contact: <sip:user@host129.example.com>
  ;expires=280297596632815
Content-Length: 0

3.1.2.5. Response Scalar Fields with Overlarge Values 🌸

this response has several scalar header field values outside their legal range, so it's giving chaos 🌪️

the CSeq sequence number is >2**32-1.
the Retry-After field is unreasonably large (note that RFC 3261 doesn't define a legal range for this field).
the Warning field has a warning-value with more than 3 digits.

an element that gets this response will just discard it. bye bye 👋

Message Details: scalarlg

SIP/2.0 503 Service Unavailable
<allOneLine>
Via: SIP/2.0/TCP host129.example.com
;branch=z9hG4bKzzxdiwo34sw
;received=192.0.2.129
</allOneLine>
To: <sip:user@example.com>
From: <sip:other@example.net>;tag=2easdjfejw
CSeq: 9292394834772304023312 OPTIONS
Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r
Retry-After: 949302838503028349304023988
Warning: 1812 overture "In Progress"
Content-Length: 0

3.1.2.6. Unterminated Quoted String in Display Name 🍓

this is a request with an unterminated quote in the display name of the To field, which is a big oops 😭 an element that gets this request should return a 400 Bad Request error.

an element could try to guess a closing quote and accept the message anyway. but it has to be careful that its guess is reasonable when it runs into something like this:

To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>

Message Details: quotbal

INVITE sip:user@example.com SIP/2.0
To: "Mr. J. User <sip:j.user@example.com>
From: sip:caller@example.net;tag=93334
Max-Forwards: 10
Call-ID: quotbal.aksdj
Contact: <sip:caller@host59.example.net>
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
Content-Type: application/sdp
Content-Length: 152

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.7. `<>` Enclosing Request-URI 🧚‍♀️

this INVITE is invalid because the Request-URI has been wrapped in "<>" 🙅‍♀️

it's always reasonable to reject a request with this error using a 400 Bad Request. elements that want to be liberal about what they accept can choose to ignore the brackets. but if the element forwards the request, it must not include the brackets in the messages it sends. no brackets in the outgoing message, bestie 💖

the brackets are the whole problem here. don't pass them along.

Message Details: ltgtruri

INVITE <sip:user@example.com> SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=39291
Max-Forwards: 23
Call-ID: ltgtruri.1@192.0.2.5
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.0.2.5
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 159

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.8. Malformed SIP Request-URI (embedded LWS) 🦋

this INVITE has illegal LWS (linear whitespace) sitting inside the Request-URI 🙃

an element that gets this request should respond with a 400 Bad Request.

an element could try to ignore the embedded LWS, but only for schemes (like SIP) where doing that wouldn't introduce any ambiguity. 🧠

Message Details: lwsruri

INVITE sip:user@example.com; lr SIP/2.0
To: sip:user@example.com;tag=3xfe-9921883-z9f
From: sip:caller@example.net;tag=231413434
Max-Forwards: 5
Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423
CSeq: 2130706432 INVITE
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 159

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=3149328700 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.9. Multiple SP Separating Request-Line Elements ✨

this INVITE has illegal multiple SP (space) characters between the elements of the start line. it's giving extra spaces, no thank you 🙈

it's fine to reject this request as malformed. an element that is liberal in what it accepts can ignore these extra SP characters when it processes the request. if the element forwards the request, it must not include these extra SP characters in the messages it sends. clean outgoing lines only, slay 💅

Message Details: lwsstart

INVITE  sip:user@example.com  SIP/2.0
Max-Forwards: 8
To: sip:user@example.com
From: sip:caller@example.net;tag=8814
Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com
CSeq: 1893884 INVITE
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923
Contact: <sip:caller@host1.example.net>
Content-Type: application/sdp
Content-Length: 150

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.10. SP Characters at End of Request-Line 💜

this OPTIONS request has SP characters sitting between the SIP-Version field and the CRLF that ends the Request-Line 🫠 the trailing spaces are the main character of this message, lowkey

Message Details: trws

OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK299342093
To: <sip:remote-target@example.com>
From: <sip:local-resource@example.com>;tag=329429089
Call-ID: trws.oicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0

3.1.2.11. Escaped Headers in SIP Request-URI ✨

okay so this INVITE is malformed 🙈 bc the SIP Request-URI is carrying escaped headers, and that's a no-go bestie 💀

it's totally fine for an element to bounce this with a 400 Bad Request 🫶 an element could also be super liberal and just ignore the escaped headers if it wants. but if the element is a proxy, those escaped headers must not show up in the Request-URI of the forwarded request. and they definitely must not get translated into the actual header of the forwarded request. no sneaky copying allowed 🚫✨

Message Details : escruri

INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=341518
Max-Forwards: 7
Contact: <sip:caller@host39923.example.net>
Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
CSeq: 149209342 INVITE
Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw
Content-Type: application/sdp
Content-Length: 150

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.12. Invalid Time Zone in Date Header Field 🌍

this INVITE is invalid bc it has a non-GMT time zone in the SIP Date header field. it's giving "wrong timezone" energy 🕰️

rejecting it as malformed is acceptable 💅 but an element shouldn't really do that unless the Date header field actually matters for what it's doing. if an element wants to be liberal, it can ignore the value entirely when it wasn't gonna use the Date header anyway. otherwise it could try to interpret the date and adjust it to GMT ✨

RFC 3261 explicitly defines the only acceptable time zone designation as "GMT". "UT" is synonymous with GMT per [RFC2822], but it's still not valid 😭. "UTC" and "UCT" are also invalid. no thank you 🙅‍♀️

Message Details : baddate

INVITE sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=2234923
Max-Forwards: 70
Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234
CSeq: 1392934 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
Date: Fri, 01 Jan 2010 16:00:00 EST
Contact: <sip:caller@host5.example.net>
Content-Type: application/sdp
Content-Length: 150

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.13. Failure to Enclose name-addr URI in <> 🎀

this REGISTER request is malformed 🥲. the SIP URI in the Contact header field has an escaped header, so the field has to be in name-addr form. and name-addr form means the URI has to be wrapped in <> 🎁

responding with a 400 Bad Request is totally reasonable 💖. an element that wants to be liberal could infer the angle brackets, since there's no ambiguity in this example. just know that in general that won't be possible 🫠

Message Details : regbadct

REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=998332
Max-Forwards: 70
Call-ID: regbadct.k345asrl3fdbv@10.0.0.1
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E
l: 0

3.1.2.14. Spaces within addr-spec 🫧

this request is malformed bc the addr-spec in the To header field has spaces in it 🙃. parsers that get this request must not break 💪. rejecting it with a 400 Bad Request is reasonable, and elements trying to be liberal can just ignore the spaces ✨

Message Details : badaspec

OPTIONS sip:user@example.org SIP/2.0
Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234
Max-Forwards: 70
From: "Bell, Alexander" <sip:a.g.bell@example.com>;tag=433423
To: "Watson, Thomas" < sip:t.watson@example.org >
Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0

3.1.2.15. Non-token Characters in Display Name 🌸

this OPTIONS request is malformed 🤨 bc the display names in To and From contain non-token characters but aren't quoted. the drama is real 🎭

rejecting this kind of error with a 400 Bad Request is always reasonable 🫶

an element can try to be liberal and infer the missing quotes. but if this element is a proxy, it must not pass the error along into the request it forwards 🚫. and if the fields are covered by a signature, there's not much point in trying to be liberal. the message should just get rejected 😤

Message Details : baddn

OPTIONS sip:t.watson@example.org SIP/2.0
Via:     SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards:      70
From:    Bell, Alexander <sip:a.g.bell@example.com>;tag=43
To:      Watson, Thomas <sip:t.watson@example.org>
Call-ID: baddn.31415@c.example.com
Accept: application/sdp
CSeq:    3923239 OPTIONS
l: 0

3.1.2.16. Unknown Protocol Version 🔢

to an element that implements [RFC3261], this request is malformed bc of its super high version number 🚀

the element should answer with a 505 Version Not Supported error 💜

Message Details : badvers

OPTIONS sip:t.watson@example.org SIP/7.0
Via:     SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw
Max-Forwards:     70
From:    A. Bell <sip:a.g.bell@example.com>;tag=qweoiqpe
To:      T. Watson <sip:t.watson@example.org>
Call-ID: badvers.31417@c.example.com
CSeq:    1 OPTIONS
l: 0

3.1.2.17. Start Line and CSeq Method Mismatch 🙅‍♀️

this request has mismatched method values in the start line and the CSeq header field. literally any element that gets this will respond with a 400 Bad Request 💀

Message Details : mismatch01

OPTIONS sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch01.dj0234sxdfl3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
l: 0

3.1.2.18. Unknown Method with CSeq Method Mismatch 🧩

this message has an unknown method in the start line, AND its CSeq method tag doesn't match. main character chaos 🌀

any element that gets this should respond with a 501 Not Implemented 💅. a 400 Bad Request is also acceptable, but picking a 501 (especially at proxies) has better future-proof characteristics 🔮✨

Message Details : mismatch02

NEWMETHOD sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: mismatch02.dj0234sxdfl3
CSeq: 8 INVITE
Contact: <sip:caller@host.example.net>
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw
Content-Type: application/sdp
l: 138

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
c=IN IP4 192.0.2.1
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.1.2.19. Overlarge Response Code 💥

this response has a response code bigger than 699 😳. an element that gets it should simply drop it, no drama 🫧

Message Details : bigcode

SIP/2.0 4294967301 better not break the receiver
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i
CSeq: 353494 INVITE
From: <sip:user@example.com>;tag=39ansfi3
To: <sip:user@example.edu>;tag=902jndnke3
Content-Length: 0
Contact: <sip:user@host105.example.com>

3.2. Transaction Layer Semantics 🔁

this section has tests that check an implementation's parser and transaction-layer logic 🧠

3.2.1. Missing Transaction Identifier 🪪

this request says it supports RFC 3261-style transaction identifiers bc it includes the z9hG4bK prefix on the branch parameter 🏷️. but it doesn't actually provide an identifier 😭

a parser must not break when it gets this message 💪. an element receiving this request could reject it with a 400 Response (preferably statelessly, since other requests from the same source are probably malformed in the branch parameter too). or it could fall back to the RFC 2543-style transaction identifier 🔄

Message Details : badbranch

OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK
Accept: application/sdp
Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n
CSeq: 8 OPTIONS
l: 0

3.3. Application-Layer Semantics 🎀

this section has tests that check an implementation's parser and application-layer logic 🧚

3.3.1. Missing Required Header Fields 🫥

this request has no Call-ID, From, or To header fields 😱

an element that gets this message must not break because of the missing info 💖. ideally it'll respond with a 400 Bad Request error 🌷

Message Details : insuf

INVITE sip:user@example.com SIP/2.0
CSeq: 193942 INVITE
Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf
Content-Type: application/sdp
l: 152

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.95
s=-
c=IN IP4 192.0.2.95
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.3.2. Request-URI with Unknown Scheme 🛸

this OPTIONS has an unknown URI scheme in the Request-URI 👽. a parser must accept this as a well-formed SIP request ✅

an element that gets this request will reject it with a 416 Unsupported URI Scheme response 🙅

some early implementations try to look at the To header field to figure out how to route this kind of request. that's an error 🚫. even though the To header field and the Request-URI often look alike in simple first-hop messages, the To header field has no routing info in it 💅

Message Details : unkscm

OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0

3.3.3. Request-URI with Known but Atypical Scheme 🦋

this OPTIONS has a Request-URI with an IANA-registered scheme that doesn't usually show up in Request-URIs of SIP requests 🤔. a parser must accept this as a well-formed SIP request 💜

if an element will never accept this scheme as meaningful in a Request-URI, it's appropriate to treat it as unknown and return a 416 Unsupported URI Scheme response 🙅‍♀️. if the element might accept some URIs with this scheme, then a 404 Not Found is appropriate for the URIs it doesn't accept 🌈

Message Details : novelsc

OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: novelsc.asdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0

3.3.4. Unknown URI Schemes in Header Fields 🦋

okay so this message has registered schemes in the To, From, and Contact header fields of a request 🔗. it's syntactically valid ✅, so parsers must not fail when they get it 💅

proxies should treat this message the same way they'd treat any other request for this URI. a registrar would reject it with a 400 Bad Request response, since the To: header field is required to contain a SIP or SIPS URI as an AOR 🙅‍♀️

Message Details : unksm2

REGISTER sip:example.com SIP/2.0
To: isbn:2983792873
From: <http://www.example.com>;tag=3234233
Call-ID: unksm2.daksdj@hyphenated-host.example.com
CSeq: 234902 REGISTER
Max-Forwards: 70
Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw
Contact: <name:John_Smith>
l: 0

3.3.5. Proxy-Require and Require 🎀

this request is testing whether SIP's Proxy-Require and Require extension mechanisms are implemented properly 🧐

any element that gets this request will respond with a 420 Bad Extension, and the response carries an Unsupported header field listing the features from either the Require or the Proxy-Require header field. which one depends on the role the element is playing when it responds 🫶

Message Details : bext01

OPTIONS sip:user@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.net;tag=242etr
Max-Forwards: 6
Call-ID: bext01.0ha0isndaksdj
Require: nothingSupportsThis, nothingSupportsThisEither
Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis
CSeq: 8 OPTIONS
Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw
Content-Length: 0

3.3.6. Unknown Content-Type 🌸

this INVITE has a body of unknown type, but it's still syntactically valid 🥹 a parser must not fail when it receives this one

a proxy would process it just like any other INVITE 🔁. an endpoint that gets it will reject it with a 415 Unsupported Media Type error 🚫

Message Details : invut

INVITE sip:user@example.com SIP/2.0
Contact: <sip:caller@host5.example.net>
To: sip:j.user@example.com
From: sip:caller@example.net;tag=8392034
Max-Forwards: 70
Call-ID: invut.0ha0isndaksdjadsfij34n23d
CSeq: 235448 INVITE
Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw
Content-Type: application/unknownformat
Content-Length: 40

<audio>
 <pcmu port="443"/>
</audio>

3.3.7. Unknown Authorization Scheme 🔐

this REGISTER has an Authorization header field with a scheme nobody knows 😭 the request is well formed, and a parser must not fail when it gets it

a proxy will handle this request just like any other REGISTER. if it forwards the request, it keeps this Authorization header field unmodified in the forwarded messages 📬

a registrar that doesn't care about challenge-response authentication will just ignore the Authorization header field and process the registration like the field wasn't there 🙈. a registrar that does care about challenge-response authentication will reject the request with a 401 and issue a new challenge using a scheme it understands 🔑

endpoints that choose not to act as registrars will simply reject the request, and a 405 Method Not Allowed is the right move there 💅

Message Details : regaut01

REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=87321hj23128
Max-Forwards: 8
Call-ID: regaut01.0ha0isndaksdj
CSeq: 9338 REGISTER
Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
Authorization: NoOneKnowsThisScheme opaque-data=here
Content-Length:0

3.3.8. Multiple Values in Single Value Required Fields 🧚

this request has more than one Call-ID, To, From, Max-Forwards, and CSeq value, which is a lot of drama for one message 😤 an element that receives it must not break

the element would respond with a 400 Bad Request error 🙅‍♀️

Message Details : multi01

INVITE sip:user@company.com SIP/2.0
Contact: <sip:caller@host25.example.net>
Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw
Max-Forwards: 70
CSeq: 5 INVITE
Call-ID: multi01.98asdh@192.0.2.1
CSeq: 59 INVITE
Call-ID: multi01.98asdh@192.0.2.2
From: sip:caller@example.com;tag=3413415
To: sip:user@example.com
To: sip:other@example.net
From: sip:caller@example.net;tag=2923420123
Content-Type: application/sdp
l: 154
Contact: <sip:caller@host36.example.net>
Max-Forwards: 5

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.25
s=-
c=IN IP4 192.0.2.25
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.3.9. Multiple Content-Length Values 🍓

this request has multiple Content-Length header field values that conflict with each other, and that's a whole mess 🥴

from a framing perspective, this is the same as having an invalid Content-Length value (or no value at all) 🧾

an element that gets this message should respond with an error. this request came in over UDP, so the rest of the datagram can just be discarded 🗑️. if a request like this arrives over TCP, the framing error can't be recovered from, and the connection should be closed 🔌

Message Details : mcl01

OPTIONS sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423
To: sip:user@example.com
From: sip:other@example.net;tag=3923942
Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf
CSeq: 15932 OPTIONS
Content-Length: 13
Max-Forwards: 60
Content-Length: 5
Content-Type: text/plain

There's no way to know how many octets are supposed to be here.

3.3.10. 200 OK Response with Broadcast Via Header Field Value 📡

this message is a response where the sent-by of the 2nd Via header field value is 255.255.255.255 👀. it's well formed, so parsers must not fail when they get it

per [RFC3261], an endpoint that receives this message should simply discard it 🫠

if a proxy followed the normal response processing rules blindly, it would forward this response to the broadcast address. to protect against that being used as an avenue of attack, proxies should drop these responses 🛡️

Message Details : bcast

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23
Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 154
Content-Type: application/sdp
Contact: <sip:user@host28.example.com>

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.3.11. Max-Forwards of Zero 💜

this is a totally legal SIP request, and its Max-Forwards header field value is set to zero 🫧

a proxy should not forward the request, and should respond with 483 (Too Many Hops) instead 🙅‍♀️. an endpoint should process the request as if the Max-Forwards field value were still positive 💖

Message Details : zeromf

OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=3ghsd41
Call-ID: zeromf.jfasdlfnm2o2l43r5u0asdfas
CSeq: 39234321 OPTIONS
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i
Max-Forwards: 0
Content-Length: 0

3.3.12. REGISTER with a Contact Header Parameter 🌈

this REGISTER has a contact where the 'unknownparam' parameter has to be read as a contact-param and not as a url-param 🧠

this REGISTER should succeed. the response must not include "unknownparam" as a url-parameter for this binding ✅. and "unknownparam" must not show up as a url-parameter in any binding during later fetches either 🔍

the behavior is the same for any known contact-param parameter names, obviously 💅

Message Details : cparam01

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe
To: sip:watson@example.com
Call-ID: cparam01.70710@saturn.example.com
CSeq: 2 REGISTER
Contact: sip:+19725552222@gw1.example.net;unknownparam
l: 0

3.3.13. REGISTER with a url-parameter 🧁

this REGISTER has a contact where the URI itself carries an unknown parameter 🤭

the register should succeed, and when the registration is fetched later, it must include "unknownparam" as a url-parameter 📋

the behavior is the same for any known url-parameter names too 🫶

Message Details : cparam02

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=838293
To: sip:watson@example.com
Call-ID: cparam02.70710@saturn.example.com
CSeq: 3 REGISTER
Contact: <sip:+19725552222@gw1.example.net;unknownparam>
l: 0

3.3.14. REGISTER with a URL Escaped Header ✨

this REGISTER has a contact where the URI has an escaped header 🎁

the register should succeed. a later retrieval of the registration must include the escaped Route header in the contact URI for this binding 🔗

Message Details : regescrt

REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=8
Max-Forwards: 70
Call-ID: regescrt.k345asrl3fdbv@192.0.2.1
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
M: <sip:user@example.com?Route=%3Csip:sip.example.com%3E>
L:0

3.3.15. Unacceptable Accept Offering 🙈

this request says the response has to contain a body of an unknown type 😬. since the Accept header field doesn't include application/sdp, the response may not contain an SDP body

the recipient could respond with a 406 Not Acceptable, with a Warning/399 saying that a response can't be formulated in the formats listed in the Accept header field. responding with a 400 Bad Request is also appropriate, since all SIP User-Agents (UAs) that support INVITE are required to support application/sdp 🎀

Message Details : sdp01

INVITE sip:user@example.com SIP/2.0
To: sip:j_user@example.com
Contact: <sip:caller@host15.example.net>
From: sip:caller@example.net;tag=234
Max-Forwards: 5
Call-ID: sdp01.ndaksdj9342dasdd
Accept: text/nobodyKnowsThis
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw
Content-Length: 150
Content-Type: application/sdp

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC

3.4. Backward Compatibility 👑

3.4.1. INVITE with RFC 2543 Syntax

okay so this one is a legal message under RFC 2543 (and a few bis versions) 🎀 that RFC 3261 elements should still accept if they want to keep backwards compatibility. it's giving old-school vibes, and I'm obsessed ✨

There is no branch parameter at all on the Via header field value.
There is no From tag.
There is no explicit Content-Length. (The body is assumed to be all octets in the datagram after the null-line.)
There is no Max-Forwards header field.

Message Details : inv2543

INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP iftgw.example.com
From: <sip:+13035551111@ift.client.example.net;user=phone>
Record-Route: <sip:UserB@example.com;maddr=ss1.example.com>
To: sip:+16505552222@ss1.example.net;user=phone
Call-ID: inv2543.1717@ift.client.example.com
CSeq: 56 INVITE
Content-Type: application/sdp

v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 49217 RTP/AVP 0

4. Security Considerations ✨

bestie, this document is just NON-NORMATIVE examples of SIP session establishment 🧚 and the security considerations in [RFC3261] still apply, so go read those too 💅

parsers gotta be SO careful about edge conditions and sketchy input 😭 attacks on loads of internet systems work by sending crafted input to make implementations act badly, and a bunch of the messages in this document are built to stress a parser right at the spots attackers love to poke 💀 but this doc is not trying to be comprehensive. think of it as a seed to get your brain thinking and planning, not just a checklist of tests to pass 🌱

5. Acknowledgements 🫶

the final detailed review of this document was done by Diego Besprosvan, Vijay Gurbani, Shashi Kumar, Derek MacDonald, Gautham Narasimhan, Nils Ohlmeier, Bob Penfield, Reinaldo Penno, Marc Petit-Huguenin, Richard Sugarman, and Venkatesh Venkataramanan 👑

earlier versions were reviewed by Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua, and Tom Taylor 🌸

thanks to Cullen Jennings and Eric Rescorla for their work on the multipart/mime sections and for building the S/MIME examples in [SIP-SEC] 🦋 thanks to Neil Deason for contributing several messages, and to Kundan Singh for running parser validation of messages in earlier versions 💖

the following people gave super important comments during the early phases of this document: Jean-Francois Mule, Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, Matt Cannon, John Hearty, the whole MCI IPOP Design team, Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI, 3Com, Cisco, Lucent, and Nortel 🔥

6. Informative References 📚

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[SIP-SEC] Jennings, C. and K. Ono, "Example call flows using SIP security mechanisms", Work in Progress, July 2005.

Appendix A. Bit-Exact Archive of Each Test Message 🎁

this is an encoded, gzip-compressed TAR archive of files, one for each of the example messages from Section 3 🍓 to get the compressed archive back intact, you can pass the text of this document into the Perl script below (send the output to a file or pipe it to "tar -xzvf -") 🧚

#!/usr/bin/perl
use strict;
my $bdata = "";
use MIME::Base64;
while(<>) {
 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) {
     if ( m/^\s*[^\s]+\s*$/) {
         $bdata = $bdata . $_;
     }
  }
}
print decode_base64($bdata);

Figure 58

or, if Perl isn't your thing, you can hand-edit the base-64 encoded block to remove the document structure lines and feed it to any base-64 decoding utility 💜

A.1. Encoded Reference Messages ✨

okay bestie, here comes the big encoded archive 🎀 it holds every reference message from the appendix, all wrapped up together 📦🫶

-- BEGIN MESSAGE ARCHIVE --
H4sIAEDwcEMCA+xdW2zc2Hm2nexNG6UN3LRF0QfaiKJdyxwdnkMOhyOPVrIt
27It22tdvHYTeM8MDzWc4ZAjkqORvK2bbIAAedmHtEHRdlvkoUCLFAjSlyLF
9rJPLYoWrTdAg6JFHwp0i+5D0SIoEAQFuj2HnAuH5GgoW3PxmgcazYU/b4f/
//3Xc04Rq9ipk1JGxe6xITVAW1YUvXc5K/W8syYheEygP0lIECWJ0gkSkMAx
DhwbQWs4LrY57phdcerYrjr96AZtb91L5/0paTdvbazevLHOOXo933CIvUT2
cK1ukIxlb3Prq7fmYQZMT23pON/+Nr958RZXthxXzLRpS1YtL4EsWCja2CyV
Cw+U8mWxeK2qVhoigkicnlrDe/wly25iW3XynEwPecmmO3GnzxPDOMstG/RQ
pkrs09w5diU4s50p0i1LgTMsLrh4uyAiJEI0PbVh0Z3vYNexzLPcRtmqYYfu
692Gm2l6v/fcyuL01AVsGPzqxTxXbPO8o2qAXp4JTdUBGChKA6IyKptmEwCl
pFZNQs+0XCqRupvncL1u6CXs6pY576h1erx1spPnkALpLSpcqyOnp4w8R29v
eurpeP60L/yHNkQAGCT/IsiG5R8KMJX/sco/lbiu/DNpi6NoizHbVqLi1Ysf
nsAiBEUYBgAUAymCQj9lYEYIochBEhiQ6BYXO1i1TM2CSBchqOwC7AAKKxqq
ILMtsbmnVVaHJP9U8Mkw1f8g+RcAFI+xf6IIBJRFVP7FbDbV/yNpqze2VjdW
jl78TeJ64g+pflWYwo5aAEHp9XiQqlGq22smlWEqsBAZFRHyvENUzax5VoQv
vwJVuQoSOf/S+xgnQdskxixpTk9dpKfMc5ds/SwHBO4qNjlIWZETsnkA6B+3
sr5Bz2iZLi5R7DkXuEd2fCkTuNNFn5CYLr+xXydxSNXafJ2Y226Z3oPk4c5u
gb5ZhVqZGj8G2eegIlNTQoYyvUGF3iC3ekvsAKM0PeUU+OmpUiG6wS0AhmS1
Am6ousXRLhdk7vbGrfnlrVscvSnItu3qKrE4BGF3ExKmp3DBdus1XM8jgbt+
68KzjIbPJv6bQ0X/BP6fgEL2n4gkKcX/Udt/sY5Trw/IWhBqS0l8wGYY/b3W
dQJpC7mBg71AXyl5rdcL9HeNu5WQC0jZnvKbIC313MNAf4+2Pi7f0yr/urkL
hHHGf2QEwvafDFAq/xNn/1Uyj2EBCkgUstSiF6CYjZiBvSLpcyIoY6A7poqr
jlrBDrUFWYwGO13/ra/l1/EhpYWFswtnzwYMuNNXLdKKLlUs0oMLC7TFmWhw
oFl3SAtO6GvCCeOy4Wiv7xLbGaf/B0QxqP8lT/5RNpX/idH/ckT/y3H6P6nq
79H8yxlP+Q/S+DtNYuk7dRLQ+xuZlupPrPI9TmdKXw4r/Y5uF56x4FCxhKmz
PFb7n4p+JP6Dsqn8j6S1tCcHAeBuXjtIpSq5kHwLCPqhncg+UJIygVd4PwcX
ic127Mqmx4UA5cScCCAQqMKnyl/DVVSBxG4SVXOW11Wtk3OROiZA1/wImya+
8SFQaUdtdyFCRtRGK0oFlTgLQEwU2OkGiLyDs/AQzAXxZfHwloKS62sqsE1p
vCdtR4P/ZM8drveXIP4jS2H7T4RCiv+Tl/+r3H+cFIAIiWuHDcFsEP59Juxx
/KanbpOdhm5T0DUtt6yb2+uNet2yXWejrDtn435c0d0yoSe6ZVt7+3xgd/aD
TpwWbXt/+6K1bO5Ht8XkCXs03Mb1dU6zDJWnQM5T7vEUySArOKxbJsWyLOrb
JUsda/4PSIIY8f/S+M9o7T8RKqKSlREQqDS6LrGZgHFFm+AqR6WKs0mJ6LtM
uvpbiCBs6UGk5Kg4WyQo6y2Gw45qaahRgQDRj6aG6BU06Keyhh1Eyl7gBzuK
3rX5kKiIIbvvXBxs+Q4jUrDpaHrL8jsXZ/r5hAqAFVM1q6zWJ0ZK+xh49GYj
Ft7TqP9LFLHtMed/5CwM+3/UaE/lf2Liv72aO/ekEWGF5fnpPwv2S7A3zG17
P5xhbyOIz7I9xkKT6JiihVpFCYLEven7qMbmWX5H5CGSIDp0Yl+h7THiwgcE
hocbGS5Rpsa18eZ/JCBE9b+cyv8o2u2Vy6vrGyu3PXmNFf6I/DjYbdjmYyV+
u5FfdrpQvLYds7lY1ba2K1XbXWtiYl+71g76xu8SBIY2L1PuEcBS9Drb4AC5
9m0HAIgdfk5QZEhZENK2tN0UghC00DCrptU0vZN8YqLDrT6D45R/MStH5B+m
+v9Zlf8cylEleTiZhwNlHsXJ/LlDCf3iJzAnpBYNm+yMNf4nICkbtv+ltP5r
UuQ/makf3doq1IKSUEEVBCODgHLTU6t5rsV/Pda8ojDfXzMNZFQhQqIAQ2q6
dbJwnW/X9u+Kev9oBZTiEMsrV+4TrqMX3PWWgkUkPf3Vvsbe7UkKZajTi+K6
qQN24c5SZJnKleJJ01KwlOQwhTIxnYBywK+3Hn5R85OXxHCJPZ800xVtxCkN
O/0zOP+P5DD+wzT+M/L4D305M2iZQeuMCALYFUSqqF6YkSWHzMgwDu08+2p1
BlLE2iX0jXZhiTjB47VisCgXwT15ekrPcz5/spEhQPFCwtVK1YTIMukXwKPA
sBDIBoaKScM+DHTjEzUHJPmnp7hOnGomeyFuKMgC/Z12xoI5kxVqpLBL34wG
vXVpBokzSFg8ItTsC5ppaUDaDov/cMzx/2zU/6eSnOL/aOz/GVGmtvKMKPk+
gE22dce1sZ3p6w2cnrlHyVvF1DZxrIZd6jF2FzvD+wdSevCvQQQrWNUqPUVh
Pmsy0Dd3mhYS7R2IdCRWbJYbLJkGRKZtVE2H1YX1JugvDBwDCIEyoz1wTGIE
NYiCRJEL9kjssMWe4AE2dOwIfkowlBC8MJO9FCGFfnlYmDR6TOQRohDhkccf
aCebDcMYb/5fjMb/sun4/wnz/xmb8DMA8OxDP9e2L1Ersqco0J+/44DhwG2W
RAoEyFS13WpFxY5W3UFN0XLtHYBVR6OggHfVzpBgESk5Zv0d4PgPSvsFCnW6
okhvZSmy42IMVT/C6/nJjhfSzrYbtj7e8f9iJP4nS6n+H7X/Fw7gvXbbarik
MIMuhLBhBq0cydwASBQkIRc3JqzfqHsPP/rVBbRZ2XMWeWY3lCs8rhBUtHmK
DTtAyTV5DTeJXYY7fFk0pS58UKihyh8e7D3ylsa7ZcKXqRmTvOJvmMGz1A1M
25M13XQa2pj9PzEbGf8rpvnfseN/F+NbKOnVbQ3OKSgxOYWMx2cDQdFoDbs9
JA4qfZMISjo3yiD5d2vELY/V/oM99V9Z3/5L/b+RtFOUAYhNHFc3t/k1ygmW
6g2/k7JyTrl/Zu7NzIxuqoSosw89kBDuN8yG08BGZvP26sNXXIsvklNOwyav
flF3zFl3Tne/MF+y8YP9187OLyycyX9Rd+fK2CkIZ5tEt9VTZ+rY+ULTeqje
dy0r84pqEbYbr7uvLg0uP2lHdoSDyjczp2ay2TP3596cfdiKV51fuZ7/0gvc
jU36doy7yL79aisoddj7iQ1zuVaVmMLDN/0PcHbuvv8JnZk5leH9E9UaporN
UPBLo7vfYqUls7MP587cp8QzhdMffOXR9x790aM//+DtR9/74J0PvvHo+4/+
5LRnMN/3jvpQmJ17kx6ZzwSM37YcNy1bnbl3jT+VoT0wu8S+vvnw1VcWz+W/
NH/6y7/02q+8FZhGS4AQ5STuEDwQNtYhK08lexTTHQriVwhWiU3PPXNm7j7t
/vx/vfcXH/7e73/41Xc/+u33JncMzLNt/+1CSURjjf9lvfF/IfsvHf83avtv
k9p/55eS1QDqmrvdzPTL+M4JCCBJkgTalihppmToVPB7C+vo2Qr1smWSRTbU
r0SBivcCDq1jRK5moYZV1S44TjjO3o5AzAlZCbTr+IJkvafrAU2f+QVZkOOu
M1BTJGU7hu/Rzgnz+LP6HQl20i5ouOPO/wE5bP+J6fyfk+T/JZ0F84mGBeW8
gL94YG7AZ9feGaJUR9MrbBZvpHZrQSRRPKD8zbFqJNksof2FvVUZrFl2DbtR
40b0rJtznuTSnuHO1Uu1BsfGGBdOiyI6PU9/PDff3jy2529Y5vawC4AHyH82
K6NI/D/N/02Q/HtO1CrHirg4zDE6zsQ1wlkaR21/m9TIE75xddtiokHl6nTs
mN58lvZpTzG+UNgl9j5j36N87WKjQRbYJ+8k7C6H/So4ZXrn/omHcUtxL8/n
JNTpu0Hf7uhu+Ya1xS6AebQ+RuMafkDdQcO7HB+w2cUO8+doQTRUcpP4J0Kx
zYplz+MdCq8U/FMEzuDxyNH8a1+/99QN4jidWzjyDwHt3VY21Aq3Cf1xf/T/
2yynd2wFlGOVA6BjLGz6PcNfp5RH+eKZrOW5VsfzRy3SvP9ch3f8ehszeA/7
C6M4k3dPMTFAilAI9bppu1EK2EuxFaUQQhRx5wFhmuUIDVRCNKvR4/TOCMZo
Yo4jh+4p5npgNkwTcxwpRBN3PWKYJuY4oT7e4vJchCbUy7txNOF+5rjouUD4
OFEaQYk8rxiiXJQohkoe/OiFbAIaKQGNmIAGJaCBCWgSsLQABtMog0lyg0kS
dHKCPk7QxQl6OEEHJ+nfASQRr7I1cY5a6MR12o7mqIy9Ubz8W2rB9cCa2THY
lo+xZofxLBTlGO62O+wCwIHz/0Tmf5WEtP5vpP5//ERaR1Plp0BFiOQNg4X+
HR4UlgLB71aWcnC9iTTMZXqUIw7oI0FUEMzJYEKAwGg6qu7Ux5r/QzKL/7OB
3jKbDNqP/6X1XyNpR7P+ny9x52JQoDsf34Cq/zYjssIDXCypSxr1L/fjUnFZ
0GdiTgYKkb3iw/rpwn9d+R9//T8K5/8lANL5P8Yd/1/gDHswBPjCvacRXqFK
LJdD/ANFSzIrMPJnZo/k+6ReUPC4058MVLWIpbOll7zi/qZt+p9ySLSr3qCi
VvJPQNSkzIooQa2q0HfqIoiUgwwLYfSGxcGOxaQZFml7WvCfAaA7Vv9PhhH/
T07rP0aJ//H2X98ZYJ/IIczlBLEX41scqFXNHWr9UYwXEVAUrLKh37hJ0FKM
FSjkFJTLDZjvQxhkCSKlPcfrcFB+4sNHtZIx7vl/gCRnw/Vf6fwPE+X/HXoy
HTaVAkTJYMJiqzbEhY3YcKMAUPisqpVNZgJatl7GTU21MLJEW4IW0m2nu0IQ
ta+o+ddxEyOCGfFFsyBKJYUF3iV77nzdwLrJxHqDXjaZdTjT4pp4n3MtjuVD
adc0uRo29zmr5BLX4bBNOIetLuEQlREVCcd2zEyG+1nTnRp2S+VhgsDA+I8k
huRfgmn95yTGfx6rrhOJEpQOWv4lyIMVNvOgs6dqRtKp3NNgz5HIPxyf/Mve
+L8e+59+SeV/FO3Gyp21lY0rNy9OBgLAAQjQ11IPGeoHI0X/yf8GZ4TZTIWH
N+njrPmJiNHUKFMPewG4AfIPRYH5/wjK9Mkj4M3/JKX6fzRtbWV9ffmyHwCu
Nmp61Yqs/hvvAQhQpowMvAiqHI6g8mpOlkTEiypWCciqoKgWBYEQXuDbmxZs
VvAdlxIKjgILniUHqGCvqlQ+dXc/z9lSrWmT6439i7fvntfnwYZ+q7ni3EX2
ypZTnb8M7+yVtze2hFuX5PKVxvXVa+Duna1r98rXdpW1Sm6TvLFTXdsqmls7
SL5wcS4noO3du5XS+U18z9x+vfZGSblz4976xRuXLzxYntPuGMrayuaVO6v3
LOECuUqK6t35N4zta2QDg5vG7g6wXRm8LlX0da24s3a19vollxB9d7NcXbtz
d3O5EAYuzWho2v5Sbx8uBpaqij6KxZ4Rdq0DRLJsUCsCtVRSAtiKVEXMSVgF
JVHJSUpx6V5tT7hXuyddvyOU7+6DvRu65BThjXJxOZPppt1bjBHARJstqEVs
fsUsWapubrO1vExs74dhs9YwXJ3BynxN3yPqQtFiQ5/t/YKMlVKRlAAsEaJl
2cjhi5g96XXsnqUeG3ez5LJ1aCUOiHlRzEtZ7vLaxvQUGwnIL2/TE3gcqNfq
rD/mvZQ690qpYTvEeTXGe5MQQ2qej562v1eX4Ganp64Qw7CSHDmoQDxvkHdc
m7DVQxKdB7x9/PbzL535+pWv/3j6+Asnvv328Qv0p9dOHD8uvAReeP65uc9+
6sQvgJe7JMeFt49zlOQXKQn4ZVAXXgYvPf+pzU8/f/LE5rpwEnyOfXnxJOMN
XbNsU8fC58BPsR9fOPniOja5q9RJFT4LPsN+mjr5HOU03RVeBbPs+8snuXX2
ndsgjstdILara+zmCLfccMvUH3f3T7x4/FvHdk6g4ye7lzfdubzjx5879umv
fuWd/9F+cuW/b/M/+PA33vmdb33nox/93+e/rd3dKX7zP/7pzB/8ozRV/ruP
v3vuz+Y+/tnGv/yD+s7dwg8vv/KjIvfjj5bd30XTv/X5//zDf/61Dz5z/qcz
b9nf+MG77//1dzP/+1fv//1Pfm5+4cTDm+/P/utG7d/++Dv59xa1v/2bL//w
L6997Ws/8+73//3jn+d//eaHb5E//c1Hz8U9OJ5/Vr0DT1jHq/8FCILjv0Rf
/6frP40l/0s1SR2b+wnHf0JpkN3dtnfjV1uIrQjxx1t3Tf6Ok9BiVSXHlolc
CljSrV2UxPvAA5yWTk6bpafZIgT9Y5jtLZEIZpL8tzcTJptnI1khqnjQtHjZ
0GOIZNQP6bHAvkVs8KgnVErDMmNtZskYcvYnQfynZ/5PD/9BWv83HvxPsP4n
FZj0ZPEgL7WDgllgxoc9w/qh4KWQbEmETdQpBwYJyoFRkol9e69MQk+W6OUf
Z9VP5p/0qRRGIxsqYFrUIXEsc6zr/0EYyP/IXv0HSuV/JK29/jftf+6J1/bu
MBOmUsxW9tbZ7PyKAiGbx7u7kne6ivfk6H9rlxhOaaz1/yKUQvKf1v+PPP9r
4XqmSEg9Pz/fFXqURwDAoxkGlItU+qIe6PD50K/0pYcHOxRhzKZf+Fs1uqt0
IH8JgT5jANpjMJUklV9iOifhTsNyi3i863/IohS2/+V0/c8Jsv+9+X/W7Ax3
NcOxaLyvRaOm/2ICHFBQzCKXQnAkUJslPTfgoLF9SthoT7rqpaTkJSCBBLCQ
uNATjmHly6PIEdtkGzeGnABONv97r/4X0/k/R9KGvP5vTkZQKFcgEmDuoJVt
O2zYEwNoizTFjL5r+jKF3w1O9vH9WxmqB54I57kb1k2TXDOtprNR1p31UplN
QWbV8U6D8FQOcIEVaEak/BNpGtCOL2K15I5X/lHY/wdp/mfS5P8g6Y+VfUXJ
IQQPHPTb4b4qEiXs2AbS1OLukgD8sohuNcJBC3ojKSPkKDViL9R3QF9oDfGD
Vzuir0zvikef0DJS+gTYuknjlX8pG43/pfWfT7v85waJvs94IdEPZ3X/v72j
2W3bBt8L9B2IALsEcUqRki05c9Fi2LB2a7I169JDgUKxKFv+oRxSspqctp4H
7F2G9bjtFZI3Gj9RdiXZlpN2tZNVbFLHlCjJ9Pf/+x+29nu2wtS4DvXvQBu/
Dx5SKVSu+LQtgNfq/9RckP9Jjf+3BP+XN2AhVQY2ahLp+eFqs33eVlBh/Seg
jZNBfx4ITpu2Q01IIFUKogMxw5TkCMOcuMyhmtAQTzxn6vLRGU24GHGWhP7A
lU4cLMomFKvP+/WbSSBYapTYwFjtmijuMJQQRwdMP1uH2Jg4LctpNimxDesj
zJh6p0a9beJ/U+d/ENLEoCim8n9t/9us/8/CFB0zMQ26DL3g7tQNRu7piH0Q
+l9cvPEC6Ngtk8Xyh2rptanCQlxVRhaYK72BzwbJ3EBA0mxRm5qtFqHYhEQC
I5//WSQMCtx56EqGQx+STfqcnIV+6MIb4rLEh2sJ6EoSifPGYz9iQt3CdCgm
NrXVTsErvIX7OLaSc05cwdPgXcNWtw2nTESxYGjnCUc/iLCnUFbu3E5fg/Qm
W8//blkL8T+E1vr/7bL/p0a+14tKwOraCeXY0GuUBKosBqRBNTMNQnCQp8iA
d//e426XTaIsjp+Hp6F3Prft3cApYFjVOWGFog63pQfQRzsCJBsHW67/ha1W
Tv5vZvX/mjX+b2KU878P1IfsxF+YOIecNycKK1E9FD0dDUCJSariAWZwudQf
YL/n7DPkL6HgXmFiMuzKVmMcjNkeiNF6lNKU9nITMuhxNZM7VzFwt8fUAXXl
3BtfuL0qknL789EjJj91+6/19r98/ReN/6RV+/82zf+VZMwfKdU4HAdZesMR
UohVntW4LdzRpF9E+mfuy4Z/JE7c596xgnDczDv4UjgrIHPe1Pfy/OLivEHU
aYpnI/WjBH/E4/EpE2olRzpCQJ9F23Nenk4UFHX1FMzVorgfhuhUfbXqa4On
DkN4I9KXJUzdvi5Pj3Sf1E6auHH37X8RJCBCJq7cYv2HZquE/5ZV2/+3w/8/
rP7vR1X+RTkYHAaDvukOPe6eDYYJ4550pQ+MfwWfv1ZN4PVl4EqLjr/6Sa0i
VatGrhx4fb9sH/n+GEW0Yh1xbBxzDz5R8TEPvzs8OjlEkVmxWKk72KeMLzHK
VLo/sOsEns8ZWyJ6RCKR2+b/Fi7jv0lxjf8bx3/BxmHEGmo/esuFfoQq+7Gv
gHhQ1bGT9wWsvFHR/DcKFUlpCCbDWHTZMsLimMTBdr7aQQrPYdCNqelYNoQQ
Mx8iiPsCGpqLtYSEUNvJBxcv72Xy/4kYjvlQdseflgKslf9NWsb/Zo3/m8X/
kt1Mx8S1ozCCpnk6NK6rAX8T2QAZVPI6G2AT+D8mW8Z/Ssr4b5Fa/78l/n/A
8kCe8raSXWnLIXaLzrl0P4ogYShJkv1lYr9CzDJWp7CWqv/980mfcTdiXqNc
xvE9MzYdnHfwL3Lj1QUnjOtEAn4JzcHaT8M+f308DqL+w8+tWmTMt57/a2Cj
7P+zDFrXf9vImEn2BGPUQWR3l6JdZO3uEnT51+Xf6OrXq7fq5fLPy3eXf1z9
DnOlqau3V7+hBrr85+qX2bHLd1U2cccu4aRBiemQIqHIgBKaAQ2B6Q/pgDCR
MM+Xj48rUolXBiMahm43skJqYV6sXZAEwhMWXX7XSwlaFsbj2AsZxjdLE3Ls
lXlCcOj2tRSsxx0aiQz4dLvxH0bLMsrxH0oArOn/hv0/02DKhr1H3b4biIbH
RbegNGXdvtPe3Dnh8Ai1799bvxwdIIQUgQVnakcRMMOGf5Ty+/d8AZ1GUBvt
PEXPQ8n4KRM99OrVq52dzPuqs009AQcfLcREwn9w5Q6CIl8Dz17jidIQv8QJ
VaT66SOlsR5dmVaewdiBW+XiSLK20gg9UCen24GA1Wm38VwOnXE76mCZiZ8S
Nu2QJd+4vDdi3rfM9SDEDCHOEl/PoayXLgKtO+Cxmlk8mLWq1+tPlPj6gscy
dkc/w+E2OjjY21O/B2t5l664qm6W7rTUYYCy8PWPxAwCEnWfjm42P+sAz0Pd
qf1h2oZ9tiepwfABAh0chpwEwO4KUJF9fXqHADIQyoQCJxgObITABz/fYn1F
9SfIE+kGG017n1jWvuLucK3sQh21aBaJDBF6igO2d36MQ6VqIBmJgCvw2gHw
WglY6lJqtzWsd2ZhAGom/ZT6mSXYQzx9ygE6U8+O9ym9MXtfWQPI3Axrv2AK
/fwt6/8EL9r/av3/Dvn/qix9vb70TCNHgDOQG4Apb+TzMQnJyKTCirE29xVM
e5QYFZ69a/V4AitCULYd4Lr0Rz3qUY/PfPwLcaRGXQDwAAA=
-- END MESSAGE ARCHIVE --

Authors' Addresses ✨

Robert J. Sparks (editor) 💅 Estacado Systems

EMail: RjS@estacado.net

Alan Hawrylyshen 🦋 Ditech Networks 200 - 1167 Kensington Cr. NW Calgary, Alberta T2N 1X7 Canada

Phone : +1.403.806.3366 EMail : ahawrylyshen@ditechcom.com

Alan Johnston 🌸 Avaya St. Louis, MO 63124

EMail: alan@sipstation.com

Jonathan Rosenberg 👑 Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07052

Phone: +1 973 952 5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net

Henning Schulzrinne 🧚 Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US

Phone: +1 212 939 7042 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu

Full Copyright Statement ✨

Okay bestie, the legal stuff, but make it cute 🎀. Copyright is held by The Internet Society (2006) 💖.

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 🔒.

This document and the information in it are provided on an "AS IS" basis 🫶. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED 💅. That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 😭. So yeah, no promises, no cap.

Intellectual Property 🦋

The IETF takes no position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach 🤷‍♀️. It also doesn't say whether a license under those rights is available or not, and it hasn't independently tried to find any of them 🙈. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 📚.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses that might be made available, are findable in the IETF on-line IPR repository at http://www.ietf.org/ipr 🌈. The same goes for the result of any attempt to get a general license or permission to use those proprietary rights, whether that's for implementers or for users of this specification 💜.

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard 👑. Send that info to the IETF at ietf-ipr@ietf.org ✨. Bestie, this is the part where you speak up if you spot something 💅.

Acknowledgement 🌸

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶. Thank you, IASA, for keeping the lights on for the RFC Editor! 🧚

📦 where this page comes from

ietf: rfc4475 2006-05
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms