torture-test.txt

这是国外的resip协议栈

   From: sip:[e-mail];tag=3413415 
   From: sip:[e-mail] 
   To: sip:[e-mail] 
   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.13     INVITE with Illegal Expires Header 
    
   This message contains an Expires header which has illegal values for 
   a number of components, but otherwise is syntactically correct. 
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw 
   Max-Forwards: 88 
   CSeq: 0 INVITE 
   Call-ID: 98asdh@10.1.1.2 
   Expires: Thu, 44 Dec 19999 16:00:00 EDT 
   From: sip:[e-mail];tag=3651 
   To: sip:[e-mail] 
   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.14     200 OK Response with Broadcast Via Header 
    
   This message is a response with a 2nd Via header of 255.255.255.255. 
    
   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. 
    
    
   Message Details 
    
   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 
   Max-Forwards: 70 
   Call-ID: 0384840201@10.1.1.1 
   CSeq: 0 INVITE 
   From: sip:[e-mail];tag=11141343 
   To: sip:[e-mail];tag=2229 
   Content-Type: application/sdp 
    
   v=0 
   o=mhandley 29739 7272939 IN IP4 126.5.4.3 
   s=- 
   c=IN IP4 224.2.17.12/127 
   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 
    
   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. 
    
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=134161461246 
   Max-Forwards: 7 
   Call-ID: 0ha0isndaksdj@10.0.0.1 
   CSeq: 8 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133;;,; 
   Contact: "" <> ;,"Joe" <sip:[e-mail]>;;,,;; 
   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.16     INVITE with Incorrect Content-Length Header 
    
   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... 
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   Max-Forwards: 80 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=93942939o2 
   Call-ID: 0ha0isndaksdj@10.0.0.1 
   CSeq: 8 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133 
   Content-Type: application/sdp 
   Content-Length: 9999 
    
   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.17     INVITE with Invalid Value for Content-Length 
    
   This is a request message with a negative value for Content-Length. 
    
   The server should respond with an error. 
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   Max-Forwards: 254 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=3 
   Call-ID: 0ha0isndaksdj@10.0.0.1 
   CSeq: 8 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw 
   Content-Type: application/sdp 
   Content-Length: -999 
    
   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.18     INVITE with Garbage after Message Body 
    
    
   This is a request message with garbage after the end of the SDP 
   included in the body.  
    
   The servers should reject the request as the body is longer than the  
   Content-Length. 
    
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=3223 
   Max-Forwards: 7 
   Call-ID: 0ha0isndaksdj@10.0.0.1 
   CSeq: 8 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133 
   Content-Type: application/sdp 
   Content-Length: 138 
    
   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 
   asdpasd08asdsdk:;;asd 
    a0sdjhg8a0''...'';;;; 
    
    
2.19     INVITE with Error in Display Name in To Header 
    
   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. 
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   To: "Mr. J. User <sip:[e-mail]> From: sip:[e-mail];tag=93334 
   Max-Forwards: 10 
   Call-ID: 0ha0isndaksdj@10.0.0.1 
   CSeq: 8 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133:5050;branch=z9hG4bKkdjuw 
   Content-Type: application/sdp 
   Content-Length: 138 
    
   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.20     INVITE with a Semicolon-Separated Parameter in the "user" Part 
    
   This is an INVITE request with a semicolon-separated parameter in  
   the "user" part.  
    
   Outbound proxies should direct it appropriately.  
    
    
   Message Details 
    
   INVITE sip:user;par=[e-mail] SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=33242 
   Max-Forwards: 3 
   Call-ID: 0ha0isndaksdj@10.1.1.1 
   CSeq: 8 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133;branch=z9hG4bKkdjuw 
    
    
    
2.21     INVITE with Illegal Enclosing of Request-URI  in "<>" 
    
   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  
   athe Request-URI if acting as a Proxy. If not it should respond 400 
   with an appropriate reason phrase. 
    
    
   Message Details 
    
   INVITE <sip:[e-mail]> SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];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: 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 0 12 
   m=video 3227 RTP/AVP 31 
   a=rtpmap:31 LPC 
    
    
