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

[Suhas Nandakumar <[e-mail]>]

On Sun, Jan 24, 2016 at 12:21 PM, Paul Kyzivat <[e-mail]>
wrote:

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

[Suhas] .. If i am not wrong, the above proposal doesn't need updates to
RFC3605 and when used in combination with a=rtcp-mux-only the intent is
clear.


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