Subject: Re: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 02:11:20 -0500

This looks like another open issue in sip.
Let us try to resolve it swiftly.

Responses inline.

Paul Kyzivat wrote:

>>>-----Original Message-----
>>>From: Paul Kyzivat [mailto:[email-masked]]
>>>Sent: Thursday, December 06, 2001 11:26 AM
>>>To: Jonathan Rosenberg
>>>Cc: 'Flemming Andreasen'; Henning Schulzrinne; MMUSIC
>>>Subject: Re: Comments on
>>><draft-rosenberg-mmusic-sdp-offer-answer-00.txt>
>>>
>>>
>>>
>>>
>>>Jonathan Rosenberg wrote:
>>>
>>>>This did require the movement of one paragraph from this
>>>>
>>>draft back into
>>>
>>>>bis:
>>>>
>>>>This means that a
>>>>re-{\INVITE} {\MAY} contain no SDP, so that the 200 OK to the
>>>>re-{\INVITE} contains the offer. In this case, the
>>>>offerer {\MUST} offer the same SDP it provided previously.
>>>>
>>>This is to
>>>
>>>>ensure that the offered SDP in the 2xx will be acceptable
>>>>
>>>to the UAC,
>>>
>>>>as there is no way to reject it.
>>>>
>>>>This will appear in bis-06.
>>>>
>>>I think this constraint is too strong.
>>>
>>We had formerly agreed to it in sip (with the additional flexibility that
>>you can change the IP address/port).
>>
> 
> Just because it was agreed to doesn't mean it was right.

No, but you can understand that I am trying to generally continue forwards.

That said, I will reopen it. Its bug 58.

> 
> 
>>>Consider:
>>>
>>>      A                   B
>>>        |   INVITE(sdp)     |  offers codecs X,Y
>>>        |------------------>|
>>>        |      OK(sdp)      |  accepts X, not Y,
>>>        |<------------------|  would have accepted Z if offered
>>>        |      ACK          |
>>>        |------------------>|
>>>        |   INVITE(no sdp)  |
>>>        |------------------>|
>>>        |      OK(sdp)      |  should be able to offer X,Z
>>>        |<------------------|
>>>        |      ACK (sdp)    |
>>>        |------------------>|
>>>
>>>In this standalone case, it probably isn't likely that A will be
>>>interested in Z the second time if it wasn't the first time.
>>>But if A is
>>>a B2BUA, it might be preparing to involve another party that is very
>>>interested in Z.
>>>
>>OK, but in this case it would be a new dialog for the new party, so that you
>>would have no previous sdp.
>>
> 
> I was suggesting that A is a B2BUA bridging between a party C not shown
> above and B. A then decides to replace C with a different one D. So
> there is a new dialog with D, but the dialog between A and B remains.
> Something like the following:
> 
> C                   A                   B
> |   INVITE(sdp)     |                   |  offers codecs X,Y
> |------------------>|                   |
> |                   |   INVITE(sdp)     |  offers codecs X,Y
> |                   |------------------>|
> |                   |      OK(sdp)      |  accepts X, not Y; would
> |                   |<------------------|  have accepted Z if offered
> |                   |      ACK          |
> |    OK(sdp)        |------------------>|  
> |<------------------|                   |  accepts X, not Y
> |    ACK            |                   |
> |------------------>|                   |
>                     |                   |
> D                   |                   |  prepare to xfer to D
> |                   |   INVITE(no sdp)  |
> |                   |------------------>|
> |                   |      OK(sdp)      |  can only offer X
> |                   |<------------------|  (should offer Z too)
> |   INVITE(sdp)     |                   |  "
> |<------------------|                   |
> |   488             |                   |  Fails - D can only do
> |------------------>|                   |  Y & Z, not X.
> 
> //
> 
> |   OK(sdp)         |                   |  If X,Z had been offered
> |------------------>|                   |  would accept Z
> |                   |      ACK (sdp)    |
> |                   |------------------>|  then all is well
>  
> 
> This is too simplistic for a practical call flow, but it makes the
> point.

OK, I see the point. It is a good one.

Generally, I think the problem is this. When using 3pcc, the controller 
wants to connect an existing user to a new user. To do this, it sends a 
re-invite w/o sdp to the existing user, to solicit its SDP in order to 
include it in an invite to a new user. Effectively, this is a new 
session, even though its a re-invite for the existing participant. Thus, 
you want the typical behavior for a new INVITE, which is to send as much 
as you know.

Now, whats interesting is this. The reason we specified that the UA 
should return the last SDP it used, is to maximize the probability that 
this SDP is acceptable. However, in the 3pcc case, even if the  is 
bitwise identical, there are no guarantees. The existing call could be 
audio, the the controller is trying to connect the user to a video-only 
server. Not going to work with the existing SDP.

In these cases, the controller would need to ACK the 2xx from the 
existing user and then BYE.

So, what we need to do is specify that the UA ought to return an SDP 
which is as broad as possible, but still should be acceptable to the 
peer in the case its not 3pcc going on (although I can't think of any 
non-3pcc cases for a mid-dialog re-invite w/o SDP). THis would include:

1. change in IP/port is OK
2. should add as many more codecs as you can, but there must be overlap 
with the previous SDP
3. can add media lines, but must at least be overlapping in a stream 
with the previous sdp

So, there are some issues here. First, we are trying to "guess" what 
changes in SDP would always be acceptable to an existing peer. Since 
whether an SDP is acceptable or not is a matter of local policy, its 
really hard to say. Second, would we need to specify rules for each and 
every parameter in the SDP? Seems like the wrong direction.

Perhaps the best we can do is leave the selection of the SDP up to the 
UA, but provide guidelines. Basically, something like:

1. offer an SDP which has a good chance of being acceptable to the 
existing peer,
2. make the SDP as broad as possible since this could be 3pcc, and you 
don't know what they can do

Thoughts?

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Dec 2001 13:09:02 -0500

Below - Paul

> Let us try to resolve it swiftly.

Agreed.

> That said, I will reopen it. Its bug 58.

Thanks.

> don't know what they can do

Seems like there are conflicting goals for reinvites. We are trying to
assign a particular intent to different patterns of usage. While I don't
have a particular problem in mind, I have the feeling that this is going
to make the protocol inflexible.

I can see two ways out:

1) explicitly communicate an indication of the purpose of the reinvite,
or hints about the kind of response that is expected. This might be
accomplished using a Reason header, or callerprefs, or a new header, or
some combination.

2) don't try to use reinvite for the complex 3pcc case. Instead of using
a no-sdp reinvite, send an OPTIONS in the context of the existing dialog
to the ua being transferred. Then mung the sdp from that and use it to
send an INVITE on hold to the new party being invited. Use the sdp
returned from that to generate a reinvite to the party being
transferred. (I am not sure this is going to work - it is just a concept
at the moment.)

To use OPTIONS in this way would not require any great violence to the
spec, but might require some clarification about how OPTIONS in the
context of an existing dialog should function. For instance section 11.2
currently says "The response code chosen is the same that would have
been chosen had the request been an INVITE." In this case we don't want
that - we don't want the same restrictions on what SDP is returned as
are applied to a reinvite.

3) we can muddle along with the relaxed guidelines you mention above. I
don't see that relaxing the rules that way does any harm. But I think it
might be inconvenient for multimedia UAs, or their users, to always
return sdp for media not currently in play. And if they choose not to do
so, we may not solve the problem at hand. They would perhaps be more
inclined to offer those media if they knew that the other end actually
desired to use them.