SIPPING
Network Working Group                                     R. Sparks, Ed.
Internet-Draft                                               dynamicsoft
Expires: April 23, 2004                                   A. Hawrylyshen
                                                         Jasomi Networks
                                                             A. Johnston
   Internet Draft                                              WorldCom
   Document: draft-ietf-sipping-torture-tests-00.txt
                                                                     MCI
                                                            J. Rosenberg
   Expires: February 2003
                                                             dynamicsoft
                                                          H. Schulzrinne
                                                     Columbia U.
                                                            August 2002 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.

   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 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.  They were developed as part of the SIPit SIP
   interoperability testing events.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [1].

Table of Contents

   1. Overview.......................................................3
                      SIP Torture Test Messages           August 2002       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..............................................3
      2.1 INVITE Messages  . . . . . . . . . . . . . . . . . . .   6
   3.1      Parser Torture Test Message.........................3
      2.2 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 Proxy-Require no LWS between display name and Require......................4
      2.3 INVITE with Unknown Schemes < . . . . .  12
   3.1.1.7  Long values in URIs........................5
      2.4 REGISTER with Y2038 Test...................................5
      2.5 INVITE with inconsistent Accept 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 body...........6
      2.6 INVITE with non-SDP  . . . . . . . . . . . . . . . . .  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 body...........................6
      2.7 . . . . . . . . . . .  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 Method Message.....................................7
      2.8 protocol version . . . . . . . . . . . . . . . .  30
   3.1.2.17 Start line and CSeq method mismatch  . . . . . . . . . .  31
   3.1.2.18 Unknown Method with CSeq Error.............................7
      2.9 REGISTER 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
   3.3.3    Request-URI with known but atypical scheme . . . . . . .  34
   3.3.4    Unknown Authorization Scheme.................8
      2.10 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 SIP Request values in a Single Message..................8
      2.11 INVITE missing Required Headers...........................9
      2.12 INVITE with Duplicate Required Headers...................10
      2.13 INVITE with Illegal Expires Header.......................10
      2.14 single value required fields  . . . .  37
   3.3.9    Multiple Content-Length values . . . . . . . . . . . . .  37
   3.3.10   200 OK Response with Broadcast broadcast Via Header................11
      2.15 INVITE header field value  .  38
   3.3.11   Max-Forwards of zero . . . . . . . . . . . . . . . . . .  39
   3.3.12   REGISTER with Invalid Via and Contact Headers..............12
      2.16 INVITE with Incorrect Content-Length Header..............12
      2.17 INVITE with Invalid Value for Content-Length.............13
      2.18 INVITE with Garbage after Message Body...................14
      2.19 INVITE with Error in Display Name in To Header...........14
      2.20 INVITE with a Semicolon-Separated Parameter in the "user"
      Part..........................................................15
      2.21 INVITE with Illegal Enclosing of Request-URI  in "<>"....15
      2.22 INVITE with Illegal LWS within Elements of Request-URI...16
      2.23 INVITE with illegal >1 SP between elements of Request URI17
      2.24 INVITE with a legal SIP URI containing escaped characters17
      2.25 INVITE with the illegal use of escaped headers in Request-URI
      ..............................................................18
      2.26 INVITE containing an unknown scheme in the Request URI...19
      2.27 OPTIONS with no LWS between display name and <...........19
      2.28 OPTIONS with extran LWS between display name and <.......20
      2.29 INVITE with an illegal SIP Date format...................20
      2.30 INVITE with Passed Expries Time..........................21
      2.31 INVITE with Max-Forwards Set to Zero.....................21
      2.32 REGISTER with a Escaped Header in a Legal SIP URI of a
      Contact.......................................................22
      2.33 REGISTER with a Escaped Header in a Illegal SIP URI of a
      Contact.......................................................22
      2.34 INVITE with Long Values in Headers.......................23
      2.35 OPTIONS with multiple headers............................24
      2.36 INVITE with large number of SDP attributes and telephone
      subscriber Request-URI........................................25
      2.37 contact header parameter . . . . . . . .  39
   3.3.13   REGISTER with a contact parameter........................26
      2.38 url parameter  . . . . . . . . . . . . .  40
   3.3.14   REGISTER with a url parameter............................26
      2.39 INVITE with an Unquoted Display Name Containing Multiple
      Tokens........................................................26
      2.40 INVITE with an Unquoted Display Name Containg Non-Token
      Characters....................................................27
      2.41 INVITE with Unknown (Higher) Protocol Version in Start Line27
                      SIP Torture Test Messages           August 2002

      2.42 escaped header . . . . . . . . . . .  40
   3.3.15   Unacceptable Accept offering . . . . . . . . . . . . . .  41
   3.4      Backward compatibility . . . . . . . . . . . . . . . . .  42
   3.4.1    INVITE with RFC2543 syntax...............................28 syntax . . . . . . . . . . . . . . .  42
   4.       Security Considerations..........................................28
   References.......................................................28
   Acknowledgments..................................................29
   Author's Addresses...............................................29 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

1. Overview

   These SIP test messages are based on the current version 2.0 of SIP
   in RFC 3261[2] with SDP usage described in RFC 3264[3].

   Note that this

   This document is informational, and is NOT NORMATIVE on any aspect of SIP syntax.

2.   SIP Test Messages

   The files in here are
   SIP.

   This document contains test messages for SIP servers to based on the current version
   (2.0) of the Session Initiation Protocol as defined in [RFC3261].
   Some messages exercise
   various functions. They have been used SIP's use of SDP as described in SIPit [RFC3264].

   These messages were developed and refined at the SIPIt
   interoperability test events.  All

   The test messages shown here are valid, unless
   otherwise noted.  The correct behavior of servers and clients is also
   described. 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    INVITE Parser Torture Representing Long Lines

   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.

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 <hex/
   > tags. This rendering applies even inside quoted-strings.

   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:

      Subject: <hex>E282AC</hex>

2.3 Representing Long Repeating Strings

   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>

    and a Max-Forwards header field with a value of one google will be
   rendered here as

      Max-Forwards: 1<repeat count=100>0</repeat>

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
   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 \\\""       <sip:jdrosen@example.com>
        ;
        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:
       <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

      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 is exercises a correctly formatted SIP message. 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 contains:

   line folding is not the same as a method of INVITE

   o  The Request-URI contain unusual, but legal, characters

   o  A branch parameter contains all over
   escaped 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 within quotes
   LWS between colons, semicolons, headers, and other fields
   both comma separated and separate listing 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 headers
   mix ',` or short and long form for " imply that
         there will be a matching symbol later in the same header 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 header ordering
   unknown parameters of URI has been defined at a known header

   Proxies should proxy, the proxy will
   forward message and clients should respond as to this request normally. Otherwise a
   normal INVITE message. proxy will generate a 404.
   Endpoints will generate a 501 listing the methods they understand in
   an Allow header field.

      Message Details

   INVITE sip:vivekg@chair.dnrc.bell-labs.com SIP/2.0
   TO :
    sip:vivekg@chair.dnrc.bell-labs.com ;   tag    = 1918181833n
   From : "J Rosenberg \\\"" <sip:jdrosen@lucent.com>
     ;
     tag = 98asjd8
   Max-Forwards: 6

      <allOneLine>
      !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
      </allOneLine>
      Via: SIP/2.0/TCP host1.example.com;branch=z9hG4bK-.!%66*_+`'~
      <allOneLine>
      To: "BEL:\<hex>07</hex> NUL:\<hex>00</hex> DEL:\<hex>7F</hex>"
       <sip:1_unusual.URI~(to-be!sure)&isn't+it$/crazy?,/;;*
      @example.com>
      </allOneLine>
      <allOneLine>
      From: token1~` token2'+_ token3*%!.- <sip:mundane@example.com>
      ;fromParam''~+*_!.-%=
      "<hex>D180D0B0D0B1D0BED182D0B0D18ED189D0B8D0B9</hex>"
      ;tag=_token~1'+`*%!-.
      </allOneLine>
      Call-ID: 0ha0isndaksdj@10.1.1.1
                      SIP Torture Test Messages           August 2002

   cseq: 8 word%ZK-!.*_+'@word`~)(><:\/"][?}{
      CSeq: 139122385 !interesting-Method0123456789_*+`.%indeed'~
      Max-Forwards: 255
      <allOneLine>
      extensionHeader-!.%*+_`'~=
      <hex>EFBBBFE5A4A7E5819CE99BBB</hex>
      </allOneLine>
      Content-Length: 0

