Subject: Re: [SIP] new torture tests

From: "Keith Robinson" <[email-masked]>
Date: Tue, 14 Nov 2000 12:11:38 +0000

I have the following comments/queries (based on bis-02)  on the proposed
additions for the torture test:

Message 2:

It is possible to parse this messge correctly even though it is strictly
illegal.

Message 3:

I don't think this message is illegal if reference is made to Appendix C which
states:

"All linear white space, including folding, has the same semantics as SP. A
recipient MAY replace any linear white space with a single SP before
interpreting the field value
or forwarding the message downstream"

Message 4:

Where does the spec imply that these characters can be replaced with their
escaped values in the context given ? In the case of the @ being replaced with
its escape sequence a conflict will occur if a client/proxy wants to use an
escaped @ in the user name, a situation described in the recent draft describing
registration in a visited domain.

Message 5:

Where does the spec imply that escaped headers cannot be used in the Reqest-URI
? The BNF for SIP URLs in section 2 gives the following rule:

headers = "?" header * ( "&" header )
header   = hname "=" hvalue
hname   = 1*(hnv-unreserved|unreserved|escaped)

which will allow escape seqences in SIP URL header fields.

Message 13:

The Call-ID: and last Via: headers span multiple lines but the LWS at the start
of the subsequent lines to indicate line folding (section 6.5 para. 1) is
missing.

Regards

K. Robinson

Neil Deason <[email-masked]> on 13/11/2000 17:56:04

                                                              

 To:      Sip List <[email-masked]>                  
                                                              
 cc:      (bcc: Keith Robinson/MAIN/MC1)                      

 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.

I would greatly appreciate any additions/corrections to be
made quickly so we can try to get these folded into a new
release of the call flows draft before the next bakeoff.

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

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

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

4) Legal SIP URL in Request URI with escaped characters and
parameter.

INVITE sip%3Auser%40company.com;other-param=summit 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

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

6) Not understood URI in Req-URI but a SIP URL in To.
Server should respond 400 + Appropriate Reason Phrase

INVITE name:user 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

7) Legal no LWS between display name and <

OPTIONS sip:[email-masked] SIP/2.0
To: sip:[email-masked]
From: "caller"<sip:[email-masked]>
Call-ID: [email-masked]
CSeq: 1 OPTIONS
Via: SIP/2.0/UDP 135.180.130.133

8) Legal extra LWS between display name and <

OPTIONS sip:[email-masked] SIP/2.0
To: sip:[email-masked]
From: "caller"    <sip:[email-masked]>
Call-ID: [email-masked]
CSeq: 2 OPTIONS
Via: SIP/2.0/UDP 135.180.130.133

9) Illegal Non GMT time zone in SIP Date
A liberal server should correct this.

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
Expires: 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=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

10) Legal message with passed Exipres date.
A Server should respond 408 Request Timeout.

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
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=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

11) Legal message with zero max forwards
Proxies should return 483 Too Many Hops, a UAS responds
as for OPTIONS.

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
Max-Forwards: 0
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

12) Legal REGISTER with SIP URL containing escaped Route header
in Contact.

REGISTER sip:company.com SIP/2.0
To: sip:[email-masked]
From: sip:[email-masked]
Contact: sip:[email-masked]
Call-ID: [email-masked]
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 135.180.130.133
Contact: sip:[email-masked]?Route=%3Csip:sip.example.com%3E

13) Legal but long, includes Token for Call-ID.

INVITE sip:[email-masked] SIP/2.0
To: "I have a user name of extreme proportion"
<sip:[email-masked]:6000;other-param=1234567890somethingelselong1234567890>
From: sip:[email-masked]
Call-ID:
kl24ahsd546folnyt2vbak9sad98u23naodiunzds09a3bqw0sdfbsk34poouymnae0043nsed09mfkvc74bd0cuwnms05dknw87hjpobd76f

