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

From: Flemming Andreasen <[email-masked]>
Date: Fri, 8 Apr 2016 10:39:34 -0400

Greetings

We recently went through WGLC on the mux-exclusive draft 
(https://www.ietf.org/id/draft-ietf-mmusic-mux-exclusive-03.txt). 
Following the WGLC, a question was raised as to whether we really need 
the mux-exclusive mechanism described in the draft or not. The issue was 
discussed further in the MMUSIC WG meeting this week in Buenos Aires 
which yielded the following outcomes:

- There was agreement that we should have a signaled solution
- It's important to get a solution quickly since this issue is holding 
up progress on other drafts that rtcweb is dependent on
- The only two proposals that got support were "rtcp:0" and 
"rtcp-mux-exclusive"
- Everybody in the room could live with either "rtcp:0" or 
"rtcp-mux-exclusive"
- A hum between the two slightly favored "rtcp-mux-exclusive, but 
overall it was inconclusive in forming a consensus

A couple of key participants in the mailing list discussion (EKR and 
Martin Thomson) were not able to attend to attend the MMUSIC session, 
however Christer subsequently met with them, and they they graciously 
agreed to respect the consensus established in the meeting.

Based on all of this, and since we currently have a WG adopted draft for 
rtcp-mux-exclusive that went through a WGLC already, we want to continue 
with the rtcp-mux-exclusive solution. If anybody objects to this, please 
let us know no later than Friday, April 15.

Thanks

     Bo & Flemming (MMUSIC chairs)

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 8 Apr 2016 18:01:28 -0400

> let us know no later than Friday, April 15.

I support this direction.

During the meeting I expressed a preference for a=rtcp:0. My reason for 
this is simply that it exists, and thus is better, other things being 
equal, than something new.

However, on further reflection, I'm changing my mind, and preferring 
rtcp-mux-exclusive. The reason is because the O/A behavior for a=rtcp 
doesn't give us an ack for use of rtcp-mux. (RFC3605 says nothing about 
O/A. And given the definition of this attribute, putting it in the 
answer implicitly says where rtcp should be sent to the answerer.)

With rtcp-mux-exclusive we are free to define the O/A behavior. The 
draft already does so, with presence in the answer serving as an ack. So 
this way the offerer will be able to detect if the answerer doesn't 
support this and can then take appropriate remedial action. There may 
still be some RTCP sent to an unassigned port, but the offerer can 
prevent it from continuing.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 8 Apr 2016 18:15:29 -0400

> let us know no later than Friday, April 15.

I support this decision. I always had a preference for rtcp-mux-exclusive
over anything a=rtcp: based since it avoids potential interop issues. I am
not sure how existing implementations will react to a=rtcp:0. This is
something that did no exist before and I am not sure if some
implementations will not break in unexpected way because of a=rtcp:0.

P.S. If some one really cares about the attribute size, we can always shave
5 bytes by renaming the attribute to rtcp-mux-only.

P.P.S. Regardless of what we do, we do need the mux exclusive document.
Upon more careful re-reading of RFC5761 it looks like it requires for the
offerer to provide a fall back RTCP destination when rtcp-mux is not
accepted. We need to update the rtcp-mux-exclusive draft to make sure it
updates RFC5761 to allow offers without RTCP fallback destination.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Apr 2016 18:30:55 +0000

Hi,

...

>P.P.S. Regardless of what we do, we do need the mux exclusive document. Upon more careful re-reading of RFC5761 it looks like it requires for the offerer to provide a fall back RTCP destination when rtcp-mux is not accepted.

That's why I've been saying the whole time - and that's the reason I wrote mix-exclusive to begin with :)

>We need to update the rtcp-mux-exclusive draft to make sure it updates RFC5761 to allow offers without RTCP fallback destination.

Currently, the draft defines that, in addition to the new attribute, you also insert the rtcp-mux attribute. So, if we keep that, I guess we would need to add something to 5761.

But, if we ONLY include the new attribute (I got the impression that's what people prefer), there is no need to update 5761.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 14 Apr 2016 14:37:48 -0400

On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg <
[email-masked]> wrote:

> Currently, the draft defines that, in addition to the new attribute, you
> also insert the rtcp-mux attribute. So, if we keep that, I guess we would
> need to add something to 5761.
>
>
>
> But, if we ONLY include the new attribute (I got the impression that’s
> what people prefer), there is no need to update 5761.
>
>
>
Agreed. I simply wanted to point out the RFC5761 requires to provide an
RTCP fallback when rtcp-mux attribute is used. If RTCP fallback is not
provided and if rtcp-mux attribute is used (which we are doing now in
rtcp-mux-exclusive), then we must update RFC5761 (which we are not doing
now).

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Apr 2016 19:31:42 +0000

Hi,

So, unless someone objects, I’ll remove the usage of the rtcp-mux attribute, and mux exclusive will be indicated using the new attribute only.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 14 April 2016 21:38
To: Christer Holmberg <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>
Subject: Re: [MMUSIC] The way forward wih mux-exclusive

On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Currently, the draft defines that, in addition to the new attribute, you also insert the rtcp-mux attribute. So, if we keep that, I guess we would need to add something to 5761.

But, if we ONLY include the new attribute (I got the impression that’s what people prefer), there is no need to update 5761.

Agreed. I simply wanted to point out the RFC5761 requires to provide an RTCP fallback when rtcp-mux attribute is used. If RTCP fallback is not provided and if rtcp-mux attribute is used (which we are doing now in rtcp-mux-exclusive), then we must update RFC5761 (which we are not doing now).

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 14 Apr 2016 15:49:01 -0400

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.

Also, does anybody want to rename rtcp-mux-exclusive to rtcp-mux-only? This
is shorter and more inline with typical naming convention for such
attributes.

Regards,
_____________
Roman Shpount

On Thu, Apr 14, 2016 at 3:31 PM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> So, unless someone objects, I’ll remove the usage of the rtcp-mux
> attribute, and mux exclusive will be indicated using the new attribute only.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Roman Shpount [mailto:[email-masked]]
> *Sent:* 14 April 2016 21:38
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>
> *Subject:* Re: [MMUSIC] The way forward wih mux-exclusive
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Apr 2016 16:00:47 -0400

On 4/14/16 3:49 PM, Roman Shpount wrote:
> 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?

> Also, does anybody want to rename rtcp-mux-exclusive to rtcp-mux-only?
> This is shorter and more inline with typical naming convention for such
> attributes.

Yes, I like it better.

	Thanks,
	Paul

> Regards,
> _____________
> Roman Shpount
>
> On Thu, Apr 14, 2016 at 3:31 PM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,____
>
>     __ __
>
>     attribute, and mux exclusive will be indicated using the new
>     attribute only.____
>
>     __ __
>
>     Regards,____
>
>     __ __
>
>     Christer____
>
>     __ __
>
>     *From:*Roman Shpount [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Christer Holmberg <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Flemming Andreasen <[email-masked]
>     <mailto:[email-masked]>>; mmusic <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [MMUSIC] The way forward wih mux-exclusive____
>
>     __ __
>
>     On Thu, Apr 14, 2016 at 2:30 PM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:____
>
>         Currently, the draft defines that, in addition to the new
>         attribute, you also insert the rtcp-mux attribute. So, if we
>         keep that, I guess we would need to add something to 5761.____
>
>         ____
>
>         But, if we ONLY include the new attribute (I got the impression
>         that’s what people prefer), there is no need to update 5761.____
>
>         __ __
>
>     __ __
>
>     Agreed. I simply wanted to point out the RFC5761 requires to provide
>     an RTCP fallback when rtcp-mux attribute is used. If RTCP fallback
>     is not provided and if rtcp-mux attribute is used (which we are
>     doing now in rtcp-mux-exclusive), then we must update RFC5761 (which
>     we are not doing now).____
>
>     __ __
>
>     Regards,____
>
>     _____________
>     Roman Shpount____
>
>     ____
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 14 Apr 2016 16:09:59 -0400

> 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).
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Apr 2016 16:19:28 -0400

On 4/14/16 4:09 PM, Roman Shpount wrote:
> On Thu, Apr 14, 2016 at 4:00 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Apr 2016 07:56:40 +0000

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Apr 2016 10:50:37 -0400

> unless another mechanism is used to indicate that such fallback is not

That seems like a good way to handle it.

	Thanks,
	Paul