3.1.1.3 Valid use of the % escaping mechanism

   This INVITE
   Via  : SIP  /   2.0
    /UDP
       135.180.130.133;branch=z9hG4bKkdjuw
   Subject :
   NewFangledHeader:   newfangled value
    more newfangled 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
      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
   Content-Type: application/sdp
   v:  SIP  / 2.0  / TCP     1192.168.156.222   ;
     branch  =   9ikj8  ,
    SIP  /    2.0   / UDP  192.168.255.111   ; hidden
   m:"Quoted string \"\"" <sip:jdrosen@bell-labs.com> ; newparam =
   newvalue ;
     secondparam = secondvalue  ; q = 0.33,
    tel:4443322 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: <sip:I%20have%20spaces@example.net>;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:
        <sip:cal%6Cer@host5.example.net;%6C%72;n%61me=v%61lue%25%34%31>
      Content-Length: 151

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.1
      s=-
      c=IN IP4 135.180.130.88 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.2    INVITE with Proxy-Require and Require

3.1.1.4 Escaped nulls in URIs

   This register request contains several URIs with nulls in the
   userpart. The message tests support for Proxy-Require and Require. It 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.

      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: <sip:%00@host5.example.com>
      Contact: <sip:%00%00@host5.example.com>
      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 that contains both headers, listing new features.

   Proxies has these properties:

   o  The request method is unknown. It is NOT equivalent to REGISTER

   o  The display-name portion of the To and clients 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 respond 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 420 Bad Extension, 501.

      Message Details :

      RE%47IST%45R sip:registrar.example.com SIP/2.0
      To: "%Z%45" <sip:resource@example.com>
      From: "%Z%45" <sip:resource@example.com>;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: <sip:alias1@host1.example.com>
      C%6Fntact: <sip:alias2@host2.example.com>
      Contact: <sip:alias3@host3.example.com>
      l: 0

3.1.1.6 Message with no LWS between display name and an
   Unsupported <

   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 listing these features. 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

   INVITE sip:user@company.com :

      OPTIONS sip:user@example.com SIP/2.0
      To: sip:j_user@company.com sip:user@example.com
      From: sip:caller@university.edu;tag=242etr
   Max-Forward: 6 "caller"<sip:caller@example.com>;tag=323
      Max-Forwards: 70
      Call-ID: 0ha0isndaksdj@10.1.1.1
   Require: newfeature1, newfeature2
   Proxy-Require: newfeature3, newfeature4 1234abcd@funky.example.com
      CSeq: 8 INVITE 60 OPTIONS
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
                      SIP Torture Test Messages           August 2002

2.3    INVITE with Unknown Schemes funky.example.com;branch=z9hG4bKkdjuw
      l: 0

3.1.1.7 Long values in URIs header fields

   This message well-formed request contains unknown schemes in the Request URI, To, From header fields with many values and Contact headers of
   values that are very long. Features include:

   o  The To header field has a request.

   A server should probably return 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 not found error; but other
   behaviors are acceptable. very long tag

   o  The Call-ID is one long token

      Message Details :

      INVITE name:John_Smith sip:user@example.com SIP/2.0
      <allOneLine>
      To: isbn:2983792873
   From: <http://www.cs.columbia.edu>;tag=3234233
   Call-ID: 0ha0isndaksdj@10.1.2.3
   CSeq: 8 INVITE
   Max-Forward: 7 "I have a user name of
       <repeat count=10>extreme</repeat> proportion"
      <sip:user@example.com:6000;
      unknownparam1=very<repeat count=20>long</count>value;
      longparam<repeat count=25>name</repeat>=shortvalue;
      very<repeat count=25>long</count>ParameterNameWithNoValue>
      </allOneLine>
      <allOneLine>
      F: sip:

      <repeat count=5>amazinglylongcallername</repeat>@example.net
      ;tag=12<repeat count=50>982</repeat>424
      ;unknownheaderparam<repeat count=20>name</count>=
      unknowheaderparam<repeat count=15>value</count>
      ;unknownValueless<repeat count=10>paramname</count>
      </allOneLine>
      Call-ID: one<repeat count=20>really</repeat>longcallid
      CSeq: 3882340 INVITE
      <allOneLine>
      Unknown-<repeat count=20>Long</repeat>-Name:
       unknown-<repeat count=20>long</repeat>-value;
       unknown-<repeat count=20>long</repeat>-parameter-name =
       unknown-<repeat count=20>long</repeat>-parameter-value
      </allOneLine>
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 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
      <allOneLine>
      Via: SIP/2.0/TCP
      host.example.com;received=192.0.2.5;
      branch=very<repeat count=50>long</repeat>branchvalue
      </allOneLine>
      Max-Forwards: 70
      <allOneLine>
      Contact: <sip:
      <repeat count=5>amazinglylongcallername</repeat>
      @host5.example.net>
      </allOneLine>
      Content-Type: application/sdp
      l: 151

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.1
      s=-
      c=IN IP4 135.180.130.88 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.4    REGISTER with Y2038 Test

   This message is

3.1.1.8 Extra trailing octets in a registration request with an expiration year of
   2040. UDP datagram

   This makes sure that message contains a server doesn't crash on seeing single SIP REGISTER request, which ostensibly
   arrived over UDP in a date
   past Y2038. single datagram. The correct behavior 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 probably a proxy choosing to limit forward the REGISTER,
   the INVITE octets would not appear in the lifetime to some
   configured maximum. forwarded request.

      Message Details :

      REGISTER sip:company.com sip:example.com SIP/2.0
      To: sip:user@company.com sip:j.user@example.com
      From: sip:user@company.com;tag=3411345 sip:j.user@example.com;tag=43251j3j324
      Max-Forwards: 8
      I: 0ha0isndaksdj99sdfafnl3lk233412
      Contact: sip:user@host.company.com
   Call-ID: 0ha0isndaksdj@10.0.0.1
                      SIP Torture Test Messages           August 2002 sip:j.user@host.example.com
      CSeq: 8 REGISTER
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
   Expires: Sat, 01 Dec 2040 16:00:00 GMT

2.5    INVITE with inconsistent Accept and message body

   This is a UAS test. It is a request that includes an Accept header
   without SDP. The UAS should respond with an error.

   Message Details 192.0.2.125;branch=z9hG4bKkdjuw23492
      Content-Length: 0
      INVITE sip:user@company.com sip:joe@example.com SIP/2.0
   To: sip:j_user@company.com
      t: sip:joe@example.com
      From: sip:caller@university.edu;tag=234 sip:caller@example.net;tag=141334
      Max-Forwards: 5 8
      Call-ID: 0ha0isndaksdj@10.0.0.1
   Accept: text/newformat 0ha0isnda977644900765@192.0.2.15
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw 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 135.180.130.88 192.0.2.15
      t=0 0
      m=audio 492170 RTP/AVP 0 12
   m=video
      m =video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.6    INVITE with non-SDP message body

   This is a test of a

3.1.1.9 Semicolon separated parameters in URI user agent server. It is a part

   This request that includes has a body 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 non-SDP type. well formed
   message. The Request-URI will parse such that the user agent server should respond with an error. part is
   "user;par=u@example.net".

      Message Details

   INVITE sip:user@comapny.com :

      OPTIONS sip:user;par=u%40example.net@example.com SIP/2.0
      To: sip:j.user@company.com sip:j_user@example.com
      From: sip:caller@university.edu;tag=8 sip:caller@example.org;tag=33242
      Max-Forwards: 70 3
      Call-ID: 0ha0isndaksdj@10.0.0.1 0ha0isndaksdj
      CSeq: 8 INVITE OPTIONS
      Accept: application/sdp, application/pkcs7-mime,
              multipart/mixed, multipart/signed,
              message/sip, message/sipfrag
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
   Content-Type: application/newformat
                      SIP Torture Test Messages           August 2002

   <audio>
    <pcmu port="443"/>
   </audio>

