Subject: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Jan 2016 14:03:30 -0500

Changing the subject since we are not talking just about BUNDLE any more.

On Thu, Jan 21, 2016 at 1:29 PM, Christer Holmberg <
[email-masked]> wrote:

> I don’t think using a=rtcp for signalling mux-exclusive is new
> functionality. We still use it to signal the RTCP port, which in the case
> of mux-exclusive happens to be same as the RTP port.
>
>
>
I agree rtcp mux exclusive is not entirely new functionality for a=rtcp.
What I am trying to say is that at this point a=rtcp attribute is required
to be generated by ICE but it could be safely ignored when received. It
carries no additional or useful information for anything ICE enabled. It
also not used or carries no useful information when legacy server side NAT
traversal is used. In practice, there is no need to parse a=rtcp or do
anything based on its value. With a=rtcp being used to signal rtcp mux
exclusive, modern end points will need to parse a=rtcp and make decisions
based on its value. This extends the lifetime of the feature which is
essentially under-designed and never operated properly. This is the reason
I was asking for a way to signal mux-exclusive for anything ICE enabled
without relying on a=rtcp. I have no problem with a=rtcp being used to
improve interop with legacy end points, but I do not like seeing new use
scenarios which are centered exclusively around a=rtcp. If we do this, we
run into problem that we need to fix all the exiting a=rtcp problems with
offer/answer, which I do not think is even possible in backwards compatible
manner.

Bottom line -- I would prefer another SDP attribute to signal RTCP mux
exclusive which is negotiated over offer/answer so that both end points can
detect that it is used. This attribute can be used in parallel with a=rtcp,
but I believe a=rtcp will be made totally redundant in this case.

I would also like to update ICE-SDP not include a=rtcp when it carries no
additional information. I believe after switching rtcp mux exclusive to a
different attribute and ICE not being required to insert a=rtcp when it
carries no additional information, a=rtcp will almost never be used in
practical deployments, so the need to fix it disappears.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2016 21:31:40 +0000

Hi,

> Changing the subject since we are not talking just about BUNDLE any more.

Well, I’d like to talk about BUNDLE, and whether it should mandate support of mux-exclusive :)

>> I don’t think using a=rtcp for signalling mux-exclusive is new functionality. We still use it to signal the 
>> RTCP port, which in the case of mux-exclusive happens to be same as the RTP port.
>
> I agree rtcp mux exclusive is not entirely new functionality for a=rtcp. What I am trying to say is that at this point a=rtcp attribute 
> is required to be generated by ICE but it could be safely ignored when received. It carries no additional or useful information for 
> anything ICE enabled. It also not used or carries no useful information when legacy server side NAT traversal is used. In practice, 
> there is no need to parse a=rtcp or do anything based on its value. With a=rtcp being used to signal rtcp mux exclusive, modern 
> end points will need to parse a=rtcp and make decisions based on its value. This extends the lifetime of the feature which is essentially 
> under-designed and never operated properly. This is the reason I was asking for a way to signal mux-exclusive for anything ICE enabled 
> without relying on a=rtcp.
>
> I have no problem with a=rtcp being used to improve interop with legacy end points, but I do not like seeing new use scenarios 
> which are centered exclusively around a=rtcp. If we do this, we run into problem that we need to fix all the exiting a=rtcp problems 
> with offer/answer, which I do not think is even possible in backwards compatible manner.
>
> Bottom line -- I would prefer another SDP attribute to signal RTCP mux exclusive which is negotiated over offer/answer so that both end points 
> can detect that it is used. This attribute can be used in parallel with a=rtcp, but I believe a=rtcp will be made totally redundant in this case.
>
> I would also like to update ICE-SDP not include a=rtcp when it carries no additional information. I believe after switching rtcp mux 
> exclusive to a different attribute and ICE not being required to insert a=rtcp when it carries no additional information, a=rtcp will 
> almost never be used in practical deployments, so the need to fix it disappears.

We can for sure define a new attribute, if people prefer that. 

But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that doesn't support the attribute may start sending RTCP on RTP+1. But, at least the offerer would see from the answer that the answerer does not support mux-exclusive, and can take proper actions.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Jan 2016 17:07:15 -0500

> But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that
> doesn't support the attribute may start sending RTCP on RTP+1. But, at
> least the offerer would see from the answer that the answerer does not
> support mux-exclusive, and can take proper actions.
>

We can define new attribute that specifies address and port for both RTP
and RTCP similar to ICE candidate or a=rtcp attribute and set address in c=
line to IN IP4 0.0.0.0. This way any end point that does not understand
this attribute will send no media.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Jan 2016 08:27:46 +0000

Hi,

> We can define new attribute that specifies address and port for both RTP and RTCP similar to ICE candidate or a=rtcp attribute and set address in c= line to IN IP4 0.0.0.0. This way any end point that does not understand this attribute will send no media.

Another option would be to set the m- line port to zero, like we do for bundle-only. Then, if the answerer doesn't support the attribute, it won't use the m- line.

Example:

c=IN IP4 11.22.33.44
m=0 RTP/AVP 0 99
a=mux-exclusive: 12345  <------- 12345 is the port to be used for RTP and RTCP

Regards,

Christer

---

From: Kevin Dempsey <[email-masked]>
Date: Fri, 22 Jan 2016 09:35:46 +0000

Would changing the protocol field of the m= line make sense in this case?
For example:

c=IN IP4 11.22.33.44
m=12345 RTPMUX/AVP 0 99

Endpoints that don't support mux-exclusive should reject that m= line.

On 22 January 2016 at 08:27, Christer Holmberg <
[email-masked]> wrote:

> Another option would be to set the m- line port to zero, like we do for
> bundle-only. Then, if the answerer doesn't support the attribute, it won't
> use the m- line.
>
> Example:
>
> c=IN IP4 11.22.33.44
> m=0 RTP/AVP 0 99
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Jan 2016 09:53:07 +0000

Hi,

>Would changing the protocol field of the m= line make sense in this case? For example:
>
>c=IN IP4 11.22.33.44
>m=12345 RTPMUX/AVP 0 99
>

I guess it could be done that way, but personally I don't think it would be semantically correct. Also, we use "RTP" when negotiating non-exclusive mux, and when muxing bundled RTP streams.

Regards,

Christer

On 22 January 2016 at 08:27, Christer Holmberg <[email-masked]> wrote:
Hi,

Example:

c=IN IP4 11.22.33.44
m=0 RTP/AVP 0 99

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Jan 2016 11:47:06 +0000

Hi,

Commenting on my own comment.

> a=mux-exclusive: 12345  <------- 12345 is the port to be used for RTP and RTCP

One problem with this solution is that an intermediary that doesn't support the attribute won't know where to forward the media, it the m- line port value is 0. It very likely will assume there will be no media to begin with.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 22 Jan 2016 13:08:58 -0500

On Fri, Jan 22, 2016 at 6:47 AM, Christer Holmberg <
[email-masked]> wrote:

> >> We can define new attribute that specifies address and port for both
> RTP and RTCP similar to ICE candidate or a=rtcp attribute and set address
> in c= line to IN IP4 0.0.0.0. This way any end point that does not
> understand this attribute will send no media.
> >
> One problem with this solution is that an intermediary that doesn't
> support the attribute won't know where to forward the media, it the m- line
> port value is 0. It very likely will assume there will be no media to begin
> with.
>

I always wondered what intermediary we are talking about which is supposed
to know where to forward media. If we are talking about firewalls which
dynamically open ports, then, most of the time it has no access to
signaling information due to use of secure channels. If we are talking
about something that does something to the media and forwards it (rtp proxy
in combination with sip proxy), then we actually want such proxy to support
rtcp mux exclusive or fail the connection for the same reason we want
regular end points to fail during connection setup -- to prevent RTCP from
being sent to unexpected destination.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 23 Jan 2016 14:06:03 +0000

Hi,

>>> But, it still wouldn't solve Paul's issue, that a non-ICE endpoint that doesn't support the attribute may
>>> start sending RTCP on RTP+1. But, at least the offerer would see from the answer that the answerer does 
>>> not support mux-exclusive, and can take proper actions.
>>>
>>> We can define new attribute that specifies address and port for both RTP and RTCP similar to ICE candidate 
>>> or a=rtcp attribute and set address in c= line to IN IP4 0.0.0.0. This way any end point that does not understand 
>> Another option would be to set the m- line port to zero, like we do for bundle-only. Then, if the answerer 
>> doesn't support the attribute, it won't use the m- line.
>>
>> Example:
>>
>> c=IN IP4 11.22.33.44
>> m=0 RTP/AVP 0 99
>> One problem with this solution is that an intermediary that doesn't support the attribute won't know where to 
>> forward the media, it the m- line port value is 0. It very likely will assume there will be no media to begin with.
>
> I always wondered what intermediary we are talking about which is supposed to know where to forward media. If 
> we are talking about firewalls which dynamically open ports, then, most of the time it has no access to signaling information 
> due to use of secure channels. If we are talking about something that does something to the media and forwards it (rtp proxy 
> in combination with sip proxy), then we actually want such proxy to support rtcp mux exclusive or fail the connection for 
> the same reason we want regular end points to fail during connection setup -- to prevent RTCP from being sent to 
> unexpected destination.

If such proxy only forwards what it receives, it doesn't need to support mux-exclusive. It only forwards what it gets. However, if it sees an m- line with port 0, it may not forward anything.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Sat, 23 Jan 2016 11:59:33 -0500

On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg <
[email-masked]> wrote:

> > I always wondered what intermediary we are talking about which is
> supposed to know where to forward media. If
> > we are talking about firewalls which dynamically open ports, then, most
> of the time it has no access to signaling information
> > due to use of secure channels. If we are talking about something that
> does something to the media and forwards it (rtp proxy
> > in combination with sip proxy), then we actually want such proxy to
> support rtcp mux exclusive or fail the connection for
> > the same reason we want regular end points to fail during connection
> setup -- to prevent RTCP from being sent to
> > unexpected destination.
>
> If such proxy only forwards what it receives, it doesn't need to support
> mux-exclusive. It only forwards what it gets. However, if it sees an m-
> line with port 0, it may not forward anything.
>
>
Can you give me an example of the product you are referring to? I was
thinking about http://ag-projects.com/mediaproxy/ and
http://www.rtpproxy.org/ which both generate RTCP.

We are dealing with trade of between not sending unexpected traffic and
backwards compatibility. I do not think there is a way to prevent
unexpected traffic and still work with all the legacy end points. I would
argue that RTCP mux required is not backwards compatible change and should
not work unless it is supported end-to-end. Only backwards compatibility
required should be ability to detect end points that do not support rtcp
mux and not to set the media session with them.

Regards,
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 24 Jan 2016 01:41:11 -0800

I might be repeating some discussions already made. So please forgive me if
all of the below suggestions is beaten to death

*Use-case: Explicitly indicate RTCP Muxing and possibly backward
compatibility*

I support a new attribute along with some rules for existing attributes
which allows backward compatibility (Strong goal of SDP) and also
exclusiveness of RTCP multiplexing

Define a new attribute *"a=rtcp-mux-only" , which *in a offer indicates
that the end-point can't receive rtcp on separate port than rtp.
Also  include a=rtcp attribute with* RTP port *as defined the mux-exclusive
draft todau.

That way even if the answerer who doesn't understand a=rtcp-mux-only, will
still send RTCP to RTP port (as needed for this use-case). The answerer can
do the same or include a=rtcp-mux based on its requirements

When ICE is in usage and the Offer want to support a=rtcp-mux-only, it does
the following
a) include a=rtcp-mux-only
b) include a=rtcp <rtp-port> <-- RTP port
c) include RTCP candidate with port information that matches RTP. No need
to do new turn allocation for RTCP either.

If the answerer doesn't understand a=rtcp-mux-only, it will still multiplex
RTP and RTCP based on the candidate information.

Not sure if i missed all the corner scenarios. Please let me know your
thoughts

Cheers
Suhas

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 24 Jan 2016 13:58:47 -0500

On 1/24/16 4:41 AM, Suhas Nandakumar wrote:
> I might be repeating some discussions already made. So please forgive me
> if all of the below suggestions is beaten to death
>

