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

On 10/19/12 12:26 PM, Martin Thomson wrote:
> On 19 October 2012 04:55, Hutton, Andrew
> <andrew.hutton@siemens-enterprise.com> 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.

Well, actually it would interrupt the media stream (rtp session).
I agree there are cases where rejecting the offer would make more sense.
That is certainly an option in sip. Deciding whether it is better to 
reject the media stream, or reject the offer can be tricky.

A more important aspect of this scenario is how it is managed on the 
offering side. When Alice makes the attempt, does she assume success and 
immediately put the offered SDP into operation? (And then undo it if the 
offer fails.) Or does the old local/remote SDP remain in effect until 
the answer is received?

SIP says that you must be prepared to receive according to the new offer 
as soon as it is sent. And yet the stuff you are receiving will still be 
in accord to the old o/a until the new offer is received by the 
answerer. And the offerer should still be sending according to the old 
stuff until it receives the answer. Hence there is a time period when 
you need to support *both*. If you switch too soon you may receive old 
stuff you can't deal with. And if you switch too soon and the offer is 
rejected then you will have to switch back, and there will be more 
disruption.

This is pretty ugly, and unless you can actually support both old and 
new concurrently (which many cannot) then you are forced to choose among 
bad choices for how to implement.

But webrtc can't ignore this. It must acknowledge this and provide some 
mechanisms to deal with it.

	Thanks,
	Paul

>> [...] 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.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>