2.7    Unknown Method Message 192.0.2.1;branch=z9hG4bKkdjuw
      l: 0

3.1.1.10 Varied and unknown transport types

   This request message contains a new unknown method, NEWMETHOD.

   A proxy should forward this using Via header field values with all known
   transport types and exercises the same retransmission rules transport extension mechanism.
   Parsers must accept this message as
   BYE. A UAS should reject well formed. Elements receiving
   this message would process it with an error, exactly as if the 2nd and list 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: <sip:caller@example.com>;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 available
   methods in received message.

   Parsers must accept this message as well formed, even if the response.
   application above the parser does not support multipart/signed.

      Message Details

   NEWMETHOD sip:user@comapny.com :

      INVITE sip:receiver@example.com SIP/2.0
      Via: SIP/2.0/UDP host5.example.org;branch=z9hG4bK923rnasdkl3
      To: sip:j.user@company.com <sip:receiver@example.com>
      From: sip:caller@university.edu;tag=34525
   Max-Forwards: 6 <sip:sender@example.org>;tag=2390234seiu3
      Call-ID: 0ha0isndaksdj@10.0.0.1 afnkjeriuoqeiuavnklafekjq34iu43uawe
      CSeq: 8 NEWMETHOD 282398492 INVITE
      Max-Forwards: 70
      Contact: <sip:sender@host5.example.org>
      Content-Length: 3134
      Content-Type: multipart/signed;
                    protocol="application/pkcs-7-signature";
                    micalg=sha1;
                    boundary="----34CF59C076641DD0879594444157C7EB"
      ------34CF59C076641DD0879594444157C7EB
      Content-Type: message/sip

      INVITE sip:receiver@example.com SIP/2.0
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw host5.example.org;branch=z9hG4bK923rnasdkl3
      To: <sip:receiver@example.com>
      From: <sip:sender@example.org>;tag=2390234seiu3
      Call-ID: afnkjeriuoqeiuavnklafekjq34iu43uawe
      CSeq: 282398492 INVITE
      Max-Forwards: 70
      Contact: <sip:sender@host5.example.org>
      Accept: application/sdp, application/pkcs7-mime,
              multipart/mixed, multipart/signed,
              message/sip, message/sipfrag
      Content-Type: application/sdp
      Content-Length: 149

      v=0
   o=mhandley
      o=sender 29739 7272939 IN IP4 126.5.4.3 192.0.2.1
      s=-
      c=IN IP4 135.180.130.88 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.8    Unknown Method with CSeq Error

      ------34CF59C076641DD0879594444157C7EB
      Content-Type: application/pkcs-7-signature; name="smime.p7s"
      Content-Transfer-Encoding: binary
      Content-Disposition: attachment; filename="smime.p7s"

      <hex>3082088806092A86
      4886F70D010702A082087930820875020101310B300906052B0E03021A050030
      0B06092A864886F70D010701A082067A30820339308202A2A003020102020800
      90008902240001300D06092A864886F70D01010505003070310B300906035504
      0613025553311330110603550408130A43616C69666F726E69613111300F0603
      550407130853616E4A6F7365310E300C060355040A1305736970697431293027
      060355040B135369706974546573744365727469666963617465417574686F72
      697479301E170D3033313032313134343332355A170D31333130313831343433
      32355A3062310B3009060355040613025553311330110603550408130A43616C
      69666F726E69613111300F0603550407130853616E4A6F7365310E300C060355
      040A13057369706974311B30190603550403141273656E646572406578616D70
      6C652E6F726730819F300D06092A864886F70D010101050003818D0030818902
      818100CB8302060F12C8FA2D1786922CA173DCEB80BF1B1B8AF74A310C6975A5
      56A7630FB6E044D9E994DCD49AFF7976C462D7A8E74ECBF98723AEBF2796EDDD
      6263577C6C2B77DC7C300B533DEDB5FB8EB3827FD6FC9B37B9A0DE829F1B1081
      D632A8AD9FB00A860928E88F87E0B979BA65294AC7D6D2D18A78C86B4FA73387
      4E230203010001A381E93081E6301D0603551D1104163014811273656E646572
      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
      9A5B120E6D559F4953A3C3C7C97B4EAD8388F1508F7AD2FC71CC7B9ED2844789
      60A3ECF87984E25A15B4AB63F150C30570B6315A2327E381EE11E866DC1405DA
      29E74CC20201816F1516DD893332D9A8E26FBAEC237C494F3EFAEF4EBCD2122C
      DE7D57DECD</hex>------34CF59C076641DD0879594444157C7EB--

3.1.1.12 Unusual reason phrase

   This message is nearly identical to the Unknown Method message. It is
   a request with a new unknown method, but with 200 response contains a CSeq method tag which
   does not match.

   A proxy should either respond with an error, or correct the method
   tag. reason phrase other than "OK". The user agent should reject it with an error,
   reason phrase is intended for human consumption, and list the
   available methods in the response. 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 Torture Test Messages           August 2002

   NEWMETHOD sip:user@comapny.com :

      <allOneLine>
      SIP/2.0
   To: sip:j.user@company.com
   From: sip:caller@university.edu;tag=23411413
   Max-Forwards: 3 200 = 2**3 * 5**2 <hex>D0BDD0BE20D181D182
      D0BE20D0B4D0B5D0B2D18FD0BDD0BED181D182D0BE20D0B4
      D0B5D0B2D18FD182D18C202D20D0BFD180D0BED181D182D0
      BED0B5</hex>
      </allOneLine>
      Via: SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
      Call-ID: 0ha0isndaksdj@10.0.1.1 0384840201234ksdfak3j2erwedfsASdf
      CSeq: 8 35 INVITE
   Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
      From: sip:user@example.com;tag=11141343
      To: sip:user@example.edu;tag=2229
      Content-Length: 159
      Content-Type: application/sdp
      Contact: <sip:user@host198.example.com>

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.198
      s=-
      c=IN IP4 135.180.130.88 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

2.9    REGISTER with Unknown Authorization Scheme

3.1.1.13 Empty reason phrase

   This message is a REGISTER request with an unknown authorization
   scheme. well formed response contains no reason phrase. A parser must
   accept this message. The server should do something reasonable, such as rejecting space character after the
   request. 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

   REGISTER sip:company.com :

      SIP/2.0
   To: sip:j.user@company.com
   From: sip:j.user@company.com;tag=87321hj23128
   Max-Forwards: 8
   Call-ID: 0ha0isndaksdj@10.0.1.1
   CSeq: 8 REGISTER 100<hex>20</hex>
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
   Authorization: Super-PGP ajsohdaosdh0asyhdaind08yasdknasd09asidhas0d8

2.10     Multiple SIP Request in a Single Message 192.0.2.105;branch=z9hG4bK2398ndaoe
      Call-ID: adsn2309jasndj203insdf99223ndf
      CSeq: 35 INVITE
      From: <sip:user@example.com>;tag=39ansfi3
      To: <sip:user@example.edu>;tag=902jndnke3
      Content-Length: 0
      Contact: <sip:user@host105.example.com>

3.1.2 Invalid messages

   This message section contains two requests, separated by 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 bunch comprehensive list of
   whitespace. Since the message exceeds the length indicated in the
   Content-Length header, the 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 be rejected. (Multiple SIP
   requests per UDP packet are no longer allowed.)
                      SIP Torture Test Messages           August 2002 respond with a 400 Bad
   Request error.

      Message Details

   REGISTER sip:company.com SIP/2.0
   To: sip:j.user@company.com
   From: sip:j.user@company.com;tag=43251j3j324
   Max-Forwards: 8
   Call-ID: 0ha0isndaksdj@10.0.2.2
   Contact: sip:j.user@host.company.com
   CSeq: 8 REGISTER
   Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
   Content-Length: 0 :

      INVITE sip:joe@company.com sip:user@example.com SIP/2.0
      To: sip:joe@company.com sip:j.user@example.com
      From: sip:caller@university.edu;tag=141334 sip:caller@example.net;tag=134161461246
      Max-Forwards: 8 7
      Call-ID: 0ha0isnda977644900765@10.0.0.1 0ha0isndaksdjasdf3234nas
      CSeq: 8 INVITE
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw 192.0.2.15;;,;,,
      Contact: "Joe" <sip:joe@example.org>;;;;
      Content-Length: 153
      Content-Type: application/sdp

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.15
      s=-
      c=IN IP4 135.180.130.88 192.0.2.15
      t=0 0
      m=audio 492170 RTP/AVP 0 12
   m =video
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.11     INVITE missing Required Headers