It is *essential* to indicate the answerer behavior too. For this to 
provide backward support, the answerer who supports must also include 
this attribute in the answer. If it isn't present in the answer, then 
the offerer knows that it hasn't been supported. I think, in that case 
it must reoffer and either provide a port pair, or else drop the media 
stream, to prevent RTCP from going to an uncontrolled port.

I think this ought to be viewed as an update to 3605.

	Thanks,
	Paul

> Also  include a=rtcp attribute with*RTP port *as defined the
> mux-exclusive draft todau.
> That way even if the answerer who doesn't understand a=rtcp-mux-only,
> will still send RTCP to RTP port (as needed for this use-case). The
> answerer can do the same or include a=rtcp-mux based on its requirements
>
>
> When ICE is in usage and the Offer want to support a=rtcp-mux-only, it
> does the following
> c) include RTCP candidate with port information that matches RTP. No
> need to do new turn allocation for RTCP either.
>
> If the answerer doesn't understand a=rtcp-mux-only, it will still
> multiplex RTP and RTCP based on the candidate information.
>
>
> On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         If such proxy only forwards what it receives, it doesn't need to
>         support mux-exclusive. It only forwards what it gets. However,
>         if it sees an m- line with port 0, it may not forward anything.
>
>
>     Can you give me an example of the product you are referring to? I
>     was thinking about http://ag-projects.com/mediaproxy/ and
>     We are dealing with trade of between not sending unexpected traffic
>     and backwards compatibility. I do not think there is a way to
>     prevent unexpected traffic and still work with all the legacy end
>     points. I would argue that RTCP mux required is not backwards
>     compatible change and should not work unless it is supported
>     end-to-end. Only backwards compatibility required should be ability
>     to detect end points that do not support rtcp mux and not to set the
>     media session with them.
>
>     Regards,
>     _____________
>     Roman Shpount
>
>     [email-masked] <mailto:[email-masked]>

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 24 Jan 2016 11:36:01 -0800

On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat <[email-masked]>
wrote:

> provide backward support, the answerer who supports must also include this
> attribute in the answer. If it isn't present in the answer, then the
> offerer knows that it hasn't been supported. I think, in that case it must
> reoffer and either provide a port pair, or else drop the media stream, to
> prevent RTCP from going to an uncontrolled port.
>
>
[Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One where
the agent understands a=rtcp-mux but not the a=rtcp-mux-only and second
where the agent doesn't understand either. Let's think the answerer
behavior in both the cases

Case 1: Agent supports RFC5761 but not mux-only
   In this scenario we mandate that the offer includes RFC5761 a=rtcp-mux
as well whenever he offers with mux-only. Thus the answerer will still MUX
the RTCP to RTP port following RFC5761 rules.

Case 2: Agent doesn't support RFC5761 and mux-only as well
This is  the case where the answerer can process just the RFC3605 a=rtcp
attribute and can either :
       2a) send the rtcp to the port indicated in a=rtcp attribute , thus
effectively muxing
       2b) will think rtcp port specified as being error since it matches
the RTP port and reject the m=line. [[ note: this isn't defined as an error
in RFC3605 ]]

Case 3: Answerer supports RFC5761, Mux-exclusive
   In this successful scenario, the answerer can just include a=rtcp-mux
and a=rtcp-mux-exclusive in its answer and that is good enough for the
Offerer to know that Answerer is able to mux the rtcp traffic towards the
offerer and also wishes to receive muxed (no fallback) rtcp traffic from
the offerer

These seems to convert most of all the cases right

> I think this ought to be viewed as an update to 3605.

[Suhas] Paul, why do you think it needs an update to RFC3605 ?

>>         > I always wondered what intermediary we are talking about which
>> is supposed to know where to forward media. If
>>         > we are talking about firewalls which dynamically open ports,
>> then, most of the time it has no access to signaling information
>>         > due to use of secure channels. If we are talking about
>> something that does something to the media and forwards it (rtp proxy
>>         > in combination with sip proxy), then we actually want such
>> proxy to support rtcp mux exclusive or fail the connection for
>>         > the same reason we want regular end points to fail during
>> connection setup -- to prevent RTCP from being sent to
>>         > unexpected destination.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 24 Jan 2016 15:21:29 -0500

