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

[Paul Kyzivat <[e-mail]>]

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

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
> 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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On Sat, Jan 23, 2016 at 9:06 AM, Christer Holmberg
>     <[e-mail]
>     <mailto:[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
>
>     _______________________________________________
>     mmusic mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>