- From: Wolfgang Beck <wolfgang.beck01@googlemail.com>
- Date: Thu, 09 Aug 2012 21:00:58 +0200
- To: public-webrtc@w3.org
- CC: Jim.Barnett@genesyslab.com
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.. Wolfgang Beck
Received on Sunday, 12 August 2012 16:21:16 UTC