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

[Paul Kyzivat <[e-mail]>]

On 1/25/16 12:57 PM, Christer Holmberg wrote:
> Hi,
>
>>> I don't know whether it would be worth the effort to "replace" a=rtcp, and whether it would really change anything.
>>>
>>> I still claim that we should assume that deployments DO support a=rtcp.
>>
>> My point is that *if* we need to introduce *something* new (e.g.
>> rtcp-mux-only), then a replacement for rtcp would be a better solution, because
>> it would fix more problems, and be no more trouble to implement.
>
> We need to ask ourselves FOR WHAT we would need something new.
>
> Do we need something new in order to indicate an non-RTP+1 RTCP port number? Some people say we don't: as ICE becomes more and more deployed, you will use candidates to indicate the RTCP port number. The a=rtcp value won't even work in many cases - no matter if entities can indicate support for the attribute or not.
>
> Do we need something new in order to indicate exclusive-mux? My opinion is that we do, because e.g. in trickle ICE cases you will not be able to indicate exclusive-mux using candidates.
>
> The launch customers of exclusive-mux are WebRTC enabled browsers, and any entity that wants to communicate with such browsers needs to support ICE.

But, if we need to implement something new anyway, why not have it be 
something, that in addition to specifying exclusive-mux in this case can 
*also* provide a fix to the problems of a=rtcp in other cases?

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: 24. tammikuuta 2016 22:21
>> To: Suhas Nandakumar
>> Cc: Roman Shpount; Christer Holmberg; [e-mail]
>> Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive
>>
>> 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
>>
>