IETF Logo Mail Archive

Re: [MMUSIC] Why do we need rtcp-mux-exclusive?

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 21 March 2016 10:18 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 2CDC012D595 for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 03:18:30 -0700 (PDT)
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 WPtxEIrL97AK for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 03:18:28 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 456DC12D5EF for <mmusic@ietf.org>; Mon, 21 Mar 2016 03:18:28 -0700 (PDT)
X-AuditID: c1b4fb2d-f79c06d000005960-aa-56efca728c21
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AB.14.22880.27ACFE65; Mon, 21 Mar 2016 11:18:26 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 11:17:25 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [MMUSIC] Why do we need rtcp-mux-exclusive?
Thread-Index: AQHRdajWE2kKEUdcwUGjD2CZk1wvxJ9I7sEQgAAvLYCAABdykP//+CcAgABTMICAAAArgIABZCbQ///1Q4CAACIS8IAAC0KAgAPbM4CAAAkjgIAAGHWAgAAE5ICAADHDgIABfqxAgACGpoCAACjoAIAAAz2AgAxwHoD//+OkgAAEug6A///hZACAAATggIAAIYYA///TiyCAAJdAAIAA4s4AgARnBgCAAC87gP//4wKAgAAma4A=
Date: Mon, 21 Mar 2016 10:17:25 +0000
Message-ID: <D31595FB.603F%christer.holmberg@ericsson.com>
References: <CABcZeBNsJkqGcU3Z=eekP4ntj7r3WMz6YOSiFt=u+HdDH2Zk3Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E7444F@ESESSMB209.ericsson.se> <CABcZeBNvsUNxrX5mx3E19St9CGf7s2vUmoyKAUmWbOw9s7jXfw@mail.gmail.com> <56DE4F09.3030902@cisco.com> <CABkgnnWPJSGmYHbds09iL+NOibm2_x-gE=5YcsS0Wf4tZtyE7g@mail.gmail.com> <CAOW+2ds7bCmLCxmaGyOgNd2P-b3FdBNxhqVC7ucWcQhmcZ+R2g@mail.gmail.com> <CABkgnnV_ChBkVh+yHLpCwvqc99odBLVVyf2L_dAJt-sWp66Nfw@mail.gmail.com> <D30448AA.55C1%christer.holmberg@ericsson.com> <7594FB04B1934943A5C02806D1A2204B37E9FE5B@ESESSMB209.ericsson.se> <CAD5OKxuC8kS=qAFkJrgZJndEvzXCrEAh=U2b4Na57MYY93o-+A@mail.gmail.com> <D30619E9.5867%christer.holmberg@ericsson.com> <CAD5OKxsOBRHwSGSsJ2+Wf1U3W_LPGWv5OuCmJR2BeXJgT8YHBQ@mail.gmail.com> <D3108E09.5D37%christer.holmberg@ericsson.com> <CAD5OKxvV1dwW=rxJ8hg3wK1_ih_w-PmF5EZ+tn0TdQSG+Rei5A@mail.gmail.com> <D3109581.5D66%christer.holmberg@ericsson.com> <CAD5OKxv+2T=j=DqYnX037H=ZCsE8=MAeCaKM95oYCJpW_Bs7YA@mail.gmail.com> <56EAD16D.6010607@alum.mit.edu> <CAD5OKxvK9SP6c8P7NH6gOFHCGDCYDXxi3Y=ieUsLiVO_KvC5Mg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37EBFA24@ESESSMB209.ericsson.se> <CAD5OKxsJzd7q5H-rr7rvgFj4tKE5iouNTBVfSRwafzWddLr0BA@mail.gmail.com> <D311B53D.5E4F%christer.holmberg@ericsson.com> <CAD5OKxt1C_Ljc6wuawypLdv8M4w-F-K662NdOmngvgwPa1UrTg@mail.gmail.com> <D3158E96.601C%christer.holmberg@ericsson.com> <CAD5OKxvQxFUKg8ZJRcHMP=+MbzHuxamFNn8Fh-Uf4bmFEjPE3Q@mail.gmail.com>
In-Reply-To: <CAD5OKxvQxFUKg8ZJRcHMP=+MbzHuxamFNn8Fh-Uf4bmFEjPE3Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_D31595FB603Fchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2K7sW7RqfdhBt/eqVpMXf6YxWLFhgOs FjMuTGV2YPb4+/4Dk8eSJT+ZPG5NKQhgjuKySUnNySxLLdK3S+DKWDf/PXPBaaWK/8eDGxi7 ZLsYOTkkBEwkZk39wwJhi0lcuLeerYuRi0NI4DCjxMcvm9ghnMWMEhdP32LqYuTgYBOwkOj+ pw3SICKgKvH3+2QmEJtZwFfi5YIvzCC2MFDJtCUnGSFqLCVWn73FCDJHRKCJSeLG0S1gCRag 5svXbrOC2LwCVhL7Ts1gA7GFBK5zS6xpNALZxSkQKNHQXAcSZgQ67vupNVC7xCVuPZnPBHG0 gMSSPeeZIWxRiZeP/4GNFBXQk9hxDsKWEFCUuDp9OVRvvMSZT6eYIdYKSpyc+YRlAqPYLCRj ZyEpm4WkDCJuIPH+3HxmCFtbYtnC11C2vsTGL2cZIWxriaZlP1DULGDkWMUoWpxaXJybbmSs l1qUmVxcnJ+nl5dasokRGK8Ht/zW3cG4+rXjIUYBDkYlHl4DoXdhQqyJZcWVuYcYJTiYlUR4 U/e9DxPiTUmsrEotyo8vKs1JLT7EKM3BoiTOy/bpcpiQQHpiSWp2ampBahFMlomDU6qBUXr/ r+ikrblnle6fydX0VF+9VH3BXo/DwQsUTh6aEsi74NvHrH+/EjbN2W30YYXZA4UH26ZXz5Od Yh/IU6S7wlR8yqWQ3+cthL0zzqhteKj5qvsMs7dZzVcNWxWXVz7vVyiv9lvDIvRZfaddVsK6 7zFts1Te+b/M2HU6KfdzvPDeTW8bpv+tu6bEUpyRaKjFXFScCAAZbV3N0wIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/UWcEwPwVp1fglJtj1KiJbBMIXxw>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] Why do we need rtcp-mux-exclusive?
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: Mon, 21 Mar 2016 10:18:30 -0000

Hi,

>>>> In my opinion, a=rtcp-mux PLUS a=rtcp with RTP port would be an easy was to indicate mux-exclusive, and it would work both with ICE and non-ICE. I don’t think we should define multiple mechanisms for doing the same thing.
>>>
>>>I would argue that a=rtcp is completely redundant potentially ignored information. It does not indicate (at least not yet) that trickle will not generate RTCP candidates. If ICE is used, the
>>>absence of RTCP candidates is enough to indicate that RTCP should not be sent yet. If ICE is not used, there is no grantee that a=rtcp is not ignored, so >it does not help. So, we can just include rtcp-mux and do not include any RTCP candidates, and we will get the result we need without any new specifications.
>>
>>How does the receiver know that RTCP candidates won’t be trickled later?
>
> If offer contained rtcp-mux and answer specified rtcp-mux, rtcp-mux will be used. Because of this, answerer always knows if rtcp-mux is used. Even if RTCP candidates will be trickled later, they will not be used and can be safely ignored.

An “mux transcoder” needs to know about exclusive mux when it receives the offer – it cannot wait for the answer.

Regards,

Christer

v2.23.0 | Report a Bug | By Email