Nitin Kapoor | 9 Mar 2011 08:24
Picon

Re: Different SDP Session Version in 183 & 200 OK

Hello All,

Could any one please help me out on requested query as below.

Thanks,
Nitin

On Tue, Mar 8, 2011 at 4:48 PM, Nitin Kapoor <nitinkapoorr <at> gmail.com> wrote:
Dear All,

I have one call scenario where my termination is sending the SDP in 183 as well as in 200 OK also. As far as i know if we are getting SDP in 183 session progress then my UAC can ignore the SDP in 200 OK. Also most of the time SDP is same.

But here i noticed the slight difference of "Session Version". Here when my termination is sending 188 Session Progress with SDP is sending the SDP as below.

I can see that  my Termination is incrementing  "Session Version" for SDP in 183 & 200 OK in same dialog..

183 with SDP

S_OWNER : o=TLPMSXP2 22660 22660 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0
M_NAME : m=audio 59072 RTP/AVP 18 4 8 98

200 OK with SDP:

S_OWNER : o=TLPMSXP2 22660 22661 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0

Could anyone please let me know if that is okay to increment the session version and if any supported document is there?

Thanks,
Nitin

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Nitin Kapoor | 9 Mar 2011 10:33
Picon

Re: Different SDP Session Version in 183 & 200 OK

Hello Ashish,

Here is the mline for both the messages.

183:

Media Description, name and address (m): audio 43888 RTP/AVP 18

200 OK:

Media Description, name and address (m): audio 43888 RTP/AVP 18

Thanks,
Nitin Kapoor


On Wed, Mar 9, 2011 at 3:25 AM, Ashish Saxena <ashish2.saxena <at> aricent.com> wrote:
what is the mline of 200OK SDP.

Regards
Ashish Saxena
(www.aricent.com)
________________________________________
From: sip-bounces <at> ietf.org [sip-bounces <at> ietf.org] On Behalf Of Nitin Kapoor [nitinkapoorr <at> gmail.com]
Sent: Wednesday, March 09, 2011 12:54 PM
To: sip-implementors <at> lists.cs.columbia.edu
Cc: sip <at> ietf.org
Subject: Re: [Sip] Different SDP Session Version in 183 & 200 OK

Hello All,

Could any one please help me out on requested query as below.

Thanks,
Nitin

On Tue, Mar 8, 2011 at 4:48 PM, Nitin Kapoor <nitinkapoorr <at> gmail.com<mailto:nitinkapoorr <at> gmail.com>> wrote:
Dear All,

I have one call scenario where my termination is sending the SDP in 183 as well as in 200 OK also. As far as i know if we are getting SDP in 183 session progress then my UAC can ignore the SDP in 200 OK. Also most of the time SDP is same.

But here i noticed the slight difference of "Session Version". Here when my termination is sending 188 Session Progress with SDP is sending the SDP as below.

I can see that  my Termination is incrementing  "Session Version" for SDP in 183 & 200 OK in same dialog..

183 with SDP

S_OWNER : o=TLPMSXP2 22660 22660 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0
M_NAME : m=audio 59072 RTP/AVP 18 4 8 98

200 OK with SDP:

S_OWNER : o=TLPMSXP2 22660 22661 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0

Could anyone please let me know if that is okay to increment the session version and if any supported document is there?

Thanks,
Nitin


"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Nitin Kapoor | 9 Mar 2011 14:20
Picon

Re: [Sip-implementors] Different SDP Session Version in 183 &200 OK

Hi Sanjiv,

I do agree that "session-version" should increment by one from the previous SDP when there is any modification is involved in SDP. But i haven't seen any modification into the SDP of 183 & 200 OK/

Also, there was no SDP in ACK. If you need i can share the traces with you.

Thanks,
Nitin Kapoor

On Wed, Mar 9, 2011 at 5:30 AM, Jaiswal, Sanjiv (NSN - IN/Bangalore) <sanjiv.jaiswal <at> nsn.com> wrote:
Hi Nitin,


