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

[Roman Shpount <[e-mail]>]

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

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