Subject: [MMUSIC] Why do we need rtcp-mux-exclusive?

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 Mar 2016 15:59:32 -0800

I've been reading this document and I'm finding myself confused about
why we need it.

As I understand it, the current state of play is that mux-only
endpoints will send offers with both a=rtcp-mux and one set of
candidates for each m= line (and with trickle, perhaps no candidates
in the initial offer).  If that offer is processed by a non-mux
endpoint, that endpoint will reject rtcp-mux and then eventually you
end up with a failure to negotiate transport connections because there
will never be RTCP-candidates.

What this draft seems to offer is that a way for the mux-only endpoint
to indicate that it is mux-only, so that non-mux endpoints can instead
fail the connection immediately (section 4.3). So you get a hard
failure instead of a transport failure. Is that correct so far?

If so, here's my problem: because unknown a= lines are ignored, old
endpoints won't know about rtcp-mux-exclusive and so they will just
ignore it. Thus, this attribute is only useful for *new* endpoints
which don't want to do mux (but do know about this attribute). I
suppose that endpoints like that might exist (maybe gateways) but I'm
skeptical that it's worth extra effort to have a hard fail here.

What am I missing here?
-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Mar 2016 08:24:56 +0000

Hi,

>failure instead of a transport failure. Is that correct so far?

Correct.

>skeptical that it's worth extra effort to have a hard fail here.

Unfortunately this is related to a general problem with SDP -you can't mandate support of features (for SIP, one can always define an option tag and place it in a Require header field).

But, we agreed that we want to have an explicit indicator, and then we can only hope people will implement it (by mandating support of it etc).

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Mar 2016 03:57:21 -0800

On Fri, Mar 4, 2016 at 12:24 AM, Christer Holmberg <
[email-masked]> wrote:

> Unfortunately this is related to a general problem with SDP -you can't
> mandate support of features (for SIP, one can always define an option tag
> and place it in a Require header field).
>
> But, we agreed that we want to have an explicit indicator,

My point is that I think that that agreement was wrong and we should not do
so.

and then we can only hope people will implement it (by mandating support of
> it etc).

But again, why would you?

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Mar 2016 12:27:58 +0000

Hi,

>My point is that I think that that agreement was wrong and we should not do so.

I think such statements should be given when the chairs initially ask the community whether it is something we should work on in the first place - not during WGLC, after people have spent time and effort on defining the feature.

>>and then we can only hope people will implement it (by mandating support of it etc).
>

Because then you will have a mechanism to explicitly indicate that you can do mux only, without having to test-and-fail. The current rtcp-mux attribute indicates that you are able to do fallback to non-mux, and entities (endpoints and intermediaries) will have to have resources if that happens.

Also, in non-ICE cases there will be no candidates, so entities will always have to assume that the rtcp-mux attribute indicates possibility to fallback to non-mux.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Mar 2016 04:53:10 -0800

On Fri, Mar 4, 2016 at 4:27 AM, Christer Holmberg <
[email-masked]> wrote:

> I think such statements should be given when the chairs initially ask the
> community whether it is something we should work on in the first place -
> not during WGLC, after people have spent time and effort on defining the
> feature.
>

Yes, I agree it would have been better to have made this comment then,
sorry about
that. Nevertheless, sunk cost seems like a poor reason to continue with a
feature
which is not useful.

> Because then you will have a mechanism to explicitly indicate that you can
> do mux only, without having to test-and-fail. The current rtcp-mux
> attribute indicates that you are able to do fallback to non-mux, and
> entities (endpoints and intermediaries) will have to have resources if that
> happens.
>
> Also, in non-ICE cases there will be no candidates, so entities will
> always have to assume that the rtcp-mux attribute indicates possibility to
> fallback to non-mux.
>

I'm sorry, I'm asking a different question: I don't think there's a problem
with new endpoints
emitting this, but I am skeptical that any old endpoints (i.e., the ones
that presently don't
do mux) will add detection for this rather than just adding mux. Can we
point to a significant
population of implementors which intends to add this?

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Mar 2016 17:34:22 +0000

Hi,

>> I think such statements should be given when the chairs initially ask the community whether it is something we 
>> should work on in the first place - not during WGLC, after people have spent time and effort on defining the feature.
>
>Yes, I agree it would have been better to have made this comment then, sorry about
>that. Nevertheless, sunk cost seems like a poor reason to continue with a feature
>which is not useful.

Well, I do think it is useful to have a mechanism to indicate exclusive mux.

a=rtcp-mux means you support fallback to non-mux, and I don't think we should have a mechanism where people have to do a try-and-fail to figure out that you can't do fallback. I also think it's misuse of the attribute.

