Re: [MMUSIC] BUNDLE and RTCP

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 19 October 2015 06:41 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BCC1A2182 for <mmusic@ietfa.amsl.com>; Sun, 18 Oct 2015 23:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LplPGWKvJC3R for <mmusic@ietfa.amsl.com>; Sun, 18 Oct 2015 23:41:52 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14D481A1EF4 for <mmusic@ietf.org>; Sun, 18 Oct 2015 23:41:50 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-ad-562490ad2500
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0C.BF.17026.DA094265; Mon, 19 Oct 2015 08:41:49 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 08:41:48 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Thomas Stach <thomass.stach@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] BUNDLE and RTCP
Thread-Index: AdEJzH14LMfHNeeTQ5m0MrbuciOcLQAASvagABTmWQAABPyt0A==
Date: Mon, 19 Oct 2015 06:41:48 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37B6CAC0@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37B66DC9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B66EEC@ESESSMB209.ericsson.se> <56248496.2050408@gmail.com>
In-Reply-To: <56248496.2050408@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B6CAC0ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje7aCSphBmdO81tMXf6YxeLTia1M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAldGd+9L5oIrRxkrrnXuYG9gfLmOsYuRk0NC wETiZ+saZghbTOLCvfVsXYxcHEICRxklPr9dwQLhLGaUePHnJlCGg4NNwEKi+582SIOIQKDE 5zPHmUBsYQFViZP7dzNDxNUk7my4CWU7SUy5uwFsGQtQzYm9i8HqeQV8JS733GGCmL+BUeLB zH4WkASngKbE1OnzwRoYgS76fmoNWAOzgLjErSfzmSAuFZBYsuc81NWiEi8f/2MFuU1CQFFi eb8ciMkskC9xaX4xxCpBiZMzn7BMYBSZhWTQLISqWUiqIEp0JBbs/sQGYWtLLFv4mhnGPnPg MROy+AJG9lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgXF1cMtv3R2Mq187HmIU4GBU4uF9 0KYSJsSaWFZcmXuIUZqDRUmct4XpQaiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtx/8qsu /9OKXXvy+Mos2TlH2O/uiGE5Nv9dpZS+fBm7eFzG93WHnnRtcsoVuzQr6svXXZcOnO3+ssR0 /he9vMvdKw5yzT53pfrBZxUd3pliIVxGt//vSul161v6bQFjQM0TNt4Eg2UfS8snr1k0cbZg 3klJtrdm2g5c0xO7XFZ113HOritZc0eJpTgj0VCLuag4EQCgNZeejAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/h3SJtQelZtKhbx-X-TXYvQoZvBg>
Subject: Re: [MMUSIC] BUNDLE and RTCP
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 19 Oct 2015 06:41:55 -0000

Hi Thomas,

>of course there are many possibilities.
>However it would be good to have some explicit signalling.
>Without inventing new signalling elements, you could use the first RTP m-line that appears in the   a=group:BUNDLE attribute in the answer.
>
>So if you have in the offer:
>
>a=group:BUNDLE foo bar baz
>m=data channel 10000
>a=mid:foo
>m=rtp 11111
>a=mid:bar
>a=rtcp: 15000
>m=rtp 11222
>a=mid:baz
>a=rtcp: 20000
>
>If you get back in the answer:
>
>a=group:BUNDLE foo bar baz
>...
>then your RTCP port is 15000
>
>If you get back a=group:BUNDLE foo baz bar then RTCP would go to 20000.
>
>Although I haven't thought it through completely it too much this could also work reasonably well of the answerer accepts only a subset of the offered m-lines.
>
>What do yo think?

I am sure we COULD do something like that. I also have some ideas, but I think they are all too hacky and/or complex for what we would gain.
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
a=rtcp-mux
m=rtp 11222
a=rtcp-mux


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
a=rtcp-mux
m=rtp 11222
a=rtcp-mux

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?
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 :)
Regards,
Christer



Am 18.10.2015 um 19:53 schrieb Christer Holmberg:
Hi,

Note that the issue exists even without bundle-only m- lines:

m=data channel 10000
m=rtp 11111
a=rtcp: 15000
m=rtp 11222
a=rtcp: 20000

Again, if the data channel m-  line is selected as the offerer BUNDLE address, which port will be used for RTCP?

Regards,

Christer

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 October 2015 20:47
To: mmusic@ietf.org<mailto:mmusic@ietf.org>
Subject: [MMUSIC] BUNDLE and RTCP

Hi,

During the proto write-up process of BUNDLE, an issue came up.

Assume the following BUNDLE offer, with one non-bundle-only data channel m- line and one bundle-only RTP m- line:

m=data channel 10000
m=rtp 0
a=bundle-only


Now, if bundle is accepted, the RTP m- line will get port 10000, as defined in BUNDLE. So far so good.

Now, if bundle is accepted, the data channel m- line will be selected as the offerer BUNDLE address, and RTP will use port 1000.

So far so good.


Next, assume we want to negotiate an explicit RTCP port for RTP. As the non-bundle-only m- line is not RTP (and therefore cannot contain an rtcp attribute), we have to add the actual RTCP port value to the bundle-only m- line:

m=data channel 10000
m=rtp 0
a=bundle-only
a=rtcp: 20000

So far so good.

Now, assume we also have one non-bundle-only RTP m- line:

m=data channel 10000
m=rtp 11111
a=rtcp: 15000
m=rtp 0
a=bundle-only
a=rtcp: 20000

Now, assume the data channel m- line is selected as the offerer BUNDLE address. It means that port 10000 will also be used for RTP. But, which port will be used for RTCP? 15000 or 20000?

Regards,

Christer








_______________________________________________

mmusic mailing list

mmusic@ietf.org<mailto:mmusic@ietf.org>

https://www.ietf.org/mailman/listinfo/mmusic