Every SDP with incremented session ( in this case 200 OK) is treated as
new negotiation(offer).
Whether ACK from other end contains SDP answer? If yes then session
version is incremented there also?


Regards
Sanjiv

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of ext
Nitin Kapoor
Sent: Wednesday, March 09, 2011 3:03 PM
To: Ashish Saxena
Cc: sip <at> ietf.org; sip-implementors <at> lists.cs.columbia.edu
Subject: Re: [Sip-implementors] [Sip] Different SDP Session Version in
183 &200 OK

Hello Ashish,

Here is the mline for both the messages.

183:

Media Description, name and address (m): audio 43888 RTP/AVP 18

200 OK:

Media Description, name and address (m): audio 43888 RTP/AVP 18

Thanks,
Nitin Kapoor


On Wed, Mar 9, 2011 at 3:25 AM, Ashish Saxena
<ashish2.saxena <at> aricent.com>wrote:

> what is the mline of 200OK SDP.
>
> Regards
> Ashish Saxena
> (www.aricent.com)
> ________________________________________
> From: sip-bounces <at> ietf.org [sip-bounces <at> ietf.org] On Behalf Of Nitin
> Kapoor [nitinkapoorr <at> gmail.com]
> Sent: Wednesday, March 09, 2011 12:54 PM
> To: sip-implementors <at> lists.cs.columbia.edu
> Cc: sip <at> ietf.org
> Subject: Re: [Sip] Different SDP Session Version in 183 & 200 OK
>
> Hello All,
>
> Could any one please help me out on requested query as below.
>
> Thanks,
> Nitin
>
> On Tue, Mar 8, 2011 at 4:48 PM, Nitin Kapoor <nitinkapoorr <at> gmail.com
> <mailto:nitinkapoorr <at> gmail.com>> wrote:
> Dear All,
>
> I have one call scenario where my termination is sending the SDP in
183 as
> well as in 200 OK also. As far as i know if we are getting SDP in 183
> session progress then my UAC can ignore the SDP in 200 OK. Also most
of the
> time SDP is same.
>
> But here i noticed the slight difference of "Session Version". Here
when my
> termination is sending 188 Session Progress with SDP is sending the
SDP as
> below.
>
> I can see that  my Termination is incrementing  "Session Version" for
SDP
> in 183 & 200 OK in same dialog..
>
> 183 with SDP
>
> S_OWNER : o=TLPMSXP2 22660 22660 IN IP4 69.90.230.210
> S_NAME : s=sip call
> S_CONNECT : c=IN IP4 69.90.230.217
> TIME : t=0 0
> M_NAME : m=audio 59072 RTP/AVP 18 4 8 98
>
> 200 OK with SDP:
>
> S_OWNER : o=TLPMSXP2 22660 22661 IN IP4 69.90.230.210
> S_NAME : s=sip call
> S_CONNECT : c=IN IP4 69.90.230.217
> TIME : t=0 0
>
> Could anyone please let me know if that is okay to increment the
session
> version and if any supported document is there?
>
> Thanks,
> Nitin
>
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended
solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or
used
> for any purpose other than for what it is intended. If you have
received
> this message in error, please notify the originator immediately. If
you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents
of this
> message. Aricent accepts no responsibility for loss or damage arising
from
> the use of the information transmitted by this email including damage
from
> virus."
>
_______________________________________________
Sip-implementors mailing list
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Vijay Tiwari | 9 Mar 2011 18:12
Picon

Re: Different SDP Session Version in 183 & 200 OK

Hello Nitin

Hope you are doing good, sorry i was able to respond that time. i saw are mail and according to my understanding this value can be change if

"<sess-version> is  increased when a modification is made to the session data."


it means that if any session data change between 183 and 200 ok message then it is standard behavior


Thanks
Vijay

On Wed, Mar 9, 2011 at 12:54 PM, Nitin Kapoor <nitinkapoorr <at> gmail.com> wrote:
Hello All,

Could any one please help me out on requested query as below.

Thanks,
Nitin

On Tue, Mar 8, 2011 at 4:48 PM, Nitin Kapoor <nitinkapoorr <at> gmail.com> wrote:
Dear All,