>>Because then you will have a mechanism to explicitly indicate that you can do mux only, without having to 
>>test-and-fail. The current rtcp-mux attribute indicates that you are able to do fallback to non-mux, and 
>>entities (endpoints and intermediaries) will have to have resources if that happens.
>>
>I'm sorry, I'm asking a different question: I don't think there's a problem with new endpoints
>emitting this, but I am skeptical that any old endpoints (i.e., the ones that presently don't
>do mux) will add detection for this rather than just adding mux. Can we point to a significant

There are WebRTC gateways that, if they receive a=rtcp-mux, may fallback to non-mux (due to different policies related to radio, the core network etc). 

I know about at least one company that intend to implement a=rtcp-mux-exclusive in the WebRTC gateway. If non-mux is then required in the core network, the gateway will then do mux/non-mux "transcoding".

I also know about SBCs that, if they receive the attribute, will not reserve resources for RTCP, because they know that they don't need to support any fallback.

Now, in earlier versions of the draft, the offerer included BOTH a=rtcp-mux and a=rtcp-mux-exclusive, so that older endpoints (that don't support mux exclusive) would know that the offerer supports mux. Perhaps we should put that back?
 
Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 4 Mar 2016 09:51:31 -0800

On Fri, Mar 4, 2016 at 9:34 AM, Christer Holmberg <
[email-masked]> wrote:

> >> should work on in the first place - not during WGLC, after people have
> spent time and effort on defining the feature.
> >
> a=rtcp-mux means you support fallback to non-mux, and I don't think we
> should have a mechanism where people have to do a try-and-fail to figure
> out that you can't do fallback. I also think it's misuse of the attribute.
>

Well, they're going to fail anyway, so failing fast seems of modest value.

> There are WebRTC gateways that, if they receive a=rtcp-mux, may fallback
> to non-mux (due to different policies related to radio, the core network
> etc).
>

Yes, of course, but the question is how they will behave if they receive
rtcp-mux-exclusive.

I know about at least one company that intend to implement
> a=rtcp-mux-exclusive in the WebRTC gateway. If non-mux is then required in
> the core network, the gateway will then do mux/non-mux "transcoding".
>
> I also know about SBCs that, if they receive the attribute, will not
> reserve resources for RTCP, because they know that they don't need to
> support any fallback.
>

Can we get those implementors to speak up on the list?

Now, in earlier versions of the draft, the offerer included BOTH a=rtcp-mux
> and a=rtcp-mux-exclusive, so that older endpoints (that don't support mux
> exclusive) would know that the offerer supports mux. Perhaps we should put
> that back?
>

I'd rather first resolve whether any change at all is indicated.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Mar 2016 14:13:58 +0000

Hi,

>> a=rtcp-mux means you support fallback to non-mux, and I don't think we should have a mechanism where people 
>> have to do a try-and-fail to figure out that you can't do fallback. I also think it's misuse of the attribute.
>

Entities that don't support the attribute will obviously fail, but at least we would have a mechanism to indicate exclusive mux.

> Yes, of course, but the question is how they will behave if they receive rtcp-mux-exclusive.
 
IF (for whatever reason) non-mux is required on the "other side" of the gateway then the gateway will do "transcoding" between mux and non-mux.

>> I know about at least one company that intend to implement a=rtcp-mux-exclusive in the WebRTC gateway. If 
>> non-mux is then required in the core network, the gateway will then do mux/non-mux "transcoding".
>>

I represent one of those implementers :)

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Mar 2016 06:27:47 -0800

On Sat, Mar 5, 2016 at 6:13 AM, Christer Holmberg <
[email-masked]> wrote:
> IF (for whatever reason) non-mux is required on the "other side" of the
> gateway then the gateway will do "transcoding" between mux and non-mux.
>

Given that essentially every Web browser is going to do only mux, it seems
like the gateway
can just infer this. In fact, since in most of these cases, the gateway and
the Web app are
related entities, that should be extremely straightforward.

> I represent one of those implementers :)

Yes, I had assumed so.

Bottom line, this seems like just another piece of complexity for minimal
value, so I
propose dropping it. Does anyone else want to speak up for it?

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Mar 2016 15:39:31 +0000

Hi,

> Given that essentially every Web browser is going to do only mux, it seems like the gateway
> can just infer this. In fact, since in most of these cases, the gateway and the Web app are

WebRTC is more than browsers, and mux-exclusive is more than WebRTC. There is a general wish to move towards mux. However, that is not going to happen over night.

>Bottom line, this seems like just another piece of complexity for minimal value, so I
>propose dropping it.

I don't see the complexity - it's adding a static attribute without a value, in the same way you add a=rtcp-mux. If your browser is always only going to do mux there is no need for any additional logic or configuration.

Also, I don't agree with minimal value. Reserving RTCP resources that may never be needed, and/or doing mux/non-mux transcoding "just in case" is not minimal. Maybe for single-user device, but not for devices handling large number of users.

And, again, from a protocol perspective, a=rtcp-mux means you are able to fallback, and I don't think we shall break that semantics. There are enough problems related to offer/answer, we don't need to create more on purpose.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Mar 2016 09:10:01 -0800

I think we're just repeating ourselves. Chairs, can we please reserve some
time in
B-A to discuss this?

-Ekr

On Sat, Mar 5, 2016 at 7:39 AM, Christer Holmberg <
[email-masked]> wrote:

> WebRTC is more than browsers, and mux-exclusive is more than WebRTC. There
> is a general wish to move towards mux. However, that is not going to happen
> over night.
>
> I don't see the complexity - it's adding a static attribute without a
> value, in the same way you add a=rtcp-mux. If your browser is always only
> going to do mux there is no need for any additional logic or configuration.
>
> Also, I don't agree with minimal value. Reserving RTCP resources that may
> never be needed, and/or doing mux/non-mux transcoding "just in case" is not
> minimal. Maybe for single-user device, but not for devices handling large
> number of users.
>
> And, again, from a protocol perspective, a=rtcp-mux means you are able to
> fallback, and I don't think we shall break that semantics. There are enough
> problems related to offer/answer, we don't need to create more on purpose.
>
> Regards,
>
> Christer
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 7 Mar 2016 23:03:21 -0500

On 3/5/16 12:10 PM, Eric Rescorla wrote:
> I think we're just repeating ourselves. Chairs, can we please reserve 
> some time in
> B-A to discuss this?

Sure. In the mean-time, we would like to hear from more people on this. 
As Christer noted, there were several people in favor of adopting this 
work when we asked in mid-December 2015, so we would like to understand 
if anything has changed since then.

Thanks

-- Flemming (as MMUSIC co-chair)

> -Ekr
>
>
> On Sat, Mar 5, 2016 at 7:39 AM, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     >> IF (for whatever reason) non-mux is required on the "other
>     side" of the gateway then the gateway will do "transcoding"
>     between mux and non-mux.
>     >
>     WebRTC is more than browsers, and mux-exclusive is more than
>     WebRTC. There is a general wish to move towards mux. However, that
>     is not going to happen over night.
>
>     I don't see the complexity - it's adding a static attribute
>     without a value, in the same way you add a=rtcp-mux. If your
>     browser is always only going to do mux there is no need for any
>     additional logic or configuration.
>
>     Also, I don't agree with minimal value. Reserving RTCP resources
>     that may never be needed, and/or doing mux/non-mux transcoding
>     "just in case" is not minimal. Maybe for single-user device, but
>     not for devices handling large number of users.
>
>     And, again, from a protocol perspective, a=rtcp-mux means you are
>     able to fallback, and I don't think we shall break that semantics.
>     There are enough problems related to offer/answer, we don't need
>     to create more on purpose.
>
>     Regards,
>
>     Christer
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Mar 2016 15:36:03 +1100

On 8 March 2016 at 15:03, Flemming Andreasen <[email-masked]> wrote:
> Sure. In the mean-time, we would like to hear from more people on this. As
> Christer noted, there were several people in favor of adopting this work
> when we asked in mid-December 2015, so we would like to understand if
> anything has changed since then.

I think that Eric is really just taking my earlier email to its
logical conclusion.  The attribute isn't properly justified.  I see
three options:

You might be able to justify it on the basis that it allows
intermediaries visibility into what is going on so that they can avoid
allocating a second component, or maybe some other variant of what
Christer and I discussed.  The draft grows.

Or, you could say that this is just an update to RFC 5761 and you want
to allow for an offerer to offer without RTCP on separate
candidates/port.  That could be a very small RFC.  The draft becomes
tiny.

Or, you could simply conclude that we're going to require mux in some
implementations and live with having no RFC that "defines" that
behaviour.  The draft dies.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Mar 2016 22:03:35 -0800

Martin said:

"Or, you could say that this is just an update to RFC 5761 and you want
to allow for an offerer to offer without RTCP on separate
candidates/port."

[BA] Since this relates to ICE, addressing it in RFC 5761bis does not make
much sense.

