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

Roman Shpount <roman@telurix.com> Mon, 21 March 2016 21:37 UTC

Return-Path: <roman@telurix.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 6833012DBEC for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 14:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com
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 tPjfDHaZqx6o for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 14:37:18 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C658912DBEF for <mmusic@ietf.org>; Mon, 21 Mar 2016 14:35:47 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id 124so72758971iov.3 for <mmusic@ietf.org>; Mon, 21 Mar 2016 14:35:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PMu2azW/Cpns5JJpPjo7/kkQteZdo+z9GXrb8l6+cY8=; b=cHvgzaAo4DTBL5ZPNFYnL28OW4CQyaYT29xCa65SEsvCSVIgoFDhBMu7VTf+TV6WIg snhnrnwv0Uo5B1/hlyI+dTq1FY8NyTq4vO5+LqZlQxkVgEbScZguJVtLmqUtdIUluRZj pzQVsvtwmNrQFa35OWvQ/dYLYzZ/vabEabi5rAEwSiEACvTYOcXJS8Io4RpBYmk1k/gR QhuDrrqi82XSMCizp2xLxaYePDnolBFZel7ijhcKGoUwPCxBo01qfrzUDaKyQiAcNlI2 wTV7S4wQiYcpBIwf0NLtxfjAjtR50OM4swqCwEGpgnlSbp4Uf9O2T5vOHAyRcb/u8OCq wjvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PMu2azW/Cpns5JJpPjo7/kkQteZdo+z9GXrb8l6+cY8=; b=EtX/yOA8UASzYg2Jl2YLHfS+6hhiwLpYXE0cI+hev69yfegN5l3JNAtUpZul3zqWhY ayJ17OvfVXFeFye+LqW06IzO9INyCpyuGgvZxgg2Mom/WaMPiU3pEubwn/zU7PRb8+8z hLIGgY80fDasfEOq7ucdLtyxqS7niYHTViD1vcqq8JHthrFOAVCTVXsdfRl5AdoMfdvk tPF9urrNU4ICYKRpgs/H/Wfw1yMBugrkFuJxDiCw+0DrKKTdstyFl9f2tXNuNxfP83M4 /CqtGUvBd674YSaw7qfKOoyOutNoFSo5xhvwnXdkf0xdIEa3DNsDamiaI6KihkckVq5z 4qDA==
X-Gm-Message-State: AD7BkJKy2Y6em+PuW7JgZXEXlYfgLGVmPahJmBVKV6T2m28lCem4CmaN7h0EggBO2N+fGg==
X-Received: by 10.107.163.137 with SMTP id m131mr32020520ioe.1.1458596147156; Mon, 21 Mar 2016 14:35:47 -0700 (PDT)
Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id z8sm3266382igp.3.2016.03.21.14.35.45 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 14:35:45 -0700 (PDT)
Received: by mail-io0-f177.google.com with SMTP id c63so45596415iof.0 for <mmusic@ietf.org>; Mon, 21 Mar 2016 14:35:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.30.71 with SMTP id e68mr31349431ioe.145.1458596144912; Mon, 21 Mar 2016 14:35:44 -0700 (PDT)
Received: by 10.36.106.194 with HTTP; Mon, 21 Mar 2016 14:35:44 -0700 (PDT)
In-Reply-To: <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> <D31595FB.603F%christer.holmberg@ericsson.com>
Date: Mon, 21 Mar 2016 17:35:44 -0400
X-Gmail-Original-Message-ID: <CAD5OKxuaCgwUj15Xdz3wMk440OgGJYLEA3MPxP_hcRyNSCFzoQ@mail.gmail.com>
Message-ID: <CAD5OKxuaCgwUj15Xdz3wMk440OgGJYLEA3MPxP_hcRyNSCFzoQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=001a1140d71e170a17052e95e1a2
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/819eVd-ltxZcMytehLf1Cjm0ad4>
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 21:37:20 -0000

On Mon, Mar 21, 2016 at 6:17 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >>>> 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.
>
>
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?

This is somewhat feasible but extremely marginal. Such transcoder would
have to convert between rtcp-mux and non-mux anyway. Since there is no way
to force rtcp-mux-exclusive on any legacy end points, such transcoder will
need to deal with rtcp-mux mismatch between the two call legs anyway.
_____________
Roman Shpount