Subject: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 09:38:39 -0800

I have been reading the mux-exclusive document and I'm not sure it says
quite what we want. Specifically, S 4.2 says:

   When an offerer sends the initial offer, if the offerer wants to
   indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
   offerer MUST associate an SDP 'rtcp-mux-only' attribute with the
   associated SDP media description ("m=" line).

   In addition, if the offerer associates an SDP 'rtcp-mux-only'
   attribute with an SDP media description ("m=" line), the offerer MAY
   also associate an SDP 'rtcp-mux' attribute with the same SDP media
   description ("m=" line), following the procedures in [RFC5761].

As I understand this text, the offerer may say the following things:

 1. No a=rtcp-mux: No muxing.
 2. a=rtcp-mux: I am offering RTCP mux
 3. a=rtcp-mux-only + a=rtcp-mux: I will only do RTCP mux
 4. a=rtcp-mux-only: I will only do RTCP mux (same as #3).

I don't think the last of these is sensible. No current implementation
will know what to do with a=rtcp-mux-only w/o a=rtcp-mux, so this will
result in interop failures. Thus the MAY in the second graf needs to be
a MUST.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 09:41:06 -0800

Following up to myself, I don't think it's sensible for answers to contain
a=rtcp-mux-only, because either you accepted mux, in which case all is
good, or you rejected it, in which case it was rejected.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Fri, 3 Feb 2017 13:05:51 -0500

In 3, offerer sends rtcp-mux and rtcp-mux-only together. If it gets an
answer without either rtcp-mux or rtcp-mux-only, offerer must tear down the
connection.

In 4, offerer sends rtcp-mux-only. If it gets an answer without
rtcp-mux-only, offer must tear down the connection.

In general 3 is redundant and was intended to be used during transition
while rtcp-mux-only is implemented.

Regards,

_____________
Roman Shpount

On Fri, Feb 3, 2017 at 12:41 PM, Eric Rescorla <[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 14:07:21 -0800

> while rtcp-mux-only is implemented.

You can only do 4 once there is no chance that there will ever be a peer
which would do mux but will not recognize rtcp-mux-only. That seems
unlikely to ever occur.

-Ekr

>> Following up to myself, I don't think it's sensible for answers to
>> contain a=rtcp-mux-only, because either you accepted mux, in which case all
>> is good, or you rejected it, in which case it was rejected.
>>
>> -Ekr
>>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Feb 2017 12:48:12 +0000

Hi,

>Following up to myself, I don't think it's sensible for answers to contain a=rtcp-mux-only, because either you accepted mux, in which case all is good, or you rejected it, in which case it was rejected.

While I agree that a=rtcp-mux would be enough in the Answer as far as indicating mux is concerned, including a=rtcp-mux-only in the Answer does indicate that the Answerer supports the mux-exclusive mechanism.

Regards,

Christer

On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
I have been reading the mux-exclusive document and I'm not sure it says
quite what we want. Specifically, S 4.2 says:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Feb 2017 05:07:40 -0800

On Mon, Feb 6, 2017 at 4:48 AM, Christer Holmberg <
[email-masked]> wrote:

> While I agree that a=rtcp-mux would be enough in the Answer as far as
> indicating mux is concerned, including a=rtcp-mux-only in the Answer does
> indicate that the Answerer supports the mux-exclusive mechanism.
>

I don't see how that's really that useful

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Feb 2017 13:57:56 +0000

Hi,

>>>contain a=rtcp-mux-only, because either you accepted mux, in which case
>>>all is good, or you rejected it, in which case it was rejected.
>>
>>indicating mux is concerned, including a=rtcp-mux-only in the Answer
>>does indicate that the Answerer supports the mux-exclusive mechanism.
>

But what harm does it cause?

Regards,

Christer

On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<[email-masked]> wrote:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Feb 2017 06:32:43 -0800

> But what harm does it cause?

I don't think that's the standard here. We should only send indicators in
SDP when they
do something useful.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Feb 2017 08:55:47 +0000

Hi,

We had a long discussion about this, with many different opinions, and it would take some time to go through the archive and check everything. But, one opinion was that it IS useful to send the attribute, as it indicates support of the mechanism.

Regards,

Christer

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux

On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I don't think that's the standard here. We should only send indicators in SDP when they
do something useful.

-Ekr

Regards,

Christer

On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2017 04:23:05 -0800

On Tue, Feb 7, 2017 at 12:55 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> We had a long discussion about this, with many different opinions, and it
> would take some time to go through the archive and check everything. But,
> one opinion was that it IS useful to send the attribute, as it indicates
> support of the mechanism.
>

What does the other side do with that? Is there any precedent for this in
SDP?

-Ekr

>
> Regards,
>
> Christer
>
> From: Eric Rescorla <[email-masked]>
> To: Christer Holmberg <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Feb 2017 17:40:17 +0000

Hi,

>> We had a long discussion about this, with many different opinions, and it would take some time to 
>> go through the archive and check everything. But, one opinion was that it IS useful to send the 
>> attribute, as it indicates support of the mechanism.
>
> What does the other side do with that? 

Well, it knows that it doesn't have to include a=rtcp-mux the next time it wants to do mux-only.

Obviously, as you suggested in your original e-mail, if we wouldn't allow a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin with, it doesn't matter.

> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer

On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <[email-masked]> wrote:
Hi,

-Ekr

Regards,

Christer

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2017 12:33:46 -0800

On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg <
[email-masked]> wrote:

> Obviously, as you suggested in your original e-mail, if we wouldn't allow
> a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin with, it
> doesn't matter.
>

Yeah, I don't think this is a plausible option.

At this point it would be great to hear from anyone who thinks that we
should allow
a=rtcp-mux-only without a=rtcp-mux....

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 7 Feb 2017 15:38:40 -0500

I want to be able to send rtcp-mux-only. I see plenty of scenarios where my
solution communicates exclusively with Web browsers. Once they implement
rtcp-mux-only, given the rate with which browsers are updated, I would
like, at some point, stop using rtcp-mux instead of inserting legacy flag
indefinitely.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2017 15:52:48 -0800

On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount <[email-masked]> wrote:

> I want to be able to send rtcp-mux-only. I see plenty of scenarios where
> my solution communicates exclusively with Web browsers. Once they implement

What resource are you conserving here? It's not exactly consuming a lot of
space in the SDP.

-Ekr

Regards,
>>> Obviously, as you suggested in your original e-mail, if we wouldn't
>>> allow a=rtcp-mux-only without a=rtcp-mux (alt #4) in an offer to begin
>>> with, it doesn't matter.
>>>
>>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 7 Feb 2017 19:26:58 -0500

Essentially a few test cases less to test.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Feb 2017 17:15:00 -0800

It seems like that just moves the load onto everyone else who has to
process both the
case where you have a=rtcp-mux and the one where you do not.

-Ekr

On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount <[email-masked]> wrote:

>> What resource are you conserving here? It's not exactly consuming a lot
>> of space in the SDP.
>>
>> -Ekr
>>
>>
>>
>> Regards,
>>> _____________
>>> Roman Shpount
>>>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 13 Feb 2017 17:02:15 -0500

Hi All,

I got the principal question about rtcp-mux-only. Is it needed only as a
hint to SBC while connection is being established?

It it is a hint to SBC, it does not matter that the answering end point
does not support it. All it says is that offering end point is not
expecting any media on rtp port + 1 and will refuse any connection which
sends it, so SBC does not need to allocate an extra port during setup. If
this is all, we should not insert rtcp-mux-only in the answer and always
must include both rtcp-mux-only and rtcp-mux in the offer.

If my understanding is correct, I agree with Eric's logic and we should
tighten up the mux-exclusive draft.

Regards,

_____________
Roman Shpount

On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorla <[email-masked]> wrote:

>>>> I want to be able to send rtcp-mux-only. I see plenty of scenarios
>>>> where my solution communicates exclusively with Web browsers. Once they
>>>> implement rtcp-mux-only, given the rate with which browsers are updated, I
>>>> would like, at some point, stop using rtcp-mux instead of inserting legacy
>>>> flag indefinitely.
>>>>
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Feb 2017 09:27:29 +0000

Hi,

Just to make sure I understand. You are suggesting:

1. In the offer, the offerer includes BOTH rtcp-mux-only and rtcp-mux. Or, is including rtcp-mux still a MAY?

2. In the answerer, the answerer includes ONLY rtcp-mux. rtcp-mux-only is never used in an answer.

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 14 February 2017 at 00:02
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux

Hi All,

I got the principal question about rtcp-mux-only. Is it needed only as a hint to SBC while connection is being established?

It it is a hint to SBC, it does not matter that the answering end point does not support it. All it says is that offering end point is not expecting any media on rtp port + 1 and will refuse any connection which sends it, so SBC does not need to allocate an extra port during setup. If this is all, we should not insert rtcp-mux-only in the answer and always must include both rtcp-mux-only and rtcp-mux in the offer.

If my understanding is correct, I agree with Eric's logic and we should tighten up the mux-exclusive draft.

Regards,

_____________
Roman Shpount

On Tue, Feb 7, 2017 at 8:15 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
It seems like that just moves the load onto everyone else who has to process both the
case where you have a=rtcp-mux and the one where you do not.

-Ekr

On Tue, Feb 7, 2017 at 4:26 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Essentially a few test cases less to test.

Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
I want to be able to send rtcp-mux-only. I see plenty of scenarios where my solution communicates exclusively with Web browsers. Once they implement rtcp-mux-only, given the rate with which browsers are updated, I would like, at some point, stop using rtcp-mux instead of inserting legacy flag indefinitely.

What resource are you conserving here? It's not exactly consuming a lot of space in the SDP.

-Ekr

Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 3:33 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

At this point it would be great to hear from anyone who thinks that we should allow
a=rtcp-mux-only without a=rtcp-mux....

-Ekr

Regards,

Christer

-Ekr

Regards,

Christer

-Ekr

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Tue, 14 Feb 2017 12:29:42 -0500

Hi,

1. In the offer BOTH rtcp-mux and rtcp-mux-only MUSTbe included
2. In the answer rtcp-mux MUST be included or the session should be
terminated. rtcp-mux-only MUST NOT be included.

This removes any variation on what can and cannot be included in the offer
or the answer.

_____________
Roman Shpount

On Tue, Feb 14, 2017 at 4:27 AM, Christer Holmberg <
[email-masked]> wrote:

> From: Roman Shpount <[email-masked]>
> To: Eric Rescorla <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>, "[email-masked]"
> <[email-masked]>
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Feb 2017 17:32:19 +0000

Hi,

Ben, what is the procedure for making a change in the draft? It’s currently in the RFC editors queue.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 14 February 2017 19:30
To: Christer Holmberg <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux

Hi,

1. In the offer BOTH rtcp-mux and rtcp-mux-only MUSTbe included
2. In the answer rtcp-mux MUST be included or the session should be terminated. rtcp-mux-only MUST NOT be included.

This removes any variation on what can and cannot be included in the offer or the answer.

_____________
Roman Shpount

On Tue, Feb 14, 2017 at 4:27 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Hi All,

Regards,

_____________
Roman Shpount

-Ekr

Regards,
_____________
Roman Shpount

-Ekr

Regards,
_____________
Roman Shpount

-Ekr

Regards,

Christer

-Ekr

Regards,

Christer

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Feb 2017 13:14:33 -0500

> terminated. rtcp-mux-only MUST NOT be included.

Do you mean the RTP session must be terminated, or the *signaling* session?

Requiring the signaling session to be terminated is overreaching. But I 
would agree that refusing the m-line (with port=0) is the proper 
alternative to accepting the rtcp-mux.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 14 Feb 2017 13:45:07 -0500

> alternative to accepting the rtcp-mux.

This should be handled the same way as getting back unexpected or error
answer for a specific m= line. Either RTP session associated with the
specific m= line needs to be terminated with port=0 or the whole signaling
session should be terminated. Most importantly, RTP session associated with
m= line MUST not continue to run expecting RTCP on rtp port + 1.
Essentially, rtcp-mux-only should be treated as a promise by the offering
party that it will not accept an answer without rtcp-mux.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 14 Feb 2017 19:17:25 +0000

Hi,

Also, if the offerer receives an answer, without a=rtcp-mux, it must take proper action for disabling the RTP session associated with the m- line.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 14 February 2017 20:45
To: Paul Kyzivat <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux

On Tue, Feb 14, 2017 at 1:14 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 2/14/17 12:29 PM, Roman Shpount wrote:
Hi,

Requiring the signaling session to be terminated is overreaching. But I would agree that refusing the m-line (with port=0) is the proper alternative to accepting the rtcp-mux.

This should be handled the same way as getting back unexpected or error answer for a specific m= line. Either RTP session associated with the specific m= line needs to be terminated with port=0 or the whole signaling session should be terminated. Most importantly, RTP session associated with m= line MUST not continue to run expecting RTCP on rtp port + 1. Essentially, rtcp-mux-only should be treated as a promise by the offering party that it will not accept an answer without rtcp-mux.

Regards,
_____________
Roman Shpount