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

From: [email-masked]
Date: Thu, 4 Oct 2001 19:29:16 +0530

Hi everyone,

Please find my comments below...

>> I am not sure I agree on that. Isn't the 200 for a non-SDP
>> re-INVITE supposed to return the current remote SDP, and if
>> the call has been put on hold that should be a call-hold
>> SDP (ie the SDP that was returned in the 200 for the call
>> hold re-INVITE)?

Just to confirm, the scenario we are talking about is

User A <-----> User B    established with 2 streams (say)
User A  -----> User B    re-INVITE Hold both streams
User A <------ User B    200 OK with Hold SDP (2 way hold)
User A  -----> User B    ACK and session is on hold now.

NOW...
User A  -----> User B    a re-INVITE w/o SDP

Is this correct?

If so, I have a feeling I agree with Brett. A response to a
re-INVITE w/o SDP need not have a held SDP even if the UAS
was earlier put on hold.

REASON: On the list it had earlier been agreed that change
of IP and/or port in ANY offer after the original INVITE
is allowed. In case of responding to a re-INVITE w/o SDP,
the offer is in the 200 OK to this re-INVITE. The UA SHOULD
be allowed to send either of:

1. A hold SDP (like the previous 200 OK response that it sent)
   if it still wants A to be on hold.
2. A unhold SDP as this involves only a change of IP (or
   media stream) as it may now want User A to come off hold.

What the UAS MUST NOT do is add a third stream (in addition
to the 2 already accepted originally). It is free to put one
or more of the 2 "originally in use streams" on/off hold.

Comments please?

Best regards,
Siddharth.

=================================
Siddharth Toshniwal
Software Engineer
Hughes Software Systems, Bangalore
http://www.hssworld.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: "Victor Paulsamy" <[email-masked]>
Date: Thu, 4 Oct 2001 11:48:53 -0700

> or more of the 2 "originally in use streams" on/off hold.

In addition to the above two, the UAS can also send a third new SDP with
addition/deletion/modification of new/old/old streams if it intends, as all
characteristics of a session can be modified.

Comments?

Warm regards,

--victor

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 05 Oct 2001 00:59:38 +0300

Hi,

>   media stream) as it may now want User A to come off hold.

What if we use an SDP attribute, and not the IP address, for the call
hold? In that case this would not work, since the current attribute
value is "on-hold" (or whatever we will use) and the UAS in not allowed
to change that in the 200.

I have no problem with what has been agreed, ie that the IP address
and/or port can change at any time, but I think that changing from hold
to non-hold is a change of STATE (even if SIP currently impelments it
using the 0.0.0.0 IP address).
 
>or more of the 2 "originally in use streams" on/off hold.

What if the UAC - for any reason - only wants the remote SDP, but it
does NOT want the re-INVITE to un-hold the session?

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Victor Paulsamy" <[email-masked]>
Date: Thu, 4 Oct 2001 16:24:35 -0700

Hi,

> or more of the 2 "originally in use streams" on/off hold.
Why the UAS MUST NOT "add" a new stream?

Thanks.

Warm regards,
--victor

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 4 Oct 2001 20:46:51 -0400

> Why the UAS MUST NOT "add" a new stream?

It is tempting since that is what basically 
happens for invite-without-sdp; the UAS adds 
all it desires.  However it serves no real 
purpose within reinvite-without-sdp.  
Some action on the "UAS" would trigger the 
desire to add the extra media stream.  
And if this is the case, it is capable to 
trigger its own reinvite-with-sdp instead 
of waiting for reinvite-without-sdp.

Ultimately I'm indifferent on adding streams 
since the UAS can add it and the UAC can 
delete it.  I think that some objected to
the poor communication as to why the stream
was not accepted.  This is also a problem
for the first invite case.

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 4 Oct 2001 21:48:42 -0400

> When the UAS is thinking of sending a 
> re-INVITE to add a stream, there comes
> a re-INVITE from the UAC without SDP. Can the 
> UAS not seize the opportunity to add a stream.

I find no harm since it makes it consistent with 
invite-without-sdp.  However if the only benefit
is the saving of 3 messages, it was deemed not 
important enough. Otherwise we could have allowed 
the 200 SDP to contain an answer and offer portion.
 
> I'm not seeing the point why it shouldn't be 
> added when *all* characteristics of the 
> session can be changed.

Actually *all* characteristics shouldn't be 
changed.  This was the reason for the open issue.  
After receiving a reinvite-without-sdp, the UAS 
should attempt to not modify the SDP's existing 
media in such a way that would potentially cause 
the UAC to have to hold it, delete it, or release 
the call.  

Thus most of the time it should return 
the previous SDP.  Devices that answer hold to 
holds should not return the previous SDP
unless it desires to keep the call on hold.

---

From: "Victor Paulsamy" <[email-masked]>
Date: Thu, 4 Oct 2001 18:06:55 -0700

Hi Brett,

Thanks for your comment.

> of waiting for reinvite-without-sdp.
When the UAS is thinking of sending a re-INVITE to add a stream, there comes
a re-INVITE from the UAC without SDP. Can the UAS not seize the opportunity
to add a stream. I'm not seeing the point why it shouldn't be added when
*all* characteristics of the session can be changed.

> for the first invite case.
Exactly.

Warm regards,

--victor

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 4 Oct 2001 22:02:55 -0400

> to change that in the 200.

That particular attribute should be allowed 
to change.  I don't recall anyone responding
negatively to the comment when I mentioned it
previously on the thread.

http://www1.ietf.org/mail-archive/working-groups/sip/current/msg01161.html
 
> using the 0.0.0.0 IP address).