3.1.2.2 Content length larger than message

   This is a request message contains no Call-ID, From, or To header.

   The server should not crash, and ideally 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 an 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@company.com sip:user@example.com SIP/2.0
      Max-Forwards: 80
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=93942939o2
      Contact: <sip:caller@hungry.example.net>
      Call-ID: 0ha0isndaksdjweiafasdk3
      CSeq: 0 8 INVITE
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
                      SIP Torture Test Messages           August 2002 host5.example.com;branch=z9hG4bK-39234-23523
      Content-Type: application/sdp
      Content-Length: 9999

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.155
      s=-
      c=IN IP4 135.180.130.88 192.0.2.155
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.12     INVITE with Duplicate Required Headers

   The message contains a

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 extra Call-ID and To field.

   The server should 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 crash, recoverable and the connection should ideally respond with 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
   error. 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@company.com sip:user@example.com SIP/2.0
   Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
      Max-Forwards: 70 254
      To: sip:j.user@example.com
      From: sip:caller@example.net;tag=32394234
      Call-ID: 0ha0isndaksdj2193423r542w35
      CSeq: 0 INVITE
   Call-ID: 98asdh@10.1.1.1
   Call-ID: 98asdh@10.1.1.2
   From: sip:caller@university.edu;tag=3413415
   From: sip:caller@organization.org
   To: sip:user@company.com
      Via: SIP/2.0/UDP 192.0.2.53;branch=z9hG4bKkdjuw
      Contact: <sip:caller@example53.example.net>
      Content-Type: application/sdp
      Content-Length: -999

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.53
      s=-
      c=IN IP4 135.180.130.88 192.0.2.53
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.13     INVITE

3.1.2.4 Request scalar fields with Illegal Expires Header overlarge values

   This message request contains an Expires several scalar header which has illegal field values for
   a outside
   their legal range.

   o  the CSeq sequence number of components, but otherwise is syntactically correct.

                      SIP Torture Test Messages           August 2002 >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 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

   INVITE sip:user@company.com :

      REGISTER sip:example.com SIP/2.0
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw
   Max-Forwards: 88 SIP/2.0/TCP host129.example.com;branch=z9hG4bK342sdfoi3
      To: <sip:user@example.com>
      From: <sip:user@example.com>;tag=239232jh3
      CSeq: 0 INVITE 36893488147419103232 REGISTER
      Call-ID: 98asdh@10.1.1.2 asdnw3qjr23o0pd9vanlq3wnrlnewofjas9ui32
      Max-Forwards: 300
      Expires: Thu, 44 Dec 19999 16:00:00 EDT
   From: sip:caller@university.edu;tag=3651
   To: sip:user@company.com
   Content-Type: application/sdp

   v=0
   o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=-
   c=IN IP4 135.180.130.88
   t=0 0
   m=audio 492170 RTP/AVP 1<repeat count=100>0</repeat>
      Contact: <sip:user@host129.example.com>
        ;expires=280297596632815
      Content-Length: 0 12
   m=video 3227 RTP/AVP 31
   a=rtpmap:31 LPC

2.14     200 OK

3.1.2.5 Response scalar fields with Broadcast Via Header overlarge values

   This message 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 response with legal range for this field).

   o  The Warning field has a 2nd Via header of 255.255.255.255.

   On warning-value with more than 3 digits

   An element receiving this response, the top Via header response will simply discard it.

      Message Details :

      SIP/2.0 503 Service Unavailable
      Via: SIP/2.0.TCP host129.example.com;branch=z0hG4bKzzxdiwo34sw
      To: <sip:user@example.com>
      From: <sip:other@example.net>;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 stripped and the
   packet forwarded.  Since a request with an unterminated quote in the next address is display name of
   the broadcast address,
   it causes 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 packet
   message. Such an element needs to be broadcast onto the network. A smart server
   should ignore packets with 2nd Via headers take care that are 255.255.255.255
   or 127.0.0.1. At the very least it should not crash. makes a
   reasonable inference when it encounters

      To: "Mr J. User <sip:j.user@example.com> <sip:realj@example.net>

      Message Details :

      INVITE sip:user@example.com SIP/2.0 200 OK
   Via: SIP/2.0/UDP 135.180.130.57;branch=0
   Via: SIP/2.0/UDP 255.255.255.255;branch=0
      To: "Mr. J. User <sip:j.user@example.com>
      From: sip:caller@example.net;tag=93334
      Max-Forwards: 70 10
      Call-ID: 0384840201@10.1.1.1 0ha0isndaksdj
      Contact: <sip:caller@host59.example.net>
      CSeq: 0 8 INVITE
   From: sip:user@company.com;tag=11141343
   To: sip:user@university.edu;tag=2229
      Via: SIP/2.0/UDP 192.0.2.59:5050;branch=z9hG4bKkdjuw39234
      Content-Type: application/sdp
      Content-Length: 153

      v=0
                      SIP Torture Test Messages           August 2002
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.15
      s=-
      c=IN IP4 224.2.17.12/127 192.0.2.15
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.15     INVITE with Invalid Via and Contact Headers

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 the Via and Contact headers incorrect. They
   contain additional semicolons and commas without parameters or
   values.

   The server should respond this error with a
   400 Bad Request error. 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:user@company.com <sip:user@example.com> SIP/2.0
      To: sip:j.user@company.com sip:user@example.com
      From: sip:caller@university.edu;tag=134161461246 sip:caller@example.net;tag=39291
      Max-Forwards: 7 23
      Call-ID: 0ha0isndaksdj@10.0.0.1 1@192.0.2.5
      CSeq: 8 1 INVITE
      Via: SIP/2.0/UDP 135.180.130.133;;,; 192.0.2.5
      Contact: "" <> ;,"Joe" <sip:joe@org.org>;;,,;; <sip:caller@host5.example.net>
      Content-Type: application/sdp
      Content-Length: 160

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.5
      s=-
      c=IN IP4 135.180.130.88
   t=0 192.0.2.5
      t=3149328700 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.16     INVITE with Incorrect Content-Length Header

