IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 17 March 2016 14:45 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 79E0212DBFE for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 07:45:40 -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 8MQ4oO_yno9E for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 07:45:38 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAC612DBF2 for <mmusic@ietf.org>; Thu, 17 Mar 2016 07:45:28 -0700 (PDT)
X-AuditID: c1b4fb30-f79246d00000788a-5b-56eac306251a
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 51.76.30858.603CAE65; Thu, 17 Mar 2016 15:45:26 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.122]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0248.002; Thu, 17 Mar 2016 15:45:10 +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///1Q4CAACIS8IAAC0KAgAPbM4CAAAkjgIAAGHWAgAAE5ICAADHDgIABfqxAgACGpoCAACjoAIAAAz2AgAxwHoA=
Date: Thu, 17 Mar 2016 14:45:10 +0000
Message-ID: <D3108E09.5D37%christer.holmberg@ericsson.com>
References: <CABcZeBNsJkqGcU3Z=eekP4ntj7r3WMz6YOSiFt=u+HdDH2Zk3Q@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5A4E2@ESESSMB209.ericsson.se> <CABcZeBOGpguqkEeUoH35R2S_fOU=eGWgG7r5gmH3T_UHXqRRjg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5BBC1@ESESSMB209.ericsson.se> <CABcZeBOQKX+LKu1vafq227wv4sy+AApmixGB4fb7wTeuByYTMQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E5C345@ESESSMB209.ericsson.se> <CABcZeBPNOCTT1ahJsH0OSaOwFnLicFSjHWUbAXxQ3sFu5tUdjA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B37E7236F@ESESSMB209.ericsson.se> <CABcZeBNtmfjrETCerCu=A5BXt5HRCG+nO4KZ4ze3sBEeRNnX_A@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>
In-Reply-To: <CAD5OKxsOBRHwSGSsJ2+Wf1U3W_LPGWv5OuCmJR2BeXJgT8YHBQ@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.154]
Content-Type: multipart/alternative; boundary="_000_D3108E095D37christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUyM2K7ii7b4VdhBk9vSlls2Pef2eL9BV2L a2f+MVpMXf6YxWLGhanMDqweU35vZPXYOesuu8eSJT+ZPG5NKQhgieKySUnNySxLLdK3S+DK OHV2M1PBTImKr9MnsjYwzhTpYuTgkBAwkTjw17aLkRPIFJO4cG89WxcjF4eQwGFGiS+3HjFC OEsYJdY+P8YK0sAmYCHR/U8bpEFEQFXi7/fJTCA1zAILGCUWNk1mBUkIA9VMW3KSEaLIUmL1 2Vtgg0QENjFKnJy2lhkkwQLU/eMARAOvgJXEji0rWSC2reeS2NVxD6ybUyBQYumzeywgNiPQ fd9PrWECsZkFxCVuPZnPBHG3gMSSPeeZIWxRiZeP/4ENFRXQk9hxDsKWEFCSWHT7M1RvvMTl xqNQiwUlTs58wjKBUWwWkrGzkJTNQlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4wQtrXEmx9X WJHVLGDkWMUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGNEHt/w22MH48rnjIUYBDkYlHt6C py/DhFgTy4orcw8xSnAwK4nw7t73KkyINyWxsiq1KD++qDQntfgQozQHi5I4L+uny2FCAumJ JanZqakFqUUwWSYOTqkGRkFplpK1CgtlPhStzszVOej++oPhCpGJ5wRX2IbtPle77QfHP2nh I1/tprexFMYHXdq1Ry0KaOrt9w95Hn245y/9Vbq14GyzkZRfznxmj4UfKw45xL3Jr3Zn+uR/ eHOa0vHv21a+0donIP0ovHxxspNKnOvqA8UvmmoN7x26NEXbupfToSBTiaU4I9FQi7moOBEA Oee/vuQCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/NGADizBAhmRI-PkKYdHvcJOhGw0>
Cc: Flemming Andreasen <fandreas@cisco.com>, mmusic WG <mmusic@ietf.org>
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: Thu, 17 Mar 2016 14:45:40 -0000

Hi,

…

>We kind of need two solutions --  one which works with ICE and another that works with legacy. If we fix the issue with a=rtcp attribute handling by draft-ietf-mmusic-ice-sip-sdp and stop requiring
>it when it serves no purpose, then we can use a=rtcp-mux plus RTP candidate to indicate mux-exclusive when ICE is used, and a=rtcp set to RTP address and port when ICE is not used (legacy).

I am not sure a=rtcp-mux plus RTP candidate would require removal of a=rtcp usage, because today a=rtcp does not contain the RTP port (as it would in case of mux-exclusive).

>We can use both together (a=rtcp-mux plus RTP and a=rtcp set to RTP) when ICE with legacy fall back is required.

My apologies if you already said it, and I missed it, but how does a=rtcp-mux plus RTP work with trickle? How does the receiver know that the RTCP candidate won’t be trickled later?

Regards,

Christer

v2.23.0 | Report a Bug | By Email