Re: [MMUSIC] Unified Plan for SDP Handling

[Jonathan Lennox <[e-mail]>]

On Jul 18, 2013, at 10:52 PM, Bernard Aboba <[e-mail]<mailto:[e-mail]>> wrote:

Jonathan said:
> > The app-id idea is useful for multiple reasons. One reason similar RTP extensions are used today is to avoid having to parse the payload to figure out what the stream is (e.g. looking for parameter sets or SEI NAL units).
>
> That sounds like an interesting idea, but unless I'm misunderstanding you, that sounds very different from what app-id (or the correlator, in Unified) is doing. Those are for identifying streams, whereas this sounds more like identifying the sub-structure of a stream (i.e. which packets contain parameter sets or SEIs).

[BA] My understanding of the problem solved by deployed RTP extensions expressing layering is similar to
that in:
http://tools.ietf.org/html/draft-fineberg-avtext-temporal-layer-ext

That is, these extensions are not used to flag packets containing parameter sets or SEIs.  Rather the
desire is to allow the MANE to avoid having to decrypt the SRTP packet to figure out what layer it
corresponds to before deciding whether to drop or forward it.  In a circumstance where the SSRC
either isn't pre-declared in SDP O/A or could correspond to multiple layers, that makes some sense.

I agree what you're describing is similar to the Fineberg draft, and a common mechanism (codec-independent, to the extent possible) would likely be useful.

I don't think it's very similar to app-id, though -- unless you're assuming MST here too, and you're trying to identify the component MST streams of a layered encoding?

--
Jonathan Lennox
[e-mail]<mailto:[e-mail]>