readme

SIP（Session Initiation Protocol）是由IETF定义

the messages in this directory are from henning's page at

	http://www.cs.columbia.edu/~hgs/sip/sipit/testmsg.html

the test messages are called textXX.txt where XX is the number from 1 to 42.
the results are kept in resultXX.txt.


Here is the text of that web page, copied for convenience:


                               SIP Test Messages

   The  files  in  here  are  test  messages  for SIP servers to exercise
   various  functions.  Contributed  by  Neil  Deason, Anders Kristensen,
   Jonathan Rosenberg, Henning Schulzrinne.

   SIP interoperabilty test event entrants are strongly encouraged to run
   these  tests.  In  particular entrants to advanced scenario testing at
   these events will be expected to have passed all torture tests.

[1]test1.txt

   This message is a correctly formatting SIP message. It contains:
     * line folding all over
     * escaped characters within quotes
     * LWS between colons, semicolons, headers, and other fields
     * both comma separated and separate listing of headers
     * mix or short and long form for the same header
     * unknown header field
     * unusual header ordering
     * nested comments
     * unknown parameters of a known header

[2]test2.txt

   This  message  tests  support  for  Proxy-Require and Require. It is a
   request  that contains both headers, listing new features. Proxies and
   clients  should  respond  with a 420 Bad Extension, and an Unsupported
   header listing these features.

[3]test3.txt

   This message contains unknown schemes in the Request URI, To, From and
   Contact  headers  of  a request. A server should probably return a not
   found error; but other behaviors are acceptable.

[4]test4.txt

   This  message  is  a  registration  request with an expiration year of
   2040.  This  makes  sure  that a server doesn't crash on seeing a date
   past  Y2038. The correct behavior is probably to limit the lifetime to
   some configured maximum.

[5]test5.txt

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

[6]test6.txt

   This  is a UAS test. It is a request that includes a body of a non-SDP
   type. The UAS should respond with an error.

[7]test7.txt

   This  request message contains a new method, NEWMETHOD. A proxy should
   forward  this using the same retransmission rules as OPTIONS or BYE. A
   UAS  should reject it with an error, and list the available methods in
   the response.

[8]test8.txt

   This  message is nearly identical to test7. It is a request with a new
   method,  but  with  a  CSeq  method  tag which does not match. A proxy
   should either respond with an error, or correct the method tag.

[9]test9.txt

   This  message  is  a  REGISTER  request  with an unknown authorization
   scheme.  The  server should do something reasonable, such as rejecting
   the request.

[10]test10.txt

   This   message   contains  two  requests,  separated  by  a  bunch  of
   whitespace.  Since  the  message  exceeds  the length indicated in the
   Content-Length  header,  the message should be rejected. (Multiple SIP
   requests per UDP packet are no longer allowed.)

[11]test11.txt

   This  message  contains  no  Call-ID,  From,  or To header. The server
   should not crash, and ideally should respond with an error.

[12]test12.txt

   The message contains a request with an extra Call-ID and To field. The
   server should not crash, and should ideally respond with an error.

[13]test13.txt

   This message contains an Expires header which has illegal values for a
   number of components, but otherwise is syntactically correct.

[14]test14.txt

   This  message  is a response with a 2nd Via header of 255.255.255.255.
   The  top  Via header will need to be modified to represent the address
   of  the  server.  On  receiving  this  response, the top Via header is
   stripped  and  the  packet  forwarded.  Since  the next address is the
   broadcast  address,  it  causes  the  packet  to be broadcast onto the
   network.  A  smart  server  should ignore packets with 2nd Via headers
   that are 255.255.255.255 or 127.0.0.1. At the very least it should not
   crash.

[15]test15.txt

   This  is  a  request  with the Via and Contact headers incorrect. They
   contain additional semicolons and commas without parameters or values.
   The server should respond with a Bad Request error.

[16]test16.txt

   This  is  a  request message with a Content Length that is much larger
   than  the length of the body. When sent UDP, the server should respond
   with an error. With TCP, there's not much you can do but wait...

[17]test17.txt

   This  is  a  request message with a negative value for Content-Length.
   The server should respond with an error.

[18]test18.txt

   This  is  a  request  message  with  garbage  after the end of the SDP
   included in the body. In fact, the server should treat this garbage as
   a  second  request.  However, it is not even close to a valid message.
   The  server  should therefore ignore it, and forward the first message
   normally.

[19]test19.txt

   This  is  a  request with an unterminated quote in the display name of
   the To field. The server can either return an error, or proxy it if it
   is successful parsing without the terminating quote.

[20]test20.txt

   This  is an INVITE request with a semicolon-separated parameter in the
   "user" part. Outbound proxies should direct it appropriately.
     _________________________________________________________________

   The  files  below  are  additional  test  messages  for SIP servers to
   exercise various functions. Comments and corrections should be sent to
   [21]Neil Deason.