"Or, you could simply conclude that we're going to require mux in some
implementations and live with having no RFC that "defines" that
behaviour.  The draft dies."

[BA] If this were solely about browsers, I might agree with you - but it is
not.  Mobile/tablet applications are now incorporating WebRTC source code,
as well as design patterns such as mux and BUNDLE.  Eventually it is
inevitable that those mobile applications will interact with life critical
applications such as health and public safety - and without a
specification, BOOM.

So having a specification that can be cited as a normative reference is
actually quite important.

On Mon, Mar 7, 2016 at 8:36 PM, Martin Thomson <[email-masked]>
wrote:

> As

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Mar 2016 17:21:05 +1100

> [BA] Since this relates to ICE, addressing it in RFC 5761bis does not make

I didn't suggest a -bis, which implies an overhaul, just a small patch.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 07:09:57 +0000

Any opinions?

If I remember correctly, it was mainly Roman who didn't want to use a=ssrc. However, it does seem like a straight forward (and most backward compatible) mechanism.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 08 March 2016 09:19
To: Martin Thomson <[email-masked]>; Bernard Aboba <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Why do we need rtcp-mux-exclusive?

Hi,

We could update 5761, by adding an ³ICE Considerations² section, where we say that a=rtcp-mux and RTP candidates only indicates exclusive mux.
Obviously, we would have to assume that RTCP candidates won¹t be provided later (using trickle).

Another alternative would be to go back to the original suggestion of using a=rtcp:0 (zero port value) to indicate exclusive mux. That would work also for non-ICE. In that case we would need to remove usage of
a=rtcp:0 for trickle ICE, as previously discussed.

Regards,

Christer

On 08/03/16 08:21, "Martin Thomson" <[email-masked]> wrote:

>> [BA] Since this relates to ICE, addressing it in RFC 5761bis does not 
>>make  much sense.
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 9 Mar 2016 07:11:09 -0800

Was ice-options=rtcp-mux-only  considered as a candidate to say this. Since
we are discussing the rtcp-mux-only option  the ICE context ,  ice-options
could be an option and it has  O/A semantics clearly defined.

On Tue, Mar 8, 2016 at 11:09 PM, Christer Holmberg <
[email-masked]> wrote:

> Any opinions?
>
> If I remember correctly, it was mainly Roman who didn't want to use
> a=ssrc. However, it does seem like a straight forward (and most backward
> compatible) mechanism.
>
> Regards,
>
> Christer
>
>
> We could update 5761, by adding an ³ICE Considerations² section, where we
> say that a=rtcp-mux and RTP candidates only indicates exclusive mux.
> Another alternative would be to go back to the original suggestion of
> using a=rtcp:0 (zero port value) to indicate exclusive mux. That would work
> also for non-ICE. In that case we would need to remove usage of

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Mar 2016 11:10:45 -0500