On 1/24/16 2:36 PM, Suhas Nandakumar wrote:
>
>
> On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     provide backward support, the answerer who supports must also
>     include this attribute in the answer. If it isn't present in the
>     answer, then the offerer knows that it hasn't been supported. I
>     think, in that case it must reoffer and either provide a port pair,
>     or else drop the media stream, to prevent RTCP from going to an
>     uncontrolled port.
>
>
>     In this scenario we mandate that the offer includes RFC5761
> a=rtcp-mux as well whenever he offers with mux-only. Thus the answerer
> will still MUX the RTCP to RTP port following RFC5761 rules.
>
>         2a) send the rtcp to the port indicated in a=rtcp attribute ,
> thus effectively muxing
>         2b) will think rtcp port specified as being error since it
> matches the RTP port and reject the m=line. [[ note: this isn't defined
> as an error in RFC3605 ]]
>
>     In this successful scenario, the answerer can just include
> a=rtcp-mux and a=rtcp-mux-exclusive in its answer and that is good
> enough for the Offerer to know that Answerer is able to mux the rtcp
> traffic towards the offerer and also wishes to receive muxed (no
> fallback) rtcp traffic from the offerer
>

Agree.

>     I think this ought to be viewed as an update to 3605.

Maybe that isn't quite right, but it ought to be an update to *something*.

It is mostly a=rtcp that is broken, because it isn't acknowledged. Any 
plausible use of it ends up being broken if the answerer doesn't support 
it, but the offerer has no way of telling that.

a=rtcp-mux is negotiated. So the offerer can tell when the answerer 
doesn't support it. In that case it can take remedial action. There may 
be some stray rtcp packets until that happens. So a=rtcp-mux-only isn't 
really *needed*. What it does is prevent those few stray packets.

But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because it 
doesn't solve cases when the offerer wants separate rtcp, but not on 
port+1, and the answerer doesn't support that.

Perhaps the right solution is to introduce a new attribute to *replace* 
a=rtcp. It would have similar semantics, but require negotiation. It 
could in principle also replace a=rtcp-mux, since if you use the same 
address/port for both rtp and rtcp you are obviously requesting mux. You 
could still use a=rtcp and/or a=rtcp-mux for backward compatibility, but 
if you need rtcp-mux-only semantics, then you could just use this new 
attribute. If it isn't ack'ed, then take remedial action.

This new attribute would have same syntax as a=rtcp, except for the 
name. New rules for it would be:

- if in offer, must also be in answer. The answer gives the port(/addr)
   for the answerer. If the answerer wants port+1 it needs to compute
   what that is and put it in.
- if it is *not* in the offer, it can't be used in the answer. If the
   answerer can't do rtcp on port+1 then it needs to refuse the media
   stream. It could try sending a subsequent offer for what it can do.

- we *could* explicitly allow the port to be set to zero, and/or the
   address to be set to 0.0.0.0, to indicate that rtcp is not desired.
   (Don't know if it is a good idea.)

	Thanks,
	Paul

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 24 Jan 2016 13:58:54 -0800

> Maybe that isn't quite right, but it ought to be an update to *something*.

[Suhas] .. If i am not wrong, the above proposal doesn't need updates to
RFC3605 and when used in combination with a=rtcp-mux-only the intent is
clear.

> doesn't support it. In that case it can take remedial action. There may be
> some stray rtcp packets until that happens. So a=rtcp-mux-only isn't really
> *needed*. What it does is prevent those few stray packets.
>
> a=rtcp. It would have similar semantics, but require negotiation. It could
> in principle also replace a=rtcp-mux, since if you use the same
> could still use a=rtcp and/or a=rtcp-mux for backward compatibility, but if
> you need rtcp-mux-only semantics, then you could just use this new
> This new attribute would have same syntax as a=rtcp, except for the name.
> New rules for it would be:
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2016 07:36:31 +0000

Hi,

...

>When ICE is in usage and the Offer want to support a=rtcp-mux-only, it does the following
>c) include RTCP candidate with port information that matches RTP. No need to do new turn allocation for RTCP either.

