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

Roman Shpount <roman@telurix.com> Thu, 17 March 2016 15:29 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 50BF212D883 for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 08:29:34 -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 aTqRXX5CAQFd for <mmusic@ietfa.amsl.com>; Thu, 17 Mar 2016 08:29:30 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 5532412D79A for <mmusic@ietf.org>; Thu, 17 Mar 2016 08:29:29 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id n190so103495799iof.0 for <mmusic@ietf.org>; Thu, 17 Mar 2016 08:29:29 -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=PgIiKauQEMxb805FONn4i06PbXeuobKkpUq+5/APwrk=; b=Yq2FY/RL1RH9DqBxv5rxrU/KGqqfHoAv6YyLt5T7vb85ticu+g62HhTOkcTkmVGXQK /cppdo8Z3T46tA5hSuIh3Tv89EFQmmOySAgok/iYKIU/fJSdPgkBjzh4MgMWn2eAy2kJ 7vjSWcLrcHlRkcM/YfGuWZbUaD2hbvRkn2Cu9j/kuWpYwxhPjWjK7s12p/cekE0tVIj0 BJtYMy7Y2/BYNVedrmQwHT8Q3QAcqFc+MnqabehhMGcFnoeoDsmhvivwID3ct0i31r2Z L1Y/Eg8AG3IxgY9LlL2pvmMARzZ+tAyH0Dmcv8gN+AAQsDjmjbEUO9OmdwMvKI9FkJ+a GKew==
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=PgIiKauQEMxb805FONn4i06PbXeuobKkpUq+5/APwrk=; b=cTDkaOzGuQzH546+xfyF21mt5JaobgfjC6HDsBN4VQencVgzb5ZAf4hOZxQL56bWTL E743pY6tq198GpMuAu91I9rCuGsgV7pRpi0x9laSrsbwk49/UaNnzttUCrDndl9WJp2G T4hqunHFS6fGXvC/bYOktH8MUYiFQuSlNx2FvrwY4kclL0aJKlwXCOhtjD5PyCmfbyF6 FOLiEa42w/X6GZXHZEh+CB7bT9rOMrpeoABilxACimyqzrP9nUmEtBY/aemN5pjCDmu7 iSTv8Y7yEwkbQrS4MYDSrkkmTW/3dtY/BEKWaOU2pn6iCEaFp6Kemtg0MWi0E7Ra9dsi bU0A==
X-Gm-Message-State: AD7BkJJaBXYAMvPubc865ZhhhzkUFGko+/+dG16j/DM+F+VSaAAHOCmg3gobVlLfYvRN2A==
X-Received: by 10.107.136.167 with SMTP id s39mr10303980ioi.120.1458228568586; Thu, 17 Mar 2016 08:29:28 -0700 (PDT)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com. [209.85.213.174]) by smtp.gmail.com with ESMTPSA id e189sm3823589ioe.44.2016.03.17.08.29.26 for <mmusic@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 08:29:27 -0700 (PDT)
Received: by mail-ig0-f174.google.com with SMTP id kc10so14218043igb.0 for <mmusic@ietf.org>; Thu, 17 Mar 2016 08:29:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.18.113 with SMTP id v17mr12514552igd.2.1458228566421; Thu, 17 Mar 2016 08:29:26 -0700 (PDT)
Received: by 10.36.106.194 with HTTP; Thu, 17 Mar 2016 08:29:26 -0700 (PDT)
In-Reply-To: <D3109581.5D66%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> <D3108E09.5D37%christer.holmberg@ericsson.com> <CAD5OKxvV1dwW=rxJ8hg3wK1_ih_w-PmF5EZ+tn0TdQSG+Rei5A@mail.gmail.com> <D3109581.5D66%christer.holmberg@ericsson.com>
Date: Thu, 17 Mar 2016 11:29:26 -0400
X-Gmail-Original-Message-ID: <CAD5OKxv+2T=j=DqYnX037H=ZCsE8=MAeCaKM95oYCJpW_Bs7YA@mail.gmail.com>
Message-ID: <CAD5OKxv+2T=j=DqYnX037H=ZCsE8=MAeCaKM95oYCJpW_Bs7YA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="089e01494ff2b41259052e404b25"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/b7xyH-n_p2y82Y8TyuPkj-C-gi8>
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 15:29:34 -0000

On Thu, Mar 17, 2016 at 11:19 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >>>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).
> >
> > ICE candidates contain both RTP and RTCP addresses and ports. If all end
> points in the deployment support ICE, address in c= line, port in m= line
> and a=rtcp are completely redundant. I actually
> > would like to see to move to "ICE only" solution where there is IN IP4
> 0.0.0.0 is always specified in the c= line, port 9 in m= line and no a=rtcp
> is added. In this scenario a re-INVITE when ICE candidate is selected is
> also removed.
>
> I know what you would like to see, but my point was that the a=rtcp-mux
> plus RTP solution doesn’t require such change, does it?
>

This enforces something to be specified in c= line, m= line and a=rtcp-mux
attributes. Because of this it prevents removal of those attributes in the
future. Furthermore, since in it reuses a legacy attribute (a=rtcp) in the
way conflicting with original ICE specification it can cause potential
interop problems. Also, all of those values (address in c= line, m= line
port, and a=rtcp) are completely redundant for at least one common use case
-- WebRTC. I think the less you need to specify for the working solution,
the better.

>>> 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?
> >
> > What I was proposing that ICE trickle either always requires rtcp-mux or
> that there are two ice-option values are defined -- one for trickle with
> RTCP and another for trickle with rtcp-mux required where no RTCP
> candidates will be trickled later.
>
> I think it’s clumsy to have two different tags for trickle, based on
> whether RTCP candidates will be provided or not.
>

This is why I was not against the  a=rtcp-mux-required attribute. We need a
mechanism to specify that no RTCP attributes are coming in trickle. This
can be done the following way:
1. Always require mux exclusive with trickle is used
2. Combine both flags into a single ice=option
3. Specify 2 separate attributes, one to indicate trickle and another to
indicate that no RTCP candidates are coming

I can live with either one of those options. As far as WebRTC is concerned,
option 1 is the easiest and will require the least amount of signaling.

Regards,
_____________
Roman Shpount