> a=ssrc. However, it does seem like a straight forward (and most backward

I was against a=rtcp for two reasons:

1. There is a conflict with RFC 5245 and things derived from it such as
JSEP which caused confusion. I have proposed the language to
draft-ietf-mmusic-ice-sip-sdp to make a=rtpc optional. I am not sure if
this was accepted or is still being discussed. If this language is accepted
then this reason goes away.

2. I want to limit a=rtcp for non-ICE end points only or only when interop
with non-ICE end points is desired. For anything modern which will not work
without ICE, such as webrtc, there is no reason to specify RTP address in
c= and m= lines, or RTCP address in a=rtcp. I do not want to create new
usages for a=rtcp to keep it alive after it have outlived its usefulness.
For webrtc, including a=rtcp-mux, setting c= address to IN IP4 0.0.0.0, m=
to port 9, and not generating any RTCP ICE candidates should be enough to
indicate what we want to achieve with a=rtcp-mux-only.

As far as a=rtcp-mux-exclusive is concerned, I see it as a optimization
attribute which helps in the following two cases:

1. Tells the remote end point not to allocate RTCP ICE candidates if
trickle ICE is used. This can be an ice-option. I would actually prefer the
ice-option to say the opposite, i.e. that RTCP candidates will be
allocated, since not allocating RTCP candidates will be a much more common
flow.

2. Tells any RTP forwarding intermediaries such as SBC, not to allocate any
resources to forward RTCP. I think this is really marginal

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Mar 2016 16:37:11 +0000

Hi,

>1. There is a conflict with RFC 5245 and things derived from it such as JSEP which caused confusion. I have proposed the language to draft-ietf-mmusic-ice-sip-sdp to make a=rtpc optional. I am not sure if this was accepted or is still being discussed. If this language is accepted then this reason goes away.
>
>2. I want to limit a=rtcp for non-ICE end points only or only when interop with non-ICE end points is desired. For anything modern which will not work without ICE, such as webrtc, there
>is no reason to specify RTP address in c= and m= lines, or RTCP address in a=rtcp. I do not want to create new usages for a=rtcp to keep it alive after it have outlived its usefulness. For webrtc, including
>a=rtcp-mux, setting c= address to IN IP4 0.0.0.0, m= to port 9, and not generating any RTCP ICE candidates should be enough to indicate what we want to achieve with a=rtcp-mux-only.
>
>As far as a=rtcp-mux-exclusive is concerned, I see it as a optimization attribute which helps in the following two cases:
>
>1. Tells the remote end point not to allocate RTCP ICE candidates if trickle ICE is used. This can be an ice-option. I would actually prefer the ice-option to say the opposite, i.e. that RTCP candidates will be allocated, since not allocating RTCP candidates will be a much more common flow.
>
>2. Tells any RTP forwarding intermediaries such as SBC, not to allocate any resources to forward RTCP. I think this is really marginal

I don’t think we should argue about whether we think the associated resource allocation is marginal or not – it is very product/deployment specific.

3. Tells whether a gateway needs to perform "mux transcoding", in case the gateway is connected to a network where usage of mux is not supported (for whatever reason).

I have no problem using ice-options, if that works. But, what happens if an endpoint does not support the received ICE option-tag? Will it simply discard it? If so, how would that be more backward compatible than a new attribute?

And, what about a=rtcp-mux plus RTP candidate, as suggested by Martin? That would probably work, assuming we don’t allow RTCP candidates to be trickled later (I would assume RTP and RTCP candidates are always sent together).

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 9 Mar 2016 13:48:45 -0500

On Wed, Mar 9, 2016 at 11:37 AM, Christer Holmberg <
[email-masked]> wrote:

> I don’t think we should argue about whether we think the associated
> resource allocation is marginal or not – it is very product/deployment
> specific.
>

I agree -- this will be up to the gateway implementer but they are all
doing it now.

3. Tells whether a gateway needs to perform "mux transcoding", in case the
> gateway is connected to a network where usage of mux is not supported (for
> whatever reason).
>

I agree this is another valid example why mux-exclusive is needed

I have no problem using ice-options, if that works. But, what happens if an
> endpoint does not support the received ICE option-tag? Will it simply
> discard it? If so, how would that be more backward compatible than a new
> attribute?
>

I think the real problem is trickle ICE and legacy (which I will cover
later). To solve trickle ICE, indicating that no RTCP candidates will be
allocated should be made part of trickle ICE specification. If trickle ICE
is supported, then end point must understand an ice option which will
indicate that no RTCP candidates should be expected. If trickle ICE is not
supported and all candidates are provided, it should be clear that there
are no rtcp candidates, so no resources for handling rtcp in that direction
is needed.

> And, what about a=rtcp-mux plus RTP candidate, as suggested by Martin?
> That would probably work, assuming we don’t allow RTCP candidates to be
> trickled later (I would assume RTP and RTCP candidates are always sent
> together).
>
>
We kind of need two solutions --  one which works with ICE and another that
works with legacy. If we fix the issue with a=rtcp attribute handling by
draft-ietf-mmusic-ice-sip-sdp and stop requiring it when it serves no
purpose, then we can use a=rtcp-mux plus RTP candidate to indicate
mux-exclusive when ICE is used, and a=rtcp set to RTP address and port when
ICE is not used (legacy). We can use both together (a=rtcp-mux plus RTP and
a=rtcp set to RTP) when ICE with legacy fall back is required.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 14:45:10 +0000

Hi,

…

>We kind of need two solutions --  one which works with ICE and another that works with legacy. If we fix the issue with a=rtcp attribute handling by draft-ietf-mmusic-ice-sip-sdp and stop requiring
>it when it serves no purpose, then we can use a=rtcp-mux plus RTP candidate to indicate mux-exclusive when ICE is used, and a=rtcp set to RTP address and port when ICE is not used (legacy).

I am not sure a=rtcp-mux plus RTP candidate would require removal of a=rtcp usage, because today a=rtcp does not contain the RTP port (as it would in case of mux-exclusive).

>We can use both together (a=rtcp-mux plus RTP and a=rtcp set to RTP) when ICE with legacy fall back is required.

My apologies if you already said it, and I missed it, but how does a=rtcp-mux plus RTP work with trickle? How does the receiver know that the RTCP candidate won’t be trickled later?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Mar 2016 11:03:39 -0400

On Thu, Mar 17, 2016 at 10:45 AM, Christer Holmberg <
[email-masked]> wrote:

> >We kind of need two solutions --  one which works with ICE and another
> that works with legacy. If we fix the issue with a=rtcp attribute
> handling by draft-ietf-mmusic-ice-sip-sdp and stop requiring
> >it when it serves no purpose, then we can use a=rtcp-mux plus RTP
> candidate to indicate mux-exclusive when ICE is used, and a=rtcp set to RTP
> address and port when ICE is not used (legacy).
>
> I am not sure a=rtcp-mux plus RTP candidate would require removal of
> a=rtcp usage, because today a=rtcp does not contain the RTP port (as it
> would in case of mux-exclusive).
>

ICE candidates contain both RTP and RTCP addresses and ports. If all end
points in the deployment support ICE, address in c= line, port in m= line
and a=rtcp are completely redundant. I actually would like to see to move
to "ICE only" solution where there is IN IP4 0.0.0.0 is always specified in
the c= line, port 9 in m= line and no a=rtcp is added. In this scenario a
re-INVITE when ICE candidate is selected is also removed.

> My apologies if you already said it, and I missed it, but how does
> a=rtcp-mux plus RTP work with trickle? How does the receiver know that the
> RTCP candidate won’t be trickled later?
>

What I was proposing that ICE trickle either always requires rtcp-mux or
that there are two ice-option values are defined -- one for trickle with
RTCP and another for trickle with rtcp-mux required where no RTCP
candidates will be trickled later.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 15:19:00 +0000

Hi,

> ICE candidates contain both RTP and RTCP addresses and ports. If all end points in the deployment support ICE, address in c= line, port in m= line and a=rtcp are completely redundant. I actually
> would like to see to move to "ICE only" solution where there is IN IP4 0.0.0.0 is always specified in the c= line, port 9 in m= line and no a=rtcp is added. In this scenario a re-INVITE when ICE candidate is selected is also removed.

I know what you would like to see, but my point was that the a=rtcp-mux plus RTP solution doesn’t require such change, does it?

> What I was proposing that ICE trickle either always requires rtcp-mux or that there are two ice-option values are defined -- one for trickle with RTCP and another for trickle with rtcp-mux required where no RTCP candidates will be trickled later.

I think it’s clumsy to have two different tags for trickle, based on whether RTCP candidates will be provided or not.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Mar 2016 11:29:26 -0400

On Thu, Mar 17, 2016 at 11:19 AM, Christer Holmberg <
[email-masked]> wrote:

> and a=rtcp are completely redundant. I actually
> > would like to see to move to "ICE only" solution where there is IN IP4
> 0.0.0.0 is always specified in the c= line, port 9 in m= line and no a=rtcp
> is added. In this scenario a re-INVITE when ICE candidate is selected is
> also removed.
>
> I know what you would like to see, but my point was that the a=rtcp-mux
> plus RTP solution doesn’t require such change, does it?
>

This enforces something to be specified in c= line, m= line and a=rtcp-mux
attributes. Because of this it prevents removal of those attributes in the
future. Furthermore, since in it reuses a legacy attribute (a=rtcp) in the
way conflicting with original ICE specification it can cause potential
interop problems. Also, all of those values (address in c= line, m= line
port, and a=rtcp) are completely redundant for at least one common use case
-- WebRTC. I think the less you need to specify for the working solution,
the better.

>>> We can use both together (a=rtcp-mux plus RTP and a=rtcp set to RTP)
> when ICE with legacy fall back is required.
> >>
> I think it’s clumsy to have two different tags for trickle, based on
> whether RTCP candidates will be provided or not.
>

This is why I was not against the  a=rtcp-mux-required attribute. We need a
mechanism to specify that no RTCP attributes are coming in trickle. This
can be done the following way:
1. Always require mux exclusive with trickle is used
2. Combine both flags into a single ice=option
3. Specify 2 separate attributes, one to indicate trickle and another to
indicate that no RTCP candidates are coming

I can live with either one of those options. As far as WebRTC is concerned,
option 1 is the easiest and will require the least amount of signaling.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Mar 2016 11:46:53 -0400

On 3/17/16 11:29 AM, Roman Shpount wrote:

> This enforces something to be specified in c= line, m= line and
> a=rtcp-mux attributes. Because of this it prevents removal of those
> attributes in the future.

Why do you want to remove these attributes? What is the harm in having them?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Mar 2016 13:46:52 -0400

> Why do you want to remove these attributes? What is the harm in having

If all parties support ICE, there is no additional useful information
carried by c= line address, m= line port and a=rtcp port address (there was
a typo in my original message where I incorrectly listed a=rtcp-mux). All
this information is already available in ICE candidates. Also, ICE is
trying to keep address information between the selected ICE candidates and
 c=, m=, and a=rtcp synchronized, which causes it to send an extra
re-INVITE.

More importantly, if ICE is used without trickle, if offer is sent with
a=rtcp-mux, c=IN IP4 0.0.0.0, m= line has port 9 and there no RTCP
candidates, this end point achieved all the required goals of
a=rtcp-mux-exclusive. No RTCP will be ever sent to this end point. If
a=rtcp-mux is not present in the answer, connection can be dropped. No
additional resources will be allocated by any intermediaries. This is what
we are trying to solve and we get this for free.

If we require that ICE trickle require a=rtcp-mux, then we get the solution
for free there as well.

All we have left are end points that are not using ICE, but this does not
affect WebRTC, so it is much less time sensitive. For legacy endpoints we
can require a=rtcp set to the same port as RTP, but since this is not
guaranteed to work, and since absence of a=rtcp-mux support can be easily
detected, this is either not a problem at all (if you can tolerate small
number of RTCP packets sent to the random IP:port) or much harder problem
to solve cleanly (since we never know if a=rtcp will be or was supported by
remote).

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Mar 2016 19:25:24 +0000

Roman,

In my opinion, what you are suggesting goes far outside the scope of mux-exclusive.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 17 March 2016 19:47
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] Why do we need rtcp-mux-exclusive?

