idnits 2.17.1 draft-ietf-sipping-torture-tests-05.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.a on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2196. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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 1299 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 (March 18, 2005) is 6978 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: 5 errors (**), 0 flaws (~~), 6 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: September 16, 2005 A. Hawrylyshen 5 Jasomi Networks 6 A. Johnston 7 MCI 8 J. Rosenberg 9 Cisco Systems 10 H. Schulzrinne 11 Columbia University 12 March 18, 2005 14 Session Initiation Protocol Torture Test Messages 15 draft-ietf-sipping-torture-tests-05 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions 20 of section 3 of RFC 3667. By submitting this Internet-Draft, each 21 author represents that any applicable patent or other IPR claims of 22 which he or she is aware have been or will be disclosed, and any of 23 which he or she become aware will be disclosed, in accordance with 24 RFC 3668. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 16, 2005. 44 Copyright Notice 46 Copyright (C) The Internet Society (2005). 48 Abstract 49 This informational document gives examples of Session Initiation 50 Protocol (SIP) test messages designed to exercise and "torture" a SIP 51 implementation. 53 Table of Contents 55 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Document Conventions . . . . . . . . . . . . . . . . . . . . 4 57 2.1 Representing Long Lines . . . . . . . . . . . . . . . . . 4 58 2.2 Representing Non-printable Characters . . . . . . . . . . 5 59 2.3 Representing Long Repeating Strings . . . . . . . . . . . 5 60 3. SIP Test Messages . . . . . . . . . . . . . . . . . . . . . 6 61 3.1 Parser tests (syntax) . . . . . . . . . . . . . . . . . . 6 62 3.1.1 Valid messages . . . . . . . . . . . . . . . . . . . . 6 63 3.1.1.1 A short tortuous INVITE . . . . . . . . . . . . . 6 64 3.1.1.2 Wide range of valid characters . . . . . . . . . . 8 65 3.1.1.3 Valid use of the % escaping mechanism . . . . . . 9 66 3.1.1.4 Escaped nulls in URIs . . . . . . . . . . . . . . 10 67 3.1.1.5 Use of % when it is not an escape . . . . . . . . 11 68 3.1.1.6 Message with no LWS between display name and < . . 11 69 3.1.1.7 Long values in header fields . . . . . . . . . . . 12 70 3.1.1.8 Extra trailing octets in a UDP datagram . . . . . 14 71 3.1.1.9 Semicolon separated parameters in URI user part . 15 72 3.1.1.10 Varied and unknown transport types . . . . . . . 16 73 3.1.1.11 S/MIME signed message . . . . . . . . . . . . . 16 74 3.1.1.12 Unusual reason phrase . . . . . . . . . . . . . 19 75 3.1.1.13 Empty reason phrase . . . . . . . . . . . . . . 20 76 3.1.2 Invalid messages . . . . . . . . . . . . . . . . . . . 21 77 3.1.2.1 Extraneous header field separators . . . . . . . . 21 78 3.1.2.2 Content length larger than message . . . . . . . . 21 79 3.1.2.3 Negative Content-Length . . . . . . . . . . . . . 22 80 3.1.2.4 Request scalar fields with overlarge values . . . 23 81 3.1.2.5 Response scalar fields with overlarge values . . . 24 82 3.1.2.6 Unterminated quoted string in display-name . . . . 24 83 3.1.2.7 <> enclosing Request-URI . . . . . . . . . . . . . 25 84 3.1.2.8 Malformed SIP Request-URI (embedded LWS) . . . . . 26 85 3.1.2.9 Multiple SP separating Request-Line elements . . . 27 86 3.1.2.10 SP characters at end of Request-Line . . . . . . 28 87 3.1.2.11 Escaped headers in SIP Request-URI . . . . . . . 29 88 3.1.2.12 Invalid timezone in Date header field . . . . . 29 89 3.1.2.13 Failure to enclose name-addr URI in <> . . . . . 30 90 3.1.2.14 Spaces within addr-spec . . . . . . . . . . . . 31 91 3.1.2.15 Non-token characters in display-name . . . . . . 31 92 3.1.2.16 Unknown protocol version . . . . . . . . . . . . 32 93 3.1.2.17 Start line and CSeq method mismatch . . . . . . 32 94 3.1.2.18 Unknown Method with CSeq method mismatch . . . . 32 95 3.1.2.19 Overlarge response code . . . . . . . . . . . . 33 96 3.2 Transaction layer semantics . . . . . . . . . . . . . . . 33 97 3.2.1 Missing transaction identifier . . . . . . . . . . . . 34 98 3.3 Application layer semantics . . . . . . . . . . . . . . . 34 99 3.3.1 Missing Required Header Fields . . . . . . . . . . . . 34 100 3.3.2 Request-URI with unknown scheme . . . . . . . . . . . 35 101 3.3.3 Request-URI with known but atypical scheme . . . . . . 35 102 3.3.4 Unknown URI schemes in header fields . . . . . . . . . 36 103 3.3.5 Proxy-Require and Require . . . . . . . . . . . . . . 37 104 3.3.6 Unknown Content-Type . . . . . . . . . . . . . . . . . 37 105 3.3.7 Unknown authorization scheme . . . . . . . . . . . . . 38 106 3.3.8 Multiple values in single value required fields . . . 38 107 3.3.9 Multiple Content-Length values . . . . . . . . . . . . 39 108 3.3.10 200 OK Response with broadcast Via header field 109 value . . . . . . . . . . . . . . . . . . . . . . . 40 110 3.3.11 Max-Forwards of zero . . . . . . . . . . . . . . . . 41 111 3.3.12 REGISTER with a contact header parameter . . . . . . 41 112 3.3.13 REGISTER with a url parameter . . . . . . . . . . . 42 113 3.3.14 REGISTER with a url escaped header . . . . . . . . . 43 114 3.3.15 Unacceptable Accept offering . . . . . . . . . . . . 43 115 3.4 Backward compatibility . . . . . . . . . . . . . . . . . . 44 116 3.4.1 INVITE with RFC2543 syntax . . . . . . . . . . . . . . 44 117 4. Security Considerations . . . . . . . . . . . . . . . . . . 45 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 45 119 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 45 120 7. Informative References . . . . . . . . . . . . . . . . . . . 46 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 122 A. Bit-exact archive of each test message . . . . . . . . . . . 47 123 A.1 Encoded Reference Messages . . . . . . . . . . . . . . . . 48 124 Intellectual Property and Copyright Statements . . . . . . . 53 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 198 strings 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 or short and long form for the same header field name 252 o unknown header fields 253 o unknown header field with a value that would be syntactically 254 invalid if it were defined in terms of generic-param 255 o unusual header field ordering 256 o unusual header field name character case 257 o unknown parameters of a known header field 258 o uri parameter with no value 259 o header parameter with no value 260 o integer fields (Max-Forwards and CSeq) with leading zeros 261 All elements should treat this as a well-formed request. 263 The UnknownHeaderWithUnusualValue header field deserves special 264 attention. If this header field were defined in terms of comma 265 separated values with semicolon separated parameters (as many of the 266 existing defined header fields), this would be invalid. However, 267 since the receiving element does not know the definition of the 268 syntax for this field, it must parse it as a header-value. Proxies 269 would forward this header field unchanged. Endpoints would ignore 270 the header field. 272 Message Details : wsinv 274 INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 275 TO : 276 sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n 277 from : "J Rosenberg \\\"" 278 ; 279 tag = 98asjd8 280 MaX-fOrWaRdS: 0068 281 Call-ID: wsinv.ndaksdj@192.0.2.1 282 Content-Length : 151 283 cseq: 0009 284 INVITE 285 Via : SIP / 2.0 286 /UDP 287 192.0.2.2;branch=390skdjuw 288 s : 289 NewFangledHeader: newfangled value 290 continued newfangled value 291 UnknownHeaderWithUnusualValue: ;;,,;;,; 292 Content-Type: application/sdp 293 Route: 294 295 v: SIP / 2.0 / TCP spindle.example.com ; 296 branch = z9hG4bK9ikj8 , 297 SIP / 2.0 / UDP 192.168.255.111 ; branch= 298 z9hG4bK30239 299 m:"Quoted string \"\"" ; newparam = 300 newvalue ; 301 secondparam ; q = 0.33 303 v=0 304 o=mhandley 29739 7272939 IN IP4 192.0.2.3 305 s=- 306 c=IN IP4 192.0.2.4 307 t=0 0 308 m=audio 492170 RTP/AVP 0 12 309 m=video 3227 RTP/AVP 31 310 a=rtpmap:31 LPC 312 3.1.1.2 Wide range of valid characters 314 This message exercises a wider range of characters in several key 315 syntactic elements than implementations usually see. Of particular 316 note: 317 o The Method contains non-alpha characters from token. Note that % 318 is not an escape character for this field. A method of IN%56ITE 319 is an unknown method. It is not the same as a method of INVITE 320 o The Request-URI contain unusual, but legal, characters 321 o A branch parameter contains all non-alphanum characters from token 322 o The To header field value's quoted-string contains quoted-pair 323 expansions, including a quoted NULL character 324 o The name part of name-addr in the From header field value contains 325 multiple tokens (instead of a quoted string) with all non-alphanum 326 characters from the token production rule. That value also has an 327 unknown header parameter whose name contains the non-alphanum 328 token characters and whose value is a non-ascii range UTF-8 329 encoded string. The tag parameter on this value contains the 330 non-alphanum token characters 331 o The Call-ID header field value contains the non-alphanum 332 characters from word. Notice that in this production: 333 * % is not an escape character. (It is only an escape character 334 in productions matching the rule "escaped") 335 * " does not start a quoted-string. None of ',` or " imply that 336 there will be a matching symbol later in the string 337 * The characters []{}()<> do not have any grouping semantics. 338 They are not required to appear in balanced pairs 339 o There is an unknown header field (matching extension-header) with 340 non-alphanum token characters in its name and a UTF8-NONASCII 341 value 343 If this unusual URI has been defined at a proxy, the proxy will 344 forward this request normally. Otherwise a proxy will generate a 345 404. Endpoints will generate a 501 listing the methods they 346 understand in an Allow header field. 348 Message Details : intmeth 350 351 !interesting-Method0123456789_*+`.%indeed'~ 352 sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;* 353 :&it+has=1,weird!*pas$wo~d_too.(doesn't-it) 354 @example.com SIP/2.0 355 356 Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~ 357 358 To: "BEL:\07 NUL:\00 DEL:\7F" 359 361 362 363 From: token1~` token2'+_ token3*%!.- 364 ;fromParam''~+*_!.-%= 365 "D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9" 366 ;tag=_token~1'+`*%!-. 367 368 Call-ID: intmeth.word%ZK-!.*_+'@word`~)(><:\/"][?}{ 369 CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~ 370 Max-Forwards: 255 371 372 extensionHeader-!.%*+_`'~: 373 EFBBBFE5A4A7E5819CE99BBB 374 375 Content-Length: 0 377 3.1.1.3 Valid use of the % escaping mechanism 379 This INVITE exercises the % HEX HEX escaping mechanism in several 380 places. The request is syntactically valid. Interesting features 381 include: 382 o The request-URI has sips:user@example.com embedded in its 383 userpart. What that might mean to example.net is beyond the scope 384 of this document. 385 o The From and To URIs have escaped characters in their userparts. 386 o The Contact URI has escaped characters in the URI parameters. 387 Note that the "name" uri-parameter has a value of "value%41" which 388 is NOT equivalent to "valueA". Per [RFC2396], unescaping URI 389 components is never performed recursively. 391 A parser must accept this as a well-formed message. The application 392 using the message must treat the % HEX HEX expansions as equivalent 393 to the character being encoded. The application must not try to 394 interpret % as an escape character in those places where % HEX HEX 395 ("escaped" in the grammar) is not a valid part of the construction. 396 In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, 397 SIPS-URI, and Reason-Phrase 399 Message Details : esc01 401 INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0 402 To: sip:%75se%72@example.com 403 From: ;tag=938 404 Max-Forwards: 87 405 i: esc01.239409asdfakjkn23onasd0-3234 406 CSeq: 234234 INVITE 407 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw 408 C: application/sdp 409 Contact: 410 411 Content-Length: 151 413 v=0 414 o=mhandley 29739 7272939 IN IP4 192.0.2.1 415 s=- 416 c=IN IP4 192.0.2.1 417 t=0 0 418 m=audio 492170 RTP/AVP 0 12 419 m=video 3227 RTP/AVP 31 420 a=rtpmap:31 LPC 422 3.1.1.4 Escaped nulls in URIs 424 This register request contains several URIs with nulls in the 425 userpart. The message is well formed - parsers must accept this 426 message. Implementations must take special care when unescaping the 427 AOR in this request to not prematurely shorten the username. This 428 request registers two distinct contact URIs. 430 Message Details : escnull 432 REGISTER sip:example.com SIP/2.0 433 To: sip:null-%00-null@example.com 434 From: sip:null-%00-null@example.com;tag=839923423 435 Max-Forwards: 70 436 Call-ID: escnull.39203ndfvkjdasfkq3w4otrq0adsfdfnavd 437 CSeq: 14398234 REGISTER 438 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 439 Contact: 440 Contact: 441 L:0 443 3.1.1.5 Use of % when it is not an escape 445 Most of the places % can appear in a SIP message, it is not an escape 446 character. This can surprise the unwary implementor. The following 447 well-formed request has these properties: 448 o The request method is unknown. It is NOT equivalent to REGISTER 449 o The display-name portion of the To and From header fields is 450 "%Z%45". Note that this is not the same as %ZE 451 o This message has two Contact header field values, not three. 452 %lt;sip:alias2@host2.example.com%gt; is a C%6Fntact header field 453 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: 151 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 492170 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 contained extra 588 octets after the body (which in this case has zero length). Those 589 octets happen to look like a SIP INVITE request, but (per section 590 18.3 of [RFC3261]) they are just spurious noise that must be ignored. 592 A SIP element receiving this datagram would handle the REGISTER 593 request normally and ignore the extra bits that look like an INVITE 594 request. If the element is a proxy choosing to forward the REGISTER, 595 the INVITE octets would not appear in the forwarded request. 597 Message Details : dblreq 599 REGISTER sip:example.com SIP/2.0 600 To: sip:j.user@example.com 601 From: sip:j.user@example.com;tag=43251j3j324 602 Max-Forwards: 8 603 I: dblreq.0ha0isndaksdj99sdfafnl3lk233412 604 Contact: sip:j.user@host.example.com 605 CSeq: 8 REGISTER 606 Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492 607 Content-Length: 0 609 INVITE sip:joe@example.com SIP/2.0 610 t: sip:joe@example.com 611 From: sip:caller@example.net;tag=141334 612 Max-Forwards: 8 613 Call-ID: dblreq.0ha0isnda977644900765@192.0.2.15 614 CSeq: 8 INVITE 615 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234 616 Content-Type: application/sdp 617 Content-Length: 151 619 v=0 620 o=mhandley 29739 7272939 IN IP4 192.0.2.15 621 s=- 622 c=IN IP4 192.0.2.15 623 t=0 0 624 m=audio 492170 RTP/AVP 0 12 625 m =video 3227 RTP/AVP 31 626 a=rtpmap:31 LPC 628 3.1.1.9 Semicolon separated parameters in URI user part 630 This request has a semicolon-separated parameter contained in the 631 "user" part of the Request-URI (whose value contains an escaped @ 632 symbol). Receiving elements will accept this as a well formed 633 message. The Request-URI will parse such that the user part is 634 "user;par=u@example.net". 636 Message Details : semiuri 638 OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0 639 To: sip:j_user@example.com 640 From: sip:caller@example.org;tag=33242 641 Max-Forwards: 3 642 Call-ID: semiuri.0ha0isndaksdj 643 CSeq: 8 OPTIONS 644 Accept: application/sdp, application/pkcs7-mime, 645 multipart/mixed, multipart/signed, 646 message/sip, message/sipfrag 647 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw 648 l: 0 650 3.1.1.10 Varied and unknown transport types 652 This request contains Via header field values with all known 653 transport types and exercises the transport extension mechanism. 654 Parsers must accept this message as well formed. Elements receiving 655 this message would process it exactly as if the 2nd and subsequent 656 header field values specified UDP (or other transport). 658 Message Details : transports 660 OPTIONS sip:user@example.com SIP/2.0 661 To: sip:user@example.com 662 From: ;tag=323 663 Max-Forwards: 70 664 Call-ID: transports.kijh4akdnaqjkwendsasfdj 665 Accept: application/sdp 666 CSeq: 60 OPTIONS 667 Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw 668 Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf 669 Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj 670 Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en 671 Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee 672 l: 0 674 3.1.1.11 S/MIME signed message 676 This is a signed INVITE request. The signature is binary encoded. 677 The body contains null (0x00) characters. Receivers must take care 678 to properly frame the received message. 680 Parsers must accept this message as well formed, even if the 681 application above the parser does not support multipart/signed. 683 Message Details : smime01 685 INVITE sip:receiver@example.com SIP/2.0 686 Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3 687 To: 688 From: ;tag=2390234seiu3 689 Call-ID: smime01.uoqeiuavnklafekjq34iu43uawe 690 CSeq: 282398492 INVITE 691 Max-Forwards: 70 692 Contact: 693 Content-Length: 3134 694 Content-Type: multipart/signed; 695 protocol="application/pkcs-7-signature"; 696 micalg=sha1; 697 boundary="----EABF38A0AAE8704C560F10418BA807CF" 699 ------EABF38A0AAE8704C560F10418BA807CF 700 Content-Type: message/sip 702 INVITE sip:receiver@example.com SIP/2.0 703 Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3 704 To: 705 From: ;tag=2390234seiu3 706 Call-ID: smime01.uoqeiuavnklafekjq34iu43uawe 707 CSeq: 282398492 INVITE 708 Max-Forwards: 70 709 Contact: 710 Accept: application/sdp, application/pkcs7-mime, 711 multipart/mixed, multipart/signed, 712 message/sip, message/sipfrag 713 Content-Type: application/sdp 714 Content-Length: 149 716 v=0 717 o=sender 29739 7272939 IN IP4 192.0.2.1 718 s=- 719 c=IN IP4 192.0.2.1 720 t=0 0 721 m=audio 492170 RTP/AVP 0 12 722 m=video 3227 RTP/AVP 31 723 a=rtpmap:31 LPC 725 ------EABF38A0AAE8704C560F10418BA807CF 726 Content-Type: application/pkcs-7-signature; name="smime.p7s" 727 Content-Transfer-Encoding: binary 728 Content-Disposition: attachment; filename="smime.p7s" 730 3082088806092A86 731 4886F70D010702A082087930820875020101310B300906052B0E03021A050030 732 0B06092A864886F70D010701A082067A30820339308202A2A003020102020800 733 90008902240001300D06092A864886F70D01010505003070310B300906035504 734 0613025553311330110603550408130A43616C69666F726E69613111300F0603 735 550407130853616E4A6F7365310E300C060355040A1305736970697431293027 736 060355040B135369706974546573744365727469666963617465417574686F72 737 697479301E170D3033313032313134343332355A170D31333130313831343433 738 32355A3062310B3009060355040613025553311330110603550408130A43616C 739 69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355 740 040A13057369706974311B30190603550403141273656E646572406578616D70 741 6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902 742 818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5 743 56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD 744 6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081 745 D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387 746 4E230203010001A381E93081E6301D0603551D1104163014811273656E646572 747 406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416 748 041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481 749 9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070 750 310B3009060355040613025553311330110603550408130A43616C69666F726E 751 69613111300F0603550407130853616E4A6F7365310E300C060355040A130573 752 6970697431293027060355040B13536970697454657374436572746966696361 753 7465417574686F72697479820100300D06092A864886F70D0101050500038181 754 006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2 755 2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870 756 102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153 757 278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7 758 5E30820339308202A2A00302010202080090008902240001300D06092A864886 759 F70D01010505003070310B300906035504061302555331133011060355040813 760 0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30 761 0C060355040A1305736970697431293027060355040B13536970697454657374 762 4365727469666963617465417574686F72697479301E170D3033313032313134 763 343332355A170D3133313031383134343332355A3062310B3009060355040613 764 025553311330110603550408130A43616C69666F726E69613111300F06035504 765 07130853616E4A6F7365310E300C060355040A13057369706974311B30190603 766 550403141273656E646572406578616D706C652E6F726730819F300D06092A86 767 4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692 768 2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79 769 76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5 770 FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9 771 79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D 772 0603551D1104163014811273656E646572406578616D706C652E6F7267300906 773 03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70 774 E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580 775 546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113 776 30110603550408130A43616C69666F726E69613111300F060355040713085361 777 6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353 778 69706974546573744365727469666963617465417574686F7269747982010030 779 0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978 780 7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E 781 C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A 782 C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972 783 242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30 784 70310B3009060355040613025553311330110603550408130A43616C69666F72 785 6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305 786 736970697431293027060355040B135369706974546573744365727469666963 787 617465417574686F7269747902080090008902240001300906052B0E03021A05 788 00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C 789 06092A864886F70D010905310F170D3034303731343230333630375A30230609 790 2A864886F70D010904311604142830DBEDC758BAA9750138384431E8F1819717 791 C8305206092A864886F70D01090F31453043300A06082A864886F70D0307300E 792 06082A864886F70D030202020080300D06082A864886F70D0302020140300706 793 052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01 794 0101050004818060FF00161CFAC1E641D0C993FACD949DC239F9DDF527F834A6 795 ECF837B5D2C7B756F30A2755F5EF7A833351721F30A4392921E0A73594AA0BF2 796 4E6BD3981362DEA4F22844CB505ED3C6C0CCADD524066593ABED4023243055CA 797 0CE0AE83F13868E29E91E3AA588BDC11B2A18F39001885E17879503523699A87 798 982C6D48D4918A------EABF38A0AAE8704C560F10418BA807CF-- 800 3.1.1.12 Unusual reason phrase 802 This 200 response contains a reason phrase other than "OK". The 803 reason phrase is intended for human consumption, and may contain any 804 string produced by 806 Reason-Phrase = *(reserved / unreserved / escaped 807 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) 809 This particular response contains unreserved and non-ASCII UTF-8 810 characters.This response is well formed. A parser must accept this 811 message. 813 Message Details : unreason 815 816 SIP/2.0 200 = 2**3 * 5**2 D0BDD0BE20D181D182 817 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4 818 D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 819 BED0B5 820 821 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 822 Call-ID: unreason.1234ksdfak3j2erwedfsASdf 823 CSeq: 35 INVITE 824 From: sip:user@example.com;tag=11141343 825 To: sip:user@example.edu;tag=2229 826 Content-Length: 159 827 Content-Type: application/sdp 828 Contact: 830 v=0 831 o=mhandley 29739 7272939 IN IP4 192.0.2.198 832 s=- 833 c=IN IP4 192.0.2.198/127 834 t=0 0 835 m=audio 492170 RTP/AVP 0 12 836 m=video 3227 RTP/AVP 31 837 a=rtpmap:31 LPC 839 3.1.1.13 Empty reason phrase 841 This well formed response contains no reason phrase. A parser must 842 accept this message. The space character after the reason code is 843 required. If it were not present, this message could be rejected as 844 invalid (a liberal receiver would accept it anyway). 846 Message Details : noreason 848 SIP/2.0 10020 849 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 850 Call-ID: noreason.asndj203insdf99223ndf 851 CSeq: 35 INVITE 852 From: ;tag=39ansfi3 853 To: ;tag=902jndnke3 854 Content-Length: 0 855 Contact: 857 3.1.2 Invalid messages 859 This section contains several invalid messages reflecting errors seen 860 at interoperability events and exploring important edge conditions 861 that can be induced through malformed messages. This section does 862 not attempt to be a comprehensive list of all types of invalid 863 messages. 865 3.1.2.1 Extraneous header field separators 867 The Via and header field of this request contains contain additional 868 semicolons and commas without parameters or values. The Contact 869 header field contains additional semicolons without parameters. This 870 message is syntactically invalid. 872 An element receiving this request should respond with a 400 Bad 873 Request error. 875 Message Details : badinv01 877 INVITE sip:user@example.com SIP/2.0 878 To: sip:j.user@example.com 879 From: sip:caller@example.net;tag=134161461246 880 Max-Forwards: 7 881 Call-ID: badinv01.0ha0isndaksdjasdf3234nas 882 CSeq: 8 INVITE 883 Via: SIP/2.0/UDP 192.0.2.15;;,;,, 884 Contact: "Joe" ;;;; 885 Content-Length: 153 886 Content-Type: application/sdp 888 v=0 889 o=mhandley 29739 7272939 IN IP4 192.0.2.15 890 s=- 891 c=IN IP4 192.0.2.15 892 t=0 0 893 m=audio 492170 RTP/AVP 0 12 894 m=video 3227 RTP/AVP 31 895 a=rtpmap:31 LPC 897 3.1.2.2 Content length larger than message 899 This is a request message with a Content Length that is larger than 900 the length of the body. 902 When sent UDP (as this message ostensibly was), the receiving element 903 should respond with a 400 Bad Request error. If this message were 904 received over a stream-based transport such as TCP, there's not much 905 you can do but wait for more data on the stream and close the 906 connection if none is forthcoming in a reasonable period of time. 908 Message Details : clerr 910 INVITE sip:user@example.com SIP/2.0 911 Max-Forwards: 80 912 To: sip:j.user@example.com 913 From: sip:caller@example.net;tag=93942939o2 914 Contact: 915 Call-ID: clerr.0ha0isndaksdjweiafasdk3 916 CSeq: 8 INVITE 917 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523 918 Content-Type: application/sdp 919 Content-Length: 9999 921 v=0 922 o=mhandley 29739 7272939 IN IP4 192.0.2.155 923 s=- 924 c=IN IP4 192.0.2.155 925 t=0 0 926 m=audio 492170 RTP/AVP 0 12 927 m=video 3227 RTP/AVP 31 928 a=rtpmap:31 LPC 930 3.1.2.3 Negative Content-Length 932 This request has a negative value for Content-Length. 934 An element receiving this message should respond with an error. This 935 request appeared over UDP, so the remainder of the datagram can 936 simply be discarded. If a request like this arrives over TCP, the 937 framing error is not recoverable and the connection should be closed. 938 The same behavior is appropriate for messages that arrive without a 939 numeric value in the Content-Length header field such as: 941 Content-Length: five 943 Implementors should take extra precautions if the technique they 944 choose for converting this ascii field into an integral form can 945 return a negative value. In particular, the result must not be used 946 as a counter or array index. 948 Message Details : ncl 950 INVITE sip:user@example.com SIP/2.0 951 Max-Forwards: 254 952 To: sip:j.user@example.com 953 From: sip:caller@example.net;tag=32394234 954 Call-ID: ncl.0ha0isndaksdj2193423r542w35 955 CSeq: 0 INVITE 956 Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw 957 Contact: 958 Content-Type: application/sdp 959 Content-Length: -999 961 v=0 962 o=mhandley 29739 7272939 IN IP4 192.0.2.53 963 s=- 964 c=IN IP4 192.0.2.53 965 t=0 0 966 m=audio 492170 RTP/AVP 0 12 967 m=video 3227 RTP/AVP 31 968 a=rtpmap:31 LPC 970 3.1.2.4 Request scalar fields with overlarge values 972 This request contains several scalar header field values outside 973 their legal range. 974 o the CSeq sequence number is >2**32-1. 975 o the Max-Forwards value is >255. 976 o the Expires value is >2**32-1. 977 o the Contact expires parameter value is >2**32-1. 979 An element receiving this request should respond with a 400 Bad 980 Request due to the CSeq error. If only the Max-Forwards field were 981 in error, the element could choose process the request as if the 982 field were absent. If only the expiry values were in error, the 983 element could treat them as if they contained the default values for 984 expiration (3600 in this case). 986 Other scalar request fields that may contain aberrant values include, 987 but are not limited to, the Contact q value, the Timestamp value, 988 and the Via ttl parameter. 990 Message Details : scalar02 992 REGISTER sip:example.com SIP/2.0 993 Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3 994 To: 995 From: ;tag=239232jh3 996 CSeq: 36893488147419103232 REGISTER 997 Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32 998 Max-Forwards: 300 999 Expires: 10 1000 Contact: 1001 ;expires=280297596632815 1002 Content-Length: 0 1004 3.1.2.5 Response scalar fields with overlarge values 1006 This response contains several scalar header field values outside 1007 their legal range. 1008 o the CSeq sequence number is >2**32-1. 1009 o The Retry-After field is unreasonably large (note that RFC 3261 1010 does not define a legal range for this field). 1011 o The Warning field has a warning-value with more than 3 digits 1013 An element receiving this response will simply discard it. 1015 Message Details : scalarlg 1017 SIP/2.0 503 Service Unavailable 1018 Via: SIP/2.0/TCP host129.example.com;branch=z0hG4bKzzxdiwo34sw 1019 To: 1020 From: ;tag=2easdjfejw 1021 CSeq: 9292394834772304023312 OPTIONS 1022 Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r 1023 Retry-After: 949302838503028349304023988 1024 Warning: 1812 overture "In Progress" 1025 Content-Length: 0 1027 3.1.2.6 Unterminated quoted string in display-name 1029 This is a request with an unterminated quote in the display name of 1030 the To field. An element receiving this request should return an 400 1031 Bad Request error. 1033 An element could attempt to infer a terminating quote and accept the 1034 message. Such an element needs to take care that it makes a 1035 reasonable inference when it encounters 1037 To: "Mr J. User 1039 Message Details : quotbal 1041 INVITE sip:user@example.com SIP/2.0 1042 To: "Mr. J. User 1043 From: sip:caller@example.net;tag=93334 1044 Max-Forwards: 10 1045 Call-ID: quotbal.aksdj 1046 Contact: 1047 CSeq: 8 INVITE 1048 Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234 1049 Content-Type: application/sdp 1050 Content-Length: 153 1052 v=0 1053 o=mhandley 29739 7272939 IN IP4 192.0.2.15 1054 s=- 1055 c=IN IP4 192.0.2.15 1056 t=0 0 1057 m=audio 492170 RTP/AVP 0 12 1058 m=video 3227 RTP/AVP 31 1059 a=rtpmap:31 LPC 1061 3.1.2.7 <> enclosing Request-URI 1063 This INVITE request is invalid because the Request-URI has been 1064 enclosed within in "<>". 1066 It is reasonable to always reject a request with this error with a 1067 400 Bad Request. Elements attempting to be liberal with what they 1068 accept may choose to ignore the brackets. If the element forwards 1069 the request, it must not include the brackets in the messages it 1070 sends. 1072 Message Details : ltgtruri 1074 INVITE SIP/2.0 1075 To: sip:user@example.com 1076 From: sip:caller@example.net;tag=39291 1077 Max-Forwards: 23 1078 Call-ID: ltgtruri.1@192.0.2.5 1079 CSeq: 1 INVITE 1080 Via: SIP/2.0/UDP 192.0.2.5 1081 Contact: 1082 Content-Type: application/sdp 1083 Content-Length: 160 1085 v=0 1086 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1087 s=- 1088 c=IN IP4 192.0.2.5 1089 t=3149328700 0 1090 m=audio 492170 RTP/AVP 0 12 1091 m=video 3227 RTP/AVP 31 1092 a=rtpmap:31 LPC 1094 3.1.2.8 Malformed SIP Request-URI (embedded LWS) 1096 This INVITE has illegal LWS within the Request-URI. 1098 An element receiving this request should respond with a 400 Bad 1099 Request. 1101 An element could attempt to ignore the embedded LWS for those schemes 1102 (like sip) where that would not introduce ambiguity. 1104 Message Details : lwsruri 1106 INVITE sip:user@example.com; lr SIP/2.0 1107 To: sip:user@example.com;tag=3xfe-9921883-z9f 1108 From: sip:caller@example.net;tag=231413434 1109 Max-Forwards: 5 1110 Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423 1111 CSeq: 2130706432 INVITE 1112 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395 1113 Contact: 1114 Content-Type: application/sdp 1115 Content-Length: 160 1117 v=0 1118 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1119 s=- 1120 c=IN IP4 192.0.2.1 1121 t=3149328700 0 1122 m=audio 492170 RTP/AVP 0 12 1123 m=video 3227 RTP/AVP 31 1124 a=rtpmap:31 LPC 1126 3.1.2.9 Multiple SP separating Request-Line elements 1128 This INVITE has illegal multiple SP characters between elements of 1129 the start line. 1131 It is acceptable to reject this request as malformed. An element 1132 that is liberal in what it accepts may ignore these extra SP 1133 characters while processing the request. If the element forwards the 1134 request, it must not include these extra SP characters in the 1135 messages it sends. 1137 Message Details : lwsstart 1139 INVITE sip:user@example.com SIP/2.0 1140 Max-Forwards: 8 1141 To: sip:user@example.com 1142 From: sip:caller@example.net;tag=8814 1143 Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com 1144 CSeq: 1893884 INVITE 1145 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923 1146 Contact: 1147 Content-Type: application/sdp 1148 Content-Length: 151 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=0 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.10 SP characters at end of Request-Line 1161 This OPTIONS request contains SP characters between the SIP-Version 1162 field and the CRLF terminating the Request-Line. 1164 It is acceptable to reject this request as malformed. An element 1165 that is liberal in what it accepts may ignore these extra SP 1166 characters while processing the request. If the element forwards the 1167 request, it must not include these extra SP characters in the 1168 messages it sends. 1170 Message Details : trws 1172 OPTIONS sip:remote-target@example.com SIP/2.02020 1173 Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093 1174 To: 1175 From: ;tag=329429089 1176 Call-ID: trws.oicu34958239neffasdhr2345r 1177 Accept: application/sdp 1178 CSeq: 238923 OPTIONS 1179 Max-Forwards: 70 1180 Content-Length: 0 1182 3.1.2.11 Escaped headers in SIP Request-URI 1184 This INVITE is malformed as the SIP Request-URI contains escaped 1185 headers. 1187 It is acceptable for an element to reject this request with a 400 Bad 1188 Request. An element could choose to be liberal in what it accepts 1189 and ignore the escaped headers. If the element is a proxy, the 1190 escaped headers must not appear in the Request-URI of forwarded 1191 request (and most certainly must not be translated into the actual 1192 header of the forwarded request). 1194 Message Details : escruri 1196 INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0 1197 To: sip:user@example.com 1198 From: sip:caller@example.net;tag=341518 1199 Max-Forwards: 7 1200 Contact: 1201 Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 1202 CSeq: 149209342 INVITE 1203 Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw 1204 Content-Type: application/sdp 1205 Content-Length: 151 1207 v=0 1208 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1209 s=- 1210 c=IN IP4 192.0.2.1 1211 t=0 0 1212 m=audio 492170 RTP/AVP 0 12 1213 m=video 3227 RTP/AVP 31 1214 a=rtpmap:31 LPC 1216 3.1.2.12 Invalid timezone in Date header field 1218 This INVITE is invalid as it contains a non GMT time zone in the SIP 1219 Date header field. 1221 It is acceptable to reject this request as malformed (though an 1222 element shouldn't do that unless the contents of the Date header 1223 field were actually important to its processing). An element wishing 1224 to be liberal in what it accepts could ignore this value altogether 1225 if it wasn't going to use the Date header field anyhow. Otherwise, 1226 it could attempt to interpret this date and adjust it to GMT. 1228 RFC 3261 explicitly defines the only acceptable timezone designation 1229 as "GMT". "UT", while synonymous with GMT per [RFC2822], is not 1230 valid. "UTC" and "UCT" are also invalid. 1232 Message Details : baddate 1234 INVITE sip:user@example.com SIP/2.0 1235 To: sip:user@example.com 1236 From: sip:caller@example.net;tag=2234923 1237 Max-Forwards: 70 1238 Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234 1239 CSeq: 1392934 INVITE 1240 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1241 Date: Fri, 01 Jan 2010 16:00:00 EST 1242 Contact: 1243 Content-Type: application/sdp 1244 Content-Length: 151 1246 v=0 1247 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1248 s=- 1249 c=IN IP4 192.0.2.5 1250 t=0 0 1251 m=audio 492170 RTP/AVP 0 12 1252 m=video 3227 RTP/AVP 31 1253 a=rtpmap:31 LPC 1255 3.1.2.13 Failure to enclose name-addr URI in <> 1257 This REGISTER request is malformed. The SIP URI contained in the 1258 Contact Header field has an escaped header, so the field must be in 1259 name-addr form (which implies the URI must be enclosed in <>). 1261 It is reasonable for an element receiving this request to respond 1262 with a 400 Bad Request. An element choosing to be liberal in what it 1263 accepts could infer the angle brackets since there is no ambiguity in 1264 this example. In general, that won't be possible. 1266 Message Details : regbadct 1268 REGISTER sip:example.com SIP/2.0 1269 To: sip:user@example.com 1270 From: sip:user@example.com;tag=998332 1271 Max-Forwards: 70 1272 Call-ID: regbadct.k345asrl3fdbv@10.0.0.1 1273 CSeq: 1 REGISTER 1274 Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 1275 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 1276 l: 0 1278 3.1.2.14 Spaces within addr-spec 1280 This request is malformed since the addr-spec in the To header field 1281 contains spaces. Parsers receiving this request must not break. It 1282 is reasonable to reject this request with a 400 Bad Request response. 1283 Elements attempting to be liberal may ignore the spaces. 1285 Message Details : badaspec 1287 OPTIONS sip:user@example.org SIP/2.0 1288 Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234 1289 Max-Forwards: 70 1290 From: "Bell, Alexander" ;tag=433423 1291 To: "Watson, Thomas" < sip:t.watson@example.org > 1292 Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3 1293 Accept: application/sdp 1294 CSeq: 3923239 OPTIONS 1295 l: 0 1297 3.1.2.15 Non-token characters in display-name 1299 This OPTIONS request is malformed since the display names in the To 1300 and From header fields contain non-token characters but are unquoted. 1302 It is reasonable to always reject this kind of error with a 400 Bad 1303 Request response. 1305 An element may attempt to be liberal in what it receives and infer 1306 the missing quotes. If this element were a proxy, it must not 1307 propagate the error into the request it forwards. As a consequence, 1308 if the fields are covered by a signature, there's not much point in 1309 trying to be liberal - the message should be simply rejected. 1311 Message Details : baddn 1313 OPTIONS sip:t.watson@example.org SIP/2.0 1314 Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw 1315 Max-Forwards: 70 1316 From: Bell, Alexander ;tag=43 1317 To: Watson, Thomas 1318 Call-ID: baddn.31415@c.example.com 1319 Accept: application/sdp 1320 CSeq: 3923239 OPTIONS 1321 l: 0 1323 3.1.2.16 Unknown protocol version 1325 To an element implementing [RFC3261], this request is malformed due 1326 to its high version number. 1328 The element should respond to the request with a 505 Version Not 1329 Supported error. 1331 Message Details : badvers 1333 OPTIONS sip:t.watson@example.org SIP/7.0 1334 Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw 1335 Max-Forwards: 70 1336 From: A. Bell ;tag=qweoiqpe 1337 To: T. Watson 1338 Call-ID: badvers.31417@c.example.com 1339 CSeq: 1 OPTIONS 1340 l: 0 1342 3.1.2.17 Start line and CSeq method mismatch 1344 This request has mismatching values for the method in the start line 1345 and the CSeq header field. Any element receiving this request will 1346 respond with a 400 Bad Request. 1348 Message Details : mismatch01 1350 OPTIONS sip:user@example.com SIP/2.0 1351 To: sip:j.user@example.com 1352 From: sip:caller@example.net;tag=34525 1353 Max-Forwards: 6 1354 Call-ID: mismatch01.dj0234sxdfl3 1355 CSeq: 8 INVITE 1356 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1357 l: 0 1359 3.1.2.18 Unknown Method with CSeq method mismatch 1361 This message has an unknown method, and a CSeq method tag which does 1362 not match it. 1364 Any element receiving this response will should respond with a 501 1365 Not Implemented. A 400 Bad Request is also acceptable, but choosing 1366 a 501 (particularly at proxies) has better future-proof 1367 characteristics. 1369 Message Details : mismatch02 1371 NEWMETHOD sip:user@example.com SIP/2.0 1372 To: sip:j.user@example.com 1373 From: sip:caller@example.net;tag=34525 1374 Max-Forwards: 6 1375 Call-ID: mismatch02.dj0234sxdfl3 1376 CSeq: 8 INVITE 1377 Contact: 1378 Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw 1379 Content-Type: application/sdp 1380 l: 139 1382 v=0 1383 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1384 c=IN IP4 192.0.2.1 1385 m=audio 492170 RTP/AVP 0 12 1386 m=video 3227 RTP/AVP 31 1387 a=rtpmap:31 LPC 1389 3.1.2.19 Overlarge response code 1391 This response has a response code larger than 699. An element 1392 receiving this response should simply drop it. 1394 Message Details : bigcode 1396 SIP/2.0 4294967301 better not break the receiver 1397 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 1398 Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i 1399 CSeq: 353494 INVITE 1400 From: ;tag=39ansfi3 1401 To: ;tag=902jndnke3 1402 Content-Length: 0 1403 Contact: 1405 3.2 Transaction layer semantics 1407 This section contains tests that exercise an implementation's parser 1408 and transaction layer logic. 1410 3.2.1 Missing transaction identifier 1412 This request indicates support for RFC 3261-style transaction 1413 identifiers by providing the z9hG4bK prefix to the branch parameter, 1414 but it provides no identifier. A parser must not break when 1415 receiving this message. An element receiving this request could 1416 reject the request with a 400 Response (preferably statelessly, as 1417 other requests from the source are likely to also have a malformed 1418 branch parameter), or it could fall back to the RFC 2543 style 1419 transaction identifier. 1421 Message Details : badbranch 1423 OPTIONS sip:user@example.com SIP/2.0 1424 To: sip:user@example.com 1425 From: sip:caller@example.org;tag=33242 1426 Max-Forwards: 3 1427 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK 1428 Accept: application/sdp 1429 Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n 1430 CSeq: 8 OPTIONS 1431 l: 0 1433 3.3 Application layer semantics 1435 This section contains tests that exercise an implementation's parser 1436 and application layer logic. 1438 3.3.1 Missing Required Header Fields 1440 This request contains no Call-ID, From, or To header fields. 1442 An element receiving this message must not break because of the 1443 missing information. Ideally, it will respond with a 400 Bad Request 1444 error. 1446 Message Details : insuf 1448 INVITE sip:user@example.com SIP/2.0 1449 CSeq: 193942 INVITE 1450 Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf 1451 Content-Type: application/sdp 1452 l: 153 1454 v=0 1455 o=mhandley 29739 7272939 IN IP4 192.0.2.95 1456 s=- 1457 c=IN IP4 192.0.2.95 1458 t=0 0 1459 m=audio 492170 RTP/AVP 0 12 1460 m=video 3227 RTP/AVP 31 1461 a=rtpmap:31 LPC 1463 3.3.2 Request-URI with unknown scheme 1465 This OPTIONS contains an unknown URI scheme in the Request-URI. A 1466 parser must accept this as a well-formed SIP request. 1468 An element receiving this request will reject it with a 416 1469 Unsupported URI Scheme response. 1471 Some early implementations attempt to look at the contents of the To 1472 header field to determine how to route this kind of request. That is 1473 an error. Despite the fact that the To header field and the Request 1474 URI frequently look alike in simplistic first-hop messages, the To 1475 header field contains no routing information. 1477 Message Details : unkscm 1479 OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0 1480 To: sip:user@example.com 1481 From: sip:caller@example.net;tag=384 1482 Max-Forwards: 3 1483 Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34 1484 CSeq: 3923423 OPTIONS 1485 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1486 Content-Length: 0 1488 3.3.3 Request-URI with known but atypical scheme 1490 This OPTIONS contains an Request-URI with an IANA registered scheme 1491 that does not commonly appear Request-URIs of SIP requests. A parser 1492 must accept this as a well-formed SIP request. 1494 If an element will never accept this scheme as meaningful in a 1495 request-URI, it is appropriate to treat it as unknown and return a 1496 416 Unsupported URI Scheme response. If the element might accept 1497 some URIs with this scheme, then a 404 Not Found is appropriate for 1498 those URIs it doesn't accept. 1500 Message Details : novelsc 1502 OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0 1503 To: sip:user@example.com 1504 From: sip:caller@example.net;tag=384 1505 Max-Forwards: 3 1506 Call-ID: novelsc.asdfasser0q239nwsdfasdkl34 1507 CSeq: 3923423 OPTIONS 1508 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1509 Content-Length: 0 1511 3.3.4 Unknown URI schemes in header fields 1513 This message contains registered schemes in the To, From and Contact 1514 header fields of a request. The message is syntactically valid. 1515 Parsers must not fail when receiving this message. 1517 Proxies should treat this message as they would any other request for 1518 this URI. A registrar would reject this request with a 400 Bad 1519 Request response since the To: header field is required to contain a 1520 SIP or SIPS URI as an AOR. 1522 Message Details : unksm2 1524 REGISTER sip:example.com SIP/2.0 1525 To: isbn:2983792873 1526 From: ;tag=3234233 1527 Call-ID: unksm2.daksdj@hyphenated-host.example.com 1528 CSeq: 234902 REGISTER 1529 Max-Forwards: 70 1530 Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw 1531 Contact: 1532 l: 0 1534 3.3.5 Proxy-Require and Require 1536 This request tests proper implementation of SIP's Proxy-Require and 1537 Require extension mechanisms. 1539 Any element receiving this request will respond with a 420 Bad 1540 Extension response containing an Unsupported header field listing 1541 these features from either the Require or Proxy-Require header field 1542 depending on the role in which the element is responding. 1544 Message Details : bext01 1546 OPTIONS sip:user@example.com SIP/2.0 1547 To: sip:j_user@example.com 1548 From: sip:caller@example.net;tag=242etr 1549 Max-Forwards: 6 1550 Call-ID: bext01.0ha0isndaksdj 1551 Require: nothingSupportsThis, nothingSupportsThisEither 1552 Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis 1553 CSeq: 8 OPTIONS 1554 Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw 1555 Content-Length: 0 1557 3.3.6 Unknown Content-Type 1559 This INVITE request contains a body of unknown type. It is 1560 syntactically valid. A parser must not fail when receiving it. 1562 A proxy receiving this request would process it just like any other 1563 INVITE. An endpoint receiving this request would reject it with a 1564 415 Unsupported Media Type error. 1566 Message Details : invut 1568 INVITE sip:user@example.com SIP/2.0 1569 Contact: 1570 To: sip:j.user@example.com 1571 From: sip:caller@example.net;tag=8392034 1572 Max-Forwards: 70 1573 Call-ID: invut.0ha0isndaksdjadsfij34n23d 1574 CSeq: 235448 INVITE 1575 Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw 1576 Content-Type: application/unknownformat 1577 Content-Length: 40 1579 1583 3.3.7 Unknown authorization scheme 1585 This REGISTER request contains an Authorization header field with an 1586 unknown scheme. The request is well-formed. A parser must not fail 1587 when receiving it. 1589 A proxy will treat this request as any other REGISTER. If it 1590 forwards the request, it will include this Authorization header field 1591 unmodified in the forwarded messages. 1593 A registrar that does not care about challenge-response 1594 authentication will simply ignore the Authorization header field, 1595 processing this registration as if the field were not present. A 1596 registrar that does care about challenge-response authentication will 1597 reject this request with a 401, issuing a new challenge with a scheme 1598 it understands. 1600 Endpoints choosing not to act as registrars will simply reject the 1601 request. A 405 Method Not Allowed is appropriate. 1603 Message Details : regaut01 1605 REGISTER sip:example.com SIP/2.0 1606 To: sip:j.user@example.com 1607 From: sip:j.user@example.com;tag=87321hj23128 1608 Max-Forwards: 8 1609 Call-ID: regaut01.0ha0isndaksdj 1610 CSeq: 9338 REGISTER 1611 Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw 1612 Authorization: NoOneKnowsThisScheme opaque-data=here 1613 Content-Length:0 1615 3.3.8 Multiple values in single value required fields 1617 The message contains a request with multiple Call-ID, To, From, 1618 Max-Forwards and CSeq values. An element receiving this request must 1619 not break. 1621 An element receiving this request would respond with a 400 Bad 1622 Request error. 1624 Message Details : multi01 1626 INVITE sip:user@company.com SIP/2.0 1627 Contact: 1628 Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw 1629 Max-Forwards: 70 1630 CSeq: 5 INVITE 1631 Call-ID: multi01.98asdh@192.0.2.1 1632 CSeq: 59 INVITE 1633 Call-ID: multi01.98asdh@192.0.2.2 1634 From: sip:caller@example.com;tag=3413415 1635 To: sip:user@example.com 1636 To: sip:other@example.net 1637 From: sip:caller@example.net;tag=2923420123 1638 Content-Type: application/sdp 1639 l: 155 1640 Contact: 1641 Max-Forwards: 5 1643 v=0 1644 o=mhandley 29739 7272939 IN IP4 192.0.2.25 1645 s=- 1646 c=IN IP4 192.0.2.25 1647 t=0 0 1648 m=audio 492170 RTP/AVP 0 12 1649 m=video 3227 RTP/AVP 31 1650 a=rtpmap:31 LPC 1652 3.3.9 Multiple Content-Length values 1654 Multiple conflicting Content-Length header field values appear in 1655 this request. 1657 From a framing perspective, this situation is equivalent to an 1658 invalid Content-Length value (or no value at all). 1660 An element receiving this message should respond with an error. This 1661 request appeared over UDP, so the remainder of the datagram can 1662 simply be discarded. If a request like this arrives over TCP, the 1663 framing error is not recoverable and the connection should be closed. 1665 Message Details : mcl01 1667 OPTIONS sip:user@example.com SIP/2.0 1668 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423 1669 To: sip:user@example.com 1670 From: sip:other@example.net;tag=3923942 1671 Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf 1672 CSeq: 15932 OPTIONS 1673 Content-Length: 13 1674 Max-Forwards: 60 1675 Content-Length: 5 1676 Content-Type: text/plain 1678 There's no way to know how many octets are supposed to be here. 1680 3.3.10 200 OK Response with broadcast Via header field value 1682 This message is a response with a 2nd Via header field value's 1683 sent-by containing 255.255.255.255. The message is well formed - 1684 parsers must not fail when receiving it. 1686 Per [RFC3261] an endpoint receiving this message should simply 1687 discard it. 1689 If a proxy followed normal response processing rules blindly, it 1690 would forward this response to the broadcast address. To protect 1691 against this being used as an avenue of attack, proxies should drop 1692 such responses. 1694 Message Details : bcast 1696 SIP/2.0 200 OK 1697 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 1698 Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23 1699 Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf 1700 CSeq: 35 INVITE 1701 From: sip:user@example.com;tag=11141343 1702 To: sip:user@example.edu;tag=2229 1703 Content-Length: 159 1704 Content-Type: application/sdp 1705 Contact: 1707 v=0 1708 o=mhandley 29739 7272939 IN IP4 192.0.2.198 1709 s=- 1710 c=IN IP4 192.0.2.198/127 1711 t=0 0 1712 m=audio 492170 RTP/AVP 0 12 1713 m=video 3227 RTP/AVP 31 1714 a=rtpmap:31 LPC 1716 3.3.11 Max-Forwards of zero 1718 This is a legal SIP request with the Max-Forwards header field value 1719 set to zero. 1721 A proxy should not forward the request and respond 483 (Too Many 1722 Hops). An endpoint should process the request as if the Max-Forwards 1723 field value were still positive. 1725 Message Details : zeromf 1727 OPTIONS sip:user@example.com SIP/2.0 1728 To: sip:user@example.com 1729 From: sip:caller@example.net;tag=3ghsd41 1730 Call-ID: zeromf.jfasdlfnm2o2l43r5u0asdfas 1731 CSeq: 39234321 OPTIONS 1732 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i 1733 Max-Forwards: 0 1734 Content-Length: 0 1736 3.3.12 REGISTER with a contact header parameter 1738 This register request contains a contact where the 'unknownparam' 1739 parameter must be interpreted as being a contact-param and not a 1740 url-param. 1742 This REGISTER should succeed. The response must not include 1743 "unknownparam" as a url-parameter for this binding. Likewise, 1744 "unknownparam" must not appear as part of the binding during 1745 subsequent fetches. 1747 Behavior is the same, of course, for any known contact-param 1748 parameter names. 1750 Message Details : cparam01 1752 REGISTER sip:example.com SIP/2.0 1753 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1754 Max-Forwards: 70 1755 From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe 1756 To: sip:watson@example.com 1757 Call-ID: cparam01.70710@saturn.example.com 1758 CSeq: 2 REGISTER 1759 Contact: sip:+19725552222@gw1.example.net;unknownparam 1760 l: 0 1762 3.3.13 REGISTER with a url parameter 1764 This register request contains a contact where the URI has an unknown 1765 parameter. 1767 The register should succeed and a subsequent retrieval of the 1768 registration must include "unknownparam" as a url-parameter. 1770 Behavior is the same, of course, for any known url-parameter names. 1772 Message Details : cparam02 1774 REGISTER sip:example.com SIP/2.0 1775 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1776 Max-Forwards: 70 1777 From: sip:watson@example.com;tag=838293 1778 To: sip:watson@example.com 1779 Call-ID: cparam02.70710@saturn.example.com 1780 CSeq: 3 REGISTER 1781 Contact: 1782 l: 0 1784 3.3.14 REGISTER with a url escaped header 1786 This register request contains a contact where the URI has an escaped 1787 header. 1789 The register should succeed and a subsequent retrieval of the 1790 registration must include the escaped Route header in the contact URI 1791 for this binding. 1793 Message Details : regescrt 1795 REGISTER sip:example.com SIP/2.0 1796 To: sip:user@example.com 1797 From: sip:user@example.com;tag=8 1798 Max-Forwards: 70 1799 Call-ID: regescrt.k345asrl3fdbv@192.0.2.1 1800 CSeq: 14398234 REGISTER 1801 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 1802 M: 1803 L:0 1805 3.3.15 Unacceptable Accept offering 1807 This request indicates the response must contain a body in an unknown 1808 type. In particular, since the Accept header field does not contain 1809 application/sdp, the response may not contain an SDP body. The 1810 recipient of this request could respond with a 406 Not Acceptable 1811 with a Warning/399 indicating that a response cannot be formulated in 1812 the formats offered in the Accept header field. It is also 1813 appropriate to respond with a 400 Bad Request since all SIP UAs 1814 supporting INVITE are required to support application/sdp. 1816 Message Details : sdp01 1818 INVITE sip:user@example.com SIP/2.0 1819 To: sip:j_user@example.com 1820 Contact: 1821 From: sip:caller@example.net;tag=234 1822 Max-Forwards: 5 1823 Call-ID: sdp01.ndaksdj9342dasdd 1824 Accept: text/nobodyKnowsThis 1825 CSeq: 8 INVITE 1826 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw 1827 Content-Length: 151 1828 Content-Type: application/sdp 1830 v=0 1831 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1832 s=- 1833 c=IN IP4 192.0.2.5 1834 t=0 0 1835 m=audio 492170 RTP/AVP 0 12 1836 m=video 3227 RTP/AVP 31 1837 a=rtpmap:31 LPC 1839 3.4 Backward compatibility 1841 3.4.1 INVITE with RFC2543 syntax 1843 This is a legal message per RFC 2543 (and several bis versions) which 1844 should be accepted by RFC 3261 elements which want to maintain 1845 backwards compatibility. 1846 o There is no branch parameter at all on the Via header field value 1847 o There is no From tag 1848 o There is no explicit Content-Length (The body is assumed to be all 1849 octets in the datagram after the null-line) 1850 o There is no Max-Forwards header field 1851 Message Details : inv2543 1853 INVITE sip:UserB@example.com SIP/2.0 1854 Via: SIP/2.0/UDP iftgw.example.com 1855 From: 1856 Record-Route: 1857 To: sip:+16505552222@ss1.example.net;user=phone 1858 Call-ID: inv2543.1717@ift.client.example.com 1859 CSeq: 56 INVITE 1860 Content-Type: application/sdp 1862 v=0 1863 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1864 s=- 1865 c=IN IP4 192.0.2.5 1866 t=0 0 1867 m=audio 492170 RTP/AVP 0 1869 4. Security Considerations 1871 This document presents NON NORMATIVE examples of SIP session 1872 establishment. The security considerations in [RFC3261] apply. 1874 Parsers must carefully consider edge conditions and malicious input 1875 as part of their design. Attacks on many Internet systems use 1876 crafted input to cause implementations to behave in undesirable ways. 1877 Many of the messages in this draft are designed to stress a parser 1878 implementation at points traditionally used for such attacks. This 1879 document does not, however, attempt to be comprehensive. It should 1880 be considered a seed to stimulate thinking and planning, not simply a 1881 set of tests to be passed. 1883 5. IANA Considerations 1885 This document has no actions for IANA. 1887 6. Acknowledgments 1889 The authors wish to thank the following individuals for their 1890 participation in the review of earlier versions of this document: 1891 Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen 1892 Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, 1893 Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua 1894 and Tom Taylor. 1896 Thanks to Neil Deason for contributing several messages and Kundan 1897 Singh for performing parser validation of messages in earlier 1898 versions. 1900 The following individuals provided significant comments during the 1901 early phases of the development of this document: Jean-Francois Mule, 1902 Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, 1903 Matt Cannon, John Hearty, the whole MCI WorldCom IPOP Design team, 1904 Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny 1905 Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom 1906 Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI 1907 WorldCom, 3Com, Cisco, Lucent and Nortel. 1909 7 Informative References 1911 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1912 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1913 August 1998. 1915 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1916 2001. 1918 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1919 A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, 1920 "SIP: Session Initiation Protocol", RFC 3261, June 2002. 1922 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1923 with Session Description Protocol (SDP)", RFC 3264, June 1924 2002. 1926 Authors' Addresses 1928 Robert J. Sparks (editor) 1929 Estacado Systems 1931 EMail: RjS@estacado.net 1933 Alan Hawrylyshen 1934 Jasomi Networks 1935 2033 Gateway Place 1936 Suite 500 1937 San Jose, CA 95110 1939 EMail: alan@jasomi.com 1940 Alan Johnston 1941 MCI 1942 100 South 4th Street 1943 St. Louis, MO 63102 1945 EMail: alan.johnston@mci.com 1947 Jonathan Rosenberg 1948 Cisco Systems 1949 600 Lanidex Plaza 1950 Parsippany, NJ 07052 1952 Phone: +1 973 952 5000 1953 EMail: jdrosen@cisco.com 1954 URI: http://www.jdrosen.net 1956 Henning Schulzrinne 1957 Columbia University 1958 Department of Computer Science 1959 450 Computer Science Building 1960 New York, NY 10027 1961 US 1963 Phone: +1 212 939 7042 1964 EMail: hgs@cs.columbia.edu 1965 URI: http://www.cs.columbia.edu 1967 Appendix A. Bit-exact archive of each test message 1969 The following text block is an encoded, gzip compressed TAR archive 1970 of files that represent each of the example messages discussed in 1971 Section 3. 1973 To recover the compressed archive file intact, the text of this 1974 document may be passed as input to the following Perl script (the 1975 output should be redirected to a file or piped to "tar -xzvf -"). 1977 #!/usr/bin/perl 1978 use strict; 1979 my $bdata = ""; 1980 use MIME::Base64; 1981 while(<>) { 1982 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 1983 if ( m/^\s*[^\s]+\s*$/) { 1984 $bdata = $bdata . $_; 1985 } 1986 } 1987 } 1988 print decode_base64($bdata); 1990 Figure 58 1992 Alternatively, the base-64 encoded block can be edited by hand to 1993 remove document structure lines and fed as input to any base-64 1994 decoding utility. 1996 A.1 Encoded Reference Messages 1998 -- BEGIN MESSAGE ARCHIVE -- 1999 H4sIAAAAAAACA+xdSXMbSXaW1O5lOOY4JvrmU4nRGHWLLDCXWkGBTbZETbO1 2000 tEKk1BHjcaiTqCyigEIVWFUgRDks2zpMeC4O3+3DhMMRvo5vdkyE/RfUP2IO 2001 PvnoqzOrsNSGhQsWtSq7IRCorCUT7/vyvZcvXx4Rg/htWisbJLg2owJYUSQp 2002 fFcVOfHOi4zRNci+kjGUZJnVgzKQwTUBXJtD6fgB8QThmtfw28Rr+qPqTTre 2003 a8vg/R0p3z453P/28YHgW+1Kx6feDn1JWm2bll3vWDjYf7KJymB15blFKv1P 2004 m8/uPRHqrh9I5X7dmtuqyEABW0cecWr16iu9/kvp6EHTaHQkjLC0uvKIvBTv 2005 u16XeIZfEVR2yfseO0lY+4ra9oawa7NLOQb11oQ7/ElI+bh8xI7sxO6wvRWQ 2006 46qEsYTw6sqhy07+jgS+62wIh3W3RXx2btiMoNwNv080ZXt15S6xbXH/XkU4 2007 6su8b5iAPZ6DHMMHBOh6B+E6rjtOFwC9ZjQdyu60W6vRdlARSLttWzUSWK6z 2008 6Rttdr0DelIRsI5YE3Wh15GrK3ZFYM1bXXk3fn/WF9GPNkMCmIR/CShp/COI 2009 CvwvFP8McUP8c7Tl1ejDmB+rMXgl+SMELMZIQmkCwDmUAnX2VxmVYYpFxiEw 2010 huieFPvEcB3TRdiSEGicAuIDRismbmCnj1jtXcXqjPDPgE9nOfxPwj8ESE7h 2011 X1LUYvyfS9l//Hz/cO/q4e/QIIQ/YuOrzgfsrAYQR28og2wYZWN7y2EYZoBF 2012 2G5ISBR9aphOK9QiIvxCNuTqWBKiRx+hnMR1kxy1pLu6co/dsiLc96wNAUDh 2013 G+IIiImiAJUKAOx/Ye/gkN3RdQJSY9xzJ9ZGfn25HGvpdlSROoF4eNameUzV 2014 O/yQOsdBnbVBhpx3TqusH9xqq86UH5ueCUhXmSqhIpU1UGcNFPafSANilFdX 2015 /Kq4ulKrZg8EVcCZrFUlHcNyBdblUAXC08Mnm7vPnwisVYgfPLUM6goYIXVw 2016 CLPnIFUvaLdIu4Kh8PDJ3feZDt9L/ndmyv5T2H8Qp/kfy3LB//PW/3INp6QN 2017 yEucamvT2IDdNPuHZWgEspIyAydbgdGgFJakFRidmteUlAnIxJ7JG5R3Em2Y 2018 aO+xMsLke1fxbzmnAC7S/6NiGMO/zPGvQqnA/9Lpf43yBTRAiCWoMI0eIknJ 2019 qIFJSEaSCOoEWL5jkKZvNIjPdEHuoyH+0H4bqfkNbEh5a2tja2MjpsCtfePS 2020 nnep4dIEL2yxkqei4Ylq3Tk1ODhShYOL0uFYr59Sz1+k/QckCWfwj5UC/0sz 2021 /quZ8V/NG/+nHfoTI/9uORz8J434J13qWidtGhv3D8u9oX/qIT+UdD7oq+lB 2022 fzC2w/fMOXRUI8xYXqj+DwHMjP9YLcb/uZTe6CkgAIRvH4wbUnUthW+IUeTa 2023 yZyDZLkce6XP88kR9fiJQ2yGUgiwJmkSQACyAZ8N/iZp4gaiXpcapr97YJiD 2024 ORd5oAIM1Y+0ahIpH5ChHffNhUw1anR6Xiqk52kA+lSOnaGDKLw4dw8hLc4v 2025 2+fXFHRtpKqga5sQqYXPpyhXwf/0ZTBb628K/48qp/lfQrDg/+Wb/2u8uMgU 2026 gIRo4KUVQSVO/5EQJgy/1ZWn9KRjeYx0HTeoW87xQafddr3AP6xb/kbel3tW 2027 UKfsRk889+WZGDudf2FRv1e3f753z911zrLHcuYJEyPc4cMDwXRtQ2RELjLp 2028 CQeSSVpwemxZFs3yyDquucZC5/+ADKWM/Qdwgf956n8S0iVdUTGADI1BQD0O 2029 MOHIo6QpMFQJHq1R65Sja7SGCNKaHsK6xuDs0jjWewJHfMM1caeBAGZ/OiZm 2030 T9Bhf9VN4mNaDx0/xNetoc6HJV1K6X138mgrMhixThzftHqa35081S+qqAPU 2031 cAynSXEuSkcoeKyxGQ3vXRz/a4yxvQXP/6gKzo7/hf23PP7f5MitXdYjrPN5 2032 fvaPi0ZNsHecY+8sPcPeZ5BIZBPKQpdahLGF0cRTOImT0/fZEVvk8zuSiLCM 2033 8Lkn9nVWLuAXHuMYnq1nuMaEmrQWO/8jg+z8D1AL/M+jPN375f7B4d7TEK+5 2034 4M/gxydBx3MuNPE79Pzy26X8tX2fzb2m+fy40fSCR11CvQcP+k7f/FPixNCX 2035 ZSY9EOxkn7NPDkjoNztGQPzy61BXERNBxMrOcRfGKWir4zQdt+uEN/nReId7 2036 fYYWiX9JUTP4R4X+/77iX8MaGyTPh3k0EfM4D/N3zgX67R/hnJBxZHv0ZKH+ 2037 P4jlDP5lpZj/XRL8T6fqZ4/2ArWQDBu4gVFmEZC2urJfEXryl9DmdZ3b/qZj 2038 Y7uJMJYgSg3TvZul43yHuv8Q6qO9FUjOY6wwXHmEu4498NBaigeRJPqr/4zJ 2039 49MEykgQ47xuGpBdurN0VWW40kM07cRDSc4TKJPTCVgDUbz17IOaryAkRpja 2040 8ilmuTKF+rVZT/9Mnv+XQJr/ESzif+ft/2Evv4R3ObWWJBDjrjhTZceFkir7 2041 tKSiPLYL9av9EmKMdUrZG+vCGvXj1+v5YLGW4T11dcWqCJF88pUhQA9dws1G 2042 00HYddgHIOLYshDEF4ZK07p9OOnmT9SMmeRfXREGfqqScjdvKcgW+551xpZT 2043 UmCLVk/Zm91hTZdLWCphuH1FrDmSNIuwgKKcl//Rgv3/Stb+Z0gu+H8++n9J 2044 UpmuXJLkyAbw6LHlBx7xyiOtgbXSr1j1XjC1R32349USyu72YHn/xJoh/ZsI 2045 owYxzEYiKCwSTU76zknXxZJ3grCFpYbH5wZrjo2w49lNx+dxYckJ+rsT1wAi 2046 oJfMV75D7fgIomNJEuI9krtsMeE8ILZFfBhNCaYmBO+WlPuZqigKD0tXzV4T 2047 hxVxquKV+x9YJzsd217s/L+U9f8pxfr/JbP/uZiIJQBE/sco03ZkpZ5nT9dR 2048 lL9jzHLgvkhiHQHsGOZps2EQ32ye4K7kBt4JIIZvMlIgp8ZgSbCEdY1rf2MM 2049 /0nTfrFAnSEUWVN2Midu59QaVfFhZbn9hayzvY5nLXb9fwL/SoT/wv83b/sv 2050 7cD78qnbCWi1hO+muKGE964kNwCWmO2j5a0JG7XqPuSPUXEBfVEOjUWR6w31 2051 hkgaFB95IuOGE6BrXdEkXerV0YlYlxx5SB+Matjgj8Zbj6JrikGdinWmxkwf 2052 8TdL51lhBhblcsVy/I65YPtPUmCa/yVc+P8Wzf9Dju+xZBi3NXlOQc+ZUyiH 2053 cjaRFO3esttz8qA+chJBL3KjTMJ/0KJBfaH6HwIZ/KtyYf/NpdxkAkA96geW 2054 cyw+YpLgGuHyO1lRNf3F7fXvyyXLMSg1br0OSQK+6Dgdv0Ps8rOn+68/D1zx 2055 iN70Ox794heW79wK1q3gs82aR16dfbmxubV1u/ILK1ivE78KN7rU8oybt9vE 2056 /6zrvjZeBK5b/txwKT9NtIIvdiaHn/Q9O3Bc+Gb5ZklRbr9Y//7W656/6qu9 2057 h5Vffyw8fsbergn3+Ke/6TmlztueXDdX4DapA19/H/2Bbq2/iP7Ct0s3y2J0 2058 o1bHMYiTcn6Z7PQnPLTk1q3X67dfsMql6toPf/v292///e1//fDm7e9/+Icf 2059 fvv2P97+51qoML8Ir/oa3lr/nl1ZLMeU3z6Ou65nlH71QLxZZj1wa4d//P71 2060 F59v36n8enPtL//iy7/+q1gaLYgQ1mThHDKQVtYRD0+lLxmn+4zEv6bEoB67 2061 d+n2+gvW/ZX//cN///Ff/+2Pf/fP//NPf1jeNTDvt/53imQJL9T/p6hKVv8r 2062 4v/mrf89Y/rfVzvTxQBaZnDcLY+a8V2HGGBZliErO6xquWZbDPjJwDp2t2q7 2063 7jp0my/1qzGiEkOHQ+8amafZahHD8Kq+n/az9z0Q61CRQT+OL14tebsEaUbC 2064 D1Wo5j1nLKZIVgaK79XmhLlEVr+rIE/WBZ1g0fN/IOP/k5Qi/+cS2X/TZsG8 2065 1LIgLXT4S2PnBiJxTWaIMnzTavAs3tgYxoLIkjQm/M13W3S6LKGjwd6LDDZd 2066 r0WCrHIjhdrNnRC5rGeEO+1aqyPwNcbVNTa8rW2yL+9s9g8v7Pe3Xed41gHA 2067 E/CvKKqUsf+K/C9LhP/QiNoXeBCXQAReT3BIiwquKTDd36Mtesk3oe25HBoM 2068 V2u5a3orCuvTRDA+rJ5S74yL71W+TondoVv8r/AmvJWzflX9Omt5dONZNCnv 2069 FdqclBl9j9nbd1ZQf+w+5w/ALdqIo0mLvGLmoB0+TkTY/GFn+XU2IBrp2jL+ 2070 LyGpL4r10OKdiaxUo1vE7hDKyNX803/+8Fe3qe8PmnDlf8RG7/5gw7Rwj7Iv 2071 z+b/b1/krIGugDUeOQAGysKzqGfEh6zmVb5EjrWK0Ot48aohLUa/6+yu3+5z 2072 hhhyf3UedwrblOMDZAyFcdJMO83WQMkaz7M1YKpG3n1Aus5upg7SU3X2s9dJ 2073 ZgTjdXKuo6balPM8SEnXybmOnKqT9zxSuk7OdVJ9/FyoCJk6qV4+zauT7mdB 2074 yN4LpK+TrQP1zO+VU0nLVsqppU7+6aEyRR15ijrSFHXwFHXQFHWmEGkIJtfR 2075 J1fRJleZopOn6OMpuniKHp6ig6fp3wlVMlZlL3GOUR34dfqG5ryUvXm8oib1 2076 6HpizOwCdMsL7Nlhvw9BOXZwHMw6AHBi/h8gp+x/GRbxf3O1//MTaV1NlJ+O 2077 dJiZN4wH+g9kEO7EnN+9WcrJ8SbyDLfpUcAVO/SZiOsYaSpYEiKwu75h+e3F 2078 5n/Pif8o9v+aT7ma/f/WIsit3cnhgWFGvglx/31R5KEH5Khm7JjMwjzLm4xT 2079 wIjUnJwWMmflO/aLrf/6+F98/D9Oz//LABb5vxbt/98SbG8yBUTQfmlSUWeD 2080 mKZh8ZVuTpMVGEeZ2TPzfXKSEkLpjJKBGi51Lb71Uhjc3/Wc6C8NS14zXFTU 2081 m/yDmKmUioSniFWFI1MXIayPUyzg/BWL8YbFsikWRXlX+J8TYLBQ+0/Faf5H 2082 oIj/nSf/5+t/IzPAXsog1DQoJTm+J4Fm0zlhuh/jeAkDXScGX/pNuhTv5OiA 2083 UNOxpk3I9wEn6YFY7+d4nQnLL7/7qFWzF53/B8jZ+M8i/8NS2X/nTqbDUykg 2084 PB1NuHzXhjy3EV9uFCOKSFTNusNVQNez6qRrGi7BruTJyMWW5w93CIIyU4aG 2085 RmIGmBlLVAHZWnIa8AF9GWy2bWI5HNaH7LHpLV9wXKFLzoTAFfh8KOuartAi 2086 zpng1gIa+ALxqODz3SV8avBKR1TgJ5aXw/hsWX6LBLX6LElgEv6xLGXG/yL+ 2087 cxn9PxeK68SSjORx27/EZbDBMw/6Lw3TnjaVe+HquRL8o8XhX2XK/hD/aoh/ 2088 ufD/zKU83vvu0d7h19/eWw4GQBMYYKSmnlLUxzPF6OR/k2eEsX4RlT5Pm18K 2089 H02rYwfWjC2Ayet/pRT+JQUU+78txP/LAN1myuuU6z+QPAl3fXnPz7acOx8U 2090 rbcaQn5AEj1R1TW+TdRODEm9U/Spz0FjSGvg0+buaZ6EeLQN0z+SsWCm8X+H 2091 mbD4OtvpAlHGOaOxkvoZMh71czIWGjmJja48oUKhly2yODV7xt6fKfS/RP6v 2092 kP/Zh4L/Fzz/N8r7i2Tpsvpg6NrBcS8wl8PEsj4EQxeSJ0uoiwfhQGCKcCA8 2093 TWK/5JPJ+HKOXvEiu37xRDcjIoXw3EIFHdejxHedhe7/gzL2HyzW/8+n9Pf/ 2094 ZP0vXHpvz4EwEYZivrOnxbPz6jpCPI/nyN3bi108Fzj+u6fU9muLjf9Dcnr8 2095 51uCFvifp//XJe3yEaXtyubmEPS4ggFAVxMGrGUifXCCOiI5jCJ92OXBCWMY 2096 pxsF/jTtYZZuHKUQHrU5d28Nhj7NzK9U5CQ66bjBEVls/m9VUrL4L/y/y6P/ 2097 h+v/H3ll4ZuywPPyRKNoVvXfnmrz35xNrmA8DrgvkqEZMC62X08r7dPueiXr 2098 FRnIYApamDrQAy9i56sr8BF79Jh0gsXu/8uT/aTxLxX+37mUGe//p6kYwXoD 2099 YYi0cTvbDcQw4QPoQ5pxxsg9/fiAP3ROjrD9dztB3fWsVyGEK8Jj91uHPnDc 2100 rn9Yt/yDWp2nIHHb5KRDRYYDUuUBGhmU/yhVA9bxR8SoBYvFP07b/6AY/5cN 2101 /+PQn4t9XdcwRmOX/Aykr4klmfiejU3j6HQHgjL/Dw4XAY7b0BPLZaix2pi/ 2102 8Ji9iBN7iI7f7YC9yskdD36kYSTsF+D7JiwW/7KS9f8V8Z/vOv61SdCPBC8F 2103 /fSs7hVu7fNohKtxEvTfgW18Llx8ZlARb7ZbAE60/3Em/kNFBf6XBP/5CdjR 2104 OAcblpBvmO5ot33cVzDG+4+4NY4a9UEgGFY0HUt8AQkzEHUIMDscI4YBuQyk 2105 GmEXtA39lDj2Ce46nu3Qrms2iK93rKxuggFr797LtuXR0CkxhzJ6aiLZwzyF 2106 qLBFo2erIg0gXZV1RcFIg/Il3JhRT9nHi8S/LEuZ8R8U8/9znf+TARYOqHdq 2107 1ajwzCGnxLLJkU3PCX8Qwv/Vq5eGxXfs9LtTE0AmhKrHAJT4RsOkje7AF4DC 2108 hSEallQVYSABhDGML/VIcgCTbMclPgWuyeNK6w46cU2X8A+I0K7Jr+XxBOSB 2109 dybumgH12C0kHQOkYY11Cn/nH/l9dI2pNN8Rz7GcY74Ajd3WPaVe0PGosLbv 2110 CE8895ih0197h6YVfKO98PVfqpyJ/0Fy4f9bLv9/6OR7kTUCRq+dTMeGTpES 2111 YGwygEhUe65BHhxkMG4wVld2azXaDnqrsxz3yDXOBr69c0wKQHl8THhiUefS 2112 7AFw2YkAn7asBef/AHI8/7cCiv0/51jS67+2WCOrnZIEYuA8PymMhLrrHUfR 2113 ABhJaFw8QF8uc+cDtOFw3wd/CoIbiS/azZqvii2rRTe4Gh2VMDSctTbYbFkv 2114 qbER+8K3jh32TawuG9XJMWUH2JVjH0yPHI+jlOVfj+bzXlns+g8VxPd/jPAv 2115 F/t/z33872UqvdgScA7spLAzNd1zotidmBWQd5OkJeBTx0gyxsAZEK4Mo1Yn 2116 QRQ9Ae64J+wIOXWaNjFps3GCJasj4Q7p0kFiII3r8GwEHSgDkzKV9p4l09Tt 2117 rFqAYTZuIM0oW0NGiUrbcwO35trVtTRdiarIzyHcuFjLnNdiVe3jql8nMHPs 2118 yOU7zXln1TWRlb3dr+5jbRfs7u5pKpDuMnzdh0CC2le7GlDv3l/jRCSK01TN 2119 tG7Ig/wihSRdUJKWYQg7b7yLFA93j9q2LGlNLirO4xC4Fe53Ul0LRaTcVuMm 2120 /qHHQ5SpJ+45NdcIXQNHlsMAOKxyz/Lbrm9FwQckYGJRb7HvtwTTsmn2yqsr 2121 4M0nf//RT27/5uvf/N/q9Y9v/O7NJ2fsq86N69fhT8FPPvpw/Wcf3PjzD6+B 2122 nw4rXf/dm49egTcf6ODNjX/53Qc3rt+48cm1f7z22xufXbsOVgf1rn/ITmuH 2123 V/ng2Z989OmNZwfwU/Bz/uGTTzkWLNP1HIvAn4M/419+/OknB8T5xvUp/Bn4 2124 U/7Nyqcf/n97VwMcVXWFs0kkGsCoZIhtknpNcAJpNtz33m72vQ3pxEIdpJgA 2125 SYCxjPXt7tvsy27exveTJQyM2aSVij+MmlrFH8iIAjo4FopFZiw/7QAtdbqL 2126 Nv0xSbFMlVTRAceKaZXe+95usrvZTYKtG8X75ffd97P3nXvOveeee865iG1E 2127 lZoHy/Dx9FkN+LBRUNSFgqyKbkxEIeJxoXbAbxXMhAwFaQrv6kdbby+YSaFD 2128 io0cQsf/pTKF8Bv4OCv/urFSD4NbYylguiIjK/hABgzemxkMZpzozpyWd93x 2129 YXPBPQ9X9Cr973YeLCzc9PESaoaoPbtyhzPv5VOL/jLU0//Glosd7b9x/Gnn 2130 O3UnPtlY+uLBskfPDjicq9b7vh3oXw+nN9Sc3ffvB/d23d33nydsr2wb7Npa 2131 eE2wj965e+tLufdcNffM5o2nXuk4IMxbcqzvZHjT2uPe+h3MxrrSzCxThumZ 2132 4BAMvg2L0RsUX5s9G+YHk70FJlLxrOxMpGPoV16dPTs7v/Zi0YzC/Z6luwq6 2133 n2ob2nBh4Ad3hmFwCz5fmh18GAY3d+Z7bynI/2dP+02djdKsxr/2nm7M7325 2134 V90up5UPukwZCWyYhajv/+yb1WvO5Px6oOLTfw2tvfvWoh+9+XF/uHhP386f 2135 bJh/+nzlk56ex7/b9Y/cbX/7rOjVuiNHMgu6bziyuyrv3KHB4rfOtF1TMfz4 2136 +8uWbjj0Z63ciUi7eGBweLDpaGj5udca//DO4Yayex3PLviA368d/nSBOiTP 2137 qThgovbuP5pz8Kd7195YsWvHHURgiMAQgbkEgaG6TH2wy3QSDUVwfVrpESOd 2138 oyPgtuDP4fUjRLoqi4odEWHR6JkrqDwkVhZooyw0ZKqg7XZYOno2m0KcMRe+ 2139 efbY6gO7NBPLLqLOnAv+rOA4XDF6UR71PbgQ5k670ijIyoFXj/yfmZmZ0Yma 2140 a/TYVAtzjGrmxJfPTRCt7GDnnRczZhcNH3775tBvHxl+reepI9wnAx+VXbA8 2141 994F276Tx3658sPcsqaPPljXzSyXb4DbuXk3ntph7Xl++vk67+uPzXIMbj8/ 2142 d9GJZXe8fvTQ73f/cc404ZEXztaWzoFNv5tx6sXuc6zn708/dPr51ff1X7un 2143 dzOXcf2P31rbscxaKm7Z+FhF6+I3Hto0OYXJbCbB2pcdVCRtX3QA+IT+X7H5 2144 /wz7D20j6z/ptv/wPl6qbeEVf6sYSW9RD9B0JbHUmGDLvK/NE2/0vY1fbXbX 2145 y6v4Fa4GO0BNHuvgrfNZnDE31tVrdce6dR1mGl3mERWAvlWPACSt1YGmlWgG 2146 BYwIEeMqxj4y6dYL4hw1UC0E3lifdfv9wIGaFjUbrrXfjw9k/U+SCS072TUd 2147 /CLo+TV64o7LQP7x7BVvvalMYf6vKluC/FutxP9zatZ/Pt/+D//Tvg8ghge9 2148 YovHwntdEn9XizeAVHqFV9x44SeFkWxSO0JMnAY44aaGhY3oLnq8u3y80uLy 2149 uBP9Y5Y2AJUZ5z6aY6EmufAbxVez7vt19avqgGoZ52ZecUE3I0hJnHLGdX+F 2150 PCe63JIgJFl6UuWAMtXjvxUmyr+FgUT+0y7/stDqVwUzokdz8kVfAFL5g+nc 2151 l4LjsasG5OJN9yk+KN5+7/OjLsUsC4pfk51Cso6Fs9AcZLlYPQPzs190aoyF 2152 s2IrvSS4cQS5R6YZi1WesCOhGZaLDS5Pbte/fCLGNcmrOFu/2B5gQv3fwiTK 2153 fxWR//TKf4LflBETaVf9Kt402QiNdBqMn45sEBGulEg2iHTIfys9xfLP0GP8 2154 P2gy/08LJhf/JSoOyY50V8bG0ayNGRmlPaqKE8YEAoHKZGo/EsxEqdZ5TZ/+ 2155 ezraPILEq4LLnJjGe3QwtnAwNsBj7GicOuEoNZlI0AV49dW+xO+RftjQKqqe 2156 73zdsoVr0pTnf6MgnTj+WymGyH9aENXsaQhBDaDLyxlQDqzl5TQIvRr6FQgH 2157 w13oT+gXoX2hPeHNuCyhKNwVvh+YQehguDN6LrRvPJ9Ijk2QSYqhLRwd31FE 2158 mBJvBenFg76XaaEFOSC43MrNDeOkkksZjEpRxnZzKbQWwaUZrkE0zSVz+eYm 2159 5SKTLIyLY8dkmLu0NDEcm9J1hmPnU7Tty7itNMFXBAFFlNqnNv6HslnH6H84 2160 JQDp/9O7/tMutgve5lqnhxdls0uSnXGTJqS8ocmhhGjAxyqH9cA+M3fi20E1 2161 AAB1sNgTsQZ1YBSLvxhGmpnrlvFOc8AOSpaAFX5FkByC3AzWrFlTUhJxXTSy 2162 jblkfLJ2TEws/oWfXANwkvcWFzvBSpTB8UkWoeJ7fb1KeqyPU9EzD0PI4Y+K 2163 iSPCVyBKADAfXayTA+ChzvC5HNFDo6Mdw0Elon4qmGh1QuAWXmr2Ca7FAu/C 2164 cYcASELAbZSBdt6nCehReNYtShoqGXuyyWgT4/5VSH1tkjRF430r8Wk7qK6u 2165 qEA/1ROOXXr+A9yOEVdVPQxUiWt+nxzlgAD6nBq9AtESs+Q36wWoQdrtIEoT 2166 3WA4H+A5OIbSJuLhLo4rIs1nUAhzBgBRn1/R28ICgB1YR0hsPBH9i/UJncBU 2167 FVtJW62VaHTHz4o8qAbdFI1Ex2GbaPCzlyzX/GiqARRVFiXEXiWYvVIyFnoU 2168 orbB6zVRH1pUor+lUWcF20NcxiXV4C5Ud1jJXHoWuJQ5oC3pGdbXCUj83FM8 2169 /6fhWPsf0f+/Qut/41n6mj2Ky0LFdMARlmvBpjyfW2ql/bTPwshWDRrmvjjT 2170 HkNT46zsTWqPT2xFEBNtB5CkfiUgICAgICAgICAgICAgICAgICAgICAgICAg 2171 ICAgICAgILgM8F+lVpDAABgBAA== 2172 -- END MESSAGE ARCHIVE -- 2174 Intellectual Property Statement 2176 The IETF takes no position regarding the validity or scope of any 2177 Intellectual Property Rights or other rights that might be claimed to 2178 pertain to the implementation or use of the technology described in 2179 this document or the extent to which any license under such rights 2180 might or might not be available; nor does it represent that it has 2181 made any independent effort to identify any such rights. Information 2182 on the procedures with respect to rights in RFC documents can be 2183 found in BCP 78 and BCP 79. 2185 Copies of IPR disclosures made to the IETF Secretariat and any 2186 assurances of licenses to be made available, or the result of an 2187 attempt made to obtain a general license or permission for the use of 2188 such proprietary rights by implementers or users of this 2189 specification can be obtained from the IETF on-line IPR repository at 2190 http://www.ietf.org/ipr. 2192 The IETF invites any interested party to bring to its attention any 2193 copyrights, patents or patent applications, or other proprietary 2194 rights that may cover technology that may be required to implement 2195 this standard. Please address the information to the IETF at 2196 ietf-ipr@ietf.org. 2198 Disclaimer of Validity 2200 This document and the information contained herein are provided on an 2201 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2202 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2203 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2204 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2205 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2206 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2208 Copyright Statement 2210 Copyright (C) The Internet Society (2005). This document is subject 2211 to the rights, licenses and restrictions contained in BCP 78, and 2212 except as set forth therein, the authors retain all their rights. 2214 Acknowledgment 2216 Funding for the RFC Editor function is currently provided by the 2217 Internet Society.