Subject: RE: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in INVIT E transaction

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Mar 2001 02:55:31 -0500

> -----Original Message-----
> From: Piotr S. Kossowski [mailto:[email-masked]]
> Sent: Thursday, March 15, 2001 3:24 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'
> Subject: Re: [SIP] RE: [Sip-implementors] Meaning of SDP 'm' line in
> INVITE transaction
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > >
> > >
> > > Generally: If 200 response contains codecs that are not understood
> > > by caller, session probably fail because ACK cannot change session
> > > description. Is it true ? Correct me, if not.
> > 
> > Correct.
> 
> Session fails, but what does it mean in practice ?
> Callee will not know that the session failed since it believed that
> its session description was right. He will wait for media streams
> from caller (till the doomsday, in this case).
> One way to deal with this problem would be sending BYE (immediately 
> after ACK) by the caller (he knows that session failed), but it is not
> pointed out in rfc2543/bis. Additionaly, it is another transaction
> and destroys purity of the protocol (shouldn't a session be
> completely defined in INVITE transaction ?)

RFC2543 already addresses the issue. THe called party will know when it
receives the invite that it has no media in common with the caller. So, it
would NOT return a 200 OK with a non-overlapping set of codecs. Rather, it
would respond with a 488 and a Warning header indicating the problem.

-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

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Ajit Kalele <[email-masked]>
Date: Fri, 16 Mar 2001 14:45:41 +0530

> completely defined in INVITE transaction ?)

RFC2543 already addresses the issue. THe called party will know when
it

receives the invite that it has no media in common with the caller.
So, it

would NOT return a 200 OK with a non-overlapping set of codecs. Rather,
it

Or it will respond with a 415 Unsupported Media Type.

-- Ajit

---

From: "Piotr S. Kossowski" <[email-masked]>
Date: Fri, 16 Mar 2001 13:10:46 +0100

> Or it will respond with a 415 Unsupported Media Type.

In my opinion, 415 response is not reasonable here.
First, the session description was understood. Second, media was 
understood. The only thing that failed was a subset of codecs for
a particular media stream , that equals zero.
The specification says to use 488 or 606 + Warnig, but not 415.
As I scanned the spec, I found only two cases of using 415.
But, frankly speaking, a name "Unsupported media type" is confusing
and could match to this case, in fact.

Regards, Piotr

---

From: Ajit Kalele <[email-masked]>
Date: Fri, 16 Mar 2001 18:50:11 +0530

> In my opinion, 415 response is not reasonable here.

Agreed.

> understood. The only thing that failed was a subset of codecs for a
> particular media stream , that equals zero. The specification says to use
> 488 or 606 + Warnig, but not 415. As I scanned the spec, I found only two
> cases of using 415. But, frankly speaking, a name "Unsupported media type"
> is confusing and could match to this case, in fact.

According to the specs. 488 + warning should be the response.
And as the request may suceed somewhere else 606 should not be sent.

regards
-Ajit