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

[Paul Kyzivat <[e-mail]>]

On 1/24/16 2:36 PM, Suhas Nandakumar wrote:
>
>
> On Sun, Jan 24, 2016 at 10:58 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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.
>
>
> [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

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