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

"Stach, Thomas" <> Wed, 08 October 2014 10:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 30F481A0171 for <>; Wed, 8 Oct 2014 03:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 244Lu6pxXFyL for <>; Wed, 8 Oct 2014 03:06:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0B03C1A0178 for <>; Wed, 8 Oct 2014 03:06:27 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id 81F691EB8538; Wed, 8 Oct 2014 12:06:26 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 12:06:26 +0200
From: "Stach, Thomas" <>
To: Christer Holmberg <>, Harald Alvestrand <>, "Cullen Jennings (fluffy)" <>
Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected
Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHgABwyUoA=
Date: Wed, 8 Oct 2014 10:06:25 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: de-AT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE121E227C60MCHP04MSXglobal_"
MIME-Version: 1.0
Cc: mmusic <>
Subject: Re: [MMUSIC] bundle-11: BUNDLE accpeted, but RTCP Mux rejected
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Oct 2014 10:06:35 -0000


From: Christer Holmberg []
Sent: Dienstag, 7. Oktober 2014 20:35
To: Stach, Thomas; Harald Alvestrand; Cullen Jennings (fluffy)
Cc: mmusic
Subject: RE: bundle-11: BUNDLE accpeted, but RTCP Mux rejected

Hi Thomas,

>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?

Alternative 1) is correct. I guess we could add some text to clarify that.
[TS] Yes, please. The current text is not sufficiently clear.

>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?

Assuming my understanding is correct, your understanding is correct :)

>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?

I am not sure what you mean. Are you asking how much implementation effort is saved if you don't have to de-mux RTP and RTCP?
[TS] Yes.  I was questioning myself what benefit there is in not mandating RTCP-mux.
In the meantime I looked up again the discussion on "Q14" that led to having rtcp-mux optional. I agree with the outcome.

>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.

Correct. But, case 2 is not applicable (unless the endpoints choose not to use BUNDLE to begin with, that is...).