Re: JSEP proposal

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.

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


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 20 December 2011 08:00:37 UTC