idnits 2.17.1 draft-ietf-sipping-torture-tests-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2182. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2195. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2211), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 46 longer pages, the longest (page 5) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 52 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1297 has weird spacing: '...d since the d...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2004) is 7219 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Sparks, Ed. 2 Internet-Draft dynamicsoft 3 Expires: January 12, 2005 A. Hawrylyshen 4 Jasomi Networks 5 A. Johnston 6 MCI 7 J. Rosenberg 8 dynamicsoft 9 H. Schulzrinne 10 Columbia University 11 July 14, 2004 13 Session Initiation Protocol Torture Test Messages 14 draft-ietf-sipping-torture-tests-04 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 12, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 This informational document gives examples of Session Initiation 48 Protocol (SIP) test messages designed to exercise and "torture" a SIP 49 implementation. 51 Table of Contents 53 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Representing Long Lines . . . . . . . . . . . . . . . . . 4 56 2.2 Representing Non-printable Characters . . . . . . . . . . 5 57 2.3 Representing Long Repeating Strings . . . . . . . . . . . 5 58 3. SIP Test Messages . . . . . . . . . . . . . . . . . . . . . 6 59 3.1 Parser tests (syntax) . . . . . . . . . . . . . . . . . . 6 60 3.1.1 Valid messages . . . . . . . . . . . . . . . . . . . . 6 61 3.1.1.1 A short tortuous INVITE . . . . . . . . . . . . . 6 62 3.1.1.2 Wide range of valid characters . . . . . . . . . . 8 63 3.1.1.3 Valid use of the % escaping mechanism . . . . . . 9 64 3.1.1.4 Escaped nulls in URIs . . . . . . . . . . . . . . 10 65 3.1.1.5 Use of % when it is not an escape . . . . . . . . 11 66 3.1.1.6 Message with no LWS between display name and < . . 11 67 3.1.1.7 Long values in header fields . . . . . . . . . . . 12 68 3.1.1.8 Extra trailing octets in a UDP datagram . . . . . 14 69 3.1.1.9 Semicolon separated parameters in URI user part . 15 70 3.1.1.10 Varied and unknown transport types . . . . . . . 16 71 3.1.1.11 S/MIME signed message . . . . . . . . . . . . . 16 72 3.1.1.12 Unusual reason phrase . . . . . . . . . . . . . 19 73 3.1.1.13 Empty reason phrase . . . . . . . . . . . . . . 20 74 3.1.2 Invalid messages . . . . . . . . . . . . . . . . . . . 21 75 3.1.2.1 Extraneous header field separators . . . . . . . . 21 76 3.1.2.2 Content length larger than message . . . . . . . . 21 77 3.1.2.3 Negative Content-Length . . . . . . . . . . . . . 22 78 3.1.2.4 Request scalar fields with overlarge values . . . 23 79 3.1.2.5 Response scalar fields with overlarge values . . . 24 80 3.1.2.6 Unterminated quoted string in display-name . . . . 24 81 3.1.2.7 <> enclosing Request-URI . . . . . . . . . . . . . 25 82 3.1.2.8 Malformed SIP Request-URI (embedded LWS) . . . . . 26 83 3.1.2.9 Multiple SP separating Request-Line elements . . . 27 84 3.1.2.10 SP characters at end of Request-Line . . . . . . 28 85 3.1.2.11 Escaped headers in SIP Request-URI . . . . . . . 29 86 3.1.2.12 Invalid timezone in Date header field . . . . . 29 87 3.1.2.13 Failure to enclose name-addr URI in <> . . . . . 30 88 3.1.2.14 Spaces within addr-spec . . . . . . . . . . . . 31 89 3.1.2.15 Non-token characters in display-name . . . . . . 31 90 3.1.2.16 Unknown protocol version . . . . . . . . . . . . 32 91 3.1.2.17 Start line and CSeq method mismatch . . . . . . 32 92 3.1.2.18 Unknown Method with CSeq method mismatch . . . . 32 93 3.1.2.19 Overlarge response code . . . . . . . . . . . . 33 94 3.2 Transaction layer semantics . . . . . . . . . . . . . . . 33 95 3.2.1 Missing transaction identifier . . . . . . . . . . . . 34 96 3.3 Application layer semantics . . . . . . . . . . . . . . . 34 97 3.3.1 Missing Required Header Fields . . . . . . . . . . . . 34 98 3.3.2 Request-URI with unknown scheme . . . . . . . . . . . 35 99 3.3.3 Request-URI with known but atypical scheme . . . . . . 35 100 3.3.4 Unknown URI schemes in header fields . . . . . . . . . 36 101 3.3.5 Proxy-Require and Require . . . . . . . . . . . . . . 37 102 3.3.6 Unknown Content-Type . . . . . . . . . . . . . . . . . 37 103 3.3.7 Unknown authorization scheme . . . . . . . . . . . . . 38 104 3.3.8 Multiple values in single value required fields . . . 38 105 3.3.9 Multiple Content-Length values . . . . . . . . . . . . 39 106 3.3.10 200 OK Response with broadcast Via header field 107 value . . . . . . . . . . . . . . . . . . . . . . . 40 108 3.3.11 Max-Forwards of zero . . . . . . . . . . . . . . . . 41 109 3.3.12 REGISTER with a contact header parameter . . . . . . 41 110 3.3.13 REGISTER with a url parameter . . . . . . . . . . . 42 111 3.3.14 REGISTER with a url escaped header . . . . . . . . . 43 112 3.3.15 Unacceptable Accept offering . . . . . . . . . . . . 43 113 3.4 Backward compatibility . . . . . . . . . . . . . . . . . . 44 114 3.4.1 INVITE with RFC2543 syntax . . . . . . . . . . . . . . 44 115 4. Security Considerations . . . . . . . . . . . . . . . . . . 45 116 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 117 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 45 118 7. Informative References . . . . . . . . . . . . . . . . . . . 46 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 120 A. Bit-exact archive of each test message . . . . . . . . . . . 47 121 A.1 Encoded Reference Messages . . . . . . . . . . . . . . . . 48 122 Intellectual Property and Copyright Statements . . . . . . . 52 124 1. Overview 126 This document is informational, and is NOT NORMATIVE on any aspect of 127 SIP. 129 This document contains test messages based on the current version 130 (2.0) of the Session Initiation Protocol as defined in [RFC3261]. 131 Some messages exercise SIP's use of SDP as described in [RFC3264]. 133 These messages were developed and refined at the SIPIt 134 interoperability test events. 136 The test messages are organized into several sections. Some stress 137 only a SIP parser and others stress both the parser and the 138 application above it. Some messages are valid, and some are not. 139 Each example clearly calls out what makes any invalid messages 140 incorrect. 142 This document does not attempt to catalog every way to make an 143 invalid message, nor does it attempt to be comprehensive in exploring 144 unusual, but valid, messages. Instead, it tries to focus on areas 145 that have caused interoperability problems or have particularly 146 unfavorable characteristics if they are handled improperly. This 147 document is a seed for a test plan, not a test plan in itself. 149 The messages are presented in the text using a set of markup 150 conventions to avoid ambiguity and meet Internet-Draft layout 151 requirements. To resolve any remaining ambiguity, a bit-accurate 152 version of each message is encapsulated in an appendix. 154 2. Document Conventions 156 This document contains many example SIP messages. Although SIP is a 157 text-based protocol, many of these examples cannot be unambiguously 158 rendered without additional markup due to the constraints placed on 159 the formatting of RFCs. This document defines and uses the markup 160 defined in this section to remove that ambiguity. This markup uses 161 the start and end tag conventions of XML, but does not define any XML 162 document type. 164 The appendix contains an encoded binary form of all the messages and 165 the algorithm needed to decode them into files. 167 2.1 Representing Long Lines 169 Several of these examples contain unfolded lines longer than 72 170 characters. These are captured between tags. The 171 single unfolded line is reconstructed by directly concatenating all 172 lines appearing between the tags (discarding any line-feeds or 173 carriage returns). There will be no whitespace at the end of lines. 174 Any whitespace appearing at a fold-point will appear at the beginning 175 of a line. 177 The following represent the same string of bits: 179 Header-name: first value, reallylongsecondvalue, third value 181 182 Header-name: first value, 183 reallylongsecondvalue 184 , third value 185 187 188 Header-name: first value, 189 reallylong 190 second 191 value, 192 third value 193 195 Note that this is NOT SIP header line folding where different 196 strings of bits have equivalent meaning. 198 2.2 Representing Non-printable Characters 200 Several examples contain binary message bodies or header field values 201 containing non-ascii range UTF-8 encoded characters. These are 202 rendered here as a pair of hexadecimal digits per octet between tags. This rendering applies even inside quoted-strings. 205 The following represent the same string of bits: 207 Header-name: value one 209 Header-name: value206F6Ee 211 The following is a Subject header field containing the euro symbol: 213 Subject: E282AC 215 2.3 Representing Long Repeating Strings 217 Several examples contain very large data values created with 218 repeating bit strings. Those will be rendered here using value. As with this rendering 220 applies even inside quoted-strings. 222 For example, the value "abcabcabc" can be rendered as abc. A display name of "1000000 bottles of beer" 224 could be rendered as 226 To: "130 bottles of beer" 227 229 and a Max-Forwards header field with a value of one google will be 230 rendered here as 232 Max-Forwards: 10 234 3. SIP Test Messages 236 3.1 Parser tests (syntax) 238 3.1.1 Valid messages 240 3.1.1.1 A short tortuous INVITE 242 This short, relatively human-readable message contains: 243 o line folding all over 244 o escaped characters within quotes 245 o an empty subject 246 o LWS between colons, semicolons, header field values, and other 247 fields 248 o both comma separated and separate listing of header field values 249 o mix or short and long form for the same header field name 250 o unknown header fields 251 o unknown header field with a value that would be syntactically 252 invalid if it were defined in terms of generic-param 253 o unusual header field ordering 254 o unusual header field name character case 255 o unknown parameters of a known header field 256 o uri parameter with no value 257 o header parameter with no value 258 o integer fields (Max-Forwards and CSeq) with leading zeros 259 All elements should treat this as a well-formed request. 261 The UnknownHeaderWithUnusualValue header field deserves special 262 attention. If this header field were defined in terms of comma 263 separated values with semicolon separated parameters (as many of the 264 existing defined header fields), this would be invalid. However, 265 since the receiving element does not know the definition of the 266 syntax for this field, it must parse it as a header-value. Proxies 267 would forward this header field unchanged. Endpoints would ignore 268 the header field. 270 Message Details : wsinv 272 INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 273 TO : 274 sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n 275 from : "J Rosenberg \\\"" 276 ; 277 tag = 98asjd8 278 MaX-fOrWaRdS: 0068 279 Call-ID: wsinv.ndaksdj@192.0.2.1 280 Content-Length : 151 281 cseq: 0009 282 INVITE 283 Via : SIP / 2.0 284 /UDP 285 192.0.2.2;branch=390skdjuw 286 s : 287 NewFangledHeader: newfangled value 288 continued newfangled value 289 UnknownHeaderWithUnusualValue: ;;,,;;,; 290 Content-Type: application/sdp 291 Route: 292 293 v: SIP / 2.0 / TCP spindle.example.com ; 294 branch = z9hG4bK9ikj8 , 295 SIP / 2.0 / UDP 192.168.255.111 ; branch= 296 z9hG4bK30239 297 m:"Quoted string \"\"" ; newparam = 298 newvalue ; 299 secondparam ; q = 0.33 301 v=0 302 o=mhandley 29739 7272939 IN IP4 192.0.2.3 303 s=- 304 c=IN IP4 192.0.2.4 305 t=0 0 306 m=audio 492170 RTP/AVP 0 12 307 m=video 3227 RTP/AVP 31 308 a=rtpmap:31 LPC 310 3.1.1.2 Wide range of valid characters 312 This message exercises a wider range of characters in several key 313 syntactic elements than implementations usually see. Of particular 314 note: 315 o The Method contains non-alpha characters from token. Note that % 316 is not an escape character for this field. A method of IN%56ITE 317 is an unknown method. It is not the same as a method of INVITE 318 o The Request-URI contain unusual, but legal, characters 319 o A branch parameter contains all non-alphanum characters from token 320 o The To header field value's quoted-string contains quoted-pair 321 expansions, including a quoted NULL character 322 o The name part of name-addr in the From header field value contains 323 multiple tokens (instead of a quoted string) with all non-alphanum 324 characters from the token production rule. That value also has an 325 unknown header parameter whose name contains the non-alphanum 326 token characters and whose value is a non-ascii range UTF-8 327 encoded string. The tag parameter on this value contains the 328 non-alphanum token characters 329 o The Call-ID header field value contains the non-alphanum 330 characters from word. Notice that in this production: 331 * % is not an escape character. (It is only an escape character 332 in productions matching the rule "escaped") 333 * " does not start a quoted-string. None of ',` or " imply that 334 there will be a matching symbol later in the string 335 * The characters []{}()<> do not have any grouping semantics. 336 They are not required to appear in balanced pairs 337 o There is an unknown header field (matching extension-header) with 338 non-alphanum token characters in its name and a UTF8-NONASCII 339 value 341 If this unusual URI has been defined at a proxy, the proxy will 342 forward this request normally. Otherwise a proxy will generate a 343 404. Endpoints will generate a 501 listing the methods they 344 understand in an Allow header field. 346 Message Details : intmeth 348 349 !interesting-Method0123456789_*+`.%indeed'~ 350 sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;* 351 :&it+has=1,weird!*pas$wo~d_too.(doesn't-it) 352 @example.com SIP/2.0 353 354 Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~ 355 356 To: "BEL:\07 NUL:\00 DEL:\7F" 357 359 360 361 From: token1~` token2'+_ token3*%!.- 362 ;fromParam''~+*_!.-%= 363 "D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9" 364 ;tag=_token~1'+`*%!-. 365 366 Call-ID: intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{ 367 CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~ 368 Max-Forwards: 255 369 370 extensionHeader-!.%*+_`'~: 371 EFBBBFE5A4A7E5819CE99BBB 372 373 Content-Length: 0 375 3.1.1.3 Valid use of the % escaping mechanism 377 This INVITE exercises the % HEX HEX escaping mechanism in several 378 places. The request is syntactically valid. Interesting features 379 include: 380 o The request-URI has sips:user@example.com embedded in its 381 userpart. What that might mean to example.net is beyond the scope 382 of this document. 383 o The From and To URIs have escaped characters in their userparts. 384 o The Contact URI has escaped characters in the URI parameters. 385 Note that the "name" uri-parameter has a value of "value%41" which 386 is NOT equivalent to "valueA". Per [RFC2396], unescaping URI 387 components is never performed recursively. 389 A parser must accept this as a well-formed message. The application 390 using the message must treat the % HEX HEX expansions as equivalent 391 to the character being encoded. The application must not try to 392 interpret % as an escape character in those places where % HEX HEX 393 ("escaped" in the grammar) is not a valid part of the construction. 394 In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, 395 SIPS-URI, and Reason-Phrase 397 Message Details : esc01 399 INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0 400 To: sip:%75se%72@example.com 401 From: ;tag=938 402 Max-Forwards: 87 403 i: esc01.239409asdfakjkn23onasd0-3234 404 CSeq: 234234 INVITE 405 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw 406 C: application/sdp 407 Contact: 408 409 Content-Length: 151 411 v=0 412 o=mhandley 29739 7272939 IN IP4 192.0.2.1 413 s=- 414 c=IN IP4 192.0.2.1 415 t=0 0 416 m=audio 492170 RTP/AVP 0 12 417 m=video 3227 RTP/AVP 31 418 a=rtpmap:31 LPC 420 3.1.1.4 Escaped nulls in URIs 422 This register request contains several URIs with nulls in the 423 userpart. The message is well formed - parsers must accept this 424 message. Implementations must take special care when unescaping the 425 AOR in this request to not prematurely shorten the username. This 426 request registers two distinct contact URIs. 428 Message Details : escnull 430 REGISTER sip:example.com SIP/2.0 431 To: sip:null-%00-null@example.com 432 From: sip:null-%00-null@example.com;tag=839923423 433 Max-Forwards: 70 434 Call-ID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd 435 CSeq: 14398234 REGISTER 436 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 437 Contact: 438 Contact: 439 L:0 441 3.1.1.5 Use of % when it is not an escape 443 Most of the places % can appear in a SIP message, it is not an escape 444 character. This can surprise the unwary implementor. The following 445 well-formed request has these properties: 446 o The request method is unknown. It is NOT equivalent to REGISTER 447 o The display-name portion of the To and From header fields is 448 "%Z%45". Note that this is not the same as %ZE 449 o This message has two Contact header field values, not three. 450 %lt;sip:alias2@host2.example.com%gt; is a C%6Fntact header field 451 value 453 A parser should accept this message as well formed. A proxy would 454 forward or reject the message depending on what the Request-URI meant 455 to it. An endpoint would reject this message with a 501. 457 Message Details : esc02 459 RE%47IST%45R sip:registrar.example.com SIP/2.0 460 To: "%Z%45" 461 From: "%Z%45" ;tag=f232jadfj23 462 Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf 463 Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234 464 CSeq: 29344 RE%47IST%45R 465 Max-Forwards: 70 466 Contact: 467 C%6Fntact: 468 Contact: 469 l: 0 471 3.1.1.6 Message with no LWS between display name and < 473 This OPTIONS request is not valid per the grammar in RFC 3261. since 474 there is no LWS between the quoted string in the display name and < 475 in the From header field value. This has been identified as a 476 specification bug that will be removed when RFC 3261 is revised. 477 Elements should accept this request as well formed. 479 Message Details : lwsdisp 481 OPTIONS sip:user@example.com SIP/2.0 482 To: sip:user@example.com 483 From: "caller";tag=323 484 Max-Forwards: 70 485 Call-ID: lwsdisp.1234abcd@funky.example.com 486 CSeq: 60 OPTIONS 487 Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw 488 l: 0 490 3.1.1.7 Long values in header fields 492 This well-formed request contains header fields with many values and 493 values that are very long. Features include: 494 o The To header field has a long display name, and long uri 495 parameter names and values 496 o The From header field has long header parameter names and values, 497 in particular a very long tag 498 o The Call-ID is one long token 500 Message Details : longreq 502 INVITE sip:user@example.com SIP/2.0 503 504 To: "I have a user name of 505 extreme proportion" 506 longvalue; 508 longparamname=shortvalue; 509 verylongParameterNameWithNoValue> 510 511 512 F: sip: 513 amazinglylongcallername@example.net 514 ;tag=12982424 515 ;unknownheaderparamname= 516 unknowheaderparamvalue 517 ;unknownValuelessparamname 518 519 Call-ID: longreq.onereallylongcallid 520 CSeq: 3882340 INVITE 521 522 Unknown-Long-Name: 523 unknown-long-value; 524 unknown-long-parameter-name = 525 unknown-long-parameter-value 526 527 Via: SIP/2.0/TCP sip33.example.com 528 v: SIP/2.0/TCP sip32.example.com 529 V: SIP/2.0/TCP sip31.example.com 530 Via: SIP/2.0/TCP sip30.example.com 531 ViA: SIP/2.0/TCP sip29.example.com 532 VIa: SIP/2.0/TCP sip28.example.com 533 VIA: SIP/2.0/TCP sip27.example.com 534 via: SIP/2.0/TCP sip26.example.com 535 viA: SIP/2.0/TCP sip25.example.com 536 vIa: SIP/2.0/TCP sip24.example.com 537 vIA: SIP/2.0/TCP sip23.example.com 538 V : SIP/2.0/TCP sip22.example.com 539 v : SIP/2.0/TCP sip21.example.com 540 V : SIP/2.0/TCP sip20.example.com 541 v : SIP/2.0/TCP sip19.example.com 542 Via : SIP/2.0/TCP sip18.example.com 543 Via : SIP/2.0/TCP sip17.example.com 544 Via: SIP/2.0/TCP sip16.example.com 545 Via: SIP/2.0/TCP sip15.example.com 546 Via: SIP/2.0/TCP sip14.example.com 547 Via: SIP/2.0/TCP sip13.example.com 548 Via: SIP/2.0/TCP sip12.example.com 549 Via: SIP/2.0/TCP sip11.example.com 550 Via: SIP/2.0/TCP sip10.example.com 551 Via: SIP/2.0/TCP sip9.example.com 552 Via: SIP/2.0/TCP sip8.example.com 553 Via: SIP/2.0/TCP sip7.example.com 554 Via: SIP/2.0/TCP sip6.example.com 555 Via: SIP/2.0/TCP sip5.example.com 556 Via: SIP/2.0/TCP sip4.example.com 557 Via: SIP/2.0/TCP sip3.example.com 558 Via: SIP/2.0/TCP sip2.example.com 559 Via: SIP/2.0/TCP sip1.example.com 560 561 Via: SIP/2.0/TCP 562 host.example.com;received=192.0.2.5; 563 branch=verylongbranchvalue 564 565 Max-Forwards: 70 566 567 Contact: amazinglylongcallername 569 @host5.example.net> 570 571 Content-Type: application/sdp 572 l: 151 573 v=0 574 o=mhandley 29739 7272939 IN IP4 192.0.2.1 575 s=- 576 c=IN IP4 192.0.2.1 577 t=0 0 578 m=audio 492170 RTP/AVP 0 12 579 m=video 3227 RTP/AVP 31 580 a=rtpmap:31 LPC 582 3.1.1.8 Extra trailing octets in a UDP datagram 584 This message contains a single SIP REGISTER request, which ostensibly 585 arrived over UDP in a single datagram. The packet contained extra 586 octets after the body (which in this case has zero length). Those 587 octets happen to look like a SIP INVITE request, but (per section 588 18.3 of [RFC3261]) they are just spurious noise that must be ignored. 590 A SIP element receiving this datagram would handle the REGISTER 591 request normally and ignore the extra bits that look like an INVITE 592 request. If the element is a proxy choosing to forward the REGISTER, 593 the INVITE octets would not appear in the forwarded request. 595 Message Details : dblreq 597 REGISTER sip:example.com SIP/2.0 598 To: sip:j.user@example.com 599 From: sip:j.user@example.com;tag=43251j3j324 600 Max-Forwards: 8 601 I: dblreq.0ha0isndaksdj99sdfafnl3lk233412 602 Contact: sip:j.user@host.example.com 603 CSeq: 8 REGISTER 604 Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492 605 Content-Length: 0 607 INVITE sip:joe@example.com SIP/2.0 608 t: sip:joe@example.com 609 From: sip:caller@example.net;tag=141334 610 Max-Forwards: 8 611 Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15 612 CSeq: 8 INVITE 613 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234 614 Content-Type: application/sdp 615 Content-Length: 151 617 v=0 618 o=mhandley 29739 7272939 IN IP4 192.0.2.15 619 s=- 620 c=IN IP4 192.0.2.15 621 t=0 0 622 m=audio 492170 RTP/AVP 0 12 623 m =video 3227 RTP/AVP 31 624 a=rtpmap:31 LPC 626 3.1.1.9 Semicolon separated parameters in URI user part 628 This request has a semicolon-separated parameter contained in the 629 "user" part of the Request-URI (whose value contains an escaped @ 630 symbol). Receiving elements will accept this as a well formed 631 message. The Request-URI will parse such that the user part is 632 "user;par=u@example.net". 634 Message Details : semiuri 636 OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0 637 To: sip:j_user@example.com 638 From: sip:caller@example.org;tag=33242 639 Max-Forwards: 3 640 Call-ID: semiuri.0ha0isndaksdj 641 CSeq: 8 OPTIONS 642 Accept: application/sdp, application/pkcs7-mime, 643 multipart/mixed, multipart/signed, 644 message/sip, message/sipfrag 645 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw 646 l: 0 648 3.1.1.10 Varied and unknown transport types 650 This request contains Via header field values with all known 651 transport types and exercises the transport extension mechanism. 652 Parsers must accept this message as well formed. Elements receiving 653 this message would process it exactly as if the 2nd and subsequent 654 header field values specified UDP (or other transport). 656 Message Details : transports 658 OPTIONS sip:user@example.com SIP/2.0 659 To: sip:user@example.com 660 From: ;tag=323 661 Max-Forwards: 70 662 Call-ID: transports.kijh4akdnaqjkwendsasfdj 663 Accept: application/sdp 664 CSeq: 60 OPTIONS 665 Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw 666 Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf 667 Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj 668 Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en 669 Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee 670 l: 0 672 3.1.1.11 S/MIME signed message 674 This is a signed INVITE request. The signature is binary encoded. 675 The body contains null (0x00) characters. Receivers must take care 676 to properly frame the received message. 678 Parsers must accept this message as well formed, even if the 679 application above the parser does not support multipart/signed. 681 Message Details : smime01 683 INVITE sip:receiver@example.com SIP/2.0 684 Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3 685 To: 686 From: ;tag=2390234seiu3 687 Call-ID: smime01.uoqeiuavnklafekjq34iu43uawe 688 CSeq: 282398492 INVITE 689 Max-Forwards: 70 690 Contact: 691 Content-Length: 3134 692 Content-Type: multipart/signed; 693 protocol="application/pkcs-7-signature"; 694 micalg=sha1; 695 boundary="----EABF38A0AAE8704C560F10418BA807CF" 697 ------EABF38A0AAE8704C560F10418BA807CF 698 Content-Type: message/sip 700 INVITE sip:receiver@example.com SIP/2.0 701 Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3 702 To: 703 From: ;tag=2390234seiu3 704 Call-ID: smime01.uoqeiuavnklafekjq34iu43uawe 705 CSeq: 282398492 INVITE 706 Max-Forwards: 70 707 Contact: 708 Accept: application/sdp, application/pkcs7-mime, 709 multipart/mixed, multipart/signed, 710 message/sip, message/sipfrag 711 Content-Type: application/sdp 712 Content-Length: 149 714 v=0 715 o=sender 29739 7272939 IN IP4 192.0.2.1 716 s=- 717 c=IN IP4 192.0.2.1 718 t=0 0 719 m=audio 492170 RTP/AVP 0 12 720 m=video 3227 RTP/AVP 31 721 a=rtpmap:31 LPC 723 ------EABF38A0AAE8704C560F10418BA807CF 724 Content-Type: application/pkcs-7-signature; name="smime.p7s" 725 Content-Transfer-Encoding: binary 726 Content-Disposition: attachment; filename="smime.p7s" 728 3082088806092A86 729 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 730 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 731 90008902240001300D06092A864886F70D01010505003070310B300906035504 732 0613025553311330110603550408130A43616C69666F726E69613111300F0603 733 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 734 060355040B135369706974546573744365727469666963617465417574686F72 735 697479301E170D3033313032313134343332355A170D31333130313831343433 736 32355A3062310B3009060355040613025553311330110603550408130A43616C 737 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 738 040A13057369706974311B30190603550403141273656E646572406578616D70 739 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 740 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 741 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 742 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 743 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 744 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 745 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 746 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 747 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 748 310B3009060355040613025553311330110603550408130A43616C69666F726E 749 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 750 6970697431293027060355040B13536970697454657374436572746966696361 751 7465417574686F72697479820100300D06092A864886F70D0101050500038181 752 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 753 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 754 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 755 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 756 5E30820339308202A2A00302010202080090008902240001300D06092A864886 757 F70D01010505003070310B300906035504061302555331133011060355040813 758 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 759 0C060355040A1305736970697431293027060355040B13536970697454657374 760 4365727469666963617465417574686F72697479301E170D3033313032313134 761 343332355A170D3133313031383134343332355A3062310B3009060355040613 762 025553311330110603550408130A43616C69666F726E69613111300F06035504 763 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 764 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 765 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 766 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 767 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 768 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 769 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 770 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 771 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 772 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 773 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 774 30110603550408130A43616C69666F726E69613111300F060355040713085361 775 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 776 69706974546573744365727469666963617465417574686F7269747982010030 777 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 778 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 779 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 780 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 781 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 782 70310B3009060355040613025553311330110603550408130A43616C69666F72 783 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 784 736970697431293027060355040B135369706974546573744365727469666963 785 617465417574686F7269747902080090008902240001300906052B0E03021A05 786 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 787 06092A864886F70D010905310F170D3034303731343230333630375A30230609 788 2A864886F70D010904311604142830DBEDC758BAA9750138384431E8F1819717 789 C8305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 790 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 791 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 792 0101050004818060FF00161CFAC1E641D0C993FACD949DC239F9DDF527F834A6 793 ECF837B5D2C7B756F30A2755F5EF7A833351721F30A4392921E0A73594AA0BF2 794 4E6BD3981362DEA4F22844CB505ED3C6C0CCADD524066593ABED4023243055CA 795 0CE0AE83F13868E29E91E3AA588BDC11B2A18F39001885E17879503523699A87 796 982C6D48D4918A------EABF38A0AAE8704C560F10418BA807CF-- 798 3.1.1.12 Unusual reason phrase 800 This 200 response contains a reason phrase other than "OK". The 801 reason phrase is intended for human consumption, and may contain any 802 string produced by 804 Reason-Phrase = *(reserved / unreserved / escaped 805 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) 807 This particular response contains unreserved and non-ASCII UTF-8 808 characters.This response is well formed. A parser must accept this 809 message. 811 Message Details : unreason 813 814 SIP/2.0 200 = 2**3 * 5**2 D0BDD0BE20D181D182 815 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4 816 D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 817 BED0B5 818 819 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 820 Call-ID: unreason.1234ksdfak3j2erwedfsASdf 821 CSeq: 35 INVITE 822 From: sip:user@example.com;tag=11141343 823 To: sip:user@example.edu;tag=2229 824 Content-Length: 159 825 Content-Type: application/sdp 826 Contact: 828 v=0 829 o=mhandley 29739 7272939 IN IP4 192.0.2.198 830 s=- 831 c=IN IP4 192.0.2.198/127 832 t=0 0 833 m=audio 492170 RTP/AVP 0 12 834 m=video 3227 RTP/AVP 31 835 a=rtpmap:31 LPC 837 3.1.1.13 Empty reason phrase 839 This well formed response contains no reason phrase. A parser must 840 accept this message. The space character after the reason code is 841 required. If it were not present, this message could be rejected as 842 invalid (a liberal receiver would accept it anyway). 844 Message Details : noreason 846 SIP/2.0 10020 847 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 848 Call-ID: noreason.asndj203insdf99223ndf 849 CSeq: 35 INVITE 850 From: ;tag=39ansfi3 851 To: ;tag=902jndnke3 852 Content-Length: 0 853 Contact: 855 3.1.2 Invalid messages 857 This section contains several invalid messages reflecting errors seen 858 at interoperability events and exploring important edge conditions 859 that can be induced through malformed messages. This section does 860 not attempt to be a comprehensive list of all types of invalid 861 messages. 863 3.1.2.1 Extraneous header field separators 865 The Via and header field of this request contains contain additional 866 semicolons and commas without parameters or values. The Contact 867 header field contains additional semicolons without parameters. This 868 message is syntactically invalid. 870 An element receiving this request should respond with a 400 Bad 871 Request error. 873 Message Details : badinv01 875 INVITE sip:user@example.com SIP/2.0 876 To: sip:j.user@example.com 877 From: sip:caller@example.net;tag=134161461246 878 Max-Forwards: 7 879 Call-ID: badinv01.0ha0isndaksdjasdf3234nas 880 CSeq: 8 INVITE 881 Via: SIP/2.0/UDP 192.0.2.15;;,;,, 882 Contact: "Joe" ;;;; 883 Content-Length: 153 884 Content-Type: application/sdp 886 v=0 887 o=mhandley 29739 7272939 IN IP4 192.0.2.15 888 s=- 889 c=IN IP4 192.0.2.15 890 t=0 0 891 m=audio 492170 RTP/AVP 0 12 892 m=video 3227 RTP/AVP 31 893 a=rtpmap:31 LPC 895 3.1.2.2 Content length larger than message 897 This is a request message with a Content Length that is larger than 898 the length of the body. 900 When sent UDP (as this message ostensibly was), the receiving element 901 should respond with a 400 Bad Request error. If this message were 902 received over a stream-based transport such as TCP, there's not much 903 you can do but wait for more data on the stream and close the 904 connection if none is forthcoming in a reasonable period of time. 906 Message Details : clerr 908 INVITE sip:user@example.com SIP/2.0 909 Max-Forwards: 80 910 To: sip:j.user@example.com 911 From: sip:caller@example.net;tag=93942939o2 912 Contact: 913 Call-ID: clerr.0ha0isndaksdjweiafasdk3 914 CSeq: 8 INVITE 915 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523 916 Content-Type: application/sdp 917 Content-Length: 9999 919 v=0 920 o=mhandley 29739 7272939 IN IP4 192.0.2.155 921 s=- 922 c=IN IP4 192.0.2.155 923 t=0 0 924 m=audio 492170 RTP/AVP 0 12 925 m=video 3227 RTP/AVP 31 926 a=rtpmap:31 LPC 928 3.1.2.3 Negative Content-Length 930 This request has a negative value for Content-Length. 932 An element receiving this message should respond with an error. This 933 request appeared over UDP, so the remainder of the datagram can 934 simply be discarded. If a request like this arrives over TCP, the 935 framing error is not recoverable and the connection should be closed. 936 The same behavior is appropriate for messages that arrive without a 937 numeric value in the Content-Length header field such as: 939 Content-Length: five 941 Implementors should take extra precautions if the technique they 942 choose for converting this ascii field into an integral form can 943 return a negative value. In particular, the result must not be used 944 as a counter or array index. 946 Message Details : ncl 948 INVITE sip:user@example.com SIP/2.0 949 Max-Forwards: 254 950 To: sip:j.user@example.com 951 From: sip:caller@example.net;tag=32394234 952 Call-ID: ncl.0ha0isndaksdj2193423r542w35 953 CSeq: 0 INVITE 954 Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw 955 Contact: 956 Content-Type: application/sdp 957 Content-Length: -999 959 v=0 960 o=mhandley 29739 7272939 IN IP4 192.0.2.53 961 s=- 962 c=IN IP4 192.0.2.53 963 t=0 0 964 m=audio 492170 RTP/AVP 0 12 965 m=video 3227 RTP/AVP 31 966 a=rtpmap:31 LPC 968 3.1.2.4 Request scalar fields with overlarge values 970 This request contains several scalar header field values outside 971 their legal range. 972 o the CSeq sequence number is >2**32-1. 973 o the Max-Forwards value is >255. 974 o the Expires value is >2**32-1. 975 o the Contact expires parameter value is >2**32-1. 977 An element receiving this request should respond with a 400 Bad 978 Request due to the CSeq error. If only the Max-Forwards field were 979 in error, the element could choose process the request as if the 980 field were absent. If only the expiry values were in error, the 981 element could treat them as if they contained the default values for 982 expiration (3600 in this case). 984 Other scalar request fields that may contain aberrant values include, 985 but are not limited to, the Contact q value, the Timestamp value, 986 and the Via ttl parameter. 988 Message Details : scalar02 990 REGISTER sip:example.com SIP/2.0 991 Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3 992 To: 993 From: ;tag=239232jh3 994 CSeq: 36893488147419103232 REGISTER 995 Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32 996 Max-Forwards: 300 997 Expires: 10 998 Contact: 999 ;expires=280297596632815 1000 Content-Length: 0 1002 3.1.2.5 Response scalar fields with overlarge values 1004 This response contains several scalar header field values outside 1005 their legal range. 1006 o the CSeq sequence number is >2**32-1. 1007 o The Retry-After field is unreasonably large (note that RFC 3261 1008 does not define a legal range for this field). 1009 o The Warning field has a warning-value with more than 3 digits 1011 An element receiving this response will simply discard it. 1013 Message Details : scalarlg 1015 SIP/2.0 503 Service Unavailable 1016 Via: SIP/2.0/TCP host129.example.com;branch=z0hG4bKzzxdiwo34sw 1017 To: 1018 From: ;tag=2easdjfejw 1019 CSeq: 9292394834772304023312 OPTIONS 1020 Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r 1021 Retry-After: 949302838503028349304023988 1022 Warning: 1812 overture "In Progress" 1023 Content-Length: 0 1025 3.1.2.6 Unterminated quoted string in display-name 1027 This is a request with an unterminated quote in the display name of 1028 the To field. An element receiving this request should return an 400 1029 Bad Request error. 1031 An element could attempt to infer a terminating quote and accept the 1032 message. Such an element needs to take care that it makes a 1033 reasonable inference when it encounters 1035 To: "Mr J. User 1037 Message Details : quotbal 1039 INVITE sip:user@example.com SIP/2.0 1040 To: "Mr. J. User 1041 From: sip:caller@example.net;tag=93334 1042 Max-Forwards: 10 1043 Call-ID: quotbal.aksdj 1044 Contact: 1045 CSeq: 8 INVITE 1046 Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234 1047 Content-Type: application/sdp 1048 Content-Length: 153 1050 v=0 1051 o=mhandley 29739 7272939 IN IP4 192.0.2.15 1052 s=- 1053 c=IN IP4 192.0.2.15 1054 t=0 0 1055 m=audio 492170 RTP/AVP 0 12 1056 m=video 3227 RTP/AVP 31 1057 a=rtpmap:31 LPC 1059 3.1.2.7 <> enclosing Request-URI 1061 This INVITE request is invalid because the Request-URI has been 1062 enclosed within in "<>". 1064 It is reasonable to always reject a request with this error with a 1065 400 Bad Request. Elements attempting to be liberal with what they 1066 accept may choose to ignore the brackets. If the element forwards 1067 the request, it must not include the brackets in the messages it 1068 sends. 1070 Message Details : ltgtruri 1072 INVITE SIP/2.0 1073 To: sip:user@example.com 1074 From: sip:caller@example.net;tag=39291 1075 Max-Forwards: 23 1076 Call-ID: ltgtruri.1@192.0.2.5 1077 CSeq: 1 INVITE 1078 Via: SIP/2.0/UDP 192.0.2.5 1079 Contact: 1080 Content-Type: application/sdp 1081 Content-Length: 160 1083 v=0 1084 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1085 s=- 1086 c=IN IP4 192.0.2.5 1087 t=3149328700 0 1088 m=audio 492170 RTP/AVP 0 12 1089 m=video 3227 RTP/AVP 31 1090 a=rtpmap:31 LPC 1092 3.1.2.8 Malformed SIP Request-URI (embedded LWS) 1094 This INVITE has illegal LWS within the Request-URI. 1096 An element receiving this request should respond with a 400 Bad 1097 Request. 1099 An element could attempt to ignore the embedded LWS for those schemes 1100 (like sip) where that would not introduce ambiguity. 1102 Message Details : lwsruri 1104 INVITE sip:user@example.com; lr SIP/2.0 1105 To: sip:user@example.com;tag=3xfe-9921883-z9f 1106 From: sip:caller@example.net;tag=231413434 1107 Max-Forwards: 5 1108 Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423 1109 CSeq: 2130706432 INVITE 1110 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395 1111 Contact: 1112 Content-Type: application/sdp 1113 Content-Length: 160 1115 v=0 1116 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1117 s=- 1118 c=IN IP4 192.0.2.1 1119 t=3149328700 0 1120 m=audio 492170 RTP/AVP 0 12 1121 m=video 3227 RTP/AVP 31 1122 a=rtpmap:31 LPC 1124 3.1.2.9 Multiple SP separating Request-Line elements 1126 This INVITE has illegal multiple SP characters between elements of 1127 the start line. 1129 It is acceptable to reject this request as malformed. An element 1130 that is liberal in what it accepts may ignore these extra SP 1131 characters while processing the request. If the element forwards the 1132 request, it must not include these extra SP characters in the 1133 messages it sends. 1135 Message Details : lwsstart 1137 INVITE sip:user@example.com SIP/2.0 1138 Max-Forwards: 8 1139 To: sip:user@example.com 1140 From: sip:caller@example.net;tag=8814 1141 Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com 1142 CSeq: 1893884 INVITE 1143 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923 1144 Contact: 1145 Content-Type: application/sdp 1146 Content-Length: 151 1148 v=0 1149 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1150 s=- 1151 c=IN IP4 192.0.2.1 1152 t=0 0 1153 m=audio 492170 RTP/AVP 0 12 1154 m=video 3227 RTP/AVP 31 1155 a=rtpmap:31 LPC 1157 3.1.2.10 SP characters at end of Request-Line 1159 This OPTIONS request contains SP characters between the SIP-Version 1160 field and the CRLF terminating the Request-Line. 1162 It is acceptable to reject this request as malformed. An element 1163 that is liberal in what it accepts may ignore these extra SP 1164 characters while processing the request. If the element forwards the 1165 request, it must not include these extra SP characters in the 1166 messages it sends. 1168 Message Details : trws 1170 OPTIONS sip:remote-target@example.com SIP/2.02020 1171 Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093 1172 To: 1173 From: ;tag=329429089 1174 Call-ID: trws.oicu34958239neffasdhr2345r 1175 Accept: application/sdp 1176 CSeq: 238923 OPTIONS 1177 Max-Forwards: 70 1178 Content-Length: 0 1180 3.1.2.11 Escaped headers in SIP Request-URI 1182 This INVITE is malformed as the SIP Request-URI contains escaped 1183 headers. 1185 It is acceptable for an element to reject this request with a 400 Bad 1186 Request. An element could choose to be liberal in what it accepts 1187 and ignore the escaped headers. If the element is a proxy, the 1188 escaped headers must not appear in the Request-URI of forwarded 1189 request (and most certainly must not be translated into the actual 1190 header of the forwarded request). 1192 Message Details : escruri 1194 INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0 1195 To: sip:user@example.com 1196 From: sip:caller@example.net;tag=341518 1197 Max-Forwards: 7 1198 Contact: 1199 Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 1200 CSeq: 149209342 INVITE 1201 Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw 1202 Content-Type: application/sdp 1203 Content-Length: 151 1205 v=0 1206 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1207 s=- 1208 c=IN IP4 192.0.2.1 1209 t=0 0 1210 m=audio 492170 RTP/AVP 0 12 1211 m=video 3227 RTP/AVP 31 1212 a=rtpmap:31 LPC 1214 3.1.2.12 Invalid timezone in Date header field 1216 This INVITE is invalid as it contains a non GMT time zone in the SIP 1217 Date header field. 1219 It is acceptable to reject this request as malformed (though an 1220 element shouldn't do that unless the contents of the Date header 1221 field were actually important to its processing). An element wishing 1222 to be liberal in what it accepts could ignore this value altogether 1223 if it wasn't going to use the Date header field anyhow. Otherwise, 1224 it could attempt to interpret this date and adjust it to GMT. 1226 RFC 3261 explicitly defines the only acceptable timezone designation 1227 as "GMT". "UT", while synonymous with GMT per [RFC2822], is not 1228 valid. "UTC" and "UCT" are also invalid. 1230 Message Details : baddate 1232 INVITE sip:user@example.com SIP/2.0 1233 To: sip:user@example.com 1234 From: sip:caller@example.net;tag=2234923 1235 Max-Forwards: 70 1236 Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234 1237 CSeq: 1392934 INVITE 1238 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1239 Date: Fri, 01 Jan 2010 16:00:00 EST 1240 Contact: 1241 Content-Type: application/sdp 1242 Content-Length: 151 1244 v=0 1245 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1246 s=- 1247 c=IN IP4 192.0.2.5 1248 t=0 0 1249 m=audio 492170 RTP/AVP 0 12 1250 m=video 3227 RTP/AVP 31 1251 a=rtpmap:31 LPC 1253 3.1.2.13 Failure to enclose name-addr URI in <> 1255 This REGISTER request is malformed. The SIP URI contained in the 1256 Contact Header field has an escaped header, so the field must be in 1257 name-addr form (which implies the URI must be enclosed in <>). 1259 It is reasonable for an element receiving this request to respond 1260 with a 400 Bad Request. An element choosing to be liberal in what it 1261 accepts could infer the angle brackets since there is no ambiguity in 1262 this example. In general, that won't be possible. 1264 Message Details : regbadct 1266 REGISTER sip:example.com SIP/2.0 1267 To: sip:user@example.com 1268 From: sip:user@example.com;tag=998332 1269 Max-Forwards: 70 1270 Call-ID: regbadct.k345asrl3fdbv@10.0.0.1 1271 CSeq: 1 REGISTER 1272 Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 1273 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 1274 l: 0 1276 3.1.2.14 Spaces within addr-spec 1278 This request is malformed since the addr-spec in the To header field 1279 contains spaces. Parsers receiving this request must not break. It 1280 is reasonable to reject this request with a 400 Bad Request response. 1281 Elements attempting to be liberal may ignore the spaces. 1283 Message Details : badaspec 1285 OPTIONS sip:user@example.org SIP/2.0 1286 Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234 1287 Max-Forwards: 70 1288 From: "Bell, Alexander" ;tag=433423 1289 To: "Watson, Thomas" < sip:t.watson@example.org > 1290 Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3 1291 Accept: application/sdp 1292 CSeq: 3923239 OPTIONS 1293 l: 0 1295 3.1.2.15 Non-token characters in display-name 1297 This OPTIONS request is malformed since the display names in the To 1298 and From header fields contain non-token characters but are unquoted. 1300 It is reasonable to always reject this kind of error with a 400 Bad 1301 Request response. 1303 An element may attempt to be liberal in what it receives and infer 1304 the missing quotes. If this element were a proxy, it must not 1305 propagate the error into the request it forwards. As a consequence, 1306 if the fields are covered by a signature, there's not much point in 1307 trying to be liberal - the message should be simply rejected. 1309 Message Details : baddn 1311 OPTIONS sip:t.watson@example.org SIP/2.0 1312 Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw 1313 Max-Forwards: 70 1314 From: Bell, Alexander ;tag=43 1315 To: Watson, Thomas 1316 Call-ID: baddn.31415@c.example.com 1317 Accept: application/sdp 1318 CSeq: 3923239 OPTIONS 1319 l: 0 1321 3.1.2.16 Unknown protocol version 1323 To an element implementing [RFC3261], this request is malformed due 1324 to its high version number. 1326 The element should respond to the request with a 505 Version Not 1327 Supported error. 1329 Message Details : badvers 1331 OPTIONS sip:t.watson@example.org SIP/7.0 1332 Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw 1333 Max-Forwards: 70 1334 From: A. Bell ;tag=qweoiqpe 1335 To: T. Watson 1336 Call-ID: badvers.31417@c.example.com 1337 CSeq: 1 OPTIONS 1338 l: 0 1340 3.1.2.17 Start line and CSeq method mismatch 1342 This request has mismatching values for the method in the start line 1343 and the CSeq header field. Any element receiving this request will 1344 respond with a 400 Bad Request. 1346 Message Details : mismatch01 1348 OPTIONS sip:user@example.com SIP/2.0 1349 To: sip:j.user@example.com 1350 From: sip:caller@example.net;tag=34525 1351 Max-Forwards: 6 1352 Call-ID: mismatch01.dj0234sxdfl3 1353 CSeq: 8 INVITE 1354 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1355 l: 0 1357 3.1.2.18 Unknown Method with CSeq method mismatch 1359 This message has an unknown method, and a CSeq method tag which does 1360 not match it. 1362 Any element receiving this response will should respond with a 501 1363 Not Implemented. A 400 Bad Request is also acceptable, but choosing 1364 a 501 (particularly at proxies) has better future-proof 1365 characteristics. 1367 Message Details : mismatch02 1369 NEWMETHOD sip:user@example.com SIP/2.0 1370 To: sip:j.user@example.com 1371 From: sip:caller@example.net;tag=34525 1372 Max-Forwards: 6 1373 Call-ID: mismatch02.dj0234sxdfl3 1374 CSeq: 8 INVITE 1375 Contact: 1376 Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw 1377 Content-Type: application/sdp 1378 l: 139 1380 v=0 1381 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1382 c=IN IP4 192.0.2.1 1383 m=audio 492170 RTP/AVP 0 12 1384 m=video 3227 RTP/AVP 31 1385 a=rtpmap:31 LPC 1387 3.1.2.19 Overlarge response code 1389 This response has a response code larger than 699. An element 1390 receiving this response should simply drop it. 1392 Message Details : bigcode 1394 SIP/2.0 4294967301 better not break the receiver 1395 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 1396 Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i 1397 CSeq: 353494 INVITE 1398 From: ;tag=39ansfi3 1399 To: ;tag=902jndnke3 1400 Content-Length: 0 1401 Contact: 1403 3.2 Transaction layer semantics 1405 This section contains tests that exercise an implementation's parser 1406 and transaction layer logic. 1408 3.2.1 Missing transaction identifier 1410 This request indicates support for RFC 3261-style transaction 1411 identifiers by providing the z9hG4bK prefix to the branch parameter, 1412 but it provides no identifier. A parser must not break when 1413 receiving this message. An element receiving this request could 1414 reject the request with a 400 Response (preferably statelessly, as 1415 other requests from the source are likely to also have a malformed 1416 branch parameter), or it could fall back to the RFC 2543 style 1417 transaction identifier. 1419 Message Details : badbranch 1421 OPTIONS sip:user@example.com SIP/2.0 1422 To: sip:user@example.com 1423 From: sip:caller@example.org;tag=33242 1424 Max-Forwards: 3 1425 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK 1426 Accept: application/sdp 1427 Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n 1428 CSeq: 8 OPTIONS 1429 l: 0 1431 3.3 Application layer semantics 1433 This section contains tests that exercise an implementation's parser 1434 and application layer logic. 1436 3.3.1 Missing Required Header Fields 1438 This request contains no Call-ID, From, or To header fields. 1440 An element receiving this message must not break because of the 1441 missing information. Ideally, it will respond with a 400 Bad Request 1442 error. 1444 Message Details : insuf 1446 INVITE sip:user@example.com SIP/2.0 1447 CSeq: 193942 INVITE 1448 Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf 1449 Content-Type: application/sdp 1450 l: 153 1452 v=0 1453 o=mhandley 29739 7272939 IN IP4 192.0.2.95 1454 s=- 1455 c=IN IP4 192.0.2.95 1456 t=0 0 1457 m=audio 492170 RTP/AVP 0 12 1458 m=video 3227 RTP/AVP 31 1459 a=rtpmap:31 LPC 1461 3.3.2 Request-URI with unknown scheme 1463 This OPTIONS contains an unknown URI scheme in the Request-URI. A 1464 parser must accept this as a well-formed SIP request. 1466 An element receiving this request will reject it with a 416 1467 Unsupported URI Scheme response. 1469 Some early implementations attempt to look at the contents of the To 1470 header field to determine how to route this kind of request. That is 1471 an error. Despite the fact that the To header field and the Request 1472 URI frequently look alike in simplistic first-hop messages, the To 1473 header field contains no routing information. 1475 Message Details : unkscm 1477 OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0 1478 To: sip:user@example.com 1479 From: sip:caller@example.net;tag=384 1480 Max-Forwards: 3 1481 Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34 1482 CSeq: 3923423 OPTIONS 1483 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1484 Content-Length: 0 1486 3.3.3 Request-URI with known but atypical scheme 1488 This OPTIONS contains an Request-URI with an IANA registered scheme 1489 that does not commonly appear Request-URIs of SIP requests. A parser 1490 must accept this as a well-formed SIP request. 1492 If an element will never accept this scheme as meaningful in a 1493 request-URI, it is appropriate to treat it as unknown and return a 1494 416 Unsupported URI Scheme response. If the element might accept 1495 some URIs with this scheme, then a 404 Not Found is appropriate for 1496 those URIs it doesn't accept. 1498 Message Details : novelsc 1500 OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0 1501 To: sip:user@example.com 1502 From: sip:caller@example.net;tag=384 1503 Max-Forwards: 3 1504 Call-ID: novelsc.asdfasser0q239nwsdfasdkl34 1505 CSeq: 3923423 OPTIONS 1506 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1507 Content-Length: 0 1509 3.3.4 Unknown URI schemes in header fields 1511 This message contains registered schemes in the To, From and Contact 1512 header fields of a request. The message is syntactically valid. 1513 Parsers must not fail when receiving this message. 1515 Proxies should treat this message as they would any other request for 1516 this URI. A registrar would reject this request with a 400 Bad 1517 Request response since the To: header field is required to contain a 1518 SIP or SIPS URI as an AOR. 1520 Message Details : unksm2 1522 REGISTER sip:example.com SIP/2.0 1523 To: isbn:2983792873 1524 From: ;tag=3234233 1525 Call-ID: unksm2.daksdj@hyphenated-host.example.com 1526 CSeq: 234902 REGISTER 1527 Max-Forwards: 70 1528 Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw 1529 Contact: 1530 l: 0 1532 3.3.5 Proxy-Require and Require 1534 This request tests proper implementation of SIP's Proxy-Require and 1535 Require extension mechanisms. 1537 Any element receiving this request will respond with a 420 Bad 1538 Extension response containing an Unsupported header field listing 1539 these features from either the Require or Proxy-Require header field 1540 depending on the role in which the element is responding. 1542 Message Details : bext01 1544 OPTIONS sip:user@example.com SIP/2.0 1545 To: sip:j_user@example.com 1546 From: sip:caller@example.net;tag=242etr 1547 Max-Forwards: 6 1548 Call-ID: bext01.0ha0isndaksdj 1549 Require: nothingSupportsThis, nothingSupportsThisEither 1550 Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis 1551 CSeq: 8 OPTIONS 1552 Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw 1553 Content-Length: 0 1555 3.3.6 Unknown Content-Type 1557 This INVITE request contains a body of unknown type. It is 1558 syntactically valid. A parser must not fail when receiving it. 1560 A proxy receiving this request would process it just like any other 1561 INVITE. An endpoint receiving this request would reject it with a 1562 415 Unsupported Media Type error. 1564 Message Details : invut 1566 INVITE sip:user@example.com SIP/2.0 1567 Contact: 1568 To: sip:j.user@example.com 1569 From: sip:caller@example.net;tag=8392034 1570 Max-Forwards: 70 1571 Call-ID: invut.0ha0isndaksdjadsfij34n23d 1572 CSeq: 235448 INVITE 1573 Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw 1574 Content-Type: application/unknownformat 1575 Content-Length: 40 1577 1581 3.3.7 Unknown authorization scheme 1583 This REGISTER request contains an Authorization header field with an 1584 unknown scheme. The request is well-formed. A parser must not fail 1585 when receiving it. 1587 A proxy will treat this request as any other REGISTER. If it 1588 forwards the request, it will include this Authorization header field 1589 unmodified in the forwarded messages. 1591 A registrar that does not care about challenge-response 1592 authentication will simply ignore the Authorization header field, 1593 processing this registration as if the field were not present. A 1594 registrar that does care about challenge-response authentication will 1595 reject this request with a 401, issuing a new challenge with a scheme 1596 it understands. 1598 Endpoints choosing not to act as registrars will simply reject the 1599 request. A 405 Method Not Allowed is appropriate. 1601 Message Details : regaut01 1603 REGISTER sip:example.com SIP/2.0 1604 To: sip:j.user@example.com 1605 From: sip:j.user@example.com;tag=87321hj23128 1606 Max-Forwards: 8 1607 Call-ID: regaut01.0ha0isndaksdj 1608 CSeq: 9338 REGISTER 1609 Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw 1610 Authorization: NoOneKnowsThisScheme opaque-data=here 1611 Content-Length:0 1613 3.3.8 Multiple values in single value required fields 1615 The message contains a request with multiple Call-ID, To, From, 1616 Max-Forwards and CSeq values. An element receiving this request must 1617 not break. 1619 An element receiving this request would respond with a 400 Bad 1620 Request error. 1622 Message Details : multi01 1624 INVITE sip:user@company.com SIP/2.0 1625 Contact: 1626 Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw 1627 Max-Forwards: 70 1628 CSeq: 5 INVITE 1629 Call-ID: multi01.98asdh@192.0.2.1 1630 CSeq: 59 INVITE 1631 Call-ID: multi01.98asdh@192.0.2.2 1632 From: sip:caller@example.com;tag=3413415 1633 To: sip:user@example.com 1634 To: sip:other@example.net 1635 From: sip:caller@example.net;tag=2923420123 1636 Content-Type: application/sdp 1637 l: 155 1638 Contact: 1639 Max-Forwards: 5 1641 v=0 1642 o=mhandley 29739 7272939 IN IP4 192.0.2.25 1643 s=- 1644 c=IN IP4 192.0.2.25 1645 t=0 0 1646 m=audio 492170 RTP/AVP 0 12 1647 m=video 3227 RTP/AVP 31 1648 a=rtpmap:31 LPC 1650 3.3.9 Multiple Content-Length values 1652 Multiple conflicting Content-Length header field values appear in 1653 this request. 1655 From a framing perspective, this situation is equivalent to an 1656 invalid Content-Length value (or no value at all). 1658 An element receiving this message should respond with an error. This 1659 request appeared over UDP, so the remainder of the datagram can 1660 simply be discarded. If a request like this arrives over TCP, the 1661 framing error is not recoverable and the connection should be closed. 1663 Message Details : mcl01 1665 OPTIONS sip:user@example.com SIP/2.0 1666 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423 1667 To: sip:user@example.com 1668 From: sip:other@example.net;tag=3923942 1669 Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf 1670 CSeq: 15932 OPTIONS 1671 Content-Length: 13 1672 Max-Forwards: 60 1673 Content-Length: 5 1674 Content-Type: text/plain 1676 There's no way to know how many octets are supposed to be here. 1678 3.3.10 200 OK Response with broadcast Via header field value 1680 This message is a response with a 2nd Via header field value's 1681 sent-by containing 255.255.255.255. The message is well formed - 1682 parsers must not fail when receiving it. 1684 Per [RFC3261] an endpoint receiving this message should simply 1685 discard it. 1687 If a proxy followed normal response processing rules blindly, it 1688 would forward this response to the broadcast address. To protect 1689 against this being used as an avenue of attack, proxies should drop 1690 such responses. 1692 Message Details : bcast 1694 SIP/2.0 200 OK 1695 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 1696 Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23 1697 Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf 1698 CSeq: 35 INVITE 1699 From: sip:user@example.com;tag=11141343 1700 To: sip:user@example.edu;tag=2229 1701 Content-Length: 159 1702 Content-Type: application/sdp 1703 Contact: 1705 v=0 1706 o=mhandley 29739 7272939 IN IP4 192.0.2.198 1707 s=- 1708 c=IN IP4 192.0.2.198/127 1709 t=0 0 1710 m=audio 492170 RTP/AVP 0 12 1711 m=video 3227 RTP/AVP 31 1712 a=rtpmap:31 LPC 1714 3.3.11 Max-Forwards of zero 1716 This is a legal SIP request with the Max-Forwards header field value 1717 set to zero. 1719 A proxy should not forward the request and respond 483 (Too Many 1720 Hops). An endpoint should process the request as if the Max-Forwards 1721 field value were still positive. 1723 Message Details : zeromf 1725 OPTIONS sip:user@example.com SIP/2.0 1726 To: sip:user@example.com 1727 From: sip:caller@example.net;tag=3ghsd41 1728 Call-ID: zeromf.jfasdlfnm2o2l43r5u0asdfas 1729 CSeq: 39234321 OPTIONS 1730 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i 1731 Max-Forwards: 0 1732 Content-Length: 0 1734 3.3.12 REGISTER with a contact header parameter 1736 This register request contains a contact where the 'unknownparam' 1737 parameter must be interpreted as being a contact-param and not a 1738 url-param. 1740 This REGISTER should succeed. The response must not include 1741 "unknownparam" as a url-parameter for this binding. Likewise, 1742 "unknownparam" must not appear as part of the binding during 1743 subsequent fetches. 1745 Behavior is the same, of course, for any known contact-param 1746 parameter names. 1748 Message Details : cparam01 1750 REGISTER sip:example.com SIP/2.0 1751 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1752 Max-Forwards: 70 1753 From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe 1754 To: sip:watson@example.com 1755 Call-ID: cparam01.70710@saturn.example.com 1756 CSeq: 2 REGISTER 1757 Contact: sip:+19725552222@gw1.example.net;unknownparam 1758 l: 0 1760 3.3.13 REGISTER with a url parameter 1762 This register request contains a contact where the URI has an unknown 1763 parameter. 1765 The register should succeed and a subsequent retrieval of the 1766 registration must include "unknownparam" as a url-parameter. 1768 Behavior is the same, of course, for any known url-parameter names. 1770 Message Details : cparam02 1772 REGISTER sip:example.com SIP/2.0 1773 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1774 Max-Forwards: 70 1775 From: sip:watson@example.com;tag=838293 1776 To: sip:watson@example.com 1777 Call-ID: cparam02.70710@saturn.example.com 1778 CSeq: 3 REGISTER 1779 Contact: 1780 l: 0 1782 3.3.14 REGISTER with a url escaped header 1784 This register request contains a contact where the URI has an escaped 1785 header. 1787 The register should succeed and a subsequent retrieval of the 1788 registration must include the escaped Route header in the contact URI 1789 for this binding. 1791 Message Details : regescrt 1793 REGISTER sip:example.com SIP/2.0 1794 To: sip:user@example.com 1795 From: sip:user@example.com;tag=8 1796 Max-Forwards: 70 1797 Call-ID: regescrt.k345asrl3fdbv@192.0.2.1 1798 CSeq: 14398234 REGISTER 1799 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 1800 M: 1801 L:0 1803 3.3.15 Unacceptable Accept offering 1805 This request indicates the response must contain a body in an unknown 1806 type. In particular, since the Accept header field does not contain 1807 application/sdp, the response may not contain an SDP body. The 1808 recipient of this request could respond with a 406 Not Acceptable 1809 with a Warning/399 indicating that a response cannot be formulated in 1810 the formats offered in the Accept header field. It is also 1811 appropriate to respond with a 400 Bad Request since all SIP UAs 1812 supporting INVITE are required to support application/sdp. 1814 Message Details : sdp01 1816 INVITE sip:user@example.com SIP/2.0 1817 To: sip:j_user@example.com 1818 Contact: 1819 From: sip:caller@example.net;tag=234 1820 Max-Forwards: 5 1821 Call-ID: sdp01.ndaksdj9342dasdd 1822 Accept: text/nobodyKnowsThis 1823 CSeq: 8 INVITE 1824 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw 1825 Content-Length: 151 1826 Content-Type: application/sdp 1828 v=0 1829 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1830 s=- 1831 c=IN IP4 192.0.2.5 1832 t=0 0 1833 m=audio 492170 RTP/AVP 0 12 1834 m=video 3227 RTP/AVP 31 1835 a=rtpmap:31 LPC 1837 3.4 Backward compatibility 1839 3.4.1 INVITE with RFC2543 syntax 1841 This is a legal message per RFC 2543 (and several bis versions) which 1842 should be accepted by RFC 3261 elements which want to maintain 1843 backwards compatibility. 1844 o There is no branch parameter at all on the Via header field value 1845 o There is no From tag 1846 o There is no explicit Content-Length (The body is assumed to be all 1847 octets in the datagram after the null-line) 1848 o There is no Max-Forwards header field 1849 Message Details : inv2543 1851 INVITE sip:UserB@example.com SIP/2.0 1852 Via: SIP/2.0/UDP iftgw.example.com 1853 From: 1854 Record-Route: 1855 To: sip:+16505552222@ss1.example.net;user=phone 1856 Call-ID: inv2543.1717@ift.client.example.com 1857 CSeq: 56 INVITE 1858 Content-Type: application/sdp 1860 v=0 1861 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1862 s=- 1863 c=IN IP4 192.0.2.5 1864 t=0 0 1865 m=audio 492170 RTP/AVP 0 1867 4. Security Considerations 1869 This document presents NON NORMATIVE examples of SIP session 1870 establishment. The security considerations in [RFC3261] apply. 1872 Parsers must carefully consider edge conditions and malicious input 1873 as part of their design. Attacks on many Internet systems use 1874 crafted input to cause implementations to behave in undesirable ways. 1875 Many of the messages in this draft are designed to stress a parser 1876 implementation at points traditionally used for such attacks. This 1877 document does not, however, attempt to be comprehensive. It should 1878 be considered a seed to stimulate thinking and planning, not simply a 1879 set of tests to be passed. 1881 5. IANA Considerations 1883 This document has no actions for IANA. 1885 6. Acknowledgments 1887 The authors wish to thank the following individuals for their 1888 participation in the review of earlier versions of this document: 1889 Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen 1890 Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, 1891 Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua 1892 and Tom Taylor. 1894 Thanks to Neil Deason for contributing several messages and Kundan 1895 Singh for performing parser validation of messages in earlier 1896 versions. 1898 The following individuals provided significant comments during the 1899 early phases of the development of this document: Jean-Francois Mule, 1900 Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, 1901 Matt Cannon, John Hearty, the whole MCI WorldCom IPOP Design team, 1902 Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny 1903 Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom 1904 Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI 1905 WorldCom, 3Com, Cisco, Lucent and Nortel. 1907 7 Informative References 1909 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1910 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1911 August 1998. 1913 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1914 2001. 1916 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1917 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1918 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1920 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1921 with Session Description Protocol (SDP)", RFC 3264, June 1922 2002. 1924 Authors' Addresses 1926 Robert J. Sparks (editor) 1927 dynamicsoft 1928 5100 Tennyson Parkway 1929 Suite 1200 1930 Plano, TX 75024 1932 EMail: rsparks@dynamicsoft.com 1934 Alan Hawrylyshen 1935 Jasomi Networks 1936 2033 Gateway Place 1937 Suite 500 1938 San Jose, CA 95110 1940 EMail: alan@jasomi.com 1941 Alan Johnston 1942 MCI 1943 100 South 4th Street 1944 St. Louis, MO 63102 1946 EMail: alan.johnston@mci.com 1948 Jonathan Rosenberg 1949 dynamicsoft 1950 600 Lanidex Plaza 1951 Parsippany, NJ 07052 1953 Phone: +1 973 952 5000 1954 EMail: jdrosen@dynamicsoft.com 1955 URI: http://www.jdrosen.net 1957 Henning Schulzrinne 1958 Columbia University 1959 Department of Computer Science 1960 1214 Amsterdam Ave. 1961 New York, NY 10027 1962 USA 1964 EMail: schulzrinne@cs.columbia.edu 1966 Appendix A. Bit-exact archive of each test message 1968 The following text block is an encoded, gzip compressed TAR archive 1969 of files that represent each of the example messages discussed in 1970 Section 3. 1972 To recover the compressed archive file intact, the text of this 1973 document may be passed as input to the following Perl script (the 1974 output should be redirected to a file or piped to "tar -xzvf -"). 1976 #!/usr/bin/perl 1977 use strict; 1978 my $bdata = ""; 1979 use MIME::Base64; 1980 while(<>) { 1981 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 1982 if ( m/^\s*[^\s]+\s*$/) { 1983 $bdata = $bdata . $_; 1984 } 1985 } 1986 } 1987 print decode_base64($bdata); 1989 Figure 58 1991 Alternatively, the base-64 encoded block can be edited by hand to 1992 remove document structure lines and fed as input to any base-64 1993 decoding utility. 1995 A.1 Encoded Reference Messages 1997 -- BEGIN MESSAGE ARCHIVE -- 1998 H4sIAHCZ9UACA+xdy3PbSHq3PZnHaqNNbc0tJ1g1XM9YItXobrwoUyONLe9o 1999 /BiXJXuqNpvytIiGCBIEKAAULafiJD5sZS+p3JPDVipVuW5uSW1V8i94/og9 2000 5JRjrukG+MCLJPTgw2P0DC2SaDy6+f1+/X1ff/31EdGJ16H1ik78azMqQARA 2001 lvE1wIqS+MuLhOA1VkWRkIgliX0vIlkUrwng2hxK1/OJKwjX3KbXIW7LG1dv 2002 2vF3tHz75HD/28cHgmd2ql2Pujv0JWl3LFpx3GPhYP/JJqyA1ZXnJqkOPm0+ 2003 u/dEaDiejyuDunWnXZWADLaOXGLXG7VXWuOX+OhBS292MYIIr648Ii/L9x23 2004 R1zdqwoKu+R9l50krH1FLWtD2LXYpWydumvCHf4kpHJcOWJHdiJ32N7yyXEN 2005 I4QhWl05dNjJ3xHfc+wN4bDhtInHzg2a4Vd6wfexpmyvrtwlllXev1cVjgYy 2006 7+kGYI9nQ1v3AAGa1oWogRq23QNAq+stm7I77dbrtONXBdLpWGad+KZjb3p6 2007 h13vgJ5UBaRB1kRN6Hfk6opVFVjzVlfejd+f9UX4o82QAKbhHwM5iX/2vsD/ 2008 QvHPEDfCP0dbVo0BjPmxOoNXnD8CwCIEMUwSAMqgFFFj7yqwIiZYZBICI4ju 2009 S7FHdMc2HIhMDEHzFBAPMFoxUBPZA8Sq7ypWZ4R/Bnw6y+F/Gv5FAKUk/jEq 2010 xv+5lP3Hz/cP964e/jb1A/hDNr5qfMBOawBR9AYyyIZRNra3bYZhBliIrCaG 2011 5bJHdcNuB1pEiF+RDbkawkL46GOUk6hukqGW9FZX7rFbVoX7rrkhAFH4htgC 2012 ZKIoiHIVAPa/sHdwyO7o2D6pM+65E2kjv75UibR0O6xIbb98eNahWUzVP/yQ 2013 2sd+g7VBEjnvnNZYPzi1doMpPxY9E6CmMFVCgQproMYaKOw/wUNilFZXvFp5 2014 daVeSx/wa4AzWbtGurrpCKzLRQUITw+fbO4+fyKwVkF+8NTUqSMgCJXhIcSe 2015 g9Rcv9MmnSoShYdP7r7PdPhe8r89U/bPYf+JKMn/oigX/D9v/S/TcIrbgLxE 2016 qbaexwbsJdk/KCMjkJWEGTjdCgwHpaDErcDw1KymJExAJvZM3kRpJ9aGqfYe 2017 K2NMvncV/6Z9CsRF+n8UpuyN8C8F+h/7U+B/2fS/ZuUCGiD7MUVZxLIIsZxS 2018 A+OQDCURNAgwPVsnLU9vEo/pgtxHQ7yR/TZW8xvakNLW1sbWxkZEgVv7xqF9 2019 71LToTFe2GIlS0VDU9W6c2pw4lgVTlyUDsd6/ZS63iLtP4AxSuFfUQr8L834 2020 r6TGfyVr/M879MdG/t1KMPhPG/FPetQxTzo0Mu4fVvpDf+4hP5B0PugryUF/ 2021 OLaL75lz6KhOmLG8UP1fBGJq/BdRMf7PpfRHTwECIHz7YNKQqqkJfIsIhq6d 2022 1DlQkiqRV/I8jxxRl584wmYghQCpWMUAApEN+GzwN0gLNSF1e1Q3vN0D3RjO 2023 uUhDFWCkfiRVk1D5EBna0cBcSFWjerfvpYJalgag5XLsjBxEwcW5ewiqUX7Z 2024 Pr+moKljVQVN3RShUvh8inIV/E9f+rO1/nL4fxQpxf8yLPh/3vpfDgPwxUWm 2025 ADCkvptUBOUo/YdCGDP8Vlee0pOu6TLStR2/YdrHB91Ox3F977BhehtZX+6Z 2026 foOyGz1xnZdn5cjp/AuTev26g/Pde86ufZY+ljFPGBvhDh8eCIZj6WVG5GUm 2027 PcFAMk0LTo4ty6JZHpnHdUdf6PwfkEScsv8wLvA/T/0PQw1rsoKAyNDo+9Tl 2028 ABOOXEpaAkOV4NI6NU85usZriCCp6UGkqQzODo1ivS9wxNMdA3WbECD21jYQ 2029 e4Iue9cwiIdoI3D8EE8zRzofwhpO6H13smgrNBiRRmzPMPua350s1S+sqAHY 2030 tHW7RVEmSscoeKyxKQ3vXfz964yx3QXP/ygySo//hf23PP7f+MitXtYjrPF5 2031 fvaPA8dNsHftY/csOcM+YJBQZGPKQo+ahLGF3kI5nMTx6fv0iF3m8zu4DJEE 2032 0bkn9jVWLuAXnuAYnq1nuM6EmrQXO/8jgYz5H1Dgfx7l6d4v9w8O954GeM0E 2033 fwo/HvG7rn2hid+R55ffLuGvHfhs7rWM58fNlus/6hHqPngwcPpmnxIlhoEs 2034 K0ARwU76OQfkAIVBsyMExC+/LmoKZCIIWdk57olRCtrq2i3b6dnBTX403uF+ 2035 n8FF4h/LSgr/cqH/v6/4V5HKBsnzYR5OxTzKwvydc4F++0c4J6QfWS49Waj/ 2036 T0RSCv8IFvO/S4L/fKp++mg/UAtKYhM1EUwtAlJXV/arQl/+Ytq8pnHb37At 2037 ZLUgQliEiWG6f7NknO9I9x9Bfby3AkpZjBWEK49x17EHHllL0SCSWH8NnjF+ 2038 PE+gDGZyn9VNQ7JLdpamMBhhjaNJ2omGkpwnUCajE5AKwnjr2Qc1X0FIjJDb 2039 8ilmuVKFevVZT/9Mn//HIMH/UJGK+N95+3/YyyuhXU6tJQwi3BVlqvS4UFIk 2040 j5YUmMV2gX61X4KMsU4p+8O6sE696PX6PlikpnhPWV0xq0Ion3xlCNACl3Cr 2041 2bIhcmz2AZRRZFkI5AtDcV63Dyfd7ImaCZP8qyvC0E9Vku9mLQXZYt+zztiy 2042 S7LYprVT9sfqsqZLJYRLSNy+ItYcS5pFWEBRzsv/cMH+fzll/0NFKfz/c9L/ 2043 S1hhunIJS6EN4NJj0/Nd4lbGWgNrpV+x6v1gapd6Ttetx5Td7eHy/qk1A/o3 2044 IIJNohvNWFBYKJqc9O2TnoOwewKRiXDT5XODdduCyHatlu3xuLD4BP3dqWsA 2045 IdBKxivPplZ0BNEQxkK0RzKXLcacB8QyiSeGU4KJCcG7Jfl+qioMw8OSVdPX 2046 REFFlKh45f4H1sl217IWO/+PU/a/BIv1/0tm/3MxKZcAKPM340zbsZX6nj1N 2047 g2H+jgnLgQciiTQIkK0bp62mTjyjdYJ62PHdE0B0z2CkQE714ZJgjDSVa38T 2048 DP9p036RQJ0RFFlTdlInbmfUGlfxYXW5/YWss92uay52/X8M/3KI/8L/N2/7 2049 L+nA+/Kp0/VprYTuJrihhPauJDcAwsz2UbPWhI1bdR/wx7i4gIEoB8ZimesN 2050 jWaZNCk6csuMG06ApvbKBulRtwFPyg1sSyP6YFTDBn842XosO0bZb9Byg6kx 2051 +SP+Zuk8K8zAolyumLbXNRZs/2FZTPK/qBT+v0Xz/4jj+ywZxG1Nn1PQMuYU 2052 KoGcTSVFq7/s9pw8qI2dRNCK3CjT8O+3qd9YqP4HQQr/PCVIgf85lJtMAKhL 2053 Pd+0j8uPmCQ4erD8TpIVVXtxe/37Ssm0dUr1W68DkhBfdO2u1yVW5dnT/def 2054 +075iN70ui794hemZ9/y103/s826S16dfbmxubV1u/oL019vEK8mbvSo6eo3 2055 b3eI91nPea2/8B2n8rnuUH5a2fS/2JkefjLw7IiTwjcrN0uyfPvF+ve3Xvf9 2056 VV/tPaz++mPh8TP255pwj3/6m75T6rztyXRz+U6L2uLr78M38Nb6i/Adul26 2057 WSmHN2p3bZ3YCeeXwU5/wkNLbt16vX77Batcqq398Ldvf//239/+1w9v3v7+ 2058 h3/44bdv/+Ptf64FCvOL4KqvxVvr37MrlysR5XeA457j6qVfPSjfrLAeuLXD 2059 P37/+ovPt+9Uf7259pd/8eVf/1UkjZYIIVIl4RwykFTWIQ9PpS8Zp3uMxL+m 2060 RKcuu3fp9voL1v3V//3Df//xX//tj3/3z//zT39Y3jUw77f+dwoljBbq/5MV 2061 Oa3/FfF/89b/njH976udfDGApuEf9yrjZnzXRQSQJEkiKzusaqVumQz48cA6 2062 drdap+HYdJsv9aszoioHDof+NVJPs9Umuu7WPC/pZx94INZFWQKDOL5otfjt 2063 YqQZCr+oiErWc0ZiiiR5qPhebU6YS2T1uwryZF3Q9Rc9/wdS/j8Ii/yfS2T/ 2064 5c2CeallQWrg8McT5wZCcY1niNI9w2zyLN5IH8WCSBhPCH/znDbNlyV0PNj7 2065 kcGG47aJn1ZucKDd3AmQy3pGuNOpt7sCX2NcW8MYrW2yL+9sDg4v7Pe3HPt4 2066 1gHAU/AvywpO2X9F/pclwn9gRO0LPIhLIAKvJ9ikTQXHEJju79I2veQfoeM6 2067 HBoMV2uZa3qrMhOUWDC+WDul7hkX36t8nRKrS7f4u+AmvJWzftW8Bmt5eONZ 2068 NCnrFdiclBl9j9mf70y/8dh5zh+AW7QhR5M2ecXMQSt4nJCw+cPO8ut0QDTU 2069 1GX8H0M8EMVGYPHORFZq4S0idwhk5Gr+GTx/8Ktb1POGTbjyN5HRezDYMC3c 2070 pezLs/n/OxA5c6grIJVHDoChsvAs7JnyQ1bzKl9ljrWq0O/48lVDuhz+rrO7 2071 fmfAGeWA+2vzuFPQpgwfIGMohOJm2mm6BozXeJ6uISZqZN0HJOvspupALVFn 2072 P32deEYwXifjOkqiTRnPA+VknYzrSIk6Wc+Dk3UyrpPo4+dCVUjVSfTyaVad 2073 ZD8LQvpeIHmddB1RS/1eGZXUdKWMWsr0n16Uc9SRctTBOeqgHHVgjjo5RFoE 2074 0+to06uo06vk6OQcfZyji3P0cI4OztO/U6qkrMp+4hy9NvTrDAzNeSl783iF 2075 TerT9dSY2QXolhfYs8N6H4JyLP/Yn3UA4NT8P0BK2v9KEf83V/s/O5HW1UT5 2076 aVATU/OG0UD/oQyKOxHnd3+Wcnq8iTTDbXpkcMUOfSbiGoKqApaECKyep5te 2077 Z7H53zPiP4r9v+ZTrmb/v7UQcmt3MnhglJFvStz/QBR56AE5qus7BrMwz7Im 2078 42QwJjUnp4XUWdmO/WLrvwH+Fx//j1Lz/5Jc5P9atP9/S7Dc6RQQQvulQcsa 2079 G8RUFZVfaUaerMAozMyemu+T4pQQSGeYDFR3qGPyrZeC4P6ea4fvVITdVrCo 2080 qD/5JyKmUsoY5YhVFcemLoJIm6RYiPNXLCYbFsumWBTlXeF/ToD+Qu0/BaXs 2081 P1zE/86T/7P1v7EZYC9lEKqqiOMc35dAo2WfMN2PcTxGQNOIzpd+kx5FOxk6 2082 oKhqSFWn5PsQp+mBSBvkeJ0Jyy+/+6hdtxad/wdIqfjPIv/Dctl/506mw1Mp 2083 QJSPJhy+a0OW24gvN4oQRSiqRsPmKqDjmg3SM3SHIAe7EnSQ6XqjHYJEiSlD 2084 IyMxBcyUJSqDdC0pCXifvvQ3OxYxbQ7rQ/bY9JYn2I7QI2eC7wh8PpR1TU9o 2085 E/tMcOo+9T2BuFTw+O4SHtV5pSMq8BMry2F8tk2vTfx6Y5YkMA3/SErGf2FQ 2086 xH8uo//nQnGdCEtQmrT9S1QGmzzzoPdSN6y8qdwLV8+V4B8uDv8KgBH8KyH+ 2087 C//PXMrjve8e7R1+/e295WAAOIUBxmrqCUV9MlOMT/43fUYYaRdR6bO0+aXw 2088 0bS7lm/O2AKYvv4XJ/CPmPZY4H8R/l8G6A5TXnOu/4DSNNwN5D0723LmfFC4 2089 3moE+SFJ9EVVU/k2UTsRJPVP0XKfAyeQ1tCnzd3TPAnxeBtmcCRlweTxfweZ 2090 sPg623yBKJOc0UhO/Awpj/o5GQuOncSGV55QodDLFlnsujVj708O/S+W/4vz 2091 P5RRkf9l0fN/47y/UMKX1QcD1w6KeoG5HMaW9UExcCG5EoY9NAwHAjnCgVCe 2092 xH7xJ5PQ5Ry95Yvs+sUT3YyJFEJzCxW0HZcSz7EXuv8PTNp/SC7W/8+nDPb/ 2093 ZP0vXHpvz6EwEYZivrOnybPzahqEPI/n2N3bi108Fzj+O6fU8uqLjf+DUhL/ 2094 EizwP1//r0M6lSNKO9XNzRHoURUBAK8mDFhNRfqgGHWEchhG+rDLgxPGMHYv 2095 DPxpWaMs3ShMITxuc+7+Ggwtz8wvLnISnXQd/4gsNv+3guUU/lHh/10e/T9Y 2096 ///IrQjfVASelyccRdOq/3auzX8zNrkSo3HAA5EMzIBJsf1aUmnPu+uVpFUl 2097 IIEctJA70AMtYuerK/ARu/SYdP3F7v+LZZDCPyj8v3MpM97/T1UQFBtNiESo 2098 TtrZbiiGMR/AANKMM8bu6ccH/JFzcoztv9v1G45rvgogXBUeO9/a9IHt9LzD 2099 hukd1Bs8BYnTISddWmY4IDUeoJFC+Y9SNWAdf0T0ur9Y/KOU/V+M/8uG/0no 2100 z8S+pqkIwYlLfobS10JYIp5rIUM/Ot0RQYX/J44WAU7a0BNJFVFltRF/oQl7 2101 Ecf2EJ282wF7VeI7HvxIw0jYL8D3TVgs/iU57f8r4j/fdfyr06AfCl4C+slZ 2102 3Svc2ufRGFfjNOi/A9v4XLh4zKAi7my3AJxq/6NU/AeWC/wvCf6zE7DDSQ42 2103 hKGnG854t33UVzDB+w+5NQ6bjWEgGJJVDWG+gETBoiYCxA5HiGFILkOphsgB 2104 HV07JbZ1gnq2a9m05xhN4mldM62bIMDau/eyY7o0cErMoYyfmoj3ME8hKmzR 2105 8NlqUAVQUyRNlhFURekSbsywp6zjReJfklL4l3Ex/z/X+T8JIOGAuqdmnQrP 2106 bHJKTIscWfSc8AcB/F+9eqmbfMdOr5ebAFIhVH0GoMTTmwZt9oa+ABgsDFER 2107 VhSIAAYQITG61CPOAUyybYd4FDgGjytt2PDEMRzCP0BCewa/lssTkPvuWXnX 2108 8KnLboE1BKCKVNYp/C//yO+jqUyl+Y64tmkf8wVo7LbOKXX9rkuFtX1beOI6 2109 xwyd3to7NK3g6Z2Fr/9SpGT8DwJi4f9bLv9/4OR7kTYCxq+dTMaG5kgJMDEZ 2110 QCiqfdcgDw7SGTfoqyu79Trt+P3VWbZz5OhnQ9/eOSYFRGlyTHhsUefS7AFw 2111 2YkAj7bNBef/AFI0/7cMiv0/51iS67+2WCNr3RIGEXCenxTGQt1xj8NoAAQx 2112 nBQPMJDLzPkAdTTcD8CfgOBG7ItOq+4p5bbZphtcjQ5LEBrOWutvts2XVN+I 2113 fOGZxzb7JlKXjerkmLID7MqRD4ZLjidRyvKvR/N4ryx2/YcCovs/hvhHxf7f 2114 cx//+5lKL7YEnAM7LuxMTXftMHYnYgVk3SRuCXjU1uOMMXQGBCvDqNmNEUVf 2115 gLvOCTtCTu2WRQzaap4gbHYx6pIeHSYGUrkOz0bQoTIwLVNp/1lSTd1OqwVI 2116 TMcNJBlla8QoYem4ju/UHau2lqSrslLm5xBuXKylzmuzqtZxzWsQMXXsyOE7 2117 zblntbUyK3u7X91H6i7Y3d1TFYDvMnzdFwEW1a92VaDcvb/GiahczlM11boR 2118 D/KLFJJ0QUlahiHsvPEuOBruHrZtWdKaXFScJyFwK9jvpLYWiEilo0RN/EOX 2119 hyhTt7xn1x09cA0cmTYD4KjKPdPrOJ4ZBh8Qn4lFo82+3xIM06LpK6+ugDef 2120 /P1HP7n9m69/83+r1z++8bs3n5yxr7o3rl8Xfwp+8tGH6z/74Maff3gN/HRU 2121 6frv3nz0Crz5QANvbvzL7z64cf3GjU+u/eO139747Np1sDqsd/1DdlonuMoH 2122 z/7ko09vPDsQPwU/5x8++ZRjwTQc1zaJ+HPwZ/zLjz/95IDY3zgeFX8G/vT/ 2123 27sWoKiuM8wCSoMaksBIWqA5ATsoZfHcx7J7F+mQajPGGFABdRInzd3du+xl 2124 l7vkPlhxdMJCGxv7cJLQPGwTZWqqpmOm1ZoaZxIf7aitzXTXpPQRoKZOE2lr 2125 M9pJY2gTe869u7BPwLRZGns+nvfcx577n/8/5z//+f//4JL8wlmIbUSVWgQr 2126 8fGcwmZ82CIo6lJBVkU3JqIQ8bhQu+Fni+dBhoI0RbEsQ1vuLZ5HoUPKFjmE 2127 jv9KZUrgp/FxTtEtyVIPgztjKWCalZUT/GYWDD6SHQxmnenLnl1wy+kxc/HD 2128 j1UPKEN/6TlaUrLtvRXUXFF7bu0eZ8GL55b9brR/6PUdV7u7fub4zd63G8+8 2129 v7XihaOVT1wcdjjXbfZ9PjC0Gc5prr946J/fOtj70OC/vmN9addI786Sm4KD 2130 9N79O3+Y//ANCy9s33rupe4jwqIVpwbPhrdtPO1t2sNsbazIzjFlmb4XHIXB 2131 t2AZeoOym3Pnw6JgqrfARCorzM1GCpJ+5Y2583OLGq6Wzi057Fm5r7jvmc7R 2132 LVeG73sgDIM78PmK3OBjMLi9p8h7Z3HRn/u7PtfTIhW2/H7gfEvRwIsD6m45 2133 o3zQa8pKYMMcRH3/h5+p23Ah76fD1R/8Y3TjQ3eVfuWN94bCZQcG935ty+Lz 2134 l2u+6+l/+ou9f8rf9YcPS19uPHEiu7jvthP7awsuHRspe/NC503VY0//bdXK 2135 Lcd+q1U5EWmXD4+MjbSeDK2+9GrLr94+3lz5iOO5Je/wh7XjHyxRR+UF1UdM 2136 1MHDJ/OOfvvgxtur9+25nwgMERgiMNcgMFSvaRD2ms6ioQhuzig9YqRzYgTc 2137 FfwRvHWcSDfkULEjIiydODOLKkBixUIrxdKQqYXWe2HFxNlcCnHGQvjGxVPr 2138 j+zTTDbbMurCpeCTxafhmomLCqgvwaUwf/anjIKcPHjj+P/Z2dlZPai5Jo5N 2139 DTDPqGZefPnCBNHKDfY8cDVrfunY8bfuCP388bFX+585wb0//G7lFfb7f71i 2140 PXT21E/W/j2/svXddzb1Mavl2+BubtHt5/ZY+p+fc7nR+9pThY6R3ZcXLjuz 2141 6v7XTh775f5fL5gtPP6Diw0VC2DrL+aee6Hvks3zx2cfPf/8+q8P3XxgYDuX 2142 detX39zYvcpSIe7Y+lR1x/LXH902PYXJbCbB2tcdVCRtH3cA+JT+X7H5/wz7 2143 D2TI+k+m7T+8j5ca2nnF3yFG0ls0ATRdSSw1Jtgy7+v0xBt97+HXm91N8jp+ 2144 javZDlCTxzp463wWZ8yNdfVa371pU7eZRpd5RAWgb9UjAEnrcKBpJZpBASNC 2145 xLiKsY9PuvWCOEcNVAuBN9Zn3X4/cKCmRc2Ga+334wNZ/5NiQmub7poOfhH0 2146 /Ho9ccd1IP949oq33lRmMP9XrTVB/lma+H/OzPrPR9v/4T/a9wHE8KBXbPew 2147 vNcl8Q+2ewNIpVd4xY0XftIYyaa1I8TUaYATbmpe2oLuoie7y8cr7S6PO9E/ 2148 ZmUzUJlJ7qM5G9QkF36j+Go23t3YtK4RqOwkN/OKC7oZQUrhlDOp+yvkOdHl 2149 lgQhxdKTKgeUmR7/LdCaNP6zRP4zLv+y0OFXBTOiR1vqRV8A0vmD6dyXhuOx 2150 qwbk4k33aT4o3n7v86MuxSwLil+TnUKqjoVjaQ7auFg9A/OzX3RqDMtZsJVe 2151 Etw4gtwj0wxrkafsSGjGxsUGl6e2618/EeOa5FWcHR9vDzCl/s8ySeu/RP4z 2152 K/8JflNGTKRd9at402QjNNJpMH4mskFEuFIi2SAyIf8d9AzLP0Mnyj9dS+b/ 2153 GcH04r9ExSHZke7KWDnaZmXGR2mPquKEMYFAoCaV2o8EM1GqdV7Tp/+e7k6P 2154 IPGq4DInpvGeGIxZDsYGeCSPxukTjlLTiQRdgldf7Sv8HunLzR2i6vnC/1u2 2155 cE2a8fxvFKSTxv9aK5H/jCCq2dMQgnpAV1UxoApYqqpoEHo59AoIB8O96E/o 2156 x6FDoQPh7bgsoSjcG/4GMIPQ0XBP9Fzo0GQ+kZwtQSZRb89ydHxHEWFKvBWk 2157 Fw/6XqadFuSA4HIrdzRPkkoubTAqRRnbzaXRWgSXZrgG0TSXyuWbm5aLTKow 2158 Ls6WlGHu2tLEcLa0rjOcbTFFW/8Xt5Um+IQgoIhS18zG/1BWS7L+RxH//0yv 2159 /3SJXYK3rcHp4UXZ7JJkZ9ykCSlvaHIoIRrwscphE7DPy5/6dlAHAEAdLPZE 2160 rEcdGGXDXwwjzct3y3inOWAH5SvAGr8iSA5BbgMbNmwoL4+4LhrZxlwyPtmQ 2161 FBOLf+En1wOc5L3dZZtiJcrg+BSLUPG9vl4lPdbHqeiZhyHk8EfFxBHhKxAl 2162 AFiMLtbJAfBQZ/hcjuuh0dGO4aASUT8VTLRGIXAnL7X5BNdygXfhuEMAJCHg 2163 NspAF+/TBPQoPOsWJQ2VJJ9sNdrEuH8dUl9bJU3ReN9afNoO6uqqq9FP3ZRj 2164 l57/ALdjxFVVDwNV4prfJ0c5IIA+p16vQLTELPnNegFqkC47iNJENxguBngO 2165 jqF0ini4i+OKSPMZFMKcAUDU51f0ttsAwA6s4yQ2noj+xfqETmCq1lZDWyw1 2166 aHTHz4o8qB7dFI1Ex2GbaPCzl6/W/GiqARRVFiXEXuWYvdIyFnoUorbB6/VR 2167 H1pUor+lUWcF20NcxiV14EFUd1jDXHsWuLQ5oNnMDOubBCR+7hme/9Mw2f5H 2168 9P9P0PrfZJa+No/iYqmYDjjCcu3YlOdzSx20n/axjGzRoGHuizPtIU1gkpW9 2169 ae3xia0IYqLtAJLUrwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE 2170 BNcB/g03l0QmABgBAA== 2171 -- END MESSAGE ARCHIVE -- 2173 Intellectual Property Statement 2175 The IETF takes no position regarding the validity or scope of any 2176 Intellectual Property Rights or other rights that might be claimed to 2177 pertain to the implementation or use of the technology described in 2178 this document or the extent to which any license under such rights 2179 might or might not be available; nor does it represent that it has 2180 made any independent effort to identify any such rights. Information 2181 on the procedures with respect to rights in RFC documents can be 2182 found in BCP 78 and BCP 79. 2184 Copies of IPR disclosures made to the IETF Secretariat and any 2185 assurances of licenses to be made available, or the result of an 2186 attempt made to obtain a general license or permission for the use of 2187 such proprietary rights by implementers or users of this 2188 specification can be obtained from the IETF on-line IPR repository at 2189 http://www.ietf.org/ipr. 2191 The IETF invites any interested party to bring to its attention any 2192 copyrights, patents or patent applications, or other proprietary 2193 rights that may cover technology that may be required to implement 2194 this standard. Please address the information to the IETF at 2195 ietf-ipr@ietf.org. 2197 Disclaimer of Validity 2199 This document and the information contained herein are provided on an 2200 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2201 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2202 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2203 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2204 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2205 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2207 Copyright Statement 2209 Copyright (C) The Internet Society (2004). This document is subject 2210 to the rights, licenses and restrictions contained in BCP 78, and 2211 except as set forth therein, the authors retain all their rights. 2213 Acknowledgment 2215 Funding for the RFC Editor function is currently provided by the 2216 Internet Society.