Re: [MMUSIC] BUNDLE and DATA CHANNEL

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 29 April 2013 14:44 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8FC21F9E53 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2013 07:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y+5KQIpPo55 for <mmusic@ietfa.amsl.com>; Mon, 29 Apr 2013 07:44:21 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D14921F9E4C for <mmusic@ietf.org>; Mon, 29 Apr 2013 07:44:20 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f316d0000028db-be-517e874303d3
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B9.FD.10459.3478E715; Mon, 29 Apr 2013 16:44:19 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Mon, 29 Apr 2013 16:44:19 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: 'Paul Kyzivat' <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] BUNDLE and DATA CHANNEL
Thread-Index: AQHOQgMEIk6q+PHpSI2jUL+JN2f+GpjoHi4ggAB69ACAACdgz4AAEvyAgARXjRCAACBWzw==
Date: Mon, 29 Apr 2013 14:44:18 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3682DB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C35F47A@ESESSMB209.ericsson.se> <51796D46.9030300@alum.mit.edu> <201304252219.r3PMJv6C3392749@shell01.TheWorld.com> <7594FB04B1934943A5C02806D1A2204B1C361D3A@ESESSMB209.ericsson.se>, <517AB252.90602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C363182@ESESSMB209.ericsson.se> <517AE347.40401@alum.mit.edu>, <7594FB04B1934943A5C02806D1A2204B1C368210@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C368210@ESESSMB209.ericsson.se>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvra5ze12gwe1ZOhZTlz9msVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWx7cIj5oLrWhWth1rYGxgPKHYxcnJICJhI vJ7Uwg5hi0lcuLeerYuRi0NI4DCjxO5PvcwQzhJGif9zfzJ1MXJwsAlYSHT/0wZpEBHQkjhw 5TILSJhZQF3i6uIgEFNYQFfi8eIYEFNEQE+i5UQNRHGYxK/NL1lAbBYBVYkTrVfZQGxeAV+J a7v+MEIs2sAs8enbd7AEp4CfxPKDR8EaGIFO+35qDROIzSwgLnHryXwmiJMFJJbsOc8MYYtK vHz8jxVkr4SAosTyfjmIch2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYxis5BMnYWkZRaSlllI WhYwsqxiZM9NzMxJLzfcxAiMjoNbfuvuYDx1TuQQozQHi5I473SpykAhgfTEktTs1NSC1KL4 otKc1OJDjEwcnFINjDI7ezYJ3217tO2jROaCBRk6XjNkGgt05+hLJ12I3bLpV/YxR6YFN0/G PT6reULKbEukqlNq9pOG/be2LlTZ8jjIeMHrOObpWp81zThmp3sv5ze8+TLbRiR4/RRrA62S EtspV9U503vlXq0++XRnSWDpqUu7rTRviwtmsU6YYd1kYHF8keqUKiWW4oxEQy3mouJEAHD+ J9RcAgAA
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 29 Apr 2013 14:44:21 -0000

Hi,

I need to correct 1).

The IP header Protocol value will of course only indicate UDP, NOT what is on top of that (RTP, SCTP, or something else...).

Regards,

Christer
________________________________________
From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Christer Holmberg [christer.holmberg@ericsson.com]
Sent: Monday, 29 April 2013 4:06 PM
To: 'Paul Kyzivat'
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL

Hi,

I think we can separate this into 3 questions:

1) How is a receiver able to demux transport flows associated with different "transport flow usages" (here I consider RTP one usage, the data channel another, etc).

Now, the general first step is of course to separate based on the IP header Protocol value.

But, of course, if you have multiple flows with the same usage (e.g. multiple RTP flows), that it is not enough.

Also, if you have SCTP on top of UDP (as in our case for the data channel), you need to go up on the SCTP level in order to figure out what it is used for.


2) How is a receiver able to associated a transport flow with its associated SDP m- line.

This becomes an issue when multiple m- lines are associated with the same transport flow usage, e.g. when you have multiple m- lines for RTP.


3) How is a receiver able to, within an m- line, identify a media flow.

This becomes an issue e.g. when multiple RTP flows are associated with a single m- line. But, as I said before, this is not a BUNDLE specific problem.


Regarding 2) and 3), the most common solutions that have been discussed are usage of PAYLOAD and/or SSRC. As we know, people have expressed concern about using PAYLOAD, due to the limited number of PT values available.

Regards,

Christer








-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
Sent: Friday, April 26, 2013 10:28 PM
To: Christer Holmberg
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] BUNDLE and DATA CHANNEL

On 4/26/13 1:33 PM, Christer Holmberg wrote:
>
> Hi,
>
>>>>> Yes - we need a way to signal the demux mechanism to be used.
>>>>> (Unless there is only one possibility. And we have already
>>>>> disproved
>>>>> that.)
>>>>
>>>> We could use different group "semantics" values to indicate the
>>>> multiplexing mechanism.  One endpoint could probe the other to
>>>> discover which mechanisms it supplies by offering a collection of bundles containing no constituents, one for each mechanism.  The answer will show which mechanisms the answerer supports.
>>>
>>> My idea was the endpoint simply lists the media description proto values that it is capable of multiplexing for a given 5-tuple:
>>>
>>>        Example: a=muxcap: RTP/AVP, SCTP/DTLS
>>>
>>> ...or something like that.
>>
>> That is sufficient *if* there is a single mux/demux algorithm per proto.
>>
>> But I don't think that is true. I think we will need to signal this
>> per-m-line, and specify the demux algorithm(s) for streams that bind
>> to that m-line.
>
> I don't it matters if there are multiple algorithms - the important thing is that the endpoint is able to mux/demux the specific proto using A algorithm.
>
> Otherwise, we can have different values, one for each algorithm. Note that in my example I used to SDP proto values, but we could use whatever.

My point is that both sides need to *agree* on what mechanism is used to mux/demux the streams - in order to associate each received packet with the correct m-line.

So simply declaring "I can mux RTP/SAVP and DTLS/SCTP" is not sufficient without saying *how* it will be done. (Except in cases where there is a mutual understanding that there is only one way, or a default way.)

> HOWEVER, before we go into the details, I would like to know whether people generally think we need a mechanism which allows to list the protos an endpoint is able to mux/demux.
>
>>> Of course, an endpoint needs to be able to multiplex all media that it inserts in a bundle group. But, it may not always insert m- lines for everything it is able to multiplex, so I think an explicit indication would be good.
>>
>> There may be more than one stream per m-line, but I think we can assume that every stream binds to one m-line.
>
> I am not sure I understand what you mean by "binds to one m-line".
>
> However, keep in mind there can be multiple streams per m- line
> already today (at least for RTP), so it's not something BUNDLE
> specific :)

My point is that the *goal* of this exercise is to be able to associate each incoming packet with exactly one of the bundled m-lines.
So there must be an unambiguous mapping that does that - "binds" each packet to the m-line it belongs with.

>>> It is important to remember that, whatever you multiplex, all media have to use the same IP transport (e.g. UDP).
>>
>> Unfortunately SDP has a pretty confusing idea of "transport".
>> The proto field identifies a whole stack of protocol layers.
>
> Yes, and therefor, when we say "must use the same protocol", we need
> to make it clear that we refer to the Protocol value in the IP header
> - not the proto value in the SDP media description :)
>
> I will reply to the rest of your e-mail later, because I need a little
> more time to read it :)

OK.

        Thanks,
        Paul