From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Emil Ivov <emcho@jitsi.org>
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: <C5E08FE080ACFD4DAE31E4BDBF944EB11351027A@xmb-aln-x02.cisco.com>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com>
 <519E80E4.6010904@jitsi.org>
In-Reply-To: <519E80E4.6010904@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2F9B32C462A59F459A37FC03A77BF53B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
Precedence: list

On May 23, 2013, at 2:49 PM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey all,
>=20
> So first of all, I'd like to say that I like the approach and think this
> is the way to go.
>=20
> 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:
>=20
> On 23.05.13, 21:02, Cullen Jennings (fluffy) wrote:
>>=20
>> Here's is my proposal for roughly what the bundle draft should say about=
 this demux topic=20
>>=20
>> Application will decide which packet processing pipeline to pass an give=
n RTP/RTCP packet to based on what the application knows:
>>=20
>> 1) If future RFCs define new things (like RTP header extension), that ex=
plicitly specify the mapping, check if that future RFC is in use and if so =
then use that to form the mapping=20
>=20
> 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=
.
>=20
> 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).
>=20
> 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.
>=20
> I believe we've built bundle port allocation and trickle ICE (and a
> number of other O/A mechanisms) around the same model.
>=20
> Emil
>=20

What I had in mind was something along the lines of the following=20

A is sending an offer that forks to B and C. A and B support the new mechan=
isms but C does not. A has no idea if the things it is talking to support t=
he new thing.=20

A constructs an offer that in the SDP has an indication it can receive the =
header extension. Perhaps something like "a=3Dnew-hdr-ext=3D123456". The ne=
w 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 m=
apping.=20

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 wit=
h the identifier 123456.=20

Imagine the RTP packets from B and C arrive at A before any SDP answer. A l=
ooks at the RTP packet from B, and see the header exertion and reads out th=
e identifier 123456 and now knows the mapping. A looks at the RTP packet fr=
om C and does not see the RTP header extension so it carries on to try othe=
r things.=20

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 f=
rom C until the answer arrives. But that is fine - if you are using somethi=
ng 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 f=
ast as it can be.=20

That seems like the type of design we want.=20