I have one call scenario where my termination is sending the SDP in 183 as well as in 200 OK also. As far as i know if we are getting SDP in 183 session progress then my UAC can ignore the SDP in 200 OK. Also most of the time SDP is same.

But here i noticed the slight difference of "Session Version". Here when my termination is sending 188 Session Progress with SDP is sending the SDP as below.

I can see that  my Termination is incrementing  "Session Version" for SDP in 183 & 200 OK in same dialog..

183 with SDP

S_OWNER : o=TLPMSXP2 22660 22660 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0
M_NAME : m=audio 59072 RTP/AVP 18 4 8 98

200 OK with SDP:

S_OWNER : o=TLPMSXP2 22660 22661 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0

Could anyone please let me know if that is okay to increment the session version and if any supported document is there?

Thanks,
Nitin


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.



--
They can because they think they can.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Attila Sipos | 9 Mar 2011 19:12

Re: [Sip-implementors] Content-Disposition

Strictly, for an error like that, there should be a "404 Bad Request"
response
but you might decide it is better to treat it as if it is missing:

   If the Content-Disposition header field is missing, bodies of
   Content-Type application/sdp imply the disposition "session", while
   other content types imply "render".

In this case, I think I would opt for a 404 response and then
inform the UA vendors that their UA is misbehaving.

regards
Attila

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of
isshed
Sent: 09 March 2011 17:55
To: discussion-bounces <at> sipforum.org; sip-implementors; sip <at> ietf.org
Subject: Re: [Sip-implementors] Content-Disposition

If this header in initial invite and parsing fails. does the call get
connected?

On Wed, Mar 9, 2011 at 11:16 PM, isshed <isshed.sip <at> gmail.com> wrote:

