Re: Sending a=rtcp-mux-only w/o a=rtcp-mux

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 protected]]
Sent: 14 February 2017 19:30
To: Christer Holmberg <[email protected]>
Cc: Eric Rescorla <[email protected]>; mmusic WG <[email protected]>
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 protected]<mailto:[email protected]>> wrote:
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 protected]<mailto:[email protected]>>
Date: Tuesday 14 February 2017 at 00:02
To: Eric Rescorla <[email protected]<mailto:[email protected]>>
Cc: Christer Holmberg <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>

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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> wrote:
Essentially a few test cases less to test.

Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla <[email protected]<mailto:[email protected]>> wrote:
On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]>> wrote:


On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg <[email protected]<mailto:[email protected]>> 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?

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.

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


> Is there any precedent for this in SDP?

Not anything I can think of.

Regards,

Christer


From: Eric Rescorla <[email protected]<mailto:[email protected]>>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>> wrote:
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.
>
> I don't see how that's really that useful

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


Regards,

Christer




On Fri, Feb 3, 2017 at 9:38 AM, Eric Rescorla
<[email protected]<mailto:[email protected]>> 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:

   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

















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

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