- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 13 Aug 2012 01:05:50 +0200
- To: public-webrtc@w3.org
On 08/09/2012 09:00 PM, Wolfgang Beck wrote: > On 08/09/2012 05:50 PM, Jim Barnett wrote: >> Martin, >> Yes, it's true that the building the signaling channel is the >> application's problem. >> I'm wondering about how the applications interpret the messages >> that are sent on the signaling channel. > > SDP specifies a syntax and semantics, so that when an application > receives an SDP message over the signaling >> channel, it knows what it is and how to interpret it. How will an >> application know that the message it has >> received over the signaling channel is a RealTimeMedia description? >> >> - Jim > > That's the problem of the web applications (the servers) that talk to > each other. They have to agree on a signaling protocol, they can agree > on a way to exchange media descriptions. > > SDP looks foreign and cumbersome in an environment that easily > serializes and parses complex data structures (JSON). What I got from > the discussions is that it was only chosen so that google can re-use > their existing SDP offer/answer libraries. SIP interconnection should > not be the reason. > > Would it really harm if JSEP dropped SDP in favor of some Javascript > object? It could still have an toSDP function.. As currently described, a SessionDescription is a Javascript object with a toSDP function.... so perhaps we're already there?
Received on Sunday, 12 August 2012 23:06:18 UTC