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

[[e-mail] (Dale R. Worley)]

[re-sent with the correct From address]

> From: Stefan Hakansson LK <[e-mail]>
> 
> One discussion I think we've not had yet is the granularity the API 
> could report "can't use this SDP blob" on. Say that a new offer (in on 
> ongoing sessions) was received indicating the addition of two audio and 
> two video tracks (from Alice to Bob). 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?

Within the use case of a WebRTC server/SIP gateway, whenever the
WebRTC client requests an update of SDP, the SIP far end UA can reject
the update.  (In regard to current practice, most of the time a UA
will accept the part of the SDP that it can and make the rest
inactive, but some transcoding SIP B2BUAs will fix a codec early in
the dialog and refuse any SDP changes after that.  In addition, some
UAs do not support UPDATE at all.)

The SIP gateway needs to be able to report this failure to the WebRTC
client API in a usable way, and the reporting has to be asynchronous
to the SDP update request.  By the rules of SIP, the session state
reverts to the previous session state, but it would be a reasonable
architecture if the gateway was required to execute additional WebRTC
actions to achieve that effect.  (However, the WebRTC client must be
forbidden from rejecting those actions!)

In theory, the reestablishment of the previous SDP state could require
renegotiating ICE (and SRTP keys?), but in practice, that would
require excessive overhead, I think.

Ideally, this does not require the code in the JSEP application to
know specifically that the remote end is a SIP gateway, because we
don't want the WebRTC client applications to have to be specially
coded to support SIP gateways (or any other particular type of WebRTC
server).

Given that these things need to be supported, it is easy for the SIP
gateway to interwork with a WebRTC architecture that allows SDP
updates in states where the SIP signaling does not:  If the SIP
gateway receives a WebRTC SDP update in a state where an update is not
permitted in SIP, it can instead send an update rejection to the
WebRTC client.  This allows the WebRTC offer/answer structure to be
more flexible than the SIP offer/answer structure without hindering
interworking (other than that sometimes WebRTC SDP updates fail).

Dale