Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

[Justin Uberti <[e-mail]>]

>From the room discussion, I sensed 3 possible options to move forward.
1) MUST NOT renegotiate codecs etc. (new PeerConnection if you want to
renegotiate)
2) MUST NOT renegotiate codecs etc. by default, but MUST support option to
renegotiate (application controls renegotiation through constraint)
3) SHOULD NOT renegotiate codecs etc, but implementation MAY do so if
desired (no application logic needed, but non-deterministic API behavior)

"etc" here would not include anything that would result in the offer
changing from the previously agreed-upon local description, including
codecs, RTP header extensions, RTCP feedback mechanisms, BUNDLE groupings,
or use of FEC/RTX.

I proposed #1 in the room, but see #2 as a reasonable solution. That
provides the application with full control over what it wants, as well as
deterministic behavior.


On Wed, Nov 6, 2013 at 1:29 PM, Justin Uberti <[e-mail]> wrote:

> Yes, it would. But I think the problem still exists for applications that
> don't use partial offer/answers.
>
>
> On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter <[e-mail]>wrote:
>
>> On 3 November 2013 22:55, Justin Uberti <[e-mail]> wrote:
>> > According to section 5.2.5, it seems that this is only the cases for
>> offers
>> > triggered by offerless reINVITEs. I don't think we want to be
>> re-allocating
>> > and negotiating codecs every time we want to make a change to the
>> session
>> > descriptions in use.
>>
>> Would the partial offer/answer work address at least part of this?
>> m-lines that you don't want to change wouldn't need to be advertised
>> at all, rather than being advertised with a restricted codec set.
>>
>> Michael
>>
>
>