Subject: Re: [MMUSIC] Unified Plan for SDP Handling

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jul 2013 16:21:43 -0700

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).  It is cleaner to solve this in as generic rather than a codec-specific way.  I see no conflict with no-plan; in fact, I believe no plan suggested an RTP extension, no?

Jonathan Lennox <[email-masked]> wrote:

On Jul 16, 2013, at 4:38 PM, Adam Roach <[email-masked]> wrote:

> On 7/16/13 15:28, Roni Even wrote:
>> Adam,
>> For correlation when the SSRC is not known in the SDP look at
>> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt and the
>> option to use SDES and not only RTP header extension.
>
> Roni:
>
> Thanks for the pointer. That's an interesting approach; however, for
> RTCWEB at least, need a solution that also works with DTLS-SRTP.

Acronym collision: This uses RTCP Source Description packets, not SDP Security Descriptions.

I think the (related) app-id approach described in http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt will also be of interest.

--
Jonathan Lennox
[email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Emil Ivov <[email-masked]>
Date: Wed, 17 Jul 2013 01:24:39 +0200

On 17.07.13, 01:21, Bernard Aboba wrote:
> 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).  It is cleaner to solve this in as generic rather
> than a codec-specific way.  I see no conflict with no-plan;

+1

> in fact, I believe no plan suggested an RTP extension, no?

It did indeed.

Emil

>>> Adam, For correlation when the SSRC is not known in the SDP look
>>> at
>>> http://tools.ietf.org/id/draft-even-mmusic-multiple-streams-02.txt
>>> and the option to use SDES and not only RTP header extension.
>>
>> Roni:
>>
>> Thanks for the pointer. That's an interesting approach; however,
>> for RTCWEB at least, need a solution that also works with
>> DTLS-SRTP.
>
>
> I think the (related) app-id approach described in
> http://tools.ietf.org/html/draft-even-mmusic-application-token-00.txt
> will also be of interest.
>
> -- Jonathan Lennox [email-masked]
>
>
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>

-- 
https://jitsi.org

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 17 Jul 2013 13:07:41 -0400

On Jul 16, 2013, at 7:21 PM, Bernard Aboba <[email-masked]> wrote:

> 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).

I could imagine that being useful, but it doesn't sound very related to stream correlation.

> It is cleaner to solve this in as generic rather than a codec-specific way.  I see no conflict with no-plan; in fact, I believe no plan suggested an RTP extension, no?
> 

--
Jonathan Lennox
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Jul 2013 19:52:53 -0700

> 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,…

[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.

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 19 Jul 2013 10:58:41 -0400

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

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
[email-masked]<mailto:[email-masked]>