idnits 2.17.1 draft-ietf-sipping-torture-tests-08.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 2164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2141. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2154. ** 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 (October 23, 2005) is 6757 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: April 26, 2006 A. Hawrylyshen 5 Ditech Communications Corp. 6 A. Johnston 7 Tello Corporation 8 J. Rosenberg 9 Cisco Systems 10 H. Schulzrinne 11 Columbia University 12 October 23, 2005 14 Session Initiation Protocol Torture Test Messages 15 draft-ietf-sipping-torture-tests-08 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 April 26, 2006. 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 . . . . . . . . . . . 6 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 . . . . . . . . 15 72 3.1.1.11. Multipart MIME message . . . . . . . . . . . . . . 16 73 3.1.1.12. Unusual reason phrase . . . . . . . . . . . . . . 17 74 3.1.1.13. Empty reason phrase . . . . . . . . . . . . . . . 18 75 3.1.2. Invalid messages . . . . . . . . . . . . . . . . . . . 19 76 3.1.2.1. Extraneous header field separators . . . . . . . . 19 77 3.1.2.2. Content length larger than message . . . . . . . . 19 78 3.1.2.3. Negative Content-Length . . . . . . . . . . . . . 20 79 3.1.2.4. Request scalar fields with overlarge values . . . 21 80 3.1.2.5. Response scalar fields with overlarge values . . . 22 81 3.1.2.6. Unterminated quoted string in display-name . . . . 22 82 3.1.2.7. <> enclosing Request-URI . . . . . . . . . . . . . 23 83 3.1.2.8. Malformed SIP Request-URI (embedded LWS) . . . . . 24 84 3.1.2.9. Multiple SP separating Request-Line elements . . . 25 85 3.1.2.10. SP characters at end of Request-Line . . . . . . . 26 86 3.1.2.11. Escaped headers in SIP Request-URI . . . . . . . . 27 87 3.1.2.12. Invalid timezone in Date header field . . . . . . 27 88 3.1.2.13. Failure to enclose name-addr URI in <> . . . . . . 28 89 3.1.2.14. Spaces within addr-spec . . . . . . . . . . . . . 29 90 3.1.2.15. Non-token characters in display-name . . . . . . . 29 91 3.1.2.16. Unknown protocol version . . . . . . . . . . . . . 30 92 3.1.2.17. Start line and CSeq method mismatch . . . . . . . 30 93 3.1.2.18. Unknown Method with CSeq method mismatch . . . . . 30 94 3.1.2.19. Overlarge response code . . . . . . . . . . . . . 31 95 3.2. Transaction layer semantics . . . . . . . . . . . . . . . 31 96 3.2.1. Missing transaction identifier . . . . . . . . . . . . 31 97 3.3. Application layer semantics . . . . . . . . . . . . . . . 32 98 3.3.1. Missing Required Header Fields . . . . . . . . . . . . 32 99 3.3.2. Request-URI with unknown scheme . . . . . . . . . . . 33 100 3.3.3. Request-URI with known but atypical scheme . . . . . . 33 101 3.3.4. Unknown URI schemes in header fields . . . . . . . . . 34 102 3.3.5. Proxy-Require and Require . . . . . . . . . . . . . . 34 103 3.3.6. Unknown Content-Type . . . . . . . . . . . . . . . . . 35 104 3.3.7. Unknown authorization scheme . . . . . . . . . . . . . 35 105 3.3.8. Multiple values in single value required fields . . . 36 106 3.3.9. Multiple Content-Length values . . . . . . . . . . . . 37 107 3.3.10. 200 OK Response with broadcast Via header field 108 value . . . . . . . . . . . . . . . . . . . . . . . . 37 109 3.3.11. Max-Forwards of zero . . . . . . . . . . . . . . . . . 38 110 3.3.12. REGISTER with a contact header parameter . . . . . . . 38 111 3.3.13. REGISTER with a url parameter . . . . . . . . . . . . 39 112 3.3.14. REGISTER with a url escaped header . . . . . . . . . . 39 113 3.3.15. Unacceptable Accept offering . . . . . . . . . . . . . 40 114 3.4. Backward compatibility . . . . . . . . . . . . . . . . . . 41 115 3.4.1. INVITE with RFC2543 syntax . . . . . . . . . . . . . . 41 116 4. Security Considerations . . . . . . . . . . . . . . . . . . . 42 117 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 118 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 119 7. Informative References . . . . . . . . . . . . . . . . . . . . 43 120 Appendix A. Bit-exact archive of each test message . . . . . . . 43 121 A.1. Encoded Reference Messages . . . . . . . . . . . . . . . . 44 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 123 Intellectual Property and Copyright Statements . . . . . . . . . . 50 125 1. Overview 127 This document is informational, and is NOT NORMATIVE on any aspect of 128 SIP. 130 This document contains test messages based on the current version 131 (2.0) of the Session Initiation Protocol as defined in [RFC3261]. 132 Some messages exercise SIP's use of SDP as described in [RFC3264]. 134 These messages were developed and refined at the SIPIt 135 interoperability test events. 137 The test messages are organized into several sections. Some stress 138 only a SIP parser and others stress both the parser and the 139 application above it. Some messages are valid, and some are not. 140 Each example clearly calls out what makes any invalid messages 141 incorrect. 143 This document does not attempt to catalog every way to make an 144 invalid message, nor does it attempt to be comprehensive in exploring 145 unusual, but valid, messages. Instead, it tries to focus on areas 146 that have caused interoperability problems or have particularly 147 unfavorable characteristics if they are handled improperly. This 148 document is a seed for a test plan, not a test plan in itself. 150 The messages are presented in the text using a set of markup 151 conventions to avoid ambiguity and meet Internet-Draft layout 152 requirements. To resolve any remaining ambiguity, a bit-accurate 153 version of each message is encapsulated in an appendix. 155 2. Document Conventions 157 This document contains many example SIP messages. Although SIP is a 158 text-based protocol, many of these examples cannot be unambiguously 159 rendered without additional markup due to the constraints placed on 160 the formatting of RFCs. This document defines and uses the markup 161 defined in this section to remove that ambiguity. This markup uses 162 the start and end tag conventions of XML, but does not define any XML 163 document type. 165 The appendix contains an encoded binary form of all the messages and 166 the algorithm needed to decode them into files. 168 2.1. Representing Long Lines 170 Several of these examples contain unfolded lines longer than 72 171 characters. These are captured between tags. The 172 single unfolded line is reconstructed by directly concatenating all 173 lines appearing between the tags (discarding any line-feeds or 174 carriage returns). There will be no whitespace at the end of lines. 175 Any whitespace appearing at a fold-point will appear at the beginning 176 of a line. 178 The following represent the same string of bits: 180 Header-name: first value, reallylongsecondvalue, third value 182 183 Header-name: first value, 184 reallylongsecondvalue 185 , third value 186 188 189 Header-name: first value, 190 reallylong 191 second 192 value, 193 third value 194 196 Note that this is NOT SIP header line folding where different strings 197 of bits have equivalent meaning. 199 2.2. Representing Non-printable Characters 201 Several examples contain binary message bodies or header field values 202 containing non-ascii range UTF-8 encoded characters. These are 203 rendered here as a pair of hexadecimal digits per octet between 204 tags. This rendering applies even inside quoted-strings. 206 The following represent the same string of bits: 208 Header-name: value one 210 Header-name: value206F6Ee 212 The following is a Subject header field containing the euro symbol: 214 Subject: E282AC 216 2.3. Representing Long Repeating Strings 218 Several examples contain very large data values created with 219 repeating bit strings. Those will be rendered here using value. As with this rendering 221 applies even inside quoted-strings. 223 For example, the value "abcabcabc" can be rendered as abc. A display name of "1000000 bottles of beer" 225 could be rendered as 227 To: "130 bottles of beer" 228 230 and a Max-Forwards header field with a value of one google will be 231 rendered here as 233 Max-Forwards: 10 235 3. SIP Test Messages 237 3.1. Parser tests (syntax) 239 3.1.1. Valid messages 241 3.1.1.1. A short tortuous INVITE 243 This short, relatively human-readable message contains: 244 o line folding all over 245 o escaped characters within quotes 246 o an empty subject 247 o LWS between colons, semicolons, header field values, and other 248 fields 249 o both comma separated and separate listing of header field values 250 o mix of short and long form for the same header field name 251 o unkown Request-URI parameter 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 : 150 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 49217 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 non- 330 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: 150 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 49217 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 Address-of-Record (AOR) in this request to not prematurely shorten 428 the username. This 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 is a C%6Fntact header field value 454 A parser should accept this message as well formed. A proxy would 455 forward or reject the message depending on what the Request-URI meant 456 to it. An endpoint would reject this message with a 501. 458 Message Details : esc02 460 RE%47IST%45R sip:registrar.example.com SIP/2.0 461 To: "%Z%45" 462 From: "%Z%45" ;tag=f232jadfj23 463 Call-ID: esc02.asdfnqwo34rq23i34jrjasdcnl23nrlknsdf 464 Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234 465 CSeq: 29344 RE%47IST%45R 466 Max-Forwards: 70 467 Contact: 468 C%6Fntact: 469 Contact: 470 l: 0 472 3.1.1.6. Message with no LWS between display name and < 474 This OPTIONS request is not valid per the grammar in RFC 3261 since 475 there is no LWS between the quoted string in the display name and < 476 in the From header field value. This has been identified as a 477 specification bug that will be removed when RFC 3261 is revised. 478 Elements should accept this request as well formed. 480 Message Details : lwsdisp 482 OPTIONS sip:user@example.com SIP/2.0 483 To: sip:user@example.com 484 From: "caller";tag=323 485 Max-Forwards: 70 486 Call-ID: lwsdisp.1234abcd@funky.example.com 487 CSeq: 60 OPTIONS 488 Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw 489 l: 0 491 3.1.1.7. Long values in header fields 493 This well-formed request contains header fields with many values and 494 values that are very long. Features include: 495 o The To header field has a long display name, and long uri 496 parameter names and values 497 o The From header field has long header parameter names and values, 498 in particular a very long tag 499 o The Call-ID is one long token 501 Message Details : longreq 503 INVITE sip:user@example.com SIP/2.0 504 505 To: "I have a user name of 506 extreme proportion" 507 longvalue; 509 longparamname=shortvalue; 510 verylongParameterNameWithNoValue> 511 512 513 F: sip: 514 amazinglylongcallername@example.net 515 ;tag=12982424 516 ;unknownheaderparamname= 517 unknowheaderparamvalue 518 ;unknownValuelessparamname 519 520 Call-ID: longreq.onereallylongcallid 521 CSeq: 3882340 INVITE 522 523 Unknown-Long-Name: 524 unknown-long-value; 525 unknown-long-parameter-name = 526 unknown-long-parameter-value 527 528 Via: SIP/2.0/TCP sip33.example.com 529 v: SIP/2.0/TCP sip32.example.com 530 V: SIP/2.0/TCP sip31.example.com 531 Via: SIP/2.0/TCP sip30.example.com 532 ViA: SIP/2.0/TCP sip29.example.com 533 VIa: SIP/2.0/TCP sip28.example.com 534 VIA: SIP/2.0/TCP sip27.example.com 535 via: SIP/2.0/TCP sip26.example.com 536 viA: SIP/2.0/TCP sip25.example.com 537 vIa: SIP/2.0/TCP sip24.example.com 538 vIA: SIP/2.0/TCP sip23.example.com 539 V : SIP/2.0/TCP sip22.example.com 540 v : SIP/2.0/TCP sip21.example.com 541 V : SIP/2.0/TCP sip20.example.com 542 v : SIP/2.0/TCP sip19.example.com 543 Via : SIP/2.0/TCP sip18.example.com 544 Via : SIP/2.0/TCP sip17.example.com 545 Via: SIP/2.0/TCP sip16.example.com 546 Via: SIP/2.0/TCP sip15.example.com 547 Via: SIP/2.0/TCP sip14.example.com 548 Via: SIP/2.0/TCP sip13.example.com 549 Via: SIP/2.0/TCP sip12.example.com 550 Via: SIP/2.0/TCP sip11.example.com 551 Via: SIP/2.0/TCP sip10.example.com 552 Via: SIP/2.0/TCP sip9.example.com 553 Via: SIP/2.0/TCP sip8.example.com 554 Via: SIP/2.0/TCP sip7.example.com 555 Via: SIP/2.0/TCP sip6.example.com 556 Via: SIP/2.0/TCP sip5.example.com 557 Via: SIP/2.0/TCP sip4.example.com 558 Via: SIP/2.0/TCP sip3.example.com 559 Via: SIP/2.0/TCP sip2.example.com 560 Via: SIP/2.0/TCP sip1.example.com 561 562 Via: SIP/2.0/TCP 563 host.example.com;received=192.0.2.5; 564 branch=verylongbranchvalue 565 566 Max-Forwards: 70 567 568 Contact: amazinglylongcallername 570 @host5.example.net> 571 572 Content-Type: application/sdp 573 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. Multipart MIME message 677 This MESSAGE request contains two body parts. The second part is 678 binary encoded and contains null (0x00) characters. Receivers must 679 take care 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 Additional examples of multipart/mime messages, in particular S/MIME 685 messages, are available in the security call flow examples draft 686 [I-D.jennings-sip-sec-flows]. 688 Message Details : mpart01 690 MESSAGE sip:kumiko@example.org SIP/2.0 691 692 Via: SIP/2.0/UDP 127.0.0.1:5070 693 ;branch=z9hG4bK-d87543-4dade06d0bdb11ee-1--d87543-;rport 694 695 Max-Forwards: 70 696 Route: 697 698 Identity: r5mwreLuyDRYBi/0TiPwEsY3rEVsk/G2WxhgTV1PF7hHuL 699 IK0YWVKZhKv9Mj8UeXqkMVbnVq37CD+813gvYjcBUaZngQmXc9WNZSDN 700 GCzA+fWl9MEUHWIZo1CeJebdY/XlgKeTa0Olvq0rt70Q5jiSfbqMJmQF 701 teeivUhkMWYUA= 702 703 Contact: 704 To: 705 From: ;tag=2fb0dcc9 706 Call-ID: 3d9485ad0c49859b@Zmx1ZmZ5LW1hYy0xNi5sb2NhbA.. 707 CSeq: 1 MESSAGE 708 Content-Transfer-Encoding: binary 709 Content-Type: multipart/mixed;boundary=7a9cbec02ceef655 710 Date: Sat, 15 Oct 2005 04:44:56 GMT 711 User-Agent: SIPimp.org/0.2.5 (curses) 712 Content-Length: 553 714 --7a9cbec02ceef655 715 Content-Type: text/plain 716 Content-Transfer-Encoding: binary 718 Hello 719 --7a9cbec02ceef655 720 Content-Type: application/octet-stream 721 Content-Transfer-Encoding: binary 722 723 3082015206092A86 724 4886F70D010702A08201433082013F02 725 01013109300706052B0E03021A300B06 726 092A864886F70D010701318201203082 727 011C020101307C3070310B3009060355 728 04061302555331133011060355040813 729 0A43616C69666F726E69613111300F06 730 03550407130853616E204A6F7365310E 731 300C060355040A130573697069743129 732 3027060355040B132053697069742054 733 65737420436572746966696361746520 734 417574686F7269747902080195007102 735 330113300706052B0E03021A300D0609 736 2A864886F70D01010105000481808EF4 737 66F948F0522DD2E5978E9D95AAE9F2FE 738 15A06659716292E8DA2AA8D8350A68CE 739 FFAE3CBD2BFF1675DDD5648E593DD647 740 28F26220F7E941749E330D9A15EDABDB 741 93D10C42102E7B7289D29CC0C9AE2EFB 742 C7C0CFF9172F3B027E4FC027E1546DE4 743 B6AA3ABB3E66CCCB5DD6C64B8383149C 744 B8E6FF182D944FE57B65BC99D005 745 746 --7a9cbec02ceef655-- 748 3.1.1.12. Unusual reason phrase 750 This 200 response contains a reason phrase other than "OK". The 751 reason phrase is intended for human consumption, and may contain any 752 string produced by 754 Reason-Phrase = *(reserved / unreserved / escaped 755 / UTF8-NONASCII / UTF8-CONT / SP / HTAB) 757 This particular response contains unreserved and non-ASCII UTF-8 758 characters. This response is well formed. A parser must accept this 759 message. 761 Message Details : unreason 763 764 SIP/2.0 200 = 2**3 * 5**2 D0BDD0BE20D181D182 765 D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4 766 D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0 767 BED0B5 768 769 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 770 Call-ID: unreason.1234ksdfak3j2erwedfsASdf 771 CSeq: 35 INVITE 772 From: sip:user@example.com;tag=11141343 773 To: sip:user@example.edu;tag=2229 774 Content-Length: 154 775 Content-Type: application/sdp 776 Contact: 778 v=0 779 o=mhandley 29739 7272939 IN IP4 192.0.2.198 780 s=- 781 c=IN IP4 192.0.2.198 782 t=0 0 783 m=audio 49217 RTP/AVP 0 12 784 m=video 3227 RTP/AVP 31 785 a=rtpmap:31 LPC 787 3.1.1.13. Empty reason phrase 789 This well formed response contains no reason phrase. A parser must 790 accept this message. The space character after the reason code is 791 required. If it were not present, this message could be rejected as 792 invalid (a liberal receiver would accept it anyway). 794 Message Details : noreason 796 SIP/2.0 10020 797 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 798 Call-ID: noreason.asndj203insdf99223ndf 799 CSeq: 35 INVITE 800 From: ;tag=39ansfi3 801 To: ;tag=902jndnke3 802 Content-Length: 0 803 Contact: 805 3.1.2. Invalid messages 807 This section contains several invalid messages reflecting errors seen 808 at interoperability events and exploring important edge conditions 809 that can be induced through malformed messages. This section does 810 not attempt to be a comprehensive list of all types of invalid 811 messages. 813 3.1.2.1. Extraneous header field separators 815 The Via header field of this request contains additional semicolons 816 and commas without parameters or values. The Contact header field 817 contains additional semicolons without parameters. This message is 818 syntactically invalid. 820 An element receiving this request should respond with a 400 Bad 821 Request error. 823 Message Details : badinv01 825 INVITE sip:user@example.com SIP/2.0 826 To: sip:j.user@example.com 827 From: sip:caller@example.net;tag=134161461246 828 Max-Forwards: 7 829 Call-ID: badinv01.0ha0isndaksdjasdf3234nas 830 CSeq: 8 INVITE 831 Via: SIP/2.0/UDP 192.0.2.15;;,;,, 832 Contact: "Joe" ;;;; 833 Content-Length: 152 834 Content-Type: application/sdp 836 v=0 837 o=mhandley 29739 7272939 IN IP4 192.0.2.15 838 s=- 839 c=IN IP4 192.0.2.15 840 t=0 0 841 m=audio 49217 RTP/AVP 0 12 842 m=video 3227 RTP/AVP 31 843 a=rtpmap:31 LPC 845 3.1.2.2. Content length larger than message 847 This is a request message with a Content Length that is larger than 848 the actual length of the body. 850 When sent over UDP (as this message ostensibly was), the receiving 851 element should respond with a 400 Bad Request error. If this message 852 arrived over a stream-based transport such as TCP, there's not much 853 the receiving could do but wait for more data on the stream and close 854 the connection if none is forthcoming in a reasonable period of time. 856 Message Details : clerr 858 INVITE sip:user@example.com SIP/2.0 859 Max-Forwards: 80 860 To: sip:j.user@example.com 861 From: sip:caller@example.net;tag=93942939o2 862 Contact: 863 Call-ID: clerr.0ha0isndaksdjweiafasdk3 864 CSeq: 8 INVITE 865 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523 866 Content-Type: application/sdp 867 Content-Length: 9999 869 v=0 870 o=mhandley 29739 7272939 IN IP4 192.0.2.155 871 s=- 872 c=IN IP4 192.0.2.155 873 t=0 0 874 m=audio 49217 RTP/AVP 0 12 875 m=video 3227 RTP/AVP 31 876 a=rtpmap:31 LPC 878 3.1.2.3. Negative Content-Length 880 This request has a negative value for Content-Length. 882 An element receiving this message should respond with an error. This 883 request appeared over UDP, so the remainder of the datagram can 884 simply be discarded. If a request like this arrives over TCP, the 885 framing error is not recoverable and the connection should be closed. 886 The same behavior is appropriate for messages that arrive without a 887 numeric value in the Content-Length header field such as: 889 Content-Length: five 891 Implementors should take extra precautions if the technique they 892 choose for converting this ascii field into an integral form can 893 return a negative value. In particular, the result must not be used 894 as a counter or array index. 896 Message Details : ncl 898 INVITE sip:user@example.com SIP/2.0 899 Max-Forwards: 254 900 To: sip:j.user@example.com 901 From: sip:caller@example.net;tag=32394234 902 Call-ID: ncl.0ha0isndaksdj2193423r542w35 903 CSeq: 0 INVITE 904 Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw 905 Contact: 906 Content-Type: application/sdp 907 Content-Length: -999 909 v=0 910 o=mhandley 29739 7272939 IN IP4 192.0.2.53 911 s=- 912 c=IN IP4 192.0.2.53 913 t=0 0 914 m=audio 49217 RTP/AVP 0 12 915 m=video 3227 RTP/AVP 31 916 a=rtpmap:31 LPC 918 3.1.2.4. Request scalar fields with overlarge values 920 This request contains several scalar header field values outside 921 their legal range. 922 o the CSeq sequence number is >2**32-1. 923 o the Max-Forwards value is >255. 924 o the Expires value is >2**32-1. 925 o the Contact expires parameter value is >2**32-1. 927 An element receiving this request should respond with a 400 Bad 928 Request due to the CSeq error. If only the Max-Forwards field were 929 in error, the element could choose process the request as if the 930 field were absent. If only the expiry values were in error, the 931 element could treat them as if they contained the default values for 932 expiration (3600 in this case). 934 Other scalar request fields that may contain aberrant values include, 935 but are not limited to, the Contact q value, the Timestamp value, and 936 the Via ttl parameter. 938 Message Details : scalar02 940 REGISTER sip:example.com SIP/2.0 941 Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3 942 To: 943 From: ;tag=239232jh3 944 CSeq: 36893488147419103232 REGISTER 945 Call-ID: scalar02.23o0pd9vanlq3wnrlnewofjas9ui32 946 Max-Forwards: 300 947 Expires: 10 948 Contact: 949 ;expires=280297596632815 950 Content-Length: 0 952 3.1.2.5. Response scalar fields with overlarge values 954 This response contains several scalar header field values outside 955 their legal range. 956 o the CSeq sequence number is >2**32-1. 957 o The Retry-After field is unreasonably large (note that RFC 3261 958 does not define a legal range for this field). 959 o The Warning field has a warning-value with more than 3 digits 961 An element receiving this response will simply discard it. 963 Message Details : scalarlg 965 SIP/2.0 503 Service Unavailable 966 967 Via: SIP/2.0/TCP host129.example.com 968 ;branch=z9hG4bKzzxdiwo34sw 969 ;received=192.0.2.129 970 971 To: 972 From: ;tag=2easdjfejw 973 CSeq: 9292394834772304023312 OPTIONS 974 Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r 975 Retry-After: 949302838503028349304023988 976 Warning: 1812 overture "In Progress" 977 Content-Length: 0 979 3.1.2.6. Unterminated quoted string in display-name 981 This is a request with an unterminated quote in the display name of 982 the To field. An element receiving this request should return an 400 983 Bad Request error. 985 An element could attempt to infer a terminating quote and accept the 986 message. Such an element needs to take care that it makes a 987 reasonable inference when it encounters 989 To: "Mr J. User 991 Message Details : quotbal 993 INVITE sip:user@example.com SIP/2.0 994 To: "Mr. J. User 995 From: sip:caller@example.net;tag=93334 996 Max-Forwards: 10 997 Call-ID: quotbal.aksdj 998 Contact: 999 CSeq: 8 INVITE 1000 Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234 1001 Content-Type: application/sdp 1002 Content-Length: 152 1004 v=0 1005 o=mhandley 29739 7272939 IN IP4 192.0.2.15 1006 s=- 1007 c=IN IP4 192.0.2.15 1008 t=0 0 1009 m=audio 49217 RTP/AVP 0 12 1010 m=video 3227 RTP/AVP 31 1011 a=rtpmap:31 LPC 1013 3.1.2.7. <> enclosing Request-URI 1015 This INVITE request is invalid because the Request-URI has been 1016 enclosed within in "<>". 1018 It is reasonable to always reject a request with this error with a 1019 400 Bad Request. Elements attempting to be liberal with what they 1020 accept may choose to ignore the brackets. If the element forwards 1021 the request, it must not include the brackets in the messages it 1022 sends. 1024 Message Details : ltgtruri 1026 INVITE SIP/2.0 1027 To: sip:user@example.com 1028 From: sip:caller@example.net;tag=39291 1029 Max-Forwards: 23 1030 Call-ID: ltgtruri.1@192.0.2.5 1031 CSeq: 1 INVITE 1032 Via: SIP/2.0/UDP 192.0.2.5 1033 Contact: 1034 Content-Type: application/sdp 1035 Content-Length: 159 1037 v=0 1038 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1039 s=- 1040 c=IN IP4 192.0.2.5 1041 t=3149328700 0 1042 m=audio 49217 RTP/AVP 0 12 1043 m=video 3227 RTP/AVP 31 1044 a=rtpmap:31 LPC 1046 3.1.2.8. Malformed SIP Request-URI (embedded LWS) 1048 This INVITE has illegal LWS within the Request-URI. 1050 An element receiving this request should respond with a 400 Bad 1051 Request. 1053 An element could attempt to ignore the embedded LWS for those schemes 1054 (like sip) where that would not introduce ambiguity. 1056 Message Details : lwsruri 1058 INVITE sip:user@example.com; lr SIP/2.0 1059 To: sip:user@example.com;tag=3xfe-9921883-z9f 1060 From: sip:caller@example.net;tag=231413434 1061 Max-Forwards: 5 1062 Call-ID: lwsruri.asdfasdoeoi2323-asdfwrn23-asd834rk423 1063 CSeq: 2130706432 INVITE 1064 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395 1065 Contact: 1066 Content-Type: application/sdp 1067 Content-Length: 159 1069 v=0 1070 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1071 s=- 1072 c=IN IP4 192.0.2.1 1073 t=3149328700 0 1074 m=audio 49217 RTP/AVP 0 12 1075 m=video 3227 RTP/AVP 31 1076 a=rtpmap:31 LPC 1078 3.1.2.9. Multiple SP separating Request-Line elements 1080 This INVITE has illegal multiple SP characters between elements of 1081 the start line. 1083 It is acceptable to reject this request as malformed. An element 1084 that is liberal in what it accepts may ignore these extra SP 1085 characters while processing the request. If the element forwards the 1086 request, it must not include these extra SP characters in the 1087 messages it sends. 1089 Message Details : lwsstart 1091 INVITE sip:user@example.com SIP/2.0 1092 Max-Forwards: 8 1093 To: sip:user@example.com 1094 From: sip:caller@example.net;tag=8814 1095 Call-ID: lwsstart.dfknq234oi243099adsdfnawe3@example.com 1096 CSeq: 1893884 INVITE 1097 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923 1098 Contact: 1099 Content-Type: application/sdp 1100 Content-Length: 150 1102 v=0 1103 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1104 s=- 1105 c=IN IP4 192.0.2.1 1106 t=0 0 1107 m=audio 49217 RTP/AVP 0 12 1108 m=video 3227 RTP/AVP 31 1109 a=rtpmap:31 LPC 1111 3.1.2.10. SP characters at end of Request-Line 1113 This OPTIONS request contains SP characters between the SIP-Version 1114 field and the CRLF terminating the Request-Line. 1116 It is acceptable to reject this request as malformed. An element 1117 that is liberal in what it accepts may ignore these extra SP 1118 characters while processing the request. If the element forwards the 1119 request, it must not include these extra SP characters in the 1120 messages it sends. 1122 Message Details : trws 1124 OPTIONS sip:remote-target@example.com SIP/2.02020 1125 Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093 1126 To: 1127 From: ;tag=329429089 1128 Call-ID: trws.oicu34958239neffasdhr2345r 1129 Accept: application/sdp 1130 CSeq: 238923 OPTIONS 1131 Max-Forwards: 70 1132 Content-Length: 0 1134 3.1.2.11. Escaped headers in SIP Request-URI 1136 This INVITE is malformed as the SIP Request-URI contains escaped 1137 headers. 1139 It is acceptable for an element to reject this request with a 400 Bad 1140 Request. An element could choose to be liberal in what it accepts 1141 and ignore the escaped headers. If the element is a proxy, the 1142 escaped headers must not appear in the Request-URI of forwarded 1143 request (and most certainly must not be translated into the actual 1144 header of the forwarded request). 1146 Message Details : escruri 1148 INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0 1149 To: sip:user@example.com 1150 From: sip:caller@example.net;tag=341518 1151 Max-Forwards: 7 1152 Contact: 1153 Call-ID: escruri.23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5 1154 CSeq: 149209342 INVITE 1155 Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw 1156 Content-Type: application/sdp 1157 Content-Length: 150 1159 v=0 1160 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1161 s=- 1162 c=IN IP4 192.0.2.1 1163 t=0 0 1164 m=audio 49217 RTP/AVP 0 12 1165 m=video 3227 RTP/AVP 31 1166 a=rtpmap:31 LPC 1168 3.1.2.12. Invalid timezone in Date header field 1170 This INVITE is invalid as it contains a non GMT time zone in the SIP 1171 Date header field. 1173 It is acceptable to reject this request as malformed (though an 1174 element shouldn't do that unless the contents of the Date header 1175 field were actually important to its processing). An element wishing 1176 to be liberal in what it accepts could ignore this value altogether 1177 if it wasn't going to use the Date header field anyhow. Otherwise, 1178 it could attempt to interpret this date and adjust it to GMT. 1180 RFC 3261 explicitly defines the only acceptable timezone designation 1181 as "GMT". "UT", while synonymous with GMT per [RFC2822], is not 1182 valid. "UTC" and "UCT" are also invalid. 1184 Message Details : baddate 1186 INVITE sip:user@example.com SIP/2.0 1187 To: sip:user@example.com 1188 From: sip:caller@example.net;tag=2234923 1189 Max-Forwards: 70 1190 Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234 1191 CSeq: 1392934 INVITE 1192 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1193 Date: Fri, 01 Jan 2010 16:00:00 EST 1194 Contact: 1195 Content-Type: application/sdp 1196 Content-Length: 150 1198 v=0 1199 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1200 s=- 1201 c=IN IP4 192.0.2.5 1202 t=0 0 1203 m=audio 49217 RTP/AVP 0 12 1204 m=video 3227 RTP/AVP 31 1205 a=rtpmap:31 LPC 1207 3.1.2.13. Failure to enclose name-addr URI in <> 1209 This REGISTER request is malformed. The SIP URI contained in the 1210 Contact Header field has an escaped header, so the field must be in 1211 name-addr form (which implies the URI must be enclosed in <>). 1213 It is reasonable for an element receiving this request to respond 1214 with a 400 Bad Request. An element choosing to be liberal in what it 1215 accepts could infer the angle brackets since there is no ambiguity in 1216 this example. In general, that won't be possible. 1218 Message Details : regbadct 1220 REGISTER sip:example.com SIP/2.0 1221 To: sip:user@example.com 1222 From: sip:user@example.com;tag=998332 1223 Max-Forwards: 70 1224 Call-ID: regbadct.k345asrl3fdbv@10.0.0.1 1225 CSeq: 1 REGISTER 1226 Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 1227 Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E 1228 l: 0 1230 3.1.2.14. Spaces within addr-spec 1232 This request is malformed since the addr-spec in the To header field 1233 contains spaces. Parsers receiving this request must not break. It 1234 is reasonable to reject this request with a 400 Bad Request response. 1235 Elements attempting to be liberal may ignore the spaces. 1237 Message Details : badaspec 1239 OPTIONS sip:user@example.org SIP/2.0 1240 Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234 1241 Max-Forwards: 70 1242 From: "Bell, Alexander" ;tag=433423 1243 To: "Watson, Thomas" < sip:t.watson@example.org > 1244 Call-ID: badaspec.sdf0234n2nds0a099u23h3hnnw009cdkne3 1245 Accept: application/sdp 1246 CSeq: 3923239 OPTIONS 1247 l: 0 1249 3.1.2.15. Non-token characters in display-name 1251 This OPTIONS request is malformed since the display names in the To 1252 and From header fields contain non-token characters but are unquoted. 1254 It is reasonable to always reject this kind of error with a 400 Bad 1255 Request response. 1257 An element may attempt to be liberal in what it receives and infer 1258 the missing quotes. If this element were a proxy, it must not 1259 propagate the error into the request it forwards. As a consequence, 1260 if the fields are covered by a signature, there's not much point in 1261 trying to be liberal - the message should be simply rejected. 1263 Message Details : baddn 1265 OPTIONS sip:t.watson@example.org SIP/2.0 1266 Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw 1267 Max-Forwards: 70 1268 From: Bell, Alexander ;tag=43 1269 To: Watson, Thomas 1270 Call-ID: baddn.31415@c.example.com 1271 Accept: application/sdp 1272 CSeq: 3923239 OPTIONS 1273 l: 0 1275 3.1.2.16. Unknown protocol version 1277 To an element implementing [RFC3261], this request is malformed due 1278 to its high version number. 1280 The element should respond to the request with a 505 Version Not 1281 Supported error. 1283 Message Details : badvers 1285 OPTIONS sip:t.watson@example.org SIP/7.0 1286 Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw 1287 Max-Forwards: 70 1288 From: A. Bell ;tag=qweoiqpe 1289 To: T. Watson 1290 Call-ID: badvers.31417@c.example.com 1291 CSeq: 1 OPTIONS 1292 l: 0 1294 3.1.2.17. Start line and CSeq method mismatch 1296 This request has mismatching values for the method in the start line 1297 and the CSeq header field. Any element receiving this request will 1298 respond with a 400 Bad Request. 1300 Message Details : mismatch01 1302 OPTIONS sip:user@example.com SIP/2.0 1303 To: sip:j.user@example.com 1304 From: sip:caller@example.net;tag=34525 1305 Max-Forwards: 6 1306 Call-ID: mismatch01.dj0234sxdfl3 1307 CSeq: 8 INVITE 1308 Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw 1309 l: 0 1311 3.1.2.18. Unknown Method with CSeq method mismatch 1313 This message has an unknown method in the start line, and a CSeq 1314 method tag which does not match. 1316 Any element receiving this response should respond with a 501 Not 1317 Implemented. A 400 Bad Request is also acceptable, but choosing a 1318 501 (particularly at proxies) has better future-proof 1319 characteristics. 1321 Message Details : mismatch02 1323 NEWMETHOD sip:user@example.com SIP/2.0 1324 To: sip:j.user@example.com 1325 From: sip:caller@example.net;tag=34525 1326 Max-Forwards: 6 1327 Call-ID: mismatch02.dj0234sxdfl3 1328 CSeq: 8 INVITE 1329 Contact: 1330 Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw 1331 Content-Type: application/sdp 1332 l: 138 1334 v=0 1335 o=mhandley 29739 7272939 IN IP4 192.0.2.1 1336 c=IN IP4 192.0.2.1 1337 m=audio 49217 RTP/AVP 0 12 1338 m=video 3227 RTP/AVP 31 1339 a=rtpmap:31 LPC 1341 3.1.2.19. Overlarge response code 1343 This response has a response code larger than 699. An element 1344 receiving this response should simply drop it. 1346 Message Details : bigcode 1348 SIP/2.0 4294967301 better not break the receiver 1349 Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe 1350 Call-ID: bigcode.asdof3uj203asdnf3429uasdhfas3ehjasdfas9i 1351 CSeq: 353494 INVITE 1352 From: ;tag=39ansfi3 1353 To: ;tag=902jndnke3 1354 Content-Length: 0 1355 Contact: 1357 3.2. Transaction layer semantics 1359 This section contains tests that exercise an implementation's parser 1360 and transaction layer logic. 1362 3.2.1. Missing transaction identifier 1364 This request indicates support for RFC 3261-style transaction 1365 identifiers by providing the z9hG4bK prefix to the branch parameter, 1366 but it provides no identifier. A parser must not break when 1367 receiving this message. An element receiving this request could 1368 reject the request with a 400 Response (preferably statelessly, as 1369 other requests from the source are likely to also have a malformed 1370 branch parameter), or it could fall back to the RFC 2543 style 1371 transaction identifier. 1373 Message Details : badbranch 1375 OPTIONS sip:user@example.com SIP/2.0 1376 To: sip:user@example.com 1377 From: sip:caller@example.org;tag=33242 1378 Max-Forwards: 3 1379 Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK 1380 Accept: application/sdp 1381 Call-ID: badbranch.sadonfo23i420jv0as0derf3j3n 1382 CSeq: 8 OPTIONS 1383 l: 0 1385 3.3. Application layer semantics 1387 This section contains tests that exercise an implementation's parser 1388 and application layer logic. 1390 3.3.1. Missing Required Header Fields 1392 This request contains no Call-ID, From, or To header fields. 1394 An element receiving this message must not break because of the 1395 missing information. Ideally, it will respond with a 400 Bad Request 1396 error. 1398 Message Details : insuf 1400 INVITE sip:user@example.com SIP/2.0 1401 CSeq: 193942 INVITE 1402 Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdj.insuf 1403 Content-Type: application/sdp 1404 l: 152 1406 v=0 1407 o=mhandley 29739 7272939 IN IP4 192.0.2.95 1408 s=- 1409 c=IN IP4 192.0.2.95 1410 t=0 0 1411 m=audio 49217 RTP/AVP 0 12 1412 m=video 3227 RTP/AVP 31 1413 a=rtpmap:31 LPC 1415 3.3.2. Request-URI with unknown scheme 1417 This OPTIONS contains an unknown URI scheme in the Request-URI. A 1418 parser must accept this as a well-formed SIP request. 1420 An element receiving this request will reject it with a 416 1421 Unsupported URI Scheme response. 1423 Some early implementations attempt to look at the contents of the To 1424 header field to determine how to route this kind of request. That is 1425 an error. Despite the fact that the To header field and the Request 1426 URI frequently look alike in simplistic first-hop messages, the To 1427 header field contains no routing information. 1429 Message Details : unkscm 1431 OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0 1432 To: sip:user@example.com 1433 From: sip:caller@example.net;tag=384 1434 Max-Forwards: 3 1435 Call-ID: unkscm.nasdfasser0q239nwsdfasdkl34 1436 CSeq: 3923423 OPTIONS 1437 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1438 Content-Length: 0 1440 3.3.3. Request-URI with known but atypical scheme 1442 This OPTIONS contains an Request-URI with an IANA registered scheme 1443 that does not commonly appear Request-URIs of SIP requests. A parser 1444 must accept this as a well-formed SIP request. 1446 If an element will never accept this scheme as meaningful in a 1447 request-URI, it is appropriate to treat it as unknown and return a 1448 416 Unsupported URI Scheme response. If the element might accept 1449 some URIs with this scheme, then a 404 Not Found is appropriate for 1450 those URIs it doesn't accept. 1452 Message Details : novelsc 1454 OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0 1455 To: sip:user@example.com 1456 From: sip:caller@example.net;tag=384 1457 Max-Forwards: 3 1458 Call-ID: novelsc.asdfasser0q239nwsdfasdkl34 1459 CSeq: 3923423 OPTIONS 1460 Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234 1461 Content-Length: 0 1463 3.3.4. Unknown URI schemes in header fields 1465 This message contains registered schemes in the To, From and Contact 1466 header fields of a request. The message is syntactically valid. 1467 Parsers must not fail when receiving this message. 1469 Proxies should treat this message as they would any other request for 1470 this URI. A registrar would reject this request with a 400 Bad 1471 Request response since the To: header field is required to contain a 1472 SIP or SIPS URI as an AOR. 1474 Message Details : unksm2 1476 REGISTER sip:example.com SIP/2.0 1477 To: isbn:2983792873 1478 From: ;tag=3234233 1479 Call-ID: unksm2.daksdj@hyphenated-host.example.com 1480 CSeq: 234902 REGISTER 1481 Max-Forwards: 70 1482 Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw 1483 Contact: 1484 l: 0 1486 3.3.5. Proxy-Require and Require 1488 This request tests proper implementation of SIP's Proxy-Require and 1489 Require extension mechanisms. 1491 Any element receiving this request will respond with a 420 Bad 1492 Extension response containing an Unsupported header field listing 1493 these features from either the Require or Proxy-Require header field 1494 depending on the role in which the element is responding. 1496 Message Details : bext01 1498 OPTIONS sip:user@example.com SIP/2.0 1499 To: sip:j_user@example.com 1500 From: sip:caller@example.net;tag=242etr 1501 Max-Forwards: 6 1502 Call-ID: bext01.0ha0isndaksdj 1503 Require: nothingSupportsThis, nothingSupportsThisEither 1504 Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis 1505 CSeq: 8 OPTIONS 1506 Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw 1507 Content-Length: 0 1509 3.3.6. Unknown Content-Type 1511 This INVITE request contains a body of unknown type. It is 1512 syntactically valid. A parser must not fail when receiving it. 1514 A proxy receiving this request would process it just like any other 1515 INVITE. An endpoint receiving this request would reject it with a 1516 415 Unsupported Media Type error. 1518 Message Details : invut 1520 INVITE sip:user@example.com SIP/2.0 1521 Contact: 1522 To: sip:j.user@example.com 1523 From: sip:caller@example.net;tag=8392034 1524 Max-Forwards: 70 1525 Call-ID: invut.0ha0isndaksdjadsfij34n23d 1526 CSeq: 235448 INVITE 1527 Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw 1528 Content-Type: application/unknownformat 1529 Content-Length: 40 1531 1535 3.3.7. Unknown authorization scheme 1537 This REGISTER request contains an Authorization header field with an 1538 unknown scheme. The request is well-formed. A parser must not fail 1539 when receiving it. 1541 A proxy will treat this request as any other REGISTER. If it 1542 forwards the request, it will include this Authorization header field 1543 unmodified in the forwarded messages. 1545 A registrar that does not care about challenge-response 1546 authentication will simply ignore the Authorization header field, 1547 processing this registration as if the field were not present. A 1548 registrar that does care about challenge-response authentication will 1549 reject this request with a 401, issuing a new challenge with a scheme 1550 it understands. 1552 Endpoints choosing not to act as registrars will simply reject the 1553 request. A 405 Method Not Allowed is appropriate. 1555 Message Details : regaut01 1557 REGISTER sip:example.com SIP/2.0 1558 To: sip:j.user@example.com 1559 From: sip:j.user@example.com;tag=87321hj23128 1560 Max-Forwards: 8 1561 Call-ID: regaut01.0ha0isndaksdj 1562 CSeq: 9338 REGISTER 1563 Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw 1564 Authorization: NoOneKnowsThisScheme opaque-data=here 1565 Content-Length:0 1567 3.3.8. Multiple values in single value required fields 1569 The message contains a request with multiple Call-ID, To, From, Max- 1570 Forwards and CSeq values. An element receiving this request must not 1571 break. 1573 An element receiving this request would respond with a 400 Bad 1574 Request error. 1576 Message Details : multi01 1578 INVITE sip:user@company.com SIP/2.0 1579 Contact: 1580 Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw 1581 Max-Forwards: 70 1582 CSeq: 5 INVITE 1583 Call-ID: multi01.98asdh@192.0.2.1 1584 CSeq: 59 INVITE 1585 Call-ID: multi01.98asdh@192.0.2.2 1586 From: sip:caller@example.com;tag=3413415 1587 To: sip:user@example.com 1588 To: sip:other@example.net 1589 From: sip:caller@example.net;tag=2923420123 1590 Content-Type: application/sdp 1591 l: 154 1592 Contact: 1593 Max-Forwards: 5 1595 v=0 1596 o=mhandley 29739 7272939 IN IP4 192.0.2.25 1597 s=- 1598 c=IN IP4 192.0.2.25 1599 t=0 0 1600 m=audio 49217 RTP/AVP 0 12 1601 m=video 3227 RTP/AVP 31 1602 a=rtpmap:31 LPC 1604 3.3.9. Multiple Content-Length values 1606 Multiple conflicting Content-Length header field values appear in 1607 this request. 1609 From a framing perspective, this situation is equivalent to an 1610 invalid Content-Length value (or no value at all). 1612 An element receiving this message should respond with an error. This 1613 request appeared over UDP, so the remainder of the datagram can 1614 simply be discarded. If a request like this arrives over TCP, the 1615 framing error is not recoverable and the connection should be closed. 1617 Message Details : mcl01 1619 OPTIONS sip:user@example.com SIP/2.0 1620 Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423 1621 To: sip:user@example.com 1622 From: sip:other@example.net;tag=3923942 1623 Call-ID: mcl01.fhn2323orihawfdoa3o4r52o3irsdf 1624 CSeq: 15932 OPTIONS 1625 Content-Length: 13 1626 Max-Forwards: 60 1627 Content-Length: 5 1628 Content-Type: text/plain 1630 There's no way to know how many octets are supposed to be here. 1632 3.3.10. 200 OK Response with broadcast Via header field value 1634 This message is a response with a 2nd Via header field value's 1635 sent-by containing 255.255.255.255. The message is well formed - 1636 parsers must not fail when receiving it. 1638 Per [RFC3261] an endpoint receiving this message should simply 1639 discard it. 1641 If a proxy followed normal response processing rules blindly, it 1642 would forward this response to the broadcast address. To protect 1643 against this being used as an avenue of attack, proxies should drop 1644 such responses. 1646 Message Details : bcast 1648 SIP/2.0 200 OK 1649 Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923 1650 Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23 1651 Call-ID: bcast.0384840201234ksdfak3j2erwedfsASdf 1652 CSeq: 35 INVITE 1653 From: sip:user@example.com;tag=11141343 1654 To: sip:user@example.edu;tag=2229 1655 Content-Length: 154 1656 Content-Type: application/sdp 1657 Contact: 1659 v=0 1660 o=mhandley 29739 7272939 IN IP4 192.0.2.198 1661 s=- 1662 c=IN IP4 192.0.2.198 1663 t=0 0 1664 m=audio 49217 RTP/AVP 0 12 1665 m=video 3227 RTP/AVP 31 1666 a=rtpmap:31 LPC 1668 3.3.11. Max-Forwards of zero 1670 This is a legal SIP request with the Max-Forwards header field value 1671 set to zero. 1673 A proxy should not forward the request and respond 483 (Too Many 1674 Hops). An endpoint should process the request as if the Max-Forwards 1675 field value were still positive. 1677 Message Details : zeromf 1679 OPTIONS sip:user@example.com SIP/2.0 1680 To: sip:user@example.com 1681 From: sip:caller@example.net;tag=3ghsd41 1682 Call-ID: zeromf.jfasdlfnm2o2l43r5u0asdfas 1683 CSeq: 39234321 OPTIONS 1684 Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i 1685 Max-Forwards: 0 1686 Content-Length: 0 1688 3.3.12. REGISTER with a contact header parameter 1690 This register request contains a contact where the 'unknownparam' 1691 parameter must be interpreted as being a contact-param and not a url- 1692 param. 1694 This REGISTER should succeed. The response must not include 1695 "unknownparam" as a url-parameter for this binding. Likewise, 1696 "unknownparam" must not appear as a url-parameter in any binding 1697 during subsequent fetches. 1699 Behavior is the same, of course, for any known contact-param 1700 parameter names. 1702 Message Details : cparam01 1704 REGISTER sip:example.com SIP/2.0 1705 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1706 Max-Forwards: 70 1707 From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe 1708 To: sip:watson@example.com 1709 Call-ID: cparam01.70710@saturn.example.com 1710 CSeq: 2 REGISTER 1711 Contact: sip:+19725552222@gw1.example.net;unknownparam 1712 l: 0 1714 3.3.13. REGISTER with a url parameter 1716 This register request contains a contact where the URI has an unknown 1717 parameter. 1719 The register should succeed and a subsequent retrieval of the 1720 registration must include "unknownparam" as a url-parameter. 1722 Behavior is the same, of course, for any known url-parameter names. 1724 Message Details : cparam02 1726 REGISTER sip:example.com SIP/2.0 1727 Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw 1728 Max-Forwards: 70 1729 From: sip:watson@example.com;tag=838293 1730 To: sip:watson@example.com 1731 Call-ID: cparam02.70710@saturn.example.com 1732 CSeq: 3 REGISTER 1733 Contact: 1734 l: 0 1736 3.3.14. REGISTER with a url escaped header 1738 This register request contains a contact where the URI has an escaped 1739 header. 1741 The register should succeed and a subsequent retrieval of the 1742 registration must include the escaped Route header in the contact URI 1743 for this binding. 1745 Message Details : regescrt 1747 REGISTER sip:example.com SIP/2.0 1748 To: sip:user@example.com 1749 From: sip:user@example.com;tag=8 1750 Max-Forwards: 70 1751 Call-ID: regescrt.k345asrl3fdbv@192.0.2.1 1752 CSeq: 14398234 REGISTER 1753 Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw 1754 M: 1755 L:0 1757 3.3.15. Unacceptable Accept offering 1759 This request indicates the response must contain a body in an unknown 1760 type. In particular, since the Accept header field does not contain 1761 application/sdp, the response may not contain an SDP body. The 1762 recipient of this request could respond with a 406 Not Acceptable 1763 with a Warning/399 indicating that a response cannot be formulated in 1764 the formats offered in the Accept header field. It is also 1765 appropriate to respond with a 400 Bad Request since all SIP User- 1766 Agents (UAs) supporting INVITE are required to support application/ 1767 sdp. 1769 Message Details : sdp01 1771 INVITE sip:user@example.com SIP/2.0 1772 To: sip:j_user@example.com 1773 Contact: 1774 From: sip:caller@example.net;tag=234 1775 Max-Forwards: 5 1776 Call-ID: sdp01.ndaksdj9342dasdd 1777 Accept: text/nobodyKnowsThis 1778 CSeq: 8 INVITE 1779 Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw 1780 Content-Length: 150 1781 Content-Type: application/sdp 1783 v=0 1784 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1785 s=- 1786 c=IN IP4 192.0.2.5 1787 t=0 0 1788 m=audio 49217 RTP/AVP 0 12 1789 m=video 3227 RTP/AVP 31 1790 a=rtpmap:31 LPC 1792 3.4. Backward compatibility 1794 3.4.1. INVITE with RFC2543 syntax 1796 This is a legal message per RFC 2543 (and several bis versions) which 1797 should be accepted by RFC 3261 elements which want to maintain 1798 backwards compatibility. 1799 o There is no branch parameter at all on the Via header field value 1800 o There is no From tag 1801 o There is no explicit Content-Length (The body is assumed to be all 1802 octets in the datagram after the null-line) 1803 o There is no Max-Forwards header field 1804 Message Details : inv2543 1806 INVITE sip:UserB@example.com SIP/2.0 1807 Via: SIP/2.0/UDP iftgw.example.com 1808 From: 1809 Record-Route: 1810 To: sip:+16505552222@ss1.example.net;user=phone 1811 Call-ID: inv2543.1717@ift.client.example.com 1812 CSeq: 56 INVITE 1813 Content-Type: application/sdp 1815 v=0 1816 o=mhandley 29739 7272939 IN IP4 192.0.2.5 1817 s=- 1818 c=IN IP4 192.0.2.5 1819 t=0 0 1820 m=audio 49217 RTP/AVP 0 1822 4. Security Considerations 1824 This document presents NON NORMATIVE examples of SIP session 1825 establishment. The security considerations in [RFC3261] apply. 1827 Parsers must carefully consider edge conditions and malicious input 1828 as part of their design. Attacks on many Internet systems use 1829 crafted input to cause implementations to behave in undesirable ways. 1830 Many of the messages in this draft are designed to stress a parser 1831 implementation at points traditionally used for such attacks. This 1832 document does not, however, attempt to be comprehensive. It should 1833 be considered a seed to stimulate thinking and planning, not simply a 1834 set of tests to be passed. 1836 5. IANA Considerations 1838 This document has no actions for IANA. 1840 6. Acknowledgments 1842 The final detailed review of this document was performed by: Diego 1843 Besprosvan, Vijay Gurbani, Shashi Kumar, Derek MacDonald, Gautham 1844 Narasimhan, Nils Ohlmeier, Bob Penfield, Reinaldo Penno, Marc Petit- 1845 Huguenin, Richard Sugarman, and Venkatesh Venkataramanan. 1847 Earlier versions of this document were reviewed by: Aseem Agarwal, 1848 Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen Jennings, Vijay 1849 Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, Marc Petit- 1850 Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua and Tom 1851 Taylor. 1853 Thanks to Cullen Jennings and Eric Rescorla for their contribution to 1854 the multipart/mime sections of this document and their work 1855 constructing S/MIME examples in [I-D.jennings-sip-sec-flows]. Thanks 1856 to Neil Deason for contributing several messages and Kundan Singh for 1857 performing parser validation of messages in earlier versions. 1859 The following individuals provided significant comments during the 1860 early phases of the development of this document: Jean-Francois Mule, 1861 Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, 1862 Matt Cannon, John Hearty, the whole MCI IPOP Design team, Scott 1863 Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny Mistry, 1864 Steve McKinnon, and Denise Ingram, Denise Caballero, Tom Redman, Ilya 1865 Slain, Pat Sollee, John Truetken, and others from MCI, 3Com, Cisco, 1866 Lucent and Nortel. 1868 7. Informative References 1870 [I-D.jennings-sip-sec-flows] 1871 Jennings, C. and K. Ono, "Example call flows using SIP 1872 security mechanisms", draft-jennings-sip-sec-flows-03 1873 (work in progress), July 2005. 1875 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1876 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1877 August 1998. 1879 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1880 April 2001. 1882 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1883 A., Peterson, J., Sparks, R., Handley, M., and E. 1884 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1885 June 2002. 1887 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1888 with Session Description Protocol (SDP)", RFC 3264, 1889 June 2002. 1891 Appendix A. Bit-exact archive of each test message 1893 The following text block is an encoded, gzip compressed TAR archive 1894 of files that represent each of the example messages discussed in 1895 Section 3. 1897 To recover the compressed archive file intact, the text of this 1898 document may be passed as input to the following Perl script (the 1899 output should be redirected to a file or piped to "tar -xzvf -"). 1901 #!/usr/bin/perl 1902 use strict; 1903 my $bdata = ""; 1904 use MIME::Base64; 1905 while(<>) { 1906 if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { 1907 if ( m/^\s*[^\s]+\s*$/) { 1908 $bdata = $bdata . $_; 1909 } 1910 } 1911 } 1912 print decode_base64($bdata); 1914 Figure 58 1916 Alternatively, the base-64 encoded block can be edited by hand to 1917 remove document structure lines and fed as input to any base-64 1918 decoding utility. 1920 A.1. Encoded Reference Messages 1922 -- BEGIN MESSAGE ARCHIVE -- 1923 H4sIAMUmXEMCA+xdW2zc2Hm2nexNG6UN3LRF0QdaiOJdyxwdnkMOhyOPVrIt 1924 27It22tdvHYTeM8MDzWc4ZAjkqORvK2bbIAAedmHtEHRdlvkoUCLFAjSlyLF 1925 9rJPLYoWrTdAg6JFHwp0i+5D0SIoEAQFuj2HnAuH5GgoW3PxmgcazYU/b4f/ 1926 //3Xc04Rq9ipk1JGxe6xITVAW1YUvXc5K/W8syYheEygP0lIECWJ0gkSkMAx 1927 DhwbQWs4LrY57phdcerYrjr96AZtb91L5/0paTdvbazevLHOOXo933CIvUT2 1928 cK1ukIxlb3Prq7fmYQZMT23pON/+Nr958RZXthxXzLRpS1YtL4EsWCja2CyV 1929 Cw+U8mWxeK2qVhoigkicnlrDe/wly25iW3XynEwPecmmO3Ez54lhnOWWDXoo 1930 UyX2DHeOXQnObGeKdMtS4AyLCy7eLogIiRBNT21YdOc72HUs8yy3UbZq2KH7 1931 erfhZpre7z23sjg9dQEbBr96Mc8V2zzvqBqgl2dCU3UABorSgKiMyqbZBEAp 1932 qVWT0DMtl0qk7uY5XK8begm7umXOO2qdHm+d7OQ5pEB6iwrX6sjpKSPP0dub 1933 nno6nj/tC/+hDREABsm/CLJh+YcCTOV/rPJPJa4r/0za4ijaYsy2lah49eKH 1934 J7AIQRGGAQDFQIqg0E8ZmBFCKHKQBAYkusXFDlYtU7Mg0kUIKrsAO4DCioYq 1935 yGxLbO5pldUhyT8VfDJM9T9I/gUAxWPsnygCAWURlX8xm031/0ja6o2t1Y2V 1936 oxd/k7ie+EOqXxWmsKMWQFB6PR6kapTq9ppJZZgKLERGRYQ87xBVM2ueFeHL 1937 r0BVroJEzr/0PsZJ0DaJMUua01MX6Snz3CVbP8sBgbuKTQ5SVuSEbB4A+set 1938 rG/QM1qmi0sUe84F7pEdX8oE7nTRJySmy2/s10kcUrU2Xyfmtlum9yB5uLNb 1939 oG9WoVamxo9B9jmoyNSUkKFMb1ChN8it3hI7wChNTzkFfnqqVIhucAuAIVmt 1940 gBuqbnG0ywWZu71xa3556xZHbwqybbu6SiwOQdjdhITpKVyw3XoN1/NI4K7f 1941 uvAso+Gzif/mUNE/gf8noJD9JyJJSvF/1PZfrOPU6wOyFoTaUhIfsBlGf691 1942 nUDaQm7gYC/QV0pe6/UC/V3jbiXkAlK2p/wmSEs99zDQ36Otj8v3tMq/bu4C 1943 YZzxHxmBsP0nA5TK/8TZf5XMY1iAAhKFLLXoBShmI2Zgr0j6nAjKGOiOqeKq 1944 o1awQ21BFqPBTtd/62v5dXxIaWHh7MLZswEDbuaqRVrRpYpFenBhgbY4Ew0O 1945 NOsOacEJfU04YVw2HO31XWI74/T/gCgG9b/kyT/KpvI/Mfpfjuh/OU7/J1X9 1946 PZp/OeMp/0Eaf6dJLH2nTgJ6fyPTUv2JVb7H6Uzpy2Gl39HtwjMWHCqWMHWW 1947 x2r/U9GPxH9QNpX/kbSW9uQgANzNawepVCUXkm8BQT+0E9kHSlIm8Arv5+Ai 1948 sdmOXdn0uBCgnJgTAQQCVfhU+Wu4iiqQ2E2ias7yuqp1ci5SxwTomh9h08Q3 1949 PgQq7ajtLkTIiNpoRamgEmcBiIkCO90AkXdwFh6CuSC+LB7eUlByfU0FtimN 1950 96TtaPCf7LnD9f4SxH9kKWz/iVBI8X/y8n+V+4+TAhAhce2wIZgNwr/PhD2O 1951 3/TUbbLT0G0KuqbllnVze71Rr1u262yUdeds3I8rulsm9ES3bGtvnw/szn7Q 1952 idOibe9vX7SWzf3otpg8YY+G27i+zmmWofIUyHnKPZ4iGWQFh3XLpFiWRX27 1953 ZKljzf8BSRAj/l8a/xmt/SdCRVSyMgIClUbXJTYTMK5oE1zlqFRxNikRfZdJ 1954 V38LEYQtPYiUHBVniwRlvcVw2FEtDTUqECD60dQQvYIG/VTWsINI2Qv8YEfR 1955 uzYfEhUxZPedi4Mt32FECjYdTW9ZfufiTD+fUAGwYqpmldX6xEhpHwOP3mzE 1956 wnsa9X+JIrY95vyPnIVh/48a7an8T0z8t1dz5540IqywPD/9Z8F+CfaGuW3v 1957 hzPsbQTxWbbHWGgSHVO0UKsoQZC4N30f1dg8y++IPEQSRIdO7Cu0PUZc+IDA 1958 8HAjwyXK1Lg23vyPBISo/pdT+R9Fu71yeXV9Y+W2J6+xwh+RHwe7Ddt8rMRv 1959 N/LLTheK17ZjNher2tZ2pWq7a01M7GvX2kHf+F2CwNDmZco9AliKXmcbHCDX 1960 vu0AALHDzwmKDCkLQtqWtptCEIIWGmbVtJqmd5JPTHS41WdwnPIvZuWI/MNU 1961 /z+r8p9DOaokDyfzcKDMoziZP3cooV/8BOaE1KJhk52xxv8EJGXD9r+U1n9N 1962 ivwnM/WjW1uFWlASKqiCYGQQUG56ajXPtfivx5pXFOb7a6aBjCpESBRgSE23 1963 Thau8+3a/l1R7x+tgFIcYnnlyn3CdfSCu95SsIikp7/a19i7PUmhDHV6UVw3 1964 dcAu3FmKLFO5UjxpWgqWkhymUCamE1AO+PXWwy9qfvKSGC6x55NmuqKNOKVh 1965 p38G5/+RHMZ/mMZ/Rh7/oS9nFi0zaJ0VQQC7gkgV1QuzsuSQWRnGoZ1nX63O 1966 QopYu4S+0S4sESd4vFYMFuUiuCdPT+l5zudPNjIEKF5IuFqpmhBZJv0CeBQY 1967 FgLZwFAxadiHgW58ouaAJP/0FNeJU81mL8QNBVmgv9POWDBns0KNFHbpm9Gg 1968 ty7NInEWCYtHhJp9QTMtDUjbYfEfjjn+n436/1SSU/wfjf0/K8rUVp4VJd8H 1969 sMm27rg2tjN9vYGZ2XuUvFVMbRPHatilHmN3sTO8fyClB/8aRLCCVa3SUxTm 1970 syYDfXOnaSHR3oFIR2LFZrnBkmlAZNpG1XRYXVhvgv7CwDGAECiz2gPHJEZQ 1971 gyhIFLlgj8QOW+wJHmBDx47gpwRDCcELs9lLEVLol4eFSaPHRB4hChEeefyB 1972 drLZMIzx5v/FaPwvm47/nzD/n7EJPwsAzz70c237ErUie4oC/fk7DhgO3GZJ 1973 pECATFXbrVZU7GjVHdQULdfeAVh1NAoKeFftDAkWkZJj1t8Bjv+gtF+gUKcr 1974 ivRWliI7LsZQ9SO8np/seCHtbLth6+Md/y9G4n+ylOr/Uft/4QDea7ethksK 1975 s+hCCBtm0cqRzA2AREEScnFjwvqNuvfwo19dQJuVPWeRZ3ZDucLjCkFFm6fY 1976 sAOUXJPXcJPYZbjDl0VT6sIHhRqq/OHB3iNvabxbJnyZmjHJK/6GGTxL3cC0 1977 PVnTTaehjdn/E7OR8b9imv8dO/53Mb6Fkl7d1uCcghKTU8h4fDYQFI3WsNtD 1978 4qDSN4mgpHOjDJJ/t0bc8ljtP9hT/5X17b/U/xtJO0UZgNjEcXVzm1+jnGCp 1979 3vA7KSvnlPtn5t7MzOqmSoh6+qEHEsL9htlwGtjIbN5effiKa/FFcspp2OTV 1980 L+qOedqd090vzJds/GD/tbPzCwtn8l/U3bkydgrC2SbRbfXUmTp2vtC0Hqr3 1981 XcvKvKJahO3G6+6rS4PLT9qRHeGg8s3Mqdls9sz9uTdPP2zFq86vXM9/6QXu 1982 xiZ9O8ZdZN9+tRWUOuz9xIa5XKtKTOHhm/4HeHruvv8JnZk9leH9E9UaporN 1983 UPBLo7vfYqUlp08/nDtznxLPFmY++Mqj7z36o0d//sHbj773wTsffOPR9x/9 1984 yYxnMN/3jvpQOD33Jj0ynwkYv205blq2OnvvGn8qQ3vg9BL7+ubDV19ZPJf/ 1985 0vzMl3/ptV95KzCNlgAhykncIXggbKxDVp5K9iimOxTErxCsEpuee/bM3H3a 1986 /fn/eu8vPvy93//wq+9+9NvvTe4YmGfb/tuFkojGGv/LeuP/QvZfOv5v1Pbf 1987 JrX/zi8lqwHUNXe7memX8Z0TEECSJAm0LVHSTMnQqeD3FtbRsxXqZcski2yo 1988 X4kCFe8FHFrHiFzNQg2rql1wnHCcvR2BmBOyEmjX8QXJek/XA5o+8wuyIMdd 1989 Z6CmSMp2DN+jnRPm8Wf1OxLspF3QcMed/wNy2P4T0/k/J8n/SzoL5hMNC8p5 1990 AX/xwNyAz669M0SpjqZX2CzeSO3WgkiieED5m2PVSLJZQvsLe6syWLPsGnaj 1991 xo3oWTfnPMmlPcOdq5dqDY6NMS7MiCKamac/nptvbx7b8zcsc3vYBcAD5D+b 1992 lVEk/p/m/yZI/j0napVjRVwc5hgdZ+Ia4SyNo7a/TWrkCd+4um0x0aByNRM7 1993 pjefpX3aU4wvFHaJvc/Y9yhfu9hokAX2yTsJu8thvwpOmd65f+Jh3FLcy/M5 1994 CXX6btC3O7pbvmFtsQtgHq2P0biGH1B30PAuxwdsdrHD/DlaEA2V3CT+iVBs 1995 s2LZ83iHwisF/xSBM3g8cjT/2tfvPXWDOE7nFo78Q0B7t5UNtcJtQn/cH/3/ 1996 NsvpHVsB5VjlAOgYC5t+z/DXKeVRvngma3mu1fH8UYs07z/X4R2/3sYM3sP+ 1997 wijO5N1TTAyQIhRCvW7abpQC9lJsRSmEEEXceUCYZjlCA5UQzWr0OL0zgjGa 1998 mOPIoXuKuR6YDdPEHEcK0cRdjximiTlOqI+3uDwXoQn18m4cTbifOS56LhA+ 1999 TpRGUCLPK4YoFyWKoZIHP3ohm4BGSkAjJqBBCWhgApoELC2AwTTKYJLcYJIE 2000 nZygjxN0cYIeTtDBSfp3AEnEq2xNnKMWOnGdtqM5KmNvFC//llpwPbBmdgy2 2001 5WOs2WE8C0U5hrvtDrsAcOD8P5H5XyUhrf8bqf8fP5HW0VT5KVARInnDYKF/ 2002 hweFpUDwu5WlHFxvIg1zmR7liAP6SBAVBHMymBAgMJqOqjv18c7/HlP/Iafx 2003 /5G0o1n/b8YXuZlzMTjQnZFvQN1/mxVZ6QEultQljXqY+3HJuCzoMzUng4XI 2004 XvGB/XTpv7b8j7/+H4Xz/xIA6fwf447/L3CGPRgCfNHe0wivUCWWyyH+gaIl 2005 mRUY+TOzR/J9Ui8keNzpTwaqWsTS2dJLXnF/0zb9Tzkk2lVvUFEr+ScgalJm 2006 RZSgVlXoO3URRMpBhoUwesPiYMdi0gyLtD0t+M8A0B2r/yfDiP+X2n8jxf94 2007 +6/vDLBP5BDmcoLYi/EtDtSq5g61/SjGiwgoClbZ0G/cJGgpxgYUcgrK5QbM 2008 9yEMsgOR0p7jdTgoP/Hho1rJGPf8P0CSs2H/L53/YaL8v0NPpsOmUoAoGUxY 2009 bNWGuLARG24UAAqfVbWyyUxAy9bLuKmpFkaWaEvQQrrtdFcIovYVNf86TmJE 2010 MCOeaBZEqaSwwLtkz52vG1g3mVhv0Msmpx3OtLgm3udci2P5UNo1Ta6GzX3O 2011 KrnEdThsE85hq0s4RGVERcKxHTOT4XzWdKeG3VJ5mCAwSP6RJIbkX4Jp/eck 2012 xn8eq64TiRKUDlr+JciDFTbzoLOnakbSqdzTUM+RyD8cn/zLXvy3x/6nX1L5 2013 H0W7sXJnbWXjys2Lk4EAcAAC9LXUQ4b6wUjRf/K/wRlhNlPh4U36OGt+ImI0 2014 NcrUw14AboD8Q1Fg/j+CMn3yCHjzP0mp/h9NW1tZX1++7AeAq42aXrUiq//G 2015 ewAClCkjAy+CKocjqLyakyUR8aKKVQKyKiiqRUEghBf49qYFmxV8xyWEgqPA 2016 gmfJASrYqyqVT93dz3O2VGva5Hpj/+Ltu+f1ebCh32quOHeRvbLlVOcvwzt7 2017 5e2NLeHWJbl8pXF99Rq4e2fr2r3ytV1lrZLbJG/sVNe2iubWDpIvXJzLCWh7 2018 926ldH4T3zO3X6+9UVLu3Li3fvHG5QsPlue0O4aytrJ55c7qPUu4QK6Sonp3 2019 /g1j+xrZwOCmsbsDbFcGr0sVfV0r7qxdrb1+ySVE390sV9fu3N1cLoSBSzMa 2020 mra/1NuHi4GlqqKPYrFnhF3rAJEcG9SKQC2VlAC2IlURcxJWQUlUcpJSXLpX 2021 2xPu1e5J1+8I5bv7YO+GLjlFeKNcXM5kumn3FmMEMNFmC2oRm18xS5aqm9ts 2022 LS8T2/th2Kw1DFdnsDJf0/eIulC02NBne78gY6VUJCUAS4RoWTZy+CJmT3od 2023 u2epx8bdLLlsHVqJA2JeFPNSlru8tjE9xUYC8svb9AQeB+q1OuuPeS+lzr1S 2024 atgOcV6N8d4kxJCa56On7e/VJbjZ6akrxDCsJEcOKhDPG+Qd1yZs9ZBE5wFv 2025 H7/9/Etnvn7l6z+ePv7CiW+/ffwC/em1E8ePCy+BF55/bu6znzrxC+DlLslx 2026 4e3jHCX5RUoCfhnUhZfBS89/avPTz588sbkunASfY19ePMl4Q9cs29Sx8Dnw 2027 U+zHF06+uI5N7ip1UoXPgs+wn6ZOPkc5TXeFV8Fp9v3lk9w6+85tEMflLhDb 2028 1TV2c4Rbbrhl6o+7+ydePP6tYzsn0PGT3cub7lze8ePPHfv0V7/yzv9oP7ny 2029 37f5H3z4G+/8zre+89GP/u/z39bu7hS/+R//dOYP/lGaKv/dx98992dzH/9s 2030 41/+QX3nbuGHl1/5UZH78UfL7u+i6d/6/H/+4T//2gefOf/Tmbfsb/zg3ff/ 2031 +ruZ//2r9//+Jz83v3Di4c33T//rRu3f/vg7+fcWtb/9my//8C+vfe1rP/Pu 2032 9//945/nf/3mh2+RP/3NR8/FPTief1a9A09Yx6v/BQiC479EX/+n6z+NJf9L 2033 NUkdm/sJx39CaZDd3bZ341dbiK0H8cdbd03+jpPQYlUlx5aJXApY0q1dlMT7 2034 wAOclk5Om6Wn2SIE/WOY7S2RCGaS/Lc3EyabZyNZIap40LR42dBjiGTUD+mx 2035 wL5FbPCoJ1RKwzJjbWbJGHL2J0H8p2f+Tw//QTad/20s+J9g/U/IsOjJ4kFe 2036 agcFs8CMD3uG9UPBSyHZkgibqFMODBKUA6MkE/v2XpmEnizRyz/Oqp/MP+lT 2037 KYxGNlTAtKhD4ljmWNf/gzCQ/5G9+g+Uyv9IWnv9b9r/3BOv7d1hJkylmK3s 2038 rbPZ+RUFQjaPd3cl73QV78nR/9YuMZzSeOv/oRSSf1FO9f+I878WrmeKhNTz 2039 8/NdoUd5BAA8mmFAuUilL+qBDp8P/UpfeniwQxHGbPqFv1Wju0oH8pcQ6DMC 2040 oD0GU0lS+SWmcxLuNCy3iMe7/ocsSmH7X07X/5wg+9+b/2fNznBXMxyLxvta 2041 NGr6LybAAQXFLHIpBMcBtVnScwMOGtunhI32pKteSkpeAhJIAAuJCz3hGFa+ 2042 PIocsU22cWPICeBk87/36n8xnf9zJG3I6//mZASFcgUiAeYOWtm2w4Y9MYC2 2043 SFPM6LumL1P43eBkH9+/laF64Ilwnrth3TTJNdNqOhtl3VkvldkUZFYd7zQI 2044 T+UAF1iBZkTKP5GmAe34IlZL7njlH4X9f5DmfyZN/g+S/ljZV5QcQvDAIb8d 2045 7qsiUcKObSBNLe4uCcAvi+hWIxy0oDeSMkKOUiP2Qn0H9IXWED94tSP6yvSu 2046 ePQJLSOlT4CtmzRe+Zey0fhfWv/5tMt/bpDo+4wXEv1wVvcIl/b7//aOZrdt 2047 G3wv0HcgAuwSxClFSrbkzEWLYcPWrcnWrEsPBQrFomz5h3JIyWpy2noesHcZ 2048 1uO2V0jeaPxE2ZVkW05S1E5WsUkdU6Ik09//7/MVpsZ1qH8P2vjdekilULni 2049 07YAXqv/U3NB/ic1/t8R/F/egIVUGdioSaTnh6vN9nlbQYX1n4A2Tgb9eSA4 2050 bdoONSGBVCmIDsQMU5IjDHPiModqQkM88Zypy0dnNOFixFkS+gNXOnGwKJtQ 2051 rD7v128ngWCpUWIDY7VrorjDUEIcHTD9bB1iY+K0LKfZpMQ2rI8wY+qdGvW2 2052 if9Nnf9BSBODopjK/7X9b7P+PwtTdMzENOgy9JK7UzcYuacjdiv0v7h46wXQ 2053 sVsmi+UP1dJrU4WFuKqMLDBXegOfDZK5gYCk2aI2NVstQrEJiQRGPv+zSBgU 2054 uPPQlQyHPiSb9Dk5C/3QhTfEZYkP1xLQlSQS542nfsSEuoXpUExsaqudgld4 2055 C/dxbCXnnLiCp8G7hq1uG06ZiGLB0M53HP0owp5CWblzN30N0ptsPf+7ZS3E 2056 /xBa6/93y/6fGvneLCoBq2snlGNDr1ESqLIYkAbVzDQIwUGeIgPewwdPu102 2057 ibI4fh6eht753LZ3A6eAYVXnhBWKOtyVHkAf7QiQbBxsuf4Xtlo5+b+Jtf+/ 2058 WeP/JkY5//tAfchO/IWJc8h5c6KwEtVD0dPRAJSYpCoeYAaXS/0B9gfOPkP+ 2059 EgruFSYmw65sNcbBmO2BGK1HKU1pLzchgx5XM7lzFQN3e0wdUFfOvfGF26si 2060 KXc/Hz1i8lO3/1pv/8vXf9H4T1q1/2/T/F9JxvyJUo3DcZClNxwhhVjlWY3b 2061 wh1N+kWkf+6+avhH4sR94R0rCMfNvIMvhbMCMudNfa/OLy7OG0Sdpng2Uj9K 2062 8Ec8Hp8yoVZypCME9Fm0Pefl6URBUVdPwVwtivthiE7VV6u+NnjqMIQ3In1Z 2063 wtTt6/L0SPdJ7aSJG/ff/hdBAiJk4sot1n9otkr4b1m1/X87/P929X8/qu4v 2064 ysHgMBj0TXfocfdsMEwY96QrfWD8K/j8tSoCry8DV1p0/NXPahWpWjVy5cDr 2065 +2X7yA/HKKIV64hj45h78ImKj3n4/eHRySGKzIrFSt3BPmV8iVGm0v2BXSfw 2066 fM7YEtEjEoncNv+3cBn/TYpr/N84/gs2DiPWUPvRWy70I1TZj30FxIOqjp28 2067 L2DljYrmv1GoSEpDMBnGosuWERbHJA6289UOUngOg25MTceyIYSY+RBB3BfQ 2068 0FysJSSE2k4+uHh5L5P/T8RwzIeyO/60FGCt/G/SMv43a/zfLP6X7GY6Jq4d 2069 hRE0zdOhcV0N+JvIBsigktfZAJvA/zHZMv5TUsZ/i9T6/x3x/wOWB/KUt5Xs 2070 SlsOsVt0zqX7UQQJQ0mS7C8T+xVilrE6hbVU/e+fT/qMuxHzGuUyjh+Yseng 2071 vIN/kRuvLjhhXCcS8EtoDtZ+Fvb5m+NxEPUff27VImO+9fxfAxtl/59l0Lr+ 2072 20bGTLInGKMOIru7FO0ia3eXoMu/L/9BV79dvVMvl39dvr/88+oPmCtNXb27 2073 +h010OW/V7/Ojl2+r7KJO3YJJw1KTIcUCUUGlNAKaAhMf0gHhImEeb58elyR 2074 SrwyGNEwdLuRFVIL82LtgiQQnrDo8rteStCyMB7HXsgwvlmakGOvzBOCQ3ev 2075 pWA97tFIZMCn243/MFqWUY7/UAJgTf837P+ZBlM27D3p9t1ANDwuugWlKev2 2076 nfbmzgmHR6j98MH65egAIaQILDhTO4qAGTb8o5Q/fOAL6DSC2mjnGXoRSsZP 2077 meih169f7+xk3ledbeoJOPhkISYS/oMrdxAU+Rp49hpPlIb4JU6oItVPHymN 2078 9ejKtPIMxg7cKhdHkrWVRuiROjndDgSsTruN53LojNtRB8tM/JSwaYcs+cbl 2079 vRHzvmWuByFmCHGW+HoOZb10EWjdAY/VzOLBrFW9Xn+ixNeXPJaxO/oFDrfR 2080 wcHenvo9WMu7dMVVdbN0p6UOA5SFr38kZhCQqPt0dLP5WQd4HupO7Y/TNuyz 2081 PUkNho8Q6OAw5CQAdleAiuzr0zsEkIFQJhQ4wXBgIwQ++PkW6yuqP0GeSDfY 2082 aNr7xLL2FXeHa2UX6qhFs0hkiNBTHLC981McKlUDyUgEXIHXDoDXSsBSl1K7 2083 rWG9MwsDUDPpp9TPLMEe4ulTDtCZena8T+mN2fvKGkDmZlj7BVPo529Z/yd4 2084 0f5X6//3yP9XZenr9aVnGjkCnIHcAEx5I5+PSUhGJhVWjLW5r2Dao8So8Oxd 2085 q8cTWBGCsu0A16U/6lGPenzm4z/w/fIfAPAAAA== 2086 -- END MESSAGE ARCHIVE -- 2088 Authors' Addresses 2090 Robert J. Sparks (editor) 2091 Estacado Systems 2093 Email: RjS@estacado.net 2095 Alan Hawrylyshen 2096 Ditech Communications Corp. 2097 602 - 11 Ave SW 2098 Suite 310 2099 Calgary, Alberta T2R 1J8 2100 Canada 2102 Phone: +1 403 561 7313 2103 Email: ahawrylyshen@ditechcom.com 2105 Alan Johnston 2106 Tello Corporation 2107 999 Baker Way, Suite 250 2108 San Mateo, CA 94404 2110 Email: ajohnston@tello.com 2112 Jonathan Rosenberg 2113 Cisco Systems 2114 600 Lanidex Plaza 2115 Parsippany, NJ 07052 2117 Phone: +1 973 952 5000 2118 Email: jdrosen@cisco.com 2119 URI: http://www.jdrosen.net 2121 Henning Schulzrinne 2122 Columbia University 2123 Department of Computer Science 2124 450 Computer Science Building 2125 New York, NY 10027 2126 US 2128 Phone: +1 212 939 7042 2129 Email: hgs@cs.columbia.edu 2130 URI: http://www.cs.columbia.edu 2132 Intellectual Property Statement 2134 The IETF takes no position regarding the validity or scope of any 2135 Intellectual Property Rights or other rights that might be claimed to 2136 pertain to the implementation or use of the technology described in 2137 this document or the extent to which any license under such rights 2138 might or might not be available; nor does it represent that it has 2139 made any independent effort to identify any such rights. Information 2140 on the procedures with respect to rights in RFC documents can be 2141 found in BCP 78 and BCP 79. 2143 Copies of IPR disclosures made to the IETF Secretariat and any 2144 assurances of licenses to be made available, or the result of an 2145 attempt made to obtain a general license or permission for the use of 2146 such proprietary rights by implementers or users of this 2147 specification can be obtained from the IETF on-line IPR repository at 2148 http://www.ietf.org/ipr. 2150 The IETF invites any interested party to bring to its attention any 2151 copyrights, patents or patent applications, or other proprietary 2152 rights that may cover technology that may be required to implement 2153 this standard. Please address the information to the IETF at 2154 ietf-ipr@ietf.org. 2156 Disclaimer of Validity 2158 This document and the information contained herein are provided on an 2159 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2160 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2161 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2162 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2163 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2164 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2166 Copyright Statement 2168 Copyright (C) The Internet Society (2005). This document is subject 2169 to the rights, licenses and restrictions contained in BCP 78, and 2170 except as set forth therein, the authors retain all their rights. 2172 Acknowledgment 2174 Funding for the RFC Editor function is currently provided by the 2175 Internet Society.