Re: [rtcweb] BUNDLE with implicit rtcp-mux

Justin Uberti <juberti@google.com> Thu, 20 March 2014 00:21 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F031A0852 for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 17:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.925
X-Spam-Level:
X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 cmbWZzIKl3oB for <rtcweb@ietfa.amsl.com>; Wed, 19 Mar 2014 17:21:35 -0700 (PDT)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 32B4F1A0851 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 17:21:35 -0700 (PDT)
Received: by mail-ve0-f170.google.com with SMTP id pa12so112972veb.1 for <rtcweb@ietf.org>; Wed, 19 Mar 2014 17:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=n1jaKxGXVmoVycy94GKOi2DLX5okQTRwiLvPJx9qUbE=; b=cBi/nUGIZ87ukINltKL1pvqTALxXdtIuuglOZjtKsMPOXwReHr+jXZMZH3W0m2Ouew rSMsz6sB7RY2016Vr50dHSB/8QSglN2oM+/06D9oqifWhk4/OmzYfdExcXhRIznZYBL2 gHgNCo7b7llkbU4K2dnSrWCltPsSl+ehM1/s5Z6ZFWD2YWeqU2Z02y9gyr0UWqKq0xKe P/aUty42h8uU3sBuyNQChW+OTGf0AnItOXqzF7p8ltoq1WVsaeBgZNIg71GaQlEDk7Fl zRzEzkpNe4hVhbRn0DDFGoN1ubqe1IYLMOjuYpqLt6y/WbF8p1TuJ5gWw+s9DfGqZR5w vFWQ==
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:from:date :message-id:subject:to:cc:content-type; bh=n1jaKxGXVmoVycy94GKOi2DLX5okQTRwiLvPJx9qUbE=; b=Bw3fxCB5sNpUbD+03WJHDTR1H2QZ6VtlgVwRS6q9pNPi3D2KOJ3CC2SnmgbX+IKCug nqIIseuBx9eMh5ostVa288XVLbd1fewU+ata5c+x3y+fteT7OOfFwF61GQW7AgRwpmpU QGurwt5Z9H+/geWorzd11qSmaOLoZNvYsyHxVcrFe3uygDCAFN+MdtRXGoQ+yJG2I6Ub /ssxvm2Ltxgea5v9pkPB0ogOFb5cfLtp/e8BS8gy7ye4p4++04yvfxj0jOPZwH4SMn+g XT1dgdRtV1BNykKtf+VnHIY/3o5U8xXsQHNDdmn5Jn6LFT8QTZAn4jHEEL51EJC/rJDI AcbQ==
X-Gm-Message-State: ALoCoQmyc0GNUeqFonZv0uoC8Do8810H55KSTfSZJaSP5Cn9/am28gzEhNqWhFS6E5/nC1NOpvFE9gTfcNMXUUndGQhoMNJ8FmceL0qtqIktvRxS533AK5Nl2DEKPXrs9G3wnp4fSn/X2zJnNTWn11cLYVBvT7BgIJAKuGsRiEWvCqJwlu8CtO95h5Nt8aKKsww5cafJ5ulm
X-Received: by 10.52.163.236 with SMTP id yl12mr1960940vdb.39.1395274886240; Wed, 19 Mar 2014 17:21:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.26.43 with HTTP; Wed, 19 Mar 2014 17:21:05 -0700 (PDT)
In-Reply-To: <5326F752.5050303@ericsson.com>
References: <CAOJ7v-063mGE_zndtAqAMN2fJw7kWvUHX2SgyDMryfw_-aS-9w@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D1F1892@ESESSMB209.ericsson.se> <531DC52B.6020500@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA6BC@ESESSMB209.ericsson.se> <531DCBE9.70701@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D1FA7B2@ESESSMB209.ericsson.se> <531DD756.50900@ericsson.com> <7594FB04B1934943A5C02806D1A2204B1D200086@ESESSMB209.ericsson.se> <532017DD.1060500@ericsson.com> <CAOJ7v-1u6eO4b1Qr4josdNoNBtW7s0Z82y570X4RwV0C4es2hg@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D212A7E@ESESSMB209.ericsson.se> <CAOJ7v-1YF+6Hfid+pPAHWZnjPeXJ+T81eV7Wk83+z4eCtUAgYw@mail.gmail.com> <cm0fhueueaioe4gj0u8m7vqa.1394776596681@email.android.com> <5322C475.5050402@ericsson.com> <CAOJ7v-3sr6TuPQ-tp-CaRLG16LfThhrckMM3Gcw5S8PNXztMoQ@mail.gmail.com> <5326F752.5050303@ericsson.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 19 Mar 2014 17:21:05 -0700
Message-ID: <CAOJ7v-1o5an=-Ng5mOQHL9fiOje5vX5fG=vvs27YaLpMvgV+Tg@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary=001a11c2c932f5759804f4febf36
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/DGX8bAQOTFSXO8HWbhovg-l1nHQ
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Mar 2014 00:21:38 -0000

