Thursday 5 July 2012

WebRTC and SIP...Experimentation underway...

I am currently hosting a visiting researcher in my office and we are exploring the potential of WebRTC and SIP interoperability. WebRTC is still draftly, but a number of milestones have already been reached in terms of standardizing the transport protocol as JSEP (JavaScript Session Establishment Protocol), for instance. Google Chrome  (Canary) supports the WebRTC API - I have played around with the flags (PeerConnection) and have tried making SIp Calls between browsers...very nice.

Still unsure of how to get started on the server side, but this should become clearer....I have Mobicents Sip Servlet (on Tomcat 7) running...now starting with a simple chat-server that proxies chats between two browsers (as SIP clients - thanks to WebRTC!) - I will then move into audio/video calls in the same manner...via SIP-Servlet-With-WebRTC.

6 comments:

  1. The WebRTC API Spec: http://dev.w3.org/2011/webrtc/editor/webrtc.html

    ReplyDelete
  2. This is one of the very informative sources - well done guys!:
    http://sip-on-the-web.aliax.net/

    ReplyDelete
  3. Conference on WebRTC, 10-12 October, 12012 , France: http://www.uppersideconferences.com/webrtc2012/webrtc2012intro.html

    ReplyDelete
  4. The joys of cutting edge, now SIP Servlet 2.0 Java Specification Requesnt has been filed - looks like the draft will be available next year (2013) - for now, every little effort we put in getting demos workign will surely help speed up the developments in the area of WebRTC which has been identified as one of the areas the spec will address (aligning requirements from other standardization efforts).

    ReplyDelete
  5. A WebSocket servlet test underway...some minor issues with the handshake, but nothinto worry...I am getting Sec-WebSocket-Accept Mismatch...I forgot to Base64.encode the key+magic...this should get rid of the problem...

    ReplyDelete
  6. Yes, the handshake work...returning 101 (Switching Protocol) - but...i get an error which is suspected to be cause by calling .fluch() on the request's PrintWriter...removing this and testing..

    ReplyDelete