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

[Paul Kyzivat <[e-mail]>]

On 10/19/12 5:23 AM, Harald Alvestrand wrote:
> 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"....)

Andy just talked about this.

The existing practice in sip is that the answerer will accept that part 
of the offer that it understands and is willing to use, and refuses the 
rest - by setting the port number to zero in the m-lines it can't/won't 
support.

	Thanks,
	Paul