On Thu, Mar 17, 2016 at 11:46 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

If all parties support ICE, there is no additional useful information carried by c= line address, m= line port and a=rtcp port address (there was a typo in my original message where I incorrectly listed a=rtcp-mux). All this information is already available in ICE candidates. Also, ICE is trying to keep address information between the selected ICE candidates and  c=, m=, and a=rtcp synchronized, which causes it to send an extra re-INVITE.

More importantly, if ICE is used without trickle, if offer is sent with a=rtcp-mux, c=IN IP4 0.0.0.0, m= line has port 9 and there no RTCP candidates, this end point achieved all the required goals of a=rtcp-mux-exclusive. No RTCP will be ever sent to this end point. If a=rtcp-mux is not present in the answer, connection can be dropped. No additional resources will be allocated by any intermediaries. This is what we are trying to solve and we get this for free.

If we require that ICE trickle require a=rtcp-mux, then we get the solution for free there as well.

All we have left are end points that are not using ICE, but this does not affect WebRTC, so it is much less time sensitive. For legacy endpoints we can require a=rtcp set to the same port as RTP, but since this is not guaranteed to work, and since absence of a=rtcp-mux support can be easily detected, this is either not a problem at all (if you can tolerate small number of RTCP packets sent to the random IP:port) or much harder problem to solve cleanly (since we never know if a=rtcp will be or was supported by remote).

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Mar 2016 20:09:06 -0400

