Network Working Group R. Sparks, Ed.
Internet-Draft dynamicsoft
Expires: April 23, 2004 A. Hawrylyshen
Jasomi Networks
A. Johnston
MCI
J. Rosenberg
dynamicsoft
H. Schulzrinne
Columbia University
October 24, 2003
Session Initiation Protocol Torture Test Messages
draft-ietf-sipping-torture-tests-01
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This informational document gives examples of Session Initiation
Protocol (SIP) test messages designed to exercise and "torture" a
parser.
Sparks, et al. Expires April 23, 2004 [Page 1]
Internet-Draft SIP Torture Tests October 2003
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Document Conventions . . . . . . . . . . . . . . . . . . 4
2.1 Representing Long Lines . . . . . . . . . . . . . . . . 4
2.2 Representing Non-printable Characters . . . . . . . . . 5
2.3 Representing Long Repeating Strings . . . . . . . . . . 5
3. SIP Test Messages . . . . . . . . . . . . . . . . . . . 6
3.1 Parser tests (syntax) . . . . . . . . . . . . . . . . . 6
3.1.1 Valid messages . . . . . . . . . . . . . . . . . . . . . 6
3.1.1.1 A short tortuous INVITE . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 10
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
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 . . . . 15
3.1.1.10 Varied and unknown transport types . . . . . . . . . . . 15
3.1.1.11 S/MIME signed message . . . . . . . . . . . . . . . . . 16
3.1.1.12 Unusual reason phrase . . . . . . . . . . . . . . . . . 19
3.1.1.13 Empty reason phrase . . . . . . . . . . . . . . . . . . 20
3.1.2 Invalid messages . . . . . . . . . . . . . . . . . . . . 20
3.1.2.1 Extraneous header field separators . . . . . . . . . . . 20
3.1.2.2 Content length larger than message . . . . . . . . . . . 21
3.1.2.3 Negative Content-Length . . . . . . . . . . . . . . . . 22
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) . . . . . . . . 25
3.1.2.9 Multiple SP separating Request-Line elements . . . . . . 26
3.1.2.10 SP characters at end of Request-Line . . . . . . . . . . 27
3.1.2.11 Escaped headers in SIP Request-URI . . . . . . . . . . . 27
3.1.2.12 Invalid timezone in Date header field . . . . . . . . . 28
3.1.2.13 Failure to enclose name-addr URI in <> . . . . . . . . . 29
3.1.2.14 Spaces within addr-spec . . . . . . . . . . . . . . . . 29
3.1.2.15 Non-token characters in display-name . . . . . . . . . . 30
3.1.2.16 Unknown protocol version . . . . . . . . . . . . . . . . 30
3.1.2.17 Start line and CSeq method mismatch . . . . . . . . . . 31
3.1.2.18 Unknown Method with CSeq method mismatch . . . . . . . . 31
3.1.2.19 Overlarge response code . . . . . . . . . . . . . . . . 32
3.2 Transaction layer semantics . . . . . . . . . . . . . . 32
3.2.1 Missing transaction identifier . . . . . . . . . . . . . 32
3.3 Application layer semantics . . . . . . . . . . . . . . 33
3.3.1 Missing Required Header Fields . . . . . . . . . . . . . 33
3.3.2 Request-URI with unknown scheme . . . . . . . . . . . . 33
Sparks, et al. Expires April 23, 2004 [Page 2]
Internet-Draft SIP Torture Tests October 2003
3.3.3 Request-URI with known but atypical scheme . . . . . . . 34
3.3.4 Unknown URI schemes in header fields . . . . . . . . . . 34
3.3.5 Proxy-Require and Require . . . . . . . . . . . . . . . 35
3.3.6 Unknown Content-Type . . . . . . . . . . . . . . . . . . 35
3.3.7 Unknown authorization scheme . . . . . . . . . . . . . . 36
3.3.8 Multiple values in single value required fields . . . . 37
3.3.9 Multiple Content-Length values . . . . . . . . . . . . . 37
3.3.10 200 OK Response with broadcast Via header field value . 38
3.3.11 Max-Forwards of zero . . . . . . . . . . . . . . . . . . 39
3.3.12 REGISTER with a contact header parameter . . . . . . . . 39
3.3.13 REGISTER with a url parameter . . . . . . . . . . . . . 40
3.3.14 REGISTER with a url escaped header . . . . . . . . . . . 40
3.3.15 Unacceptable Accept offering . . . . . . . . . . . . . . 41
3.4 Backward compatibility . . . . . . . . . . . . . . . . . 42
3.4.1 INVITE with RFC2543 syntax . . . . . . . . . . . . . . . 42
4. Security Considerations . . . . . . . . . . . . . . . . 42
5. Open Issues and Remaining Work . . . . . . . . . . . . . 43
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . 43
Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . 44
A. Bit-exact archive of each test message . . . . . . . . . 45
A.1 Encoded Reference Messages . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . 51
Sparks, et al. Expires April 23, 2004 [Page 3]
Internet-Draft SIP Torture Tests October 2003
1. Overview
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 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 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.
2. Document Conventions
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
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.
2.1 Representing Long Lines
Several of these examples contain unfolded lines longer than 72
characters. These are captured between tags. The single
unfolded line is reconstructed by directly concatenating all lines
appearing between the tags (discarding any line-feeds or carriage
Sparks, et al. Expires April 23, 2004 [Page 4]
Internet-Draft SIP Torture Tests October 2003
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
Header-name: first value,
reallylongsecondvalue
, third value
Header-name: first value,
reallylong
second
value,
third value
Note that this is NOT SIP header line folding where different
strings of bits have equivalent meaning.
2.2 Representing Non-printable Characters
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 tags. This rendering applies even inside quoted-strings.
The following represent the same string of bits:
Header-name: value one
Header-name: value206F6Ee
The following is a Subject header field containing the euro symbol:
Subject: E282AC
2.3 Representing Long Repeating Strings
Several examples contain very large data values created with
repeating bit strings. Those will be rendered here using value. As with this rendering
applies even inside quoted-strings.
For example, the value "abcabcabc" can be rendered as abc. A display name of "1000000 bottles of beer"
could be rendered as
To: "130 bottles of beer"
and a Max-Forwards header field with a value of one google will be
rendered here as
Max-Forwards: 10
3. SIP Test Messages
3.1 Parser tests (syntax)
3.1.1 Valid messages
3.1.1.1 A short tortuous INVITE
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 separate listing of header field values
o mix or short and long form for the same header field name
o unknown header fields
o 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
Sparks, et al. Expires April 23, 2004 [Page 6]
Internet-Draft SIP Torture Tests October 2003
o unknown parameters of a known header field
o uri parameter with no value
o 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 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.
Message Details :
INVITE sip:vivekg@chair-dnrc.example.com;unknownparam SIP/2.0
TO :
sip:vivekg@chair-dnrc.example.com ; tag = 1918181833n
from : "J Rosenberg \\\""
;
tag = 98asjd8
MaX-fOrWaRdS: 0068
Call-ID: 0ha0isndaksdj@192.0.2.1
Content-Length : 151
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:
v: SIP / 2.0 / TCP spindle.example.com ;
branch = z9hG4bK9ikj8 ,
SIP / 2.0 / UDP 192.168.255.111 ; branch=
z9hG4bK30239
m:"Quoted string \"\"" ; newparam =
newvalue ;
Sparks, et al. Expires April 23, 2004 [Page 7]
Internet-Draft SIP Torture Tests October 2003
secondparam ; q = 0.33
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.3
s=-
c=IN IP4 192.0.2.4
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.1.2 Wide range of valid characters
This message exercises a wider range of characters in several key
syntactic elements than implementations usually see. Of particular
note:
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 contain 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
Sparks, et al. Expires April 23, 2004 [Page 8]
Internet-Draft SIP Torture Tests October 2003
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.
Message Details :
!interesting-Method0123456789_*+`.%indeed'~
sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
:&it+has=1,weird!*pas$wo~d_too.(doesn't-it)
@example.com SIP/2.0
Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~
To: "BEL:\07 NUL:\00 DEL:\7F"
From: token1~` token2'+_ token3*%!.-
;fromParam''~+*_!.-%=
"D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9"
;tag=_token~1'+`*%!-.
Call-ID: word%ZK-!.*_+'@word`~)(><:\/"][?}{
CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~
Max-Forwards: 255
extensionHeader-!.%*+_`'~=
EFBBBFE5A4A7E5819CE99BBB
Content-Length: 0
3.1.1.3 Valid use of the % escaping mechanism
This INVITE exercises the % HEX HEX escaping mechanism in several
places. The request is syntactically valid. Interesting features
include:
o The request-URI has sips:user@example.com embedded in its
userpart. What that might mean to example.net is beyond the scope
Sparks, et al. Expires April 23, 2004 [Page 9]
Internet-Draft SIP Torture Tests October 2003
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 [RFC2396], unescaping URI
components is never performed recursively.
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
Message Details :
INVITE sip:sips%3Auser%40example.com@example.net SIP/2.0
To: sip:%75se%72@example.com
From: ;tag=938
Max-Forwards: 87
i: 239409asdfakjkn23onasd0-3234
CSeq: 234234 INVITE
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bKkdjuw
C: application/sdp
Contact:
Content-Length: 151
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.1.4 Escaped nulls in URIs
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
AOR in this request to not prematurely shorten the username. This
request registers two distinct contact URIs.
Sparks, et al. Expires April 23, 2004 [Page 10]
Internet-Draft SIP Torture Tests October 2003
Message Details :
REGISTER sip:example.com SIP/2.0
To: sip:null-%00-null@example.com
From: sip:null-%00-null@example.com;tag=839923423
Max-Forwards: 70
Call-ID: 39203ndfvkjdasfkq3w4otrq0adsfdfnavd
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
Contact:
Contact:
L:0
3.1.1.5 Use of % when it is not an escape
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.
%lt;sip:alias2@host2.example.com%gt; 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.
Message Details :
RE%47IST%45R sip:registrar.example.com SIP/2.0
To: "%Z%45"
From: "%Z%45" ;tag=f232jadfj23
Call-ID: asdfnqwo34rq23i34jrjasdcnl23nrlknsdf
Via: SIP/2.0/TCP host.example.com;branch=z9hG4bK209%fzsnel234
CSeq: 29344 RE%47IST%45R
Max-Forwards: 70
Contact:
C%6Fntact:
Contact:
l: 0
Sparks, et al. Expires April 23, 2004 [Page 11]
Internet-Draft SIP Torture Tests October 2003
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 quoted string 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.
Message Details :
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: "caller";tag=323
Max-Forwards: 70
Call-ID: 1234abcd@funky.example.com
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP funky.example.com;branch=z9hG4bKkdjuw
l: 0
3.1.1.7 Long values in header fields
This well-formed request contains header fields with many values and
values that are very long. Features include:
o The To header field has a long display name, and long uri
parameter names and values
o The From header field has long header parameter names and values,
in particular a very long tag
o The Call-ID is one long token
Message Details :
INVITE sip:user@example.com SIP/2.0
To: "I have a user name of
extreme proportion"
longvalue;
longparamname=shortvalue;
verylongParameterNameWithNoValue>
F: sip:
Sparks, et al. Expires April 23, 2004 [Page 12]
Internet-Draft SIP Torture Tests October 2003
amazinglylongcallername@example.net
;tag=12982424
;unknownheaderparamname=
unknowheaderparamvalue
;unknownValuelessparamname
Call-ID: onereallylongcallid
CSeq: 3882340 INVITE
Unknown-Long-Name:
unknown-long-value;
unknown-long-parameter-name =
unknown-long-parameter-value
Via: SIP/2.0/TCP sip33.example.com
v: SIP/2.0/TCP sip32.example.com
V: SIP/2.0/TCP sip31.example.com
Via: SIP/2.0/TCP sip30.example.com
ViA: SIP/2.0/TCP sip29.example.com
VIa: SIP/2.0/TCP sip28.example.com
VIA: SIP/2.0/TCP sip27.example.com
via: SIP/2.0/TCP sip26.example.com
viA: SIP/2.0/TCP sip25.example.com
vIa: SIP/2.0/TCP sip24.example.com
vIA: SIP/2.0/TCP sip23.example.com
V : SIP/2.0/TCP sip22.example.com
v : SIP/2.0/TCP sip21.example.com
V : SIP/2.0/TCP sip20.example.com
v : SIP/2.0/TCP sip19.example.com
Via : SIP/2.0/TCP sip18.example.com
Via : SIP/2.0/TCP sip17.example.com
Via: SIP/2.0/TCP sip16.example.com
Via: SIP/2.0/TCP sip15.example.com
Via: SIP/2.0/TCP sip14.example.com
Via: SIP/2.0/TCP sip13.example.com
Via: SIP/2.0/TCP sip12.example.com
Via: SIP/2.0/TCP sip11.example.com
Via: SIP/2.0/TCP sip10.example.com
Via: SIP/2.0/TCP sip9.example.com
Via: SIP/2.0/TCP sip8.example.com
Via: SIP/2.0/TCP sip7.example.com
Via: SIP/2.0/TCP sip6.example.com
Via: SIP/2.0/TCP sip5.example.com
Via: SIP/2.0/TCP sip4.example.com
Via: SIP/2.0/TCP sip3.example.com
Via: SIP/2.0/TCP sip2.example.com
Via: SIP/2.0/TCP sip1.example.com
Sparks, et al. Expires April 23, 2004 [Page 13]
Internet-Draft SIP Torture Tests October 2003
Via: SIP/2.0/TCP
host.example.com;received=192.0.2.5;
branch=verylongbranchvalue
Max-Forwards: 70
Contact: amazinglylongcallername
@host5.example.net>
Content-Type: application/sdp
l: 151
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.1.8 Extra trailing octets in a UDP datagram
This message contains a single SIP REGISTER request, which ostensibly
arrived over UDP in a single datagram. The packet contained extra
octets after the body (which in this case has zero length). Those
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.
Message Details :
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=43251j3j324
Max-Forwards: 8
I: 0ha0isndaksdj99sdfafnl3lk233412
Contact: sip:j.user@host.example.com
CSeq: 8 REGISTER
Via: SIP/2.0/UDP 192.0.2.125;branch=z9hG4bKkdjuw23492
Content-Length: 0
Sparks, et al. Expires April 23, 2004 [Page 14]
Internet-Draft SIP Torture Tests October 2003
INVITE sip:joe@example.com SIP/2.0
t: sip:joe@example.com
From: sip:caller@example.net;tag=141334
Max-Forwards: 8
Call-ID: 0ha0isnda977644900765@192.0.2.15
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw380234
Content-Type: application/sdp
Content-Length: 151
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 492170 RTP/AVP 0 12
m =video 3227 RTP/AVP 31
a=rtpmap:31 LPC
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 such that the user part is
"user;par=u@example.net".
Message Details :
OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Call-ID: 0ha0isndaksdj
CSeq: 8 OPTIONS
Accept: application/sdp, application/pkcs7-mime,
multipart/mixed, multipart/signed,
message/sip, message/sipfrag
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bKkdjuw
l: 0
3.1.1.10 Varied and unknown transport types
This request contains Via header field values with all known
Sparks, et al. Expires April 23, 2004 [Page 15]
Internet-Draft SIP Torture Tests October 2003
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).
Message Details :
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: ;tag=323
Max-Forwards: 70
Call-ID: nfc9ehfdfaekijh4akdnaqjkwendsasfdj
Accept: application/sdp
CSeq: 60 OPTIONS
Via: SIP/2.0/UDP t1.example.com;branch=z9hG4bKkdjuw
Via: SIP/2.0/SCTP t2.example.com;branch=z9hG4bKklasjdhf
Via: SIP/2.0/TLS t3.example.com;branch=z9hG4bK2980unddj
Via: SIP/2.0/UNKNOWN t4.example.com;branch=z9hG4bKasd0f3en
Via: SIP/2.0/TCP t5.example.com;branch=z9hG4bK0a9idfnee
l: 0
3.1.1.11 S/MIME signed message
This is a signed INVITE request. The signature is binary encoded. The
body contains null (0x00) characters. Receivers must take care to
properly frame the received message.
Parsers must accept this message as well formed, even if the
application above the parser does not support multipart/signed.
Message Details :
INVITE sip:receiver@example.com SIP/2.0
Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3
To:
From: ;tag=2390234seiu3
Call-ID: afnkjeriuoqeiuavnklafekjq34iu43uawe
CSeq: 282398492 INVITE
Max-Forwards: 70
Contact:
Content-Length: 3134
Content-Type: multipart/signed;
protocol="application/pkcs-7-signature";
micalg=sha1;
boundary="----34CF59C076641DD0879594444157C7EB"
Sparks, et al. Expires April 23, 2004 [Page 16]
Internet-Draft SIP Torture Tests October 2003
------34CF59C076641DD0879594444157C7EB
Content-Type: message/sip
INVITE sip:receiver@example.com SIP/2.0
Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3
To:
From: ;tag=2390234seiu3
Call-ID: afnkjeriuoqeiuavnklafekjq34iu43uawe
CSeq: 282398492 INVITE
Max-Forwards: 70
Contact:
Accept: application/sdp, application/pkcs7-mime,
multipart/mixed, multipart/signed,
message/sip, message/sipfrag
Content-Type: application/sdp
Content-Length: 149
v=0
o=sender 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
------34CF59C076641DD0879594444157C7EB
Content-Type: application/pkcs-7-signature; name="smime.p7s"
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"
3082088806092A86
4886F70D010702A082087930820875020101310B300906052B0E03021A050030
0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
90008902240001300D06092A864886F70D01010505003070310B300906035504
0613025553311330110603550408130A43616C69666F726E69613111300F0603
550407130853616E4A6F7365310E300C060355040A1305736970697431293027
060355040B135369706974546573744365727469666963617465417574686F72
697479301E170D3033313032313134343332355A170D31333130313831343433
32355A3062310B3009060355040613025553311330110603550408130A43616C
69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
040A13057369706974311B30190603550403141273656E646572406578616D70
6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
Sparks, et al. Expires April 23, 2004 [Page 17]
Internet-Draft SIP Torture Tests October 2003
406578616D706C652E6F726730090603551D1304023000301D0603551D0E0416
041440FF1C0C1BB8684CA917839D70E97DF8DD5B60D130819A0603551D230481
9230818F80146B461714EA94762580546E1354DAA1E35414A1B6A174A4723070
310B3009060355040613025553311330110603550408130A43616C69666F726E
69613111300F0603550407130853616E4A6F7365310E300C060355040A130573
6970697431293027060355040B13536970697454657374436572746966696361
7465417574686F72697479820100300D06092A864886F70D0101050500038181
006FFE1A3B5CE807C3DD2CFDF6E9787F491C84DBF7DCD11DB2D6A8887D2FE3F2
2E9C6894994282E50AA0DFFE1CBD4EC2C20217831FC2AD360FF1C0DE1DE1E870
102CFA99EE504C7DC0D8752A63294AC748DDDEFADE55C6D051F1CD54CFE7C153
278962A53CEF61B875C1FD3C74E972242CBA0131B3B8C607BF95B378212CA9A7
5E30820339308202A2A00302010202080090008902240001300D06092A864886
F70D01010505003070310B300906035504061302555331133011060355040813
0A43616C69666F726E69613111300F0603550407130853616E4A6F7365310E30
0C060355040A1305736970697431293027060355040B13536970697454657374
4365727469666963617465417574686F72697479301E170D3033313032313134
343332355A170D3133313031383134343332355A3062310B3009060355040613
025553311330110603550408130A43616C69666F726E69613111300F06035504
07130853616E4A6F7365310E300C060355040A13057369706974311B30190603
550403141273656E646572406578616D706C652E6F726730819F300D06092A86
4886F70D010101050003818D0030818902818100CB8302060F12C8FA2D178692
2CA173DCEB80BF1B1B8AF74A310C6975A556A7630FB6E044D9E994DCD49AFF79
76C462D7A8E74ECBF98723AEBF2796EDDD6263577C6C2B77DC7C300B533DEDB5
FB8EB3827FD6FC9B37B9A0DE829F1B1081D632A8AD9FB00A860928E88F87E0B9
79BA65294AC7D6D2D18A78C86B4FA733874E230203010001A381E93081E6301D
0603551D1104163014811273656E646572406578616D706C652E6F7267300906
03551D1304023000301D0603551D0E0416041440FF1C0C1BB8684CA917839D70
E97DF8DD5B60D130819A0603551D2304819230818F80146B461714EA94762580
546E1354DAA1E35414A1B6A174A4723070310B30090603550406130255533113
30110603550408130A43616C69666F726E69613111300F060355040713085361
6E4A6F7365310E300C060355040A1305736970697431293027060355040B1353
69706974546573744365727469666963617465417574686F7269747982010030
0D06092A864886F70D0101050500038181006FFE1A3B5CE807C3DD2CFDF6E978
7F491C84DBF7DCD11DB2D6A8887D2FE3F22E9C6894994282E50AA0DFFE1CBD4E
C2C20217831FC2AD360FF1C0DE1DE1E870102CFA99EE504C7DC0D8752A63294A
C748DDDEFADE55C6D051F1CD54CFE7C153278962A53CEF61B875C1FD3C74E972
242CBA0131B3B8C607BF95B378212CA9A75E318201D6308201D2020101307C30
70310B3009060355040613025553311330110603550408130A43616C69666F72
6E69613111300F0603550407130853616E4A6F7365310E300C060355040A1305
736970697431293027060355040B135369706974546573744365727469666963
617465417574686F7269747902080090008902240001300906052B0E03021A05
00A081B1301806092A864886F70D010903310B06092A864886F70D010701301C
06092A864886F70D010905310F170D3033313032323135323930325A30230609
2A864886F70D010904311604144A2FD5856B6006413209FA56A0C1D85179DBCB
5F305206092A864886F70D01090F31453043300A06082A864886F70D0307300E
06082A864886F70D030202020080300D06082A864886F70D0302020140300706
052B0E030207300D06082A864886F70D0302020128300D06092A864886F70D01
01010500048180C1C3193CF4A8BE1278B5529ACFA1C51DDEDECF0D3DC4C18FC5
Sparks, et al. Expires April 23, 2004 [Page 18]
Internet-Draft SIP Torture Tests October 2003
9A5B120E6D559F4953A3C3C7C97B4EAD8388F1508F7AD2FC71CC7B9ED2844789
60A3ECF87984E25A15B4AB63F150C30570B6315A2327E381EE11E866DC1405DA
29E74CC20201816F1516DD893332D9A8E26FBAEC237C494F3EFAEF4EBCD2122C
DE7D57DECD------34CF59C076641DD0879594444157C7EB--
3.1.1.12 Unusual reason phrase
This 200 response contains a reason phrase other than "OK". The
reason phrase is intended for human consumption, and may contain any
string produced by
Reason-Phrase = *(reserved / unreserved / escaped
/ UTF8-NONASCII / UTF8-CONT / SP / HTAB)
This particular response contains unreserved and non-ASCII UTF-8
characters.This response is well formed. A parser must accept this
message.
Message Details :
SIP/2.0 200 = 2**3 * 5**2 D0BDD0BE20D181D182
D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
BED0B5
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Call-ID: 0384840201234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 159
Content-Type: application/sdp
Contact:
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198/127
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
Sparks, et al. Expires April 23, 2004 [Page 19]
Internet-Draft SIP Torture Tests October 2003
3.1.1.13 Empty reason phrase
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).
Message Details :
SIP/2.0 10020
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: adsn2309jasndj203insdf99223ndf
CSeq: 35 INVITE
From: ;tag=39ansfi3
To: ;tag=902jndnke3
Content-Length: 0
Contact:
3.1.2 Invalid messages
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.
3.1.2.1 Extraneous header field separators
The Via and header field of this request contains contain 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.
Message Details :
INVITE sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=134161461246
Max-Forwards: 7
Call-ID: 0ha0isndaksdjasdf3234nas
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;;,;,,
Contact: "Joe" ;;;;
Content-Length: 153
Sparks, et al. Expires April 23, 2004 [Page 20]
Internet-Draft SIP Torture Tests October 2003
Content-Type: application/sdp
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.2 Content length larger than message
This is a request message with a Content Length that is larger than
the length of the body.
When sent UDP (as this message ostensibly was), the receiving element
should respond with a 400 Bad Request error. If this message were
received over a stream-based transport such as TCP, there's not much
you can do but wait for more data on the stream and close the
connection if none is forthcoming in a reasonable period of time.
Message Details :
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 80
To: sip:j.user@example.com
From: sip:caller@example.net;tag=93942939o2
Contact:
Call-ID: 0ha0isndaksdjweiafasdk3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bK-39234-23523
Content-Type: application/sdp
Content-Length: 9999
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.155
s=-
c=IN IP4 192.0.2.155
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
Sparks, et al. Expires April 23, 2004 [Page 21]
Internet-Draft SIP Torture Tests October 2003
3.1.2.3 Negative Content-Length
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:
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.
Message Details :
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 254
To: sip:j.user@example.com
From: sip:caller@example.net;tag=32394234
Call-ID: 0ha0isndaksdj2193423r542w35
CSeq: 0 INVITE
Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
Contact:
Content-Type: application/sdp
Content-Length: -999
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.53
s=-
c=IN IP4 192.0.2.53
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
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.
Sparks, et al. Expires April 23, 2004 [Page 22]
Internet-Draft SIP Torture Tests October 2003
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 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.
Message Details :
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
To:
From: ;tag=239232jh3
CSeq: 36893488147419103232 REGISTER
Call-ID: asdnw3qjr23o0pd9vanlq3wnrlnewofjas9ui32
Max-Forwards: 300
Expires: 10
Contact:
;expires=280297596632815
Content-Length: 0
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 :
Sparks, et al. Expires April 23, 2004 [Page 23]
Internet-Draft SIP Torture Tests October 2003
SIP/2.0 503 Service Unavailable
Via: SIP/2.0.TCP host129.example.com;branch=z0hG4bKzzxdiwo34sw
To:
From: ;tag=2easdjfejw
CSeq: 9292394834772304023312 OPTIONS
Call-ID: nvoao34irnoase0of0234hn2qofoaf0232aewf2394r
Retry-After: 949302838503028349304023988
Warning: 1812 overture "In Progress"
Content-Length: 0
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 an 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
Message Details :
INVITE sip:user@example.com SIP/2.0
To: "Mr. J. User
From: sip:caller@example.net;tag=93334
Max-Forwards: 10
Call-ID: 0ha0isndaksdj
Contact:
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
Content-Type: application/sdp
Content-Length: 153
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.15
s=-
c=IN IP4 192.0.2.15
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
Sparks, et al. Expires April 23, 2004 [Page 24]
Internet-Draft SIP Torture Tests October 2003
3.1.2.7 <> enclosing Request-URI
This INVITE request is invalid because the Request-URI has been
enclosed within in "<>".
It is reasonable to always 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.
Message Details :
INVITE SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=39291
Max-Forwards: 23
Call-ID: 1@192.0.2.5
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.0.2.5
Contact:
Content-Type: application/sdp
Content-Length: 160
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=3149328700 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.8 Malformed SIP Request-URI (embedded LWS)
This INVITE has illegal LWS within the Request-URI.
An element receiving this request should respond with a 400 Bad
Request.
An element could attempt to ignore the embedded LWS for those schemes
(like sip) where that would not introduce ambiguity.
Message Details :
INVITE sip:user@example.com; lr SIP/2.0
To: sip:user@example.com;tag=3xfe-9921883-z9f
From: sip:caller@example.net;tag=231413434
Sparks, et al. Expires April 23, 2004 [Page 25]
Internet-Draft SIP Torture Tests October 2003
Max-Forwards: 5
Call-ID: asdfasdoijweoi2323-asdfwern23-asd8ia0swn34rk423
CSeq: 2130706432 INVITE
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKkdjuw2395
Contact:
Content-Type: application/sdp
Content-Length: 160
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=3149328700 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
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
while processing the request. If the element forwards the request, it
must not include these extra SP characters in the messages it sends.
Message Details :
INVITE sip:user@example.com SIP/2.0
Max-Forwards: 8
To: sip:user@example.com
From: sip:caller@example.net;tag=8814
Call-ID: 2304u0qwsdfknq234oi243099adsdfnawe3@example.com
CSeq: 1893884 INVITE
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw3923
Contact:
Content-Type: application/sdp
Content-Length: 151
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
Sparks, et al. Expires April 23, 2004 [Page 26]
Internet-Draft SIP Torture Tests October 2003
a=rtpmap:31 LPC
3.1.2.10 SP characters at end of Request-Line
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
while processing the request. If the element forwards the request, it
must not include these extra SP characters in the messages it sends.
Message Details :
OPTIONS sip:remote-target@example.com SIP/2.02020
Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093
To:
From: ;tag=329429089
Call-ID: afewroicu34958239neffasdhr2345r
Accept: application/sdp
CSeq: 238923 OPTIONS
Max-Forwards: 70
Content-Length: 0
3.1.2.11 Escaped headers in SIP Request-URI
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 forwarded request (and
most certainly must not be translated into the actual header of the
forwarded request).
Message Details :
INVITE sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=341518
Max-Forwards: 7
Contact:
Call-ID: 23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
CSeq: 149209342 INVITE
Sparks, et al. Expires April 23, 2004 [Page 27]
Internet-Draft SIP Torture Tests October 2003
Via: SIP/2.0/UDP host-of-the-hour.example.com;branch=z9hG4bKkdjuw
Content-Type: application/sdp
Content-Length: 151
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.12 Invalid timezone in Date header field
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 anyhow. Otherwise, it
could attempt to interpret this date and adjust it to GMT.
RFC 3261 explicitly defines the only acceptable timezone designation
as "GMT". "UT", while synonymous with GMT per [RFC2822], is not
valid. "UTC" and "UCT" are also invalid.
Message Details :
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: 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:
Content-Type: application/sdp
Content-Length: 151
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
Sparks, et al. Expires April 23, 2004 [Page 28]
Internet-Draft SIP Torture Tests October 2003
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.1.2.13 Failure to enclose name-addr URI in <>
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 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.
Message Details :
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
From: sip:user@example.com;tag=998332
Max-Forwards: 70
Call-ID: k345asrl3fdbv@10.0.0.1
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
Contact: sip:user@example.com?Route=%3Csip:sip.example.com%3E
l: 0
3.1.2.14 Spaces within addr-spec
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.
Message Details :
OPTIONS sip:user@example.org SIP/2.0
Via: SIP/2.0/UDP host4.example.com:5060;branch=z9hG4bKkdju43234
Max-Forwards: 70
From: "Bell, Alexander" ;tag=433423
To: "Watson, Thomas" < sip:t.watson@example.org >
Call-ID: sdf0234n2nds0a099u23h3hnnw009cdkne3
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
Sparks, et al. Expires April 23, 2004 [Page 29]
Internet-Draft SIP Torture Tests October 2003
3.1.2.15 Non-token characters in display-name
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 to always 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 be simply rejected.
Message Details :
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 ;tag=43
To: Watson, Thomas
Call-ID: 31415@c.example.com
Accept: application/sdp
CSeq: 3923239 OPTIONS
l: 0
3.1.2.16 Unknown protocol version
To an element implementing [RFC3261], this request is malformed due
to its high version number.
The element should respond to the request with a 505 Version Not
Supported error.
Message Details :
OPTIONS sip:t.watson@example.org SIP/7.0
Via: SIP/7.0/UDP c.example.com;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: A. Bell ;tag=qweoiqpe
To: T. Watson
Call-ID: 31417@c.example.com
CSeq: 1 OPTIONS
l: 0
Sparks, et al. Expires April 23, 2004 [Page 30]
Internet-Draft SIP Torture Tests October 2003
3.1.2.17 Start line and CSeq method mismatch
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.
Message Details :
OPTIONS sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: 0ha0isndaksdj0234sxdfl3
CSeq: 8 INVITE
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKkdjuw
l: 0
3.1.2.18 Unknown Method with CSeq method mismatch
This message has an unknown method, and a CSeq method tag which does
not match it.
Any element receiving this response will 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.
Message Details :
NEWMETHOD sip:user@example.com SIP/2.0
To: sip:j.user@example.com
From: sip:caller@example.net;tag=34525
Max-Forwards: 6
Call-ID: 0ha0isndaksdj0234sxdfl3
CSeq: 8 INVITE
Contact:
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bKkdjuw
Content-Type: application/sdp
l: 139
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.1
c=IN IP4 192.0.2.1
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
Sparks, et al. Expires April 23, 2004 [Page 31]
Internet-Draft SIP Torture Tests October 2003
3.1.2.19 Overlarge response code
This response has a response code larger than 699. An element
receiving this response should simply drop it.
Message Details :
SIP/2.0 4294967301 better not break the receiver
Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
Call-ID: asdof3uj203asdnf3429uasdhfas3ehjasdfas9i
CSeq: 353494 INVITE
From: ;tag=39ansfi3
To: ;tag=902jndnke3
Content-Length: 0
Contact:
3.2 Transaction layer semantics
This section contains tests that exercise an implementation's parser
and transaction layer logic.
3.2.1 Missing transaction identifier
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 to also have a malformed branch
parameter), or it could fall back to the RFC 2543 style transaction
identifier.
Message Details :
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.org;tag=33242
Max-Forwards: 3
Via: SIP/2.0/UDP 192.0.2.1;branch=z9hG4bK
Accept: application/sdp
Call-ID: sadonfo23i420jv0as0derf3j3n
CSeq: 8 OPTIONS
l: 0
Sparks, et al. Expires April 23, 2004 [Page 32]
Internet-Draft SIP Torture Tests October 2003
3.3 Application layer semantics
This section contains tests that exercise an implementation's parser
and application layer logic.
3.3.1 Missing Required Header Fields
This request contains no Call-ID, From, or To header fields.
An element receiving this message must not break because of the
missing information. Ideally, it will respond with a 400 Bad Request
error.
Message Details :
INVITE sip:user@example.com SIP/2.0
CSeq: 193942 INVITE
Via: SIP/2.0/UDP 192.0.2.95;branch=z9hG4bKkdjuw
Content-Type: application/sdp
l: 153
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.95
s=-
c=IN IP4 192.0.2.95
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.3.2 Request-URI with unknown scheme
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.
Message Details :
OPTIONS nobodyKnowsThisScheme:totallyopaquecontent SIP/2.0
Sparks, et al. Expires April 23, 2004 [Page 33]
Internet-Draft SIP Torture Tests October 2003
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: 2340923nasdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0
3.3.3 Request-URI with known but atypical scheme
This OPTIONS contains an Request-URI with an IANA registered scheme
that does not commonly appear 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.
Message Details :
OPTIONS soap.beep://192.0.2.103:3002 SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=384
Max-Forwards: 3
Call-ID: 2340923nasdfasser0q239nwsdfasdkl34
CSeq: 3923423 OPTIONS
Via: SIP/2.0/TCP host9.example.com;branch=z9hG4bKkdjuw39234
Content-Length: 0
3.3.4 Unknown URI schemes in header fields
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.
Message Details :
REGISTER sip:example.com SIP/2.0
Sparks, et al. Expires April 23, 2004 [Page 34]
Internet-Draft SIP Torture Tests October 2003
To: isbn:2983792873
From: ;tag=3234233
Call-ID: 0ha0isndaksdj@hyphenated-host.example.com
CSeq: 234902 REGISTER
Max-Forward: 70
Via: SIP/2.0/UDP 192.0.2.21:5060;branch=z9hG4bKkdjuw
Contact:
l: 0
3.3.5 Proxy-Require and Require
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.
Message Details :
OPTIONS sip:user@example.com SIP/2.0
To: sip:j_user@example.com
From: sip:caller@example.net;tag=242etr
Max-Forward: 6
Call-ID: 0ha0isndaksdj
Require: nothingSupportsThis, nothingSupportsThisEither
Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis
CSeq: 8 OPTIONS
Via: SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw
Content-Length: 0
3.3.6 Unknown Content-Type
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 like any other
INVITE. An endpoint receiving this request would reject it with a 415
Unsupported Media Type error.
Message Details :
INVITE sip:user@example.com SIP/2.0
Contact:
Sparks, et al. Expires April 23, 2004 [Page 35]
Internet-Draft SIP Torture Tests October 2003
To: sip:j.user@example.com
From: sip:caller@example.net;tag=8392034
Max-Forwards: 70
Call-ID: 0ha0isndaksdjadsfij34n23d
CSeq: 235448 INVITE
Via: SIP/2.0/UDP somehost.example.com;branch=z9hG4bKkdjuw
Content-Type: application/unknownformat
Content-Length: 40
3.3.7 Unknown authorization scheme
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 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.
Message Details :
REGISTER sip:example.com SIP/2.0
To: sip:j.user@example.com
From: sip:j.user@example.com;tag=87321hj23128
Max-Forwards: 8
Call-ID: 0ha0isndaksdj
CSeq: 9338 REGISTER
Via: SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
Authorization: NoOneKnowsThisScheme opaque data here
Content-Length:0
Sparks, et al. Expires April 23, 2004 [Page 36]
Internet-Draft SIP Torture Tests October 2003
3.3.8 Multiple values in single value required fields
The message contains a request with multiple Call-ID, To, From,
Max-Forwards and CSeq values. An element receiving this request must
not break.
An element receiving this request would respond with a 400 Bad
Request error.
Message Details :
INVITE sip:user@company.com SIP/2.0
Contact:
Via: SIP/2.0/UDP 192.0.2.25;branch=z9hG4bKkdjuw
Max-Forwards: 70
CSeq: 5 INVITE
Call-ID: 98asdh@192.0.2.1
CSeq: 59 INVITE
Call-ID: 98asdh@192.0.2.2
From: sip:caller@example.com;tag=3413415
To: sip:user@example.com
To: sip:other@example.net
From: sip:caller@example.net;tag=2923420123
Content-Type: application/sdp
l: 155
Contact:
Max-Forwards: 5
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.25
s=-
c=IN IP4 192.0.2.25
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.3.9 Multiple Content-Length values
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
Sparks, et al. Expires April 23, 2004 [Page 37]
Internet-Draft SIP Torture Tests October 2003
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.
Message Details :
OPTIONS sip:user@example.com SIP/2.0
Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423
To: sip:user@example.com
From: sip:other@example.net;tag=3923942
Call-ID: 234asdfhn2323orihawfdoa3o4r52o3irsdf
CSeq: 15932 OPTIONS
Content-Length: 13
Max-Forwards: 60
Content-Length: 5
Content-Type: text/plain
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 being used as an avenue of attack, proxies should drop
such responses.
Message Details :
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
Via: SIP/2.0/UDP 255.255.255.255;branch=z9hG4bK1saber23
Call-ID: 0384840201234ksdfak3j2erwedfsASdf
CSeq: 35 INVITE
From: sip:user@example.com;tag=11141343
To: sip:user@example.edu;tag=2229
Content-Length: 159
Content-Type: application/sdp
Contact:
Sparks, et al. Expires April 23, 2004 [Page 38]
Internet-Draft SIP Torture Tests October 2003
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.198
s=-
c=IN IP4 192.0.2.198/127
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
3.3.11 Max-Forwards of zero
This is a legal SIP request with the Max-Forwards header field value
set to zero.
A proxy should not forward the request and respond 483 (Too Many
Hops). An endpoint should process the request as if the Max-Forwards
field value were still positive.
Message Details :
OPTIONS sip:user@example.com SIP/2.0
To: sip:user@example.com
From: sip:caller@example.net;tag=3ghsd41
Call-ID: 2304sadjfasdlfnm2o2l43r5u0asdfas
CSeq: 39234321 OPTIONS
Via: SIP/2.0/UDP host1.example.com;branch=z9hG4bKkdjuw2349i
Max-Forwards: 0
Content-Length: 0
3.3.12 REGISTER with a contact header parameter
This register request contains a contact where the 'unknownparam'
parameter must be interpreted as being 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 part of the binding during
subsequent fetches.
Behavior is the same, of course, for any known contact-param
parameter names.
Message Details :
Sparks, et al. Expires April 23, 2004 [Page 39]
Internet-Draft SIP Torture Tests October 2003
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe
To: sip:watson@example.com
Call-ID: 70710@saturn.example.com
CSeq: 2 REGISTER
Contact: sip:+19725552222@gw1.example.net;unknownparam
l: 0
3.3.13 REGISTER with a url parameter
This register request contains a contact where the URI has an unknown
parameter.
The register should succeed and a subsequent retrieval of the
registration must include "unknownparam" as a url-parameter.
Behavior is the same, of course, for any known url-parameter names.
Message Details :
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP saturn.example.com:5060;branch=z9hG4bKkdjuw
Max-Forwards: 70
From: sip:watson@example.com;tag=838293
To: sip:watson@example.com
Call-ID: 70710@saturn.example.com
CSeq: 3 REGISTER
Contact:
l: 0
3.3.14 REGISTER with a url escaped header
This register request contains a contact where the URI has an escaped
header.
The register should succeed and a subsequent retrieval of the
registration must include the escaped Route header in the contact URI
for this binding.
Message Details :
REGISTER sip:example.com SIP/2.0
Sparks, et al. Expires April 23, 2004 [Page 40]
Internet-Draft SIP Torture Tests October 2003
To: sip:user@example.com
From: sip:user@example.com;tag=8
Max-Forwards: 70
Call-ID: k345asrl3fdbv@192.0.2.1
CSeq: 14398234 REGISTER
Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
M:
L:0
3.3.15 Unacceptable Accept offering
This request indicates 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 UAs
supporting INVITE are required to support application/sdp.
Message Details :
INVITE sip:user@example.com SIP/2.0
To: sip:j_user@example.com
Contact:
From: sip:caller@example.net;tag=234
Max-Forwards: 5
Call-ID: 0ha0isndaksdj9342dasdd
Accept: text/nobodyKnowsThis
CSeq: 8 INVITE
Via: SIP/2.0/UDP 192.0.2.15;branch=z9hG4bKkdjuw
Content-Length: 151
Content-Type: application/sdp
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 492170 RTP/AVP 0 12
m=video 3227 RTP/AVP 31
a=rtpmap:31 LPC
Sparks, et al. Expires April 23, 2004 [Page 41]
Internet-Draft SIP Torture Tests October 2003
3.4 Backward compatibility
3.4.1 INVITE with RFC2543 syntax
This is a legal message per RFC 2543 (and several bis versions) which
should be accepted by RFC 3261 elements which 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
o There is no explicit Content-Length (The body is assumed to be all
octets in the datagram after the null-line)
o There is no Max-Forwards header field
Message Details :
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP iftgw.example.com
From:
Record-Route:
To: sip:+16505552222@ss1.example.net;user=phone
Call-ID: 1717@ift.client.example.com
CSeq: 56 INVITE
Content-Type: application/sdp
v=0
o=mhandley 29739 7272939 IN IP4 192.0.2.5
s=-
c=IN IP4 192.0.2.5
t=0 0
m=audio 492170 RTP/AVP 0
4. Security Considerations
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 draft are designed to stress a parser
implementation at points traditionally used for such attacks. This
document does not, however, attempt to be comprehensive. It should be
Sparks, et al. Expires April 23, 2004 [Page 42]
Internet-Draft SIP Torture Tests October 2003
considered a seed to stimulate thinking and planning, not simply a
set of tests to be passed.
5. Open Issues and Remaining Work
1. All of the messages in this document should be considered new.
They are either new additions or major revisions of the previous
versions. They all need to be carefully reviewed by the working
group
2. Are the header field values in Section 3.1.1.7 long enough?
Should we push each field over 256 octets or even longer? Where
is the threshold of reason?
3. Is this really possible to recover from embedded whitespace in a
SIP Request-URI as suggested in Section 3.1.2.8?
4. Can we modify the example in Section 3.1.2.15 such that it is not
obvious where to infer quotes?
5. Can we modify the example in Section 3.1.2.13 such that it is not
obvious (due to ambiguity perhaps) where to infer angle brackets?
6. Is the message at Section 3.3.11 sufficiently tortuous to include
in this document?
6. Acknowledgments
The authors wish to thank the following individuals for their
participation in the review of earlier versions of this document:
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 Neil Deason for contributing several messages and 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 WorldCom 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
WorldCom, 3Com, Cisco, Lucent and Nortel.
Sparks, et al. Expires April 23, 2004 [Page 43]
Internet-Draft SIP Torture Tests October 2003
Informative References
[RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[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.
Authors' Addresses
Robert J. Sparks (editor)
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
EMail: rsparks@dynamicsoft.com
Alan Hawrylyshen
Jasomi Networks
2033 Gateway Place
Suite 500
San Jose, CA 95110
EMail: alan@jasomi.com
Alan Johnston
MCI
100 South 4th Street
St. Louis, MO 63102
EMail: alan.johnston@mci.com
Sparks, et al. Expires April 23, 2004 [Page 44]
Internet-Draft SIP Torture Tests October 2003
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07052
Phone: +1 973 952 5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Henning Schulzrinne
Columbia University
Department of Computer Science
1214 Amsterdam Ave.
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
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.
Sparks, et al. Expires April 23, 2004 [Page 45]
Internet-Draft SIP Torture Tests October 2003
A.1 Encoded Reference Messages
-- BEGIN MESSAGE ARCHIVE --
H4sIAANxmD8CA+xdW4/bSHbumQF2Jx00MMD+AbqxWs/YTXWxqnhTt3raY/fs
9PgyDbvtATYb2NViUaJEkWqSktwO4iTzsNm8BLPIY/IwCBIEecoGecgGCySA
/MdSRd0okpLY7dbFHpat1oWHlyLr++qcU6dOnRGD+C1aKRok2FhQARIAioI3
ACtq7J0XWVI3gKpiBahAgpDJI0WSNwSwsYTS9gPiCcKGV/dbxGv40+TmbX9H
yzcnp8ffPHoi+Far1Papd0hfkmbLpkXXqwpPjk92YRFsbT6zSGn4bffpvROh
5voBLg5lK26zJAMF7J15xKnUyq/02i/x2f2GUW9jBBHe2nxIXopful6XeIZf
ElR2yC89tpOw/QW17R3hjs0O5RjU2xb2+ZWQYrV4xrYcRs5wsBeQahkjhCHa
2jx12c7fksB3nR3htOY2ic/2DasRFLvh7xNVOdjavEtsWzy+VxJ8wwTsqhzo
GD4gQNfbENVQzXG6AOgVo+FQdoI7lQptBSWBtFq2VSGB5Tq7vtFih3lCz0sC
0iGrmS4M7t/Wpl0SWK3eued/Roz+Q1sgAczDP1JxHP+qAnL8rxT/DHFj/HO0
pUkMYcy3VRi8JvkjBCxCEMM4AaAUSpF09qkIi1KMRWZBcYRoYriO6UJkYQjq
HUB8wMjERHXkDAGrxaH6DoJ1MfhnwKeL7P7n4V8CrLOP4R8jKcf/Msrxo2fH
p0fXD3+HBiH8Ietodd5hJzWAEXpZP8r69KbDUMwgC5Fdx1AUfWqYTjPUHvoI
llifqyMs9C95ilIS1UlS1JHu1uY91txLwpeetSMASfiaOAJkTVCQlBIA7L9w
9OSUndF1AlJhnLMfqRs/vlyM1PCgL0idQDy9aNE0hhpsfkCdalBjdZAlzjyd
Mqu/W27WmNJj0wsB6irTJVSosgrqrILC8QkeEaK8temXxa3NSjm5ISgDzmXN
MmkbliuwWy2pQHh8erJ759mJwGoF+caOZVBXQBCqo02IXQcpe0GrSVolJAkP
Tu7mhPgj5X9noeyfwf4DCf6XYK7/LV3/SzWcJm1AXqKUW8liA3bj7B+WsRHI
SswMnG8F9julsExagf1d06oSNQGRhCX5cOLq55p8rLwvVt8E/i2nA6RV+n9U
Bva4/iejHP9rp//Vi1fQANnDlBQJKxLESkINjEAS1AiwfMcgDd+oE5+pgtxH
Q/yxATdV8RuZjvLe3s7ezk5Ef9v+2qUDp1LdpRN0sMdKmoaG5mp1l1TgpKka
nLRyFY7hv0M9f5X2H+DGXhz/Ks7xvzb9v5ro/9W0/j9r1z/R898php3/vB7/
vEtd67xFI/3+aXHQ9Wfv8tV4lz/q2aX3qE+/FP4rhBnNK9X/2VYUwT8K9X+k
5vhfRhl0owIEQPjm/qy+Vddi+JYQ7Lt2EvtAWS5GXvH9fHJGPb7juO9HGtYw
gPzxY9b/m6SB6pB6XWqY/p0nhjkadpFHWsBY8YgrJX21Q2J4R0NDISFGjfbA
PwX1NCVAz+TaGbuIwoNzBxHUogxzcHllQdemagu6titBNff65OX6+J++DBZr
/WXw/yhJ/s/H/5av/2UwAJ9fZQgAQxp4E4pgSVCmWX5bm4/pedvyGOU6blCz
nOqTdqvleoF/WrP8nbQfj6ygRtkJTjz35YUY2Z3/YFF/IDvc37vn3nEukttS
RgonerbTB08E07UNkdG4yFpN2I3M037jPcu6aZZnVrXiGisd/wMywHH8Y5zb
f0vV/zDUsa6oCEjCGQ0C6nGgCWceJQ2BoUvwaIVaHY6y6RoiiGt6EOkag7VL
I2AnvuGaqF2HALGPjonYmdvsU80kPqK10PNDfN0aa3wI6zim9e2n0VXfUEQ6
cXzTGuh9+2mKX19QB7DuGE6DolSUTlHvWCUT+t27/PwrjLG9FY//qLKc7P9z
+299/L+TLhztbT3COh/vZ39cOG2gve1UvYv4SHuqutClFmF8YTRQBj/x5AB+
ss8W+fgOFiGSIbr00L7OyhVcwzN8w8twDldYoybN1Y7/YBUk+n9ZyfG/jPL4
6JfHT06PHod4TQV/AkU+Cdqec6WB37Hnl58u5q8dem7uNcxn1XrDCx52CfXu
3x86fdN3iRCDClQJHCYvb8gMUBjWNsI7/Ki3JV2FsixDVg6rXSnKPHttp+G4
XSfEyfsXOzjAP1wp/hnY4/hX8vHfHyv+NaSxrvKaMI/SML9/KdAfvM8Rw8aZ
7dHzlfr/eIBAHP8I5vG/a4L/bKp+cusgUAvKUh3VEUxMAtK2No9jyryuc+Pf
dGxkNyBizQLGOurBWeKBvmPVfwz26W4KKKdRVRinnOoJ4P8iZlI0jGTiRg2v
cXJ7lggZzBp82v1Jmjy6yoCDdY4f+TAaRXKZGJmU2iMN9COtFx/OfA3RMEJm
iycf3ZpTqF9Z9PDP/PF/BGP8D/P5X8v3/7CXX0B3OMMWMIhQWJSwkv1CQZV9
WlBhGumFitZxATL+6lD2xm5hhfrR4w18sUhL0J+6tWn154YAPXQKN+oNByLX
YV+AiCITQyCfEoqzun0466YP1cwY5N/aFEYeqoJyN20yyB77nd2GPaegSE1a
7rA3u80qLRcQLiDp4JrYcyp55mEBebka/8MV+/8VRUrwv5rz/5L0/wJWmcpc
Sparks, et al. Expires April 23, 2004 [Page 46]
Internet-Draft SIP Torture Tests October 2003
wHLfBvBo1fIDj3jFqdbAduFXTHwQVe1R3217lQmd92A0vX+uZEj/JkSwTgyz
PhEUxknfOe+6CHvnEFkI1z0+OlhxbIgcz244Po8Lmxyivzt3FiAEesF85TvU
jvYgOsJYiN6L1AmLE/4DYlvEl/qDgrEhwbsF5cuEKOyHh8VFk8dEoSCKCS7I
BcHw77Rte7Xj/0iN2/8yzP1/a2b/82YiFgAQ+YdpFu5UoYFnT9dhP3/HjOnA
SIcAOYbZadQN4puNc9TFbuCdA2L4JqME0jFGU4Ix0jWu+82w++cN+kUCdcZA
ZFU4TOx4kCI1TfBB6d1wGDL8e23PWu38/zT85+N/y7b/4g68zx+77YCWC+hu
jBsK6OhacgMgzCwgLW1O2LTZ9yF/TIsLCE1FkWsNtbpI6hSdeSLjhnOga13R
JF3q1eC5WMOOPKYPRjWs64ezbUfRNcWgRsUaU1+yR/wt0oWWG4F5uZ5iOX7b
XLH9hyfivzDnfwhgzv8r5v8xxw/YMozbmj/CoMtXIkZ7MPf2klyoTx1O0PP8
KFnwHzRpUFup/gcn5v+G+OcpIXP8L6HcYA2AetQPLKcqPmQtwTXCSXiyomr6
81u3XxQLlmNQatx8HZKE9LzttP02sYtPHx+//jRwxTN6w2979LNfWL5zM7ht
BT/frXjk1cXnO7t7e7dKv7CC2zXil6WdLrU848atFvF/3nVfG88D1y1+ariU
7yZawWeH88NPhv4daVYQZ/FGQVFuPb/94ubrgb/qi6MHpV//VHj0lL1tCPf4
t78aOKUuW59UN1fgNqgjvX7R/wBv3n7e/4RuFW4Uxf6Jmm3HIE7M+WWy3U94
jMnNm69v33rOhAvl7Te/6/31m+97v2ev/2Sv/2Xfvwu//6739+z1d+zzH9jr
f7ZDJfp5eKbX0s3bL9jZxGJEIe66nlH41X3xRpHdjZuH/OuL1599erBf+vXu
9p//2ed/+ReR1FoShEiThUu0h7jiDnnAKn3JON5npP4VJQb12LkLt24/Z4+i
/OY/en/s/d+bf+39S+/f2N+/6f3Tm3/v/WPvj1PG3HPVbEn834EyRiv1/ymK
Eud/Kc//sHT97ynT/744zBYDaJlBtVucNuJ7W0IAybIssXLIRIsV22IAn4yw
Y2crt2quQw/4lL8KIycxdDgMjpG4mr0mMQyv7Ptxb/vQA3FbUmQwDOiLik2e
LkKQkiqpadcXCSmSlZHCe71JYd4iq991kiPDfztY9fgfSOh/UMrxv0b2X9Zs
mG81LUgLHf945tjAZJIowzetOk/kjYxxLIiM8YwwON9t0mx5QqfDfRAcbLpe
kwRJ9QWH+st+iF12T4T9VqXZFvgs4/I2xmh7l/24vzvcvOLnb7tOddEBwHPw
r0CctP9gjv/1wX9oRB0LPIhLIAKXExzSpIJrCkzf92iTvuWb0PJcDhCGru3U
ub0lhTWUiah8qdyh3sW+R1uUBELFbTtBGYID3p73d8OvBx1it+ke/yXcg1/y
ol9lv8aq0T9xyvXJE9cXWn6UmVuP2Nu3VlB75D7je3K7ss+UpEleMUPMvuC7
9WmTn2WRPyejk6GureN/DPGwQdRCWzN8yIkGwes0vOHlvvxUcUnut5mh/PD4
4VOxqe/HxMHBqGENd4n0VUzX9Cj7crH8v8NHao36RaTxcXIw6hif9msmPmCS
1/kSeVsuCYMbJ/ILuc6X2IfW4o7fGmJSDBmuvIwzhXVK8XQxBkBo0ijpJCXg
pMSzpIQUk0g7D4jL3EnIQD0mc5w8zmT2Ky6Tchw1VqeU64FKXCblOHJMJu16
cFwm5Tixe/xMKAkJmdhd7qTJxO+zICTPBeLHScpIeuJ5pQhpSaEUKXX+o5eU
DDJyBhmcQQZlkIEZZDI0aQnMl9Hni2jzRTLc5Az3OMMtznCHM9zgLPd3tkjC
gBpkhzHKIyfG0KbiStB1U+eqXv0qDdh6bnjoClS3KyxQYecRKD/qYgfVYNEB
gHP9fxPrf4X2v4ry9f+Waf+nJ9S6nig/HepSYqwwGugvHUZ834MByflhJvIC
V+lRwDX785GEdQQ1FawbNdpd37D81krH/5Ca9P/hfP7PUsr1rP+33cfe9n4K
D4wz882J++dhBuSsYhyazOa+SBuMU8CU1JycFxJ7pbv188X/4vhfffw/Bgn8
y7n/f9X+/z3B9uZTQB/aL00q6qw30zQkvtLNLFmBUT8/e2K8T45NAeQJQ606
X/6Br70Uxvd3mb3T/6hZBPhdB2GvEU4rGgwCSog1JQWjDNGq0tTkRRDps3QM
afk6xmyra211jLysNf9zAgxWuv6XihL2X57/ean8n67/Tc0A+1YGoaZJeGLa
FsBtcM7sELPhnDMdkBE9RkDXicEngJMuRYcpuqCk6UjT5mT9kObpg0gfZnpd
CMevv2etWbFXnf8HyGo8/hOqaj7/c43sv0un1OEJFSDKRhMuX70hzW3EpxtN
EAUOJ3c6XA90PatGuqbhEuRiT4Yusjx/vE6QJDNVaGwsJoCZsEQVkJSS44AP
6Mtgt2UTy+GwPmWXTW/6guMKXXIhBK7AR4rZrekKTeJcCG4loIEvEI8KPl9l
wqcGFzqjAt+xuB5GaNPymySo1BZJAnP9P3Lc/4sBzOf/raH/50pxnQjLUE7g
bVpQJ89D6L80TDtrQvfc5XMt+Ierw78KYBL/uf93KeXR0bcPj06/+ubeu8EA
UzX1mKI+mymmpwCcP1iO9Kuo9Gna/Fp4aJptO7AWbAHM8/9KSrT/l8P8z3KO
/5X4fxmgW0x5zTj/A8rzcDds71DOmh9+MO9qDPkhSegaXybqMIKggag+VxbO
IKmRD5u7o3kK4uk2y3BLwmLJ4u8OM1/xubTZYnJmuZ6RErvtCQ/6JRkKTh29
Sparks, et al. Expires April 23, 2004 [Page 47]
Internet-Draft SIP Torture Tests October 2003
hteeRCHXw9apOBV7wd6fDPofRjH+hwrK8/+tevxvmvcXyvht9cHQtYPwNA0Q
SqH7yJMx7KJRTBDIEBOEsiT3m7wqGb2dk1e8yrpfPNHNlHAhtNQISsf1KPFd
Z6Xr/0AY1/8UNY//W0oZrv/JHpHw9mt7Gr4DEdDrhCGZr/Bp8Ry9ug4hz+c5
dQ33fDXPFfb/bofafmWl8X8Yxvv/PP/v0v2/LmkVzyhtlXZ3x6BHJQQAvJ4w
YC0R6YMmB3cAs5CcfsQPOzw4ZwzjdPsBQA17nKsb9VMIT1uke5AhSs8y8ovX
f33uRZfzthuckdXm/2bIT+Af5et/rY/+H87/f+gVha+LAs/L0+9Fk6r/QabF
f1PWupKm5viYFeSvxxX3rGtgyXpJBjLIQAuZAz3QKtbBugYTwKNV0g5WvP4v
VhP4l3L/71LKgtf/01QEpVodIglqmRa4G2A+RDKjiqkr+vF+fuyjnGL232kH
NdezXoXILQmP3G8cet9xu/5pzfKfVGo884jbIudtKrDmT8K4jAS43++hY4b/
M2JUgtWu/wsS9j/M7f81w/8s9KdiX9c1hODMKT8NhGXiezYyjbPOoQSK/J80
ngQ4azlPJBcljUkj/kIzliCeWEF09iIH7FWcXOhgGD3yHuOfLwGyWvxjOen/
y+O/33X8a5eBfnxQ9xpX9nk4xcM4D/rv0Co+Vy8+M6iIt9glAOfa/ygR/4GV
PP57TfCfnoAdznKwIQx9w3Snu+2jvoIZ3n/IrXFYr40CwZCi6QjzCSQqlnS+
cDCCEYaIzht0uui87kHkgpahd4hjn6Ou49kO7bpmnfh620rqJgiw+h69bFke
DZ0SSyjThyYm7zBPJCrs0f61laEGoK7KuqIgqEnyW6RQ7+Pfrq4S/7KcwL+C
8/Ufljr+JwMkPKFex6pQ4alDOsSyyZkdy0pXnAd/EML/1auXhsXX7fS7mQkg
EVI1YADKoFw3ab07cgrAcGKIhrCq8qljACIkRad6DDnA6biEXYPlOS7xKXBN
Hldac+C5a7qEf4GEdk1+LI8nIA+8C/GOGVCPnQLrCEANaeym8Hf+lZ9H15hK
8y3xHMup8glo7LRuh3pB26PC9rEjnHhulaHT336HljTwjdbK53+pcsL/x/7n
+F8r/3/o5HueNAKmz52Mx4ZmSAkwMxnAhI+QBwgZjBuMrc07lQptBYPZWY57
5hoXIyffJQYFpDnLVk1M6lybtQDediDAp01rxfk/gDwR/630x/9y/X8pJT7/
a49VstwuYBAB5+VJYSrUXa/ajwZAEMNZ8QCpAwLauJsfgj4GvZ2JH1qNiq+K
TatJd7j63C/hjAdWy2C3ab2kxk7kB9+qOuyXiCzrzUmVsg3syJEvpkeqs6jk
3ZmH5vO7s9L5H6EVF8c/ytf/XXr/P0jierUp4BzYk42eqeme04/diVgBaSeZ
tAR86hiTjDFyBoQzw6jVjhIFMZ1GnXpW2z1nW0jHadjEpI36OVP92xi1SZeO
0gJpXIdnPehIGZiXxHVwLYmqHiTVAiQl4wbizLI3ZpZ+aXlu4FZcu7wdpy1R
Ffk+hBsX24n9mkzUrpb9GpES285cvtKcd1HeFllB+O6Xsn6X4U3B0r17QFN1
WcesSLJ6Vz36YpsTkihmEU3UbsyH/CB5S7piS1qHruyy8S44GvLer9u6pDW5
anOehcC9cL2T8nbYWxZbatTEP/V4iDL1xCOn4hqha+DMchgAxyL3LL/l+lY/
CoEErFnUmuz3PcG0bJo88tYm6H33ce+3P/mTW73fbPR+67befP9J69bHQu9v
e//A/54In/zsk95/bfS+f/G49/s3P4AbvR9OPtr403CHr3q/efPfWx/89IPe
D73vfvKKHeojnf35sPfPvR8++vCDDz/8mNH+x73vtw83frbx5vv/b+9a3Jo6
svgNCQFEKhgqtIg7ha21LNGbhEgCsh/WLm3ZimikdFt3l5DcmPC4wdyEh6tb
Hip9qKBQ8IkPVitW2+ITter3nfOP7ZkEWEIe0O5X+Nreg0EyuffcyZlzfnNm
5syZJjgLt9yzD8mur9emaWdZW+t1ekNKg8NkEHP02gZduoHbis/jD8g+pylH
XKfXCvXVh0Q4vn0D/gdu4uPtjmycFLCXbq2Ga2LjdhjXw/iu9TCSksY5ZBoc
vg5fcL+kBHdJgaDPw+UtRaI0BBh/D0Y0eK0DR7QWg7bYYNi1y1LcALzAQAUG
GKASrdn6idhsyhQzOMM49RNgzIOPN+NNGDPk0Bf8gVcmfiVTdWsMqQqvkalA
fI2z0OauXwgaAp7Yh3TLZiX9NbwfI6zsesGWj8Pa9HwYToE+6BPwKxhI0a9b
j5/jU2MenICzpXBNwUv4LfTCy4IC+BIf15rW+kJwQ2jpFPGZrNsNE3B+N576
AL7HxzDeVmM8DKeDeAdewrlABX6L93pkvJzV7Go80vanLrx0RMx0VOFdeIjP
4DTch/7PcAx/hIvl8ASu4gT0w5WCbKqKq4Qedh6fCXCL1/o0fI4z/86EcbgI
N/fBKNw52m7Mh2/gJNXyAT5VbGl1xSlajaCBSejDKZF+3RQLSSiFOboNYi70
zUpG0DfCiQ04rp+XTVhX9uIZsbpY0Gow/GYYr+7U63Kr8eXGtQUw4/0QpvJg
AC534NRRnMHLnzbR9SSyC/wBxTqqb3F6Ps5oauCB81AdTL3X/HFqDV6z7obb
m6w7awta8mrfK04TkrR7WC+FpRs9opnacKu/Lb6VSC2Fmv15jTXclDZzxTzH
srVxjIXaXyP48cXrlQfwVhoO4OVSfI6PcKr7sw82wjG8iI+p8c8Uwj0cg1vw
+dFtOIn3BJzCE/DFBzC6ZWs93M7Cl3gNv8JRvFPK3ug24Y8lONJEksui4olN
Sparks, et al. Expires April 23, 2004 [Page 48]
Internet-Draft SIP Torture Tests October 2003
MChkl+JTOI/f1X94FHvxXKjE9XYtDr6Pl3ECn+JEA57A4b04jaf24xB+g30O
oRvGShx4Gh8VwOCBP+AIDtbBeNE7pJ9XDQWVcLLpX/jk03LoX49fwoW0f8QD
CRgW4IuUPwoaMWsOV4Q4GFHtFN9ssORYNNlh2fZpY0CiQZdmSHc45Vq/Iple
EePjQ0e4bNoaKfpLTWO5LgYifMEecVNelmgxiWaTqUyIAw+8ZFJfvKB22uQI
1qATloFgOXBfQ/xiESLSiXNNvjIrJiEeOmzJz14LMyJrwulSGILreKbbl5IQ
Gj6Cb1zr4BFefZcMeApG6aJRuIAve4QE6IBjm61dpAT98PgoDuKAAA8tpBoX
U5NjBI6ZSSnvwhX4YQ2cyNiCt6hug3gVnggJUSKI16mzzhZet22ivmiTS5MV
CxFRosnQC/HAoWnnu+tIY3uxD54R72Okh2e67TguJAIIOMvfDkFvbmtNXi7e
htHON6FXiAWJGNXUJmn8sGYKS/Zec9qpTdh9kW5Cv0YQ44NEtp7bOCHrQzwN
vUeq8CwZ6hUZxtOT4cRWuOSlNjj/DvTjjTXUclfwxUZ4XifEhwlNCg7BFEzg
DR0pwaUsGNwHN80wuiYpVLwFXzTDjR34vRNmQtiHz3cEcSogJICKEE7ms0JX
Oitk5IMQ4gkdS2CysJyeOCzw2a44MSgLedGgPMygN2PelVnoDKUK5Pz0wbSY
v9AlytCaFrlI4kYhqrVgmKo0PeeBFBscxTCifRMmU8SmhXx0pg263Npt+DUc
b23S7zRn4NOPqHn68NzeHmrLrwS8n8oWMcb7uQ6dherVROY3Vy4qwiv69HnO
2pSUFAF6CUmiyjTVYppeiHw5poQ1bAELxtbDwCK102g0qQI3GrIvHHhtBz4g
rXqxvhse7iMgGYJreLyQFGICh7Kq8BjZ4BAeF+AGTDPq0r/+G13+dcWOHUfI
W3iAt/GcDYZeTSfv5O42HNyIg/AE7255tzujCSbxDs70kAJf/+RVeADfunC6
HgdSO+CR6ZPit5B7Et/l4C0PXspNxQsCTATxJGP5G3B6bzuegxGLES7A6c0E
U99hfzkeI6y7j9/TmwcEbafeKFqLE0cbqZqnlufSG41qeoGfSEGyr186AcCS
8X9R+f/D83+iev7His//OduccnWLU/G3+2bTnexhNFxdXBqZYAk42zq80ZP+
u50fGz17Ao3OfW5HBaMmTxjgvzDc7+Oew4d7jOYKFvT6FEb/gl6JyaH2ZinA
aPDMIpuDIldZKubnW8IFUTE6VAHJGVma9/j9rJlalVqMV9jv528C4f/izGXY
lrucx22F+FeFc7j8Vuyfz17wo1eVVcz/tr18kf2XWUTV/ldl/e/nnf/xf537
wWSPyy55PW6PU2r1tXjLnK1u2XmopbWLRhOKU/HwBcAEk6TLOhlk6TTQi25y
7NpPd5mT3dXmVFrcXs/i8MgPHSxoSXKf2W4TQ7Kbf6Poatb9tW5PYx0LliW5
2am4RY9FkuPEZCaNgxaddp/bI0tSnCXIYKBLWe3+3yqWx/T/VtX+V9z+A1K7
PygZSR4H4y/6M5YoHDisfQk0nofqiPbopZsED4pev2nzE6QYA5LiDwVcUjxg
sZeZ7aLNHrWII3UF/D5XyFJmt/JVGlny8AwC3oDZUmYNLAkkZovNvjC5QPx1
nV9FaN/y1F9uVVztvywCLL3/J3b9X7X/lbX/RXFzkc2xFUF/kB8nHtkj64oo
/u8sG8hvfD6B23+7eZXt3xIz/jeXq/k/VoSWt//PpzTLFeS7WsrtZlu5Zb6X
9gaDPGFQV1fX1nhuPxlmwpi+am9Ph1eSnUHJbVycxv1/nXGZXVy4wWcBYkQ6
48T5Zk3L2RG8gy++V9T6vfI/He2+oPfPv7tk8SF51fP/mcSY8b+l3KSe/7Ai
NOfZm0WRVTFzSYmFlTBrSYmZ4TA8p9cLhmegj179QiZez8rcnfn3TGM+Ps/E
y5l4N78w3xgu1tGlD+l1j64c4lfT6yQzci4v6c9ezmmOEQ4LeDczWfys3bbI
cKlHKLNHHRoskgth4+cE8GNDW7lj0GppMUuBLsntUXY6kqQbTLhh2WSKHEmY
wLOR3KFI+JjZbI+3LcC+rDCqeFv97LaYLIQ/LZWQ3ZYwvMpu22Yyl6unsqsU
l7oUn9y5uvu/TPywv8X+n0XN/7TS6z+dvk6p9WC1y+v0BYxuOeCKGjTRQIEG
hzLJwLnQOdzDKrLWLH07q2SMEXjySNQqAieTjf9YLHLWGk+AnzTIKlhRLdvn
VyS5WQocZAcOHCgqmg1djWSbcwf4h9Uxe6L5L865Kpz0v8Vt+7krUdGIHq5S
eK+XSwlnnxZFO3/Ugn1k/AqSBGPb6OKwOBjvxiIxt/OO6FxPZrGLyqz/qXCh
1UldNU75YJvkfl9yuvm+U8ZkqcsTKWOdzraQRKz4qNsnh6gk9sOGSJtE7m8k
/7VBDikhZ9tH/OMKVllZWkqvyiX7pXAiDN6Os6HK4W3ASlTztwXmNKCLnlMV
rsBciVH2G8MF1CCdFWxOJuEJw22Mj8E5KR0+3pVFacVs80UkxDWDsbmYb19r
i40xHsA8L+IIR/qT+wphAZu227aardat1HNzXrOMquimuUwEfNsudWwVRXtD
fhpqMCUY8MmkXkVcvRIqFrEiaUd0nbjR3+HvF6mtwmdC3JEPK9khqrW41fLT
8/8lzABetpKd9WGJzM+zyuN/sxg7/6f6/7+i9b9kM30HvYq7zLTowFfF6W7h
U3ltHrnd7De3lVkC1pAYme6LmtqzmE1JVvaWdcYrn0XwLZ5tFH+Pk30qqaSS
SiqppJJKKqmkkkoqqaSSSiqppJJKKqmkkkoqqaSSSiqppNJvkv4L6lHiEwAY
Sparks, et al. Expires April 23, 2004 [Page 49]
Internet-Draft SIP Torture Tests October 2003
AQA=
-- END MESSAGE ARCHIVE --
Sparks, et al. Expires April 23, 2004 [Page 50]
Internet-Draft SIP Torture Tests October 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Sparks, et al. Expires April 23, 2004 [Page 51]
Internet-Draft SIP Torture Tests October 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sparks, et al. Expires April 23, 2004 [Page 52]