Re: [MMUSIC] The way forward wih mux-exclusive

On 4/15/16 3:56 AM, Christer Holmberg wrote:
>
> Hi,
>
> First, I am ok to rename the attribute, in order to make it shorter. Roman
> has suggested the name change a few times already, and nobody has
> objected, so I¹ll change it in the next version of the draft.
>
> Second, if we also allow ³a=rtcp-mux², I guess we would need to update
> 5761 by saying something like:
>
> ³By default, the sender of the attribute must be used with RTCP fallback,
> unless another mechanism is used to indicate that such fallback is not
> supported.²

That seems like a good way to handle it.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>
> On 14/04/16 23:19, "mmusic on behalf of Paul Kyzivat"
> <mmusic-bounces@ietf.org on behalf of pkyzivat@alum.mit.edu> wrote:
>
>> On 4/14/16 4:09 PM, Roman Shpount wrote:
>>> On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>
>>>      On 4/14/16 3:49 PM, Roman Shpount wrote:
>>>
>>>          This can currently produce interop problems. With current
>>> usage, if
>>>          rtcp-mux is supported by the remote end point, it will correctly
>>>          negotiate with rtcp-mux-exclusive. If you remove rtcp-mux
>>>          attribute from
>>>          the offer, connection will not be established. This will be
>>>          especially
>>>          important during the migration from rtcp-mux to
>>>          rtcp-mux-exclusive for
>>>          current implementations. Only inserting rtcp-mux-exclusive, of
>>>          cause, is
>>>          better long term, since it is removing redundant information
>>>          from SDP.
>>>
>>>
>>>      So, why not remove use of rtcp-mux as a *requirement* and leave it
>>>      as an implementation tactic for migration?
>>>
>>>
>>> I would be happy to remove this as a "requirement". Specify that it can
>>> be optionally used during the migration. But if we do this we will need
>>> to update RFC5761, since rtcp-mux will be used without RTCP fallback
>>> address being provided (which is required by RFC5761).
>>
>> I guess that "depends". If there is a normative statement about it (even
>> MAY) then I guess you are right. OTOH, maybe not if there is just a note
>> about it, explaining that it it technically a non-conforming usage, and
>> discussing the pros/cons of doing so.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>