Note that suggested ICE text says that if an entity only supports mux there is no need to include RTCP candidates. Instead the entity will only include RTP candidates (there are other mechanisms to indicate whether the entity doesn't support/want to use RTCP to begin with).

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 24 Jan 2016 23:44:18 -0800

On Sun, Jan 24, 2016 at 11:36 PM, Christer Holmberg <
[email-masked]> wrote:

> Note that suggested ICE text says that if an entity only supports mux
> there is no need to include RTCP candidates. Instead the entity will only
> include RTP candidates (there are other mechanisms to indicate whether the
> entity doesn't support/want to use RTCP to begin with).
>
>
[Suhas] As an offerer you have no idea if the Answerer supports RTCP Mux.
So it needs to include RTCP candidates.
This is what RFC5245bis says

"In the case of RTP, this would happen when one agent provides candidates
for RTCP, and the other does not. As another example, the initiating agent
can multiplex RTP and RTCP on the same port [RFC5761]. However, since the
initiating agent doesn't know if the peer agent can perform such
multiplexing, it includes candidates for RTP and RTCP on separate ports. If
the peer agent can perform such  multiplexing, it would include just a
single component for each candidate -- for the combined RTP/RTCP mux. ICE
would end up acting as if there was just a single component for this
candidate."

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2016 07:51:02 +0000

Hi,

>[Suhas] As an offerer you have no idea if the Answerer supports RTCP Mux. So it needs to include RTCP candidates.
>"In the case of RTP, this would happen when one agent provides candidates for RTCP, and the other does not. As another example, the initiating agent can
> multiplex RTP and RTCP on the same port [RFC5761]. However, since the initiating agent doesn't know if the peer agent can perform such multiplexing, it includes 
> candidates for RTP and RTCP on separate ports. If the peer agent can perform such  multiplexing, it would include just a single component for each candidate -- for 
>the combined RTP/RTCP mux. ICE would end up acting as if there was just a single component for this candidate."

The following next text has been discussed on the ICE list:

"     When candidates are obtained, unless the agent knows for sure that
       RTP/RTCP multiplexing will be used (i.e. the agent knows that the
       other agent also supports, and is willing to use, RTP/RTCP
       multiplexing), or unless the agent only supports RTP/RTCP
       multiplexing, the agent MUST obtain a separate candidate for RTCP.
       If an agent has obtained a candidate for RTCP, and ends up using RTP/
       RTCP multiplexing, the agent does not need to perform connectivity
       checks on the RTCP candidate."

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 24 Jan 2016 23:58:02 -0800

On Sun, Jan 24, 2016 at 11:51 PM, Christer Holmberg <
[email-masked]> wrote:

> can
> > multiplex RTP and RTCP on the same port [RFC5761]. However, since the
> multiplexing, it includes
> > candidates for RTP and RTCP on separate ports. If the peer agent can
> perform such  multiplexing, it would include just a single component for
> each candidate -- for
[Suhas]
I see .. however I am not sure about the below statement

" i.e. the agent knows that the other agent also supports, and is willing
to use, RTP/RTCP multiplexing"

what mechanism is available to ensure the *peer supports and is willing to
use  *RTCP multiplexing. At any point as a peer, I can support RTCP Mux but
might decide not to use for a given session. These were the few reasons
that i thought motivated for supporting mux-exclusive in the first place

Regards,

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2016 08:01:20 +0000

Hi,

If you have concerns with the text, please take it to the ICE list :)

Regards,

Christer

From: Suhas Nandakumar [mailto:[email-masked]]
Sent: 25. tammikuuta 2016 9:58
To: Christer Holmberg
Cc: Roman Shpount; [email-masked]; Paul Kyzivat
Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

On Sun, Jan 24, 2016 at 11:51 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

[Suhas]

" i.e. the agent knows that the other agent also supports, and is willing to use, RTP/RTCP multiplexing"

what mechanism is available to ensure the peer supports and is willing to use  RTCP multiplexing. At any point as a peer, I can support RTCP Mux but might decide not to use for a given session. These were the few reasons that i thought motivated for supporting mux-exclusive in the first place

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2016 08:13:58 +0000

Hi,

I don't know whether it would be worth the effort to "replace" a=rtcp, and whether it would really change anything.

I still claim that we should assume that deployments DO support a=rtcp. 

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 24. tammikuuta 2016 22:21
To: Suhas Nandakumar
Cc: Roman Shpount; Christer Holmberg; [email-masked]
Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

On 1/24/16 2:36 PM, Suhas Nandakumar wrote:
> [Suhas] - Agreed Paul. I see backward compatibility in 2 ways. One 
> where the agent understands a=rtcp-mux but not the a=rtcp-mux-only and 
> second where the agent doesn't understand either. Let's think the 
> answerer behavior in both the cases
>
> Case 2: Agent doesn't support RFC5761 and mux-only as well This is  
> the case where the answerer can process just the RFC3605 a=rtcp 
> matches the RTP port and reject the m=line. [[ note: this isn't 
> defined as an error in RFC3605 ]]
>

Agree.

It is mostly a=rtcp that is broken, because it isn't acknowledged. Any plausible use of it ends up being broken if the answerer doesn't support it, but the offerer has no way of telling that.

a=rtcp-mux is negotiated. So the offerer can tell when the answerer doesn't support it. In that case it can take remedial action. There may be some stray rtcp packets until that happens. So a=rtcp-mux-only isn't really *needed*. What it does is prevent those few stray packets.

But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because it doesn't solve cases when the offerer wants separate rtcp, but not on 
port+1, and the answerer doesn't support that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2016 11:36:13 -0500

> I still claim that we should assume that deployments DO support a=rtcp.

My point is that *if* we need to introduce *something* new (e.g. 
rtcp-mux-only), then a replacement for rtcp would be a better solution, 
because it would fix more problems, and be no more trouble to implement.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2016 11:38:34 -0500

On 1/24/16 4:58 PM, Suhas Nandakumar wrote:
>
>
> On Sun, Jan 24, 2016 at 12:21 PM, Paul Kyzivat <[email-masked]
>         On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>
>                  I might be repeating some discussions already made. So
>         please
>                  forgive me
>                  I support a new attribute along with some rules for
>         existing
>                  attributes
>                  Define a new attribute *"a=rtcp-mux-only" , which *in a
>         offer
>                  indicates

My point is that introducing a new replacement for a=rtcp solves the 
problem that rtcp-mux-only solves, but also solves other problems.

	Thanks,
	Paul

>     It is mostly a=rtcp that is broken, because it isn't acknowledged.
>     Any plausible use of it ends up being broken if the answerer doesn't
>     support it, but the offerer has no way of telling that.
>
>     doesn't support it. In that case it can take remedial action. There
>     may be some stray rtcp packets until that happens. So
>     a=rtcp-mux-only isn't really *needed*. What it does is prevent those
>     few stray packets.
>
>     But a=rtcp-mux-only isn't the best answer for fixing a=rtcp, because
>     it doesn't solve cases when the offerer wants separate rtcp, but not
>     on port+1, and the answerer doesn't support that.
>
>     Perhaps the right solution is to introduce a new attribute to
>     *replace* a=rtcp. It would have similar semantics, but require
>     negotiation. It could in principle also replace a=rtcp-mux, since if
>     you use the same address/port for both rtp and rtcp you are
>     obviously requesting mux. You could still use a=rtcp and/or
>     a=rtcp-mux for backward compatibility, but if you need rtcp-mux-only
>     semantics, then you could just use this new attribute. If it isn't
>     ack'ed, then take remedial action.
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 Jan 2016 17:57:59 +0000

Hi,

> rtcp-mux-only), then a replacement for rtcp would be a better solution, because 
> it would fix more problems, and be no more trouble to implement.

