Christer Holmberg <> Mon, 19 October 2015 07:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EA6781A6F88 for <>; Mon, 19 Oct 2015 00:35:19 -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 KkH2CAOkk5CB for <>; Mon, 19 Oct 2015 00:35:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 063E11A6F83 for <>; Mon, 19 Oct 2015 00:35:15 -0700 (PDT)
X-AuditID: c1b4fb30-f79626d000006adf-47-56249d3165ac
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 4D.AD.27359.13D94265; Mon, 19 Oct 2015 09:35:14 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 09:35:12 +0200
From: Christer Holmberg <>
To: Thomas Stach <>, "" <>
Thread-Topic: [MMUSIC] BUNDLE and RTCP
Thread-Index: AdEJzH14LMfHNeeTQ5m0MrbuciOcLQAASvagABTmWQAABPyt0P//7NmA///YEmA=
Date: Mon, 19 Oct 2015 07:35:12 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B6CCC5ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvja7RXJUwg/6L7BZTlz9msfh0YiuT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx9vc5xoINVRU/9ncxNTDuzeli5OSQEDCR uLhnBxOELSZx4d56ti5GLg4hgaOMEk9efWKGcBYzSvxZvYW1i5GDg03AQqL7nzZIg4hAoMTn M8fBmoUFVCVO7t/NDBFXk7iz4SYzSLmIgJ/E7tPsIGEWoJKLy8+C2bwCvhKzpnZA7ZrMJLF1 +mQ2kASngKbEvpXvWUBsRqCDvp9aAzafWUBc4taT+VCHCkgs2XOeGcIWlXj5+B/YaRICihLL ++UgyvMlzi9+xwSxS1Di5MwnLBMYRWYhmTQLSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjM hCy+gJF9FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgVB3c8ttgB+PL546HGAU4GJV4eB+0 qYQJsSaWFVfmHmKU5mBREudtZnoQKiSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHRSmCS+M6N fx9Ou/gl4qKicLfF7Wv1O7wNlZefN7YJYvv8pSikse7gwVuany+XsqnPMvty/da815y60ROc neyEP5V3RG+Y/nmy2jLPSRGJdyLbOPfOlKurS0wQTmkRmd/BXfVli8PubRNnat33mJp/anrk B4clE7TDqoPPZB3517p4xe3Q1yenKrEUZyQaajEXFScCAK9kyQeLAgAA
Archived-At: <>
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: Mon, 19 Oct 2015 07:35:20 -0000


HOWEVER, we could make it SIMPLE and either:

1)      Mandate usage of rtcp-mux with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux MUST be used.
This was already suggested in the past, but Paul(?) said we should not make such restriction without a good reason. I think the current issue is a good reason :)
             m=data channel 10000
m=rtp 11111
m=rtp 11222

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.
m=data channel 10000             // rtcp-mux
m=rtp 11111
m=rtp 11222

m=data channel 10000             // "+1"
m=rtp 11111
m=rtp 11222

The solutions above would not allow explicit negotiation of an RTCP port when BUNDLE is used, but maybe we could live with that?
>Well, I could live with both of your suggestions, but I thought you wanted a solution that can also negotiate which a=rtcp attribute to use.

>If nobody really needs something like that , I would prefer 1) as it removes the needs for several implementation option that would only be needed to cover full backwards compatibility but would hardly be used.

Personally I don't have a strong preference, but as far as I know there may be environments where separate ports for RTP and RTCP are desired - even if BUNDLE is used.

>>Now, if we can agree on a way forward before Yokohama, you won't have to sit listening to me talking about BUNDLE at the meeting :)
>Well, I wouldn't be sitting there anyhow but understand that your motivation to speak there about BUNDLE again is probably limited.
I don't mind talking about BUNDLE - but I'd like to talk about it in the context of the great RFC that we have published :)