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

[Justin Uberti <[e-mail]>]

On Wed, Nov 6, 2013 at 10:40 PM, Paul Kyzivat <[e-mail]> wrote:

> On 11/6/13 6:48 PM, Harald Alvestrand wrote:
>
>> On 11/06/2013 11:06 PM, Martin Thomson wrote:
>>
>>> The question in the room was:
>>>
>>> Given a negotiated session with "A, B, and C", is an endpoint
>>> permitted to create an offer that includes "D"?
>>>
>>
>> That's not what I heard.
>>
>> What I heard was:
>>
>> X offers A, B and C (codecs being the canonical example).
>> Y answers A (only). That means we have agreement to use A only.
>> X wants to send a new offer.
>>
>
> This is a subset of the possible cases. But lets stick with it for the
> moment.
>
>
>  Three alternatives:
>>
>> 1) X MUST offer A, B and C
>> 2) X MUST offer A (only) if no particular constraint is set, but MUST
>> offer A, B and C if some (to-be-defined) constraint is set.
>> 3) X MAY offer A, and MAY offer A, B and C (nondeterministic behaviour)
>>
>> I like option 2, for the reasons stated (deterministic, seems to do the
>> job).
>>
>
> SDP O/A recommends an offer that contains A, but allows offering B and C
> (or D) without A. Of course that could cause a great deal of pain, but
> maybe X has no choice due to some change of situation.
>
> If JSEP wants to restrict to (2) then I don't see that as a problem. (But
> be prepared for the possibility of *receiving* an offer that doesn't
> contain A.) But I think it also ought to be possible for the non-default
> offer to contain A plus anything else.
>
> 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.


> (Note that audio easily can result in negotiating two codecs, where one of
> them is telephone-events.)
>
>         Thanks,
>         Paul
>
>
>  A great many people said yes, because that is how SDP is most commonly
>>> used.
>>>
>>> I agree that not offering A, B or C would be bad.
>>>
>>> On 6 November 2013 14:01, Hutton, Andrew <[e-mail]>
>>> wrote:
>>>
>>>> I vote for option 2 – Application controls renegotiation through
>>>> constraint.
>>>>
>>>>
>>>>
>>>> Option 1 would be bad.
>>>>
>>>>
>>>>
>>>> Option 3 would be very bad.
>>>>
>>>>
>>>>
>>>> Andy
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of
>>>> Justin Uberti
>>>> Sent: 06 November 2013 13:37
>>>> To: Michael Procter
>>>>
>>>>
>>>> Cc: [e-mail]
>>>> Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
>>>>
>>>>
>>>>
>>>>  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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>  _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>>
>>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>