IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 14 February 2017 17:32 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162981296CF for <mmusic@ietfa.amsl.com>; Tue, 14 Feb 2017 09:32:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCJqB3qkUErr for <mmusic@ietfa.amsl.com>; Tue, 14 Feb 2017 09:32:24 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F391296D5 for <mmusic@ietf.org>; Tue, 14 Feb 2017 09:32:22 -0800 (PST)
X-AuditID: c1b4fb30-b99fe70000007389-94-58a33f232e89
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 1F.95.29577.32F33A85; Tue, 14 Feb 2017 18:32:20 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Tue, 14 Feb 2017 18:32:19 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, "ben@nostrum.com" <ben@nostrum.com>
Thread-Topic: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux
Thread-Index: AQHSfkR3UhfsVBhEwUWv5/2Z0yKCVaFXfBcAgASHPoD//+NbAIAAMCIA///nooCAAVZKgIAAF9KAgABohoCAACCTAIAAAV4AgAA2PgCAAAmMAIAADWsAgAk4I4CAAOGbAIAAZJMAgAARMoA=
Date: Tue, 14 Feb 2017 17:32:19 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFFEF88@ESESSMB209.ericsson.se>
References: <CABcZeBPESaiH2wuE8RhcBHKz5h10MjKQ_EBDzcRpoy7mYeaspA@mail.gmail.com> <CABcZeBOY5pNRB=W_Zkqm5gYDMRGb-p7ChYctGRmfw5oGyYk-Pg@mail.gmail.com> <D4BE3D32.17805%christer.holmberg@ericsson.com> <CABcZeBO9j2nRqJduZCaaKJPT7YFNzrgLpKncmkvJ+6R=wjAH_w@mail.gmail.com> <D4BE4DA4.17818%christer.holmberg@ericsson.com> <CABcZeBMnJ5QoRt3id0dOPVZyyQgzNTtccMqt2dm14sedZOOXVw@mail.gmail.com> <D4BF5838.178E0%christer.holmberg@ericsson.com> <CABcZeBP0+OVqN3gC2DFwafoA3ta8HNd1hM=giWnHD+=kcN-1cg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B4BFEF197@ESESSMB209.ericsson.se> <CABcZeBPNKMg+Qw8nhJFdy7wbx23v+=uicpTqP5jgEH_J-wpFAw@mail.gmail.com> <CAD5OKxurvALsOs1wuPUid3QG+1f0B3zZAEWjcpFiD2cQHQCJMg@mail.gmail.com> <CABcZeBNCT4g6=YCsur4D=gv8+wmoQzLaDxYhMDC8kSTwk2O5+g@mail.gmail.com> <CAD5OKxtu+4aHhB=Nq21G93vGZ-MCb_iaUG9bLsgiDMj9g+38Ew@mail.gmail.com> <CABcZeBPFGLmtGwsD48621dSGMwYjz87kDiTzmybU_sra9sWTQA@mail.gmail.com> <CAD5OKxssUg8YoPM-i26cFgacKCEcgPD0=GmYA5TSpXG7AGjd+A@mail.gmail.com> <D4C898F7.181B1%christer.holmberg@ericsson.com> <CAD5OKxtyMfm02Ye9B9ikM7Ea5fto=b=umdf_dU8bBKdLfBC6ew@mail.gmail.com>
In-Reply-To: <CAD5OKxtyMfm02Ye9B9ikM7Ea5fto=b=umdf_dU8bBKdLfBC6ew@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4BFFEF88ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM2K7va6K/eIIg9sfFSzmd55mt1jx+hy7 xdTlj1ksZlyYyuzA4rFkyU8mj1k7n7B4TH7cxuxxa0pBAEsUl01Kak5mWWqRvl0CV0b7xCeM BdueMVVsb9rP0sDYcZepi5GTQ0LAROJD103GLkYuDiGBdYwSWw7vYIJwFjNK7Dr9Bsjh4GAT sJDo/qcN0iAi4CWx4vxcVhCbWcBWYuapi4wgtrCAjcS608uYIWpsJZ5uP8wMMkdEYB6jxIP7 p1hAEiwCqhI7t60E28wr4Cvx8ms31LKXHBJnD18Dm8QpECgx+dcSsA2MAmIS30+tYYLYJi5x 68l8qLMFJJbsOc8MYYtKvHz8jxXCVpJYdPszVH2+xOdtk5khlglKnJz5hGUCo8gsJKNmISmb haRsFtDPzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqRkV5qUWZycXF+ nl5easkmRmAMHtzy22AH48vnjocYBTgYlXh4P5xcGCHEmlhWXJl7iFGCg1lJhFfKdnGEEG9K YmVValF+fFFpTmrxIUZpDhYlcV6zlffDhQTSE0tSs1NTC1KLYLJMHJxSDYws3XNuGUaFBD4z uZ+QtkL80jrn51eKDAVvTH34rGe/TFbxqYsT9x8w+qXBcvhznLN8IFN4yvU8hpmp80pCkzov /rGz27LoP//+jStuMvQqGy/i/+nQ/qvZ5OE9nej5eq1PD+95kG81L8Dw3ZQHS5Wt4+b0RlqG 3azbkcPku++JoOb9udNj5mgpsRRnJBpqMRcVJwIAZ+RLZb0CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/oa8GO8R--WmIAWiCMZo0C1yNscQ>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 17:32:28 -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:roman@telurix.com]
Sent: 14 February 2017 19:30
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Eric Rescorla <ekr@rtfm.com>; mmusic WG <mmusic@ietf.org>
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 <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 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 <roman@telurix.com<mailto:roman@telurix.com>>
Date: Tuesday 14 February 2017 at 00:02
To: Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>>
Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>, "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>

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 <ekr@rtfm.com<mailto:ekr@rtfm.com>> 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 <roman@telurix.com<mailto:roman@telurix.com>> wrote:
Essentially a few test cases less to test.

Regards,
_____________
Roman Shpount

On Tue, Feb 7, 2017 at 6:52 PM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
On Tue, Feb 7, 2017 at 12:38 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> 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 <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:


On Tue, Feb 7, 2017 at 9:40 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 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 <ekr@rtfm.com<mailto:ekr@rtfm.com>>
Date: Monday 6 February 2017 at 16:32
To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>
Cc: "mmusic@ietf.org<mailto:mmusic@ietf.org>" <mmusic@ietf.org<mailto:mmusic@ietf.org>>
Subject: Re: [MMUSIC] Sending a=rtcp-mux-only w/o a=rtcp-mux



On Mon, Feb 6, 2017 at 5:57 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> 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
<ekr@rtfm.com<mailto:ekr@rtfm.com>> 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
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email