Real SIP stack for Chrome

[Guilherme Versiani]

Hi,

I've started a project of a SIP stack in C++ reusing Chrome source code (basically base + net + webrtc), and my final objective is to achieve a simple stack which could be used by JavaScript applications in the same way PeerConnect does.

The motivation is to aim Chrome to do SIP calls natively without the need of encapsulating protocols, such as those currently available using WebSockets. Chrome could use UDP/TCP/TLS protocols directly as SIP transport, becoming directly connectible to SIP networks, hardware, softphones, etc. without the need of expensive and useless translating gateways.

This is the link: http://sippet.googlecode.com/

The project is at an early stage, where I'm still writing and testing the SIP message parser and keeping this part as maintainable as possible. Next stage will be the creation of the transport and transaction layers, the main infrastructure of the stack.

Any help, comments, etc. are welcome.

Regards,
Balena.

[James Mortensen]

Hi Balena (Guilherme),

• Are you suggesting that SIP messaging be added directly into the Chromium build itself to eliminate the need for JavaScript libraries that use SIP over WebSockets, such as JsSIP or sipML5?  

• It sounds like this would be SIP over UDP/TLS/TCP, and it sounds like you picture the final result as becoming a native part of Chromium?

What do you picture the API looking like for a developer who wishes to utilize such a solution?

Would it be compatible with the WebRTC spec? This sounds like an interesting idea.  Let me know if I can help test anything and I'll see what I can do. :)

James

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-discuss

--
James Mortensen
Project Manager, VoiceCurve, Inc.
866-707-4590
james.m...@voicecurve.com

[Guilherme Versiani]

Hi Mr. James,

• Are you suggesting that SIP messaging be added directly into the Chromium build itself to eliminate the need for JavaScript libraries that use SIP over WebSockets, such as JsSIP or sipML5?  

Yes. My main concern is that the current voice and video, when integrating to existing SIP networks, needs to implement a SIP stack on JavaScript. And a SIP stack (full-featured and compatible) is not so straightforward to implement... It sounds like giving socket access to the JavaScript layer and letting the developers implement HTTP entirely in the JS layer!...

Moreover, when talking SIP, WebSockets support is limited to a few existing server-side solutions, and doesn't benefit from the low-cost UDP protocol, used in those networks.

 

• It sounds like this would be SIP over UDP/TLS/TCP, and it sounds like you picture the final result as becoming a native part of Chromium?

Yes, actually my first idea was to create a SIP stack reusing Chrome source to speed up the development, but in the end, make the browser supporting SIP seemed a good idea to me...

 

What do you picture the API looking like for a developer who wishes to utilize such a solution?

Currently there's no session API being exposed in Chrome, right? It's being delegated to the application itself, and developers normally implement Jabber/XMPP using WebSockets. I would like to create something over the existing PeerConnection API, extending the required session handling.

 

Would it be compatible with the WebRTC spec? This sounds like an interesting idea.  Let me know if I can help test anything and I'll see what I can do. :)

It will be using WebRTC as the audio/video engine, and reusing the PeerConnection API, so, yes... But due to the session requirements, something else will need to be exposed. It would seem more like an extension.

Regarding the tests, it's not ready for testing yet. Actually I'm still creating the unit tests for the SIP headers, which are the biggest headache for the SIP stack development. I want to make it robust, supporting at least a part of RFC 4475. After that, it will be just connect the network part (the SIP transport) and implementing the machine-state used for transferring SIP requests/responses. This basic environment can be immediately exposed to JavaScript once done, then the developer have just create some default messages based on context, and customize as he wants. Something in the middle should connect the PeerConnect to selected requests (like INVITE) and it's done.

Further reuse for other purposes can be done in the same way indicated above. The security and user privacy can be improved by controlling what SIP headers can be modified by the developer.

Regards,

Balena.