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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Sep 2001 02:50:56 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Friday, September 07, 2001 6:06 PM
> To: 'Jonathan Rosenberg'
> Cc: [email-masked]
> Subject: RE: [Sip] Open Issue #58: Rejected mid-call SDP in 2xx
> 
> 
> > I suppose that we could say that its a MUST to use the 
> > existing SDP if you
> > know it. A UA that sends a re-INVITE w/o SDP MUST be prepared 
> > for SDP that
> > may be different for the reason you describe. Hopefully its 
> something
> > acceptable. If its not, BYE the call. I don't think we can 
> > reasonably do
> > better. We're already talking about the case where the UA has 
> > failed and
> > recovered.
> > 
> > Sound OK?
>  
> Sounds fine if the above text also includes 
> the portion from your original recommendation 
> concerning the connection address and port 
> potentially changing.  

Just to be clear, you are saying that it is ok for a UA to respond to a
re-invite w/o SDP with an offer that is the same as the previous sdp in all
ways, except a change in ip address and port?

Why is that needed?

> This would specifically 
> be for those devices that respond to holds 
> with holds. 

But the re-invite is not a hold - its an empty invite with no sdp.

> I guess that it would also have
> to accommodate for the new hold SDP format 
> that is being discussed.

I don't see how thats relevant to this bit here. Can you explain?

> 
> The "MUST" also prevents a 3PCC/B2BUA from 
> using a re-INVITE without SDP to potentially 
> get the UA to send an SDP with all media that 
> it would like to use. 

Thats not the purpose of invite w/o sdp.

-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: "Brett Tate" <[email-masked]>
Date: Thu, 20 Sep 2001 19:40:45 -0400

> ways, except a change in ip address and port?

Not in all ways, version would need to increment.
 
> Why is that needed?

This would specifically be for those 
devices that respond to holds with holds. 

Many current products that use the 0.0.0.0 
mechanism for hold, will return 0.0.0.0 in 
response to a hold.

Example:
After a call has been established, 
A sends reinvite with 0.0.0.0 in SDP.  
B responds with 0.0.0.0 in SDP.  
A sends reinvite without SDP to B; 
B should not return 0.0.0.0 in SDP 
unless it desires to keep the session 
on hold.

> I don't see how thats relevant to this bit here. Can you explain?

After a call has been established, 
A sends reinvite with "inactive" in SDP.  
B responds with "inactive" in SDP.  
A sends reinvite without SDP to B; 
B should not return "inactive" in SDP 
unless it desires to keep the session 
inactive.

> Thats not the purpose of invite w/o sdp.

It has that meaning within invite-without-sdp; 
I agree that it doesn't necessarily have
that meaning in reinvite-without-sdp.

I was just stating that "MUST" would mean
that it can't have that meaning within
reinvite-without-sdp.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2001 18:57:05 +0300

Hi,

I think this thread is related to the discussion about the replacements
of media stream.

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... 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)?

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?

Also, I think that one has to live with a moment of silence if he start
changing codecs/ports for a stream during the call - no matter which
method is used. And, how often is one going to that, anyway? Yes, one
may put the call on hold, and/or add/release streams, but that is
another case.

Regards,

Christer Holmberg
Ericsson Finland