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

"Mo Zanaty (mzanaty)" <> Thu, 23 May 2013 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96AA221F90EA for <>; Thu, 23 May 2013 15:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JG3x6OglKEfw for <>; Thu, 23 May 2013 15:29:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 507D321F9929 for <>; Thu, 23 May 2013 14:48:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3092; q=dns/txt; s=iport; t=1369345690; x=1370555290; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZTstaeb5UIz6VxUGTI2aJZoBR0DPoHK37M5fWt8q2jI=; b=dT2YpRlwSrMMtle/lFxFpM/36NNQ2XVGmMb9uJS6CuKjXJtKYBOJcm1X paf6aTY0QdfUKZ2MA0Z6fzl1Z/Ar/UOLMTN9GEerWT5Au0VP4GfgQfNaX H0iK+hHFBywfQVjcSVm31Ta91Za8xEzefEYV4NYNcIzlDH9jfLa9FesOh M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,730,1363132800"; d="scan'208";a="214347136"
Received: from ([]) by with ESMTP; 23 May 2013 21:48:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4NLm9v6032099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Thu, 23 May 2013 21:48:09 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 23 May 2013 16:48:09 -0500
From: "Mo Zanaty (mzanaty)" <>
To: "Cullen Jennings (fluffy)" <>, mmusic WG <>
Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux
Thread-Index: AQHOV9/DVjr8src5NEuGXcSJwmehbJkTIk8w
Date: Thu, 23 May 2013 21:48:08 +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
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: Thu, 23 May 2013 22:29:07 -0000

I agree with this, including the order of 2 and 3.

I was initially averse to PT demux, for RTP purist reasons (since it is intended to convey codecs not sources) and practical reasons (limited space of 32-96 code points, depending on your interop risk tolerance, for all combinations of codecs and sources). But I have warmed up to it based on a realization that I (and maybe others) missed.

When using rtcp-mux, there must *always* be an initial step:
0) PT demux to classify RTP vs. RTCP
...before you can look at RTP header extensions in 1 (no X bit in RTCP headers)
...before you can look at SSRCs in 3 (different SSRC offsets in RTP vs. RTCP headers)

Given step 0, it is hard to argue against PT demux from a RTP purist view. The practical problem of the limited PT space remains. But for simple cases, like a single audio and video stream with a reasonable number of codec formats, I see no reason to disallow or discourage this, since step 2 can be folded into step 0. For more complex cases, with more sources and codec formats, FEC/RTX, scalable/simulcast layers, screen sharing, multiple cameras, etc., it quickly becomes impractical or impossible. In that sense, Plan A may work best for simple cases, while Plan B may work best for complex cases. But both could still share these common demux rules.


-----Original Message-----
From: [] On Behalf Of Cullen Jennings (fluffy)
Sent: Thursday, May 23, 2013 2:03 PM
To: mmusic WG
Subject: [MMUSIC] Proposal for what bundle should say about demux

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