W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

Re: Proposal: RtpListener for unsignalled ssrcs

From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 13 Feb 2014 14:52:58 -0800
Message-ID: <CAJrXDUHwvcGmFDsCD5wQsu7rPZS4JAq3eRraCWDAPnUxgmGRJg@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Cc: Emil Ivov <emcho@jitsi.org>, "public-orca@w3.org" <public-orca@w3.org>
On Thu, Feb 13, 2014 at 2:42 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2014-02-13 23:32 GMT+01:00 Peter Thatcher <pthatcher@google.com>:
> > One could use it to create an RtpReceiver to get a track to render.
>  This is
> > especially useful if we have the RTP header extension that allows the
> app to
> > include meta data so the receiver knows what to do with the media,
> without
> > the need for signalling ahead of time.
> How can the receiver know which media type and codec are in use?
> This is:
> - Alice signals its media info to Bob, and includes info for Bob to
> set in the RTP header extension (in case Bob wants to send media to
> Alice even before Alice receives the media info signaling from Bob).
> - Alice starts receiving RTP packets (the N first ones include such a
> negotiated RTP header extension).
> - How can Alice know which codec do those RTP packet include?
> ​
The app may predefine codecs (100=OPUS, 101==VP8), or Alice and Bob can
negotiate codecs ahead of time.

​And there are use cases other than 1:1.  For example, in a multiway
scenario, media streams come and go and you want to receive media quickly.
 You can negotiate codecs once, and then just receive new media as it
becomes available.
Or maybe you make an application that requests video from a server, where
it negotiates codecs ahead of time and then ​
​you want quick "click and see video", and so you start sending media
immediately without knowing the ssrc ahead of time.
There are lots of use cases ​
​other than the typical Alice:Bob call.

> Do I miss something?
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
Received on Thursday, 13 February 2014 22:54:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC