IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 22 March 2016 08:52 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 1ED5612D7F6 for <mmusic@ietfa.amsl.com>; Tue, 22 Mar 2016 01:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 T3_QqfxPptzm for <mmusic@ietfa.amsl.com>; Tue, 22 Mar 2016 01:52:53 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A9412D5C0 for <mmusic@ietf.org>; Tue, 22 Mar 2016 01:52:52 -0700 (PDT)
X-AuditID: c1b4fb25-f79f86d00000400a-95-56f107e274fe
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9A.26.16394.2E701F65; Tue, 22 Mar 2016 09:52:50 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Tue, 22 Mar 2016 09:51:58 +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//4wKAgAAma4CAAJv+AP//MseQ
Date: Tue, 22 Mar 2016 08:51:58 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37EFECF5@ESESSMB209.ericsson.se>
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> <D31595FB.603F%christer.holmberg@ericsson.com> <CAD5OKxuaCgwUj15Xdz3wMk440OgGJYLEA3MPxP_hcRyNSCFzoQ@mail.gmail.com>
In-Reply-To: <CAD5OKxuaCgwUj15Xdz3wMk440OgGJYLEA3MPxP_hcRyNSCFzoQ@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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7pe4j9o9hBj3rLSymLn/MYrFiwwFW ixkXpjI7MHv8ff+ByWPJkp9MHremFAQwR3HZpKTmZJalFunbJXBlnOo9wVzQw1Hx7s9jtgbG D+xdjJwcEgImEo1H77NB2GISF+6tB7K5OIQEDjNKzJs1jx3CWcwo8fDyRMYuRg4ONgELie5/ 2iANIgKqEn+/T2YCsZkFfCVeLvjCDGILA5Xcu3mLHaLGUmL12VuMIHNEBPqYJDbdfsYCkmAB aj50aBvYZl6g5hPTTzNCLDvPI7HnyzGwbk6BQIk5/VPAbEag876fWgO1TVzi1pP5TBBnC0gs 2XOeGcIWlXj5+B8rhK0ksej2ZyaQo5kFNCXW79KHaFWUmNL9kB1ir6DEyZlPWCYwis1CMnUW QscsJB2zkHQsYGRZxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYUQe3/FbdwXj5jeMhRgEO RiUeXoOtH8KEWBPLiitzDzFKcDArifAu/QoU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzsv66XKY kEB6YklqdmpqQWoRTJaJg1OqgVEywtflRnj85Ak/a1vLr/DVKYpdf/CkqmKNBus6/WSTyivW km/+znLObLeK4qmJyko94nYjrsJr6Wej6INWLZrin9y+V3Jc5P/eU/HO4cAuU1XH4v5Xv9d/ jK+qL5GaoGdm9ce1VIkjQz6t03Ge4rrgi6ovNleI5mZJzpGynhJfa+r3/MplJZbijERDLeai 4kQA3c30DaQCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/GNeIZbhQpIk2ecRmY5DWBZ9QUqg>
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: Tue, 22 Mar 2016 08:52:54 -0000

Hi,

...

>> An “mux transcoder” needs to know about exclusive mux when it receives the offer – it cannot wait for the answer.
>
> Are you saying that "mux trancoder" which converts trickle ICE into non-ICE or non-trickle needs to know in advance that 
> it needs to allocate an RTCP address/port in the offer it generates on the other side of transcoder?

Yes.

Assume the "mux transcoder" knows that non-mux must be used on the "other side". It needs to know, when it receives the offer, whether the offerer supports fallback to non-mux, or whether the offerer only supports exclusive mux.

The purpose of this work item was to define *A* mechanism where an endpoint can indicate exclusive support of mux.

Regards,

Christer

v2.23.0 | Report a Bug | By Email