[rtcweb] Handling a partially-useful offer (Re: Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting))

[Harald Alvestrand <[e-mail]>]

Forking thread, since this is a new topic....

On 10/19/2012 08:36 AM, Stefan Hakansson LK wrote:
> On 10/19/2012 08:23 AM, Harald Alvestrand wrote:
>> On 10/18/2012 11:10 PM, Dale R. Worley wrote:
>>>> From: Harald Alvestrand <[e-mail]>
>>>>
>>>> But the API never forces the application to send an offer; sending or
>>>> not sending an offer is strictly the application's responsibility.
>>> Is the API able to report that the far end has rejected the offer?
>> The concept of "the far end" (application far end, not RTP far end) and
>> "reject" are application-level concepts, not API-level concepts.
>> So in the context of the API, I can't parse the question.
>>
>> The API can report that it was handed an SDP blob it couldn't use.
>
> 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?

This seems to be something that should be happening to SIP endpoints too.

I can imagine either answering with capabilities reduced to reflect what 
could be handled, accepting the offer followed by generating a new offer 
of reduced capabilities, or rejecting the offer.

What is existing practice in this area? (I would not be surprised if it 
was "it depends"....)