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

Bernard Aboba <bernard_aboba@hotmail.com> Fri, 03 May 2013 05:13 UTC

Return-Path: <bernard_aboba@hotmail.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 E8B9C21F8E62 for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 22:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.224
X-Spam-Level:
X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 xL1CUHh4sGhv for <mmusic@ietfa.amsl.com>; Thu, 2 May 2013 22:13:21 -0700 (PDT)
Received: from blu0-omc1-s4.blu0.hotmail.com (blu0-omc1-s4.blu0.hotmail.com [65.55.116.15]) by ietfa.amsl.com (Postfix) with ESMTP id DB9C521F92BB for <mmusic@ietf.org>; Thu, 2 May 2013 22:13:20 -0700 (PDT)
Received: from BLU169-W131 ([65.55.116.7]) by blu0-omc1-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 May 2013 22:13:20 -0700
X-EIP: [hs4BJt4tk/Karh4oFb1B2xfFpTNaClwR]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W1311854975457C1CFC4B01093BE0@phx.gbl>
Content-Type: multipart/alternative; boundary="_fe64c10f-71e4-4453-9687-720dd0bd9cce_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: "Dale R. Worley" <worley@ariadne.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Date: Thu, 02 May 2013 22:13:20 -0700
Importance: Normal
In-Reply-To: <201305030115.r431Fis33999826@shell01.TheWorld.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>
MIME-Version: 1.0
X-OriginalArrivalTime: 03 May 2013 05:13:20.0392 (UTC) FILETIME=[ED79A880:01CE47BC]
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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: Fri, 03 May 2013 05:13:27 -0000

> 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. 
[RFC5761]  Section 5.1.3 also requires a fallback port for RTCP in the offer, in case the answerer doesn't support RTCP-mux:  
   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.
Given the existing normative text,  and all the other problems we need to solve, I think the burden of proof is on those who advocate deviation from RFC 5761.