Re: [rtcweb] ROAP Example Application

[Eric Rescorla <[e-mail]>]

On Fri, Oct 21, 2011 at 7:13 AM, Matthew Kaufman
<[e-mail]> wrote:
> On 10/21/11 4:00 AM, Harald Alvestrand wrote:
>>
>> On 10/21/2011 08:46 AM, Matthew Kaufman wrote:
>>>
>>> On 10/20/11 7:08 PM, Cullen Jennings wrote:
>>>>
>>>> I liked Dan Yorks rant on what we need and it made me want to show some
>>>> simple code using an interface like the current W3C PeerConnection API along
>>>> with ROAP. Assuming the ROAP objects got passed in and out of the Peer
>>>> Connection object, here is a short little example I copied that shows how
>>>> simple it is to write a web application that sets up an audio / video
>>>> connection between two browsers. It assumes a simple web server that that
>>>> can pass messages from alice to bob and visa versa. Both alice and bob just
>>>> short poll the web server to get messages from their mailbox and post
>>>> messages to the others mailbox. The web server does not transform the
>>>> messages in any way. Clearly this example is wrong in some ways, lacks
>>>> authentication, and various error handling but I think it illustrates the
>>>> basics of the interfaces.
>>>>
>>>>
>>>
>>> Thanks for the example.
>>>
>>> However, in addition to illustrating the basics, it also illustrates that
>>> ICE parameters and codec SDP parameters are now inextricably intertwined
>>> within this proposal, where in fact there is a good argument that not only
>>> should they be kept separate but that in fact they are the responsibility of
>>> different objects within the JavaScript API.
>>
>> As I've noted before, they are more entangled than one might like them to
>> be;
>
> This is just an argument that RTP is actually a poor choice as well, but I'm
> afraid it is too late for that.
>
>> if we don't support the extension to use a single RTP session, we don't
>> know how many ICE sessions we need to set up until we know at least how many
>> top level media types we want to support. If we want to support multiple RTP
>> sessions for other reasons, we need similar control of the number of ICE
>> sessions set up.
>
> But none of these examples actually shows that there's a requirement to
> combine the two into a single blob.
>
> An easy solution to these examples, for instance, would be to exchange the
> codec-choosing blobs *first* and then, based on the results, examine the
> "encoder" and "decoder" objects to see how many transport streams they need
> attached. Or, even easier, when you wire the media encoding/decoding objects
> to the transport object, the transport object can know what it will need to
> be transporting and, once it receives an internal event that the codec and
> RTP parameters have been selected, it can fire an event to JavaScript
> containing the ICE setup blob.

Note that Jingle in some cases does sort of the opposite of this:
The caller offers combined media encoding/decoding objects  and
transport objects (in a session-initiate) and the callee sends
back only transport objects (in a transport-info) and then the
combined media encoding objects and transport objects
(in a session-accept).

XEP-0167 has a good example of this.

-Ekr