2.22     INVITE with Illegal LWS within Elements of Request-URI  
    
   This INVITE has illegal LWS within the SIP 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. 
    
   Message Details 
    
   INVITE sip:[e-mail]; transport=udp SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=231413434 
   Max-Forwards: 5 
   Call-ID: 2@10.0.0.1 
   CSeq: 1 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=3149328700 0 
   m=audio 492170 RTP/AVP 0 12 
   m=video 3227 RTP/AVP 31 
   a=rtpmap:31 LPC 
`    
    
2.23     INVITE with illegal >1 SP between elements of Request URI  
    
   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. 
    
    
   Message Details 
    
   INVITE sip:[e-mail]  SIP/2.0 
   Max-Forwards: 8 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=8814 
   Call-ID: 3@10.0.0.1 
   CSeq: 1 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 0 12 
   m=video 3227 RTP/AVP 31 
   a=rtpmap:31 LPC 
    
    
    
2.24     INVITE with a legal SIP URI containing escaped characters 
    
   This INVITE is legal and has a Request-URI with a SIP URI containing 
   escaped characters. 
 
   Message Details 
    
   INVITE sip:[e-mail];other-param=summit 
   SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=938 
   Max-Forwards: 87 
   Call-ID: 4@10.0.0.1 
   CSeq: 1 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 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 
    
   This INVITE is illegal as it the Request-URI contains a SIP URI 
   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. 
    
    
   Message Details 
    
   INVITE sip:[e-mail]?Route=%3Csip:sip.example.com%3E SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=341518 
   Max-Forwards: 7 
   Call-ID: 5@10.0.0.1 
   CSeq: 1 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 0 12 
   m=video 3227 RTP/AVP 31 
   a=rtpmap:31 LPC 
    
    
    
2.26     INVITE containing an unknown scheme in the Request URI 
    
   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 URI. 
    
    
   Message Details 
    
   INVITE name:user SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=384 
   Max-Forwards: 3 
   Call-ID: 6@10.0.0.1 
   CSeq: 1 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133;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 0 12 
   m=video 3227 RTP/AVP 31 
   a=rtpmap:31 LPC 
    
    
    
2.27     OPTIONS with no LWS between display name and < This OPTIONS request is legal despite there being no LWS between 
   the display name and < in the From header. 
    
    
   Message Details 
    
   OPTIONS sip:[e-mail] SIP/2.0 
   To: sip:[e-mail] 
   From: "caller"<sip:[e-mail]>;tag=323 
   Max-Forwards: 70 
   Call-ID: 1234abcd@10.0.0.1 
   CSeq: 1 OPTIONS 
   Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 
    
    
2.28     OPTIONS with extran LWS between display name and < This OPTIONS request is legal despite there being extra LWS between 
   the display name and < in the From header. 
    
    
   Message Details 
    
   OPTIONS sip:[e-mail] SIP/2.0 
   To: sip:[e-mail] 
   From: "caller"    <sip:[e-mail]>;tag=32 
   Max-Forwards: 70 
   Call-ID: 1234abcd@10.0.0.1 
   CSeq: 2 OPTIONS 
   Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 
    
    
    
2.29     INVITE with an illegal SIP Date format. 
    
   This INVITE is illegal as it contains a non GMT time zone in the SIP 
   Date 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. 
    
    
   Message Details 
    
   INVITE sip:[e-mail] SIP/2.0 
   To: sip:[e-mail] 
   From: sip:[e-mail];tag=2 
   Max-Forwards: 70 
   Call-ID: 7@10.0.0.1 
   CSeq: 1 INVITE 
   Via: SIP/2.0/UDP 135.180.130.133:5060;branch=z9hG4bKkdjuw 
   Date: Fri, 01 Jan 2010 16:00:00 EST 
   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