> In my opinion, what you are suggesting goes far outside the scope of

It might be going outside of rtcp-mux, but this mostly describes existing
behavior.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Mar 2016 11:40:53 +0000

Hi,

In my opinion, a=rtcp-mux PLUS a=rtcp with RTP port would be an easy was to indicate mux-exclusive, and it would work both with ICE and non-ICE. I don’t think we should define multiple mechanisms for doing the same thing.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Friday 18 March 2016 at 02:09
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Why do we need rtcp-mux-exclusive?

On Thu, Mar 17, 2016 at 3:25 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
In my opinion, what you are suggesting goes far outside the scope of mux-exclusive.

It might be going outside of rtcp-mux, but this mostly describes existing behavior.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Mar 2016 04:54:38 -0400

On Fri, Mar 18, 2016 at 7:40 AM, Christer Holmberg <
[email-masked]> wrote:

> In my opinion, a=rtcp-mux PLUS a=rtcp with RTP port would be an easy was
> to indicate mux-exclusive, and it would work both with ICE and non-ICE. I
> don’t think we should define multiple mechanisms for doing the same thing.
>
>
I would argue that a=rtcp is completely redundant potentially ignored
information. It does not indicate (at least not yet) that trickle will not
generate RTCP candidates. If ICE is used, the absence of RTCP candidates is
enough to indicate that RTCP should not be sent yet. If ICE is not used,
there is no grantee that a=rtcp is not ignored, so it does not help. So, we
can just include rtcp-mux and do not include any RTCP candidates, and we
will get the result we need without any new specifications.

