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

[Martin Thomson <[e-mail]>]

On 6 November 2013 23:11, Justin Uberti <[e-mail]> wrote:
>>
>> A more complex case is:
>>   X offers A, B, C
>>   Y answers A, B
>>
>> Then X begins using A, and not using B.
>> When doing next offer,
>> 1) X MUST offer A, B, C
>> 2) X MUST offer A, B
>> 3) X MUST offer A
>> 4..N) X MUST offer one of above by default, but may offer more according
>> to some constraint.
>>
>
> X may be using A in this case, but Y may be using B, so #3 would be bad IMO.
> (Remember, the reason for the new offer is because some other property of
> the session changed.)
>
> #2 would be the default behavior, and #1 would be the optional behavior that
> the application could choose.

Thanks to Paul for the example, and I definitely agree with the
requirement that the negotiated (not just in-use) parameters MUST
remain.  That's a given.

My suggestion is that we *don't* add a constraint, we just require the
inclusion of everything.  If you want to constrain codec use, then you
can use the mechanisms that we provide for doing that.  Currently,
that's editing SDP; though we've talked about specific constraints in
the form of { video: { disableCodec: 'VP8' } } or something like that.

I don't want to create a special new set of constraints that will
effectively never get used.

(We do need to be careful about overconstraining implementations by
using MUST here.  Implementations should be encouraged to offer
everything that they can do, but circumstances might change such that
even negotiated codecs can become unavailable.  Any MUST will need to
be modulated.)