3.1.2.8 Malformed SIP Request-URI (embedded LWS)

   This is a request message with a Content Length that is much larger
   than the length of the body.

   When sent UDP, INVITE has illegal LWS within the server Request-URI.

   An element receiving this request should respond with an error. With TCP,
   there's a 400 Bad
   Request.

   An element could attempt to ignore the embedded LWS for those schemes
   (like sip) where that would not much you can do but wait...

                      SIP Torture Test Messages           August 2002 introduce ambiguity.

      Message Details :

      INVITE sip:user@company.com sip:user@example.com; lr SIP/2.0
   Max-Forwards: 80
      To: sip:j.user@company.com sip:user@example.com;tag=3xfe-9921883-z9f
      From: sip:caller@university.edu;tag=93942939o2 sip:caller@example.net;tag=231413434
      Max-Forwards: 5
      Call-ID: 0ha0isndaksdj@10.0.0.1 asdfasdoijweoi2323-asdfwern23-asd8ia0swn34rk423
      CSeq: 8 2130706432 INVITE
      Via: SIP/2.0/UDP 135.180.130.133 192.0.2.1:5060;branch=z9hG4bKkdjuw2395
      Contact: <sip:caller@host1.example.net>
      Content-Type: application/sdp
      Content-Length: 9999 160

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.1
      s=-
      c=IN IP4 135.180.130.88
   t=0 192.0.2.1
      t=3149328700 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.17     INVITE with Invalid Value for Content-Length

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 a acceptable to reject this request message with a negative value for Content-Length.

   The server should respond with an error. 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@company.com  sip:user@example.com  SIP/2.0
      Max-Forwards: 254 8
      To: sip:j.user@company.com sip:user@example.com
      From: sip:caller@university.edu;tag=3 sip:caller@example.net;tag=8814
      Call-ID: 0ha0isndaksdj@10.0.0.1 2304u0qwsdfknq234oi243099adsdfnawe3@example.com
      CSeq: 8 1893884 INVITE
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw host1.example.com;branch=z9hG4bKkdjuw3923
      Contact: <sip:caller@host1.example.net>
      Content-Type: application/sdp
      Content-Length: -999 151

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.1
      s=-
      c=IN IP4 135.180.130.88 192.0.2.1
      t=0 0
                      SIP Torture Test Messages           August 2002
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.18     INVITE with Garbage after Message Body

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 a acceptable to reject this request message with garbage after as malformed. An element that
   is liberal in what it accepts may ignore these extra SP characters
   while processing the end of request. If the SDP
   included element forwards the request, it
   must not include these extra SP characters in the body.

   The servers should reject messages it sends.

      Message Details :

      OPTIONS sip:remote-target@example.com SIP/2.0<hex>2020</hex>
      Via: SIP/2.0/TCP host1.examle.com;branch=z9hG4bK299342093
      To: <sip:remote-target@example.com>
      From: <sip:local-resource@example.com>;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 as with a 400 Bad
   Request. An element could choose to be liberal in what it accepts and
   ignore the body escaped headers. If the element is longer than a proxy, the
   Content-Length. 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@company.com sip:user@example.com?Route=%3Csip:example.com%3E SIP/2.0
      To: sip:j.user@company.com sip:user@example.com
      From: sip:caller@university.edu;tag=3223 sip:caller@example.net;tag=341518
      Max-Forwards: 7
      Contact: <sip:caller@host39923.example.net>
      Call-ID: 0ha0isndaksdj@10.0.0.1 23940-asdfhj-aje3br-234q098w-fawerh2q-h4n5
      CSeq: 8 149209342 INVITE
      Via: SIP/2.0/UDP 135.180.130.133 host-of-the-hour.example.com;branch=z9hG4bKkdjuw
      Content-Type: application/sdp
      Content-Length: 138 151

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.1
      s=-
      c=IN IP4 135.180.130.88 192.0.2.1
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC
   asdpasd08asdsdk:;;asd
    a0sdjhg8a0''...'';;;;

2.19     INVITE with Error in Display Name

3.1.2.12 Invalid timezone in To Header 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 with as malformed (though an unterminated quote in
   element shouldn't do that unless the display name contents of the To field.

   The server can either return an error, or proxy 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 is
   successful parsing without wasn't going to use the terminating quote.

                      SIP Torture Test Messages           August 2002 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@company.com sip:user@example.com SIP/2.0
      To: "Mr. J. User <sip:j.user@company.com> sip:user@example.com
      From: sip:caller@university.edu;tag=93334 sip:caller@example.net;tag=2234923
      Max-Forwards: 10 70
      Call-ID: 0ha0isndaksdj@10.0.0.1 239423mnsadf3j23lj42--sedfnm234
      CSeq: 8 1392934 INVITE
      Via: SIP/2.0/UDP 135.180.130.133:5050;branch=z9hG4bKkdjuw 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: 138 151

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.5
      s=-
      c=IN IP4 135.180.130.88 192.0.2.5
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.20     INVITE with a Semicolon-Separated Parameter

3.1.2.13 Failure to enclose name-addr URI in the "user" Part <>

   This REGISTER request is malformed. The SIP URI contained in the
   Contact Header field has an INVITE 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 semicolon-separated parameter 400 Bad Request. An element choosing to be liberal in
   the "user" part.

   Outbound proxies should direct what it appropriately.
   accepts could infer the angle brackets since there is no ambiguity in
   this example. In general, that won't be possible.

      Message Details

   INVITE sip:user;par=u%40h.com@company.com :

      REGISTER sip:example.com SIP/2.0
      To: sip:j_user@company.com sip:user@example.com
      From: sip:caller@university.edu;tag=33242 sip:user@example.com;tag=998332
      Max-Forwards: 3 70
      Call-ID: 0ha0isndaksdj@10.1.1.1 k345asrl3fdbv@10.0.0.1
      CSeq: 8 INVITE 1 REGISTER
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw

2.21     INVITE with Illegal Enclosing of Request-URI  in "<>" 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 INVITE request is illegal because malformed since the Request-URI has been enclosed
   within addr-spec in "<>".

                      SIP Torture Test Messages           August 2002

   An intelligent server may be able the To header field
   contains spaces. Parsers receiving this request must not break. It is
   reasonable to deal with reject this and fix up
   athe Request-URI if acting as request with a Proxy. If not it should respond 400
   with an appropriate reason phrase. Bad Request response.
   Elements attempting to be liberal may ignore the spaces.

      Message Details

   INVITE <sip:user@company.com> :

      OPTIONS sip:user@example.org SIP/2.0
   To: sip:user@company.com
   From: sip:caller@university.edu;tag=39291
   Max-Forwards: 23
   Call-ID: 1@10.0.0.1
   CSeq: 1 INVITE
      Via: SIP/2.0/UDP 135.180.130.133
   Content-Type: host4.example.com:5060;branch=z9hG4bKkdju43234
      Max-Forwards: 70
      From: "Bell, Alexander" <sip:a.g.bell@example.com>;tag=433423
      To: "Watson, Thomas" < sip:t.watson@example.org >
      Call-ID: sdf0234n2nds0a099u23h3hnnw009cdkne3
      Accept: application/sdp
   Content-Length: 174

   v=0
   o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=-
   c=IN IP4 135.180.130.88
   t=3149328700 0
   m=audio 492170 RTP/AVP
      CSeq: 3923239 OPTIONS
      l: 0 12
   m=video 3227 RTP/AVP 31
   a=rtpmap:31 LPC

2.22     INVITE with Illegal LWS within Elements of Request-URI

3.1.2.15 Non-token characters in display-name

   This INVITE has illegal LWS within OPTIONS request is malformed since  the SIP URI. 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 intelligent server element may be able attempt to deal with this be liberal in what it receives and fix up infer
   the Request-URI if acting as a Proxy. 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 respond 400
   with an appropriate reason phrase. be simply rejected.

      Message Details

   INVITE sip:user@company.com; transport=udp :

      OPTIONS sip:t.watson@example.org SIP/2.0
   To: sip:user@company.com
      Via:     SIP/2.0/UDP c.example.com:5060;branch=z9hG4bKkdjuw
      Max-Forwards:      70
      From: sip:caller@university.edu;tag=231413434    Bell, Alexander <sip:a.g.bell@example.com>;tag=43
      To:      Watson, Thomas <sip:t.watson@example.org>
      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: 5     70
      From:    A. Bell <sip:a.g.bell@example.com>;tag=qweoiqpe
      To:      T. Watson <sip:t.watson@example.org>
      Call-ID: 2@10.0.0.1 31417@c.example.com
      CSeq:    1 INVITE
   Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
   Content-Type: application/sdp
   Content-Length: 174
                      SIP Torture Test Messages           August 2002

   v=0
   o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=-
   c=IN IP4 135.180.130.88
   t=3149328700 0
   m=audio 492170 RTP/AVP OPTIONS
      l: 0 12
   m=video 3227 RTP/AVP 31
   a=rtpmap:31 LPC

2.23     INVITE with illegal >1 SP between elements of Request URI

3.1.2.17 Start line and CSeq method mismatch

   This INVITE request has illegal >1 SP between elements of mismatching values for the Request-URI.

   An intelligent server may be able to deal with this method in the start line
   and fix up the Request-URI if acting as a Proxy. If not it should CSeq header field. Any element receiving this request will
   respond 400 with an appropriate reason phrase. a 400 Bad Request.

      Message Details

   INVITE sip:user@company.com :

      OPTIONS sip:user@example.com SIP/2.0
   Max-Forwards: 8
      To: sip:user@company.com sip:j.user@example.com
      From: sip:caller@university.edu;tag=8814 sip:caller@example.net;tag=34525
      Max-Forwards: 6
      Call-ID: 3@10.0.0.1 0ha0isndaksdj0234sxdfl3
      CSeq: 1 8 INVITE
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
   Content-Type: application/sdp
   Content-Length: 174

   v=0
   o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=-
   c=IN IP4 135.180.130.88
   t=0 0
   m=audio 492170 RTP/AVP host.example.com;branch=z9hG4bKkdjuw
      l: 0 12
   m=video 3227 RTP/AVP 31
   a=rtpmap:31 LPC

2.24     INVITE

3.1.2.18 Unknown Method with a legal SIP URI containing escaped characters CSeq method mismatch

   This INVITE is legal and message has an unknown method, and a Request-URI CSeq method tag which does
   not match it.

   Any element receiving this response will should respond with a SIP URI containing
   escaped characters.

                      SIP Torture Test Messages           August 2002 501
   Not Implemented. A 400 Bad Request is also acceptable, but choosing a
   501 (particularly at proxies) has better future-proof
   characteristics.

      Message Details

   INVITE sip:sip%3Auser%40example.com@company.com;other-param=summit :

      NEWMETHOD sip:user@example.com SIP/2.0
      To: sip:user@company.com sip:j.user@example.com
      From: sip:caller@university.edu;tag=938 sip:caller@example.net;tag=34525
      Max-Forwards: 87 6
      Call-ID: 4@10.0.0.1 0ha0isndaksdj0234sxdfl3
      CSeq: 1 8 INVITE
      Contact: <sip:caller@host.example.net>
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw host.example.net;branch=z9hG4bKkdjuw
      Content-Type: application/sdp
   Content-Length: 174
      l: 139

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=- 192.0.2.1
      c=IN IP4 135.180.130.88
   t=0 0 192.0.2.1
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.25     INVITE with the illegal use of escaped headers in Request-URI

3.1.2.19 Overlarge response code

   This INVITE is illegal as it the Request-URI contains response has a SIP URI
   containing
   escaped headers. response code larger than 699. An intelligent server may be liberal enough to accept this. A server
   acting as a proxy element
   receiving this response should remove the escaped header before processing. simply drop it.

      Message Details

   INVITE sip:user@company.com?Route=%3Csip:sip.example.com%3E :

      SIP/2.0
   To: sip:user@company.com
   From: sip:caller@university.edu;tag=341518
   Max-Forwards: 7 4294967301 better not break the receiver
      Via: SIP/2.0/UDP 192.0.2.105;branch=z9hG4bK2398ndaoe
      Call-ID: 5@10.0.0.1 asdof3uj203asdnf3429uasdhfas3ehjasdfas9i
      CSeq: 1 353494 INVITE
   Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
   Content-Type: application/sdp
      From: <sip:user@example.com>;tag=39ansfi3
      To: <sip:user@example.edu>;tag=902jndnke3
      Content-Length: 174

   v=0
   o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=-
                      SIP Torture Test Messages           August 2002

   c=IN IP4 135.180.130.88
   t=0 0
   m=audio 492170 RTP/AVP 0 12
   m=video 3227 RTP/AVP 31
   a=rtpmap:31 LPC

2.26     INVITE containing an unknown scheme in the Request URI
      Contact: <sip:user@host105.example.com>

3.2 Transaction layer semantics

   This INVITE section contains tests that exercise an unknown URI scheme in 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 Request-URI. z9hG4bK prefix to the branch parameter,
   but it provides no identifier. A server should reject parser must not break when receiving
   this message message. An element receiving this request could reject the
   request with a 400 response plus an
   appropriate reason phrase despite being able Response (preferably statelessly, as other
   requests from the source are likely to also have a malformed branch
   parameter), or it could fall back to understand 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

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 as fields.

   An element receiving this message must not break because of the
   missing information. Ideally, it will respond with a SIP URI. 400 Bad Request
   error.

      Message Details :

      INVITE name:user sip:user@example.com SIP/2.0
   To: sip:user@company.com
   From: sip:caller@university.edu;tag=384
   Max-Forwards: 3
   Call-ID: 6@10.0.0.1
      CSeq: 1 193942 INVITE
      Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw 192.0.2.95;branch=z9hG4bKkdjuw
      Content-Type: application/sdp
   Content-Length: 174
      l: 153

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.95
      s=-
      c=IN IP4 135.180.130.88 192.0.2.95
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.27     OPTIONS

3.3.2 Request-URI with no LWS between display name and < 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 legal despite there being no LWS between
   an error. Despite the display name 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
      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 From header. 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 sip:user@company.com 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
                      SIP Torture Test Messages           August 2002
      To: sip:user@company.com isbn:2983792873
      From: "caller"<sip:caller@example.com>;tag=323
   Max-Forwards: 70 <http://www.example.com>;tag=3234233
      Call-ID: 1234abcd@10.0.0.1 0ha0isndaksdj@hyphenated-host.example.com
      CSeq: 1 OPTIONS 234902 REGISTER
      Max-Forward: 70
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw

2.28     OPTIONS with extran LWS between display name 192.0.2.21:5060;branch=z9hG4bKkdjuw
      Contact: <name:John_Smith>
      l: 0

3.3.5 Proxy-Require and < Require

   This OPTIONS request is legal despite there being extra LWS between
   the display name 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 From header. element is responding.

      Message Details :

      OPTIONS sip:user@company.com sip:user@example.com SIP/2.0
      To: sip:user@company.com sip:j_user@example.com
      From: "caller"    <sip:caller@example.com>;tag=32
   Max-Forwards: 70 sip:caller@example.net;tag=242etr
      Max-Forward: 6
      Call-ID: 1234abcd@10.0.0.1 0ha0isndaksdj
      Require: nothingSupportsThis, nothingSupportsThisEither
      Proxy-Require: noProxiesSupportThis, norDoAnyProxiesSupportThis
      CSeq: 2 8 OPTIONS
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw

2.29     INVITE with an illegal SIP Date format. SIP/2.0/TLS fold-and-staple.example.com;branch=z9hG4bKkdjuw
      Content-Length: 0

3.3.6 Unknown Content-Type

   This INVITE is illegal as it request contains a non GMT time zone in the SIP
   Date header.

   An intelligent server may be able to fix body of unknown type. It is
   syntactically valid. A parser must not fail when receiving it.

   A proxy receiving this up and correct the time
   to GMT. Alternatively request would process it just like any other
   INVITE. An endpoint receiving this message may illicit a 400 response request would reject it with an
   appropriate reason phrase. a 415
   Unsupported Media Type error.

      Message Details :

      INVITE sip:user@company.com sip:user@example.com SIP/2.0
      Contact: <sip:caller@host5.example.net>
      To: sip:user@company.com sip:j.user@example.com
      From: sip:caller@university.edu;tag=2 sip:caller@example.net;tag=8392034
      Max-Forwards: 70
      Call-ID: 7@10.0.0.1 0ha0isndaksdjadsfij34n23d
      CSeq: 1 235448 INVITE
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
   Date: Fri, 01 Jan 2010 16:00:00 EST somehost.example.com;branch=z9hG4bKkdjuw
      Content-Type: application/sdp application/unknownformat
      Content-Length: 174
                      SIP Torture Test Messages           August 2002

   v=0
   o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=-
   c=IN IP4 135.180.130.88
   t=0 0
   m=audio 492170 RTP/AVP 0 12
   m=video 3227 RTP/AVP 31
   a=rtpmap:31 LPC

2.30     INVITE 40

      <audio>
       <pcmu port="443"/>
      </audio>

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 Passed Expries Time

   This is a legal INVITE but 401, issuing a new challenge with a scheme
   it understands.

   Endpoints choosing not to act as registrars will simply reject the message content has long since
   expired.
   request. A server should respond 408 (Timeout). 405 Method Not Allowed is appropriate.

      Message Details

   INVITE sip:user@company.com :

      REGISTER sip:example.com SIP/2.0
      To: sip:user@company.com sip:j.user@example.com
      From: sip:caller@university.edu;tag=3843 sip:j.user@example.com;tag=87321hj23128
      Max-Forwards: 70 8
      Call-ID: 8@10.0.0.1 0ha0isndaksdj
      CSeq: 1 INVITE 9338 REGISTER
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw
   Expires: Thu, 01 Dec 1994 16:00:00 GMT
   Content-Type: application/sdp
   Content-Length: 174

   v=0
   o=mhandley 29739 7272939 IN IP4 126.5.4.3
   s=-
   c=IN IP4 135.180.130.88
   t=0 0
   m=audio 492170 RTP/AVP 0 12
   m=video 3227 RTP/AVP 31
   a=rtpmap:31 LPC

2.31     INVITE with Max-Forwards Set to Zero

   This is SIP/2.0/TCP 192.0.2.253;branch=z9hG4bKkdjuw
      Authorization: NoOneKnowsThisScheme opaque data here
      Content-Length:0

3.3.8 Multiple values in single value required fields

   The message contains a legal SIP request with the multiple Call-ID, To, From,
   Max-Forwards header set to zero.

   A proxy or gateway should and CSeq values. An element receiving this request must
   not forward the break.

   An element receiving this request and would respond 483
   (Too Many Hops).

                      SIP Torture Test Messages           August 2002 with a 400 Bad
   Request error.

      Message Details :

      INVITE sip:user@company.com SIP/2.0
   To: sip:user@company.com
   From: sip:caller@university.edu;tag=3ghsd41
   Call-ID: 9@10.0.0.1
   CSeq: 1 INVITE
      Contact: <sip:caller@host25.example.net>
      Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 192.0.2.25;branch=z9hG4bKkdjuw
      Max-Forwards: 0 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
   Content-Length: 174
      l: 155
      Contact: <sip:caller@host36.example.net>
      Max-Forwards: 5

      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.25
      s=-
      c=IN IP4 135.180.130.88 192.0.2.25
      t=0 0
      m=audio 492170 RTP/AVP 0 12
      m=video 3227 RTP/AVP 31
      a=rtpmap:31 LPC

2.32     REGISTER with a Escaped Header in a Legal SIP URI of a Contact

   This is a legal REGISTER message where the Contact header contains a
   SIP URI with an escaped

3.3.9 Multiple Content-Length values

   Multiple conflicting Content-Length header within it.

   Message Details

   REGISTER sip:company.com SIP/2.0
   To: sip:user@company.com
   From: sip:user@company.com;tag=8
   Max-Forwards: 70
   Contact: sip:user@host.company.com
   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>

2.33     REGISTER with a Escaped Header field values appear in
   this request.

   From a Illegal SIP URI of a Contact

   This framing perspective, this situation is equivalent to an illegal
   invalid Content-Length value (or no value at all).

   An element receiving this message as the REGISTER request contains a SIP
                      SIP Torture Test Messages           August 2002

   URI should respond with an escaped header but it 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 enclosed in  <>

   A server recoverable and the connection should respond 400 with an appropriate reason phrase. be closed.

      Message Details

   REGISTER sip:company.com :

      OPTIONS sip:user@example.com SIP/2.0
      Via: SIP/2.0/UDP host5.example.net;branch=z9hG4bK293423
      To: sip:user@company.com sip:user@example.com
      From: sip:user@company.com;tag=998332
   Max-Forwards: 70
   Contact: sip:user@host.company.com sip:other@example.net;tag=3923942
      Call-ID: k345asrl3fdbv@10.0.0.1 234asdfhn2323orihawfdoa3o4r52o3irsdf
      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

2.34     INVITE 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 Long Values in Headers broadcast Via header field value

   This message is a legal response with a 2nd Via header field value's
   sent-by containing 255.255.255.255. The message that contains long values in many headers.

   Message Details

   INVITE sip:user@company.com SIP/2.0
   To: "I have is well formed -
   parsers must not fail when receiving it.

   Per [RFC3261] an endpoint receiving this message should simply
   discard it.

   If a user name of extreme proportion"
   <sip:user@company.com:6000;other-
   param=1234567890somethingelselong1234567890>
   From: sip:caller@university.edu;tag=12481841982424
   Call-ID:
   kl24ahsd546folnyt2vbak9sad98u23naodiunzds09a3bqw0sdfbsk34poouymnae004
   3nsed09mfkvc74bd0cuwnms05dknw87hjpobd76f
   CSeq: 1 INVITE
   P-My-State: sldkjflzdsfaret0803adgaasd0afds0asdaasd
   Via: SIP/2.0/TCP sip33.example.com
   Via: SIP/2.0/TCP sip32.example.com
   Via: 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
   Via: SIP/2.0/TCP sip22.example.com
   Via: SIP/2.0/TCP sip21.example.com
                      SIP Torture Test Messages           August 2002

   Via: SIP/2.0/TCP sip20.example.com
   Via: 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 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/TCP sip1.example.com SIP/2.0/UDP 192.0.2.198;branch=z9hG4bK1324923
      Via: SIP/2.0/TCP
   host.example.com;received=135.180.130.133;branch=C1C3344E2710000000E2
   99E568E7potato10potato0potato0 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: <sip:user@host28.example.com>
      v=0
      o=mhandley 29739 7272939 IN IP4 126.5.4.3 192.0.2.198
      s=-
      c=IN IP4 135.180.130.88 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

2.35     OPTIONS with multiple headers.

3.3.11 Max-Forwards of zero

   This is an illegal and badly mangled message. a legal SIP request with the Max-Forwards header field value
   set to zero.

   A server proxy should not forward the request and respond 400 with an appropriate reason phrase 483 (Too Many
   Hops). An endpoint should process the request as if it
   can. It may just drop this message. the Max-Forwards
   field value were still positive.

      Message Details :

      OPTIONS sip:135.180.130.133 sip:user@example.com SIP/2.0
   Via: SIP/2.0/UDP company.com:5604
   Max-Forwards: 70
                      SIP Torture Test Messages           August 2002

   From: sip:iuser@company.com;tag=74345345
   To: sip:user@135.180.130.133
   Call-ID: 1804928587@company.com
   CSeq: 1 OPTIONS
   Expires: 0 0l@company.com
      To: sip:user@135.180.130.133 sip:user@example.com
      From: sip:caller@example.net;tag=3ghsd41
      Call-ID: 1804928587@company.com 2304sadjfasdlfnm2o2l43r5u0asdfas
      CSeq: 1 39234321 OPTIONS
   Contact: sip:host.company.com
   Expires: 0xpires: 0sip:host.company.com
   Expires: 0
   Contact: sip:host.company.com

2.36     INVITE with large number of SDP attributes and telephone subscriber
    Request-URI

   This is a legal message with a large number of SDP attributes and a
   long telephone subscriber Request-URI

   Message Details

   INVITE sip:+19725552222;phone-
   context=name%40domain;new=user?%22Route%3a%20X%40Y%3bZ=W%22@gw1.atlan
   ta.com;user=phone SIP/2.0
      Via: SIP/2.0/UDP iftgw.biloxi.com:5060;branch=z9hG4bKjeefr3 host1.example.com;branch=z9hG4bKkdjuw2349i
      Max-Forwards: 70
   From:
   <sip:+13035551111@ift.client.atlanta.com;user=phone>;tag=332lflke
   To: sip:+16555552222@ss1.atlanta.com;user=phone
   Call-ID: 1717@ift.client.atlanta.com
   CSeq: 56 INVITE
   Content-Type: application/sdp 0
      Content-Length: 320

   v=0
   o=faxgw1 2890844527 2890844527 IN IP4 iftgw.biloxi.com
   s=-
   c=IN IP4 iftmg.biloxi.com
   t=0 0
   m=image 49172 udptl t38
   a=T38FaxVersion:0
   a=T38maxBitRate:14400
   a=T38FaxFillBitRemoval:0
   a=T38FaxTranscodingMMR:0
   a=T38FaxTranscodingJBIG:0
   a=T38FaxRateManagement:transferredTCF
                      SIP Torture Test Messages           August 2002

   a=T38FaxMaxBuffer:260
   a=T38FaxUdpEC:t38UDPR

2.37

3.3.12 REGISTER with a contact parameter. header parameter

   This REGISTER register request contains a contact where the 'user' 'unknownparam'
   parameter should must be interpreted as being a contact-param and not a
   url-param.

   The register

   This REGISTER should succeed but a subsequent retrieval of the
   registration succeed. The response must not include "user=phone"
   "unknownparam" as a url-parameter. 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 :

      REGISTER sip:bell-tel.com sip:example.com SIP/2.0
      Via: SIP/2.0/UDP saturn.bell-tel.com:5060;branch=z9hG4bKkdjuw saturn.example.com:5060;branch=z9hG4bKkdjuw
      Max-Forwards: 70
      From: sip:watson@bell-tel.com;tag=DkfVgjkrtMwaerKKpe sip:watson@example.com;tag=DkfVgjkrtMwaerKKpe
      To: sip:watson@bell-tel.com sip:watson@example.com
      Call-ID: 70710@saturn.bell-tel.com 70710@saturn.example.com
      CSeq: 2 REGISTER
      Contact: sip:+19725552222@gw1.atlanta.com;user=phone

2.38 sip:+19725552222@gw1.example.net;unknownparam
      l: 0

3.3.13 REGISTER with a url parameter. parameter

   This register request contains a contact where the 'user'parameter is a url-
   param. URI has an unknown
   parameter.

   The register should succeed and a subsequent retrieval of the
   registration must include "user=phone" "unknownparam" as a url-parameter.

   Message Details

   REGISTER sip:bell-tel.com SIP/2.0
   Via: SIP/2.0/UDP saturn.bell-tel.com:5060;branch=z9hG4bKkdjuw
   Max-Forwards: 70
   From: sip:watson@bell-tel.com;tag=838293
   To: sip:watson@bell-tel.com
   Call-ID: 70710@saturn.bell-tel.com
   CSeq: 3 REGISTER
   Contact: <sip:+19725552222@gw1.atlanta.com;user=phone>

2.39     INVITE with an Unquoted Display Name Containing Multiple Tokens
                      SIP Torture Test Messages           August 2002

   This is a legal INVITE where the To and From header contain display
   names that contain multiple tokens but are unquoted. a url-parameter.

   Behavior is the same, of course, for any known url-parameter names.

      Message Details

   INVITE sip:t.watson@ieee.org :

      REGISTER sip:example.com SIP/2.0
      Via: SIP/2.0/UDP c.bell-tel.com:5060;branch=z9hG4bKkdjuw saturn.example.com:5060;branch=z9hG4bKkdjuw
      Max-Forwards: 70
      From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=459843 sip:watson@example.com;tag=838293
      To:      T. Watson <sip:t.watson@ieee.org> sip:watson@example.com
      Call-ID: 31414@c.bell-tel.com 70710@saturn.example.com
      CSeq:    1 INVITE

2.40     INVITE 3 REGISTER
      Contact: <sip:+19725552222@gw1.example.net;unknownparam>
      l: 0

3.3.14 REGISTER with an Unquoted Display Name Containg Non-Token Characters a url escaped header

   This is register request contains a contact where the URI has an illegal invite at escaped
   header.

   The register should succeed and a subsequent retrieval of the display names
   registration must include the escaped Route header in the To and From
   headers contain non-token characters but are unquoted.

   A server may be intelligent enough to cope with contact URI
   for this but may also
   return a 400 response with an appropriate reason phrase. binding.

      Message Details

   INVITE sip:t.watson@ieee.org :

      REGISTER sip:example.com SIP/2.0
   Via:     SIP/2.0/UDP c.bell-tel.com:5060;branch=z9hG4bKkdjuw
      To: sip:user@example.com
      From: sip:user@example.com;tag=8
      Max-Forwards: 70
   From:    Bell, Alexander <sip:a.g.bell@bell-tel.com>;tag=43
   To:      Watson, Thomas <sip:t.watson@ieee.org>
      Call-ID: 31415@c.bell-tel.com k345asrl3fdbv@192.0.2.1
      CSeq:    1 INVITE

2.41     INVITE with Unknown (Higher) Protocol Version in Start Line 14398234 REGISTER
      Via: SIP/2.0/UDP host5.example.com;branch=z9hG4bKkdjuw
      M: <sip:user@example.com?Route=%3Csip:sip.example.com%3E>
      L:0

3.3.15 Unacceptable Accept offering

   This is request indicates the response must contain a body in an illegal INVITE as unknown
   type. In particular, since the SIP Protocol version is unknown. Accept header field does not contain
   application/sdp, the response may not contain an SDP body. The server should
   recipient of this request could respond to with a 406 Not Acceptable
   with a Warning/399 indicating that a response cannot be formulated in
   the request formats offered in the Accept header field. It is also
   appropriate to respond with a bad version error. 400 Bad Request since all SIP UAs
   supporting INVITE are required to support application/sdp.

      Message Details :

      INVITE sip:t.watson@ieee.org SIP/7.0
   Via:     SIP/2.0/UDP c.bell-tel.com;branch=z9hG4bKkdjuw
   Max-Forwards:     70
                      SIP Torture Test Messages           August 2002

   From:    A. Bell <sip:a.g.bell@bell-tel.com>;tag=qweoiqpe sip:user@example.com SIP/2.0
      To:      T. Watson <sip:t.watson@ieee.org> sip:j_user@example.com
      Contact: <sip:caller@host15.example.net>
      From: sip:caller@example.net;tag=234
      Max-Forwards: 5
      Call-ID: 31417@c.bell-tel.com 0ha0isndaksdj9342dasdd
      Accept: text/nobodyKnowsThis
      CSeq:    1 8 INVITE

2.42
      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

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. 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@biloxi.com sip:UserB@example.com SIP/2.0
      Via: SIP/2.0/UDP iftgw.biloxi.com iftgw.example.com
      From: <sip:+13035551111@ift.client.atlanta.com;user=phone>;tag=93752 <sip:+13035551111@ift.client.example.net;user=phone>
      Record-Route: <sip:UserB@biloxi.com;maddr=ss1.wcom.com> <sip:UserB@example.com;maddr=ss1.example.com>
      To: sip:+16505552222@ss1.atlanta.com;user=phone sip:+16505552222@ss1.example.net;user=phone
      Call-ID: 1717@ift.client.atlanta.com 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

   Since this

   This document represents presents NON NORMATIVE examples of SIP session
   establishment, the
   establishment. The security considerations in RFC 3261 [2] [RFC3261] apply.

References

   1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   2 J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
    J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
    Session Initiation Protocol", RFC 3261, June 2002.

   3 J.Rosenberg

   Parsers must carefully consider edge conditions and H.Schulzrinne, "An Offer/Answer Model
    with SDP", malicious input
   as part of their design. Attacks on many Internet Engineering Task Force, RFC 3264, April 2002.

                      SIP Torture Test Messages           August 2002

Acknowledgments

   Thanks systems use crafted
   input to Rohan Mahy, Adam Roach, Gonzalo Camarillo, Cullen Jennings,
   and Tom Taylor for their detailed comments during cause implementations to behave in undesirable ways. Many of
   the final final
   review.  Thanks messages in this draft are designed to Vijay Gurbani stress a parser
   implementation at points traditionally used for his comments.

   The authors wish such attacks. This
   document does not, however, attempt to thank Neil Deason for his additions be comprehensive. It should be
   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
   Torture Test messages and Kundan Singh for performing parser
   validation in this document should be considered new.
       They are either new additions or major revisions of messages. 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 final review of earlier versions of this call flows document:
   Aseem Agarwal, Rafi Assadi, Gonzalo Camarillo, Ben Campbell, Cullen
   Jennings, Vijay Gurbani, Sunitha Kumar, Rohan Mahy, Jon Peterson,
   Marc Petit-Huguenin, Vidhi Rastogi, and Adam Roach, Bodgey Yin Shaohua.

   The authors also wish Shaohua
   and Tom Taylor.

   Thanks to thank the Neil Deason for contributing several messages and Kundan
   Singh for performing parser validation of messages in earlier
   versions..

   The following individuals for their
   assistance: 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.

Author's

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
      WorldCom
   MCI
   100 South 4th Street
   St. Louis, MO  63102
      USA

   EMail:  alan.johnston@wcom.com alan.johnston@mci.com
   Jonathan Rosenberg
   dynamicsoft
      72 Eagle Rock Ave
      East Hanover,
   600 Lanidex Plaza
   Parsippany, NJ 07936
      USA  07052

   Phone: +1 973 952 5000
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net

   Henning Schulzrinne
      Dept.
   Columbia University
   Department of Computer Science
      Columbia University
   1214 Amsterdam Avenue Ave.
   New York, NY  10027
   USA
                      SIP Torture Test Messages           August 2002

   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.

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
   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
   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
   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
   AQA=
   -- END MESSAGE ARCHIVE --

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 Notice

   "Copyright (C) The Internet Society 2002. (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 assigns. 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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.