Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

worley@ariadne.com (Dale R. Worley) Mon, 06 May 2013 18:01 UTC

Return-Path: <worley@shell01.TheWorld.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 68E9521F92EC for <mmusic@ietfa.amsl.com>; Mon, 6 May 2013 11:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.948
X-Spam-Level:
X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Himkbzl5d3ep for <mmusic@ietfa.amsl.com>; Mon, 6 May 2013 11:01:06 -0700 (PDT)
Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 7F32F21F92EF for <mmusic@ietf.org>; Mon, 6 May 2013 11:01:06 -0700 (PDT)
Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r46I0mN1004428; Mon, 6 May 2013 14:00:50 -0400
Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r46I0lZ64254394; Mon, 6 May 2013 14:00:48 -0400 (EDT)
Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r46I0jM84247693; Mon, 6 May 2013 14:00:45 -0400 (EDT)
Date: Mon, 06 May 2013 14:00:45 -0400
Message-Id: <201305061800.r46I0jM84247693@shell01.TheWorld.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: Bernard Aboba <bernard_aboba@hotmail.com>
In-reply-to: <BLU169-W1311854975457C1CFC4B01093BE0@phx.gbl> (bernard_aboba@hotmail.com)
References: <7594FB04B1934943A5C02806D1A2204B1C368E12@ESESSMB209.ericsson.se>, <517FFB7E.8050801@alum.mit.edu>, <CABkgnnVf6f3RrP2h66_8hFPZScWU3Xp4f1x0dmW0xhmvZRQ70Q@mail.gmail.com>, <51801BBD.1010505@alum.mit.edu>, <CAOJ7v-12j0k1W7GRfOzvPmfN-BZ0ve=fHVcWy+avronfc8wFYw@mail.gmail.com>, , <7594FB04B1934943A5C02806D1A2204B1C369709@ESESSMB209.ericsson.se>, <CE0F590A-D948-4702-9082-FDE0DCBFB698@cisco.com>, <7594FB04B1934943A5C02806D1A2204B1C3699A8@ESESSMB209.ericsson.se>, <201305030115.r431Fis33999826@shell01.TheWorld.com> <BLU169-W1311854975457C1CFC4B01093BE0@phx.gbl>
Cc: mmusic@ietf.org, christer.holmberg@ericsson.com
Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 06 May 2013 18:01:12 -0000

> From: Bernard Aboba <bernard_aboba@hotmail.com>
> 
> > But it doesn't seem that there is much to gain by mandating rtcp-mux
> > in the first offer/answer, the one where actual bundling is not being
> > done.  All of the RTP/RTCP routing code that is active at that point
> > has to support non-rtcp-mux operation already.
>
> [BA]  Support for rtcp-mux in the first offer/answer is mandated by
> RFC 5761 Section 5.1.3:
>    The initial SDP offer MUST include this
>    attribute at the media level to request multiplexing of RTP and RTCP
>    on a single port. 

I don't see how 5761 mandates that a=rtcp-mux MUST be used in the
first offer of a bundle negotiation.  The context of your quote is:

   5.1.3.  Interactions with ICE
   [...]
   If it is desired to use both ICE and multiplexed RTP and RTCP, the
   initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
   RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
   lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
   fallback port for RTCP in the case that the answerer does not support
   RTP and RTCP multiplexing.  This MUST be done for each media where
   RTP and RTCP multiplexing is desired.

That is, if the device desires to use both ICE and multiplex, it has
to use a=rtcp-mux in the first offer of ICE's set of offers.  But
we're talking about bundling, which (in the current design) contains
*two* ICE cycles, since the second offer (in the bundle spec) is going
to restart ICE.  And the device need not "desire" to use "both ICE and
multiplexed RTP and RTCP" during the first of the ICE cycles.

Dale