Re: JSEP proposal

On Tue, Dec 20, 2011 at 2:57 AM, Randell Jesup <randell-ietf@jesup.org>wrote:

> On 12/19/2011 10:48 PM, Justin Uberti wrote:
>
>> On Sun, Dec 18, 2011 at 5:43 PM, Cullen Jennings <fluffy@cisco.com
>> <mailto:fluffy@cisco.com>> wrote:
>>
> >
>
>>    In the scenario where we start with voice and later add video, I
>>    assume that after the initial call is set up, the side that wants to
>>    add video will call the createOffer method then setLocalDescription
>>    and later when the answer is received will call the
>>    setRemoteDescription. Do I have that right ?
>>
>>
>> Yes. The adder of the video will need to keep the old description
>> around, in the event the request is rejected. Alternatively, it could
>> choose to only apply the new local description once the request is
>> accepted, although this could lead to media clipping.
>
>
> Hmmm.  If you're removing video, then the new local description will stop
> receiving video immediately, and if the removal is rejected (and the old
> sdp is re-applied) it will get re-enabled.  Not sure that's a problem, just
> noting.
>

Actually what I wrote in the document was the latter, that the new local
description would not be enabled by the offerer until the description had
been accepted by the answerer. While media clipping can occur from
answerer->offerer in the case where both sides add video at the same time
(due to the race between media and the answer), the most common case for
modifying the session in WebRTC is to add/remove individual streams being
sent by either side, which by its 1-way nature has no clipping risk.


> If you're switching from codec A to codec B and the original negotiation
> only had codec A, then you may have a clipping problem no matter when you
> install the SDP using this API.  In theory, if inner code knew the
> re-invite SDP as well as current it could switch on the first packet that
> implied acceptance of the re-negotiation, but that's an odd case (and
> rarely if ever implemented in current O-A devices).
>
> Definitely need to think through if there are any gotchas with this sort
> of API for re-negotiations - SRTP, codec params, etc.  Perhaps not (since
> normal offer-answer re-negotiation implies something similar to this,
> though perhaps not exactly this).


Right, http://tools.ietf.org/html/rfc3264#section-8 goes through a bunch of
this. The mechanisms it lists for knowing when you can switch to the new
description aren't all that great though; the best suggestion is to try
decoding with both old and new descriptions for some timeout T.

Agree we need to think more about this to see if there are any common cases
that we need to pay attention to.

>
>
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
>