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

"Cullen Jennings (fluffy)" <> Thu, 23 May 2013 22:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12AD721F978B for <>; Thu, 23 May 2013 15:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.562
X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a41Yi4dR2ln9 for <>; Thu, 23 May 2013 15:38:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4561321F8B98 for <>; Thu, 23 May 2013 15:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3346; q=dns/txt; s=iport; t=1369347798; x=1370557398; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=imj7/Vr0vseG833cu00e8ygLqHYFYv2gRdFg6xG95Xc=; b=FHvXCRbhs0SiqRI4E4K3xZkOjy6cc1ciCrPXjoNuZRYjxloIg4Kkz271 HpwuyioxCSPurw3QbNHROTHL1i6t/yH73ZypefxuKSC1F62UCf4SCKWnG jtdKCHBaAVxowirfvJkLWCiAGs0kftBA+LPZHDVfa0h3df8K3GvHzwKgH g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.87,730,1363132800"; d="scan'208";a="214381198"
Received: from ([]) by with ESMTP; 23 May 2013 22:22:58 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r4NMMwvh031543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 May 2013 22:22:58 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Thu, 23 May 2013 17:22:58 -0500
From: "Cullen Jennings (fluffy)" <>
To: Emil Ivov <>
Thread-Topic: [MMUSIC] Proposal for what bundle should say about demux
Thread-Index: AQHOV/cQIaUMan7TmECSKq/rU07GDJkTrAqA
Date: Thu, 23 May 2013 22:22:33 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 23 May 2013 22:38:41 -0000

On May 23, 2013, at 2:49 PM, Emil Ivov <> wrote:

> Hey all,
> So first of all, I'd like to say that I like the approach and think this
> is the way to go.
> I have just one concern here. I already mentioned it in the call but I
> am not quite sure what the answer was. So here I go:
> On 23.05.13, 21: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 
> So my problem with having the above as number one is that while it would
> work perfectly with protocols like XMPP that have good discovery
> support, it would be a problem for SDP O/A based ones like SIP and WebRTC.
> The reason is that even when demuxing RFCs like that exist, an offerer
> won't know if the remote party supports them. They would hence always
> need to construct an offer where a fallback to another mechanism could
> be possible (like for example falling back to uniquely allocated PTs).
> Now, if the offerer does indeed know in advance that the fancy demuxing
> RFC will be supported, and only then, they would be able to rely on it
> and be careless about PT allocation.
> I believe we've built bundle port allocation and trickle ICE (and a
> number of other O/A mechanisms) around the same model.
> Emil

What I had in mind was something along the lines of the following 

A is sending an offer that forks to B and C. A and B support the new mechanisms but C does not. A has no idea if the things it is talking to support the new thing. 

A constructs an offer that in the SDP has an indication it can receive the header extension. Perhaps something like "a=new-hdr-ext=123456". The new header extension allows one to embed an identifer in the RTP packets and this SDP indicates that the identifier should be 123456 for RTP with this mapping. 

A sends the offer and it arrives at both B and C. C does not understand it and just ignores it. B understands it and inserts a TP header extension with the identifier 123456. 

Imagine the RTP packets from B and C arrive at A before any SDP answer. A looks at the RTP packet from B, and see the header exertion and reads out the identifier 123456 and now knows the mapping. A looks at the RTP packet from C and does not see the RTP header extension so it carries on to try other things. 

So yes, as you point out, for the packets from C where it can't use PT, it needs to fall back to SSRC which means A can't really process the packets from C until the answer arrives. But that is fine - if you are using something that does not support the new stuff, the behavior you get is the best we can do with the old stuff yet at the same time you get the faster behavior with things that do the new stuff. C is as fast as it can be and B is as fast as it can be. 

That seems like the type of design we want.