torture-test.txt

一个著名的SIP协议栈

   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 
   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 
   Via: SIP/2.0/TCP sip1.example.com 
   Via: SIP/2.0/TCP 
   host.example.com;received=135.180.130.133;branch=C1C3344E2710000000E2
   99E568E7potato10potato0potato0 
   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 0 12 
   m=video 3227 RTP/AVP 31 
   a=rtpmap:31 LPC 
    
    
    
2.35     OPTIONS with multiple headers. 
    
   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. 
    
    
   Message Details 
    
   OPTIONS sip:135.180.130.133 SIP/2.0 
   Via: SIP/2.0/UDP company.com:5604 
   Max-Forwards: 70 
   From: sip:[e-mail];tag=74345345 
   To: sip:user@135.180.130.133 
   Call-ID: [e-mail] 
   CSeq: 1 OPTIONS 
   Expires: 0 [e-mail] 
   To: sip:user@135.180.130.133 
   Call-ID: [e-mail] 
   CSeq: 1 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:[phone];phone-
   context=name%40domain;new=user?%22Route%3a%20X%40Y%3bZ=[e-mail]
   ta.com;user=phone SIP/2.0 
   Via: SIP/2.0/UDP iftgw.biloxi.com:5060;branch=z9hG4bKjeefr3 
   Max-Forwards: 70 
   From: 
   <sip:[e-mail];user=phone>;tag=332lflke 
   To: sip:[e-mail];user=phone 
   Call-ID: [e-mail] 
   CSeq: 56 INVITE 
   Content-Type: application/sdp 
   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 
   a=T38FaxMaxBuffer:260 
   a=T38FaxUdpEC:t38UDPR 
    
    
    
2.37     REGISTER with a contact parameter. 
    
   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. 
    
   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:[e-mail];tag=DkfVgjkrtMwaerKKpe 
   To: sip:[e-mail] 
   Call-ID: [e-mail] 
   CSeq: 2 REGISTER 
   Contact: sip:[e-mail];user=phone 
    
    
    
2.38     REGISTER with a url parameter. 
    
   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. 
    
   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:[e-mail];tag=838293 
   To: sip:[e-mail] 
   Call-ID: [e-mail] 
   CSeq: 3 REGISTER 
   Contact: <sip:[e-mail];user=phone> 

2.39     INVITE with an Unquoted Display Name Containing Multiple Tokens 
 
   This is a legal INVITE where the To and From header contain display 
   names that contain multiple tokens but are unquoted. 
    
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   Via:     SIP/2.0/UDP c.bell-tel.com:5060;branch=z9hG4bKkdjuw 
   Max-Forwards:    70 
   From:    A. Bell <sip:[e-mail]>;tag=459843 
   To:      T. Watson <sip:[e-mail]> Call-ID: [e-mail] 
   CSeq:    1 INVITE 
    
    
    
2.40     INVITE with an Unquoted Display Name Containg Non-Token Characters 
    
   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. 
    
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   Via:     SIP/2.0/UDP c.bell-tel.com:5060;branch=z9hG4bKkdjuw 
   Max-Forwards:      70 
   From:    Bell, Alexander <sip:[e-mail]>;tag=43 
   To:      Watson, Thomas <sip:[e-mail]> Call-ID: [e-mail] 
   CSeq:    1 INVITE 
    
    
    
2.41     INVITE with Unknown (Higher) Protocol Version in Start Line 
    
   This is an illegal INVITE as the SIP Protocol version is unknown.  
    
   The server should respond to the request with a bad version error. 
    
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/7.0 
   Via:     SIP/2.0/UDP c.bell-tel.com;branch=z9hG4bKkdjuw 
   Max-Forwards:     70 
   From:    A. Bell <sip:[e-mail]>;tag=qweoiqpe 
   To:      T. Watson <sip:[e-mail]> Call-ID: [e-mail] 
   CSeq:    1 INVITE 
    
    
2.42     INVITE with RFC2543 syntax 
    
   This is a legal message per RFC 2543 which should be accepted by RFC 
   3261 elements which want to maintain backwards compatibility. 
    
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   Via: SIP/2.0/UDP iftgw.biloxi.com 
   From: <sip:[e-mail];user=phone>;tag=93752 
   Record-Route: <sip:[e-mail];maddr=ss1.wcom.com> To: sip:[e-mail];user=phone 
   Call-ID: [e-mail] 
   CSeq: 56 INVITE 
    
    
    
Security Considerations 
    
   Since this document represents NON NORMATIVE examples of SIP session 
   establishment, the security considerations in RFC 3261 [2] 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 and H.Schulzrinne, "An Offer/Answer Model 
    with SDP", Internet Engineering Task Force, RFC 3264, April 2002. 
    
    
    
    
    
    


 
 
Johnston et al         Expires - February 2002              [Page 28] 

                      SIP Torture Test Messages           August 2002 
 
 
Acknowledgments 
    
   Thanks to Rohan Mahy, Adam Roach, Gonzalo Camarillo, Cullen Jennings, 
   and Tom Taylor for their detailed comments during the final final 
   review.  Thanks to Vijay Gurbani for his comments. 
    
   The authors wish to thank Neil Deason for his additions to the 
   Torture Test messages and Kundan Singh for performing parser 
   validation of messages.  
    
   The authors wish to thank the following individuals for their 
   participation in the final review of this call flows document: Aseem 
   Agarwal, Rafi Assadi, Ben Campbell, Sunitha Kumar, Jon Peterson, Marc 
   Petit-Huguenin, Vidhi Rastogi, and Bodgey Yin Shaohua.   
    
   The authors also wish to thank the following individuals for their 
   assistance: 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 Addresses 
    
      Alan Johnston 
      WorldCom 
      100 South 4th Street 
      St. Louis, MO 63102 
      USA 
    
      EMail:  [e-mail] 
    
      Jonathan Rosenberg 
      dynamicsoft 
      72 Eagle Rock Ave 
      East Hanover, NJ 07936 
      USA 
    
      EMail:  [e-mail] 
    
    
      Henning Schulzrinne 
      Dept. of Computer Science 
      Columbia University 
      1214 Amsterdam Avenue 
      New York, NY 10027 
      USA 
 
 
Johnston et al         Expires - February 2002              [Page 29] 

                      SIP Torture Test Messages           August 2002 
 
 
    
      EMail:  [e-mail] 
    
    
    
   Copyright Notice 
    
   "Copyright (C) The Internet Society 2002. 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. 
    
   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 
 
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    









 
 
Johnston et al         Expires - February 2002              [Page 30]