Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 19 June 2013 18:01 UTC

Return-Path: <prvs=788294ad5f=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 4D79A21F9AC3 for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 11:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.833
X-Spam-Level:
X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.416, 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 Auh0C5AVvQDA for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 11:01:25 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A49C821F9BD4 for <mmusic@ietf.org>; Wed, 19 Jun 2013 11:01:05 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-4f-51c1f1df184d
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B0.5E.18006.FD1F1C15; Wed, 19 Jun 2013 20:01:03 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 20:01:03 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg///oowD//9xlEP//0iKA//91ifA=
Date: Wed, 19 Jun 2013 18:01:03 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B14BD@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no>, <BLU169-W56DEA51EC84C8180A7DCD5938D0@phx.gbl>, <7594FB04B1934943A5C02806D1A2204B1C3B0B60@ESESSMB209.ericsson.se>, <BLU169-W1288AEADA7A090C209F376C938D0@phx.gbl> <7594FB04B1934943A5C02806D1A2204B1C3B0EF1@ESESSMB209.ericsson.se> <51C1DD3A.8030705@alvestrand.no> <7594FB04B1934943A5C02806D1A2204B1C3B1392@ESESSMB209.ericsson.se> <51C1E5D5.9020009@jitsi.org>
In-Reply-To: <51C1E5D5.9020009@jitsi.org>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvre79jwcDDZYcsbBYs3MCi8Wxvi42 i6nLH7M4MHtcmXCF1WPJkp9MHv/fBAYwR3HbJCWWlAVnpufp2yVwZ7Ss2MNYsEqw4uOzNtYG xiu8XYycHBICJhLzt61khrDFJC7cW8/WxcjFISRwmFFiwoOvLBDOIkaJ71cXsnYxcnCwCVhI dP/TBmkQEZCX6G5bxARiMwsESmzd8YUVxBYWcJA49nomE0SNo0TzkrcsEHaZxJND/9hAbBYB VYkrc/+DLeYV8JXo+dPBCrHrDIvE//VvwBo4BTQlZm3uAhvKCHTd91NroJaJS3w4eB3qagGJ JXvOQ9miEi8f/2OFsJUkGpc8YYWo15FYsPsTG4StLbFs4WuoxYISJ2c+YZnAKDYLydhZSFpm IWmZhaRlASPLKkb23MTMnPRyo02MwMg5uOW36g7GO+dEDjFKc7AoifN+PLUrUEggPbEkNTs1 tSC1KL6oNCe1+BAjEwcniOCSamCcvfae+LabGvxPbft+3P5m/ff+tp99vBuWX048uPdUxPSL Ank5RV2d0Qe3zhdeocTOZd5oMfNNM2Nr+E/9OjvzjXFWrSseXG9kqCmQmPpZtfwY87ZdrcW8 C14yvAhx25ZyePnFzujGaxWCF7pMfOaLGe/s27hHhqd6VsV2kTKjSQJthrPm/n6pxFKckWio xVxUnAgADVQZ3m8CAAA=
Cc: "mmusic_ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
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: Wed, 19 Jun 2013 18:01:32 -0000

Hi,

>>>> The question is whether we shall specify exactly how entities associate RTP packets with the correct m= lines, or whether we shall simply give some guidelines and hints.
>>>>
>>>> For example, a client can choose to use unique PT values per m- 
>>>> values, within a given BUNDLE group, and everything should work 
>>>> fine. And, if the endpoint runs out of PT values, the create a new 
>>>> BUNDLE group. Now, whether it's religiously correct, I don't know :)
>>>>
>>>> OR, if the endpoints are able to signal which SSRCs they are going to use, they can use that.
>>>>
>>>> OR, if the endpoints support some kind of RTP header extension for this purpose, they can use that.
>>>>
>>> OR, if they don't care which M-line the stream is associated with, the question may be moot.
>>
>> Correct.
>>
>>> In all cases, the payload type MUST clearly identify the codec configuration it's associated with.
>>
>> *IF* you have a way to find the right m= line, couldn't PT X have different codec configurations in different m= lines?
>
> Let's assume that it could ... but then how would you know that your peer also supports the same demuxing technique as yourself?

In the PT case, he doesn't have to, because he is going to tell you what PT values he wants you to send him.

> In SIP for example, when constructing a first offer, you may want to map both Opus and VP8 to 96, then add SSRCs for demuxing. This means that you expect your peer to support SSRC demuxing and you can't expect that unless we mandate it.
>
> Or am I missing something?

No. In case of support of extensions (e.g. the SDP ssrc attribute), you either have to perform some kind of capability exchange before you send the initial Offer. Or, you will figure out in the response to the initial Offer, and then you can "fix" it in a new Offer (as BUNDLE is currently specified, you will have to send a second Offer anyway).

But, again, what I want to discuss now is whether/what we are going to specify regarding the usage of multiple m= lines with the same transport protocol (RTP, or whatever other there could be).

Regards,

Christer