Re: [MMUSIC] Unified Plan for SDP Handling

On Jul 16, 2013, at 7:21 PM, Bernard Aboba <bernard_aboba@hotmail.com> 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 <jonathan@vidyo.com> wrote:
> 
> 
> On Jul 16, 2013, at 4:38 PM, Adam Roach <adam@nostrum.com> 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
> jonathan@vidyo.com
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

--
Jonathan Lennox
jonathan@vidyo.com