Network Working Group R. Sparks, Ed. Request for Comments: 4475 Estacado Systems Category: Informational A. Hawrylyshen Ditech Networks A. Johnston Avaya J. Rosenberg Cisco Systems H. Schulzrinne Columbia University May 2006
Session Initiation Protocol (SIP) Torture Test Messages
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This informational document gives examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" a SIP implementation.
Table of Contents
1. Overview ........................................................3 2. Document Conventions ............................................3 2.1. Representing Long Lines ....................................4 2.2. Representing Non-printable Characters ......................4 2.3. Representing Long Repeating Strings ........................5 3. SIP Test Messages ...............................................5 3.1. Parser Tests (syntax) ......................................5 3.1.1. Valid Messages ......................................5 3.1.1.1. A Short Tortuous INVITE ....................5 3.1.1.2. Wide Range of Valid Characters .............8 3.1.1.3. Valid Use of the % Escaping Mechanism ......9 3.1.1.4. Escaped Nulls in URIs .....................11 3.1.1.5. Use of % When It Is Not an Escape .........11 3.1.1.6. Message with No LWS between Display Name and < ........................12
Sparks, et al. Informational [Page 1]
RFC 4475 SIP Torture Test Messages May 2006
3.1.1.7. Long Values in Header Fields ..............12 3.1.1.8. Extra Trailing Octets in a UDP Datagram ...14 3.1.1.9. Semicolon-Separated Parameters in URI User Part .............................16 3.1.1.10. Varied and Unknown Transport Types .......16 3.1.1.11. Multipart MIME Message ...................17 3.1.1.12. Unusual Reason Phrase ....................18 3.1.1.13. Empty Reason Phrase ......................19 3.1.2. Invalid Messages ...................................20 3.1.2.1. Extraneous Header Field Separators ........20 3.1.2.2. Content Length Larger Than Message ........20 3.1.2.3. Negative Content-Length ...................21 3.1.2.4. Request Scalar Fields with Overlarge Values ..........................22 3.1.2.5. Response Scalar Fields with Overlarge Values ..........................23 3.1.2.6. Unterminated Quoted String in Display Name ..............................24 3.1.2.7. <> Enclosing Request-URI ..................25 3.1.2.8. Malformed SIP Request-URI (embedded LWS) ..26 3.1.2.9. Multiple SP Separating Request-Line Elements .....................27 3.1.2.10. SP Characters at End of Request-Line .....28 3.1.2.11. Escaped Headers in SIP Request-URI .......29 3.1.2.12. Invalid Timezone in Date Header Field ....30 3.1.2.13. Failure to Enclose name-addr URI in <> ...31 3.1.2.14. Spaces within addr-spec ..................31 3.1.2.15. Non-token Characters in Display Name .....32 3.1.2.16. Unknown Protocol Version .................32 3.1.2.17. Start Line and CSeq Method Mismatch ......33 3.1.2.18. Unknown Method with CSeq Method Mismatch .33 3.1.2.19. Overlarge Response Code ..................34 3.2. Transaction Layer Semantics ...............................34 3.2.1. Missing Transaction Identifier .....................34 3.3. Application-Layer Semantics ...............................35 3.3.1. Missing Required Header Fields .....................35 3.3.2. Request-URI with Unknown Scheme ....................36 3.3.3. Request-URI with Known but Atypical Scheme .........36 3.3.4. Unknown URI Schemes in Header Fields ...............37 3.3.5. Proxy-Require and Require ..........................37 3.3.6. Unknown Content-Type ...............................38 3.3.7. Unknown Authorization Scheme .......................38 3.3.8. Multiple Values in Single Value Required Fields ....39 3.3.9. Multiple Content-Length Values .....................40 3.3.10. 200 OK Response with Broadcast Via Header Field Value .......................................40 3.3.11. Max-Forwards of Zero ..............................41 3.3.12. REGISTER with a Contact Header Parameter ..........42
Sparks, et al. Informational [Page 2]
RFC 4475 SIP Torture Test Messages May 2006
3.3.13. REGISTER with a url-parameter .....................42 3.3.14. REGISTER with a URL Escaped Header ................43 3.3.15. Unacceptable Accept Offering ......................44 3.4. Backward Compatibility ....................................44 3.4.1. INVITE with RFC 2543 Syntax ........................44 4. Security Considerations ........................................45 5. Acknowledgements ...............................................46 6. Informative References .........................................46 Appendix A. Bit-Exact Archive of Each Test Message ................47 A.1. Encoded Reference Messages ................................48
This document is informational and is NOT NORMATIVE on any aspect of SIP.
This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as, defined in [RFC3261]. Some messages exercise SIP's use of the Session Description Protocol (SDP), as described in [RFC3264].
These messages were developed and refined at the SIPIt interoperability test events.
The test messages are organized into several sections. Some stress only a SIP parser, and others stress both the parser and the application above it. Some messages are valid, and some are not. Each example clearly calls out what makes any invalid messages incorrect.
This document does not attempt to catalog every way to make an invalid message, nor does it attempt to be comprehensive in exploring unusual, but valid, messages. Instead, it tries to focus on areas that have caused interoperability problems or that have particularly unfavorable characteristics if they are handled improperly. This document is a seed for a test plan, not a test plan in itself.
The messages are presented in the text using a set of markup conventions to avoid ambiguity and meet Internet-Draft layout requirements. To resolve any remaining ambiguity, a bit-accurate version of each message is encapsulated in an appendix.
This document contains many example SIP messages. Although SIP is a text-based protocol, many of these examples cannot be unambiguously rendered without additional markup due to the constraints placed on the formatting of RFCs. This document defines and uses the markup
Sparks, et al. Informational [Page 3]
RFC 4475 SIP Torture Test Messages May 2006
defined in this section to remove that ambiguity. This markup uses the start and end tag conventions of XML but does not define any XML document type.
The appendix contains an encoded binary form of all the messages and the algorithm needed to decode them into files.
Several of these examples contain unfolded lines longer than 72 characters. These are captured between <allOneLine/> tags. The single unfolded line is reconstructed by directly concatenating all lines appearing between the tags (discarding any line feeds or carriage returns). There will be no whitespace at the end of lines. Any whitespace appearing at a fold-point will appear at the beginning of a line.
The following represent the same string of bits:
Header-name: first value, reallylongsecondvalue, third value
<allOneLine> Header-name: first value, reallylongsecondvalue , third value </allOneLine>
<allOneLine> Header-name: first value, reallylong second value, third value </allOneLine>
Note that this is NOT SIP header-line folding, where different strings of bits have equivalent meaning.
Several examples contain binary message bodies or header field values containing non-ascii range UTF-8 encoded characters. These are rendered here as a pair of hexadecimal digits per octet between <hex/> tags. This rendering applies even inside quoted-strings.
Sparks, et al. Informational [Page 4]
RFC 4475 SIP Torture Test Messages May 2006
The following represent the same string of bits:
Header-name: value one Header-name: value<hex>206F6E</hex>e
The following is a Subject header field containing the euro symbol:
Several examples contain very large data values created with repeating bit strings. Those will be rendered here using <repeat count=some_integer>value</repeat>. As with <hex>, this rendering applies even inside quoted strings.
For example, the value "abcabcabc" can be rendered as <repeat count=3>abc</repeat>. A display name of "1000000 bottles of beer" could be rendered as
To: "1<repeat count=6><hex>30</hex></repeat> bottles of beer" <sip:beer.example.com>
A Max-Forwards header field with a value of one google will be rendered here as
This short, relatively human-readable message contains:
o line folding all over.
o escaped characters within quotes.
o an empty subject.
o LWS between colons, semicolons, header field values, and other fields.
o both comma separated and separately listed header field values.
Sparks, et al. Informational [Page 5]
RFC 4475 SIP Torture Test Messages May 2006
o a mix of short and long form for the same header field name.
o unknown Request-URI parameter.
o unknown header fields.
o an unknown header field with a value that would be syntactically invalid if it were defined in terms of generic-param.
o unusual header field ordering.
o unusual header field name character case.
o unknown parameters of a known header field.
o a uri parameter with no value.
o a header parameter with no value.
o integer fields (Max-Forwards and CSeq) with leading zeros.
All elements should treat this as a well-formed request.
The UnknownHeaderWithUnusualValue header field deserves special attention. If this header field were defined in terms of comma- separated values with semicolon-separated parameters (as would many of the existing defined header fields), this would be invalid. However, since the receiving element does not know the definition of the syntax for this field, it must parse it as a header value. Proxies would forward this header field unchanged. Endpoints would ignore the header field.
Sparks, et al. Informational [Page 6]
RFC 4475 SIP Torture Test Messages May 2006
Message Details : wsinv
INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0 TO : sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n from : "J Rosenberg \\\"" <sip:jdrosen@example.com> ; tag = 98asjd8 MaX-fOrWaRdS: 0068 Call-ID: wsinv.ndaksdj@192.0.2.1 Content-Length : 150 cseq: 0009 INVITE Via : SIP / 2.0 /UDP 192.0.2.2;branch=390skdjuw s : NewFangledHeader: newfangled value continued newfangled value UnknownHeaderWithUnusualValue: ;;,,;;,; Content-Type: application/sdp Route: <sip:services.example.com;lr;unknownwith=value;unknown-no-value> v: SIP / 2.0 / TCP spindle.example.com ; branch = z9hG4bK9ikj8 , SIP / 2.0 / UDP 192.168.255.111 ; branch= z9hG4bK30239 m:"Quoted string \"\"" <sip:jdrosen@example.com> ; newparam = newvalue ; secondparam ; q = 0.33
This message exercises a wider range of characters in several key syntactic elements than implementations usually see. In particular, note the following:
o The Method contains non-alpha characters from token. Note that % is not an escape character for this field. A method of IN%56ITE is an unknown method. It is not the same as a method of INVITE.
o The Request-URI contains unusual, but legal, characters.
o A branch parameter contains all non-alphanum characters from token.
o The To header field value's quoted string contains quoted-pair expansions, including a quoted NULL character.
o The name part of name-addr in the From header field value contains multiple tokens (instead of a quoted string) with all non-alphanum characters from the token production rule. That value also has an unknown header parameter whose name contains the non-alphanum token characters and whose value is a non-ascii range UTF-8 encoded string. The tag parameter on this value contains the non-alphanum token characters.
o The Call-ID header field value contains the non-alphanum characters from word. Notice that in this production:
* % is not an escape character. It is only an escape character in productions matching the rule "escaped".
* " does not start a quoted string. None of ',` or " imply that there will be a matching symbol later in the string.
* The characters []{}()<> do not have any grouping semantics. They are not required to appear in balanced pairs.
o There is an unknown header field (matching extension-header) with non-alphanum token characters in its name and a UTF8-NONASCII value.
If this unusual URI has been defined at a proxy, the proxy will forward this request normally. Otherwise, a proxy will generate a 404. Endpoints will generate a 501 listing the methods they understand in an Allow header field.
This INVITE exercises the % HEX HEX escaping mechanism in several places. The request is syntactically valid. Interesting features include the following:
o The request-URI has sips:user@example.com embedded in its userpart. What that might mean to example.net is beyond the scope of this document.
o The From and To URIs have escaped characters in their userparts.
o The Contact URI has escaped characters in the URI parameters. Note that the "name" uri-parameter has a value of "value%41", which is NOT equivalent to "valueA". Per [RFC3986], unescaping URI components is never performed recursively.
Sparks, et al. Informational [Page 9]
RFC 4475 SIP Torture Test Messages May 2006
A parser must accept this as a well-formed message. The application using the message must treat the % HEX HEX expansions as equivalent to the character being encoded. The application must not try to interpret % as an escape character in those places where % HEX HEX ("escaped" in the grammar) is not a valid part of the construction. In [RFC3261], "escaped" only occurs in the expansions of SIP-URI, SIPS-URI, and Reason-Phrase.
This register request contains several URIs with nulls in the userpart. The message is well formed - parsers must accept this message. Implementations must take special care when unescaping the Address-of-Record (AOR) in this request so as to not prematurely shorten the username. This request registers two distinct contact URIs.
In most of the places % can appear in a SIP message, it is not an escape character. This can surprise the unwary implementor. The following well-formed request has these properties:
o The request method is unknown. It is NOT equivalent to REGISTER.
o The display name portion of the To and From header fields is "%Z%45". Note that this is not the same as %ZE.
o This message has two Contact header field values, not three. <sip:alias2@host2.example.com> is a C%6Fntact header field value.
A parser should accept this message as well formed. A proxy would forward or reject the message depending on what the Request-URI meant to it. An endpoint would reject this message with a 501.
3.1.1.6. Message with No LWS between Display Name and <
This OPTIONS request is not valid per the grammar in RFC 3261 since there is no LWS between the token in the display name and < in the From header field value. This has been identified as a specification bug that will be removed when RFC 3261 is revised. Elements should accept this request as well formed.
This message contains a single SIP REGISTER request, which ostensibly arrived over UDP in a single datagram. The packet contains extra octets after the body (which in this case has zero length). The extra octets happen to look like a SIP INVITE request, but (per section 18.3 of [RFC3261]) they are just spurious noise that must be ignored.
A SIP element receiving this datagram would handle the REGISTER request normally and ignore the extra bits that look like an INVITE request. If the element is a proxy choosing to forward the REGISTER, the INVITE octets would not appear in the forwarded request.
3.1.1.9. Semicolon-Separated Parameters in URI User Part
This request has a semicolon-separated parameter contained in the "user" part of the Request-URI (whose value contains an escaped @ symbol). Receiving elements will accept this as a well-formed message. The Request-URI will parse so that the user part is "user;par=u@example.net".
This request contains Via header field values with all known transport types and exercises the transport extension mechanism. Parsers must accept this message as well formed. Elements receiving this message would process it exactly as if the 2nd and subsequent header field values specified UDP (or other transport).
This MESSAGE request contains two body parts. The second part is binary encoded and contains null (0x00) characters. Receivers must take care to frame the received message properly.
Parsers must accept this message as well formed, even if the application above the parser does not support multipart/signed.
Additional examples of multipart/mime messages, in particular S/MIME messages, are available in the security call flow examples document [SIP-SEC].
This well-formed response contains no reason phrase. A parser must accept this message. The space character after the reason code is required. If it were not present, this message could be rejected as invalid (a liberal receiver would accept it anyway).
This section contains several invalid messages reflecting errors seen at interoperability events and exploring important edge conditions that can be induced through malformed messages. This section does not attempt to be a comprehensive list of all types of invalid messages.
The Via header field of this request contains additional semicolons and commas without parameters or values. The Contact header field contains additional semicolons without parameters. This message is syntactically invalid.
An element receiving this request should respond with a 400 Bad Request error.
This is a request message with a Content Length that is larger than the actual length of the body.
When sent over UDP (as this message ostensibly was), the receiving element should respond with a 400 Bad Request error. If this message arrived over a stream-based transport, such as TCP, there's not much
Sparks, et al. Informational [Page 20]
RFC 4475 SIP Torture Test Messages May 2006
the receiving party could do but wait for more data on the stream and close the connection if none is forthcoming within a reasonable period of time.
This request has a negative value for Content-Length.
An element receiving this message should respond with an error. This request appeared over UDP, so the remainder of the datagram can simply be discarded. If a request like this arrives over TCP, the framing error is not recoverable, and the connection should be closed. The same behavior is appropriate for messages that arrive without a numeric value in the Content-Length header field, such as the following:
Content-Length: five
Implementors should take extra precautions if the technique they choose for converting this ascii field into an integral form can return a negative value. In particular, the result must not be used as a counter or array index.
3.1.2.4. Request Scalar Fields with Overlarge Values
This request contains several scalar header field values outside their legal range.
o The CSeq sequence number is >2**32-1.
o The Max-Forwards value is >255.
o The Expires value is >2**32-1.
o The Contact expires parameter value is >2**32-1.
An element receiving this request should respond with a 400 Bad Request due to the CSeq error. If only the Max-Forwards field were in error, the element could choose to process the request as if the field were absent. If only the expiry values were in error, the element could treat them as if they contained the default values for expiration (3600 in this case).
Other scalar request fields that may contain aberrant values include, but are not limited to, the Contact q value, the Timestamp value, and the Via ttl parameter.
3.1.2.5. Response Scalar Fields with Overlarge Values
This response contains several scalar header field values outside their legal range.
o The CSeq sequence number is >2**32-1.
o The Retry-After field is unreasonably large (note that RFC 3261 does not define a legal range for this field).
o The Warning field has a warning-value with more than 3 digits.
An element receiving this response will simply discard it.
Message Details : scalarlg
SIP/2.0 503 Service Unavailable <allOneLine> Via: SIP/2.0/TCP host129.example.com ;branch=z9hG4bKzzxdiwo34sw ;received=192.0.2.129 </allOneLine> To: <sip:user@example.com> From: <sip:other@example.net>;tag=2easdjfejw CSeq: 9292394834772304023312 OPTIONS Call-ID: scalarlg.noase0of0234hn2qofoaf0232aewf2394r Retry-After: 949302838503028349304023988 Warning: 1812 overture "In Progress" Content-Length: 0
Sparks, et al. Informational [Page 23]
RFC 4475 SIP Torture Test Messages May 2006
3.1.2.6. Unterminated Quoted String in Display Name
This is a request with an unterminated quote in the display name of the To field. An element receiving this request should return a 400 Bad Request error.
An element could attempt to infer a terminating quote and accept the message. Such an element needs to take care that it makes a reasonable inference when it encounters
To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>
Message Details : quotbal
INVITE sip:user@example.com SIP/2.0 To: "Mr. J. User <sip:j.user@example.com> From: sip:caller@example.net;tag=93334 Max-Forwards: 10 Call-ID: quotbal.aksdj Contact: <sip:caller@host59.example.net> CSeq: 8 INVITE Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234 Content-Type: application/sdp Content-Length: 152
This INVITE request is invalid because the Request-URI has been enclosed within in "<>".
It is reasonable always to reject a request with this error with a 400 Bad Request. Elements attempting to be liberal with what they accept may choose to ignore the brackets. If the element forwards the request, it must not include the brackets in the messages it sends.
3.1.2.9. Multiple SP Separating Request-Line Elements
This INVITE has illegal multiple SP characters between elements of the start line.
It is acceptable to reject this request as malformed. An element that is liberal in what it accepts may ignore these extra SP characters when processing the request. If the element forwards the request, it must not include these extra SP characters in the messages it sends.
This OPTIONS request contains SP characters between the SIP-Version field and the CRLF terminating the Request-Line.
It is acceptable to reject this request as malformed. An element that is liberal in what it accepts may ignore these extra SP characters when processing the request. If the element forwards the request, it must not include these extra SP characters in the messages it sends.
This INVITE is malformed, as the SIP Request-URI contains escaped headers.
It is acceptable for an element to reject this request with a 400 Bad Request. An element could choose to be liberal in what it accepts and ignore the escaped headers. If the element is a proxy, the escaped headers must not appear in the Request-URI of the forwarded request (and most certainly must not be translated into the actual header of the forwarded request).
This INVITE is invalid, as it contains a non-GMT time zone in the SIP Date header field.
It is acceptable to reject this request as malformed (though an element shouldn't do that unless the contents of the Date header field were actually important to its processing). An element wishing to be liberal in what it accepts could ignore this value altogether if it wasn't going to use the Date header field anyway. Otherwise, it could attempt to interpret this date and adjust it to GMT.
RFC 3261 explicitly defines the only acceptable time zone designation as "GMT". "UT", while synonymous with GMT per [RFC2822], is not valid. "UTC" and "UCT" are also invalid.
Message Details : baddate
INVITE sip:user@example.com SIP/2.0 To: sip:user@example.com From: sip:caller@example.net;tag=2234923 Max-Forwards: 70 Call-ID: baddate.239423mnsadf3j23lj42--sedfnm234 CSeq: 1392934 INVITE Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw Date: Fri, 01 Jan 2010 16:00:00 EST Contact: <sip:caller@host5.example.net> Content-Type: application/sdp Content-Length: 150
This REGISTER request is malformed. The SIP URI contained in the Contact Header field has an escaped header, so the field must be in name-addr form (which implies that the URI must be enclosed in <>).
It is reasonable for an element receiving this request to respond with a 400 Bad Request. An element choosing to be liberal in what it accepts could infer the angle brackets since there is no ambiguity in this example. In general, that won't be possible.
This request is malformed, since the addr-spec in the To header field contains spaces. Parsers receiving this request must not break. It is reasonable to reject this request with a 400 Bad Request response. Elements attempting to be liberal may ignore the spaces.
This OPTIONS request is malformed, since the display names in the To and From header fields contain non-token characters but are unquoted.
It is reasonable always to reject this kind of error with a 400 Bad Request response.
An element may attempt to be liberal in what it receives and infer the missing quotes. If this element were a proxy, it must not propagate the error into the request it forwards. As a consequence, if the fields are covered by a signature, there's not much point in trying to be liberal - the message should simply be rejected.
Message Details : baddn
OPTIONS sip:t.watson@example.org SIP/2.0 Via: SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw Max-Forwards: 70 From: Bell, Alexander <sip:a.g.bell@example.com>;tag=43 To: Watson, Thomas <sip:t.watson@example.org> Call-ID: baddn.31415@c.example.com Accept: application/sdp CSeq: 3923239 OPTIONS l: 0
This request has mismatching values for the method in the start line and the CSeq header field. Any element receiving this request will respond with a 400 Bad Request.
3.1.2.18. Unknown Method with CSeq Method Mismatch
This message has an unknown method in the start line, and a CSeq method tag that does not match.
Any element receiving this response should respond with a 501 Not Implemented. A 400 Bad Request is also acceptable, but choosing a 501 (particularly at proxies) has better future-proof characteristics.
This request indicates support for RFC 3261-style transaction identifiers by providing the z9hG4bK prefix to the branch parameter, but it provides no identifier. A parser must not break when receiving this message. An element receiving this request could reject the request with a 400 Response (preferably statelessly, as other requests from the source are likely also to have a malformed branch parameter), or it could fall back to the RFC 2543-style transaction identifier.
This OPTIONS contains an unknown URI scheme in the Request-URI. A parser must accept this as a well-formed SIP request.
An element receiving this request will reject it with a 416 Unsupported URI Scheme response.
Some early implementations attempt to look at the contents of the To header field to determine how to route this kind of request. That is an error. Despite the fact that the To header field and the Request URI frequently look alike in simplistic first-hop messages, the To header field contains no routing information.
This OPTIONS contains an Request-URI with an IANA-registered scheme that does not commonly appear in Request-URIs of SIP requests. A parser must accept this as a well-formed SIP request.
If an element will never accept this scheme as meaningful in a Request-URI, it is appropriate to treat it as unknown and return a 416 Unsupported URI Scheme response. If the element might accept some URIs with this scheme, then a 404 Not Found is appropriate for those URIs it doesn't accept.
This message contains registered schemes in the To, From, and Contact header fields of a request. The message is syntactically valid. Parsers must not fail when receiving this message.
Proxies should treat this message as they would any other request for this URI. A registrar would reject this request with a 400 Bad Request response, since the To: header field is required to contain a SIP or SIPS URI as an AOR.
This request tests proper implementation of SIP's Proxy-Require and Require extension mechanisms.
Any element receiving this request will respond with a 420 Bad Extension response, containing an Unsupported header field listing these features from either the Require or Proxy-Require header field, depending on the role in which the element is responding.
This INVITE request contains a body of unknown type. It is syntactically valid. A parser must not fail when receiving it.
A proxy receiving this request would process it just as it would any other INVITE. An endpoint receiving this request would reject it with a 415 Unsupported Media Type error.
This REGISTER request contains an Authorization header field with an unknown scheme. The request is well formed. A parser must not fail when receiving it.
A proxy will treat this request as it would any other REGISTER. If it forwards the request, it will include this Authorization header field unmodified in the forwarded messages.
A registrar that does not care about challenge-response authentication will simply ignore the Authorization header field, processing this registration as if the field were not present. A registrar that does care about challenge-response authentication will reject this request with a 401, issuing a new challenge with a scheme it understands.
Endpoints choosing not to act as registrars will simply reject the request. A 405 Method Not Allowed is appropriate.
Multiple conflicting Content-Length header field values appear in this request.
From a framing perspective, this situation is equivalent to an invalid Content-Length value (or no value at all).
An element receiving this message should respond with an error. This request appeared over UDP, so the remainder of the datagram can simply be discarded. If a request like this arrives over TCP, the framing error is not recoverable, and the connection should be closed.
There's no way to know how many octets are supposed to be here.
3.3.10. 200 OK Response with Broadcast Via Header Field Value
This message is a response with a 2nd Via header field value's sent- by containing 255.255.255.255. The message is well formed; parsers must not fail when receiving it.
Per [RFC3261], an endpoint receiving this message should simply discard it.
If a proxy followed normal response processing rules blindly, it would forward this response to the broadcast address. To protect against this as an avenue of attack, proxies should drop such responses.
This is a legal SIP request with the Max-Forwards header field value set to zero.
A proxy should not forward the request and should respond 483 (Too Many Hops). An endpoint should process the request as if the Max- Forwards field value were still positive.
This register request contains a contact where the 'unknownparam' parameter must be interpreted as a contact-param and not a url-param.
This REGISTER should succeed. The response must not include "unknownparam" as a url-parameter for this binding. Likewise, "unknownparam" must not appear as a url-parameter in any binding during subsequent fetches.
Behavior is the same, of course, for any known contact-param parameter names.
This request indicates that the response must contain a body in an unknown type. In particular, since the Accept header field does not contain application/sdp, the response may not contain an SDP body. The recipient of this request could respond with a 406 Not Acceptable, with a Warning/399 indicating that a response cannot be formulated in the formats offered in the Accept header field. It is also appropriate to respond with a 400 Bad Request, since all SIP User-Agents (UAs) supporting INVITE are required to support application/sdp.
This is a legal message per RFC 2543 (and several bis versions) that should be accepted by RFC 3261 elements that want to maintain backwards compatibility.
o There is no branch parameter at all on the Via header field value.
o There is no From tag.
Sparks, et al. Informational [Page 44]
RFC 4475 SIP Torture Test Messages May 2006
o There is no explicit Content-Length. (The body is assumed to be all octets in the datagram after the null-line.)
This document presents NON-NORMATIVE examples of SIP session establishment. The security considerations in [RFC3261] apply.
Parsers must carefully consider edge conditions and malicious input as part of their design. Attacks on many Internet systems use crafted input to cause implementations to behave in undesirable ways. Many of the messages in this document are designed to stress a parser implementation at points traditionally used for such attacks. However, this document does not attempt to be comprehensive. It should be considered a seed to stimulate thinking and planning, not simply a set of tests to be passed.
The final detailed review of this document was performed by Diego Besprosvan, Vijay Gurbani, Shashi Kumar, Derek MacDonald, Gautham Narasimhan, Nils Ohlmeier, Bob Penfield, Reinaldo Penno, Marc Petit-Huguenin, Richard Sugarman, and Venkatesh Venkataramanan.
Earlier versions of this document were reviewed by Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson, Marc Petit-Huguenin, Vidhi Rastogi, Adam Roach, Bodgey Yin Shaohua, and Tom Taylor.
Thanks to Cullen Jennings and Eric Rescorla for their contribution to the multipart/mime sections of this document and their work constructing S/MIME examples in [SIP-SEC]. Thanks to Neil Deason for contributing several messages and to Kundan Singh for performing parser validation of messages in earlier versions.
The following individuals provided significant comments during the early phases of the development of this document: Jean-Francois Mule, Hemant Agrawal, Henry Sinnreich, David Devanatham, Joe Pizzimenti, Matt Cannon, John Hearty, the whole MCI IPOP Design team, Scott Orton, Greg Osterhout, Pat Sollee, Doug Weisenberg, Danny Mistry, Steve McKinnon, and Denise Ingram, Denise Caballero, Tom Redman, Ilya Slain, Pat Sollee, John Truetken, and others from MCI, 3Com, Cisco, Lucent, and Nortel.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[SIP-SEC] Jennings, C. and K. Ono, "Example call flows using SIP security mechanisms", Work in Progress, July 2005.
Sparks, et al. Informational [Page 46]
RFC 4475 SIP Torture Test Messages May 2006
Appendix A. Bit-Exact Archive of Each Test Message
The following text block is an encoded, gzip-compressed TAR archive of files that represent each of the example messages discussed in Section 3.
To recover the compressed archive file intact, the text of this document may be passed as input to the following Perl script (the output should be redirected to a file or piped to "tar -xzvf -").
#!/usr/bin/perl use strict; my $bdata = ""; use MIME::Base64; while(<>) { if (/-- BEGIN MESSAGE ARCHIVE --/ .. /-- END MESSAGE ARCHIVE --/) { if ( m/^\s*[^\s]+\s*$/) { $bdata = $bdata . $_; } } } print decode_base64($bdata);
Figure 58
Alternatively, the base-64 encoded block can be edited by hand to remove document structure lines and fed as input to any base-64 decoding utility.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).