Christer Holmberg <> Tue, 20 October 2015 06:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AB8681A1BC9 for <>; Mon, 19 Oct 2015 23:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XoUJe_etXQ2d for <>; Mon, 19 Oct 2015 23:47:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CBCD1A1BB5 for <>; Mon, 19 Oct 2015 23:47:21 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-1c-5625e3776841
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 4F.50.17026.773E5265; Tue, 20 Oct 2015 08:47:19 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 20 Oct 2015 08:47:18 +0200
From: Christer Holmberg <>
To: Jonathan Lennox <>
Thread-Topic: [MMUSIC] BUNDLE and RTCP
Thread-Index: AdEJzH14LMfHNeeTQ5m0MrbuciOcLQAASvagABTmWQAABPyt0P//7NmA///YEmCAAV/wAP//iyBg
Date: Tue, 20 Oct 2015 06:47:17 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B78CFFESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGfG3Rrf8sWqYwb+VKhb7F59ntpi6/DGL xacTW5kcmD12zrrL7rFkyU8mj7Znd9gDmKO4bFJSczLLUov07RK4Mr698S14l1Hx69ErlgbG hrQuRg4OCQETiSmzObsYOYFMMYkL99azdTFycQgJHGWUmPWynxHCWcwosbrxNyNIA5uAhUT3 P22QBhEBDYmLzz6wgdjMAi4SE1dsYQaxhQVUJU7u380MUaMmcWfDTSg7SmL1/dtgNgtQzaM1 jxhBbF4BX4nHM2czQezqYpbYeus3E0iCU8BW4vWe9ywgNiPQdd9PrWGCWCYucevJfCaIqwUk luw5zwxhi0q8fPyPFcJWlPj4ah8jRH2+xK8v91kglglKnJz5hGUCo+gsJKNmISmbhaRsFtDL zAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkm RmD8HdzyW3cH4+rXjocYBTgYlXh4H6SrhgmxJpYVV+YeYpTmYFES521hehAqJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgZFhb+zHxNo95yWNj+7Zw6TBJ1T7LOr6PdstyqULdsrac796M13y tmv1Tn+91SudPWPTlOZZepes2rVnl/O8M6zdG37Wy3H9SP3fvOLYTfG/fbqKL4VefNBQ/ZXD 8V2DhcNxz+UPf18tZVtzNKfM3rBm/VymBBbn5EW56/hKn64uc/vgdzbn6EElluKMREMt5qLi RAB2oMB8oAIAAA==
Archived-At: <>
Cc: mmusic <>
Subject: Re: [MMUSIC] BUNDLE and RTCP
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, 20 Oct 2015 06:47:23 -0000


On Oct 19, 2015, at 3:35 AM, Christer Holmberg <<>> wrote:

1)      Mandate usage of rtcp-mux with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux MUST be used.

2)      Mandate usage of either rtcp-mux OR the default “+1” port with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux or “+1” MUST be used. The selection is based on whether the rtcp-mux attribute was included in the offer/answer or not.
The solutions above would not allow explicit negotiation of an RTCP port when BUNDLE is used, but maybe we could live with that?

> Would using ICE also solve the problem?  ICE candidates for component 2 are RTCP candidates. It might mean putting ICE candidates for component 2 in an m-line that doesn’t “naturally” use two candidates, but that might be cleaner than a=rtcp.

When using ICE, that is one possibility. But, then we would have to specify that, when BUNDLE is used, component 2 is always for RTCP – no matter what type of m- line it is associated with it.

But, would that mean that, when ICE is NOT used, we would include a=rtcp in non-RTP m- lines?

>The “+1” technique, by contrast, doesn’t work in any scenario where you’re trying to advertise port numbers on the outside of a NAT, because the endpoint has no control over the mapping of its ports through the NAT.