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

Christer Holmberg <> Wed, 19 June 2013 15:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F66121F9986 for <>; Wed, 19 Jun 2013 08:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.812
X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PXLoXDWUrcXT for <>; Wed, 19 Jun 2013 08:56:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 137AD21F9D98 for <>; Wed, 19 Jun 2013 08:56:37 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-a5-51c1d4b49e85
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 4D.67.18006.4B4D1C15; Wed, 19 Jun 2013 17:56:36 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Wed, 19 Jun 2013 17:56:36 +0200
From: Christer Holmberg <>
To: Bernard Aboba <>, Harald Alvestrand <>
Thread-Topic: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
Thread-Index: Ac5s4y9zPDdk8vnuSOSyMPT24r/CS///6fSA///dtTCAACcFAIAADdaA///cleCAAC1bgIAAPlNg
Date: Wed, 19 Jun 2013 15:56:35 +0000
Message-ID: <>
References: <>, <>, <>, <>, <BLU169-W56DEA51EC84C8180A7DCD5938D0@phx.gbl>, <>, <BLU169-W1288AEADA7A090C209F376C938D0@phx.gbl>
In-Reply-To: <BLU169-W1288AEADA7A090C209F376C938D0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3B0EF1ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvre6WKwcDDf6d0bTYv+Qys8Wxvi42 i6nLH7M4MHtcmXCF1eNxzxk2jyVLfjIFMEdx2yQllpQFZ6bn6dslcGesOj6XveCjSsWHZedY Gxjb5bsYOTkkBEwk+u7cZoGwxSQu3FvP1sXIxSEkcJhRYu/JjVDOIkaJVUdusncxcnCwCVhI dP/TBmkQEYiUeDTzIyuIzSygKvF66ncwW1jAQeLe71mMEDWOEs1L3rKAtIoIREks31EFEmYB Kj8z9xPYXl4BX4lnz1+wQKz6wCTxrXc6O0iCU8BaYkVzFxOIzQh03PdTa5ggdolL3Hoynwni aAGJJXvOM0PYohIvH/+DuidfYs269+wQCwQlTs58wjKBUWQWkvZZSMpmISmDiOtJ3Jg6hQ3C 1pZYtvA1M4StKzHj3yEWZPEFjOyrGNlzEzNz0suNNjECI+rglt+qOxjvnBM5xCjNwaIkzvvx 1K5AIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJwggkuqgXHujcbIu/xzQvNkzv8+9EJ1d8kvn6p7 196FBsULP2dd96br+zSprp0WNX37c5LaanJUPNl5eh/933V3cxzzQ81VsnMSzOcIh5deZU+8 t53lw/L9B5f0iu3I82Ro+3TFYN/PNTxnt+2aPOW57P1jj25/68i7vGvZrLL86KmF9rUXltSL tzA/ed+pxFKckWioxVxUnAgAhLUEe3sCAAA=
Cc: "" <>
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2013 15:56:51 -0000


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.




Sent from Windows using TouchDown (

-----Original Message-----
From: Bernard Aboba []
To: Christer Holmberg []; Harald Alvestrand []
CC: []
Subject: RE: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Christer said:

"The suggested text currently says that, in case you have multiple "m=" lines associated with the same transport protocol (e.g. RTP/AVP), selecting which of those "m=" lines received media belongs (whether it's based on PT, SSRC or something else) to is outside the scope of the document.

But, IF we think that shall be described, then we need to add text."

[BA] Leaving this out could result in interoperability problems (unless it is specified elsewhere and this document references that).     So I do think that some text is needed, somewhere.