Subject: RE: [SIP] new torture tests

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 13 Nov 2000 21:48:48 -0500

Comments below.

> -----Original Message-----
> From: Neil Deason [mailto:[email-masked]]
> Sent: Monday, November 13, 2000 12:56 PM
> To: Sip List
> Subject: [SIP] new torture tests
> 
> 
> The following are 15 new proposed torture test messages 
> based on the bis draft. None of them should cause good 
> implementations to crash. Recommended responses to the 
> illegal messages are given where needed.

Well, some of your messages have only mild errors in them. Based on the
philosophy of being liberal with what you receive, I would not declare an
entity to have failed the test if it does not generate the specific error
code.

> 1) Illegal enclosing of Request-URI  in "<>"
> Server should respond with 400 + Appropriate Reason Phrase.
> 
> INVITE <sip:[email-masked]> SIP/2.0
> To: sip:[email-masked]
> From: sip:[email-masked]
> Call-ID: [email-masked]
> 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=SIP Call
> t=3149328700 0
> c=IN IP4 135.180.130.88
> m=audio 492170 RTP/AVP 0 12
> m=video 3227 RTP/AVP 31
> a=rtpmap:31 LPC
> 
> 
> 2) Illegal LWS in elements of Request-URI
> Server should respond with 400 + Appropriate Reason Phrase.
> 
> INVITE sip:[email-masked]; transport=udp SIP/2.0
> To: sip:[email-masked]
> From: sip:[email-masked]
> Call-ID: [email-masked]
> 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=SIP Call
> t=3149328700 0
> c=IN IP4 135.180.130.88
> m=audio 492170 RTP/AVP 0 12
> m=video 3227 RTP/AVP 31
> a=rtpmap:31 LPC

I suspect many implementations will accept the above message. 

> 
> 
> 3) Illegal >1 SP between elements of Request URI
> Server should respond with 400 + Appropriate Reason Phrase.
> 
> INVITE sip:[email-masked]  SIP/2.0
> To: sip:[email-masked]
> From: sip:[email-masked]
> Call-ID: [email-masked]
> 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=SIP Call
> t=3149328700 0
> c=IN IP4 135.180.130.88
> m=audio 492170 RTP/AVP 0 12
> m=video 3227 RTP/AVP 31
> a=rtpmap:31 LPC

Same here.

> 5) Illegal use of escaped header in Request-URI
> Proxies should strip off the escaped header before proxying on.
> 
> INVITE sip:[email-masked]?Route=%3Csip:sip.example.com%3E
> SIP/2.0
> To: sip:[email-masked]
> From: sip:[email-masked]
> Call-ID: [email-masked]
> 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=SIP Call
> t=3149328700 0
> c=IN IP4 135.180.130.88
> m=audio 492170 RTP/AVP 0 12
> m=video 3227 RTP/AVP 31
> a=rtpmap:31 LPC

I'm not sure I agree with the behavior here. If the proxy is not
company.com, it may simple forward the request to company.com without
stripping the Route header. I see nothing wrong with that.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Neil Deason <[email-masked]>
Date: Tue, 14 Nov 2000 11:40:57 +0000

> entity to have failed the test if it does not generate the specific error

Good point, I will include text to this effect.

[snip]

> stripping the Route header. I see nothing wrong with that.

Glad you think so too because this is what our proxy does. 
However, bis 02 says in 4.3 "A server which receives a 
SIP-URL with illegal elements removes them before further 
processing." So should this text be changed?

Cheers,
Neil
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net