IETF Logo Mail Archive

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

Roman Shpount <roman@telurix.com> Mon, 21 March 2016 08:54 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 8D65612D647 for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 01:54:42 -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 dOu9lIJM-9wk for <mmusic@ietfa.amsl.com>; Mon, 21 Mar 2016 01:54:40 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 B97BD12D53C for <mmusic@ietf.org>; Mon, 21 Mar 2016 01:54:40 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id cl4so27264490igb.0 for <mmusic@ietf.org>; Mon, 21 Mar 2016 01:54:40 -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=LJMMOR6cPN+WcXegOUNAWggWfEV3fjPhCyQHnVlVIZ4=; b=CwygiK8JLI9+J5Wzd7kWXxkLAOCipHN1ijY66DcBEaI2Of8YnOz019PEhzmnkAwoJv q3iE6acU9+4S7CRF7jdaeZp+kL2/Jo+ZkEh8aEhyLKXDTmlscLS7c1Xns5Qd4bcTuKAf TDOJmb8REKeWJM3kY1xX5BBneoVcvd05LrjV57RuOK7WUPK2Q9wOiVQgL6BpE/dsqeX2 Y307OUdpgU6zh9mMgEf8nDHgrYxZk7lK9c6f0wa+Pt7AgVjP572+oAXRhJJ/CbpAbM+P 3FFQdOPG5tJx0/N2nBniIPx7pvrMJfgWMRGT57JNsw7XscQ/F7Gz7lkUd0dWb+Cdy5m/ 51Eg==
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=LJMMOR6cPN+WcXegOUNAWggWfEV3fjPhCyQHnVlVIZ4=; b=bJFoQJD34+toJ70nD8fiAqzG1Fei49ZLIfV8mhtxtD9+cj8pJn3GhLHLANBvp9DGLF GBoIul0vsH+zLgSYCXXBQpKgXNccuE0utPoPJjqTy/nQqdkpVuFO3/Fq0E2WLvmUQ8PO J7jQGWe9w1fwr4v/Sh6dQNv2dJWtundUERcAC57wnbNEtFru2AoulU6zvEWwTvZbuJ4e GIMdVjWm83kQmZmP8YtnFISchV+pPeUdu7sIOb8nR6nundzO09GCus/diQX0EGprZggL L9/Yq64bDn77Xpm4nr3XyLvnb2evyPLAVrn3JlJ8ouoAO5xxzQjZtPJLfEfh9iAATY7k ITpw==
X-Gm-Message-State: AD7BkJI6kDc8ta8tHarTJEA+OQVcT5snvDuzDXQCI0IpFdW9HMLM13BxgvBf6aOm4jTK/g==
X-Received: by 10.50.79.200 with SMTP id l8mr10048054igx.75.1458550479955; Mon, 21 Mar 2016 01:54:39 -0700 (PDT)
Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id qi9sm4977523igc.4.2016.03.21.01.54.38 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 01:54:38 -0700 (PDT)
Received: by mail-io0-f171.google.com with SMTP id o5so118221660iod.2 for <mmusic@ietf.org>; Mon, 21 Mar 2016 01:54:38 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.30.71 with SMTP id e68mr27547318ioe.145.1458550478194; Mon, 21 Mar 2016 01:54:38 -0700 (PDT)
Received: by 10.36.106.194 with HTTP; Mon, 21 Mar 2016 01:54:38 -0700 (PDT)
In-Reply-To: <D311B53D.5E4F%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>
Date: Mon, 21 Mar 2016 04:54:38 -0400
X-Gmail-Original-Message-ID: <CAD5OKxt1C_Ljc6wuawypLdv8M4w-F-K662NdOmngvgwPa1UrTg@mail.gmail.com>
Message-ID: <CAD5OKxt1C_Ljc6wuawypLdv8M4w-F-K662NdOmngvgwPa1UrTg@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1140d71e23cf5c052e8b3f39"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Lwp2UEK-BhITSWp0P7SgpNGs6K4>
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 08:54:42 -0000

On Fri, Mar 18, 2016 at 7:40 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.

As far as trickle is concerned, it can detect that remote party supports or
does not support rtcp-mux before it allocates any RTCP candidates. If it
will not include any RTPC candidates, no RTCP will be sent to it.

I think this firmly puts the problem with mux-exclusive outside of anything
ICE enabled. If we are dealing with anything non-ICE, I do not think the
backwards compatible solution can be based on a=rtcp since it is not
guaranteed if remote party will honor it. If you want a solution for
legacy, it should be something that replaces the address in c= line and/or
port in m= line to stop remote from sending any RTCP unless it understands
this extension.
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email