CSeq: 1 INVITE
My-State: sldkjflzdsfaret0803adgaasd0afds0asdaasd
Via: SIP/2.0/UDP sip33.example.com
Via: SIP/2.0/UDP sip32.example.com
Via: SIP/2.0/UDP sip31.example.com
Via: SIP/2.0/UDP sip30.example.com
Via: SIP/2.0/UDP sip29.example.com
Via: SIP/2.0/UDP sip28.example.com
Via: SIP/2.0/UDP sip27.example.com
Via: SIP/2.0/UDP sip26.example.com
Via: SIP/2.0/UDP sip25.example.com
Via: SIP/2.0/UDP sip24.example.com
Via: SIP/2.0/UDP sip23.example.com
Via: SIP/2.0/UDP sip22.example.com
Via: SIP/2.0/UDP sip21.example.com
Via: SIP/2.0/UDP sip20.example.com
Via: SIP/2.0/UDP sip19.example.com
Via: SIP/2.0/UDP sip18.example.com
Via: SIP/2.0/UDP sip17.example.com
Via: SIP/2.0/UDP sip16.example.com
Via: SIP/2.0/UDP sip15.example.com
Via: SIP/2.0/UDP sip14.example.com
Via: SIP/2.0/UDP sip13.example.com
Via: SIP/2.0/UDP sip12.example.com
Via: SIP/2.0/UDP sip11.example.com
Via: SIP/2.0/UDP sip10.example.com
Via: SIP/2.0/UDP sip9.example.com
Via: SIP/2.0/UDP sip8.example.com
Via: SIP/2.0/UDP sip7.example.com
Via: SIP/2.0/UDP sip6.example.com
Via: SIP/2.0/UDP sip5.example.com
Via: SIP/2.0/UDP sip4.example.com
Via: SIP/2.0/UDP sip3.example.com
Via: SIP/2.0/UDP sip2.example.com
Via: SIP/2.0/UDP sip1.example.com
Via: SIP/2.0/UDP
host.example.com;received=135.180.130.133;branch=C1C3344E2710000000E299E568E7potato10potato0potato0

Content-Type: application/sdp

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

14) Illegal, badly mangled message with mutliple To,
From, Call-ID and CSeq headers.
Server should respond 400 + Appropriate Reason Phrase

OPTIONS sip:135.180.130.133 SIP/2.0
Via: SIP/2.0/UDP company.com:5604
From: sip:[email-masked]
To: sip:[email-masked]
Call-ID: [email-masked]
CSeq: 1 OPTIONS
Expires: 0 [email-masked]
To: sip:[email-masked]
Call-ID: [email-masked]
CSeq: 1 OPTIONS
Contact: sip:host.company.com
Expires: 0xpires: 0sip:host.company.com
Expires: 0
Contact: sip:host.company.com

15) Legal message with an unusual amount of SDP attributes.

INVITE sip:[email-masked];user=phone SIP/2.0
Via: SIP/2.0/UDP iftgw.there.com:5060
From: sip:[email-masked];user=phone
To: sip:[email-masked];user=phone
Call-ID: [email-masked]
CSeq: 56 INVITE
Content-Type: application/sdp
Content-Length: 320

v=0
o=faxgw1 2890844527 2890844527 IN IP4 iftgw.there.com
s=Session SDP
c=IN IP4 iftmg.there.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:t38UDPRedundancy

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

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

---

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

> additions for the torture test:

Thanks for the comments.

> It is possible to parse this messge correctly even though it is strictly

If you are clever enough you can parse anything ;) 
But is a fair point that following the "be liberal on what 
you accept .." is good and responding 400 to this would be 
harsh.

> or forwarding the message downstream"

Hmm this is a MAY and indeed being liberal and accepting this 
is highly desirable. Going strictly from section 4.1 I read
this as being illegal. Authors, parser implementers care to 
comment on the matter?

> registration in a visited domain.

Yeah I got carried away on this one. I intend to change it to :

sip:[email-masked];other-param=summit

> which will allow escape seqences in SIP URL header fields.

See Table 2 which indicates escaped headers are not allowed in 
the Req	URI.

> of the subsequent lines to indicate line folding (section 6.5 para. 1) is

That is an unfortunate effect of my mail client's formatting.

Cheers,
Neil.

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 14 Nov 2000 15:18:50 +0100

> you accept .." is good and responding 400 to this would be

I don't know about that. I believe it is the case that URLs can *never*
contain unencoded space characters. If this is true then the test seems
very reasonable.

--
Anders Kristensen