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

From: [email-masked]
Date: Wed, 3 Oct 2001 15:51:45 +0530

Hi Christer,

Thanks for the reply. Please find my comments inline
again...

>>> Another question related to this SDP-in-the-ACK issue.
>>> Again, assume that the UAS receives a re-INVITE w/o SDP.
>>> It sends back 200 OK with its original SDP. This far,
>>> everything is fine.
>>>
>> Just an aside, I suppose you are referring to the negotiated
>> SDP in the original session and not to the original
>> capabilities of the UAS.
>>
> I am talking about a re-INVITE case, ie where the session
> already has been established.

Same here :) Lets make it clear with an example: the session
is established with 2 streams being accepted originally by the
UAS (say, Mu-law and ADPCM) What I meant to say was this:

The UAS MUST reply back to a re-INVITE without SDP with only
these 2 streams (Mu-law and ADPCM) in the 200 OK to this re-INVITE
regardless of whether the UAS actually supports more streams than
just these 2. (this is what Rosenberg had proposed as the open
issue).

Since these 2 were accepted the first time when INVITE-OK-ACK
took place, the UAC which initiated the re-INVITE should be
supporting the same still.

===========================================================

>>> Then the UAC MUST send its SDP in the ACK. Again, if
>>> the UAS accepts it everything is fine.
>>>
>>> In a previous mail, I asked about what the UAS shall do
>>> if it does not accept the SDP in the ACK. The reason the
>>> UAS doesn't accept it may be because it simply doesn't have
>>> resources.
>>>
>> Is this really possible? Because till the re-INVITE from the
>> other end this very UAS was in session with the other entity.
>> If it had resources for an established call in the first hand,
>> it should have them at time of the re-INVITE w/o SDP. Is it
>> not?
>>
> I am sure this could happen, for example if there is
> some codec change etc involved. Also, there may be some
> SDP attributes, which require some kind of resources,
> included.

===========================================================

>> So assuming that the UAS proposes already negotiated SDP
>> to the UAC who has not sent any SDP in the re-INVITE AND if
>> the UAC accepts these media streams, resource reservation
>> for the original call should suffice for the re-INVITE as
>> well, is it not?
>>
> Not, if the UAC changes something in the SDP it sends in
> the ACK.

Precisely. I agree. The UAC MUST NOT make a proposal for
media in the ACK in any case (!) Whether it is to add a new
stream or any other modification, if the modification is not
proposed in the INVITE, it MUST NOT be proposed in the ACK.

===========================================================

>>> Then, if we have a scenario (someone mentioned some 3pcc
>>> cases) where the SDP must be sent in the ACK, how does the
>>> UAC ADD streams in those cases?
>>>
>> To add streams, the UAC SHOULD do a re-INVITE instead of
>> using the ACK for this purpose. Any counter-offer should not
>> be made in the ACK either case, whether the INVITE came with
>> SDP or not for the same reason as what you mentioned: The
>> UAS would have no way of telling the UAC whether it accepted
>> the added streams or not.
>>
> I know, but I wanted to bring the case up because there seems
> to be scenarios where the SDP must be sent in the ACK. So,
> my questions is if adding of strems is not possible for those
> scenarios.

>>> I assume that the number of m= lines in the ACK must match
>>> the number in the 200 OK from the UAS, so the UAC is not
>>> allowed to add more streams in the ACK SDP.
>> I guess this should be true as even in the offer/answer model
>> of SDP in INVITE and negotiated SDP in 200 OK, the 200 OK
>> should have the same lines as the INVITE.
> I agree. But, like I said, how do we add streams?

No, it is not possible to add streams directly in the ACK.
I have a feeling we both are on consensus with that, are we
not? :) To do so, the end-point will need another re-INVITE.
It will need to store the negotiated session parameters after
the first INVITE-OK-ACK and add to the same in the SDP of
the re-INVITE. No other go... as far as I can see.

This re-INVITE that was sent w/o SDP served no purpose for
adding streams as such. All it would tell you were the current
streams with which the call was established. (Even for this
actually, a re-INVITE w/o SDP should not be used)

===========================================================

>>> And, IF the UAC would be allowed to do that, how does the
>>> UAS then send back a SDP with a new SDP, where the new m=
>>> line is also matched? Using re-INVITE???
>>>
>> No, this should not be allowed. For an offer that is made in
>> 200 OK, the ACK should just contain a response to the offer
>> and not any additional streams.
>>
> "Should" doesn't work here. If it doesn't work, it shall
> be "MUST NOT".

Quite frankly, I'm all for saying "so be it" :) A new media
proposal in ACK for adding streams to the call does not really
make sense to me. It MUST NOT be done. But I might be mistaken...
so anyone who feels its necessary in the ACK instead of a new
re-INVITE can please correct me.

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: Christer Holmberg <[email-masked]>
Date: Wed, 03 Oct 2001 15:33:39 +0300

Hi,

>just these 2. (this is what Rosenberg had proposed as the open

Yes, and so far everything is ok :)
 
>supporting the same still.

True. Again, the issue was if the UAC in the ACK then ADD new streams.

>proposed in the INVITE, it MUST NOT be proposed in the ACK.

That sounds very fine to me, IF the SDP in the ACK MUST be the same as
the original SDP. BUT, can someone then give a case where this is really
needed? If the UAC isn't able to send the original SDP in the re-INVITE,
how can it suddenly then be able to send it in the ACK??????????????? I
mean, if it MUST send the original SDP, it doesn't matter what it
receives in the 200 response to the re-INVITE...

However, my understanding was that the UAC should be able to modify the
existing streams in the ACK SDP (but not add new streams). Is that
wrong?

>I have a feeling we both are on consensus with that, are we

At least I am :) But, again, my concern is if there IS a scenario where
the UAC DOES add streams in the ACK SDP?

>To do so, the end-point will need another re-INVITE.

I couldn't agree more :)
 
>actually, a re-INVITE w/o SDP should not be used)

Yes, and that is related to my question: what is 200/ACK SDP exchange
really needed for, if no party is allowed to change anything in the
SDPs? What is it that can't be done with a re-INVITE/200 SDP
exchange??????

>make sense to me.

Again, it is not only about adding streams, but also about modifying
existing ones.

>It MUST NOT be done. But I might be mistaken...

Again, my understanding is that there ARE some scenarios where the
re-INVITE with SDP can't be used, and in those cases ACK with SDP must
be used, and that is the reason I brought this up in the first place.

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 3 Oct 2001 19:14:03 -0400

> However, my understanding was that the UAC 
> should be able to modify the existing streams 
> in the ACK SDP (but not add new streams). 
> Is that wrong?

You are correct.

<snip>

> the UAC DOES add streams in the ACK SDP?

Within the offer-answer model (both INVITE-200 
and 200-ACK), it is a protocol violation to 
add media streams in the answer.

<snip>

> really needed for, if no party is allowed 
> to change anything in the SDPs? 

After a call has been established and placed 
on hold, a reinvite-without-sdp will likely 
trigger non-hold SDP in the 200 and ACK.
Thus one or both SDP's have changed.

> What is it that can't be done with a 
> re-INVITE/200 SDP exchange??????

The main reason is to avoid an SDP change 
loop associated with using 3PCC/B2BUA 
during active calls.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 04 Oct 2001 08:11:20 +0300

Hi,

>>in the ACK SDP (but not add new streams).

Good :)

>add media streams in the answer.

I agree.

>Thus one or both SDP's have changed.

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

Christer Holmberg
Ericsson Finland