Correct.  And the UAS decides if it wants 
to keep the session on hold or allow it to 
be pulled off hold.  
 
> What if the UAC - for any reason - only 
> wants the remote SDP, but it does NOT want 
> the re-INVITE to un-hold the session?

It sends a reinvite-with-sdp.  The UAS can 
keep the session on hold if it desires.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 05 Oct 2001 07:53:14 +0300

Hi,

>previously on the thread.

"That particular attribute"... I was afraid you were going to say that
:) 

In future we may have (or maybe there already exist) other similar
attributes, for other services, and then we suddenly may have to allow
those particular attributes to change too...

For example, someone may come up with some SECURITY related attributes,
some CHARGING related attributes, some other MEDIA related attributes
(echo canceller, silence supression, etc etc etc), some who-knows-what
attributes, that we must be able to change during the session...
 
>to keep the session on hold or allow it to

I think that if the UAS wants to pull off the hold, it should send an
un-hold re-INVITE.
 
>keep the session on hold if it desires.

...or it can return a un-hold SDP in this case too.

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Victor Paulsamy" <[email-masked]>
Date: Fri, 5 Oct 2001 09:52:11 -0700

Hi Brett,

> important enough.
The basic offer/answer model has to be up held here. If the UAS were to
answer an offer, it must not add a stream. However, here the UAS is
offering, wheather or not it is in mid call.

>Otherwise we could have allowed
If the UAS were to return the "previous SDP", what purpose does re-INVITE
without SDP serve?
Warm regards,

--victor

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 5 Oct 2001 13:29:00 -0400

> The basic offer/answer model has to be up 
> held here. If the UAS were to answer an offer, 
> it must not add a stream. However, here the UAS is

As I mentioned previously on this thread,
I agree that it would make things consistent.

> If the UAS were to return the "previous SDP", 
> what purpose does re-INVITE without SDP serve?

It helps to avoid an SDP change loop when 
a 3PCC/B2BUA unholds the session or switches
between lines on behalf of the controlled party.

---

From: "Victor Paulsamy" <[email-masked]>
Date: Fri, 5 Oct 2001 10:41:29 -0700

Hi Brett,
> between lines on behalf of the controlled party.

Could you please elaborate it to help understand?

Thanks in advance.

--victor

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 5 Oct 2001 14:24:08 -0400

> Could you please elaborate it to help understand?

An example of using reinvite-without-sdp is depicted 
within Figure 9: Mid-Call Announcement of 
http://www.softarmor.com/sipwg/drafts/draft-rosenberg-sip-3pcc-02.txt

Using basic SIP without reinvite-without-sdp, 
the SDP change loop could have been introduced.
The controller would have to send "previous" 
SDP in a reinvite on behalf of one party.
However once that party receives a reinvite, 
it can change its SDP; thus triggering another 
invite and potentially a new SDP in response,
thus triggering ... sdp change loop.

A similar sdp change loop is discussed 
within section 2.2 of the same draft.

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 5 Oct 2001 14:44:02 -0400

> attributes, that we must be able to change during the session...

I agree.  That is why I would prefer the 
open issue not be closed with "MUST" 
provide same SDP.  I prefer the 
"SHOULD" text that is currently 
documented within rfc2543bis-04.

It works fine.  Everyone agrees that 
providing modified SDP within the 200 of 
the 200-ACK model doesn't provide good 
negotiation capabilities.  Thus any product that 
doesn't provide an SDP offer in 200 that 
isn't expected to be accepted should be 
aware that the call will likely be torn 
down if the rejecting party doesn't 
"hold" and subsequently send reinvite-with-sdp.

> I think that if the UAS wants to pull off 
> the hold, it should send an un-hold re-INVITE.

I agree; however the UAS only sent hold in 
response to a hold.  Now the UAC is indicating 
it desires to communicate by sending a 
reinvite-without-sdp, the UAS should not return 
hold unless it wishes to keep the media on hold.
The UAC will supply hold or non-hold sdp within
the ACK; and it potentially will 0 port some of
the media streams.  (The deleted streams are 
potentially recoverable based upon another open 
issue.)

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 06 Oct 2001 18:08:22 +0300

Hi,

>>For example, someone may come up with some SECURITY related
>>attributes, some CHARGING related attributes, some other MEDIA related attributes
>I agree.  That is why I would prefer the open issue not be closed with "MUST"
>provide same SDP.  I prefer the "SHOULD" text that is currently

My general opinion is that "SHOULD" makes things even more unclear...
 
>response to a hold.

Well... Someone could argue, that if the UAS is allowed to send un-hold
SDP (assuming the session is on hold) to an INVITE w/o SDP it should
also be allowed to send a hold SDP (assuming the session is not on hold)
to an INVITE w/o SDP...

>Now the UAC is indicating it desires to communicate by sending a
>reinvite-without-sdp, the UAS should not return hold unless it wishes to keep the media on hold.

We should remember that the SDP may include MULTIPLE streams, and maybe
SOME of them are on hold, ie the c=0.0.0.0 was sent for specific
streams, and not for the whole session. 

Then, the UAC "desires to communicate", but ONLY with the streams that
currently are NOT on hold. It wants the others to remain on hold.

>The UAC will supply hold or non-hold sdp within the ACK; and it potentially will 0 port some of
>the media streams.  (The deleted streams are potentially recoverable based upon another open
>issue.)

Yes, that is another issue. Assume the UAC has earlier terminated a
stream by setting the port to zero. However, since the m= line for that
stream must be included in the SDP during the whole session, the UAS
could suddenly change the port to non-zero in a 200 response. Do we want
to allow that?

Regards,

Christer Holmberg
Ericsson Finland