[MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected

"Stach, Thomas" <thomas.stach@unify.com> Tue, 07 October 2014 15:36 UTC

Return-Path: <thomas.stach@unify.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2A5111ACDFE for <mmusic@ietfa.amsl.com>; Tue, 7 Oct 2014 08:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fjOyKKd7shxd for <mmusic@ietfa.amsl.com>; Tue, 7 Oct 2014 08:35:57 -0700 (PDT)
Received: from mx12.unify.com (mx12.unify.com []) by ietfa.amsl.com (Postfix) with ESMTP id E26A01A6FAA for <mmusic@ietf.org>; Tue, 7 Oct 2014 08:35:56 -0700 (PDT)
Received: from MCHP02HTC.global-ad.net (unknown []) by mx12.unify.com (Server) with ESMTP id 0C1D223F0533; Tue, 7 Oct 2014 17:35:56 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([]) by MCHP02HTC.global-ad.net ([]) with mapi id 14.03.0195.001; Tue, 7 Oct 2014 17:35:55 +0200
From: "Stach, Thomas" <thomas.stach@unify.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Harald Alvestrand <harald@alvestrand.no>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected
Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5Kw==
Date: Tue, 7 Oct 2014 15:35:55 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE121E224ECF@MCHP04MSX.global-ad.net>
Accept-Language: de-AT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E224ECFMCHP04MSXglobal_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/gkIbjXxeuDr35x_Lsqbv_6D5V-Q
Cc: mmusic <mmusic@ietf.org>
Subject: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 07 Oct 2014 15:36:02 -0000

Christer, Cullen, Harald, all

BUNDLE can be used separate from RFC5761 RTCP-Multiplexing.
I can't find text in bundle-11 where the answerer would send its RTCP packets if it accepted BUNDLE, but rejected RTCP-muxing.
I see two options:
1. The answerer sends all RTCP packets to the shared RTP-port+1 of the negotiated shared address.
2. The answerer sends the RTCP packets to separate ports based on the unique addresses in the m-lines of the offer?

The offerer on the other hand will only receive a shared address. I assume it then has to send all its RTCP packets
to the shared RTP-port+1 of the answerer.

Is my understanding correct or am I completely off-track?

Supposed I'm correct, then independent from the response, I'm asking if there really is a use case for that.
In case 1, one would have to demux the RTP streams and RTCP streams from two separate ports instead of a single port. How much implementation effort is saved in that case?
In case 2 the RTCP handling at offerer and answerer is completely different. In addition, you still need "a lot" of RTCP ports and take advantage of only half of the BUNDLE benefits.

Dr.-Ing. Thomas Stach
Unify  Austria
Systems Engineering & Standardization
Dietrichgasse 27
A-1030 Vienna
Tel: +43 57008 4377
Fax: +43 570085 4377