We need to ask ourselves FOR WHAT we would need something new.

Do we need something new in order to indicate an non-RTP+1 RTCP port number? Some people say we don't: as ICE becomes more and more deployed, you will use candidates to indicate the RTCP port number. The a=rtcp value won't even work in many cases - no matter if entities can indicate support for the attribute or not.

Do we need something new in order to indicate exclusive-mux? My opinion is that we do, because e.g. in trickle ICE cases you will not be able to indicate exclusive-mux using candidates.

The launch customers of exclusive-mux are WebRTC enabled browsers, and any entity that wants to communicate with such browsers needs to support ICE.

Regards,

Christer

>> where the agent understands a=rtcp-mux but not the a=rtcp-mux-only 
>> and second where the agent doesn't understand either. Let's think the 
>> a=rtcp-mux as well whenever he offers with mux-only. Thus the 
>> answerer will still MUX the RTCP to RTP port following RFC5761 rules.
>>
>>          2a) send the rtcp to the port indicated in a=rtcp attribute 
>> , thus effectively muxing
> on
> you use the same address/port for both rtp and rtcp you are obviously 
> requesting mux. You could still use a=rtcp and/or a=rtcp-mux for 
> backward compatibility, but if you need rtcp-mux-only semantics, then 
> you could just use this new attribute. If it isn't ack'ed, then take remedial action.
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Jan 2016 13:51:51 -0500

