Re: [rtcweb] Current state of signaling discussion

[Eric Rescorla <[e-mail]>]

On Tue, Oct 18, 2011 at 1:30 PM, Hadriel Kaplan <[e-mail]> wrote:
>
> Dear Chairs,
> I have a question of clarification on your request for "signaling" proposals/drafts.
> Which *type* of "signaling" do you mean?  What purpose/problem-solution are these candidate drafts meant to address?
>
> In the email below, you indicate draft-jennings-rtcweb-signaling is one of the drafts that provides a solution, but as far as I can tell it is not a session signaling protocol; it is just a protocol for SDP offer/answer.  It is not a sufficient solution for sessions, and it admits that within its own text.  It would not, for example, let one write a RTCWeb-based communication application in "20 lines of code".


Is this actually correct? The introduction of that draft suggests otherwise:

"The protocol is designed to operate between two entities (browsers
for example), which exchange messages "directly" - meaning that a
message output by one entity is meant to be directly processed by the
other entity without further modification. In practice, this means
that a web server can treat ROAP messages as opaque and just shuffle
them between browser instances. This allows for simple
implementations."

If we take the PeerConnection API as our point of reference, isn't the
idea here that
you would instantiate callbacks that take messages coming out of the
PeerConnection
API and push them to the Web server and messages coming from the Web server
and push them to the PeerConnection instance. I don't know if this is 20 lines
of code (though with JS minimization it might be one line of code :)),
but it does
seem comparatively trivial...

-Ekr




-Ekr