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

[Roman Shpount <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>> Essentially a few test cases less to test.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>> On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla <[e-mail]> wrote:
>>
>>> On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount <[e-mail]>
>>> 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 <[e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg <
>>>>> [e-mail]> 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 <[e-mail]>
>>>>>> Date: Monday 6 February 2017 at 16:32
>>>>>> To: Christer Holmberg <[e-mail]>
>>>>>> Cc: "[e-mail]" <[e-mail]>
>>>>>> Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <
>>>>>> [e-mail]> 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
>>>>>> <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>
>>>>
>>>
>>
>