Re: [Sip-implementors] SDP longer than that given in "Content-Lenght" header

2007-12-20 Thread Dale . Worley
   From: "Aneesh Naik" <[EMAIL PROTECTED]>

   What should be the behavior when SDP is longer than that given in
   "Content-Length" header?

If the SIP message arrives in a UDP datagram, or via some other
protocol which "frames" each message, as you say, the excess bytes
must be discarded.

   The RFC 3261 section 18.3 Framing states:
   If there are additional bytes in the transport packet beyond the end of the
   body, they MUST be discarded.

   So this means, SIP parser should discard the data beyond the length given by
   "Content-Lenght" header.
   In the below case the call should fail as we wont get enough data from SDP
   to complete the call as we will drop them.

   INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0
   From: sipp ;tag=15126SIPpTag001
   To: sut 
   Call-ID: [EMAIL PROTECTED]
   CSeq: 1 INVITE
   Contact: sip:[EMAIL PROTECTED]:5061
   Max-Forwards: 70
   Subject: Performance Test
   Content-Type: application/sdp
   *Content-Length:  20*

   v=0
   o=user1 53655765 2353687637 IN IP4 10.253.6.209
   s=-
   c=IN IP4 10.253.6.209
   t=0 0
   m=audio 6001 RTP/AVP 0
   a=rtpmap:0 PCMU/8000

   Please suggest what must be the behavior in this case.

Which means that the message is effectively:

   INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
   Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0
   From: sipp ;tag=15126SIPpTag001
   To: sut 
   Call-ID: [EMAIL PROTECTED]
   CSeq: 1 INVITE
   Contact: sip:[EMAIL PROTECTED]:5061
   Max-Forwards: 70
   Subject: Performance Test
   Content-Type: application/sdp
   Content-Length:  20

   v=0
   o=user1 5365576

That is not validly formed SDP, since the o-line does not have the
correct syntax.  Your SDP parser should detect this.

There is no defined error code for this situation, but 488 seems to be
the closest in meaning.  You can add a Warning header to the reponse
that contains text explaining the problem with the invalid SDP.

And as Attila says, tell the vendor about their problem.

If the SIP message comes in via TCP or another "unframed" (stream)
protocol, the Content-Length defines where the end of the SIP message
is.  The following bytes start the next SIP message.  In this case,
they are:

5 2353687637 IN IP4 10.253.6.209
s=-
c=IN IP4 10.253.6.209
t=0 0
m=audio 6001 RTP/AVP 0
a=rtpmap:0 PCMU/8000

which is syntactically invalid.

Dale
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


Re: [Sip-implementors] SDP longer than that given in "Content-Lenght"header

2007-12-20 Thread nataraju.basavaraju

Comments Inline...

Regards,
Nataraju A B
 
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On 
> Behalf Of Aneesh Naik
> Sent: Thursday, December 20, 2007 5:33 PM
> To: Sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] SDP longer than that given in 
> "Content-Lenght"header
> 
> Hi,
> 
> What should be the behavior when SDP is longer than that 
> given in "Content-Length" header?
> 
> The RFC 3261 section 18.3 Framing states:
> If there are additional bytes in the transport packet beyond 
> the end of the body, they MUST be discarded.
> 
> So this means, SIP parser should discard the data beyond the 
> length given by "Content-Lenght" header.
> In the below case the call should fail as we wont get enough 
> data from SDP to complete the call as we will drop them.
> 
> INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
> Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0
> From: sipp ;tag=15126SIPpTag001
> To: sut 
> Call-ID: [EMAIL PROTECTED]
> CSeq: 1 INVITE
> Contact: sip:[EMAIL PROTECTED]:5061
> Max-Forwards: 70
> Subject: Performance Test
> Content-Type: application/sdp
> *Content-Length:  20*
> 
> v=0
> o=user1 53655765 2353687637 IN IP4 10.253.6.209
> s=-
> c=IN IP4 10.253.6.209
> t=0 0
> m=audio 6001 RTP/AVP 0
> a=rtpmap:0 PCMU/8000
> 
> 
> Please suggest what must be the behavior in this case.
> 
[ABN] since this message is received over UDP transport, it would be
preferred to consider whole packet and give less precedence to
content-length header value. Even RFC.3261 suggests discard the rest of
the bytes, but being liberal here would make the UA implementation more
robust also.

In case of TCP transport you should use the content-length header value
strictly to determine the body of the received SIP request/response.

This is my understanding, please add on if something better or preferred
alternatives are available

> Thanks,
> Aneesh
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> 


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.
 
www.wipro.com

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


Re: [Sip-implementors] SDP longer than that given in "Content-Lenght"header

2007-12-20 Thread Attila Sipos

Discard the extra bytes.  You have no choice.

And tell the UA vendor to fix their implementation.

Regards,

Attila
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Aneesh Naik
Sent: 20 December 2007 12:03
To: Sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] SDP longer than that given in
"Content-Lenght"header

Hi,

What should be the behavior when SDP is longer than that given in
"Content-Length" header?

The RFC 3261 section 18.3 Framing states:
If there are additional bytes in the transport packet beyond the end of
the body, they MUST be discarded.

So this means, SIP parser should discard the data beyond the length
given by "Content-Lenght" header.
In the below case the call should fail as we wont get enough data from
SDP to complete the call as we will drop them.

INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0
From: sipp ;tag=15126SIPpTag001
To: sut 
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE
Contact: sip:[EMAIL PROTECTED]:5061
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
*Content-Length:  20*

v=0
o=user1 53655765 2353687637 IN IP4 10.253.6.209
s=-
c=IN IP4 10.253.6.209
t=0 0
m=audio 6001 RTP/AVP 0
a=rtpmap:0 PCMU/8000


Please suggest what must be the behavior in this case.

Thanks,
Aneesh
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


[Sip-implementors] SDP longer than that given in "Content-Lenght" header

2007-12-20 Thread Aneesh Naik
Hi,

What should be the behavior when SDP is longer than that given in
"Content-Length" header?

The RFC 3261 section 18.3 Framing states:
If there are additional bytes in the transport packet beyond the end of the
body, they MUST be discarded.

So this means, SIP parser should discard the data beyond the length given by
"Content-Lenght" header.
In the below case the call should fail as we wont get enough data from SDP
to complete the call as we will drop them.

INVITE sip:[EMAIL PROTECTED]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.1.209:5061;branch=z9hG4bK-15126-1-0
From: sipp ;tag=15126SIPpTag001
To: sut 
Call-ID: [EMAIL PROTECTED]
CSeq: 1 INVITE
Contact: sip:[EMAIL PROTECTED]:5061
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
*Content-Length:  20*

v=0
o=user1 53655765 2353687637 IN IP4 10.253.6.209
s=-
c=IN IP4 10.253.6.209
t=0 0
m=audio 6001 RTP/AVP 0
a=rtpmap:0 PCMU/8000


Please suggest what must be the behavior in this case.

Thanks,
Aneesh
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors