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

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Nov 2013 14:45:32 -0700

Section 5.2.2 (Subsequent Offers) says:

    o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
       only include codecs present in the remote description.

    o  The RTP header extensions MUST only include those that are present
       in the remote description.

    o  The RTCP feedback extensions MUST only include those that are
       present in the remote description.

    o  The "a=rtcp-mux" line MUST only be added if present in the remote
       description.

    o  The "a=rtcp-rsize" line MUST only be added if present in the
       remote description.

Including only codecs that were present in the prior answer is a bad 
idea. It doesn't play well with SIP. There is no harm in continuing to 
include all the codecs you support. And it keeps options open for 
changing codecs later.

The same is true for most other things that are being restricted based 
on what was in the last answer. (But I won't say that with certainty 
without checking the semantics of each one.)

For further info, see RFC 6337, especially section 5.1.

	Thanks,
	Paul

---

From: Justin Uberti <[email-masked]>
Date: Sun, 3 Nov 2013 22:55:35 -0800

On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <[email-masked]> wrote:

> Including only codecs that were present in the prior answer is a bad idea.
> It doesn't play well with SIP. There is no harm in continuing to include
> all the codecs you support. And it keeps options open for changing codecs
> later.
>
> The same is true for most other things that are being restricted based on
> what was in the last answer. (But I won't say that with certainty without
> checking the semantics of each one.)
>

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.

Generally I think we should consider that the capabilities of the remote
side will not change unexpectedly during the call, and so full
renegotiation is not needed with each reINVITE. If full renegotiation is
needed, use an INVITE-with-replaces, as Cullen has suggested. This avoids
complicated cases like having to unBUNDLE in mid-call, or re-reserve codecs
that are unlikely to be used.

>
>         Thanks,
>         Paul
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 4 Nov 2013 23:13:34 +0530

Justin,

As the signaling is not defined in WebRTC, it is not possible to assume that the remote side capabilities will not change between browser to browser scenario as well.  RTCWeb Server shall transfer the session using RE-INVITE equivalent functionality. 

Re-INVITE without offer is a power tool in SIP for getting the capabilities before selecting the final codec. It shall be used to initiate the offer from the remote side. One of the INIVTE/Re-INVITE without offer usecase in WebRTC shall be used to get ICE-TCP candidate from the browser wherein the incoming TCP connection is forbidden by the firewall.

Thanks

Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Monday, November 04, 2013 12:26 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

Including only codecs that were present in the prior answer is a bad idea. It doesn't play well with SIP. There is no harm in continuing to include all the codecs you support. And it keeps options open for changing codecs later.

The same is true for most other things that are being restricted based on what was in the last answer. (But I won't say that with certainty without checking the semantics of each one.)

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. 

Generally I think we should consider that the capabilities of the remote side will not change unexpectedly during the call, and so full renegotiation is not needed with each reINVITE. If full renegotiation is needed, use an INVITE-with-replaces, as Cullen has suggested. This avoids complicated cases like having to unBUNDLE in mid-call, or re-reserve codecs that are unlikely to be used.

        Thanks,
        Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 6 Nov 2013 19:10:06 +0000

I would just like to say that I agree with the points raised by Paul and Partha here that it has to be possible for the application to create an offer with a complete set of current capabilities.  The reason for this is of course interoperability with existing SIP implementations which need this.  Having to create a new peer connection and force use of INVITE with replaces doesn’t work well with existing implementations and would be a high cost to pay for what is hopefully a simple API constraint to create a full offer.

Regards
Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Parthasarathi R
Sent: 04 November 2013 09:44
To: 'Justin Uberti'; 'Paul Kyzivat'
Cc: [email-masked]
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

Justin,

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Monday, November 04, 2013 12:26 PM
To: Paul Kyzivat
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
Section 5.2.2 (Subsequent Offers) says:

        Thanks,
        Paul
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Michael Procter <[email-masked]>
Date: Wed, 6 Nov 2013 12:47:22 -0800

> and negotiating codecs every time we want to make a change to the session

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 6 Nov 2013 13:29:52 -0800

Yes, it would. But I think the problem still exists for applications that
don't use partial offer/answers.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 6 Nov 2013 13:37:24 -0800

>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 <[email-masked]> wrote:

> On Wed, Nov 6, 2013 at 12:47 PM, Michael Procter <[email-masked]>wrote:
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 6 Nov 2013 22:01:51 +0000

I vote for option 2 – Application controls renegotiation through constraint.

Option 1 would be bad.

Option 3 would be very bad.

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 06 November 2013 13:37
To: Michael Procter
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:

Michael

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Nov 2013 14:06:19 -0800

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"?

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.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 6 Nov 2013 22:14:05 +0000

> A great many people said yes, because that is how SDP is most commonly

Yes that was my understanding as well and what I thought was meant be renegotiating codecs. There must be a way for the new offer to contain the full set of capabilities which might be greater than those previously negotiated.

Andy

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Nov 2013 03:48:41 +0100

> 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.

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).

-- 
Surveillance is pervasive. Go Dark.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Nov 2013 19:14:34 -0800

> offer A, B and C if some (to-be-defined) constraint is set.
...
> I like option 2, for the reasons stated (deterministic, seems to do the

Yes, I didn't precisely describe the issue, but the discussion and
disagreement was focused on the sub-options of that point.

I'm less concerned about determinism here.  It's SDP already, suck it
up.  The key point of determinism that I consider relevant here is
that A remains in the set (if possible).  I'm perfectly comfortable
with additional codecs appearing in the list.

I don't see a need for constraints, in fact, given that there is no
need to convey the extra options to the answerer.  SDP is mutable.  In
that sense, having all the options enumerated, every time, is actually
highly desirable.  (Note that as a browser vendor you can unilaterally
determine that B and C are no longer "viable options" and then not
include them.)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Nov 2013 22:40:32 -0800

> X wants to send a new offer.

This is a subset of the possible cases. But lets stick with it for the 
moment.

> I like option 2, for the reasons stated (deterministic, seems to do the

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 6 Nov 2013 23:11:01 -0800

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

> 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
>
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
>
>
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of
>>>> Justin Uberti

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Nov 2013 09:52:03 -0800

On 6 November 2013 23:11, Justin Uberti <[email-masked]> wrote:
> 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.)

---

From: Stefan Håkansson LK <[email-masked]>
Date: Thu, 7 Nov 2013 18:06:58 +0000

On 07/11/13 18:52, "Martin Thomson" <[email-masked]> wrote:

>>IMO.

At the last WebRTC teleconf we discussed what media transmission related
constraints we should have for v1, and the consensus at that meeting was
clear: codec selection was not one of them. So if you have to remove
codec(s) from the offer that would have to be done by SDP mangling. I
guess that I¹m trying to say that your suggestion is in line with
consensus at that meeting at least, and also in line with my personal
opinion.

>effectively never get used.

I agree.