summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4475.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4475.txt')
-rw-r--r--doc/rfc/rfc4475.txt2971
1 files changed, 2971 insertions, 0 deletions
diff --git a/doc/rfc/rfc4475.txt b/doc/rfc/rfc4475.txt
new file mode 100644
index 0000000..3c4e6e5
--- /dev/null
+++ b/doc/rfc/rfc4475.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group R. Sparks, Ed.
+Request for Comments: 4475 Estacado Systems
+Category: Informational A. Hawrylyshen
+ Ditech Networks
+ A. Johnston
+ Avaya
+ J. Rosenberg
+ Cisco Systems
+ H. Schulzrinne
+ Columbia University
+ May 2006
+
+
+ Session Initiation Protocol (SIP) Torture Test Messages
+
+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
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This informational document gives examples of Session Initiation
+ Protocol (SIP) test messages designed to exercise and "torture" a SIP
+ implementation.
+
+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
+
+
+
+Sparks, et al. Informational [Page 1]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+
+
+Sparks, et al. Informational [Page 2]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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.
+
+ 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
+
+
+
+Sparks, et al. Informational [Page 3]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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.
+
+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.
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 4]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+ This short, relatively human-readable message contains:
+
+ o line folding all over.
+
+ o escaped characters within quotes.
+
+ o an empty subject.
+
+ o LWS between colons, semicolons, header field values, and other
+ fields.
+
+ o both comma separated and separately listed header field values.
+
+
+
+Sparks, et al. Informational [Page 5]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ o a mix of short and long form for the same header field name.
+
+ o unknown Request-URI parameter.
+
+ o unknown header fields.
+
+ o an unknown header field with a value that would be syntactically
+ invalid if it were defined in terms of generic-param.
+
+ o unusual header field ordering.
+
+ o unusual header field name character case.
+
+ o unknown parameters of a known header field.
+
+ o a uri parameter with no value.
+
+ o a header parameter with no value.
+
+ o 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 (as would many
+ of the existing defined header fields), this would be invalid.
+ However, since the receiving element does not know the definition of
+ the syntax for this field, it must parse it as a header value.
+ Proxies would forward this header field unchanged. Endpoints would
+ ignore the header field.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 6]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 7]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+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. In particular,
+ note the following:
+
+ o 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. It is not the same as a method of INVITE.
+
+ o The Request-URI contains unusual, but legal, characters.
+
+ o A branch parameter contains all non-alphanum characters from
+ token.
+
+ o The To header field value's quoted string contains quoted-pair
+ expansions, including a quoted NULL character.
+
+ o 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.
+
+ o The Call-ID header field value contains the non-alphanum
+ characters from word. Notice that in this production:
+
+ * % is not an escape character. It is 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.
+
+ o 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.
+
+
+
+
+
+Sparks, et al. Informational [Page 8]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 exercises the % HEX HEX escaping mechanism in several
+ places. The request is syntactically valid. Interesting features
+ include the following:
+
+ o 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.
+
+ o The From and To URIs have escaped characters in their userparts.
+
+ o 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.
+
+
+
+
+
+
+Sparks, et al. Informational [Page 9]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 10]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.1.4. Escaped Nulls in URIs
+
+ This register request contains several URIs with nulls in the
+ userpart. The message is well formed - 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:
+
+ o The request method is unknown. It is NOT equivalent to REGISTER.
+
+ o The display name portion of the To and From header fields is
+ "%Z%45". Note that this is not the same as %ZE.
+
+ o 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 11]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 is not 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
+
+ This well-formed request contains header fields with many values and
+ values that are very long. Features include the following:
+
+ o The To header field has a long display name, and long uri
+ parameter names and values.
+
+ o The From header field has long header parameter names and values,
+ in particular, a very long tag.
+
+ o The Call-ID is one long token.
+
+
+
+
+
+
+Sparks, et al. Informational [Page 12]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+
+
+Sparks, et al. Informational [Page 13]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 contains a single SIP REGISTER request, which ostensibly
+ arrived over UDP in a single datagram. The packet contains extra
+ octets after the body (which in this case has zero length). The
+ 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.
+
+ 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.
+
+
+
+Sparks, et al. Informational [Page 14]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 15]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.1.9. Semicolon-Separated Parameters in URI User Part
+
+ This request has a semicolon-separated parameter contained in the
+ "user" part of the Request-URI (whose value contains an escaped @
+ symbol). Receiving elements will accept this as a well-formed
+ message. The Request-URI will parse 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 contains Via header field values with all known
+ transport types and exercises the transport extension mechanism.
+ Parsers must accept this message as well formed. Elements receiving
+ this message 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
+
+
+
+
+
+
+Sparks, et al. Informational [Page 16]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.1.11. Multipart MIME Message
+
+ This MESSAGE request contains two body parts. The second part is
+ binary encoded and contains null (0x00) characters. Receivers must
+ take care to frame the received message properly.
+
+ 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
+
+
+
+
+Sparks, et al. Informational [Page 17]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ <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 contains a reason phrase other than "OK". The
+ reason phrase is intended for human consumption and 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. This response is well formed. A parser must accept this
+ message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 18]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 contains no reason phrase. 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>
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 19]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2. Invalid Messages
+
+ This section contains several invalid messages reflecting errors seen
+ at interoperability events and exploring important edge conditions
+ that can be induced through malformed messages. This section does
+ not attempt to be a comprehensive list of all types of invalid
+ messages.
+
+3.1.2.1. Extraneous Header Field Separators
+
+ The Via header field of this request contains additional semicolons
+ and commas without parameters or values. The Contact header field
+ contains additional semicolons without parameters. This message is
+ syntactically invalid.
+
+ An element receiving 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 message with a Content Length that is larger than
+ the actual length of the body.
+
+ When sent over UDP (as this message ostensibly was), the receiving
+ element should respond with a 400 Bad Request error. If this message
+ arrived over a stream-based transport, such as TCP, there's not much
+
+
+
+Sparks, et al. Informational [Page 20]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ the receiving party could do but wait for more data on the stream and
+ close the connection if none is forthcoming within a reasonable
+ period of time.
+
+ 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.
+
+ An element receiving this message should respond with an error. This
+ request appeared over UDP, so the remainder of the datagram can
+ simply be discarded. If a request like this arrives over TCP, the
+ framing error is not recoverable, and the connection should be
+ closed. The same behavior is appropriate for messages that arrive
+ without a numeric value in the Content-Length header field, such as
+ the following:
+
+ Content-Length: five
+
+ Implementors should take extra precautions if the technique they
+ choose for converting this ascii field into an integral form can
+ return a negative value. In particular, the result must not be used
+ as a counter or array index.
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 21]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 contains several scalar header field values outside
+ their legal range.
+
+ o The CSeq sequence number is >2**32-1.
+
+ o The Max-Forwards value is >255.
+
+ o The Expires value is >2**32-1.
+
+ o The Contact expires parameter value is >2**32-1.
+
+ An element receiving this request should respond with a 400 Bad
+ Request due to the CSeq error. If only the Max-Forwards field were
+ in error, the element could choose to process the request as if the
+ field were absent. If only the expiry values were in error, the
+ element could treat them as if they contained the default values for
+ expiration (3600 in this case).
+
+ Other scalar request fields that may contain aberrant values include,
+ but are not limited to, the Contact q value, the Timestamp value, and
+ the Via ttl parameter.
+
+
+
+
+
+
+Sparks, et al. Informational [Page 22]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 contains several scalar header field values outside
+ their legal range.
+
+ o The CSeq sequence number is >2**32-1.
+
+ o The Retry-After field is unreasonably large (note that RFC 3261
+ does not define a legal range for this field).
+
+ o The Warning field has a warning-value with more than 3 digits.
+
+ An element receiving this response will simply discard it.
+
+ 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
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 23]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+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. An element receiving this request should return a 400
+ Bad Request error.
+
+ An element could attempt to infer a terminating quote and accept the
+ message. Such an element needs to take care that it makes a
+ reasonable inference when it encounters
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 24]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.7. <> Enclosing Request-URI
+
+ This INVITE request is invalid because the Request-URI has been
+ enclosed within in "<>".
+
+ It is reasonable always to reject a request with this error with a
+ 400 Bad Request. Elements attempting to be liberal with what they
+ accept may choose to ignore the brackets. If the element forwards
+ the request, it must not include the brackets in the messages it
+ sends.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 25]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.8. Malformed SIP Request-URI (embedded LWS)
+
+ This INVITE has illegal LWS within the Request-URI.
+
+ An element receiving this request should respond with a 400 Bad
+ Request.
+
+ An element could attempt to ignore the embedded LWS for those schemes
+ (like SIP) where doing so would not introduce 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 26]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.9. Multiple SP Separating Request-Line Elements
+
+ This INVITE has illegal multiple SP characters between elements of
+ the start line.
+
+ It is acceptable to reject this request as malformed. An element
+ that is liberal in what it accepts may ignore these extra SP
+ characters when processing the request. If the element forwards the
+ request, it must not include these extra SP characters in the
+ messages it sends.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 27]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.10. SP Characters at End of Request-Line
+
+ This OPTIONS request contains SP characters between the SIP-Version
+ field and the CRLF terminating the Request-Line.
+
+ It is acceptable to reject this request as malformed. An element
+ that is liberal in what it accepts may ignore these extra SP
+ characters when processing the request. If the element forwards the
+ request, it must not include these extra SP characters in the
+ messages it sends.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 28]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.11. Escaped Headers in SIP Request-URI
+
+ This INVITE is malformed, as the SIP Request-URI contains escaped
+ headers.
+
+ It is acceptable for an element to reject this request with a 400 Bad
+ Request. An element could choose to be liberal in what it accepts
+ and ignore the escaped headers. If the element is a proxy, the
+ escaped headers must not appear in the Request-URI of the forwarded
+ request (and most certainly must not be translated into the actual
+ header of the forwarded request).
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 29]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.12. Invalid Time Zone in Date Header Field
+
+ This INVITE is invalid, as it contains a non-GMT time zone in the SIP
+ Date header field.
+
+ It is acceptable to reject this request as malformed (though an
+ element shouldn't do that unless the contents of the Date header
+ field were actually important to its processing). An element wishing
+ to be liberal in what it accepts could ignore this value altogether
+ if it wasn't going to use the Date header field anyway. Otherwise,
+ it could attempt to interpret this date and adjust it to GMT.
+
+ RFC 3261 explicitly defines the only acceptable time zone designation
+ as "GMT". "UT", while synonymous with GMT per [RFC2822], is not
+ valid. "UTC" and "UCT" are also invalid.
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 30]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.13. Failure to Enclose name-addr URI in <>
+
+ This REGISTER request is malformed. The SIP URI contained in the
+ Contact Header field has an escaped header, so the field must be in
+ name-addr form (which implies that the URI must be enclosed in <>).
+
+ It is reasonable for an element receiving this request to respond
+ with a 400 Bad Request. An element choosing to be liberal in what it
+ accepts could infer the angle brackets since there is no ambiguity in
+ this example. 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, since the addr-spec in the To header field
+ contains spaces. Parsers receiving this request must not break. It
+ is reasonable to reject this request with a 400 Bad Request response.
+ Elements attempting to be liberal may 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
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 31]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.15. Non-token Characters in Display Name
+
+ This OPTIONS request is malformed, since the display names in the To
+ and From header fields contain non-token characters but are unquoted.
+
+ It is reasonable always to reject this kind of error with a 400 Bad
+ Request response.
+
+ An element may attempt to be liberal in what it receives and infer
+ the missing quotes. If this element were a proxy, it must not
+ propagate the error into the request it forwards. As a consequence,
+ if the fields are covered by a signature, there's not much point in
+ trying to be liberal - the message should simply be 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 implementing [RFC3261], this request is malformed due
+ to its high version number.
+
+ The element should respond to the request 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
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 32]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.17. Start Line and CSeq Method Mismatch
+
+ This request has mismatching values for the method in the start line
+ and the CSeq header field. Any element receiving this request 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 a CSeq
+ method tag that does not match.
+
+ Any element receiving this response should respond with a 501 Not
+ Implemented. A 400 Bad Request is also acceptable, but choosing a
+ 501 (particularly 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
+
+
+
+
+
+Sparks, et al. Informational [Page 33]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.1.2.19. Overlarge Response Code
+
+ This response has a response code larger than 699. An element
+ receiving this response should simply drop it.
+
+ 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 contains tests that exercise an implementation's parser
+ and transaction-layer logic.
+
+3.2.1. Missing Transaction Identifier
+
+ This request indicates support for RFC 3261-style transaction
+ identifiers by providing the z9hG4bK prefix to the branch parameter,
+ but it provides no identifier. A parser must not break when
+ receiving this message. An element receiving this request could
+ reject the request with a 400 Response (preferably statelessly, as
+ other requests from the source are likely also to have a malformed
+ branch parameter), 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
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 34]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3. Application-Layer Semantics
+
+ This section contains tests that exercise an implementation's parser
+ and application-layer logic.
+
+3.3.1. Missing Required Header Fields
+
+ This request contains no Call-ID, From, or To header fields.
+
+ An element receiving this message must not break because of the
+ missing information. Ideally, it will 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 35]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3.2. Request-URI with Unknown Scheme
+
+ This OPTIONS contains an unknown URI scheme in the Request-URI. A
+ parser must accept this as a well-formed SIP request.
+
+ An element receiving this request will reject it with a 416
+ Unsupported URI Scheme response.
+
+ Some early implementations attempt to look at the contents of the To
+ header field to determine how to route this kind of request. That is
+ an error. Despite the fact that the To header field and the Request
+ URI frequently look alike in simplistic first-hop messages, the To
+ header field contains no routing information.
+
+ 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 contains an Request-URI with an IANA-registered scheme
+ that does not commonly appear 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 is 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
+ those 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
+
+
+
+
+Sparks, et al. Informational [Page 36]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3.4. Unknown URI Schemes in Header Fields
+
+ This message contains registered schemes in the To, From, and Contact
+ header fields of a request. The message is syntactically valid.
+ Parsers must not fail when receiving this message.
+
+ Proxies should treat this message as they would any other request for
+ this URI. A registrar would reject this request 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 tests proper implementation of SIP's Proxy-Require and
+ Require extension mechanisms.
+
+ Any element receiving this request will respond with a 420 Bad
+ Extension response, containing an Unsupported header field listing
+ these features from either the Require or Proxy-Require header field,
+ depending on the role in which the element is responding.
+
+ 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
+
+
+
+
+
+
+Sparks, et al. Informational [Page 37]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3.6. Unknown Content-Type
+
+ This INVITE request contains a body of unknown type. It is
+ syntactically valid. A parser must not fail when receiving it.
+
+ A proxy receiving this request would process it just as it would any
+ other INVITE. An endpoint receiving this request would 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 request contains an Authorization header field with an
+ unknown scheme. The request is well formed. A parser must not fail
+ when receiving it.
+
+ A proxy will treat this request as it would any other REGISTER. If
+ it forwards the request, it will include this Authorization header
+ field unmodified in the forwarded messages.
+
+ A registrar that does not care about challenge-response
+ authentication will simply ignore the Authorization header field,
+ processing this registration as if the field were not present. A
+ registrar that does care about challenge-response authentication will
+ reject this request with a 401, issuing a new challenge with a scheme
+ it understands.
+
+ Endpoints choosing not to act as registrars will simply reject the
+ request. A 405 Method Not Allowed is appropriate.
+
+
+
+
+
+
+Sparks, et al. Informational [Page 38]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+ The message contains a request with multiple Call-ID, To, From, Max-
+ Forwards, and CSeq values. An element receiving this request must
+ not break.
+
+ An element receiving this request 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
+
+
+
+Sparks, et al. Informational [Page 39]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3.9. Multiple Content-Length Values
+
+ Multiple conflicting Content-Length header field values appear in
+ this request.
+
+ From a framing perspective, this situation is equivalent to an
+ invalid Content-Length value (or no value at all).
+
+ An element receiving this message should respond with an error. This
+ request appeared over UDP, so the remainder of the datagram can
+ simply be discarded. If a request like this arrives over TCP, the
+ framing error is not recoverable, 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 with a 2nd Via header field value's sent-
+ by containing 255.255.255.255. The message is well formed; parsers
+ must not fail when receiving it.
+
+ Per [RFC3261], an endpoint receiving this message should simply
+ discard it.
+
+ If a proxy followed normal response processing rules blindly, it
+ would forward this response to the broadcast address. To protect
+ against this as an avenue of attack, proxies should drop such
+ responses.
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 40]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 legal SIP request with the Max-Forwards header field value
+ set to zero.
+
+ A proxy should not forward the request and should respond 483 (Too
+ Many Hops). 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
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 41]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3.12. REGISTER with a Contact Header Parameter
+
+ This register request contains a contact where the 'unknownparam'
+ parameter must be interpreted as a contact-param and not a url-param.
+
+ This REGISTER should succeed. The response must not include
+ "unknownparam" as a url-parameter for this binding. Likewise,
+ "unknownparam" must not appear as a url-parameter in any binding
+ during subsequent fetches.
+
+ Behavior is the same, of course, for any known contact-param
+ parameter names.
+
+ 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 request contains a contact where the URI has an unknown
+ parameter.
+
+ The register should succeed, and a subsequent retrieval of the
+ registration must include "unknownparam" as a url-parameter.
+
+ Behavior is the same, of course, for any known url-parameter names.
+
+ 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
+
+
+
+
+
+Sparks, et al. Informational [Page 42]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3.14. REGISTER with a URL Escaped Header
+
+ This register request contains a contact where the URI has an escaped
+ header.
+
+ The register should succeed, and a subsequent 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 43]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+3.3.15. Unacceptable Accept Offering
+
+ This request indicates that the response must contain a body in an
+ unknown type. In particular, since the Accept header field does not
+ contain application/sdp, the response may not contain an SDP body.
+ The recipient of this request could respond with a 406 Not
+ Acceptable, with a Warning/399 indicating that a response cannot be
+ formulated in the formats offered in the Accept header field. It is
+ also appropriate to respond with a 400 Bad Request, since all SIP
+ User-Agents (UAs) supporting 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
+
+ This is a legal message per RFC 2543 (and several bis versions) that
+ should be accepted by RFC 3261 elements that want to maintain
+ backwards compatibility.
+
+ o There is no branch parameter at all on the Via header field value.
+
+ o There is no From tag.
+
+
+
+
+
+Sparks, et al. Informational [Page 44]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ o There is no explicit Content-Length. (The body is assumed to be
+ all octets in the datagram after the null-line.)
+
+ o 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
+
+ This document presents NON-NORMATIVE examples of SIP session
+ establishment. The security considerations in [RFC3261] apply.
+
+ Parsers must carefully consider edge conditions and malicious input
+ as part of their design. Attacks on many Internet systems use
+ crafted input to cause implementations to behave in undesirable ways.
+ Many of the messages in this document are designed to stress a parser
+ implementation at points traditionally used for such attacks.
+ However, this document does not attempt to be comprehensive. It
+ should be considered a seed to stimulate thinking and planning, not
+ simply a set of tests to be passed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 45]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+5. Acknowledgements
+
+ The final detailed review of this document was performed 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 of this document 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 contribution to
+ the multipart/mime sections of this document and their work
+ constructing S/MIME examples in [SIP-SEC]. Thanks to Neil Deason for
+ contributing several messages and to Kundan Singh for performing
+ parser validation of messages in earlier versions.
+
+ The following individuals provided significant comments during the
+ early phases of the development 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.
+
+
+
+Sparks, et al. Informational [Page 46]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+Appendix A. Bit-Exact Archive of Each Test Message
+
+ The following text block is an encoded, gzip-compressed TAR archive
+ of files that represent each of the example messages discussed in
+ Section 3.
+
+ To recover the compressed archive file intact, the text of this
+ document may be passed as input to the following Perl script (the
+ output should be redirected to a file or piped 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
+
+ Alternatively, the base-64 encoded block can be edited by hand to
+ remove document structure lines and fed as input to any base-64
+ decoding utility.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 47]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+A.1. Encoded Reference Messages
+
+ -- 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
+
+
+
+Sparks, et al. Informational [Page 48]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+
+
+
+Sparks, et al. Informational [Page 49]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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
+ ZFj0ZPEgL7WDgllgxoc9w/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/
+
+
+
+Sparks, et al. Informational [Page 50]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+ 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 --
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 51]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+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
+
+
+
+
+
+
+Sparks, et al. Informational [Page 52]
+
+RFC 4475 SIP Torture Test Messages May 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) 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 contained herein are provided on an
+ "AS IS" basis and 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,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sparks, et al. Informational [Page 53]
+