Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB1135183E7@xmb-aln-x02.cisco.com>
Date: Mon, 27 May 2013 14:57:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7E47BAA-5289-4C34-A9B9-6E8A1147D20F@csperkins.org>
References: <C5E08FE080ACFD4DAE31E4BDBF944EB11350F3C8@xmb-aln-x02.cisco.com>
 <71E1CC64-09A0-41D3-81D0-CFE8C30277B1@csperkins.org>
 <C5E08FE080ACFD4DAE31E4BDBF944EB1135183E7@xmb-aln-x02.cisco.com>
To: Cullen Jennings (fluffy) <fluffy@cisco.com>
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Proposal for what bundle should say about demux
Precedence: list

I don't agree with the phrasing about "packet processing pipelines", but =
can't tell if this is a terminology disagreement or a more fundamental =
disconnect. The way I see the demultiplexing logically working is:

                    |
                    | packets
    +--             v
    |           +----------+
    |           |UDP socket|
 A  |           +----------+
    |        RTP ||  |  |
    |   and RTCP ||  |  +------> SCTP
    |            ||  +---------> STUN/ICE
    +--          ||
    +--          ||
    |       split by SSRC
    |       ||   ||   ||
    |       ||   ||   ||
 B  |      +--+ +--+ +--+
    |      |PB| |PB| |PB| Playout buffer, process RTCP, FEC, etc.
    |      +--+ +--+ +--+
    +--      |   |     |
    +--      |  /      |
    |        +---+     |
    |         /  |     |
 C  |      +--+ +--+ +--+
    |      |CR| |CR| |CR| Codecs and rendering
    |      +--+ +--+ +--+
    +--

If your algorithm is for demultiplexing at layer C, i.e., to figure out =
what codec and rendering pipeline to use, then I think we're in =
agreement apart from terminology.=20

For layer B, I believe the SSRC is the right thing to use to =
demultiplex, and fits with RTP and RTCP. This is where RTCP is =
processed, playout de-jitter buffering happens, FEC is processed, NACKs =
are sent, etc. It's logically independent of the decoding and rendering =
process since you can start filling your de-jitter buffer for an SSRC =
before you figure out if/how/where you're going to render that SSRC.=20

For layer A, there was a clear-cut way of doing this with RTP, RTCP, and =
STUN. I haven't looked at SCTP enough to know how that affects things. I =
do think it's a logically separate issue, and should be documented =
separately to BUNDLE though, since it the same issues arise with =
non-bundled sessions.

An implementation might merge these together, of course, but to avoid =
confusion the standards should be clear what level they're considering.

Colin



On 27 May 2013, at 14:15, Cullen Jennings (fluffy) wrote:
> Great - sounds like we agree this algorithm will work.
>=20
> On May 27, 2013, at 6:41 AM, Colin Perkins <csp@csperkins.org> wrote:
>=20
>> I'm not sure I agree.
>>=20
>> As I said in my previous message to the list, if we are agreed that =
the m=3D lines in a BUNDLE group form a single RTP session, then I =
believe we need unique payload types across all m=3D 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=3D lines for those applications that care about doing =
so.=20
>>=20
>> If we're not agreed that the m=3D lines in a BUNDLE group form a =
single RTP session, then we have a lot more to discuss...
>>=20
>> Colin
>>=20
>>=20
>>=20
>> 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=20
>>>=20
>>> Application will decide which packet processing pipeline to pass an =
given RTP/RTCP packet to based on what the application knows:
>>>=20
>>> 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=20
>>>=20
>>> 2) If the PT type is uniquely identifies a mapping, use that to form =
the mapping
>>>=20
>>> 3) If application knows the SSRC the other side will use, use that =
to form the mapping=20
>>>=20
>>> 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=20
>>>=20
>>> This is trivial to implement. It meets the requirements for Plan A, =
Plan B, UCIF, CLUE, and so on.=20
>>>=20
>>> 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.
>>>=20
>>>=20
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>=20
>>=20
>>=20
>> --=20
>> Colin Perkins
>> http://csperkins.org/
>>=20
>>=20
>>=20
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>=20
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic



--=20
Colin Perkins
http://csperkins.org/