> does anyone know what the behaviour if parsing of Content-Disposition 
> header fails.
>
> Thanks,
> HArendra
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Worley, Dale R (Dale | 9 Mar 2011 19:28
Favicon

Re: [Sip-implementors] Content-Disposition

________________________________________
From: sip-bounces <at> ietf.org [sip-bounces <at> ietf.org] On Behalf Of Attila Sipos [attila.sipos <at> vegastream.com]

Strictly, for an error like that, there should be a "404 Bad Request"
response
but you might decide it is better to treat it as if it is missing:

   If the Content-Disposition header field is missing, bodies of
   Content-Type application/sdp imply the disposition "session", while
   other content types imply "render".

In this case, I think I would opt for a 404 response and then
inform the UA vendors that their UA is misbehaving.
_______________________________________________

I agree with Attila, although beware he typed "404" where he should have typed "400".  (404 is "Not Found".)

Be careful that your parser will accept all possible future extensions of Content-Disposition as
specified in RFC 3261 section 25.1 -- you wouldn't want your device rejecting calls that implemented some
future extension.

Dale
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Sudeesh Ravindran | 10 Mar 2011 07:09
Picon

Re: Different SDP Session Version in 183 & 200 OK


 
Hey Guys,
 
             Please tell me , how can i relieve from this site. All your mails are delivers into my mail id to........ Please suggest the idea.
 
 
With regards,
 
Ji
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
On Wed, Mar 9, 2011 at 1042 PM, Vijay Tiwari <vijay11tiwari <at> gmail.com> wrote:
Hello Nitin

Hope you are doing good, sorry i was able to respond that time. i saw are mail and according to my understanding this value can be change if

"<sess-version> is  increased when a modification is made to the session data."


it means that if any session data change between 183 and 200 ok message then it is standard behavior


Thanks
Vijay

On Wed, Mar 9, 2011 at 12:54 PM, Nitin Kapoor <nitinkapoorr <at> gmail.com> wrote:
Hello All,

Could any one please help me out on requested query as below.

Thanks,
Nitin

On Tue, Mar 8, 2011 at 4:48 PM, Nitin Kapoor <nitinkapoorr <at> gmail.com> wrote:
Dear All,

I have one call scenario where my termination is sending the SDP in 183 as well as in 200 OK also. As far as i know if we are getting SDP in 183 session progress then my UAC can ignore the SDP in 200 OK. Also most of the time SDP is same.

But here i noticed the slight difference of "Session Version". Here when my termination is sending 188 Session Progress with SDP is sending the SDP as below.

I can see that  my Termination is incrementing  "Session Version" for SDP in 183 & 200 OK in same dialog..

183 with SDP

S_OWNER : o=TLPMSXP2 22660 22660 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0
M_NAME : m=audio 59072 RTP/AVP 18 4 8 98

200 OK with SDP:

S_OWNER : o=TLPMSXP2 22660 22661 IN IP4 69.90.230.210
S_NAME : s=sip call
S_CONNECT : c=IN IP4 69.90.230.217
TIME : t=0 0

Could anyone please let me know if that is okay to increment the session version and if any supported document is there?

Thanks,
Nitin


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.



--
They can because they think they can.


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
isshed | 10 Mar 2011 12:16
Picon

Warning header

Hi All, 
 
If an initial INVITE from an endpoint offer contains the sdp as follows.
 
m=audio 15190 RTP/AVP 100 101\r\n
a=fmtp:18 annexb=yes\r\n
a=fmtp:101 0-15\r\n
a=rtpmap:100 UNACCEPTABLECODEC/8000\r\n
a=sendrecv
 
the terminating endpoint returns an error response 488 with a warning header as follows.
 
Warning: 306 132.177.120.67:5060 "Attribute not understood"
 
Is 306 is correct response?
 
Thanks,
 
 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Christer Holmberg | 10 Mar 2011 12:23
Picon
Favicon

Re: Warning header

Hi,

Per section 20.43 of RFC 3261, 306 seems like a good value.

 "306 Attribute not understood: One or more of the media attributes
      in the session description are not supported."

Note that it is not a SIP response code, but a code supposed to give additional information about the response.

Regards,

Christer

________________________________

	From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of isshed
	Sent: 10. maaliskuuta 2011 13:17
	To: sip <at> ietf.org; sip-implementors
	Subject: [Sip] Warning header
	
	
	Hi All, 
	 
	If an initial INVITE from an endpoint offer contains the sdp as follows.
	 
	m=audio 15190 RTP/AVP 100 101\r\n
	a=fmtp:18 annexb=yes\r\n
	a=fmtp:101 0-15\r\n
	a=rtpmap:100 UNACCEPTABLECODEC/8000\r\n
	a=sendrecv
	 
	the terminating endpoint returns an error response 488 with a warning header as follows.
	 
	Warning: 306 132.177.120.67:5060 "Attribute not understood"
	 
	Is 306 is correct response?
	 
	Thanks,
	 

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

isshed | 10 Mar 2011 13:24
Picon

Re: Warning header

Thanks for reply..
 
what about the addiftional info response 305 or 307?
 
My question is which one is best suited here?
Thanks,
Harendra
On Thu, Mar 10, 2011 at 4:53 PM, Christer Holmberg <christer.holmberg <at> ericsson.com> wrote:
Hi,

Per section 20.43 of RFC 3261, 306 seems like a good value.

 "306 Attribute not understood: One or more of the media attributes
     in the session description are not supported."

Note that it is not a SIP response code, but a code supposed to give additional information about the response.

Regards,

Christer






________________________________

       From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of isshed
       Sent: 10. maaliskuuta 2011 13:17
       To: sip <at> ietf.org; sip-implementors
       Subject: [Sip] Warning header


       Hi All,

       If an initial INVITE from an endpoint offer contains the sdp as follows.

       m=audio 15190 RTP/AVP 100 101\r\n
       a=fmtp:18 annexb=yes\r\n
       a=fmtp:101 0-15\r\n
       a=rtpmap:100 UNACCEPTABLECODEC/8000\r\n
       a=sendrecv

       the terminating endpoint returns an error response 488 with a warning header as follows.

       Warning: 306 132.177.120.67:5060 "Attribute not understood"

       Is 306 is correct response?

       Thanks,



_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.

Gmane