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

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.

(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 <andrew.hutton@unify.com> wrote:
>>> I vote for option 2 – Application controls renegotiation through constraint.
>>>
>>>
>>>
>>> Option 1 would be bad.
>>>
>>>
>>>
>>> Option 3 would be very bad.
>>>
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>>
>>> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
>>> Justin Uberti
>>> Sent: 06 November 2013 13:37
>>> To: Michael Procter
>>>
>>>
>>> Cc: rtcweb@ietf.org
>>> 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 <juberti@google.com> 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 <michael@voip.co.uk> wrote:
>>>
>>> On 3 November 2013 22:55, Justin Uberti <juberti@google.com> 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
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>