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

From: [email-masked]
Date: Wed, 3 Oct 2001 12:18:36 +0530

Hi Christer,

 Please find comments inline.

> 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. (This was what Rosenberg had
 proposed in the beginning of this thread...)

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

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?

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

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

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 12:50:52 +0300

Hi,

My comments.

>capabilities of the UAS.

I am talking about a re-INVITE case, ie where the session already has
been established.

>it should have them at time of the re-INVITE w/o SDP. Is it

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.
 
>for the original call should suffice for the re-INVITE as

Not, if the UAC changes something in the SDP it sends in the ACK.
 
>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.
 
>should have the same lines as the INVITE.

I agree. But, like I said, how do we add streams?
 
>and not any additional streams.

"Should" doesn't work here. If it doesn't work, it shall be "MUST NOT".

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland