idnits 2.17.1 draft-ietf-sipping-torture-tests-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == 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 1330 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 (January 21, 2004) is 7373 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: 2 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Sparks, Ed. 3 Internet-Draft dynamicsoft 4 Expires: July 21, 2004 A. Hawrylyshen 5 Jasomi Networks 6 A. Johnston 7 MCI 8 J. Rosenberg 9 dynamicsoft 10 H. Schulzrinne 11 Columbia University 12 January 21, 2004 14 Session Initiation Protocol Torture Test Messages 15 draft-ietf-sipping-torture-tests-03 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on July 21, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This informational document gives examples of Session Initiation 46 Protocol (SIP) test messages designed to exercise and "torture" a 47 parser. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Document Conventions . . . . . . . . . . . . . . . . . . 4 53 2.1 Representing Long Lines . . . . . . . . . . . . . . . . 4 54 2.2 Representing Non-printable Characters . . . . . . . . . 5 55 2.3 Representing Long Repeating Strings . . . . . . . . . . 5 56 3. SIP Test Messages . . . . . . . . . . . . . . . . . . . 6 57 3.1 Parser tests (syntax) . . . . . . . . . . . . . . . . . 6 58 3.1.1 Valid messages . . . . . . . . . . . . . . . . . . . . . 6 59 3.1.1.1 A short tortuous INVITE . . . . . . . . . . . . . . . . 6 60 3.1.1.2 Wide range of valid characters . . . . . . . . . . . . . 8 61 3.1.1.3 Valid use of the % escaping mechanism . . . . . . . . . 9 62 3.1.1.4 Escaped nulls in URIs . . . . . . . . . . . . . . . . . 10 63 3.1.1.5 Use of % when it is not an escape . . . . . . . . . . . 11 64 3.1.1.6 Message with no LWS between display name and < . . . . . 12 65 3.1.1.7 Long values in header fields . . . . . . . . . . . . . . 12 66 3.1.1.8 Extra trailing octets in a UDP datagram . . . . . . . . 14 67 3.1.1.9 Semicolon separated parameters in URI user part . . . . 15 68 3.1.1.10 Varied and unknown transport types . . . . . . . . . . . 15 69 3.1.1.11 S/MIME signed message . . . . . . . . . . . . . . . . . 16 70 3.1.1.12 Unusual reason phrase . . . . . . . . . . . . . . . . . 19 71 3.1.1.13 Empty reason phrase . . . . . . . . . . . . . . . . . . 20 72 3.1.2 Invalid messages . . . . . . . . . . . . . . . . . . . . 20 73 3.1.2.1 Extraneous header field separators . . . . . . . . . . . 20 74 3.1.2.2 Content length larger than message . . . . . . . . . . . 21 75 3.1.2.3 Negative Content-Length . . . . . . . . . . . . . . . . 22 76 3.1.2.4 Request scalar fields with overlarge values . . . . . . 22 77 3.1.2.5 Response scalar fields with overlarge values . . . . . . 23 78 3.1.2.6 Unterminated quoted string in display-name . . . . . . . 24 79 3.1.2.7 <> enclosing Request-URI . . . . . . . . . . . . . . . . 25 80 3.1.2.8 Malformed SIP Request-URI (embedded LWS) . . . . . . . . 25 81 3.1.2.9 Multiple SP separating Request-Line elements . . . . . . 26 82 3.1.2.10 SP characters at end of Request-Line . . . . . . . . . . 27 83 3.1.2.11 Escaped headers in SIP Request-URI . . . . . . . . . . . 27 84 3.1.2.12 Invalid timezone in Date header field . . . . . . . . . 28 85 3.1.2.13 Failure to enclose name-addr URI in <> . . . . . . . . . 29 86 3.1.2.14 Spaces within addr-spec . . . . . . . . . . . . . . . . 29 87 3.1.2.15 Non-token characters in display-name . . . . . . . . . . 30 88 3.1.2.16 Unknown protocol version . . . . . . . . . . . . . . . . 30 89 3.1.2.17 Start line and CSeq method mismatch . . . . . . . . . . 31 90 3.1.2.18 Unknown Method with CSeq method mismatch . . . . . . . . 31 91 3.1.2.19 Overlarge response code . . . . . . . . . . . . . . . . 32 92 3.2 Transaction layer semantics . . . . . . . . . . . . . . 32 93 3.2.1 Missing transaction identifier . . . . . . . . . . . . . 32 94 3.3 Application layer semantics . . . . . . . . . . . . . . 33 95 3.3.1 Missing Required Header Fields . . . . . . . . . . . . . 33 96 3.3.2 Request-URI with unknown scheme . . . . . . . . . . . . 33 97 3.3.3 Request-URI with known but atypical scheme . . . . . . . 34 98 3.3.4 Unknown URI schemes in header fields . . . . . . . . . . 34 99 3.3.5 Proxy-Require and Require . . . . . . . . . . . . . . . 35 100 3.3.6 Unknown Content-Type . . . . . . . . . . . . . . . . . . 35 101 3.3.7 Unknown authorization scheme . . . . . . . . . . . . . . 36 102 3.3.8 Multiple values in single value required fields . . . . 37 103 3.3.9 Multiple Content-Length values . . . . . . . . . . . . . 38 104 3.3.10 200 OK Response with broadcast Via header field value . 38 105 3.3.11 Max-Forwards of zero . . . . . . . . . . . . . . . . . . 39 106 3.3.12 REGISTER with a contact header parameter . . . . . . . . 39 107 3.3.13 REGISTER with a url parameter . . . . . . . . . . . . . 40 108 3.3.14 REGISTER with a url escaped header . . . . . . . . . . . 40 109 3.3.15 Unacceptable Accept offering . . . . . . . . . . . . . . 41 110 3.4 Backward compatibility . . . . . . . . . . . . . . . . . 42 111 3.4.1 INVITE with RFC2543 syntax . . . . . . . . . . . . . . . 42 112 4. Security Considerations . . . . . . . . . . . . . . . . 42 113 5. Open Issues and Remaining Work . . . . . . . . . . . . . 43 114 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . 43 115 Informative References . . . . . . . . . . . . . . . . . 44 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . 44 117 A. Bit-exact archive of each test message . . . . . . . . . 45 118 A.1 Encoded Reference Messages . . . . . . . . . . . . . . . 46 119 Intellectual Property and Copyright Statements . . . . . 50 121 1. Overview 123 This document is informational, and is NOT NORMATIVE on any aspect of 124 SIP. 126 This document contains test messages based on the current version 127 (2.0) of the Session Initiation Protocol as defined in [RFC3261]. 128 Some messages exercise SIP's use of SDP as described in [RFC3264]. 130 These messages were developed and refined at the SIPIt 131 interoperability test events. 133 The test messages are organized into several sections. Some stress 134 only a SIP parser and others stress both the parser and the 135 application above it. Some messages are valid, and some are not. Each 136 example clearly calls out what makes any invalid messages incorrect. 138 This document does not attempt to catalog every way to make an 139 invalid message, nor does it attempt to be comprehensive in exploring 140 unusual, but valid, messages. Instead, it tries to focus on areas 141 that have caused interoperability problems or have particularly 142 unfavorable characteristics if they are handled improperly. This 143 document is a seed for a test plan, not a test plan in itself. 145 The messages are presented in the text using a set of markup 146 conventions to avoid ambiguity and meet Internet-Draft layout 147 requirements. To resolve any remaining ambiguity, a bit-accurate 148 version of each message is encapsulated in an appendix. 150 2. Document Conventions 152 This document contains many example SIP messages. Although SIP is a 153 text-based protocol, many of these examples cannot be unambiguously 154 rendered without additional markup due to the constraints placed on 155 the formatting of RFCs. This document defines and uses the markup 156 defined in this section to remove that ambiguity. This markup uses 157 the start and end tag conventions of XML, but does not define any XML 158 document type. 160 The appendix contains an encoded binary form of all the messages and 161 the algorithm needed to decode them into files. 163 2.1 Representing Long Lines 165 Several of these examples contain unfolded lines longer than 72 166 characters. These are captured between tags. The single 167 unfolded line is reconstructed by directly concatenating all lines 168 appearing between the tags (discarding any line-feeds or carriage 169 returns). There will be no whitespace at the end of lines. Any 170 whitespace appearing at a fold-point will appear at the beginning of 171 a line. 173 The following represent the same string of bits: 175 Header-name: first value, reallylongsecondvalue, third value 177 178 Header-name: first value, 179 reallylongsecondvalue 180 , third value 181 183 184 Header-name: first value, 185 reallylong 186 second 187 value, 188 third value 189 191 Note that this is NOT SIP header line folding where different 192 strings of bits have equivalent meaning. 194 2.2 Representing Non-printable Characters 196 Several examples contain binary message bodies or header field values 197 containing non-ascii range UTF-8 encoded characters. These are 198 rendered here as a pair of hexadecimal digits per octet between tags. This rendering applies even inside quoted-strings. 201 The following represent the same string of bits: 203 Header-name: value one 205 Header-name: value206F6Ee 207 The following is a Subject header field containing the euro symbol: 209 Subject: E282AC 211 2.3 Representing Long Repeating Strings 213 Several examples contain very large data values created with 214 repeating bit strings. Those will be rendered here using value. As with this rendering 216 applies even inside quoted-strings. 218 For example, the value "abcabcabc" can be rendered as abc. A display name of "1000000 bottles of beer" 220 could be rendered as 222 To: "130 bottles of beer" 223 225 and a Max-Forwards header field with a value of one google will be 226 rendered here as 228 Max-Forwards: 10 230 3. SIP Test Messages 232 3.1 Parser tests (syntax) 234 3.1.1 Valid messages 236 3.1.1.1 A short tortuous INVITE 238 This short, relatively human-readable message contains: 240 o line folding all over 242 o escaped characters within quotes 244 o an empty subject 246 o LWS between colons, semicolons, header field values, and other 247 fields 249 o both comma separated and separate listing of header field values 251 o mix or short and long form for the same header field name 253 o unknown header fields 255 o unknown header field with a value that would be syntactically 256 invalid if it were defined in terms of generic-param 258 o unusual header field ordering 260 o unusual header field name character case 261 o unknown parameters of a known header field 263 o uri parameter with no value 265 o header parameter with no value 267 o integer fields (Max-Forwards and CSeq) with leading zeros 269 All elements should treat this as a well-formed request. 271 The UnknownHeaderWithUnusualValue header field deserves special 272 attention. If this header field were defined in terms of comma 273 separated values with semicolon separated parameters (as many of the 274 existing defined header fields), this would be invalid. However, 275 since the receiving element does not know the definition of the 276 syntax for this field, it must parse it as a header-value. Proxies 277 would forward this header field unchanged. Endpoints would ignore the 278 header field. 280 Message Details : wsinv 282 INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 283 TO : 284 sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n 285 from : "J Rosenberg \\\"" 286 ; 287 tag = 98asjd8 288 MaX-fOrWaRdS: 0068 289 Call-ID: 0ha0isndaksdj@192.0.2.1 290 Content-Length : 151 291 cseq: 0009 292 INVITE 293 Via : SIP / 2.0 294 /UDP 295 192.0.2.2;branch=390skdjuw 296 s : 297 NewFangledHeader: newfangled value 298 continued newfangled value 299 UnknownHeaderWithUnusualValue: ;;,,;;,; 300 Content-Type: application/sdp 301 Route: 302 303 v: SIP / 2.0 / TCP spindle.example.com ; 304 branch = z9hG4bK9ikj8 , 305 SIP / 2.0 / UDP 192.168.255.111 ; branch= 306 z9hG4bK30239 307 m:"Quoted string \"\"" ; newparam = 308 newvalue ; 310 secondparam ; q = 0.33 312 v=0 313 o=mhandley 29739 7272939 IN IP4 192.0.2.3 314 s=- 315 c=IN IP4 192.0.2.4 316 t=0 0 317 m=audio 492170 RTP/AVP 0 12 318 m=video 3227 RTP/AVP 31 319 a=rtpmap:31 LPC 321 3.1.1.2 Wide range of valid characters 323 This message exercises a wider range of characters in several key 324 syntactic elements than implementations usually see. Of particular 325 note: 327 o The Method contains non-alpha characters from token. Note that % 328 is not an escape character for this field. A method of IN%56ITE is 329 an unknown method. It is not the same as a method of INVITE 331 o The Request-URI contain unusual, but legal, characters 333 o A branch parameter contains all non-alphanum characters from token 335 o The To header field value's quoted-string contains quoted-pair 336 expansions, including a quoted NULL character 338 o The name part of name-addr in the From header field value contains 339 multiple tokens (instead of a quoted string) with all non-alphanum 340 characters from the token production rule. That value also has an 341 unknown header parameter whose name contains the non-alphanum 342 token characters and whose value is a non-ascii range UTF-8 343 encoded string. The tag parameter on this value contains the 344 non-alphanum token characters 346 o The Call-ID header field value contains the non-alphanum 347 characters from word. Notice that in this production: 349 * % is not an escape character. (It is only an escape character 350 in productions matching the rule "escaped") 352 * " does not start a quoted-string. None of ',` or " imply that 353 there will be a matching symbol later in the string 355 * The characters []{}()<> do not have any grouping semantics. 356 They are not required to appear in balanced pairs 358 o There is an unknown header field (matching extension-header) with 359 non-alphanum token characters in its name and a UTF8-NONASCII 360 value 362 If this unusual URI has been defined at a proxy, the proxy will 363 forward this request normally. Otherwise a proxy will generate a 404. 364 Endpoints will generate a 501 listing the methods they understand in 365 an Allow header field. 367 Message Details : intmeth 369 370 !interesting-Method0123456789_*+`.%indeed'~ 371 sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;* 372 :&it+has=1,weird!*pas$wo~d_too.(doesn't-it) 373 @example.com SIP/2.0 374 375 Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~ 376 377 To: "BEL:\07 NUL:\00 DEL:\7F" 378 380 381 382 From: token1~` token2'+_ token3*%!.- 383 ;fromParam''~+*_!.-%= 384 "D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9" 385 ;tag=_token~1'+`*%!-. 386 387 Call-ID: word%ZK-!.*_+'@word`~)(><:\/"][?}{ 388 CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~ 389 Max-Forwards: 255 390 391 extensionHeader-!.%*+_`'~: 392 EFBBBFE5A4A7E5819CE99BBB 393 394 Content-Length: 0 396 3.1.1.3 Valid use of the % escaping mechanism 398 This INVITE exercises the % HEX HEX escaping mechanism in several 399 places. The request is syntactically valid. Interesting features 400 include: 402 o The request-URI has sips:user@example.com embedded in its 403 userpart. What that might mean to example.net is beyond the scope 404 of this document. 406 o The From and To URIs have escaped characters in their userparts. 408 o The Contact URI has escaped characters in the URI parameters. Note 409 that the "name" uri-parameter has a value of "value%41" which is 410 NOT equivalent to "valueA". Per [RFC2396], unescaping URI 411 components is never performed recursively. 413 A parser must accept this as a well-formed message. The application 414 using the message must treat the % HEX HEX expansions as equivalent 415 to the character being encoded. The application must not try to 416 interpret % as an escape character in those places where % HEX HEX 417 ("escaped" in the grammar) is not a valid part of the construction. 418 In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, 419 SIPS-URI, and Reason-Phrase 421 Message Details : esc01 423 INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0 424 To: sip:%75se%72@example.com 425 From: ;tag=938 426 Max-Forwards: 87 427 i: 239409asdfakjkn23onasd0-3234 428 CSeq: 234234 INVITE 429 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw 430 C: application/sdp 431 Contact: 432 433 Content-Length: 151 435 v=0 436 o=mhandley 29739 7272939 IN IP4 192.0.2.1 437 s=- 438 c=IN IP4 192.0.2.1 439 t=0 0 440 m=audio 492170 RTP/AVP 0 12 441 m=video 3227 RTP/AVP 31 442 a=rtpmap:31 LPC 444 3.1.1.4 Escaped nulls in URIs 446 This register request contains several URIs with nulls in the 447 userpart. The message is well formed - parsers must accept this 448 message. Implementations must take special care when unescaping the 449 AOR in this request to not prematurely shorten the username. This 450 request registers two distinct contact URIs. 452 Message Details : escnull 454 REGISTER sip:example.com SIP/2.0 455 To: sip:null-%00-null@example.com 456 From: sip:null-%00-null@example.com;tag=839923423 457 Max-Forwards: 70 458 Call-ID: 39203ndfvkjdasfkq3w4otrq0adsfdfnavd 459 CSeq: 14398234 REGISTER 460 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 461 Contact: 462 Contact: 463 L:0 465 3.1.1.5 Use of % when it is not an escape 467 Most of the places % can appear in a SIP message, it is not an escape 468 character. This can surprise the unwary implementor. The following 469 well-formed request has these properties: 471 o The request method is unknown. It is NOT equivalent to REGISTER 473 o The display-name portion of the To and From header fields is 474 "%Z%45". Note that this is not the same as %ZE 476 o This message has two Contact header field values, not three. 477 %lt;sip:alias2@host2.example.com%gt; is a C%6Fntact header field 478 value 480 A parser should accept this message as well formed. A proxy would 481 forward or reject the message depending on what the Request-URI meant 482 to it. An endpoint would reject this message with a 501. 484 Message Details : esc02 486 RE%47IST%45R sip:registrar.example.com SIP/2.0 487 To: "%Z%45" 488 From: "%Z%45" ;tag=f232jadfj23 489 Call-ID: asdfnqwo34rq23i34jrjasdcnl23nrlknsdf 490 Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234 491 CSeq: 29344 RE%47IST%45R 492 Max-Forwards: 70 493 Contact: 494 C%6Fntact: 495 Contact: 496 l: 0 498 3.1.1.6 Message with no LWS between display name and < 500 This OPTIONS request is not valid per the grammar in RFC 3261. since 501 there is no LWS between the quoted string in the display name and < 502 in the From header field value. This has been identified as a 503 specification bug that will be removed when RFC 3261 is revised. 504 Elements should accept this request as well formed. 506 Message Details : lwsdisp 508 OPTIONS sip:user@example.com SIP/2.0 509 To: sip:user@example.com 510 From: "caller";tag=323 511 Max-Forwards: 70 512 Call-ID: 1234abcd@funky.example.com 513 CSeq: 60 OPTIONS 514 Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw 515 l: 0 517 3.1.1.7 Long values in header fields 519 This well-formed request contains header fields with many values and 520 values that are very long. Features include: 522 o The To header field has a long display name, and long uri 523 parameter names and values 525 o The From header field has long header parameter names and values, 526 in particular a very long tag 528 o The Call-ID is one long token 530 Message Details : longreq 532 INVITE sip:user@example.com SIP/2.0 533 534 To: "I have a user name of 535 extreme proportion" 536 longvalue; 538 longparamname=shortvalue; 539 verylongParameterNameWithNoValue> 540 541 542 F: sip: 544 amazinglylongcallername@example.net 545 ;tag=12982424 546 ;unknownheaderparamname= 547 unknowheaderparamvalue 548 ;unknownValuelessparamname 549 550 Call-ID: onereallylongcallid 551 CSeq: 3882340 INVITE 552 553 Unknown-Long-Name: 554 unknown-long-value; 555 unknown-long-parameter-name = 556 unknown-long-parameter-value 557 558 Via: SIP/2.0/TCP sip33.example.com 559 v: SIP/2.0/TCP sip32.example.com 560 V: SIP/2.0/TCP sip31.example.com 561 Via: SIP/2.0/TCP sip30.example.com 562 ViA: SIP/2.0/TCP sip29.example.com 563 VIa: SIP/2.0/TCP sip28.example.com 564 VIA: SIP/2.0/TCP sip27.example.com 565 via: SIP/2.0/TCP sip26.example.com 566 viA: SIP/2.0/TCP sip25.example.com 567 vIa: SIP/2.0/TCP sip24.example.com 568 vIA: SIP/2.0/TCP sip23.example.com 569 V : SIP/2.0/TCP sip22.example.com 570 v : SIP/2.0/TCP sip21.example.com 571 V : SIP/2.0/TCP sip20.example.com 572 v : SIP/2.0/TCP sip19.example.com 573 Via : SIP/2.0/TCP sip18.example.com 574 Via : SIP/2.0/TCP sip17.example.com 575 Via: SIP/2.0/TCP sip16.example.com 576 Via: SIP/2.0/TCP sip15.example.com 577 Via: SIP/2.0/TCP sip14.example.com 578 Via: SIP/2.0/TCP sip13.example.com 579 Via: SIP/2.0/TCP sip12.example.com 580 Via: SIP/2.0/TCP sip11.example.com 581 Via: SIP/2.0/TCP sip10.example.com 582 Via: SIP/2.0/TCP sip9.example.com 583 Via: SIP/2.0/TCP sip8.example.com 584 Via: SIP/2.0/TCP sip7.example.com 585 Via: SIP/2.0/TCP sip6.example.com 586 Via: SIP/2.0/TCP sip5.example.com 587 Via: SIP/2.0/TCP sip4.example.com 588 Via: SIP/2.0/TCP sip3.example.com 589 Via: SIP/2.0/TCP sip2.example.com 590 Via: SIP/2.0/TCP sip1.example.com 591 592 Via: SIP/2.0/TCP 593 host.example.com;received=192.0.2.5; 594 branch=verylongbranchvalue 595 596 Max-Forwards: 70 597 598 Contact: amazinglylongcallername 600 @host5.example.net> 601 602 Content-Type: application/sdp 603 l: 151 605 v=0 606 o=mhandley 29739 7272939 IN IP4 192.0.2.1 607 s=- 608 c=IN IP4 192.0.2.1 609 t=0 0 610 m=audio 492170 RTP/AVP 0 12 611 m=video 3227 RTP/AVP 31 612 a=rtpmap:31 LPC 614 3.1.1.8 Extra trailing octets in a UDP datagram 616 This message contains a single SIP REGISTER request, which ostensibly 617 arrived over UDP in a single datagram. The packet contained extra 618 octets after the body (which in this case has zero length). Those 619 octets happen to look like a SIP INVITE request, but (per section 620 18.3 of [RFC3261]) they are just spurious noise that must be ignored. 622 A SIP element receiving this datagram would handle the REGISTER 623 request normally and ignore the extra bits that look like an INVITE 624 request. If the element is a proxy choosing to forward the REGISTER, 625 the INVITE octets would not appear in the forwarded request. 627 Message Details : dblreq 629 REGISTER sip:example.com SIP/2.0 630 To: sip:j.user@example.com 631 From: sip:j.user@example.com;tag=43251j3j324 632 Max-Forwards: 8 633 I: 0ha0isndaksdj99sdfafnl3lk233412 634 Contact: sip:j.user@host.example.com 635 CSeq: 8 REGISTER 636 Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492 637 Content-Length: 0 638 INVITE sip:joe@example.com SIP/2.0 639 t: sip:joe@example.com 640 From: sip:caller@example.net;tag=141334 641 Max-Forwards: 8 642 Call-ID: 0ha0isnda977644900765@192.0.2.15 643 CSeq: 8 INVITE 644 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234 645 Content-Type: application/sdp 646 Content-Length: 151 648 v=0 649 o=mhandley 29739 7272939 IN IP4 192.0.2.15 650 s=- 651 c=IN IP4 192.0.2.15 652 t=0 0 653 m=audio 492170 RTP/AVP 0 12 654 m =video 3227 RTP/AVP 31 655 a=rtpmap:31 LPC 657 3.1.1.9 Semicolon separated parameters in URI user part 659 This request has a semicolon-separated parameter contained in the 660 "user" part of the Request-URI (whose value contains an escaped @ 661 symbol). Receiving elements will accept this as a well formed 662 message. The Request-URI will parse such that the user part is 663 "user;par=u@example.net". 665 Message Details : semiuri 667 OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0 668 To: sip:j_user@example.com 669 From: sip:caller@example.org;tag=33242 670 Max-Forwards: 3 671 Call-ID: 0ha0isndaksdj 672 CSeq: 8 OPTIONS 673 Accept: application/sdp, application/pkcs7-mime, 674 multipart/mixed, multipart/signed, 675 message/sip, message/sipfrag 676 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw 677 l: 0 679 3.1.1.10 Varied and unknown transport types 681 This request contains Via header field values with all known 682 transport types and exercises the transport extension mechanism. 683 Parsers must accept this message as well formed. Elements receiving 684 this message would process it exactly as if the 2nd and subsequent 685 header field values specified UDP (or other transport). 687 Message Details : transports 689 OPTIONS sip:user@example.com SIP/2.0 690 To: sip:user@example.com 691 From: ;tag=323 692 Max-Forwards: 70 693 Call-ID: nfc9ehfdfaekijh4akdnaqjkwendsasfdj 694 Accept: application/sdp 695 CSeq: 60 OPTIONS 696 Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw 697 Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf 698 Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj 699 Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en 700 Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee 701 l: 0 703 3.1.1.11 S/MIME signed message 705 This is a signed INVITE request. The signature is binary encoded. The 706 body contains null (0x00) characters. Receivers must take care to 707 properly frame the received message. 709 Parsers must accept this message as well formed, even if the 710 application above the parser does not support multipart/signed. 712 Message Details : smime01 714 INVITE sip:receiver@example.com SIP/2.0 715 Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3 716 To: 717 From: ;tag=2390234seiu3 718 Call-ID: afnkjeriuoqeiuavnklafekjq34iu43uawe 719 CSeq: 282398492 INVITE 720 Max-Forwards: 70 721 Contact: 722 Content-Length: 3134 723 Content-Type: multipart/signed; 724 protocol="application/pkcs-7-signature"; 725 micalg=sha1; 726 boundary="----34CF59C076641DD0879594444157C7EB" 728 ------34CF59C076641DD0879594444157C7EB 729 Content-Type: message/sip 731 INVITE sip:receiver@example.com SIP/2.0 732 Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3 733 To: 734 From: ;tag=2390234seiu3 735 Call-ID: afnkjeriuoqeiuavnklafekjq34iu43uawe 736 CSeq: 282398492 INVITE 737 Max-Forwards: 70 738 Contact: 739 Accept: application/sdp, application/pkcs7-mime, 740 multipart/mixed, multipart/signed, 741 message/sip, message/sipfrag 742 Content-Type: application/sdp 743 Content-Length: 149 745 v=0 746 o=sender 29739 7272939 IN IP4 192.0.2.1 747 s=- 748 c=IN IP4 192.0.2.1 749 t=0 0 750 m=audio 492170 RTP/AVP 0 12 751 m=video 3227 RTP/AVP 31 752 a=rtpmap:31 LPC 754 ------34CF59C076641DD0879594444157C7EB 755 Content-Type: application/pkcs-7-signature; name="smime.p7s" 756 Content-Transfer-Encoding: binary 757 Content-Disposition: attachment; filename="smime.p7s" 759 3082088806092A86 760 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 761 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 762 90008902240001300D06092A864886F70D01010505003070310B300906035504 763 0613025553311330110603550408130A43616C69666F726E69613111300F0603 764 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 765 060355040B135369706974546573744365727469666963617465417574686F72 766 697479301E170D3033313032313134343332355A170D31333130313831343433 767 32355A3062310B3009060355040613025553311330110603550408130A43616C 768 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 769 040A13057369706974311B30190603550403141273656E646572406578616D70 770 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 771 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 772 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 773 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 774 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 775 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 776 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 777 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 778 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 779 310B3009060355040613025553311330110603550408130A43616C69666F726E 780 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 781 6970697431293027060355040B13536970697454657374436572746966696361 782 7465417574686F72697479820100300D06092A864886F70D0101050500038181 783 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 784 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 785 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 786 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 787 5E30820339308202A2A00302010202080090008902240001300D06092A864886 788 F70D01010505003070310B300906035504061302555331133011060355040813 789 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 790 0C060355040A1305736970697431293027060355040B13536970697454657374 791 4365727469666963617465417574686F72697479301E170D3033313032313134 792 343332355A170D3133313031383134343332355A3062310B3009060355040613 793 025553311330110603550408130A43616C69666F726E69613111300F06035504 794 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 795 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 796 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 797 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 798 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 799 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 800 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 801 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 802 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 803 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 804 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 805 30110603550408130A43616C69666F726E69613111300F060355040713085361 806 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 807 69706974546573744365727469666963617465417574686F7269747982010030 808 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 809 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 810 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 811 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 812 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 813 70310B3009060355040613025553311330110603550408130A43616C69666F72 814 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 815 736970697431293027060355040B135369706974546573744365727469666963 816 617465417574686F7269747902080090008902240001300906052B0E03021A05 817 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 818 06092A864886F70D010905310F170D3033313032323135323930325A30230609 819 2A864886F70D010904311604144A2FD5856B6006413209FA56A0C1D85179DBCB 820 5F305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 821 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 822 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 823 01010500048180C1C3193CF4A8BE1278B5529ACFA1C51DDEDECF0D3DC4C18FC5 824 9A5B120E6D559F4953A3C3C7C97B4EAD8388F1508F7AD2FC71CC7B9ED2844789 825 60A3ECF87984E25A15B4AB63F150C30570B6315A2327E381EE11E866DC1405DA 826 29E74CC20201816F1516DD893332D9A8E26FBAEC237C494F3EFAEF4EBCD2122C 827 DE7D57DECD------34CF59C076641DD0879594444157C7EB-- 829 3.1.1.12 Unusual reason phrase 831 This 200 response contains a reason phrase other than "OK". The 832 reason phrase is intended for human consumption, and may contain any 833 string produced by 835 Reason-Phrase = *(reserved / unreserved / escaped 836 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) 838 This particular response contains unreserved and non-ASCII UTF-8 839 characters.This response is well formed. A parser must accept this 840 message. 842 Message Details : unreason 844 845 SIP/2.0 200 = 2**3 * 5**2 D0BDD0BE20D181D182 846 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4 847 D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 848 BED0B5 849 850 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 851 Call-ID: 0384840201234ksdfak3j2erwedfsASdf 852 CSeq: 35 INVITE 853 From: sip:user@example.com;tag=11141343 854 To: sip:user@example.edu;tag=2229 855 Content-Length: 159 856 Content-Type: application/sdp 857 Contact: 859 v=0 860 o=mhandley 29739 7272939 IN IP4 192.0.2.198 861 s=- 862 c=IN IP4 192.0.2.198/127 863 t=0 0 864 m=audio 492170 RTP/AVP 0 12 865 m=video 3227 RTP/AVP 31 866 a=rtpmap:31 LPC 868 3.1.1.13 Empty reason phrase 870 This well formed response contains no reason phrase. A parser must 871 accept this message. The space character after the reason code is 872 required. If it were not present, this message could be rejected as 873 invalid (a liberal receiver would accept it anyway). 875 Message Details : noreason 877 SIP/2.0 10020 878 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 879 Call-ID: adsn2309jasndj203insdf99223ndf 880 CSeq: 35 INVITE 881 From: ;tag=39ansfi3 882 To: ;tag=902jndnke3 883 Content-Length: 0 884 Contact: 886 3.1.2 Invalid messages 888 This section contains several invalid messages reflecting errors seen 889 at interoperability events and exploring important edge conditions 890 that can be induced through malformed messages. This section does not 891 attempt to be a comprehensive list of all types of invalid messages. 893 3.1.2.1 Extraneous header field separators 895 The Via and header field of this request contains contain additional 896 semicolons and commas without parameters or values. The Contact 897 header field contains additional semicolons without parameters. This 898 message is syntactically invalid. 900 An element receiving this request should respond with a 400 Bad 901 Request error. 903 Message Details : badinv01 905 INVITE sip:user@example.com SIP/2.0 906 To: sip:j.user@example.com 907 From: sip:caller@example.net;tag=134161461246 908 Max-Forwards: 7 909 Call-ID: 0ha0isndaksdjasdf3234nas 910 CSeq: 8 INVITE 911 Via: SIP/2.0/UDP 192.0.2.15;;,;,, 912 Contact: "Joe" ;;;; 913 Content-Length: 153 914 Content-Type: application/sdp 916 v=0 917 o=mhandley 29739 7272939 IN IP4 192.0.2.15 918 s=- 919 c=IN IP4 192.0.2.15 920 t=0 0 921 m=audio 492170 RTP/AVP 0 12 922 m=video 3227 RTP/AVP 31 923 a=rtpmap:31 LPC 925 3.1.2.2 Content length larger than message 927 This is a request message with a Content Length that is larger than 928 the length of the body. 930 When sent UDP (as this message ostensibly was), the receiving element 931 should respond with a 400 Bad Request error. If this message were 932 received over a stream-based transport such as TCP, there's not much 933 you can do but wait for more data on the stream and close the 934 connection if none is forthcoming in a reasonable period of time. 936 Message Details : clerr 938 INVITE sip:user@example.com SIP/2.0 939 Max-Forwards: 80 940 To: sip:j.user@example.com 941 From: sip:caller@example.net;tag=93942939o2 942 Contact: 943 Call-ID: 0ha0isndaksdjweiafasdk3 944 CSeq: 8 INVITE 945 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523 946 Content-Type: application/sdp 947 Content-Length: 9999 949 v=0 950 o=mhandley 29739 7272939 IN IP4 192.0.2.155 951 s=- 952 c=IN IP4 192.0.2.155 953 t=0 0 954 m=audio 492170 RTP/AVP 0 12 955 m=video 3227 RTP/AVP 31 956 a=rtpmap:31 LPC 958 3.1.2.3 Negative Content-Length 960 This request has a negative value for Content-Length. 962 An element receiving this message should respond with an error. This 963 request appeared over UDP, so the remainder of the datagram can 964 simply be discarded. If a request like this arrives over TCP, the 965 framing error is not recoverable and the connection should be closed. 966 The same behavior is appropriate for messages that arrive without a 967 numeric value in the Content-Length header field such as: 969 Content-Length: five 971 Implementors should take extra precautions if the technique they 972 choose for converting this ascii field into an integral form can 973 return a negative value. In particular, the result must not be used 974 as a counter or array index. 976 Message Details : ncl 978 INVITE sip:user@example.com SIP/2.0 979 Max-Forwards: 254 980 To: sip:j.user@example.com 981 From: sip:caller@example.net;tag=32394234 982 Call-ID: 0ha0isndaksdj2193423r542w35 983 CSeq: 0 INVITE 984 Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw 985 Contact: 986 Content-Type: application/sdp 987 Content-Length: -999 989 v=0 990 o=mhandley 29739 7272939 IN IP4 192.0.2.53 991 s=- 992 c=IN IP4 192.0.2.53 993 t=0 0 994 m=audio 492170 RTP/AVP 0 12 995 m=video 3227 RTP/AVP 31 996 a=rtpmap:31 LPC 998 3.1.2.4 Request scalar fields with overlarge values 1000 This request contains several scalar header field values outside 1001 their legal range. 1003 o the CSeq sequence number is >2**32-1. 1005 o the Max-Forwards value is >255. 1007 o the Expires value is >2**32-1. 1009 o the Contact expires parameter value is >2**32-1. 1011 An element receiving this request should respond with a 400 Bad 1012 Request due to the CSeq error. If only the Max-Forwards field were in 1013 error, the element could choose process the request as if the field 1014 were absent. If only the expiry values were in error, the element 1015 could treat them as if they contained the default values for 1016 expiration (3600 in this case). 1018 Other scalar request fields that may contain aberrant values include, 1019 but are not limited to, the Contact q value, the Timestamp value, 1020 and the Via ttl parameter. 1022 Message Details : scalar02 1024 REGISTER sip:example.com SIP/2.0 1025 Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3 1026 To: 1027 From: ;tag=239232jh3 1028 CSeq: 36893488147419103232 REGISTER 1029 Call-ID: asdnw3qjr23o0pd9vanlq3wnrlnewofjas9ui32 1030 Max-Forwards: 300 1031 Expires: 10 1032 Contact: 1033 ;expires=280297596632815 1034 Content-Length: 0 1036 3.1.2.5 Response scalar fields with overlarge values 1038 This response contains several scalar header field values outside 1039 their legal range. 1041 o the CSeq sequence number is >2**32-1. 1043 o The Retry-After field is unreasonably large (note that RFC 3261 1044 does not define a legal range for this field). 1046 o The Warning field has a warning-value with more than 3 digits 1048 An element receiving this response will simply discard it. 1050 Message Details : scalarlg 1051 SIP/2.0 503 Service Unavailable 1052 Via: SIP/2.0/TCP host129.example.com;branch=z0hG4bKzzxdiwo34sw 1053 To: 1054 From: ;tag=2easdjfejw 1055 CSeq: 9292394834772304023312 OPTIONS 1056 Call-ID: nvoao34irnoase0of0234hn2qofoaf0232aewf2394r 1057 Retry-After: 949302838503028349304023988 1058 Warning: 1812 overture "In Progress" 1059 Content-Length: 0 1061 3.1.2.6 Unterminated quoted string in display-name 1063 This is a request with an unterminated quote in the display name of 1064 the To field. An element receiving this request should return an 400 1065 Bad Request error. 1067 An element could attempt to infer a terminating quote and accept the 1068 message. Such an element needs to take care that it makes a 1069 reasonable inference when it encounters 1071 To: "Mr J. User 1073 Message Details : quotbal 1075 INVITE sip:user@example.com SIP/2.0 1076 To: "Mr. J. User 1077 From: sip:caller@example.net;tag=93334 1078 Max-Forwards: 10 1079 Call-ID: 0ha0isndaksdj 1080 Contact: 1081 CSeq: 8 INVITE 1082 Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234 1083 Content-Type: application/sdp 1084 Content-Length: 153 1086 v=0 1087 o=mhandley 29739 7272939 IN IP4 192.0.2.15 1088 s=- 1089 c=IN IP4 192.0.2.15 1090 t=0 0 1091 m=audio 492170 RTP/AVP 0 12 1092 m=video 3227 RTP/AVP 31 1093 a=rtpmap:31 LPC 1095 3.1.2.7 <> enclosing Request-URI 1097 This INVITE request is invalid because the Request-URI has been 1098 enclosed within in "<>". 1100 It is reasonable to always reject a request with this error with a 1101 400 Bad Request. Elements attempting to be liberal with what they 1102 accept may choose to ignore the brackets. If the element forwards the 1103 request, it must not include the brackets in the messages it sends. 1105 Message Details : ltgtruri 1107 INVITE SIP/2.0 1108 To: sip:user@example.com 1109 From: sip:caller@example.net;tag=39291 1110 Max-Forwards: 23 1111 Call-ID: 1@192.0.2.5 1112 CSeq: 1 INVITE 1113 Via: SIP/2.0/UDP 192.0.2.5 1114 Contact: 1115 Content-Type: application/sdp 1116 Content-Length: 160 1118 v=0 1119 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1120 s=- 1121 c=IN IP4 192.0.2.5 1122 t=3149328700 0 1123 m=audio 492170 RTP/AVP 0 12 1124 m=video 3227 RTP/AVP 31 1125 a=rtpmap:31 LPC 1127 3.1.2.8 Malformed SIP Request-URI (embedded LWS) 1129 This INVITE has illegal LWS within the Request-URI. 1131 An element receiving this request should respond with a 400 Bad 1132 Request. 1134 An element could attempt to ignore the embedded LWS for those schemes 1135 (like sip) where that would not introduce ambiguity. 1137 Message Details : lwsruri 1139 INVITE sip:user@example.com; lr SIP/2.0 1140 To: sip:user@example.com;tag=3xfe-9921883-z9f 1141 From: sip:caller@example.net;tag=231413434 1142 Max-Forwards: 5 1143 Call-ID: asdfasdoijweoi2323-asdfwern23-asd8ia0swn34rk423 1144 CSeq: 2130706432 INVITE 1145 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395 1146 Contact: 1147 Content-Type: application/sdp 1148 Content-Length: 160 1150 v=0 1151 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1152 s=- 1153 c=IN IP4 192.0.2.1 1154 t=3149328700 0 1155 m=audio 492170 RTP/AVP 0 12 1156 m=video 3227 RTP/AVP 31 1157 a=rtpmap:31 LPC 1159 3.1.2.9 Multiple SP separating Request-Line elements 1161 This INVITE has illegal multiple SP characters between elements of 1162 the start line. 1164 It is acceptable to reject this request as malformed. An element that 1165 is liberal in what it accepts may ignore these extra SP characters 1166 while processing the request. If the element forwards the request, it 1167 must not include these extra SP characters in the messages it sends. 1169 Message Details : lwsstart 1171 INVITE sip:user@example.com SIP/2.0 1172 Max-Forwards: 8 1173 To: sip:user@example.com 1174 From: sip:caller@example.net;tag=8814 1175 Call-ID: 2304u0qwsdfknq234oi243099adsdfnawe3@example.com 1176 CSeq: 1893884 INVITE 1177 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923 1178 Contact: 1179 Content-Type: application/sdp 1180 Content-Length: 151 1182 v=0 1183 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1184 s=- 1185 c=IN IP4 192.0.2.1 1186 t=0 0 1187 m=audio 492170 RTP/AVP 0 12 1188 m=video 3227 RTP/AVP 31 1189 a=rtpmap:31 LPC 1191 3.1.2.10 SP characters at end of Request-Line 1193 This OPTIONS request contains SP characters between the SIP-Version 1194 field and the CRLF terminating the Request-Line. 1196 It is acceptable to reject this request as malformed. An element that 1197 is liberal in what it accepts may ignore these extra SP characters 1198 while processing the request. If the element forwards the request, it 1199 must not include these extra SP characters in the messages it sends. 1201 Message Details : trws 1203 OPTIONS sip:remote-target@example.com SIP/2.02020 1204 Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093 1205 To: 1206 From: ;tag=329429089 1207 Call-ID: afewroicu34958239neffasdhr2345r 1208 Accept: application/sdp 1209 CSeq: 238923 OPTIONS 1210 Max-Forwards: 70 1211 Content-Length: 0 1213 3.1.2.11 Escaped headers in SIP Request-URI 1215 This INVITE is malformed as the SIP Request-URI contains escaped 1216 headers. 1218 It is acceptable for an element to reject this request with a 400 Bad 1219 Request. An element could choose to be liberal in what it accepts and 1220 ignore the escaped headers. If the element is a proxy, the escaped 1221 headers must not appear in the Request-URI of forwarded request (and 1222 most certainly must not be translated into the actual header of the 1223 forwarded request). 1225 Message Details : escruri 1227 INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0 1228 To: sip:user@example.com 1229 From: sip:caller@example.net;tag=341518 1230 Max-Forwards: 7 1231 Contact: 1232 Call-ID: 23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 1233 CSeq: 149209342 INVITE 1234 Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw 1235 Content-Type: application/sdp 1236 Content-Length: 151 1238 v=0 1239 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1240 s=- 1241 c=IN IP4 192.0.2.1 1242 t=0 0 1243 m=audio 492170 RTP/AVP 0 12 1244 m=video 3227 RTP/AVP 31 1245 a=rtpmap:31 LPC 1247 3.1.2.12 Invalid timezone in Date header field 1249 This INVITE is invalid as it contains a non GMT time zone in the SIP 1250 Date header field. 1252 It is acceptable to reject this request as malformed (though an 1253 element shouldn't do that unless the contents of the Date header 1254 field were actually important to its processing). An element wishing 1255 to be liberal in what it accepts could ignore this value altogether 1256 if it wasn't going to use the Date header field anyhow. Otherwise, it 1257 could attempt to interpret this date and adjust it to GMT. 1259 RFC 3261 explicitly defines the only acceptable timezone designation 1260 as "GMT". "UT", while synonymous with GMT per [RFC2822], is not 1261 valid. "UTC" and "UCT" are also invalid. 1263 Message Details : baddate 1265 INVITE sip:user@example.com SIP/2.0 1266 To: sip:user@example.com 1267 From: sip:caller@example.net;tag=2234923 1268 Max-Forwards: 70 1269 Call-ID: 239423mnsadf3j23lj42--sedfnm234 1270 CSeq: 1392934 INVITE 1271 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1272 Date: Fri, 01 Jan 2010 16:00:00 EST 1273 Contact: 1274 Content-Type: application/sdp 1275 Content-Length: 151 1277 v=0 1278 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1279 s=- 1280 c=IN IP4 192.0.2.5 1281 t=0 0 1282 m=audio 492170 RTP/AVP 0 12 1283 m=video 3227 RTP/AVP 31 1284 a=rtpmap:31 LPC 1286 3.1.2.13 Failure to enclose name-addr URI in <> 1288 This REGISTER request is malformed. The SIP URI contained in the 1289 Contact Header field has an escaped header, so the field must be in 1290 name-addr form (which implies the URI must be enclosed in <>). 1292 It is reasonable for an element receiving this request to respond 1293 with a 400 Bad Request. An element choosing to be liberal in what it 1294 accepts could infer the angle brackets since there is no ambiguity in 1295 this example. In general, that won't be possible. 1297 Message Details : regbadct 1299 REGISTER sip:example.com SIP/2.0 1300 To: sip:user@example.com 1301 From: sip:user@example.com;tag=998332 1302 Max-Forwards: 70 1303 Call-ID: k345asrl3fdbv@10.0.0.1 1304 CSeq: 1 REGISTER 1305 Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 1306 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 1307 l: 0 1309 3.1.2.14 Spaces within addr-spec 1311 This request is malformed since the addr-spec in the To header field 1312 contains spaces. Parsers receiving this request must not break. It is 1313 reasonable to reject this request with a 400 Bad Request response. 1314 Elements attempting to be liberal may ignore the spaces. 1316 Message Details : badaspec 1318 OPTIONS sip:user@example.org SIP/2.0 1319 Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234 1320 Max-Forwards: 70 1321 From: "Bell, Alexander" ;tag=433423 1322 To: "Watson, Thomas" < sip:t.watson@example.org > 1323 Call-ID: sdf0234n2nds0a099u23h3hnnw009cdkne3 1324 Accept: application/sdp 1325 CSeq: 3923239 OPTIONS 1326 l: 0 1328 3.1.2.15 Non-token characters in display-name 1330 This OPTIONS request is malformed since the display names in the To 1331 and From header fields contain non-token characters but are unquoted. 1333 It is reasonable to always reject this kind of error with a 400 Bad 1334 Request response. 1336 An element may attempt to be liberal in what it receives and infer 1337 the missing quotes. If this element were a proxy, it must not 1338 propagate the error into the request it forwards. As a consequence, 1339 if the fields are covered by a signature, there's not much point in 1340 trying to be liberal - the message should be simply rejected. 1342 Message Details : baddn 1344 OPTIONS sip:t.watson@example.org SIP/2.0 1345 Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw 1346 Max-Forwards: 70 1347 From: Bell, Alexander ;tag=43 1348 To: Watson, Thomas 1349 Call-ID: 31415@c.example.com 1350 Accept: application/sdp 1351 CSeq: 3923239 OPTIONS 1352 l: 0 1354 3.1.2.16 Unknown protocol version 1356 To an element implementing [RFC3261], this request is malformed due 1357 to its high version number. 1359 The element should respond to the request with a 505 Version Not 1360 Supported error. 1362 Message Details : badvers 1364 OPTIONS sip:t.watson@example.org SIP/7.0 1365 Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw 1366 Max-Forwards: 70 1367 From: A. Bell ;tag=qweoiqpe 1368 To: T. Watson 1369 Call-ID: 31417@c.example.com 1370 CSeq: 1 OPTIONS 1371 l: 0 1373 3.1.2.17 Start line and CSeq method mismatch 1375 This request has mismatching values for the method in the start line 1376 and the CSeq header field. Any element receiving this request will 1377 respond with a 400 Bad Request. 1379 Message Details : mismatch01 1381 OPTIONS sip:user@example.com SIP/2.0 1382 To: sip:j.user@example.com 1383 From: sip:caller@example.net;tag=34525 1384 Max-Forwards: 6 1385 Call-ID: 0ha0isndaksdj0234sxdfl3 1386 CSeq: 8 INVITE 1387 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1388 l: 0 1390 3.1.2.18 Unknown Method with CSeq method mismatch 1392 This message has an unknown method, and a CSeq method tag which does 1393 not match it. 1395 Any element receiving this response will should respond with a 501 1396 Not Implemented. A 400 Bad Request is also acceptable, but choosing a 1397 501 (particularly at proxies) has better future-proof 1398 characteristics. 1400 Message Details : mismatch02 1402 NEWMETHOD sip:user@example.com SIP/2.0 1403 To: sip:j.user@example.com 1404 From: sip:caller@example.net;tag=34525 1405 Max-Forwards: 6 1406 Call-ID: 0ha0isndaksdj0234sxdfl3 1407 CSeq: 8 INVITE 1408 Contact: 1409 Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw 1410 Content-Type: application/sdp 1411 l: 139 1413 v=0 1414 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1415 c=IN IP4 192.0.2.1 1416 m=audio 492170 RTP/AVP 0 12 1417 m=video 3227 RTP/AVP 31 1418 a=rtpmap:31 LPC 1420 3.1.2.19 Overlarge response code 1422 This response has a response code larger than 699. An element 1423 receiving this response should simply drop it. 1425 Message Details : bigcode 1427 SIP/2.0 4294967301 better not break the receiver 1428 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 1429 Call-ID: asdof3uj203asdnf3429uasdhfas3ehjasdfas9i 1430 CSeq: 353494 INVITE 1431 From: ;tag=39ansfi3 1432 To: ;tag=902jndnke3 1433 Content-Length: 0 1434 Contact: 1436 3.2 Transaction layer semantics 1438 This section contains tests that exercise an implementation's parser 1439 and transaction layer logic. 1441 3.2.1 Missing transaction identifier 1443 This request indicates support for RFC 3261-style transaction 1444 identifiers by providing the z9hG4bK prefix to the branch parameter, 1445 but it provides no identifier. A parser must not break when receiving 1446 this message. An element receiving this request could reject the 1447 request with a 400 Response (preferably statelessly, as other 1448 requests from the source are likely to also have a malformed branch 1449 parameter), or it could fall back to the RFC 2543 style transaction 1450 identifier. 1452 Message Details : badbranch 1454 OPTIONS sip:user@example.com SIP/2.0 1455 To: sip:user@example.com 1456 From: sip:caller@example.org;tag=33242 1457 Max-Forwards: 3 1458 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK 1459 Accept: application/sdp 1460 Call-ID: sadonfo23i420jv0as0derf3j3n 1461 CSeq: 8 OPTIONS 1462 l: 0 1464 3.3 Application layer semantics 1466 This section contains tests that exercise an implementation's parser 1467 and application layer logic. 1469 3.3.1 Missing Required Header Fields 1471 This request contains no Call-ID, From, or To header fields. 1473 An element receiving this message must not break because of the 1474 missing information. Ideally, it will respond with a 400 Bad Request 1475 error. 1477 Message Details : insuf 1479 INVITE sip:user@example.com SIP/2.0 1480 CSeq: 193942 INVITE 1481 Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdjuw 1482 Content-Type: application/sdp 1483 l: 153 1485 v=0 1486 o=mhandley 29739 7272939 IN IP4 192.0.2.95 1487 s=- 1488 c=IN IP4 192.0.2.95 1489 t=0 0 1490 m=audio 492170 RTP/AVP 0 12 1491 m=video 3227 RTP/AVP 31 1492 a=rtpmap:31 LPC 1494 3.3.2 Request-URI with unknown scheme 1496 This OPTIONS contains an unknown URI scheme in the Request-URI. A 1497 parser must accept this as a well-formed SIP request. 1499 An element receiving this request will reject it with a 416 1500 Unsupported URI Scheme response. 1502 Some early implementations attempt to look at the contents of the To 1503 header field to determine how to route this kind of request. That is 1504 an error. Despite the fact that the To header field and the Request 1505 URI frequently look alike in simplistic first-hop messages, the To 1506 header field contains no routing information. 1508 Message Details : unkscm 1510 OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0 1511 To: sip:user@example.com 1512 From: sip:caller@example.net;tag=384 1513 Max-Forwards: 3 1514 Call-ID: 2340923nasdfasser0q239nwsdfasdkl34 1515 CSeq: 3923423 OPTIONS 1516 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1517 Content-Length: 0 1519 3.3.3 Request-URI with known but atypical scheme 1521 This OPTIONS contains an Request-URI with an IANA registered scheme 1522 that does not commonly appear Request-URIs of SIP requests. A parser 1523 must accept this as a well-formed SIP request. 1525 If an element will never accept this scheme as meaningful in a 1526 request-URI, it is appropriate to treat it as unknown and return a 1527 416 Unsupported URI Scheme response. If the element might accept some 1528 URIs with this scheme, then a 404 Not Found is appropriate for those 1529 URIs it doesn't accept. 1531 Message Details : novelsc 1533 OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0 1534 To: sip:user@example.com 1535 From: sip:caller@example.net;tag=384 1536 Max-Forwards: 3 1537 Call-ID: 2340923nasdfasser0q239nwsdfasdkl34 1538 CSeq: 3923423 OPTIONS 1539 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1540 Content-Length: 0 1542 3.3.4 Unknown URI schemes in header fields 1544 This message contains registered schemes in the To, From and Contact 1545 header fields of a request. The message is syntactically valid. 1546 Parsers must not fail when receiving this message. 1548 Proxies should treat this message as they would any other request for 1549 this URI. A registrar would reject this request with a 400 Bad 1550 Request response since the To: header field is required to contain a 1551 SIP or SIPS URI as an AOR. 1553 Message Details : unksm2 1555 REGISTER sip:example.com SIP/2.0 1556 To: isbn:2983792873 1557 From: ;tag=3234233 1558 Call-ID: 0ha0isndaksdj@hyphenated-host.example.com 1559 CSeq: 234902 REGISTER 1560 Max-Forwards: 70 1561 Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw 1562 Contact: 1563 l: 0 1565 3.3.5 Proxy-Require and Require 1567 This request tests proper implementation of SIP's Proxy-Require and 1568 Require extension mechanisms. 1570 Any element receiving this request will respond with a 420 Bad 1571 Extension response containing an Unsupported header field listing 1572 these features from either the Require or Proxy-Require header field 1573 depending on the role in which the element is responding. 1575 Message Details : bext01 1577 OPTIONS sip:user@example.com SIP/2.0 1578 To: sip:j_user@example.com 1579 From: sip:caller@example.net;tag=242etr 1580 Max-Forwards: 6 1581 Call-ID: 0ha0isndaksdj 1582 Require: nothingSupportsThis, nothingSupportsThisEither 1583 Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis 1584 CSeq: 8 OPTIONS 1585 Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw 1586 Content-Length: 0 1588 3.3.6 Unknown Content-Type 1590 This INVITE request contains a body of unknown type. It is 1591 syntactically valid. A parser must not fail when receiving it. 1593 A proxy receiving this request would process it just like any other 1594 INVITE. An endpoint receiving this request would reject it with a 415 1595 Unsupported Media Type error. 1597 Message Details : invut 1599 INVITE sip:user@example.com SIP/2.0 1600 Contact: 1601 To: sip:j.user@example.com 1602 From: sip:caller@example.net;tag=8392034 1603 Max-Forwards: 70 1604 Call-ID: 0ha0isndaksdjadsfij34n23d 1605 CSeq: 235448 INVITE 1606 Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw 1607 Content-Type: application/unknownformat 1608 Content-Length: 40 1610 1614 3.3.7 Unknown authorization scheme 1616 This REGISTER request contains an Authorization header field with an 1617 unknown scheme. The request is well-formed. A parser must not fail 1618 when receiving it. 1620 A proxy will treat this request as any other REGISTER. If it forwards 1621 the request, it will include this Authorization header field 1622 unmodified in the forwarded messages. 1624 A registrar that does not care about challenge-response 1625 authentication will simply ignore the Authorization header field, 1626 processing this registration as if the field were not present. A 1627 registrar that does care about challenge-response authentication will 1628 reject this request with a 401, issuing a new challenge with a scheme 1629 it understands. 1631 Endpoints choosing not to act as registrars will simply reject the 1632 request. A 405 Method Not Allowed is appropriate. 1634 Message Details : regaut01 1636 REGISTER sip:example.com SIP/2.0 1637 To: sip:j.user@example.com 1638 From: sip:j.user@example.com;tag=87321hj23128 1639 Max-Forwards: 8 1640 Call-ID: 0ha0isndaksdj 1641 CSeq: 9338 REGISTER 1642 Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw 1643 Authorization: NoOneKnowsThisScheme opaque-data=here 1644 Content-Length:0 1646 3.3.8 Multiple values in single value required fields 1648 The message contains a request with multiple Call-ID, To, From, 1649 Max-Forwards and CSeq values. An element receiving this request must 1650 not break. 1652 An element receiving this request would respond with a 400 Bad 1653 Request error. 1655 Message Details : multi01 1657 INVITE sip:user@company.com SIP/2.0 1658 Contact: 1659 Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw 1660 Max-Forwards: 70 1661 CSeq: 5 INVITE 1662 Call-ID: 98asdh@192.0.2.1 1663 CSeq: 59 INVITE 1664 Call-ID: 98asdh@192.0.2.2 1665 From: sip:caller@example.com;tag=3413415 1666 To: sip:user@example.com 1667 To: sip:other@example.net 1668 From: sip:caller@example.net;tag=2923420123 1669 Content-Type: application/sdp 1670 l: 155 1671 Contact: 1672 Max-Forwards: 5 1674 v=0 1675 o=mhandley 29739 7272939 IN IP4 192.0.2.25 1676 s=- 1677 c=IN IP4 192.0.2.25 1678 t=0 0 1679 m=audio 492170 RTP/AVP 0 12 1680 m=video 3227 RTP/AVP 31 1681 a=rtpmap:31 LPC 1683 3.3.9 Multiple Content-Length values 1685 Multiple conflicting Content-Length header field values appear in 1686 this request. 1688 From a framing perspective, this situation is equivalent to an 1689 invalid Content-Length value (or no value at all). 1691 An element receiving this message should respond with an error. This 1692 request appeared over UDP, so the remainder of the datagram can 1693 simply be discarded. If a request like this arrives over TCP, the 1694 framing error is not recoverable and the connection should be closed. 1696 Message Details : mcl01 1698 OPTIONS sip:user@example.com SIP/2.0 1699 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423 1700 To: sip:user@example.com 1701 From: sip:other@example.net;tag=3923942 1702 Call-ID: 234asdfhn2323orihawfdoa3o4r52o3irsdf 1703 CSeq: 15932 OPTIONS 1704 Content-Length: 13 1705 Max-Forwards: 60 1706 Content-Length: 5 1707 Content-Type: text/plain 1709 There's no way to know how many octets are supposed to be here. 1711 3.3.10 200 OK Response with broadcast Via header field value 1713 This message is a response with a 2nd Via header field value's 1714 sent-by containing 255.255.255.255. The message is well formed - 1715 parsers must not fail when receiving it. 1717 Per [RFC3261] an endpoint receiving this message should simply 1718 discard it. 1720 If a proxy followed normal response processing rules blindly, it 1721 would forward this response to the broadcast address. To protect 1722 against this being used as an avenue of attack, proxies should drop 1723 such responses. 1725 Message Details : bcast 1727 SIP/2.0 200 OK 1728 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 1729 Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23 1730 Call-ID: 0384840201234ksdfak3j2erwedfsASdf 1731 CSeq: 35 INVITE 1732 From: sip:user@example.com;tag=11141343 1733 To: sip:user@example.edu;tag=2229 1734 Content-Length: 159 1735 Content-Type: application/sdp 1736 Contact: 1738 v=0 1739 o=mhandley 29739 7272939 IN IP4 192.0.2.198 1740 s=- 1741 c=IN IP4 192.0.2.198/127 1742 t=0 0 1743 m=audio 492170 RTP/AVP 0 12 1744 m=video 3227 RTP/AVP 31 1745 a=rtpmap:31 LPC 1747 3.3.11 Max-Forwards of zero 1749 This is a legal SIP request with the Max-Forwards header field value 1750 set to zero. 1752 A proxy should not forward the request and respond 483 (Too Many 1753 Hops). An endpoint should process the request as if the Max-Forwards 1754 field value were still positive. 1756 Message Details : zeromf 1758 OPTIONS sip:user@example.com SIP/2.0 1759 To: sip:user@example.com 1760 From: sip:caller@example.net;tag=3ghsd41 1761 Call-ID: 2304sadjfasdlfnm2o2l43r5u0asdfas 1762 CSeq: 39234321 OPTIONS 1763 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i 1764 Max-Forwards: 0 1765 Content-Length: 0 1767 3.3.12 REGISTER with a contact header parameter 1769 This register request contains a contact where the 'unknownparam' 1770 parameter must be interpreted as being a contact-param and not a 1771 url-param. 1773 This REGISTER should succeed. The response must not include 1774 "unknownparam" as a url-parameter for this binding. Likewise, 1775 "unknownparam" must not appear as part of the binding during 1776 subsequent fetches. 1778 Behavior is the same, of course, for any known contact-param 1779 parameter names. 1781 Message Details : cparam01 1783 REGISTER sip:example.com SIP/2.0 1784 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1785 Max-Forwards: 70 1786 From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe 1787 To: sip:watson@example.com 1788 Call-ID: 70710@saturn.example.com 1789 CSeq: 2 REGISTER 1790 Contact: sip:+19725552222@gw1.example.net;unknownparam 1791 l: 0 1793 3.3.13 REGISTER with a url parameter 1795 This register request contains a contact where the URI has an unknown 1796 parameter. 1798 The register should succeed and a subsequent retrieval of the 1799 registration must include "unknownparam" as a url-parameter. 1801 Behavior is the same, of course, for any known url-parameter names. 1803 Message Details : cparam02 1805 REGISTER sip:example.com SIP/2.0 1806 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1807 Max-Forwards: 70 1808 From: sip:watson@example.com;tag=838293 1809 To: sip:watson@example.com 1810 Call-ID: 70710@saturn.example.com 1811 CSeq: 3 REGISTER 1812 Contact: 1813 l: 0 1815 3.3.14 REGISTER with a url escaped header 1817 This register request contains a contact where the URI has an escaped 1818 header. 1820 The register should succeed and a subsequent retrieval of the 1821 registration must include the escaped Route header in the contact URI 1822 for this binding. 1824 Message Details : regescrt 1826 REGISTER sip:example.com SIP/2.0 1827 To: sip:user@example.com 1828 From: sip:user@example.com;tag=8 1829 Max-Forwards: 70 1830 Call-ID: k345asrl3fdbv@192.0.2.1 1831 CSeq: 14398234 REGISTER 1832 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 1833 M: 1834 L:0 1836 3.3.15 Unacceptable Accept offering 1838 This request indicates the response must contain a body in an unknown 1839 type. In particular, since the Accept header field does not contain 1840 application/sdp, the response may not contain an SDP body. The 1841 recipient of this request could respond with a 406 Not Acceptable 1842 with a Warning/399 indicating that a response cannot be formulated in 1843 the formats offered in the Accept header field. It is also 1844 appropriate to respond with a 400 Bad Request since all SIP UAs 1845 supporting INVITE are required to support application/sdp. 1847 Message Details : sdp01 1849 INVITE sip:user@example.com SIP/2.0 1850 To: sip:j_user@example.com 1851 Contact: 1852 From: sip:caller@example.net;tag=234 1853 Max-Forwards: 5 1854 Call-ID: 0ha0isndaksdj9342dasdd 1855 Accept: text/nobodyKnowsThis 1856 CSeq: 8 INVITE 1857 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw 1858 Content-Length: 151 1859 Content-Type: application/sdp 1861 v=0 1862 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1863 s=- 1864 c=IN IP4 192.0.2.5 1865 t=0 0 1866 m=audio 492170 RTP/AVP 0 12 1867 m=video 3227 RTP/AVP 31 1868 a=rtpmap:31 LPC 1870 3.4 Backward compatibility 1872 3.4.1 INVITE with RFC2543 syntax 1874 This is a legal message per RFC 2543 (and several bis versions) which 1875 should be accepted by RFC 3261 elements which want to maintain 1876 backwards compatibility. 1878 o There is no branch parameter at all on the Via header field value 1880 o There is no From tag 1882 o There is no explicit Content-Length (The body is assumed to be all 1883 octets in the datagram after the null-line) 1885 o There is no Max-Forwards header field 1887 Message Details : inv2543 1889 INVITE sip:UserB@example.com SIP/2.0 1890 Via: SIP/2.0/UDP iftgw.example.com 1891 From: 1892 Record-Route: 1893 To: sip:+16505552222@ss1.example.net;user=phone 1894 Call-ID: 1717@ift.client.example.com 1895 CSeq: 56 INVITE 1896 Content-Type: application/sdp 1898 v=0 1899 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1900 s=- 1901 c=IN IP4 192.0.2.5 1902 t=0 0 1903 m=audio 492170 RTP/AVP 0 1905 4. Security Considerations 1907 This document presents NON NORMATIVE examples of SIP session 1908 establishment. The security considerations in [RFC3261] apply. 1910 Parsers must carefully consider edge conditions and malicious input 1911 as part of their design. Attacks on many Internet systems use crafted 1912 input to cause implementations to behave in undesirable ways. Many of 1913 the messages in this draft are designed to stress a parser 1914 implementation at points traditionally used for such attacks. This 1915 document does not, however, attempt to be comprehensive. It should be 1916 considered a seed to stimulate thinking and planning, not simply a 1917 set of tests to be passed. 1919 5. Open Issues and Remaining Work 1921 1. All of the messages in this document should be considered new. 1922 They are either new additions or major revisions of the previous 1923 versions. They all need to be carefully reviewed by the working 1924 group 1926 2. Are the header field values in Section 3.1.1.7 long enough? 1927 Should we push each field over 256 octets or even longer? Where 1928 is the threshold of reason? 1930 3. Is this really possible to recover from embedded whitespace in a 1931 SIP Request-URI as suggested in Section 3.1.2.8? 1933 4. Can we modify the example in Section 3.1.2.15 such that it is not 1934 obvious where to infer quotes? 1936 5. Can we modify the example in Section 3.1.2.13 such that it is not 1937 obvious (due to ambiguity perhaps) where to infer angle brackets? 1939 6. Is the message at Section 3.3.11 sufficiently tortuous to include 1940 in this document? 1942 6. Acknowledgments 1944 The authors wish to thank the following individuals for their 1945 participation in the review of earlier versions of this document: 1946 Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen 1947 Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, 1948 Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua 1949 and Tom Taylor. 1951 Thanks to Neil Deason for contributing several messages and Kundan 1952 Singh for performing parser validation of messages in earlier 1953 versions.. 1955 The following individuals provided significant comments during the 1956 early phases of the development of this document: Jean-Francois Mule, 1957 Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, 1958 Matt Cannon, John Hearty, the whole MCI WorldCom IPOP Design team, 1959 Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny 1960 Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom 1961 Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI 1962 WorldCom, 3Com, Cisco, Lucent and Nortel. 1964 Informative References 1966 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1967 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1968 August 1998. 1970 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1971 2001. 1973 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1974 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1975 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1977 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1978 with Session Description Protocol (SDP)", RFC 3264, June 1979 2002. 1981 Authors' Addresses 1983 Robert J. Sparks (editor) 1984 dynamicsoft 1985 5100 Tennyson Parkway 1986 Suite 1200 1987 Plano, TX 75024 1989 EMail: rsparks@dynamicsoft.com 1991 Alan Hawrylyshen 1992 Jasomi Networks 1993 2033 Gateway Place 1994 Suite 500 1995 San Jose, CA 95110 1997 EMail: alan@jasomi.com 1998 Alan Johnston 1999 MCI 2000 100 South 4th Street 2001 St. Louis, MO 63102 2003 EMail: alan.johnston@mci.com 2005 Jonathan Rosenberg 2006 dynamicsoft 2007 600 Lanidex Plaza 2008 Parsippany, NJ 07052 2010 Phone: +1 973 952 5000 2011 EMail: jdrosen@dynamicsoft.com 2012 URI: http://www.jdrosen.net 2014 Henning Schulzrinne 2015 Columbia University 2016 Department of Computer Science 2017 1214 Amsterdam Ave. 2018 New York, NY 10027 2019 USA 2021 EMail: schulzrinne@cs.columbia.edu 2023 Appendix A. Bit-exact archive of each test message 2025 The following text block is an encoded, gzip compressed TAR archive 2026 of files that represent each of the example messages discussed in 2027 Section 3. 2029 To recover the compressed archive file intact, the text of this 2030 document may be passed as input to the following Perl script (the 2031 output should be redirected to a file or piped to "tar -xzvf -"). 2033 #!/usr/bin/perl 2034 use strict; 2035 my $bdata = ""; 2036 use MIME::Base64; 2037 while(<>) { 2038 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 2039 if ( m/^\s*[^\s]+\s*$/) { 2040 $bdata = $bdata . $_; 2041 } 2042 } 2043 } 2044 print decode_base64($bdata); 2046 Figure 58 2048 Alternatively, the base-64 encoded block can be edited by hand to 2049 remove document structure lines and fed as input to any base-64 2050 decoding utility. 2052 A.1 Encoded Reference Messages 2054 -- BEGIN MESSAGE ARCHIVE -- 2055 H4sIABptDEACA+xdy3PbSHq3PZnHaqJNbc0tJ1g1XM9YItXoxpMyNfLYmh2N 2056 H+OyZE/VZlOeFtEQQYIABYCk5VScxIet7CW1e04OW6mkUjllc0tqq5Iqzx+V 2057 a74GXyAAkpAsPuxB2xAJ4MOjQfy+/t59TA3qt1i1ZNDgypwaEhFSFOkKgqbG 2058 PnmTsXgFqdDgj6ioQE8UIl0R0JUFtLYfUE8Qrnh1v0W9hj+Jbtb+t7R9++jo 2059 4NuHh4Jvtcptn3l77DlttmxWcr0T4fDg0TYuofW1pxYtD9a2n9x9JNRcP5BK 2060 A9qq2yzLSEE7xx51qrXKC732C+n4XsOotyWCibS+9oA+L37lel3qGX5ZUOGU 2061 X3lwkLDxJbPtLeG2DadyDOZtCLf4ndDSSekY9uxFrrC7E9CTikSIhMn62pEL 2062 B39HA991toSjmtukPhwbdiModcPtY13ZXV+7Q227eHC3LPiGieCuHOwYPqJI 2063 19uY1EjNcboI6VWj4TC4wO1qlbWCskBbLduq0sBynW3faMFpDtlpWSA6hp7p 2064 Qv/5ra/ZZQF6tb72lv3+x9To/WhzZACz8E9UieNfViRFVGTE8a+qJMf/UvEP 2065 iBvhn6MtjWIAY76vCvAa5x8hYAnBEo4zAJLCUkQdvpVwSYxxkWlQHCKaGq5j 2066 uphYEkb1DqI+AmZikjpxBoDV3nqozgv/AHw2z+F/Fv5FJMpx/EtSPv4vpB08 2067 fHpwtH/58HdYEMIfw0Cr8wE7KQEM0QvjKIzpTQdQDJDFxK5LuFj0mWE6zVB6 2068 6CFYhDFXJ5LQu+UJQklUJkkRR7rra3fhdS8LX3nWloBE4RvqCBheQUFUygjB 2069 f2H/8Aiu6DoBrQLPuRXpGz+/XIr0cLdHyJygeHTWYmkcqr/7PnNOghr0QRY5 2070 5+lUoP9upVkDocdmZwLWVZAlVKxCB3XooHDwSBoyRHl9za8U19eqleSOoII4 2071 L2tWaNuwXAEetagi4fHRo+3bTx8J0CvMd3Ysg7kCwVgd7iJwH7TiBa0mbZWJ 2072 KNx/dCdniD9S/u/Mlftn0P9Qgv+LJJf/Fi7/pSpO4zogb1GWW82iA3bj3D9s 2073 IyUQWkwNnK0F9galsI1rgb1D07oSVQGJKIny3tjdz1T5oE3Q+t5u/FtOB4nL 2074 tP+oGCXkP0XJ8b9y8l+9dAEJEH5MURHhp8WSkhADI5BENYos3zFowzfq1AdR 2075 kNtoqD9S4CYKfkPVUd7Z2drZ2orIbxvfuKxvVKq7bIwd7EBLk9DITKnunAKc 2076 OFGCE5cuwgH+O8zzl6n/IQkGe5HbgTgVwT385+P/6oz/amL8V9PG/6xD/9jI 2077 f7sUDv6zRvzTLnOt0xaLjPtHpf7Qn33IV+ND/nBkF3+k5qHjKgWleanyP+wl 2078 CflfFnP8L6L1h1EBIyR8e2/a2KprMXyLBPdMO4ljsCyXIkv8OJ8eM48fOBr7 2079 iSZpEsJIhDEfxn+TNkgdM6/LDNO/fWiYQ7eLPJQCRoJHXCjpiR0i4J0MFIUE 2080 GTPaffsU1tOEAD2TaWdkIgpPzg1EWItymN3zCwu6NlFa0LVtEau51Sdvl8f/ 2081 2fNgvtpfBvsPKHsx/z9Guf63cPkvgwL47CIuAAmzwIsLgsok1W997TE7bVse 2082 8FzHDWqWc3LYbrVcL/CPapa/lbZx3wpqDK7wyHOfnxUjh/MNFvP7tIPjvbvu 2083 becsuS/FVTg2tB3dPxRM1zaKwMeL8NqE48gs8Tc+tKyYaHlsnVRdY6n+PySj 2084 qP9fDPU/Wc3xv0j5T8K6pCsqQaJwzIKAeRxnwrHHaEMAcAkeqzKrw0E2WUJE 2085 cUkPE10DVLssgnXqG65J2nWMCHx1TAJXbsO3mkl9wmqh5Yf6ujWS+IikSzGp 2086 71Yau+opikSnjm9afbnvVprg1yPUEa47htNgJBWkE8Q76GRCvnubf/8qcGxv 2087 yf4fVZbj+McI5/hfGfvv+MitvalFWOf+fvjj4kmO9rZz4p3FPe2p0kKXWRT4 2088 hdEgGezE4w785JBd5P4dqYiJjMm5Xfs6tAuYhqfYhhdhHK7CS02by/X/SCpK 2089 jP9qbv9ZSHu8/4uDw6P9xyFeU8GfQJFPg7bnXMjxO7L88svF7LUDy83dhvn0 2090 pN7wggddyrx79wZG3/RDIowB9EcR7SVvb8AZsDDobYTv8LNuirqKZVnG0PZO 2091 umKU8+y0nYbjdp0QJ++ecbiPf7xU/MtKEv+5/v9jxb9GNBgqLwnzJA3zt84F 2092 +t132SVkHNseO12q/Y8HCMTxT/L8n1XBfzZRP7m3H6iFZbFO6gQnkoC09bWD 2093 mDCv61z5Nx2b2A0Mr4CIYwN1/yrxQN+R6D8C+2QzBZbTWFUYpzzBXAd3OlKT 2094 omEkYw9qcI/j+7NEyEjwwqc9n6TKo6sAHEnn+JH3olEk54mRSek90VAv0nr+ 2095 4cyXEA0jZNZ4cu/WjMb86rzdP7P9/zzmZ4z/4zz/a/H2H1j8ArnNOWxBQhEW 2096 FmVYyXGhoMo+K6g4jemFgtZBAQP/6jD4gEdYZX70fH1bLNES7E9dX7N6uSFI 2097 D43CjXrDwcR1YAUVSSQxBPOUUCmr2Ydz3XRPzRQn//qaMLRQFZQ7ackgO7Ad 2098 HsOOU1DEJqt04MNuQ6flApEKRNy9JO45kXnmYQF5uxj/x0u2/ytKQv7nIWE5 2099 /1+I/F+QVBCZC5Lc0wE8dmL5gUe90kRtYKPwSyDvR1V7zHfbXnVM5t0dpvfP 2100 pAzZv4kJrlPDrI8FhXGm75x2XSJ5p5hYRKp73DtYdWxMHM9uOD6PCxv30N+Z 2101 mQWIkV4wX/gOs6MjiE4kSYg+i9SExTH7AbUt6os9p2DMJXinoHyVIMW98LA4 2102 afKcJCQkMcI5mSAA/07btpfr/ydqHP8yye1/K6b/89ekWECoyL9M0nAnEvUt 2103 e7qOe/U7pqQDEx0j4hhmp1E3qG82TklXcgPvFFHDN4El0I4xTAmWiK5x2W+K 2104 3j/L6ReJ0xkBEbqwlzhwN4VqEuH98tthMAT8e23PWm7+fwr+pdz/t2j9L27A 2105 ++Kx2w5YpUDuxHhDgexfSm0AIoEGpKXlhE3Kvg/5x6S4gFBVLHKpoVYv0joj 2106 x14ReMMp0rVu0aRd5tXwabEmOfKIfQCrgaEfT9cdi65ZDGqsWAPxJXvA3zxN 2107 aLkSmLfLaZbjt80l639SSvyXmPt/ls3/Rzy+zy3DuK3ZHgZdvhBjtPu5t+fk 2108 hfpEd4Ke10fJgv+gyYLaUuU/TBL1H3P5b0HtOrwAzGN+YDknxQfwJrhGmIQn 2109 K6qmP7u5+X2pYDkGY8aNlyGTEJ+1nbbfpnbpyeODl58FbvGYXffbHvv855bv 2110 3Ag2reDT7apHX5x9sbW9s3Oz/HMr2KxRvyJudZnlGddvtqj/add9aTwLXLf0 2111 meEyfljRCj7fmx1+MrDviNOCOEvXC4py89nm9zde9u1VX+7fL//qQ+HhE/i4 2112 Itzla3/TN0qdtz+pZq7AbTBHfPl97wu+sfms943cLFwvFXsXarYdgzox45cJ 2113 hz/iMSY3brzcvPkMiAuVjR9+9/pvf/jt6z/A8p+w/A+svwrXf/f6H2D5DXz/ 2114 L1j+eyMUop+FV3op3tj8Hq5WLEUE4q7rGYVf3iteL8HTuLHHV79/+flnu7fK 2115 v9re+Mu/+OKv/ypSWkvEmGiycI73IS64Yx6wyp4Dj/eBqX/NqME8uHbh5uYz 2116 +CnKP/zH6z++/t8f/vX1v7z+N/j7d6//6Yd/f/2Pr/+48iky77j818GyRJZq 2117 /1MUJRn/n9v/Fi3/PQH578u9bDGAlhmcdEuTPL6bIkFElmUR2h6Qlqq2BQAf 2118 j7CDq1VaNddhuzzjrwrMqRgaHPrnSNzNTpMahlfx/bi1fWCB2OTFAwYBfVGy 2119 8ctFGKSoimra/UVCimRlKPBeblGYN6jqd5nMEfDfDpbt/0MJ/x/GOf5XSP/L 2120 Wg3zjdKCtNDwL031DYwXiTJ806rzQt7EGMWCyJI0JQzOd5ssW53QyXDvBweb 2121 rtekQVJ8kUL55VaIXXgmwq1WtdkWeJJxZUOSyMY2bLy1Pdi95N/fdp2TeQcA 2122 z8C/wvfF6j/JGOX4Xxn8h0rUgcCDuAQqcDrBoU0muKYA8r7HmuwNP4SW53KA 2123 ALo2UnN7ywq8H2NR+WKlw7wz/vpe5tKhdpvt8G/hRXgv571U/Br0vHfheXQp 2124 bQl1TgaK3kP4+M4Kag/dp/wGuEbb49G0SV+ACmiHt9Nj2Pxm57k5GReNdW0V 2125 /0tYGryKtVDLncu7UuldInKF8B25nD+D+w9/dZv5/rALl/4lMnqD9O0xWDlb 2126 /N/Bq2YNJQWi8cgBNBQVnvSeSPE+UF7mUuQYKwv9B168bCgXe7/n/M7fGvCK 2127 YsjzK4u4UtinFNsfcCZCxtW0TpICj1M8TVKIMYq066A4ze0EDdZjNAfJ84zX 2128 A+M0KedRY31KuR+sxGlSziPHaNLuR4rTpJwn9oyfCmUhQRN7yp00mvhzFoTk 2129 tVD8PEkaUU/8XilEWpIohUqd/dOLSgYaOQONlIGGZKDBGWgyvNIimk2jzybR 2130 ZpNkeMgZnnGGR5zhCWd4wFme7wyShE7ZL5hjVIZ2nYGauSghbxFLr0t9dj0z 2131 YnYJMuUF5uywf0xBOXZwEsw7AHCm/W9s/q9Q/1flXP9fpP6fXlDrcqL8dKyL 2132 CV9hNNBf3IvYvvsOydlhJvIcZ+lR0CXb84ko6QRrKlo1PmB3fcPyW0v1/xFV 2133 jONflvP8n4W0y5n/b6OHvY1bKXxgVJlvRtw/DzOgx1VjzwQN8yzNGaegCZU5 2134 OV9IHJVu1s8n/4vjf/nx/xJK4F/J638u2/6/I9jebBbQg/ZzkxV1GM00jRRf 2135 6GaWqsCkV5894e+TYymAvGCoVefTP/C5l8L4/i4I972vmkWR33WI5DXCtKK+ 2136 E1AkSEXcl5ShHsbE4kWY6NNkDHHxMsZ0FWNlZYy8rTT/5wwwWOr8XypJ6n85 2137 /18k/0+X/yZWgH0jhVDTRGksbQtJbXQKeojZcE5BBgRGLxGk69TgCeC0y8he 2138 iiwoajrRtBlVP8RZ8iDRB5Ve58LjV9+M1Kzay67/g2RVieMfiXn8/wrpf+cu 2139 qcMLKmCSjU24fPKGNLMRTzcaYxRSmNzpcDnQ9awa7ZqGS4kreTJ2ieX5o3mC 2140 RBlEoZGymABmQhNVUJJKjgM+YM+D7ZZNLYfD+ghum93wBccVuvRMCFyB+0Xh 2141 0XSFJnXOBLcasMAXqMcEn08y4TODEx0zgR9YWg0ltGn5TRpUa/NkAjPtP3Lc 2142 /ivBthz/q2f/uVBcJ5FkLGee/oXXIfSfG6adtaB7bvK5FPzj5eFfRTiJ/9z+ 2143 u5D2cP+7B/tHX3979+3gABMl9ZigPp1TTC4BONszTPSLiPRp0vxKWGiabTuw 2144 5qwBzLL/ikrC/0uUfP6Xpdh/AdAtEF4z5n9geRbuBu87lrPWh+/nXY0gP2AS 2145 usanidqLIKhPqs+kxVOY1NCGzc3RvATxZJ1lsCehsWSxd4eVr3gubbYAlGmm 2146 Z6LEHnvCgn5ODoUneq/xpRdRyOWwVWpO1Z6z9SeD/CfF7b9YkXL9b9n+v0nW 2147 XyxLbyoPhqYdIk2SALEYmo88WcJdMowJQhligkiW4n7jdyWTNzPyFi8y7xcv 2148 dDMhXIgsNFzQcT1GfddZ6vw/GCf8Pyj3/yykDeb/hJ9IePO5PQ3fwQTpdQpI 2149 5jN8WrxGr65jzOt5TpzDPZ/Nc4njv9thtl9davyfhOVk/ac8/3+x9l+XtkrH 2150 jLXK29sj0JMyQQhfThiwloj0IePOHQQaktOL+IHTo1PgME63FwDUsEe1ukmv 2151 hPCkObr7uRh6Fs+vlNceOm27wTFdbv1vVUr4f2Upt/+ujvwf5v8/8ErCNyWB 2152 1+XpjaJJ0X830+S/KXNdiRNrfEwL8tfjgnvWObBkvSwjGWVgC5kDPcgy5sG6 2153 BBXAYye0HSx5/l9JTYz/JI//WEib8/x/mkqwWKtjImIt0wR3fcyHSAZWMXFG 2154 Pz7Oj2yUE9T+2+2g5nrWixC5ZeGh+63D7jlu1z+qWf5htcYrj7gtetpmRXj9 2155 aYXHZSTA/W5LBID/Y2pUg+XO/4vj+Ffy/L9Vw/809KdiX9c1QvDUlJ8GkWTq 2156 ezYxjePOnohK/J84SgKcNp0nkUuiBtSEL2TKFMRjM4hOn+QAltL4RAfvevQI 2157 4J9PAbJc/EvR+u8kt/+9G/jXzgP9uFP3Emf2eTDBwjgL+m/RLD4Xbz4oVNSb 2158 7xSAM/V/IsXxL6Nc/l8R/KcXYMfTDGxEwr5hupPN9lFbwRTrP+baOK7XhoFg 2159 RNF0IvEEElUSdT5xMMERDhHNG3S65LTuYeKilqF3qGOfkq7j2Q7rumad+nrb 2160 SsomBEF/95+3LI+FRokFtMmuifEnzAuJCjusd28VrCGsq7KuKARrovwGZswe 2161 /u2TZeJf7sV/j8n/ai7/L9T/JyMiHDKvY1WZ8MShHWrZ9Nhm54Q/CuH/4sVz 2162 w+LzdvrdzAwgEVLV5wAMoFw3Wb07NArgMDFEI5Kq8tQxhAkRo6keAx7gdFwK 2163 92B5jkt9hlyTx5XWHHzqmi7lK5iyrsnP5fEC5IF3VrxtBsyDS0g6QVgjGjwU 2164 /slX+XV0DUSa76jnWM4JT0CDy7od5gVtjwkbB47wyHNPAJ3+xlvkVvCN1tLz 2165 v3iyZ2z8R3n97xWz/4dGvmdJJWBy7mQ8NjRDSYCpxQDGbIQ8QMgA3mCsr92u 2166 Vlkr6GdnOe6xa5wNjXzncAqIM6atGkvqXJm5AN7UEeCzprXk+h9IVpLyf27/ 2167 W0yL53/tQCcr7YKEIuA8P1OYCHXXO+lFAxAs4WnxAKkOAW00zA9AH4Pe1tiG 2168 VqPqq8Wm1WRbXHzutTDjAXoZbDet58zYimzwrRMHtkRoYTSnJwx2wJkjK6ZH 2169 T6axkrcnD83nT2e5+R8qSo7/RM7zPxY9/vcrll4sBZwDe/ylBzHdc3qxOxEt 2170 IO0i45qAzxxjnGMMjQFhZhiz2lFGQU2nUWee1XZPYQ/tOA2bmqxRPwXRvy2R 2171 Nu2yYVkgjcvwMIIOhYFZFUv795Lo6m5SLCBiMm4gzll2Rpyl11qeG7hV165s 2172 xNlWUS3yYyhXLjYSxzWB1D6p+DUqJvYdu3ymOe+sslGERqQ7X8n6HcCbIol3 2173 7yJN1WVdgibK6h11/8sNzpCKxSykid6N+CE/Sf4mXfBNWoWh7LzxLlI05L3X 2174 t1Upa3LR13kaAnfC+U4qG+FoWWqpURX/yOMhyswr7jtV1whNA8eWAwAckdy1 2175 /JbrW70oBBrAa1FrwvYdwbRsljzz+hp69dHff/CTm7/++tf/t371w2u/f/XR 2176 GWxqX7t6VfwY/eSD9zd/+t61P3//Cvp4RHT1968+eIFevaejV9f++ffvXbt6 2177 7dpHV3575TfXPr1yFa0P6a6+D4e1wrO89+RPPvjk2pND8RP0M77y0SccC5bp 2178 eo5FxZ+hP+MbP/zko0PqfOP6TPwp+lO+Ze2T9+G1sQLxc3SDr3/8/+1dDVAb 2179 xxVGApuaBJNgYpJi2i2044Qg2PuR0QkrQ+o0iakrbAubjONJfOhOSEjc4bsT 2180 Mo49QdiN40xTZjJuZuI2sRk3YzIdd9o49jieJA52fsfJGDEpzQ/QNJ7Wps3P 2181 uNNpUpqf7t5JIAkJcNqIlO7Hj3R7t6fV23333r597+0SFz5sFFVtlahoPg8m 2182 ohh1vdA64beK8yFDQZqiWJahrZuK8yl0SNmih7D5v9KYEngdPs4uKpzK9TB8 2183 IJ4CpgVZ2eEHs2B4rzkczjq7y7ywoPCVcUvxfQ9V9qrDf+06VVLywMf11JW+ 2184 4OMbD7sLjr97y1tj+4bf2P9FZ8cLzb/vu+A8+8895b8+tfzhD0aa3U07AjeG 2185 hnfAK1yOD47966dHu+8d+vTnNU8fHO0+UHJVeIjuO3LgN3n3Lbr+Ys+ed5/u 2186 PCneUP/y0GDkgW2v+BsOM3uc5eZsU5bpUHgMhv8MS9E3KL06ZyksCqf6FphI 2187 pUtyzDDLuHJxztKcorovll1ZcsK75oniXY+2j+38ZOTOLREY3o/Pl+eEH4Lh 2188 nq4i/63FRX/Z1/G9rkZpSePbvecbi3qP92q/VDI6DrpNWUnDMBtRX/78m7Wb 2189 L+aeGan87B9j2+5dvWz3Ox8PR0qfHOq7f2f1+b9V/cK775Hvd/8p7+AfPl/2 2190 rPP0aXPxrm+fPrKi4NLzo6V/vNh+VeX4Ix+uXbPz+TeDFW5E2ttHRsdHN7w0 2191 sO7S643nLvS7lu9tfnzlR/yJYP9nK7Ux5buVJ03U0RMv5Z762dFt36l84vBd 2192 hGEIwxCGuQyGobpNQ7DbNIhEEdyRUXrEceekBDwY/i28doJIi7KpeIkIl02e 2193 WUAVRNmKpqw00v82wfLJszkUGhn11b/7sX/LwpvpReMbD/a/ua7znbN3w/WT 2194 FxVQP4CrYN7CbxgF2blw8cR7s9mc1YW6a/LYVAdzjWbmJpZfn8RaOeGu/jPX 2195 rfx733OF246t33+u98XS0dFz+Y4X+nte3H9n4eK2DQdWuw6defnVe5xHdt1/ 2196 aW3P9sFPt752z2ODu2/bu+XQ+5907n5v0zVP/cp9ae2ZBe3HqU3ly8+HP7z6 2197 ome4aMHbN1xYc9psCsvXLB3Zy9Bv9b0nn3y/fMfqhpvGP3I+M1hYObqzafT1 2198 2alLFgsJ3Z6H0BC3fdUB4DP6fyXkfzfWf1ji/5Vp+w8f4KW6Vl6V23zRdBcN 2199 AE1XkkuNCbbCB9q9iUbfH/F3WDwNShO/XnDZAerytA7e8e5ed3Ru395poe1A 2200 8/pUgH41rwikYFszmlGiyRMwgkOMqxj7xHxbL0jw0UANEHljadYjy6AZ9Srq 2201 MdxgWcYHiv6SYi5rm+1yDuYVdH+HnsNjvvA/nr3irTfVOcz/tSLZ/ssyFOH/ 2202 OVn/+XL7P/xH+z4AyePmRK9H8PCi39fqZXm/IPFbW/0hpNKrvOrBC0BpjGSz 2203 2hli5jTASZVcqxpRLXq6WgFebRW8nmT/mDUuoDHT1KM5GwxKAv5Gic10/tDZ 2204 0OQEGjtNZV4VoIcRpRROOdP6wUKe8wkeSRRTLEFpSkida/lvhVP9P8j+D5nn 2205 f0VskzXRgujRknrRF4B0/mD66Esz4rGrBuQSTfdpPijRfh+Q0SPFooiqHFTc 2206 YqoHC8eiqZyNSzDiiyFF9rmDDMtZsZVeEj04gtyr0AxrVWZ8kNCMjYsPLk9t 2207 158/EeNBya+6277aJ8DM8R/MlPVfwv+Z5f8kvykjONKuyRrePNmIkXQbA59k 2208 g5hPwPzfRs8x/zNx8Z81UOd/yBL+zwRmF//lU5slO9JdmRqOttUwE1Laq2k4 2209 YUwoFKpKpfYjxkzr01Xn7Wz3ihKviYIlOY33pDBmORgf4DFVGqdPOErNJiR0 2210 JV59tdfLXuluV5tP8970/5YtPCjNef43CtLx8p/V4z8pkv8xI4hp9jSEwAHo 2211 igoGVABrRQUNBp4deA5EwpFu9DLw1MCxgScjPbgsqSjSHfkJsICBU5Gu2LmB 2212 Y9P5RnK2JJ6kGJrlEjaEhUg9sLFQz5bL+rHQ9zOttKiERMGj3uyaJpVc2mBU 2213 ijK2m0ujtYhC0HANomkulcs3NysXmVRhXJxtSoa5y0sTw9nSus5wtmqKrvk6 2214 by9N8DVHSPVJHXMb/0PVWKfofzRL4n8zvf7T4esQ/S11bi/vUyyCpLgTJk1o 2215 ooAmhxKiAR+vHDYAe37ezNVBLQAAPWCxJ6IDPcAoG/5hGCk/z6PgneaAHZTV 2216 g/WyKkrNotICNm/eXFYWdV00so0JCj5ZNyUmFv/Dd3boSd9bBduXXYlKfOrr 2217 TdJjfdyqnn0YQg5/VFwcEb4CUQKAanSxTg6ARZ3hczmhh8akHcNBNap+qpho 2218 TjF0Ky+1BEThdpEXcNwhAJIY8hhloIMPBEV0Kzzr9klBVDL15AajT4z6TUh9 2219 3SAF1SAf2IhP20FtbWUl+qudUXbpiRBwP0ZdVfUwUDWh+wNKbASE0Oc49AbE 2220 SiySbNELUId02EGMJrrBsBrgOTiG2u7D4i5hVES7z6AQHhkAxHx+ff5WGwDY 2221 gXWCxMYd0VusT+gEplbYqmirtQpJd3yv6I0cqFIsEh2HbSLhZy9bF5TRVAOo 2222 muKT0PAqw8Mr7cBCt0LUNsa6I+ZDi0r0b2m0WcX2EMG4pBZsRW2HVczlZ4FL 2223 mweazYxY3y4i9vPM8fyfhsn6P7OC6P//Q+t/01n6WryqwFJJG36qvNCKTXkB 2224 j9RGy3SAZRRrEBrmvgTTHkNT06zszWqPT2xF8CXbDiBJ/UpAQEBAQEBAQEBA 2225 QEBAQEBAQEBAQEBAQEBAQEBAQEBAQDAP8G/qAJOHABgBAA== 2226 -- END MESSAGE ARCHIVE -- 2228 Intellectual Property Statement 2230 The IETF takes no position regarding the validity or scope of any 2231 intellectual property or other rights that might be claimed to 2232 pertain to the implementation or use of the technology described in 2233 this document or the extent to which any license under such rights 2234 might or might not be available; neither does it represent that it 2235 has made any effort to identify any such rights. Information on the 2236 IETF's procedures with respect to rights in standards-track and 2237 standards-related documentation can be found in BCP-11. Copies of 2238 claims of rights made available for publication and any assurances of 2239 licenses to be made available, or the result of an attempt made to 2240 obtain a general license or permission for the use of such 2241 proprietary rights by implementors or users of this specification can 2242 be obtained from the IETF Secretariat. 2244 The IETF invites any interested party to bring to its attention any 2245 copyrights, patents or patent applications, or other proprietary 2246 rights which may cover technology that may be required to practice 2247 this standard. Please address the information to the IETF Executive 2248 Director. 2250 Full Copyright Statement 2252 Copyright (C) The Internet Society (2004). All Rights Reserved. 2254 This document and translations of it may be copied and furnished to 2255 others, and derivative works that comment on or otherwise explain it 2256 or assist in its implementation may be prepared, copied, published 2257 and distributed, in whole or in part, without restriction of any 2258 kind, provided that the above copyright notice and this paragraph are 2259 included on all such copies and derivative works. However, this 2260 document itself may not be modified in any way, such as by removing 2261 the copyright notice or references to the Internet Society or other 2262 Internet organizations, except as needed for the purpose of 2263 developing Internet standards in which case the procedures for 2264 copyrights defined in the Internet Standards process must be 2265 followed, or as required to translate it into languages other than 2266 English. 2268 The limited permissions granted above are perpetual and will not be 2269 revoked by the Internet Society or its successors or assignees. 2271 This document and the information contained herein is provided on an 2272 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2273 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2274 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2275 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2276 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2278 Acknowledgment 2280 Funding for the RFC Editor function is currently provided by the 2281 Internet Society.