idnits 2.17.1 draft-ietf-sipping-torture-tests-07.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 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2174. ** 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. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances 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 -- 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 (April 2005) is 6944 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: 3 errors (**), 0 flaws (~~), 5 warnings (==), 11 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 Estacado Systems 4 Expires: October 3, 2005 A. Hawrylyshen 5 Jasomi Networks 6 A. Johnston 7 MCI 8 J. Rosenberg 9 Cisco Systems 10 H. Schulzrinne 11 Columbia University 12 April 2005 14 Session Initiation Protocol Torture Test Messages 15 draft-ietf-sipping-torture-tests-07 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 3, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2005). 46 Abstract 48 This informational document gives examples of Session Initiation 49 Protocol (SIP) test messages designed to exercise and "torture" a SIP 50 implementation. 52 Table of Contents 54 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 4 56 2.1 Representing Long Lines . . . . . . . . . . . . . . . . . 4 57 2.2 Representing Non-printable Characters . . . . . . . . . . 5 58 2.3 Representing Long Repeating Strings . . . . . . . . . . . 5 59 3. SIP Test Messages . . . . . . . . . . . . . . . . . . . . . 6 60 3.1 Parser tests (syntax) . . . . . . . . . . . . . . . . . . 6 61 3.1.1 Valid messages . . . . . . . . . . . . . . . . . . . . 6 62 3.1.1.1 A short tortuous INVITE . . . . . . . . . . . . . 6 63 3.1.1.2 Wide range of valid characters . . . . . . . . . . 8 64 3.1.1.3 Valid use of the % escaping mechanism . . . . . . 9 65 3.1.1.4 Escaped nulls in URIs . . . . . . . . . . . . . . 10 66 3.1.1.5 Use of % when it is not an escape . . . . . . . . 11 67 3.1.1.6 Message with no LWS between display name and < . . 11 68 3.1.1.7 Long values in header fields . . . . . . . . . . . 12 69 3.1.1.8 Extra trailing octets in a UDP datagram . . . . . 14 70 3.1.1.9 Semicolon separated parameters in URI user part . 15 71 3.1.1.10 Varied and unknown transport types . . . . . . . 16 72 3.1.1.11 S/MIME signed message . . . . . . . . . . . . . 16 73 3.1.1.12 Unusual reason phrase . . . . . . . . . . . . . 18 74 3.1.1.13 Empty reason phrase . . . . . . . . . . . . . . 19 75 3.1.2 Invalid messages . . . . . . . . . . . . . . . . . . . 20 76 3.1.2.1 Extraneous header field separators . . . . . . . . 20 77 3.1.2.2 Content length larger than message . . . . . . . . 20 78 3.1.2.3 Negative Content-Length . . . . . . . . . . . . . 21 79 3.1.2.4 Request scalar fields with overlarge values . . . 22 80 3.1.2.5 Response scalar fields with overlarge values . . . 23 81 3.1.2.6 Unterminated quoted string in display-name . . . . 23 82 3.1.2.7 <> enclosing Request-URI . . . . . . . . . . . . . 24 83 3.1.2.8 Malformed SIP Request-URI (embedded LWS) . . . . . 25 84 3.1.2.9 Multiple SP separating Request-Line elements . . . 26 85 3.1.2.10 SP characters at end of Request-Line . . . . . . 27 86 3.1.2.11 Escaped headers in SIP Request-URI . . . . . . . 28 87 3.1.2.12 Invalid timezone in Date header field . . . . . 28 88 3.1.2.13 Failure to enclose name-addr URI in <> . . . . . 29 89 3.1.2.14 Spaces within addr-spec . . . . . . . . . . . . 30 90 3.1.2.15 Non-token characters in display-name . . . . . . 30 91 3.1.2.16 Unknown protocol version . . . . . . . . . . . . 31 92 3.1.2.17 Start line and CSeq method mismatch . . . . . . 31 93 3.1.2.18 Unknown Method with CSeq method mismatch . . . . 32 94 3.1.2.19 Overlarge response code . . . . . . . . . . . . 32 95 3.2 Transaction layer semantics . . . . . . . . . . . . . . . 33 96 3.2.1 Missing transaction identifier . . . . . . . . . . . . 33 98 3.3 Application layer semantics . . . . . . . . . . . . . . . 33 99 3.3.1 Missing Required Header Fields . . . . . . . . . . . . 34 100 3.3.2 Request-URI with unknown scheme . . . . . . . . . . . 34 101 3.3.3 Request-URI with known but atypical scheme . . . . . . 35 102 3.3.4 Unknown URI schemes in header fields . . . . . . . . . 35 103 3.3.5 Proxy-Require and Require . . . . . . . . . . . . . . 36 104 3.3.6 Unknown Content-Type . . . . . . . . . . . . . . . . . 36 105 3.3.7 Unknown authorization scheme . . . . . . . . . . . . . 37 106 3.3.8 Multiple values in single value required fields . . . 38 107 3.3.9 Multiple Content-Length values . . . . . . . . . . . . 38 108 3.3.10 200 OK Response with broadcast Via header field 109 value . . . . . . . . . . . . . . . . . . . . . . . 39 110 3.3.11 Max-Forwards of zero . . . . . . . . . . . . . . . . 40 111 3.3.12 REGISTER with a contact header parameter . . . . . . 40 112 3.3.13 REGISTER with a url parameter . . . . . . . . . . . 41 113 3.3.14 REGISTER with a url escaped header . . . . . . . . . 42 114 3.3.15 Unacceptable Accept offering . . . . . . . . . . . . 42 115 3.4 Backward compatibility . . . . . . . . . . . . . . . . . . 43 116 3.4.1 INVITE with RFC2543 syntax . . . . . . . . . . . . . . 43 117 4. Security Considerations . . . . . . . . . . . . . . . . . . 44 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 119 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 44 120 7. Informative References . . . . . . . . . . . . . . . . . . . 45 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45 122 A. Bit-exact archive of each test message . . . . . . . . . . . 46 123 A.1 Encoded Reference Messages . . . . . . . . . . . . . . . . 47 124 Intellectual Property and Copyright Statements . . . . . . . 52 126 1. Overview 128 This document is informational, and is NOT NORMATIVE on any aspect of 129 SIP. 131 This document contains test messages based on the current version 132 (2.0) of the Session Initiation Protocol as defined in [RFC3261]. 133 Some messages exercise SIP's use of SDP as described in [RFC3264]. 135 These messages were developed and refined at the SIPIt 136 interoperability test events. 138 The test messages are organized into several sections. Some stress 139 only a SIP parser and others stress both the parser and the 140 application above it. Some messages are valid, and some are not. 141 Each example clearly calls out what makes any invalid messages 142 incorrect. 144 This document does not attempt to catalog every way to make an 145 invalid message, nor does it attempt to be comprehensive in exploring 146 unusual, but valid, messages. Instead, it tries to focus on areas 147 that have caused interoperability problems or have particularly 148 unfavorable characteristics if they are handled improperly. This 149 document is a seed for a test plan, not a test plan in itself. 151 The messages are presented in the text using a set of markup 152 conventions to avoid ambiguity and meet Internet-Draft layout 153 requirements. To resolve any remaining ambiguity, a bit-accurate 154 version of each message is encapsulated in an appendix. 156 2. Document Conventions 158 This document contains many example SIP messages. Although SIP is a 159 text-based protocol, many of these examples cannot be unambiguously 160 rendered without additional markup due to the constraints placed on 161 the formatting of RFCs. This document defines and uses the markup 162 defined in this section to remove that ambiguity. This markup uses 163 the start and end tag conventions of XML, but does not define any XML 164 document type. 166 The appendix contains an encoded binary form of all the messages and 167 the algorithm needed to decode them into files. 169 2.1 Representing Long Lines 171 Several of these examples contain unfolded lines longer than 72 172 characters. These are captured between tags. The 173 single unfolded line is reconstructed by directly concatenating all 174 lines appearing between the tags (discarding any line-feeds or 175 carriage returns). There will be no whitespace at the end of lines. 176 Any whitespace appearing at a fold-point will appear at the beginning 177 of a line. 179 The following represent the same string of bits: 181 Header-name: first value, reallylongsecondvalue, third value 183 184 Header-name: first value, 185 reallylongsecondvalue 186 , third value 187 189 190 Header-name: first value, 191 reallylong 192 second 193 value, 194 third value 195 197 Note that this is NOT SIP header line folding where different strings 198 of bits have equivalent meaning. 200 2.2 Representing Non-printable Characters 202 Several examples contain binary message bodies or header field values 203 containing non-ascii range UTF-8 encoded characters. These are 204 rendered here as a pair of hexadecimal digits per octet between 205 tags. This rendering applies even inside quoted-strings. 207 The following represent the same string of bits: 209 Header-name: value one 211 Header-name: value206F6Ee 213 The following is a Subject header field containing the euro symbol: 215 Subject: E282AC 217 2.3 Representing Long Repeating Strings 219 Several examples contain very large data values created with 220 repeating bit strings. Those will be rendered here using value. As with this rendering 222 applies even inside quoted-strings. 224 For example, the value "abcabcabc" can be rendered as abc. A display name of "1000000 bottles of beer" 226 could be rendered as 228 To: "130 bottles of beer" 229 231 and a Max-Forwards header field with a value of one google will be 232 rendered here as 234 Max-Forwards: 10 236 3. SIP Test Messages 238 3.1 Parser tests (syntax) 240 3.1.1 Valid messages 242 3.1.1.1 A short tortuous INVITE 244 This short, relatively human-readable message contains: 245 o line folding all over 246 o escaped characters within quotes 247 o an empty subject 248 o LWS between colons, semicolons, header field values, and other 249 fields 250 o both comma separated and separate listing of header field values 251 o mix of short and long form for the same header field name 252 o unkown Request-URI parameter 253 o unknown header fields 254 o unknown header field with a value that would be syntactically 255 invalid if it were defined in terms of generic-param 256 o unusual header field ordering 257 o unusual header field name character case 258 o unknown parameters of a known header field 259 o uri parameter with no value 260 o header parameter with no value 261 o integer fields (Max-Forwards and CSeq) with leading zeros 262 All elements should treat this as a well-formed request. 264 The UnknownHeaderWithUnusualValue header field deserves special 265 attention. If this header field were defined in terms of comma 266 separated values with semicolon separated parameters (as many of the 267 existing defined header fields), this would be invalid. However, 268 since the receiving element does not know the definition of the 269 syntax for this field, it must parse it as a header-value. Proxies 270 would forward this header field unchanged. Endpoints would ignore 271 the header field. 273 Message Details : wsinv 275 INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 276 TO : 277 sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n 278 from : "J Rosenberg \\\"" 279 ; 280 tag = 98asjd8 281 MaX-fOrWaRdS: 0068 282 Call-ID: wsinv.ndaksdj@192.0.2.1 283 Content-Length : 150 284 cseq: 0009 285 INVITE 286 Via : SIP / 2.0 287 /UDP 288 192.0.2.2;branch=390skdjuw 289 s : 290 NewFangledHeader: newfangled value 291 continued newfangled value 292 UnknownHeaderWithUnusualValue: ;;,,;;,; 293 Content-Type: application/sdp 294 Route: 295 296 v: SIP / 2.0 / TCP spindle.example.com ; 297 branch = z9hG4bK9ikj8 , 298 SIP / 2.0 / UDP 192.168.255.111 ; branch= 299 z9hG4bK30239 300 m:"Quoted string \"\"" ; newparam = 301 newvalue ; 302 secondparam ; q = 0.33 304 v=0 305 o=mhandley 29739 7272939 IN IP4 192.0.2.3 306 s=- 307 c=IN IP4 192.0.2.4 308 t=0 0 309 m=audio 49217 RTP/AVP 0 12 310 m=video 3227 RTP/AVP 31 311 a=rtpmap:31 LPC 313 3.1.1.2 Wide range of valid characters 315 This message exercises a wider range of characters in several key 316 syntactic elements than implementations usually see. Of particular 317 note: 318 o The Method contains non-alpha characters from token. Note that % 319 is not an escape character for this field. A method of IN%56ITE 320 is an unknown method. It is not the same as a method of INVITE 321 o The Request-URI contain unusual, but legal, characters 322 o A branch parameter contains all non-alphanum characters from token 323 o The To header field value's quoted-string contains quoted-pair 324 expansions, including a quoted NULL character 325 o The name part of name-addr in the From header field value contains 326 multiple tokens (instead of a quoted string) with all non-alphanum 327 characters from the token production rule. That value also has an 328 unknown header parameter whose name contains the non-alphanum 329 token characters and whose value is a non-ascii range UTF-8 330 encoded string. The tag parameter on this value contains the non- 331 alphanum token characters 332 o The Call-ID header field value contains the non-alphanum 333 characters from word. Notice that in this production: 334 * % is not an escape character. (It is only an escape character 335 in productions matching the rule "escaped") 336 * " does not start a quoted-string. None of ',` or " imply that 337 there will be a matching symbol later in the string 338 * The characters []{}()<> do not have any grouping semantics. 339 They are not required to appear in balanced pairs 340 o There is an unknown header field (matching extension-header) with 341 non-alphanum token characters in its name and a UTF8-NONASCII 342 value 344 If this unusual URI has been defined at a proxy, the proxy will 345 forward this request normally. Otherwise a proxy will generate a 346 404. Endpoints will generate a 501 listing the methods they 347 understand in an Allow header field. 349 Message Details : intmeth 351 352 !interesting-Method0123456789_*+`.%indeed'~ 353 sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;* 354 :&it+has=1,weird!*pas$wo~d_too.(doesn't-it) 355 @example.com SIP/2.0 356 357 Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~ 358 359 To: "BEL:\07 NUL:\00 DEL:\7F" 360 362 363 364 From: token1~` token2'+_ token3*%!.- 365 ;fromParam''~+*_!.-%= 366 "D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9" 367 ;tag=_token~1'+`*%!-. 368 369 Call-ID: intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{ 370 CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~ 371 Max-Forwards: 255 372 373 extensionHeader-!.%*+_`'~: 374 EFBBBFE5A4A7E5819CE99BBB 375 376 Content-Length: 0 378 3.1.1.3 Valid use of the % escaping mechanism 380 This INVITE exercises the % HEX HEX escaping mechanism in several 381 places. The request is syntactically valid. Interesting features 382 include: 383 o The request-URI has sips:user@example.com embedded in its 384 userpart. What that might mean to example.net is beyond the scope 385 of this document. 386 o The From and To URIs have escaped characters in their userparts. 387 o The Contact URI has escaped characters in the URI parameters. 388 Note that the "name" uri-parameter has a value of "value%41" which 389 is NOT equivalent to "valueA". Per [RFC2396], unescaping URI 390 components is never performed recursively. 392 A parser must accept this as a well-formed message. The application 393 using the message must treat the % HEX HEX expansions as equivalent 394 to the character being encoded. The application must not try to 395 interpret % as an escape character in those places where % HEX HEX 396 ("escaped" in the grammar) is not a valid part of the construction. 397 In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, 398 SIPS-URI, and Reason-Phrase. 400 Message Details : esc01 402 INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0 403 To: sip:%75se%72@example.com 404 From: ;tag=938 405 Max-Forwards: 87 406 i: esc01.239409asdfakjkn23onasd0-3234 407 CSeq: 234234 INVITE 408 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw 409 C: application/sdp 410 Contact: 411 412 Content-Length: 150 414 v=0 415 o=mhandley 29739 7272939 IN IP4 192.0.2.1 416 s=- 417 c=IN IP4 192.0.2.1 418 t=0 0 419 m=audio 49217 RTP/AVP 0 12 420 m=video 3227 RTP/AVP 31 421 a=rtpmap:31 LPC 423 3.1.1.4 Escaped nulls in URIs 425 This register request contains several URIs with nulls in the 426 userpart. The message is well formed - parsers must accept this 427 message. Implementations must take special care when unescaping the 428 Address-of-Record (AOR) in this request to not prematurely shorten 429 the username. This request registers two distinct contact URIs. 431 Message Details : escnull 433 REGISTER sip:example.com SIP/2.0 434 To: sip:null-%00-null@example.com 435 From: sip:null-%00-null@example.com;tag=839923423 436 Max-Forwards: 70 437 Call-ID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd 438 CSeq: 14398234 REGISTER 439 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 440 Contact: 441 Contact: 442 L:0 444 3.1.1.5 Use of % when it is not an escape 446 Most of the places % can appear in a SIP message, it is not an escape 447 character. This can surprise the unwary implementor. The following 448 well-formed request has these properties: 449 o The request method is unknown. It is NOT equivalent to REGISTER 450 o The display-name portion of the To and From header fields is 451 "%Z%45". Note that this is not the same as %ZE 452 o This message has two Contact header field values, not three. 453 is a C%6Fntact header field value 455 A parser should accept this message as well formed. A proxy would 456 forward or reject the message depending on what the Request-URI meant 457 to it. An endpoint would reject this message with a 501. 459 Message Details : esc02 461 RE%47IST%45R sip:registrar.example.com SIP/2.0 462 To: "%Z%45" 463 From: "%Z%45" ;tag=f232jadfj23 464 Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf 465 Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234 466 CSeq: 29344 RE%47IST%45R 467 Max-Forwards: 70 468 Contact: 469 C%6Fntact: 470 Contact: 471 l: 0 473 3.1.1.6 Message with no LWS between display name and < 475 This OPTIONS request is not valid per the grammar in RFC 3261 since 476 there is no LWS between the quoted string in the display name and < 477 in the From header field value. This has been identified as a 478 specification bug that will be removed when RFC 3261 is revised. 479 Elements should accept this request as well formed. 481 Message Details : lwsdisp 483 OPTIONS sip:user@example.com SIP/2.0 484 To: sip:user@example.com 485 From: "caller";tag=323 486 Max-Forwards: 70 487 Call-ID: lwsdisp.1234abcd@funky.example.com 488 CSeq: 60 OPTIONS 489 Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw 490 l: 0 492 3.1.1.7 Long values in header fields 494 This well-formed request contains header fields with many values and 495 values that are very long. Features include: 496 o The To header field has a long display name, and long uri 497 parameter names and values 498 o The From header field has long header parameter names and values, 499 in particular a very long tag 500 o The Call-ID is one long token 502 Message Details : longreq 504 INVITE sip:user@example.com SIP/2.0 505 506 To: "I have a user name of 507 extreme proportion" 508 longvalue; 510 longparamname=shortvalue; 511 verylongParameterNameWithNoValue> 512 513 514 F: sip: 515 amazinglylongcallername@example.net 516 ;tag=12982424 517 ;unknownheaderparamname= 518 unknowheaderparamvalue 519 ;unknownValuelessparamname 520 521 Call-ID: longreq.onereallylongcallid 522 CSeq: 3882340 INVITE 523 524 Unknown-Long-Name: 525 unknown-long-value; 526 unknown-long-parameter-name = 527 unknown-long-parameter-value 528 529 Via: SIP/2.0/TCP sip33.example.com 530 v: SIP/2.0/TCP sip32.example.com 531 V: SIP/2.0/TCP sip31.example.com 532 Via: SIP/2.0/TCP sip30.example.com 533 ViA: SIP/2.0/TCP sip29.example.com 534 VIa: SIP/2.0/TCP sip28.example.com 535 VIA: SIP/2.0/TCP sip27.example.com 536 via: SIP/2.0/TCP sip26.example.com 537 viA: SIP/2.0/TCP sip25.example.com 538 vIa: SIP/2.0/TCP sip24.example.com 539 vIA: SIP/2.0/TCP sip23.example.com 540 V : SIP/2.0/TCP sip22.example.com 541 v : SIP/2.0/TCP sip21.example.com 542 V : SIP/2.0/TCP sip20.example.com 543 v : SIP/2.0/TCP sip19.example.com 544 Via : SIP/2.0/TCP sip18.example.com 545 Via : SIP/2.0/TCP sip17.example.com 546 Via: SIP/2.0/TCP sip16.example.com 547 Via: SIP/2.0/TCP sip15.example.com 548 Via: SIP/2.0/TCP sip14.example.com 549 Via: SIP/2.0/TCP sip13.example.com 550 Via: SIP/2.0/TCP sip12.example.com 551 Via: SIP/2.0/TCP sip11.example.com 552 Via: SIP/2.0/TCP sip10.example.com 553 Via: SIP/2.0/TCP sip9.example.com 554 Via: SIP/2.0/TCP sip8.example.com 555 Via: SIP/2.0/TCP sip7.example.com 556 Via: SIP/2.0/TCP sip6.example.com 557 Via: SIP/2.0/TCP sip5.example.com 558 Via: SIP/2.0/TCP sip4.example.com 559 Via: SIP/2.0/TCP sip3.example.com 560 Via: SIP/2.0/TCP sip2.example.com 561 Via: SIP/2.0/TCP sip1.example.com 562 563 Via: SIP/2.0/TCP 564 host.example.com;received=192.0.2.5; 565 branch=verylongbranchvalue 566 567 Max-Forwards: 70 568 569 Contact: amazinglylongcallername 571 @host5.example.net> 572 573 Content-Type: application/sdp 574 l: 150 575 v=0 576 o=mhandley 29739 7272939 IN IP4 192.0.2.1 577 s=- 578 c=IN IP4 192.0.2.1 579 t=0 0 580 m=audio 49217 RTP/AVP 0 12 581 m=video 3227 RTP/AVP 31 582 a=rtpmap:31 LPC 584 3.1.1.8 Extra trailing octets in a UDP datagram 586 This message contains a single SIP REGISTER request, which ostensibly 587 arrived over UDP in a single datagram. The packet contains extra 588 octets after the body (which in this case has zero length). The 589 extra octets happen to look like a SIP INVITE request, but (per 590 section 18.3 of [RFC3261]) they are just spurious noise that must be 591 ignored. 593 A SIP element receiving this datagram would handle the REGISTER 594 request normally and ignore the extra bits that look like an INVITE 595 request. If the element is a proxy choosing to forward the REGISTER, 596 the INVITE octets would not appear in the forwarded request. 598 Message Details : dblreq 600 REGISTER sip:example.com SIP/2.0 601 To: sip:j.user@example.com 602 From: sip:j.user@example.com;tag=43251j3j324 603 Max-Forwards: 8 604 I: dblreq.0ha0isndaksdj99sdfafnl3lk233412 605 Contact: sip:j.user@host.example.com 606 CSeq: 8 REGISTER 607 Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492 608 Content-Length: 0 610 INVITE sip:joe@example.com SIP/2.0 611 t: sip:joe@example.com 612 From: sip:caller@example.net;tag=141334 613 Max-Forwards: 8 614 Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15 615 CSeq: 8 INVITE 616 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234 617 Content-Type: application/sdp 618 Content-Length: 150 620 v=0 621 o=mhandley 29739 7272939 IN IP4 192.0.2.15 622 s=- 623 c=IN IP4 192.0.2.15 624 t=0 0 625 m=audio 49217 RTP/AVP 0 12 626 m =video 3227 RTP/AVP 31 627 a=rtpmap:31 LPC 629 3.1.1.9 Semicolon separated parameters in URI user part 631 This request has a semicolon-separated parameter contained in the 632 "user" part of the Request-URI (whose value contains an escaped @ 633 symbol). Receiving elements will accept this as a well formed 634 message. The Request-URI will parse such that the user part is 635 "user;par=u@example.net". 637 Message Details : semiuri 639 OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0 640 To: sip:j_user@example.com 641 From: sip:caller@example.org;tag=33242 642 Max-Forwards: 3 643 Call-ID: semiuri.0ha0isndaksdj 644 CSeq: 8 OPTIONS 645 Accept: application/sdp, application/pkcs7-mime, 646 multipart/mixed, multipart/signed, 647 message/sip, message/sipfrag 648 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw 649 l: 0 651 3.1.1.10 Varied and unknown transport types 653 This request contains Via header field values with all known 654 transport types and exercises the transport extension mechanism. 655 Parsers must accept this message as well formed. Elements receiving 656 this message would process it exactly as if the 2nd and subsequent 657 header field values specified UDP (or other transport). 659 Message Details : transports 661 OPTIONS sip:user@example.com SIP/2.0 662 To: sip:user@example.com 663 From: ;tag=323 664 Max-Forwards: 70 665 Call-ID: transports.kijh4akdnaqjkwendsasfdj 666 Accept: application/sdp 667 CSeq: 60 OPTIONS 668 Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw 669 Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf 670 Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj 671 Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en 672 Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee 673 l: 0 675 3.1.1.11 S/MIME signed message 677 This is a signed MESSAGE request. The signature is binary encoded. 678 The body contains null (0x00) characters. Receivers must take care 679 to properly frame the received message. 681 Parsers must accept this message as well formed, even if the 682 application above the parser does not support multipart/signed. 684 Message Details : smime01 686 MESSAGE sip:kumiko@example.com SIP/2.0 687 To: 688 From: ;tag=2929017b 689 690 Via: SIP/2.0/UDP 127.0.0.1:5060 691 ;branch=z9hG4bK-d87543-5032442a6f48352f-1--d87543-;rport 692 693 Call-ID: 74dd6bf53ebdf741@Y2ouY2lzY28uc2lwaXQubmV0 694 CSeq: 1 MESSAGE 695 Route: 696 Contact: 697 Max-Forwards: 70 698 Content-Transfer-Encoding: binary 699 700 Content-Type: multipart/signed 701 ;boundary=4d7f63e86a96c361;micalg=sha1 702 ;protocol=application/pkcs7-signature 703 704 Date: Tue, 12 Apr 2005 17:30:54 GMT 705 User-Agent: SIPimp.org/0.2.5 (curses) 706 Content-Length: 1567 708 --4d7f63e86a96c361 709 Content-Type: text/plain 710 Content-Transfer-Encoding: binary 712 This has a null in the body. 713 --4d7f63e86a96c361 714 Content-Type: application/pkcs7-mime;name=smime.p7s 715 716 Content-Disposition: attachment;handling=required 717 ;filename=smime.p7s 718 719 Content-Transfer-Encoding: binary 721 722 308204E006092A864886F70D010702A08204D1308204CD020101310B3009 723 06052B0E03021A0500300B06092A864886F70D010701A08202D2308202CE 724 30820237A00302010202080195007102330113300D06092A864886F70D01 725 010505003070310B3009060355040613025553311330110603550408130A 726 43616C69666F726E69613111300F0603550407130853616E204A6F736531 727 0E300C060355040A1305736970697431293027060355040B132053697069 728 74205465737420436572746966696361746520417574686F72697479301E 729 170D3035303431323137313933385A170D3038303431313137313933385A 730 3062310B3009060355040613025553311330110603550408130A43616C69 731 666F726E69613111300F0603550407130853616E204A6F7365310E300C06 732 0355040A13057369706974311B301906035504031412666C756666794065 733 78616D706C652E636F6D30819F300D06092A864886F70D01010105000381 734 8D0030818902818100978BB1A8AE41595A61730F9DDB218A7EC4F30F33C8 735 584E5B7B063FCFABBB8F95BF1C3F763D85A70F1CE95374CE801CA74D333F 736 EA7913548BD8CA4E683C0495F6127B365B067C8A04EEF31D1E4DD7A99492 737 2DF15F468622B49B3DD3AACEF5CE36DFAF51FDBE68AAFBDFB50274365450 738 DF147F544BB5F2BE3BCEFBE39291B764EB0203010001A37F307D30510603 739 551D11044A304886167369703A666C75666679406578616D706C652E636F 740 6D8615696D3A666C75666679406578616D706C652E636F6D861770726573 741 3A666C75666679406578616D706C652E636F6D30090603551D1304023000 742 301D0603551D0E041604146EA02972AF7BF578F284A873F7979DB3AD59EA 743 90300D06092A864886F70D01010505000381810010EB632291EB8560CCCB 744 C8FF9EB8481B8083A7AC2520AF79A4852CE997A0BF81272B8DBD5EB2CB72 745 97982BF66F20CB5758D85C9C90426571269D4523FA67C86BD72BF94A1C34 746 2054529F92B370D1C55A1A75F4BC17423B2BBB53CE289AEAD505925F3786 747 74A5BDAC658CFD48D8C600F21B9E7DDE5A1135E1FE273BA75392DFAE3182 748 01D6308201D2020101307C3070310B300906035504061302555331133011 749 0603550408130A43616C69666F726E69613111300F060355040713085361 750 6E204A6F7365310E300C060355040A130573697069743129302706035504 751 0B1320536970697420546573742043657274696669636174652041757468 752 6F7269747902080195007102330113300906052B0E03021A0500A081B130 753 1806092A864886F70D010903310B06092A864886F70D010701301C06092A 754 864886F70D010905310F170D3035303431323137333035335A302306092A 755 864886F70D010904311604140E5123C664D47E6B9BBE2630DD21D2496580 756 11B0305206092A864886F70D01090F31453043300A06082A864886F70D03 757 07300E06082A864886F70D030202020080300D06082A864886F70D030202 758 0140300706052B0E030207300D06082A864886F70D0302020128300D0609 759 2A864886F70D010101050004818018EEAA35F807FF7C7F96B747722367C9 760 5F72FCD74140721B36BF638375D5DBF13EF4F00A71DC7E3E866E1D51C14B 761 C91AC2FF8369FF56F2F16603701570A9273355A8D5875718204FABAF5DB7 762 480A718560B89F1E28F9186431BB2B2452D45DFC68C0EE42DD808C70355B 763 4BC18F7954DED86ED20AFD57275A6A1DFAAEE607C482 764 --4d7f63e86a96c361-- 766 3.1.1.12 Unusual reason phrase 768 This 200 response contains a reason phrase other than "OK". The 769 reason phrase is intended for human consumption, and may contain any 770 string produced by 772 Reason-Phrase = *(reserved / unreserved / escaped 773 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) 775 This particular response contains unreserved and non-ASCII UTF-8 776 characters.This response is well formed. A parser must accept this 777 message. 779 Message Details : unreason 781 782 SIP/2.0 200 = 2**3 * 5**2 D0BDD0BE20D181D182 783 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4 784 D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 785 BED0B5 786 787 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 788 Call-ID: unreason.1234ksdfak3j2erwedfsASdf 789 CSeq: 35 INVITE 790 From: sip:user@example.com;tag=11141343 791 To: sip:user@example.edu;tag=2229 792 Content-Length: 154 793 Content-Type: application/sdp 794 Contact: 796 v=0 797 o=mhandley 29739 7272939 IN IP4 192.0.2.198 798 s=- 799 c=IN IP4 192.0.2.198 800 t=0 0 801 m=audio 49217 RTP/AVP 0 12 802 m=video 3227 RTP/AVP 31 803 a=rtpmap:31 LPC 805 3.1.1.13 Empty reason phrase 807 This well formed response contains no reason phrase. A parser must 808 accept this message. The space character after the reason code is 809 required. If it were not present, this message could be rejected as 810 invalid (a liberal receiver would accept it anyway). 812 Message Details : noreason 814 SIP/2.0 10020 815 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 816 Call-ID: noreason.asndj203insdf99223ndf 817 CSeq: 35 INVITE 818 From: ;tag=39ansfi3 819 To: ;tag=902jndnke3 820 Content-Length: 0 821 Contact: 823 3.1.2 Invalid messages 825 This section contains several invalid messages reflecting errors seen 826 at interoperability events and exploring important edge conditions 827 that can be induced through malformed messages. This section does 828 not attempt to be a comprehensive list of all types of invalid 829 messages. 831 3.1.2.1 Extraneous header field separators 833 The Via header field of this request contains additional semicolons 834 and commas without parameters or values. The Contact header field 835 contains additional semicolons without parameters. This message is 836 syntactically invalid. 838 An element receiving this request should respond with a 400 Bad 839 Request error. 841 Message Details : badinv01 843 INVITE sip:user@example.com SIP/2.0 844 To: sip:j.user@example.com 845 From: sip:caller@example.net;tag=134161461246 846 Max-Forwards: 7 847 Call-ID: badinv01.0ha0isndaksdjasdf3234nas 848 CSeq: 8 INVITE 849 Via: SIP/2.0/UDP 192.0.2.15;;,;,, 850 Contact: "Joe" ;;;; 851 Content-Length: 152 852 Content-Type: application/sdp 854 v=0 855 o=mhandley 29739 7272939 IN IP4 192.0.2.15 856 s=- 857 c=IN IP4 192.0.2.15 858 t=0 0 859 m=audio 49217 RTP/AVP 0 12 860 m=video 3227 RTP/AVP 31 861 a=rtpmap:31 LPC 863 3.1.2.2 Content length larger than message 865 This is a request message with a Content Length that is larger than 866 the actual length of the body. 868 When sent over UDP (as this message ostensibly was), the receiving 869 element should respond with a 400 Bad Request error. If this message 870 arrived over a stream-based transport such as TCP, there's not much 871 the receiving could do but wait for more data on the stream and close 872 the connection if none is forthcoming in a reasonable period of time. 874 Message Details : clerr 876 INVITE sip:user@example.com SIP/2.0 877 Max-Forwards: 80 878 To: sip:j.user@example.com 879 From: sip:caller@example.net;tag=93942939o2 880 Contact: 881 Call-ID: clerr.0ha0isndaksdjweiafasdk3 882 CSeq: 8 INVITE 883 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523 884 Content-Type: application/sdp 885 Content-Length: 9999 887 v=0 888 o=mhandley 29739 7272939 IN IP4 192.0.2.155 889 s=- 890 c=IN IP4 192.0.2.155 891 t=0 0 892 m=audio 49217 RTP/AVP 0 12 893 m=video 3227 RTP/AVP 31 894 a=rtpmap:31 LPC 896 3.1.2.3 Negative Content-Length 898 This request has a negative value for Content-Length. 900 An element receiving this message should respond with an error. This 901 request appeared over UDP, so the remainder of the datagram can 902 simply be discarded. If a request like this arrives over TCP, the 903 framing error is not recoverable and the connection should be closed. 904 The same behavior is appropriate for messages that arrive without a 905 numeric value in the Content-Length header field such as: 907 Content-Length: five 909 Implementors should take extra precautions if the technique they 910 choose for converting this ascii field into an integral form can 911 return a negative value. In particular, the result must not be used 912 as a counter or array index. 914 Message Details : ncl 916 INVITE sip:user@example.com SIP/2.0 917 Max-Forwards: 254 918 To: sip:j.user@example.com 919 From: sip:caller@example.net;tag=32394234 920 Call-ID: ncl.0ha0isndaksdj2193423r542w35 921 CSeq: 0 INVITE 922 Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw 923 Contact: 924 Content-Type: application/sdp 925 Content-Length: -999 927 v=0 928 o=mhandley 29739 7272939 IN IP4 192.0.2.53 929 s=- 930 c=IN IP4 192.0.2.53 931 t=0 0 932 m=audio 49217 RTP/AVP 0 12 933 m=video 3227 RTP/AVP 31 934 a=rtpmap:31 LPC 936 3.1.2.4 Request scalar fields with overlarge values 938 This request contains several scalar header field values outside 939 their legal range. 940 o the CSeq sequence number is >2**32-1. 941 o the Max-Forwards value is >255. 942 o the Expires value is >2**32-1. 943 o the Contact expires parameter value is >2**32-1. 945 An element receiving this request should respond with a 400 Bad 946 Request due to the CSeq error. If only the Max-Forwards field were 947 in error, the element could choose process the request as if the 948 field were absent. If only the expiry values were in error, the 949 element could treat them as if they contained the default values for 950 expiration (3600 in this case). 952 Other scalar request fields that may contain aberrant values include, 953 but are not limited to, the Contact q value, the Timestamp value, 954 and the Via ttl parameter. 956 Message Details : scalar02 958 REGISTER sip:example.com SIP/2.0 959 Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3 960 To: 961 From: ;tag=239232jh3 962 CSeq: 36893488147419103232 REGISTER 963 Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32 964 Max-Forwards: 300 965 Expires: 10 966 Contact: 967 ;expires=280297596632815 968 Content-Length: 0 970 3.1.2.5 Response scalar fields with overlarge values 972 This response contains several scalar header field values outside 973 their legal range. 974 o the CSeq sequence number is >2**32-1. 975 o The Retry-After field is unreasonably large (note that RFC 3261 976 does not define a legal range for this field). 977 o The Warning field has a warning-value with more than 3 digits 979 An element receiving this response will simply discard it. 981 Message Details : scalarlg 983 SIP/2.0 503 Service Unavailable 984 985 Via: SIP/2.0/TCP host129.example.com 986 ;branch=z9hG4bKzzxdiwo34sw 987 ;received=192.0.2.129 988 989 To: 990 From: ;tag=2easdjfejw 991 CSeq: 9292394834772304023312 OPTIONS 992 Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r 993 Retry-After: 949302838503028349304023988 994 Warning: 1812 overture "In Progress" 995 Content-Length: 0 997 3.1.2.6 Unterminated quoted string in display-name 999 This is a request with an unterminated quote in the display name of 1000 the To field. An element receiving this request should return an 400 1001 Bad Request error. 1003 An element could attempt to infer a terminating quote and accept the 1004 message. Such an element needs to take care that it makes a 1005 reasonable inference when it encounters 1007 To: "Mr J. User 1009 Message Details : quotbal 1011 INVITE sip:user@example.com SIP/2.0 1012 To: "Mr. J. User 1013 From: sip:caller@example.net;tag=93334 1014 Max-Forwards: 10 1015 Call-ID: quotbal.aksdj 1016 Contact: 1017 CSeq: 8 INVITE 1018 Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234 1019 Content-Type: application/sdp 1020 Content-Length: 152 1022 v=0 1023 o=mhandley 29739 7272939 IN IP4 192.0.2.15 1024 s=- 1025 c=IN IP4 192.0.2.15 1026 t=0 0 1027 m=audio 49217 RTP/AVP 0 12 1028 m=video 3227 RTP/AVP 31 1029 a=rtpmap:31 LPC 1031 3.1.2.7 <> enclosing Request-URI 1033 This INVITE request is invalid because the Request-URI has been 1034 enclosed within in "<>". 1036 It is reasonable to always reject a request with this error with a 1037 400 Bad Request. Elements attempting to be liberal with what they 1038 accept may choose to ignore the brackets. If the element forwards 1039 the request, it must not include the brackets in the messages it 1040 sends. 1042 Message Details : ltgtruri 1044 INVITE SIP/2.0 1045 To: sip:user@example.com 1046 From: sip:caller@example.net;tag=39291 1047 Max-Forwards: 23 1048 Call-ID: ltgtruri.1@192.0.2.5 1049 CSeq: 1 INVITE 1050 Via: SIP/2.0/UDP 192.0.2.5 1051 Contact: 1052 Content-Type: application/sdp 1053 Content-Length: 159 1055 v=0 1056 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1057 s=- 1058 c=IN IP4 192.0.2.5 1059 t=3149328700 0 1060 m=audio 49217 RTP/AVP 0 12 1061 m=video 3227 RTP/AVP 31 1062 a=rtpmap:31 LPC 1064 3.1.2.8 Malformed SIP Request-URI (embedded LWS) 1066 This INVITE has illegal LWS within the Request-URI. 1068 An element receiving this request should respond with a 400 Bad 1069 Request. 1071 An element could attempt to ignore the embedded LWS for those schemes 1072 (like sip) where that would not introduce ambiguity. 1074 Message Details : lwsruri 1076 INVITE sip:user@example.com; lr SIP/2.0 1077 To: sip:user@example.com;tag=3xfe-9921883-z9f 1078 From: sip:caller@example.net;tag=231413434 1079 Max-Forwards: 5 1080 Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423 1081 CSeq: 2130706432 INVITE 1082 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395 1083 Contact: 1084 Content-Type: application/sdp 1085 Content-Length: 159 1087 v=0 1088 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1089 s=- 1090 c=IN IP4 192.0.2.1 1091 t=3149328700 0 1092 m=audio 49217 RTP/AVP 0 12 1093 m=video 3227 RTP/AVP 31 1094 a=rtpmap:31 LPC 1096 3.1.2.9 Multiple SP separating Request-Line elements 1098 This INVITE has illegal multiple SP characters between elements of 1099 the start line. 1101 It is acceptable to reject this request as malformed. An element 1102 that is liberal in what it accepts may ignore these extra SP 1103 characters while processing the request. If the element forwards the 1104 request, it must not include these extra SP characters in the 1105 messages it sends. 1107 Message Details : lwsstart 1109 INVITE sip:user@example.com SIP/2.0 1110 Max-Forwards: 8 1111 To: sip:user@example.com 1112 From: sip:caller@example.net;tag=8814 1113 Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com 1114 CSeq: 1893884 INVITE 1115 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923 1116 Contact: 1117 Content-Type: application/sdp 1118 Content-Length: 150 1120 v=0 1121 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1122 s=- 1123 c=IN IP4 192.0.2.1 1124 t=0 0 1125 m=audio 49217 RTP/AVP 0 12 1126 m=video 3227 RTP/AVP 31 1127 a=rtpmap:31 LPC 1129 3.1.2.10 SP characters at end of Request-Line 1131 This OPTIONS request contains SP characters between the SIP-Version 1132 field and the CRLF terminating the Request-Line. 1134 It is acceptable to reject this request as malformed. An element 1135 that is liberal in what it accepts may ignore these extra SP 1136 characters while processing the request. If the element forwards the 1137 request, it must not include these extra SP characters in the 1138 messages it sends. 1140 Message Details : trws 1142 OPTIONS sip:remote-target@example.com SIP/2.02020 1143 Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093 1144 To: 1145 From: ;tag=329429089 1146 Call-ID: trws.oicu34958239neffasdhr2345r 1147 Accept: application/sdp 1148 CSeq: 238923 OPTIONS 1149 Max-Forwards: 70 1150 Content-Length: 0 1152 3.1.2.11 Escaped headers in SIP Request-URI 1154 This INVITE is malformed as the SIP Request-URI contains escaped 1155 headers. 1157 It is acceptable for an element to reject this request with a 400 Bad 1158 Request. An element could choose to be liberal in what it accepts 1159 and ignore the escaped headers. If the element is a proxy, the 1160 escaped headers must not appear in the Request-URI of forwarded 1161 request (and most certainly must not be translated into the actual 1162 header of the forwarded request). 1164 Message Details : escruri 1166 INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0 1167 To: sip:user@example.com 1168 From: sip:caller@example.net;tag=341518 1169 Max-Forwards: 7 1170 Contact: 1171 Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 1172 CSeq: 149209342 INVITE 1173 Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw 1174 Content-Type: application/sdp 1175 Content-Length: 150 1177 v=0 1178 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1179 s=- 1180 c=IN IP4 192.0.2.1 1181 t=0 0 1182 m=audio 49217 RTP/AVP 0 12 1183 m=video 3227 RTP/AVP 31 1184 a=rtpmap:31 LPC 1186 3.1.2.12 Invalid timezone in Date header field 1188 This INVITE is invalid as it contains a non GMT time zone in the SIP 1189 Date header field. 1191 It is acceptable to reject this request as malformed (though an 1192 element shouldn't do that unless the contents of the Date header 1193 field were actually important to its processing). An element wishing 1194 to be liberal in what it accepts could ignore this value altogether 1195 if it wasn't going to use the Date header field anyhow. Otherwise, 1196 it could attempt to interpret this date and adjust it to GMT. 1198 RFC 3261 explicitly defines the only acceptable timezone designation 1199 as "GMT". "UT", while synonymous with GMT per [RFC2822], is not 1200 valid. "UTC" and "UCT" are also invalid. 1202 Message Details : baddate 1204 INVITE sip:user@example.com SIP/2.0 1205 To: sip:user@example.com 1206 From: sip:caller@example.net;tag=2234923 1207 Max-Forwards: 70 1208 Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234 1209 CSeq: 1392934 INVITE 1210 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1211 Date: Fri, 01 Jan 2010 16:00:00 EST 1212 Contact: 1213 Content-Type: application/sdp 1214 Content-Length: 150 1216 v=0 1217 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1218 s=- 1219 c=IN IP4 192.0.2.5 1220 t=0 0 1221 m=audio 49217 RTP/AVP 0 12 1222 m=video 3227 RTP/AVP 31 1223 a=rtpmap:31 LPC 1225 3.1.2.13 Failure to enclose name-addr URI in <> 1227 This REGISTER request is malformed. The SIP URI contained in the 1228 Contact Header field has an escaped header, so the field must be in 1229 name-addr form (which implies the URI must be enclosed in <>). 1231 It is reasonable for an element receiving this request to respond 1232 with a 400 Bad Request. An element choosing to be liberal in what it 1233 accepts could infer the angle brackets since there is no ambiguity in 1234 this example. In general, that won't be possible. 1236 Message Details : regbadct 1238 REGISTER sip:example.com SIP/2.0 1239 To: sip:user@example.com 1240 From: sip:user@example.com;tag=998332 1241 Max-Forwards: 70 1242 Call-ID: regbadct.k345asrl3fdbv@10.0.0.1 1243 CSeq: 1 REGISTER 1244 Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 1245 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 1246 l: 0 1248 3.1.2.14 Spaces within addr-spec 1250 This request is malformed since the addr-spec in the To header field 1251 contains spaces. Parsers receiving this request must not break. It 1252 is reasonable to reject this request with a 400 Bad Request response. 1253 Elements attempting to be liberal may ignore the spaces. 1255 Message Details : badaspec 1257 OPTIONS sip:user@example.org SIP/2.0 1258 Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234 1259 Max-Forwards: 70 1260 From: "Bell, Alexander" ;tag=433423 1261 To: "Watson, Thomas" < sip:t.watson@example.org > 1262 Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3 1263 Accept: application/sdp 1264 CSeq: 3923239 OPTIONS 1265 l: 0 1267 3.1.2.15 Non-token characters in display-name 1269 This OPTIONS request is malformed since the display names in the To 1270 and From header fields contain non-token characters but are unquoted. 1272 It is reasonable to always reject this kind of error with a 400 Bad 1273 Request response. 1275 An element may attempt to be liberal in what it receives and infer 1276 the missing quotes. If this element were a proxy, it must not 1277 propagate the error into the request it forwards. As a consequence, 1278 if the fields are covered by a signature, there's not much point in 1279 trying to be liberal - the message should be simply rejected. 1281 Message Details : baddn 1283 OPTIONS sip:t.watson@example.org SIP/2.0 1284 Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw 1285 Max-Forwards: 70 1286 From: Bell, Alexander ;tag=43 1287 To: Watson, Thomas 1288 Call-ID: baddn.31415@c.example.com 1289 Accept: application/sdp 1290 CSeq: 3923239 OPTIONS 1291 l: 0 1293 3.1.2.16 Unknown protocol version 1295 To an element implementing [RFC3261], this request is malformed due 1296 to its high version number. 1298 The element should respond to the request with a 505 Version Not 1299 Supported error. 1301 Message Details : badvers 1303 OPTIONS sip:t.watson@example.org SIP/7.0 1304 Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw 1305 Max-Forwards: 70 1306 From: A. Bell ;tag=qweoiqpe 1307 To: T. Watson 1308 Call-ID: badvers.31417@c.example.com 1309 CSeq: 1 OPTIONS 1310 l: 0 1312 3.1.2.17 Start line and CSeq method mismatch 1314 This request has mismatching values for the method in the start line 1315 and the CSeq header field. Any element receiving this request will 1316 respond with a 400 Bad Request. 1318 Message Details : mismatch01 1320 OPTIONS sip:user@example.com SIP/2.0 1321 To: sip:j.user@example.com 1322 From: sip:caller@example.net;tag=34525 1323 Max-Forwards: 6 1324 Call-ID: mismatch01.dj0234sxdfl3 1325 CSeq: 8 INVITE 1326 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1327 l: 0 1329 3.1.2.18 Unknown Method with CSeq method mismatch 1331 This message has an unknown method in the start line, and a CSeq 1332 method tag which does not match. 1334 Any element receiving this response should respond with a 501 Not 1335 Implemented. A 400 Bad Request is also acceptable, but choosing a 1336 501 (particularly at proxies) has better future-proof 1337 characteristics. 1339 Message Details : mismatch02 1341 NEWMETHOD sip:user@example.com SIP/2.0 1342 To: sip:j.user@example.com 1343 From: sip:caller@example.net;tag=34525 1344 Max-Forwards: 6 1345 Call-ID: mismatch02.dj0234sxdfl3 1346 CSeq: 8 INVITE 1347 Contact: 1348 Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw 1349 Content-Type: application/sdp 1350 l: 138 1352 v=0 1353 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1354 c=IN IP4 192.0.2.1 1355 m=audio 49217 RTP/AVP 0 12 1356 m=video 3227 RTP/AVP 31 1357 a=rtpmap:31 LPC 1359 3.1.2.19 Overlarge response code 1361 This response has a response code larger than 699. An element 1362 receiving this response should simply drop it. 1364 Message Details : bigcode 1366 SIP/2.0 4294967301 better not break the receiver 1367 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 1368 Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i 1369 CSeq: 353494 INVITE 1370 From: ;tag=39ansfi3 1371 To: ;tag=902jndnke3 1372 Content-Length: 0 1373 Contact: 1375 3.2 Transaction layer semantics 1377 This section contains tests that exercise an implementation's parser 1378 and transaction layer logic. 1380 3.2.1 Missing transaction identifier 1382 This request indicates support for RFC 3261-style transaction 1383 identifiers by providing the z9hG4bK prefix to the branch parameter, 1384 but it provides no identifier. A parser must not break when 1385 receiving this message. An element receiving this request could 1386 reject the request with a 400 Response (preferably statelessly, as 1387 other requests from the source are likely to also have a malformed 1388 branch parameter), or it could fall back to the RFC 2543 style 1389 transaction identifier. 1391 Message Details : badbranch 1393 OPTIONS sip:user@example.com SIP/2.0 1394 To: sip:user@example.com 1395 From: sip:caller@example.org;tag=33242 1396 Max-Forwards: 3 1397 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK 1398 Accept: application/sdp 1399 Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n 1400 CSeq: 8 OPTIONS 1401 l: 0 1403 3.3 Application layer semantics 1405 This section contains tests that exercise an implementation's parser 1406 and application layer logic. 1408 3.3.1 Missing Required Header Fields 1410 This request contains no Call-ID, From, or To header fields. 1412 An element receiving this message must not break because of the 1413 missing information. Ideally, it will respond with a 400 Bad Request 1414 error. 1416 Message Details : insuf 1418 INVITE sip:user@example.com SIP/2.0 1419 CSeq: 193942 INVITE 1420 Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf 1421 Content-Type: application/sdp 1422 l: 152 1424 v=0 1425 o=mhandley 29739 7272939 IN IP4 192.0.2.95 1426 s=- 1427 c=IN IP4 192.0.2.95 1428 t=0 0 1429 m=audio 49217 RTP/AVP 0 12 1430 m=video 3227 RTP/AVP 31 1431 a=rtpmap:31 LPC 1433 3.3.2 Request-URI with unknown scheme 1435 This OPTIONS contains an unknown URI scheme in the Request-URI. A 1436 parser must accept this as a well-formed SIP request. 1438 An element receiving this request will reject it with a 416 1439 Unsupported URI Scheme response. 1441 Some early implementations attempt to look at the contents of the To 1442 header field to determine how to route this kind of request. That is 1443 an error. Despite the fact that the To header field and the Request 1444 URI frequently look alike in simplistic first-hop messages, the To 1445 header field contains no routing information. 1447 Message Details : unkscm 1449 OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0 1450 To: sip:user@example.com 1451 From: sip:caller@example.net;tag=384 1452 Max-Forwards: 3 1453 Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34 1454 CSeq: 3923423 OPTIONS 1455 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1456 Content-Length: 0 1458 3.3.3 Request-URI with known but atypical scheme 1460 This OPTIONS contains an Request-URI with an IANA registered scheme 1461 that does not commonly appear Request-URIs of SIP requests. A parser 1462 must accept this as a well-formed SIP request. 1464 If an element will never accept this scheme as meaningful in a 1465 request-URI, it is appropriate to treat it as unknown and return a 1466 416 Unsupported URI Scheme response. If the element might accept 1467 some URIs with this scheme, then a 404 Not Found is appropriate for 1468 those URIs it doesn't accept. 1470 Message Details : novelsc 1472 OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0 1473 To: sip:user@example.com 1474 From: sip:caller@example.net;tag=384 1475 Max-Forwards: 3 1476 Call-ID: novelsc.asdfasser0q239nwsdfasdkl34 1477 CSeq: 3923423 OPTIONS 1478 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1479 Content-Length: 0 1481 3.3.4 Unknown URI schemes in header fields 1483 This message contains registered schemes in the To, From and Contact 1484 header fields of a request. The message is syntactically valid. 1485 Parsers must not fail when receiving this message. 1487 Proxies should treat this message as they would any other request for 1488 this URI. A registrar would reject this request with a 400 Bad 1489 Request response since the To: header field is required to contain a 1490 SIP or SIPS URI as an AOR. 1492 Message Details : unksm2 1494 REGISTER sip:example.com SIP/2.0 1495 To: isbn:2983792873 1496 From: ;tag=3234233 1497 Call-ID: unksm2.daksdj@hyphenated-host.example.com 1498 CSeq: 234902 REGISTER 1499 Max-Forwards: 70 1500 Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw 1501 Contact: 1502 l: 0 1504 3.3.5 Proxy-Require and Require 1506 This request tests proper implementation of SIP's Proxy-Require and 1507 Require extension mechanisms. 1509 Any element receiving this request will respond with a 420 Bad 1510 Extension response containing an Unsupported header field listing 1511 these features from either the Require or Proxy-Require header field 1512 depending on the role in which the element is responding. 1514 Message Details : bext01 1516 OPTIONS sip:user@example.com SIP/2.0 1517 To: sip:j_user@example.com 1518 From: sip:caller@example.net;tag=242etr 1519 Max-Forwards: 6 1520 Call-ID: bext01.0ha0isndaksdj 1521 Require: nothingSupportsThis, nothingSupportsThisEither 1522 Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis 1523 CSeq: 8 OPTIONS 1524 Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw 1525 Content-Length: 0 1527 3.3.6 Unknown Content-Type 1529 This INVITE request contains a body of unknown type. It is 1530 syntactically valid. A parser must not fail when receiving it. 1532 A proxy receiving this request would process it just like any other 1533 INVITE. An endpoint receiving this request would reject it with a 1534 415 Unsupported Media Type error. 1536 Message Details : invut 1538 INVITE sip:user@example.com SIP/2.0 1539 Contact: 1540 To: sip:j.user@example.com 1541 From: sip:caller@example.net;tag=8392034 1542 Max-Forwards: 70 1543 Call-ID: invut.0ha0isndaksdjadsfij34n23d 1544 CSeq: 235448 INVITE 1545 Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw 1546 Content-Type: application/unknownformat 1547 Content-Length: 40 1549 1553 3.3.7 Unknown authorization scheme 1555 This REGISTER request contains an Authorization header field with an 1556 unknown scheme. The request is well-formed. A parser must not fail 1557 when receiving it. 1559 A proxy will treat this request as any other REGISTER. If it 1560 forwards the request, it will include this Authorization header field 1561 unmodified in the forwarded messages. 1563 A registrar that does not care about challenge-response 1564 authentication will simply ignore the Authorization header field, 1565 processing this registration as if the field were not present. A 1566 registrar that does care about challenge-response authentication will 1567 reject this request with a 401, issuing a new challenge with a scheme 1568 it understands. 1570 Endpoints choosing not to act as registrars will simply reject the 1571 request. A 405 Method Not Allowed is appropriate. 1573 Message Details : regaut01 1575 REGISTER sip:example.com SIP/2.0 1576 To: sip:j.user@example.com 1577 From: sip:j.user@example.com;tag=87321hj23128 1578 Max-Forwards: 8 1579 Call-ID: regaut01.0ha0isndaksdj 1580 CSeq: 9338 REGISTER 1581 Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw 1582 Authorization: NoOneKnowsThisScheme opaque-data=here 1583 Content-Length:0 1585 3.3.8 Multiple values in single value required fields 1587 The message contains a request with multiple Call-ID, To, From, Max- 1588 Forwards and CSeq values. An element receiving this request must not 1589 break. 1591 An element receiving this request would respond with a 400 Bad 1592 Request error. 1594 Message Details : multi01 1596 INVITE sip:user@company.com SIP/2.0 1597 Contact: 1598 Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw 1599 Max-Forwards: 70 1600 CSeq: 5 INVITE 1601 Call-ID: multi01.98asdh@192.0.2.1 1602 CSeq: 59 INVITE 1603 Call-ID: multi01.98asdh@192.0.2.2 1604 From: sip:caller@example.com;tag=3413415 1605 To: sip:user@example.com 1606 To: sip:other@example.net 1607 From: sip:caller@example.net;tag=2923420123 1608 Content-Type: application/sdp 1609 l: 154 1610 Contact: 1611 Max-Forwards: 5 1613 v=0 1614 o=mhandley 29739 7272939 IN IP4 192.0.2.25 1615 s=- 1616 c=IN IP4 192.0.2.25 1617 t=0 0 1618 m=audio 49217 RTP/AVP 0 12 1619 m=video 3227 RTP/AVP 31 1620 a=rtpmap:31 LPC 1622 3.3.9 Multiple Content-Length values 1624 Multiple conflicting Content-Length header field values appear in 1625 this request. 1627 From a framing perspective, this situation is equivalent to an 1628 invalid Content-Length value (or no value at all). 1630 An element receiving this message should respond with an error. This 1631 request appeared over UDP, so the remainder of the datagram can 1632 simply be discarded. If a request like this arrives over TCP, the 1633 framing error is not recoverable and the connection should be closed. 1635 Message Details : mcl01 1637 OPTIONS sip:user@example.com SIP/2.0 1638 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423 1639 To: sip:user@example.com 1640 From: sip:other@example.net;tag=3923942 1641 Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf 1642 CSeq: 15932 OPTIONS 1643 Content-Length: 13 1644 Max-Forwards: 60 1645 Content-Length: 5 1646 Content-Type: text/plain 1648 There's no way to know how many octets are supposed to be here. 1650 3.3.10 200 OK Response with broadcast Via header field value 1652 This message is a response with a 2nd Via header field value's 1653 sent-by containing 255.255.255.255. The message is well formed - 1654 parsers must not fail when receiving it. 1656 Per [RFC3261] an endpoint receiving this message should simply 1657 discard it. 1659 If a proxy followed normal response processing rules blindly, it 1660 would forward this response to the broadcast address. To protect 1661 against this being used as an avenue of attack, proxies should drop 1662 such responses. 1664 Message Details : bcast 1666 SIP/2.0 200 OK 1667 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 1668 Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23 1669 Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf 1670 CSeq: 35 INVITE 1671 From: sip:user@example.com;tag=11141343 1672 To: sip:user@example.edu;tag=2229 1673 Content-Length: 154 1674 Content-Type: application/sdp 1675 Contact: 1677 v=0 1678 o=mhandley 29739 7272939 IN IP4 192.0.2.198 1679 s=- 1680 c=IN IP4 192.0.2.198 1681 t=0 0 1682 m=audio 49217 RTP/AVP 0 12 1683 m=video 3227 RTP/AVP 31 1684 a=rtpmap:31 LPC 1686 3.3.11 Max-Forwards of zero 1688 This is a legal SIP request with the Max-Forwards header field value 1689 set to zero. 1691 A proxy should not forward the request and respond 483 (Too Many 1692 Hops). An endpoint should process the request as if the Max-Forwards 1693 field value were still positive. 1695 Message Details : zeromf 1697 OPTIONS sip:user@example.com SIP/2.0 1698 To: sip:user@example.com 1699 From: sip:caller@example.net;tag=3ghsd41 1700 Call-ID: zeromf.jfasdlfnm2o2l43r5u0asdfas 1701 CSeq: 39234321 OPTIONS 1702 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i 1703 Max-Forwards: 0 1704 Content-Length: 0 1706 3.3.12 REGISTER with a contact header parameter 1708 This register request contains a contact where the 'unknownparam' 1709 parameter must be interpreted as being a contact-param and not a url- 1710 param. 1712 This REGISTER should succeed. The response must not include 1713 "unknownparam" as a url-parameter for this binding. Likewise, 1714 "unknownparam" must not appear as a url-parameter in any binding 1715 during subsequent fetches. 1717 Behavior is the same, of course, for any known contact-param 1718 parameter names. 1720 Message Details : cparam01 1722 REGISTER sip:example.com SIP/2.0 1723 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1724 Max-Forwards: 70 1725 From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe 1726 To: sip:watson@example.com 1727 Call-ID: cparam01.70710@saturn.example.com 1728 CSeq: 2 REGISTER 1729 Contact: sip:+19725552222@gw1.example.net;unknownparam 1730 l: 0 1732 3.3.13 REGISTER with a url parameter 1734 This register request contains a contact where the URI has an unknown 1735 parameter. 1737 The register should succeed and a subsequent retrieval of the 1738 registration must include "unknownparam" as a url-parameter. 1740 Behavior is the same, of course, for any known url-parameter names. 1742 Message Details : cparam02 1744 REGISTER sip:example.com SIP/2.0 1745 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1746 Max-Forwards: 70 1747 From: sip:watson@example.com;tag=838293 1748 To: sip:watson@example.com 1749 Call-ID: cparam02.70710@saturn.example.com 1750 CSeq: 3 REGISTER 1751 Contact: 1752 l: 0 1754 3.3.14 REGISTER with a url escaped header 1756 This register request contains a contact where the URI has an escaped 1757 header. 1759 The register should succeed and a subsequent retrieval of the 1760 registration must include the escaped Route header in the contact URI 1761 for this binding. 1763 Message Details : regescrt 1765 REGISTER sip:example.com SIP/2.0 1766 To: sip:user@example.com 1767 From: sip:user@example.com;tag=8 1768 Max-Forwards: 70 1769 Call-ID: regescrt.k345asrl3fdbv@192.0.2.1 1770 CSeq: 14398234 REGISTER 1771 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 1772 M: 1773 L:0 1775 3.3.15 Unacceptable Accept offering 1777 This request indicates the response must contain a body in an unknown 1778 type. In particular, since the Accept header field does not contain 1779 application/sdp, the response may not contain an SDP body. The 1780 recipient of this request could respond with a 406 Not Acceptable 1781 with a Warning/399 indicating that a response cannot be formulated in 1782 the formats offered in the Accept header field. It is also 1783 appropriate to respond with a 400 Bad Request since all SIP User- 1784 Agents (UAs) supporting INVITE are required to support application/ 1785 sdp. 1787 Message Details : sdp01 1789 INVITE sip:user@example.com SIP/2.0 1790 To: sip:j_user@example.com 1791 Contact: 1792 From: sip:caller@example.net;tag=234 1793 Max-Forwards: 5 1794 Call-ID: sdp01.ndaksdj9342dasdd 1795 Accept: text/nobodyKnowsThis 1796 CSeq: 8 INVITE 1797 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw 1798 Content-Length: 150 1799 Content-Type: application/sdp 1801 v=0 1802 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1803 s=- 1804 c=IN IP4 192.0.2.5 1805 t=0 0 1806 m=audio 49217 RTP/AVP 0 12 1807 m=video 3227 RTP/AVP 31 1808 a=rtpmap:31 LPC 1810 3.4 Backward compatibility 1812 3.4.1 INVITE with RFC2543 syntax 1814 This is a legal message per RFC 2543 (and several bis versions) which 1815 should be accepted by RFC 3261 elements which want to maintain 1816 backwards compatibility. 1817 o There is no branch parameter at all on the Via header field value 1818 o There is no From tag 1819 o There is no explicit Content-Length (The body is assumed to be all 1820 octets in the datagram after the null-line) 1821 o There is no Max-Forwards header field 1822 Message Details : inv2543 1824 INVITE sip:UserB@example.com SIP/2.0 1825 Via: SIP/2.0/UDP iftgw.example.com 1826 From: 1827 Record-Route: 1828 To: sip:+16505552222@ss1.example.net;user=phone 1829 Call-ID: inv2543.1717@ift.client.example.com 1830 CSeq: 56 INVITE 1831 Content-Type: application/sdp 1833 v=0 1834 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1835 s=- 1836 c=IN IP4 192.0.2.5 1837 t=0 0 1838 m=audio 49217 RTP/AVP 0 1840 4. Security Considerations 1842 This document presents NON NORMATIVE examples of SIP session 1843 establishment. The security considerations in [RFC3261] apply. 1845 Parsers must carefully consider edge conditions and malicious input 1846 as part of their design. Attacks on many Internet systems use 1847 crafted input to cause implementations to behave in undesirable ways. 1848 Many of the messages in this draft are designed to stress a parser 1849 implementation at points traditionally used for such attacks. This 1850 document does not, however, attempt to be comprehensive. It should 1851 be considered a seed to stimulate thinking and planning, not simply a 1852 set of tests to be passed. 1854 5. IANA Considerations 1856 This document has no actions for IANA. 1858 6. Acknowledgments 1860 The final detailed review of this document was performed by: Diego 1861 Besprosvan, Vijay Gurbani, Shashi Kumar, Derek MacDonald, Gautham 1862 Narasimhan, Nils Ohlmeier, Bob Penfield, Reinaldo Penno, Marc Petit- 1863 Huguenin, Richard Sugarman, and Venkatesh Venkataramanan. 1865 Earlier versions of this document were reviewed by: Aseem Agarwal, 1866 Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen Jennings, Vijay 1867 Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, Marc Petit- 1868 Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua and Tom 1869 Taylor. 1871 Thanks to Cullen Jennings for contributing the S/MIME message. 1872 Thanks to Neil Deason for contributing several messages and Kundan 1873 Singh for performing parser validation of messages in earlier 1874 versions. 1876 The following individuals provided significant comments during the 1877 early phases of the development of this document: Jean-Francois Mule, 1878 Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, 1879 Matt Cannon, John Hearty, the whole MCI IPOP Design team, Scott 1880 Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny Mistry, 1881 Steve McKinnon, and Denise Ingram, Denise Caballero, Tom Redman, Ilya 1882 Slain, Pat Sollee, John Truetken, and others from MCI, 3Com, Cisco, 1883 Lucent and Nortel. 1885 7. Informative References 1887 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1888 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1889 August 1998. 1891 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1892 April 2001. 1894 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1895 A., Peterson, J., Sparks, R., Handley, M., and E. 1896 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1897 June 2002. 1899 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1900 with Session Description Protocol (SDP)", RFC 3264, 1901 June 2002. 1903 Authors' Addresses 1905 Robert J. Sparks (editor) 1906 Estacado Systems 1908 Email: RjS@estacado.net 1909 Alan Hawrylyshen 1910 Jasomi Networks 1911 2033 Gateway Place 1912 Suite 500 1913 San Jose, CA 95110 1915 Email: alan@jasomi.com 1917 Alan Johnston 1918 MCI 1919 100 South 4th Street 1920 St. Louis, MO 63102 1922 Email: alan.johnston@mci.com 1924 Jonathan Rosenberg 1925 Cisco Systems 1926 600 Lanidex Plaza 1927 Parsippany, NJ 07052 1929 Phone: +1 973 952 5000 1930 Email: jdrosen@cisco.com 1931 URI: http://www.jdrosen.net 1933 Henning Schulzrinne 1934 Columbia University 1935 Department of Computer Science 1936 450 Computer Science Building 1937 New York, NY 10027 1938 US 1940 Phone: +1 212 939 7042 1941 Email: hgs@cs.columbia.edu 1942 URI: http://www.cs.columbia.edu 1944 Appendix A. Bit-exact archive of each test message 1946 The following text block is an encoded, gzip compressed TAR archive 1947 of files that represent each of the example messages discussed in 1948 Section 3. 1950 To recover the compressed archive file intact, the text of this 1951 document may be passed as input to the following Perl script (the 1952 output should be redirected to a file or piped to "tar -xzvf -"). 1954 #!/usr/bin/perl 1955 use strict; 1956 my $bdata = ""; 1957 use MIME::Base64; 1958 while(<>) { 1959 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 1960 if ( m/^\s*[^\s]+\s*$/) { 1961 $bdata = $bdata . $_; 1962 } 1963 } 1964 } 1965 print decode_base64($bdata); 1967 Figure 58 1969 Alternatively, the base-64 encoded block can be edited by hand to 1970 remove document structure lines and fed as input to any base-64 1971 decoding utility. 1973 A.1 Encoded Reference Messages 1975 -- BEGIN MESSAGE ARCHIVE -- 1976 H4sIAAAAAAACA+xdS3PbSH73IZVUVKXvAKuW6xlLoIDuxosyNdLYmhmNH+NY 1977 siezuylPk2iQIEGAQoOi5FScZA9blUu+QHJMVa6bW1JblXwFzzfIZQ855Zhr 1978 ugE+8CIJ2eLDY/QMTYpoPLrZv3///o/+dwObmPZJs2ri4M6SisSKilD4rqlK 1979 4p0XBYI7MvtKgTJSFFZPViRFuiNId1ZQBjTAviDc8Tu0j/0unVVv0fFRWybv 1980 H0n57vn56XfPzgRq92sDSvwjcoV7fYdUPb8lnJ0+3wdVaXvrlY1r47/2Xz56 1981 LrQ9GqDquG7T69UUSZUOGj52m+36G6P9NWo87pqdAYIAou2tp/hK/Mrzh9g3 1982 aU3Q2CW/8tlJws6XxHH2hGOHXco1ib8jPOBPgqutaoMdOYrd4fAgwK06ghAB 1983 uL117rGTv8cB9dw94bzt9TBl54bNCKrD8PtEUw63tx5ixxFPH9WExnjMU9OS 1984 2OO5wDWphCXDGADYhm3XHUqS0TS7LmF3Om42ST+oCbjfd+wmDmzP3admn13v 1985 jFzUBGgA1kRDGHXk9pZTE1jztrc+jt+f9UX0oy1RACzCP5LUNP6BDEr8rxX/ 1986 DHFT/HO05dUYw5gfazJ4JeVHCFgIAQJpAQBzRIpssE9VUJVTUmQeAmOIHo1i 1987 ik3PtTwAbQSkzqWEqcTEigU70B0jVv9Ysbok/DPgk2VO/4vwL0sA3eH/ICTJ 1988 UIUM/0hVy/l/JeX02avT85Pbh79LghD+gM2vBp+wswwgjt5wDLJplM3tPZdh 1989 mAEWQKeDgChSYlpuL2QREX5lNuUaEAnRo88gJ3FukkNLhttbj9gta8JXvr0n 1990 SLLwLXYFwIaiIKs1SWL/Cydn5+yOnhvgJpM9D2Jt5NdXqrGWHkYViRuI59d9 1991 kiepRoefELcVtFkblFDuXNbZm1fvtRn5cci1AAyNUQkNaKyBBmugcPocTQSj 1992 sr1F6+L2VrOePRDUJS7JenU8MG1PYF0ua8KL8+f7x6+eC6xRgB+7tE3iCRCA 1993 6SEob2/huh/0e7hfg7Lw5PnDT1kafpry312q9C+g/8kwxf8QVJRS/q+a/+Uq 1994 TkkdkJe4qG0W0QGHaekflqkSyEpKDVysBUaTUliSWmB0al5TUiogG/ZsvMnK 1995 UaINC/U9VmaofB8r/m33UpLXaf/RoJTmf5oES/xvHP/rVN+DAcoQySpj9DJA 1996 aoYGJiEZjUSpjSWbuibuUrODKeOC3EaD6VR/m8n8JjqkcnCwd7C3FyNwO996 1997 ZGRd6ngkIRcOWMmjaGAhrbshg5NnUjh5XRyO9fol8ek69T8Jofj8r4T4h2qJ 1998 /42Z/7XM/K/lzf9Fp/7EzH9cDSf/RTP+xZB49kWfxOb98+po6i885YcjnU/6 1999 WnrSn8zt8idmHGo0MVOW18r/GfQz9h+olvhfSRnNngKQJOG7x/OmVENP4VuG 2000 IDLtZM4BilKNvdLnUdwgPj9xis1wFEpQRzqSgCSzCZ9N/hbuwg4g/pCYFj0+ 2001 M62Jz0WZUIAp/UhTk4h8yAztcKwuZKoRczCyUgEjjwGgQoadqYEovDg3DwE9 2002 Ll8Ob84UDH0mVeCHSntPWW5H/pOrYLnaXwH7j6ak+R8Ccin/N8//13n9Pi4A 2003 BEjgp4mgGhf/0SBMKH7bWy/IxcD2mdB1vaBtu62zQb/v+QE9b9t0L+/LEzto 2004 E3aj5753dS3GTudf2ISO6o7P9x95x+519liOnzAxw50/ORMszzFFJshFNnrC 2005 iWQRC07PLZvCLBt2q+mZa/X/SYqMMvpfaf9ZLf9DwECGqkFJZmgMAuJzgAkN 2006 n+CuwFAl+KRJ7EuOrtkMUUozPQANncHZI3GsjwYcpqZnwUEHSJB9dC3InmDA 2007 PrUtTCFph4YfTA17yvkgMlCK9z3IE1uRwggN7FLLHjG/B3nUL6poSKDjmm6X 2008 x/rkoHQGwWONzTC8j3H+bzKJ7a/Z/6OpIK3/MdJe4n9j7L/JmVv/UIuwwf38 2009 7B8PzHKwD9yWf532sI8lSDRkE2RhSGzMpIXZhQWMxEn3fXbGFrl/B4kAKgDe 2010 2LFvsPIeduE5huHlWoabbFDj3nr9P4okZ+d/rcT/KsqLk69Pz85PXoR4zQV/ 2011 Bj8UBwPffS/H79Tyy2+XsteObTaPutarVqfrB0+HmPiPH4+NvvmnxAXDeCyz 2012 0SNLR9nnHAsHIIybHRNA/PK7sqEBNgQBK0etoRwXQQcDt+t6Qze8yc/GOjzq 2013 M7BO/CNVy+AflPP/p4p/HepskrwZ5sFCzMM8zD+4EegPf4Y+IbPh+ORirfY/ 2014 GSpqmv8rZfzXpuC/GNXPHh0FagFF7sAOBJlFQPr21mlNGI2/BJs3DK77W64D 2015 nS6AEMkgNU2PbpaO851y/ynUZ1srgJInscJw5RnmOvbAU20pHkSS6K/xMyaP 2016 FwmUYUovzOumibBLd5ahaQxXRoimo3goyU0CZXI6AepSFG+9/KDmDw+JEQpr 2017 PqWnK1sIbS7b/bPY/w+1tPwHpf1n5fYf9qIVeMxFawVJMdkVl1TZeaGiKZRU 2018 NJAn7UJ+dVoBTGJdEvbGurBJaPx6Ixss1DNyT9vesmtCND75yhDJCE3C3U7X 2019 BdBz2R+SCGPLQgBfGIqKmn240M131Mxx8m9vCRM7VUV9mLcU5IB9zzrjwK2o 2020 co/UL9mbM2BNVyoQVaB8eEtSc6bQLEMDynJT+Q/WbP9Xs/o/Q3Ip/1fD/ytI 2021 Y1y5gpRIB/BJy6aBj/3qTG1gp/IrVn0UTO0T6g38ZoLsHk6W9y+sGYp/C0DQ 2022 wabVSQSFRUOTC333YuhB5F8AaEPU8blvsOk6ALq+03UpjwtLOugfLlwDCCSj 2023 Yr2hLnHiM4gBERLiPZK7bDFhPMCOjakcuQRTDsGHFfWrTFUQhYelq2avCcOK 2024 MFXx1u0PrJPdgeOs1/+PsvY/tVz/v2H6Px8mYkWSRP5hlmo7s9LIsmcYIMrf 2025 MWc58HhIQgNI0DWty27HxNTqXsAh8gL/QsImtZhQwJfmZEkwgobO2d8cxX+R 2026 2y8WqDOFImvKUebEw5xasyo+qW22vZB1tj/w7fWu/0cZ+5+mlPP/qvW/tAHv 2027 ixfeICD1CnyYkg0VeHIruQEgkhVZz1sTNmvVfSg/ZsUFjIdyqCyKnDe0OyLu 2028 ENjwRSYbLiRDH4oWHhK/DS7ENnKVqfhgooZN/mC+9ih6lhi0idhmNKZ4xN8y 2029 jWelGliWDyu2SwfWmvU/pGbW/6LS/7t2+T+V8SMpGcZtLfYpGDk+hWo4zhYK 2030 RWe07PaGctCY6UQwytwoi/Af9EjQXiv/A4n4LzXif6X+t5Jylw0A4hMa2G5L 2031 fMpGgmeGy+8UVdON1/d3f6xWbNckxLz3NhQS8uuBO6AD7FRfvjh9+1ngiQ1y 2032 lw588vkvbereC3bt4Bf7TR+/uf5ib//g4H7tl3aw28a0Lu8Nie2bd+/3Mf3F 2033 0Htrvg48r/qZ6RF+mmgHnx8tDj8ZW3bkeeGb1bsVVb3/evfHe29H9qovT57U 2034 fvNnwrOX7O2O8Ij/9bcjo9RN25Nr5gq8LnHltz9GH8C93dfRJ3i/crcqRjfq 2035 DVwTuynjl8VOf85DS+7de7t7/zWrXKnv/PR3737/7t/e/edPv333+5/+8ad/ 2036 ePfv7/5jJyTMr8OrvpXv7f7IrixWY+R3jOOh55uVXz0W71ZZD9w74n/++Pbz 2037 zw4f1H6zv/NXv/7ib/46lkZLBgDqinCDMZAm64CHp5IrJtMpE+LfEGwSn927 2038 cn/3Nev+2v/+4b/++C//+se//+f/+ac/bO4amE+b/10CBcG12v/UcP1fiv+V 2039 6/9Wzf9eMv735VGxGEDbClrD6iyP764MJagoiszKEatabTo2A34ysI7drd5v 2040 ey455Ev9mkxQiaHBYXSNzNMc9LBp+nVK03b2sQViV1YVaRzHF6+WvF1CaEaD 2041 X9ZkLe85YzFFijohvrebE+b9s/rdiuxkXTAI1u3/k7Q0/0Nl/s9N0v+KZsH8 2042 oGVBemjwR3N9A9FwTWaIMqlld3gWb2hOY0EUhOaEv1GvR4plCZ0N9lFksOX5 2043 PRxkyQ0K2c2DELmsZ4QH/WZvIPA1xvUdhODOPvvywf748Np+f8dzW8sOAF6A 2044 f1XVYMb+X/r/Ngj/oRJ1KvAgLgELvJ7g4h4RPEtg3N8nPfKBb0Lf9zg0GK52 2045 ctf01lTWp4lgfLl+SfxrPnxv83WJnQE54J/Cm/BWLvtVp23W8ujGy2hS3ivU 2046 OQlT+p6xt+/toP3Me8UfgGu0kYzGPfyGqYNO+DiRwOYPu8yvswHRwNA38X8E 2047 0HgotkONdyljpR7dInaHcIzczj/j5w9/dYdQOmnCrX+Izd7jyYaxcJ+wL69X 2048 /+94yNkTrgB1HjkgTcjCy6hnxCes5m2+RI61mjDqePG2IS1Gv+vyrt8fywwx 2049 lP31VdwpbFOODZBJKAiTatpltgZI1niVrSGnauTdR0rXOc7UAUaqzmn2OsmM 2050 YLxOznW0VJtyngeo6To511FSdfKeB6Xr5Fwn1cevhJqQqZPq5cu8Oul+FoTs 2051 vaT0dbJ1ZCPze+VU0rOVcmppi396WS1QRylQBxWoAwvUAQXqFBjSsrS4jrG4 2052 ir64SoFOLtDHBbq4QA8X6OAi/bugSkarHCXOMesTu85Y0VwV2VvFK2rSSFwv 2053 jJldA7d8jz07nE8hKMcJWsGyAwAX5v/J5H9V5DL+b6X6f34irduJ8jOAIWf8 2054 hvFA/8kYlI9ixu+Rl3JxvImyzG16jFs26EMZGRDomrQhgsAZUtOm/fXmf8+J 2055 /9BK+/9Kyu3s/7cTQW7nQY4cmGbkWxD3Px6KPPQAN5rmkcU0zOs8Z5wqzUjN 2056 ycVC5qx8w3659d8Y/+uP/4dp/78iSWX+j3Xb/w8Ex18sAiJoX1lENNgkputQ 2057 fGNYRbICwygze8bfpyRFQjg6o2Sgpkc8m2+9FAb3D303+qRD5HfDRUUj558M 2058 GaVUESwQqyrPTF0EoDGPWMirJxbzFYtNIxZl+VjkPxeAwVr1Pw1k9L+S/61U 2059 /ufzv5kZYD9IIdR1GSVl/GgEWl33gnE/JuMRlAwDm3zpNx4SeJTDAWXdgLq+ 2060 IN+HvIgHQmOc43U5Un7jzUe9prPu/D+Soqlp/a/M/7BR+t+Nk+nwVAoAFhMT 2061 Ht+1Ic9sxJcbxQRFNFSttsspoOfbbTy0TA9DD/kK8KDt0+kOQYxfMfo3URIz 2062 wMxooqqUraWkAR+Qq2C/72Db5bA+Z49N7lHB9YQhvhYCT+D+UNY1Q6GH3WvB 2063 awYkoAL2iUD57hKUmLxSgwj8xOpmKJ89m/Zw0GwvUwgswj9UUAr/CijjPzfR 2064 /vNecZ0QKUCZt/1LfAx2eOZBemVaTtFU7qWp51bwD9aHfy20/yb4P/ujxP8q 2065 yrOT75+enH/z3aPNkABggQSYydRTRH2+pJid/G+xR5hnKrw5pc9j8xtho+kN 2066 nMBesgaweP1vPP4bhfmf1XL/h7XYfxmg+4y8Flz/AZRFuBuP9/xsy7n+oGi9 2067 1RTyEyExGqqGzreJOoohaXSKUfgcMEdoTWza3DzNkxDP1mHGRzIaTBH7d5gJ 2068 i6+zLRaIgualxVFTP0PGon5DiQVmOrHBbSdUKGnZWovbdJZs/SnA/xL5v0L5 2069 L6ll/pd1+/9mWX8Bl0UfxgdD0w6MW4H5OEws6wNyaELyFQSGcBIOJBUIB4JF 2070 Evsln0yBH2boFd9n1y8FzowUgisLFXQ9n2DquWvd/weAmP1HC/0/sMT/Ssp4 2071 /0/W/8IH7+05GUyYoZjv7Gnz7LyGAQDP4zlz9/ZyF881zv/eJXFoc73xf0BJ 2072 4R9p5fy/Yvuvh/vVBiH92v7+FPSwBiUJ3E4YsJ6J9IEJ0RGNwyjSh11eumAS 2073 xh1GgT9dZ5qlG0YphGdtzj1ag2EU8fyiMifRxcALGni9+b81pKT5v1bu/7VB 2074 /D9c///UrwrfVgWelyeaRbPU/7DQ5r85m1zJ8Tjg8ZAM1YB5sf1GmrQX3fVK 2075 MWqKpEgFxELhQA+whp2vbsNG7JMWHgTr3f83yv+anP9Rmf9rJWXJ+//pGgRy 2076 uwOgDPR5O9tNhmHCBjCGNJMZM/f04xP+1Dg5Q/c/HgRtz7ffhBCuCc+871zy 2077 2PWG9Lxt07Nmm6cg8fr4YkBEhgNc5wEaGZT/LKkB6/gGNpvBevEP0/q/VPp/ 2078 Ng3/89Cfi33D0CEEc5f8TEZfFyIFU9+Bltm4PJKlKv9Pni4CnLehJ1Sqss5q 2079 Q/6Cc/YiTuwhOn+3A/aqJnc8+JmGkbBfgO+bsF78K2rW/lfGf3zs+NcXQT8a 2080 eCnop726t7i1z9MZpsZF0P8ItvF570KZQoX95W4BuFD/hyjD/0GJ/w3Bf34C 2081 djDPwAYRoKblzTbbx20Fc6z/gGvjoNOeBIJBVTcg4gtImIJoyBJkh2OCYSJc 2082 JqMaQE/qm8Yldp0LOHR9xyVDz+pgagzsLDeBEmvvyVXf9klolFhBme2aSPYw 2083 TyEqHJDo2epAl4ChKYaqQqDLygeYMaOeclrrxL8axX8CoEpcUQz5f2n/W63/ 2084 T5GgcEb8S7tJhJcuvsS2gxsOeS/4v3lzZdp8x046zKY/YqcWlgqZuKqRWCCY 2085 mh2LdIYTAwEIV4voEGkagBJi44gNpNj6j6RgYMPd9TAlkmfxYNO2Cy48y8P8 2086 D4DJ0OLX8nlW8sC/Fo+tgPjsFsiAEtChznqKv/M/+X0MnfGc77Hv2m6Lr0pj 2087 t/UuiR8MfCLsnLrCc99rMcjSnc30NVCzv/b1X5qSif8BsNT/N8v+Hxr5XmeV 2088 gNlrJ9OxoQVSAsxNBhAN1ZFpkAcHmUwMmNtbx80m6Qej1Vmu1/DM64lt7wZO 2089 AVmZHxOeWNS5KXsAfLAjgJKeveb8H5Kixfi/KkX+f7XE/ypKev3XAWtkfVBB 2090 UgycNxcKM6Hu+a0oGgACBObFA4zHZa4/QJ/O7GPwpyC4l/ii321STezZPbLH 2091 aXRUwtBw1tpgv2dfEXMv9gW1Wy77JlaXTeC4RdgBduXYH5aPW/NEyuavR6O8 2092 V9a7/gPJapj/AWgykDRNjdZ/lPr/SsrTk7Oz468jAtAd9OyuNxvtD/IrJTm7 2093 5Qws6zpHl2ccXZK1Rh5cgBbZ+/Ns96KpawqCIqPdjCECrFqM5ivAEmVxfOjA 2094 53sHxISHhkxTbVgKJA3T0pB89APwBj8A580PQB80gTPEf/kXg0bv1XRrS2HU 2095 D4z0x/YgmjxYZsfvUSuTT344K/VpyBR8HslIfPHEbXpmqCw0bBf712kykRZD 2096 Bw2Pbx3nX9eRqVkqJLqKDbUJVfmgxwSc06rTNpYP+r4XeE3PqWcFH78O5grJ 2097 9tYjzBt3PiB7rNeF474vADb/CrJWg1JNQcLXT8+3t3iIh3jcYo8U/k52r8/l 2098 9n5ISITPmgOfEvp5HjFSNS7WRDH9oPPW0RfoH77U3qZCG1MBC3xreMF2BaYa 2099 CpzqVYvcMH8yOIi2X+Afq32NTk96ZNO+R+3IWYwD9ru3e+z7g5DMsUer++Ri 2100 YPvst7Fsh8y6ytwWSb/9k//+0z+//7tvfvd//9/e1QA3cVxh/dkmprbriAQK 2101 NrMxbUxsRPbuJFsnR2Bgkrqm2LVlx8SQkrPuZJ0kn+S7k1UDAcsUd5qQIfGU 2102 0mlK8EzbgZAUmh+GzFCg6aQZUlrXpqEwkyZMpzOdCcwwhfy0+aF0VyfbkizZ 2103 TtvIIdnPlq3duz2d9t7bfe/te28L9HmGoX7TKKr6g0Gvp+bCW3JzKguNhoU5 2104 Ojh34iT9UL/hLOw3DKNX9ZDRoDcY5uj36LoNjN4MC8bP0+egZqHYVYytplyz 2105 odVFmWExLswxYx4RPUGkrXJUMSzClXnmOS5OAvVBRaAK4ZdwVb45BxG5qFJ3 2106 wXJcnmsGLlwGLYKigjVIuxU9uDsFEF9YV3vh4vkF0IbGciSeUixjb0dFOypS 2107 8SLs+P/c0SL4FVw2zrt18kADo/sT+0GfozNGH9PB6PcN0ahu76PPHTy86oF2 2108 Tina98Ydj2x75Z0i5vT6hg1bclf+8Znju/ecKlnZ49x5oKjkbZc63FdyYB2z 2109 8lKvueXRC79r8N5j2vP+rVuqNuRufcR05Z3SxevOP/2DQcvVTfcNlL34pPNP 2110 h4bfG666eKTp+knvoY8uHjWoVS3fujhve8vao9dO1gx/9LfBJ47xlw1GvU7/ 2111 0+3wYdiEvkBpsake1g3cnn7EHLhN7EpXPT+EDZNpvjju2FKzyYCmn1L8ttB0 2112 u2meNHSXfGTLe9+59t2Dyj/37nvhFw9cejyFToyoY7582V32xOWdD/3+zOkb 2113 T71Ut6hvx4FnvwaO9P5s57K39w6dipZXPnbi28+fkff+qPL9IDjTtv7Cxp88 2114 vlrovnPfvUs+7DztP1/5QX2JFbQ07x98ITT62/aF4Xd/NX91TeVx1/DSH186 2115 lzO4qXpA/fmJZ4Vd1+suvKq7tuiph99qL7b99d/lNQdcgxcPU/36P8N+/VlE 2116 +nBr9gk3gYcm2G4o+hxcMN5TtxipRDaEJRNHcqiiCbpnoI1ph0smjpoo9BgK 2117 m5a8yr++zf/kyTvhm3ec/YbQV/xL2DxxUhF1L1wD83PnaBXGPFg4/t5gMOj6 2118 0DObKOtrYZ52m3nJ9UtTSN8U7Vtw5ZDtX3k3tm7/4bGvy0s6X9skf3x+Va28 2119 qOqUe0f43BtXV7z7j/zuv2xbMSCVNr289rWFv7mxQ7xx/7WrHmPottDT5Uzr 2120 wXPfa1sAGp858uCxuvzunQ+9tH/x0g8W8NTxyq82v/7gx95fX1n9Zt+ukG3D 2121 2pd397a8dUE6m3+9rbzdV/rh4b/nvdKfbmS2WHQEnyGoiDE+7QDAadf/E/M/ 2122 afo/0gWI/J9l+x8X4KRaH6cEu8R4eHMjQOJPaq0m68tcIORNVvrXcestnka5 2123 jWvmXUjDhVWJDn4xOktS5hOX+tf3bt7ca6HRaVjQQ79YupPCXR2CjFpKQPMQ 2124 1s5iHOO2vFhF0kIduguB00zxnmAQdKBHix4bvutgEBfk2L80sqt9pjY9Vdsn 2125 2RkL3P4c8D8WUrH6pMxi/peq6hT+t9mI/8/s2P/+u/zf/1Peb5BAg37R57Vy 2126 fl7iun3+iCDxCqd4sOEvg51vRhnBp08DmdLItaYFtaKnahXgFB/v9aSuj37T 2127 BVRminY0a4dIm8ffKPk2G9Y2NLY1ANU6RWNO4aGHEaQ0i7JTuj9BjhV5jyQI 2128 aUyPqhxRZnv+t8FU/rcykPB/1vlfFrqCqmBB/dGZ3ugPQCZ/gBj1ZaB4vFQH 2129 2URfoIwflGxKDATRkGJBKm8wLLuFdAMLa6VZaGcT5QxMz0HRHWasrM2OQwgF 2130 D44g9Mo0Y7XJ0w4kNGNnE4MLMxv0Ph8Rg2HJr7i7Pt0RYFr538qk8n8V4f/s 2131 8n/KurkWE+NQgyreNFMLjXFrhJ+NaOA4VUokGjgb/N9FzzL/M3Qq/9toov9n 2132 BTPz/xeVDsmBZFemmqXt1cz4LO1VVZwwIBKJLE8n9iPGTOXqGK3F1H9vb8gr 2133 SJwq8JbUNK4Tk7GVhYkOvpNn48wJ56iZRALdgxdvHPVBr7TJ1SWq3hVftGyx 2134 YWnW8/9QkEr1/7NRDMn/nBWMSfY0hMAJ6IoKBlQAW0UFDUZOjJwEo9HRfvRv 2135 5MWRoyPPj+7GdSlVo/2ju4AFjJwa7Rs7NnJ0Kp8Y1p7CkxRDW1k6eaCIEyXe 2136 CsyPJ30/46MFOSLwHmWVa4pUQhmDkShK224og9Qi8GHNS4HG7smTV7ZnlhIg 2137 nRs/a5+UYeiTpQlg7RnzBOBDn70tRQluIkQUUeqZXf9vqtpGpfp/IwGQjP9Z 2138 Xv/pEXsEf2et28uJsoWXZHeS0oSEN6QcSqgPuEThsBE4CvKnbw5qAABogMXO 2139 lE40gFF2/MMwUkG+R8Y7DQEHKKsHzUFFkDoEuRNs3LixrCzufallm+FlfLB2 2140 UkwU/oOv7AQ4ya+Pt0+zEqVRfJpFqORRP3ZLMV9vtxLLPAkhiz8qwY88vq08 2141 AHejk2PdAfBUp7mNjsuhY7Mdw0IlLn4quNMahMh9nNQZEPg6geNxiAkAkhDx 2142 aHUgvpc2wFq3KIVRzeSDrdoz0dq3IfG1VQorYS5wPz7sADU1y5ahV820c5fm 2143 84Y+LNbTihYGpCQ9/oA8RgER9DnO2A2M1VikoCVWgR5IjwOM9UnMYHg3wDo4 2144 hhIS8XSXRBXxx6f1EKYMAOJCASv6fXYAsA/ueBdrV0RvsTwR62Cqyr6cttmW 2145 o9kdXyt+ISdqNBaJiCN00AzoKGsKB5GqARRVFiVEXmWYvDISFroU6m2N1p1j 2146 bsCoJvYttXtWsD2E106pAd3o3uFyrO18wuk9Yw5Qa3am9s0CYj/PLOv/NJxs 2147 /yP6/020/jeVpa/Tq/BWKmEAjpOcD5vyAh6piw7SASsj28JQM/clmfYYmppi 2148 ZW9Ge7xhK4KYajuAJPUfAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB 2149 AQEBAQEBAQHBTYr/AD4op6MAGAEA 2150 -- END MESSAGE ARCHIVE -- 2152 Intellectual Property Statement 2154 The IETF takes no position regarding the validity or scope of any 2155 Intellectual Property Rights or other rights that might be claimed to 2156 pertain to the implementation or use of the technology described in 2157 this document or the extent to which any license under such rights 2158 might or might not be available; nor does it represent that it has 2159 made any independent effort to identify any such rights. Information 2160 on the procedures with respect to rights in RFC documents can be 2161 found in BCP 78 and BCP 79. 2163 Copies of IPR disclosures made to the IETF Secretariat and any 2164 assurances of licenses to be made available, or the result of an 2165 attempt made to obtain a general license or permission for the use of 2166 such proprietary rights by implementers or users of this 2167 specification can be obtained from the IETF on-line IPR repository at 2168 http://www.ietf.org/ipr. 2170 The IETF invites any interested party to bring to its attention any 2171 copyrights, patents or patent applications, or other proprietary 2172 rights that may cover technology that may be required to implement 2173 this standard. Please address the information to the IETF at 2174 ietf-ipr@ietf.org. 2176 Disclaimer of Validity 2178 This document and the information contained herein are provided on an 2179 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2180 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2181 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2182 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2183 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2184 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2186 Copyright Statement 2188 Copyright (C) The Internet Society (2005). This document is subject 2189 to the rights, licenses and restrictions contained in BCP 78, and 2190 except as set forth therein, the authors retain all their rights. 2192 Acknowledgment 2194 Funding for the RFC Editor function is currently provided by the 2195 Internet Society.