On Mon, Jan 25, 2016 at 12:57 PM, Christer Holmberg <
[email-masked]> wrote:

> Do we need something new in order to indicate an non-RTP+1 RTCP port
> number? Some people say we don't: as ICE becomes more and more deployed,
> you will use candidates to indicate the RTCP port number. The a=rtcp value
> won't even work in many cases - no matter if entities can indicate support
> for the attribute or not.
>
> Do we need something new in order to indicate exclusive-mux? My opinion is
> that we do, because e.g. in trickle ICE cases you will not be able to
> indicate exclusive-mux using candidates.
>
> The launch customers of exclusive-mux are WebRTC enabled browsers, and any
> entity that wants to communicate with such browsers needs to support ICE.
>
>
I agree.

If end-points are deployed behind NAT they really should use ICE. If end
points are not deployed behind NAT they do not need a=rtcp. I think what we
need the simplest possible solution that works with end points on public
addresses and end points that use ICE. I think a simple, flag like
negotiated attribute would be ideal for this.

Furthermore, we should decide if we care about few RTCP packets being sent
during the session setup by an end point that does not understand a=rtcp,
a=mux, or new attribute. If we can allow those packets, then flag like
attribute is sufficient. If we need to block those few packets, then we
need to either set c= line to IN IP4 0.0.0.0 or m= line port to 0 and
provide the actual address/port elsewhere.

Finally, whatever design is used, I would like to see something that would
definitely fail to setup the media session when both sides do not support
RTCP mux. What I would like to avoid is an end point continuously sending
RTCP to address/port which is not expecting it. When deploying this can be
a hard issue to detect during the interop testing and it can produce a lot
of interesting and unexpected results. This is one of the reasons I do not
linke a=rtcp only solution.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2016 14:37:57 -0500

> The launch customers of exclusive-mux are WebRTC enabled browsers, and any entity that wants to communicate with such browsers needs to support ICE.

But, if we need to implement something new anyway, why not have it be 
something, that in addition to specifying exclusive-mux in this case can 
*also* provide a fix to the problems of a=rtcp in other cases?

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Jan 2016 14:46:04 -0500

> *also* provide a fix to the problems of a=rtcp in other cases?

What other cases? There is practically no existing usage for a=rtcp. Why
fix something that is not going to be used?
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jan 2016 14:55:39 -0500

On 1/25/16 2:46 PM, Roman Shpount wrote:
> On Mon, Jan 25, 2016 at 2:37 PM, Paul Kyzivat <[email-masked]
>     But, if we need to implement something new anyway, why not have it
>     be something, that in addition to specifying exclusive-mux in this
>     case can *also* provide a fix to the problems of a=rtcp in other cases?
>
>

Do you have data supporting this assertion?

Maybe we can find some. Perhaps from sipits.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 25 Jan 2016 16:10:30 -0500

> Do you have data supporting this assertion?

I believe a=rtcp was developed to work in conjunction with RFC 3489. In
practice such deployment scenarios are recipes for disaster since end
points will end up not getting connected often enough for large groups of
your customers to complain. Such architecture also has serious security
problems. This entire architecture was later completely redesigned (see
https://tools.ietf.org/html/rfc5389#section-2 for more details).

Anything commercially viable is using either something like ICE or host
based NAT traversal. I think we should strongly steer service implementers
towards ICE when NAT support is required and do not extend or promote
a=rtcp based solutions. ICE does mention a=rtcp but it is only used there
for legacy interop with exiting end points which were designed to work with
RFC 3489 derived addresses. I do not think a=rtcp has any use cases beyond
such legacy interop.
_____________
Roman Shpount