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

[Roman Shpount <[e-mail]>]

On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg <
[e-mail]> 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