WebRTC and SIP Over WebSockets
draft-ietf-sipcore-sip-websocket defines a way to use WebSockets formally as a transport for SIP. It is not possible to simply view the WebSocket as a tunnel and pass SIP messages through them. Specfically, SIP user agents and proxies must behave slightly differently when WebSockets is used instead of UDP or TCP, and the draft specifies what this means in practice. There is a branch in reSIProcate attempting to implement this behavior.
NAT busting: living the dream
- NAT has always been a pain for SIP
- WebRTC offers great hope for NAT busting, by masquerading as HTTP and HTTPS traffic and getting relayed by HTTP proxies
- running a SIP proxy WebSocket server on port 443 makes it look like a real HTTPS server and allows end users to reach it from almost anywhere
* the reSIProcate SIP proxy, repro, can listen on port 443 and talk WebSockets over TLS
- for media relay to traverse NAT, it is also necessary to use a TURN server on port 443
* the reSIProcate TURN server, reTurn, can listen on port 443
- Unresolved issues:
* it is also necessary for the TURN client to use secure TURN (TURNS) over port 443. This is not yet implemented in Google Chrome - bug tracker link
reSIProcate and WebRTC
- WebRTC specifies that ICE/STUN/TURN support is mandatory in user agents/end-points. The reTurn server project and the reTurn client libraries from reSIProcate can fulfil this requirement.
- WebRTC requires some mechanism for finding peers and initiating calls. SIP over WebSockets, interacting with a repro proxy server can fulfill this task.
Current support for WebSockets
- There is a branch in the repository
- There has been discussion in various threads on the resiprocate-devel mailing list
- and some test results/observations
- Using options like EnableFlowTokens seems to be helpful
WebRTC capable browsers
- The SIP client must be hosted on a web server such as Apache