As far as trickle is concerned, it can detect that remote party supports or
does not support rtcp-mux before it allocates any RTCP candidates. If it
will not include any RTPC candidates, no RTCP will be sent to it.

I think this firmly puts the problem with mux-exclusive outside of anything
ICE enabled. If we are dealing with anything non-ICE, I do not think the
backwards compatible solution can be based on a=rtcp since it is not
guaranteed if remote party will honor it. If you want a solution for
legacy, it should be something that replaces the address in c= line and/or
port in m= line to stop remote from sending any RTCP unless it understands
this extension.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Mar 2016 09:43:42 +0000

Hi,

>I would argue that a=rtcp is completely redundant potentially ignored information. It does not indicate (at least not yet) that trickle will not generate RTCP candidates. If ICE is used, the absence of RTCP candidates is enough to indicate that RTCP should not be sent yet. If ICE is not used, there is no grantee that a=rtcp is not ignored, so >it does not help. So, we can just include rtcp-mux and do not include any RTCP candidates, and we will get the result we need without any new specifications.

How does the receiver know that RTCP candidates won’t be trickled later?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Mar 2016 05:59:55 -0400

On Mon, Mar 21, 2016 at 5:43 AM, Christer Holmberg <
[email-masked]> wrote:

> >> In my opinion, a=rtcp-mux PLUS a=rtcp with RTP port would be an easy
> was to indicate mux-exclusive, and it would work both with ICE and non-ICE.
> I don’t think we should define multiple mechanisms for doing the same thing.
> >
> there is no grantee that a=rtcp is not ignored, so >it does not help. So,
> we can just include rtcp-mux and do not include any RTCP candidates, and we
If offer contained rtcp-mux and answer specified rtcp-mux, rtcp-mux will be
used. Because of this, answerer always knows if rtcp-mux is used. Even if
RTCP candidates will be trickled later, they will not be used and can be
safely ignored.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Mar 2016 10:17:25 +0000

Hi,

>>>I would argue that a=rtcp is completely redundant potentially ignored information. It does not indicate (at least not yet) that trickle will not generate RTCP candidates. If ICE is used, the
>>>absence of RTCP candidates is enough to indicate that RTCP should not be sent yet. If ICE is not used, there is no grantee that a=rtcp is not ignored, so >it does not help. So, we can just include rtcp-mux and do not include any RTCP candidates, and we will get the result we need without any new specifications.
>>
> If offer contained rtcp-mux and answer specified rtcp-mux, rtcp-mux will be used. Because of this, answerer always knows if rtcp-mux is used. Even if RTCP candidates will be trickled later, they will not be used and can be safely ignored.

An “mux transcoder” needs to know about exclusive mux when it receives the offer – it cannot wait for the answer.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Mon, 21 Mar 2016 17:35:44 -0400

On Mon, Mar 21, 2016 at 6:17 AM, Christer Holmberg <
[email-masked]> wrote:

> generate RTCP candidates. If ICE is used, the
> >>>absence of RTCP candidates is enough to indicate that RTCP should not
> be sent yet. If ICE is not used, there is no grantee that a=rtcp is not
> ignored, so >it does not help. So, we can just include rtcp-mux and do not
> include any RTCP candidates, and we will get the result we need without any
> new specifications.
> >>
> > If offer contained rtcp-mux and answer specified rtcp-mux, rtcp-mux will
> be used. Because of this, answerer always knows if rtcp-mux is used. Even
> if RTCP candidates will be trickled later, they will not be used and can be
> safely ignored.
>
Are you saying that "mux trancoder" which converts trickle ICE into non-ICE
or non-trickle needs to know in advance that it needs to allocate an RTCP
address/port in the offer it generates on the other side of transcoder?

This is somewhat feasible but extremely marginal. Such transcoder would
have to convert between rtcp-mux and non-mux anyway. Since there is no way
to force rtcp-mux-exclusive on any legacy end points, such transcoder will
need to deal with rtcp-mux mismatch between the two call legs anyway.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Mar 2016 08:51:58 +0000

Hi,

...

> Are you saying that "mux trancoder" which converts trickle ICE into non-ICE or non-trickle needs to know in advance that 
> it needs to allocate an RTCP address/port in the offer it generates on the other side of transcoder?

Yes.

Assume the "mux transcoder" knows that non-mux must be used on the "other side". It needs to know, when it receives the offer, whether the offerer supports fallback to non-mux, or whether the offerer only supports exclusive mux.

The purpose of this work item was to define *A* mechanism where an endpoint can indicate exclusive support of mux.

Regards,

Christer