[22]test21.txt

   This  INVITE  is  illegal  because  the  Request-URI has been enclosed
   within in "<>".

   An  intelligent  server  may  be able to deal with this and fix up the
   Request-URI  if  acting as a Proxy. If not it should respond 400  with
   an appropriate reason phrase.

[23]test22.txt

   This INVITE has illegal LWS within the SIP URL.

   An  intelligent  server  may  be able to deal with this and fix up the
   Request-URI if acting as a proxy. If not it should respond 400 with an
   appropriate reason phrase.

[24]test23.txt

   This INVITE has illegal >1 SP between elements of the Request-URI.

   An  intelligent  server  may  be able to deal with this and fix up the
   Request-URI if acting as a proxy. If not it should respond 400 with an
   appropriate reason phrase.

[25]test24.txt

   This  INVITE  is legal and has a Request-URI with a SIP URL containing
   escaped characters.

[26]test25.txt

   This  INVITE  is  illegal  as  it  the  Request-URI contains a SIP URL
   containing escaped headers.

   An  intelligent  server may be liberal enough to accept this. A server
   acting as a proxy should remove the escaped header before processing.

[27]test26.txt

   This INVITE contains an unknown URI scheme in the Request-URI.

   A  server  should  reject  this  message  with  a 400 response plus an
   appropriate  reason  phrase  despite  being  able to understand the To
   header as a SIP URL.

[28]test27.txt

   This  OPTIONS  request is legal despite there being no LWS between the
   display name and < in the From header.

[29]test28.txt

   This  OPTIONS  request  is legal despite there being extra LWS between
   the display name and < in the From header.

[30]test29.txt

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

   An  intelligent server may be able to fix this up and correct the time
   to  GMT. Alternatively this message may illicit a 400 response with an
   appropriate reason phrase.

[31]test30.txt

   This is a legal INVITE but the message content has long since expired.

   A server should respond 408 (Timeout).

[32]test31.txt

   This is a legal SIP request with the Max-Forwards header set to zero.

   A proxy or gateway should not forward the request and respond 483 (Too
   Many Hops).

[33]test32.txt

   This  is  a legal REGISTER message where the Contact header contains a
   SIP URL with an escaped header within it.

[34]test33.txt

   This  is an illegal message as the REGISTER request contains a SIP URL
   with an escaped header but it is not enclosed in <>

   A server should respond 400 with an appropriate reason phrase.

[35]test34.txt

   This is a legal message that contains long values in many headers.

[36]test35.txt

   This is an illegal and badly mangled message.

   A  server  should  respond 400 with an appropriate reason phrase if it
   can. It may just drop this message.

[37]test36.txt

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

[38]test37.txt

   This  REGISTER contains a contact where the 'user' parameter should be
   interpreted as being a contact-param and not a url-param. The register
   should succeed but a subsequent retrieval of the registration must not
   include "user=phone" as a url-parameter.

[39]test38.txt

   This  register  contains  a  contact  where  the 'user' parameter is a
   url-param.  The  register should succeed and a subsequent retrieval of
   the registration must include "user=phone" as a url-parameter.

[40]test39.txt

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

[41]test40.txt

   This  is  an  illegal  invite  at the display names in the To and From
   headers contain non-token characters but are unquoted. A server may be
   intelligent  enough  to  cope  with  this  but  may  also return a 400
   response with an appropriate reason phrase.

[42]test41.txt

   This  should  be rejected with 400. Section 4.1 lists SIP version as a
   literal  and  doesn't say anything about ignoring leading zeros. As an
   example  of  why rejecting it is a good idea, consider version numbers
   like 2.1 and 2.01 - they are unlikely to refer to the same version.

[43]test42.txt

   This is an illegal INVITE as the SIP Protocol version is unknown.

   The server should respond to the request with a bad version error.
     _________________________________________________________________

   Last updated Tue 03 Apr 2001 11:16:26 AM PDT by [44]Neil Deason
     _________________________________________________________________

   Last   updated  Tue  03  Apr  2001  11:16:26  AM  PDT  by  [45]Henning
   Schulzrinne
======================================================================

Copyright 2000-2003, Cisco Systems, Inc.
THE INFORMATION HEREIN IS PROVIDED ON AN "AS IS" BASIS, WITHOUT ANY
WARRANTIES OR REPRESENTATIONS, EXPRESS, IMPLIED OR STATUTORY, INCLUDING
WITHOUT LIMITATION, WARRANTIES OF NONINFRINGEMENT, MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.

$Id: README,v 1.3.2.1 2003/03/28 05:25:57 bko Exp $