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

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

On Sat, Jan 23, 2016 at 8:59 AM, Roman Shpount <roman@telurix.com> wrote:

> On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> 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
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>