Re: [MMUSIC] Proposal for what bundle should say about demux

Christer Holmberg <> Mon, 27 May 2013 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9C8721F9524 for <>; Mon, 27 May 2013 05:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.972
X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bG7euLJ2EFVO for <>; Mon, 27 May 2013 05:49:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7BB6A21F9452 for <>; Mon, 27 May 2013 05:48:59 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fe36d000007102-c3-51a3563abba1
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 19.0F.28930.A3653A15; Mon, 27 May 2013 14:48:58 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Mon, 27 May 2013 14:48:57 +0200
From: Christer Holmberg <>
To: Colin Perkins <>, Cullen Jennings <>
Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux
Thread-Index: AQHOV9/DVjr8src5NEuGXcSJwmehbJkY3cWAgAAh+IA=
Date: Mon, 27 May 2013 12:48:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrILMWRmVeSWpSXmKPExsUyM+Jvra5V2OJAg7N/BCyWvzzBaNExmc1i 6vLHLA7MHlN+b2T1mHb/PpvHkiU/mQKYo7hsUlJzMstSi/TtErgypty5wlrQIFIxYeJOtgbG Z/xdjJwcEgImEkcmzmSEsMUkLtxbzwZiCwkcZpR4t1G2i5ELyF7CKNF/7CtTFyMHB5uAhUT3 P20QU0TAU6LzsQdIObOAvMSFJWuYQGxhAVeJc0dXg9kiAm4SzUsuMEPYVhJ3t+xhBGllEVCV 6FluD2LyCvhKdK7kgFjUzCgxs/sLWDmngKPE28+/2EFsRqDLvp+CGM8sIC5x68l8JoiLBSSW 7DnPDGGLSrx8/I8VZKaEgKLE8n45iHIdiQW7P7FB2NoSyxa+BivnFRCUODnzCcsERrFZSKbO QtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBEbLwS2/dXcwnjoncohRmoNFSZxXj3dxoJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbG4tBFuyqvs3vILL7vw/I+52ZN8vOpa9puXt1Y+a1wd9ee tGDjQ41f3lft8lu2ZA5X6c+4hirnwO9Xf936mv1g17o675IVZ9N5Pya7zqo0SQpkM/HpKCwy iEwWucF7hLdeSP7w8ZCoQ1sZpb9c3Dw9NGsWn+LK/P97fIyuO3WbXyti/VKVqP1RiaU4I9FQ i7moOBEAxNF7imQCAAA=
Cc: mmusic WG <>
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
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: Mon, 27 May 2013 12:49:04 -0000


> I'm not sure I agree.
> As I said in my previous message to the list, if we are agreed that the m= lines in a BUNDLE group form a single RTP session, then I believe we
> need unique payload types across all m= lines. In this case, BUNDLE can simply say that regular RTP source demultiplexing based on the SSRC 
> has to be performed, then the payload type can be used to match sources to m= lines for those applications that care about doing so. 
> If we're not agreed that the m= lines in a BUNDLE group form a single RTP session, then we have a lot more to discuss...

Keep in mind that the single-RTP-session has been an assumption for a long time already - it was not something we agreed upon last week :)



On 23 May 2013, at 19:02, Cullen Jennings (fluffy) wrote:
> Here's is my proposal for roughly what the bundle draft should say about this demux topic 
> Application will decide which packet processing pipeline to pass an given RTP/RTCP packet to based on what the application knows:
> 1) If future RFCs define new things (like RTP header extension), that explicitly specify the mapping, check if that future RFC is in use and if so then use that to form the mapping 
> 2) If the PT type is uniquely identifies a mapping, use that to form the mapping
> 3) If application knows the SSRC the other side will use, use that to form the mapping 
> 4) if there is no way to know which pipeline to pass it too, the packet MAY be discarded or the application MAY decide to buffer it until the mapping is known 
> This is trivial to implement. It meets the requirements for Plan A, Plan B, UCIF, CLUE, and so on. 
> We could swap the order of step 2 and 3, My thinking for this order was the only time it made any difference the order was if the PT were unique and indicated a different mapping than the SSRC. The only way this could happen is with a SSRC collision so the PT is the one that would be correct not the SSRC. If someone feels strongly the order of steps 2 and 3 should be the opposite way around, I can live with that.
> _______________________________________________
> mmusic mailing list

Colin Perkins

mmusic mailing list