Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Sep 2001 02:36:00 -0400

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, September 21, 2001 11:57 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx
> 
> 
> 
> Hi,
> 
> I think this thread is related to the discussion about the 
> replacements
> of media stream.

Not really.

> 
> So, since basic SIP requires the m= lines to be in the same 
> order during
> the session, I don't understand why we should allow re-INVITE without
> SDP in the first place... 

Because we allow INVITE without SDP.
Because its needed for many 3pcc scenarios.

> I thought that one of the ideas of including
> all m= lines during the whole session was to make the system robust. I
> also thought that one of the good things with re-INVITEs was 
> to give the
> call state back to nodes that may have lost it, but how will that
> happend if there is no SDP in the re-INVITE (since there will 
> be none in
> the ACK either)?

In most cases recovery will work here just fine as well. The UAS (which has
presumably failed and recovered) will get the INV w/o SDP, and generate an
offer in the 2xx. In many cases this offer is a valid offer as far as the
UAC is concerned (i.e, a single audio stream), and the offer generates an
answer in the ACK.

As I said, the cases where this doesn't work are so far into corner cases it
is not worth worrying about. That in SOME cases for third party call
control, the call cannot be recovered when the UAS implements call recovery
and the UAC sends an INVITE w/o SDP - well, I think thats OK.

> 
> Also, I don't like the idea of using ACK. I think we have to 
> accept that
> basic SIP has an offer/answer model for the media 
> negoatiation - nothing
> else. If A doesn't like the parameters it gets back from B it 
> simply has
> to send a new re-INVITE, or a BYE, but NOT "change the media 
> parameters"
> back in the ACK. It is not even sure that B manages to do that, and
> since there is no response to ACK, how does it inform A about that?

No one has proposed that. Everything is offer/answer. The offer/answer can
be in INV/200 or 200/ACK. 

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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2001 10:55:47 +0300

Hi,

>>order during the session, I don't understand why we should allow re-INVITE without
>>I thought that one of the ideas of including all m= lines during the whole session was to make the system >>robust. I also thought that one of the good things with re-INVITEs was
>>to give the call state back to nodes that may have lost it, but how will that
>>be none in the ACK either)?

Oki.

So, if the UAS receives a re-INVITE w/o SDP, and then also receives an
ACK w/o SDP, what does it do? For the initial INVITE, it probably
releases the call, because it's a protocol error. Does the UAS do the
same here, or should it assume that the UAC SDP has not changed?
 
>and the UAC sends an INVITE w/o SDP - well, I think thats OK.

Do you know if anyone has looked into how/if this will work with with
the manyfolks resource reservation mechanism? If it does not, these 3pcc
scenarios can't use it.

>>accept that basic SIP has an offer/answer model for the media
>>negoatiation - nothing else. If A doesn't like the parameters it gets back from B it
>>simply has to send a new re-INVITE, or a BYE, but NOT "change the media
>>parameters" back in the ACK. It is not even sure that B manages to do that, and

Oki. Good. My missunderstanding.

Regards,

Christer Holmberg
Ericsson Finland