Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)

[Martin Thomson <[e-mail]>]

On 19 October 2012 04:55, Hutton, Andrew
<[e-mail]> wrote:
> On 19 October 2012 07:37 Stefan Hakansson LK wrote:
>> [...] What if Bob's browser could
>> decode
>> both  audio tracks but has resources to handle only one of the video
>> tracks, should it be able to tell so (perhaps with the result that two
>> audio and one video track was added)? Or should the update of the
>> session just fail?
>
> The update to the session should not just fail. Normally in this case the answer would simple reject the one video stream and not the whole offer.

A more interesting case is where Alice decides to (attempt to) switch
codecs.  That decision might even be based on some prior knowledge of
Bob's ability to understand codecs.  Maybe Bob originally offers A and
B, but when Alice decides to upgrade from A to B, that is not a mode
that Bob supports any more.  The session should continue with A.

An answer that rejected the stream would cause an interruption to the session.

> [...] I am also thinking it would be nice if the API provided some way of cancelling an offer and reverting to the original state but if this is putting too much state back in the browser we would need a clearly documented mechanism.

Nice or necessary?  There is already a great deal of state in the browser.

I am actually interested in a small modification to the API for this
case, for outstanding offers there are actually three pieces of SDP in
play: original local description (could be offer or answer), original
remote description (answer or offer) and the new outstanding offer
(which is only ever a local description, the action can be immediate
on the answering side).  We currently have a means to get two of
these: the remote description and (I assume) the local description
that was most recently set.  We do not have a way to get the original
local description.