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

Christer Holmberg <> Tue, 07 October 2014 18:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 188551A7113 for <>; Tue, 7 Oct 2014 11:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7yyQC9eU2GDH for <>; Tue, 7 Oct 2014 11:34:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 170A51A7026 for <>; Tue, 7 Oct 2014 11:34:41 -0700 (PDT)
X-AuditID: c1b4fb3a-f79da6d0000008c7-46-5434323fb675
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D9.59.02247.F3234345; Tue, 7 Oct 2014 20:34:39 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Tue, 7 Oct 2014 20:34:39 +0200
From: Christer Holmberg <>
To: "Stach, Thomas" <>, Harald Alvestrand <>, "Cullen Jennings (fluffy)" <>
Thread-Topic: bundle-11: BUNDLE accpeted, but RTCP Mux rejected
Thread-Index: Ac/iRGIfWukm+VgKTsyCbXLuDZy5KwAGEVHg
Date: Tue, 7 Oct 2014 18:34:38 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D46CF08ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvja69kUmIwbHXhhYdk9ksjvV1sVlM Xf6YxeLkzm3MDiweVyZcYfWY8nsjq8eSJT+ZPLb3PGYJYInisklJzcksSy3St0vgytg3+T5r wXTbiobGc8wNjEtMuxg5OSQETCQuTX/GDGGLSVy4t56ti5GLQ0jgKKPE9QcHmSCcxYwSCw+9 Aari4GATsJDo/qcNEhcRaGeU+H/0FCtIN7OAjMSMs41MILawgIPE3APbWEBsEQFHicNvbjBD 2EYSt/s3sIPYLAIqEi9mdoDZvAK+EhfbV4PNERLwk7g1cStYnFPAX+LyJYj5jEDXfT+1hgli l7jErSfzmSCuFpBYsuc81AeiEi8f/2OFsJUkGpc8gbotX+LclEYWiF2CEidnPmGZwCg6C8mo WUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYRYtTi4tz042M9FKLMpOLi/Pz 9PJSSzYxAuPy4JbfVjsYDz53PMQowMGoxMOr4GkcIsSaWFZcmXuIUZqDRUmcd+G5ecFCAumJ JanZqakFqUXxRaU5qcWHGJk4OKUaGBtddrQv//pDcGkPnzXXjYznLScSwx6evjPvqvWyI8eX LfFNPG3pU7Tqqch7waA1ZRsuJcx13JqUd7Fb3XuWQN/6qLOT6o/M7WI0aXSM5LxYv2hlLcOr KaoV2gbl1boTXi4Of/rmyqaIH3XsYvOeX5nyZ5bRnRm7Ds02PBszNeLsr5+hemu3V39SYinO SDTUYi4qTgQAQGocs6wCAAA=
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: Tue, 07 Oct 2014 18:34:47 -0000

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.

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

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