On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> On 2014-03-14 17:26, Justin Uberti wrote:
> >
> >
> >
> > On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund
> > <magnus.westerlund@ericsson.com <mailto:magnus.westerlund@ericsson.com>>
> > wrote:
> >
> >     Hi,
> >     (as individual)
> >
> >     Although this discussion really should be on MMUSIC, I am still
> >     following up here. Anything we come to conclude here really need to
> go
> >     to MMUSIC for confirmation.
> >
> >     Justin, I do agree that it appear unnecessarily of having to include
> an
> >     RTCP transport in an OFFER when the offerer know the answerer is
> BUNDLE
> >     capable. I am fine with that and think the rule needed here is
> something
> >     along the line of the below:
> >
> >     A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is
> already
> >     required). In any answer by a BUNDLE capable endpoint, it MUST NOT
> >     change the usage of a=rtcp-mux. If it is present in the offer, it
> must
> >     be confirmed to be used in the answer, and if not present in the
> offer,
> >     it MUST NOT be added in the answer. An BUNDLE capable endpoint is
> >     RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might
> not
> >     be suitable include, lack RTP payload types, or cases when RTCP
> traffic
> >     is needed to be on its own transport flow (5-tuple) to enable QoS or
> >     other traffic handling functionalities.
> >
> >     The reason for writing the rule like the above, is that then an
> endpoint
> >     can choose when creating an offer to renegotiate the use of
> a=rtcp-mux.
> >     For example due to it running out of available PTs.
> >
> >     Feedback on this proposal?
> >
> >
> > I am not OK with this. It just gets too complicated to deal with all the
> > cases, especially if with the provision that rtcp-mux can change during
> > the session.
>
> (still as individual)
>
> Lets be clear what we are discussing here. I don't think this is lot of
> cases. And if you don't want to implement this in your code generating
> offer, that is fine. What this describes is that your code handling
> reception of offers and generating answers must be able to handle the
> lack of a=rtcp-mux in any offer, rather than just the initial one.
>
> I would question if even that assumption holds considering what happens
> if people start implementing session resumption or session mobility
> between devices using rehydration style establishment procedures. What
> one sides consider an initial offer might not be the state the answering
> party is in. Thus, I am worried about cases that are first offer/answer
> exchange related.
>
> To my understanding you will have code to handle the following cases
> when offers contains:
>
> 1) No bundle, no a=rtcp-mux
> 2) No bundle, with a=rtcp-mux
> 3) Bundle, with a=rtcp-mux
>
> Considering that you support bundle, and you support usage or not of
> a=rtcp-mux. Then I don't see how the code handling the SDP logic for
> Bundle, without a=rtcp-mux is that significant.
>

It is significant because you always know you can rtcp-mux. And you always
know you can BUNDLE when rtcp-muxing. But I think trying to BUNDLE a
no-rtcp-mux m= line into a rtcp-mux m= line is asking for problems.

>
> First of all, to be robust, you have to be capable of handling
> significant reconfigurations of the Peer Connection session in an Offer.
> If someone moves the peer of one peer connection to another device
> anything can happen, and everything can change.
>
> Secondly, to be able to turn off a=rtcp-mux is one method which can free
> up PTs if one run out. The other would be first unbundle the media
> types, then to completely unbundle the media sources. The later would be
> far worse when it comes to requiring providing ICE candidates and
> dealing with new transports. I however think unbundling the media types
> is likely to resolve many of the PT shortage situations.
>
> Just to confirm, you are also against allowing any initial offer request
> with bundle but without a=rtcp-mux within that bundle-group?
>

I am against _any_ offer request with bundle and without a=rtcp-mux (as
indicated in the current bundle draft).

>
> This, I would question, as it prevents anyone from treating the RTCP
> packets differently from the RTP packets within one RTP session. I know
> that this has been done in some cases, including IMS.
>
> From a principal point of view I think this should be either be use of
> BUNDLE groups results in MUST use a=rtcp-mux with RTP or that any offer
> may change the usage of a=rtcp-mux. Anything else depending on initial
> offer appears very messy and prone to errors.
>
> I would appreciate if someone else would provide their input and views
> here!
>
> First on the question if they need to separate the RTP and RTCP at all
> within a BUNDLE group?
>
> Secondly if they see that splitting a bundle group into different groups
> if one runs into issue is a sufficient and more preferred method for
> dealing with any PT exhaustion issue?
>
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>