Difference between revisions of "WebRTC and SIP Over WebSockets"

From reSIProcate
Jump to navigation Jump to search
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
== Get started quickly ==
 +
 +
* Install the [http://packages.debian.org/repro repro SIP proxy using the packages from Debian] or another Linux distribution like Fedora or Ubuntu.
 +
* Set these options in repro.config:
 +
 +
AssumePath = true
 +
DisableOutbound = false
 +
EnableFlowTokens = true
 +
 +
* For local testing, you can use regular HTTP (no TLS) on any port, if you do this, it is necessary to set the record route URI to your host or domain name (not IP):
 +
 +
WSPort = 80
 +
RecordRouteUri = sip:example.org
 +
 +
* For production use, it is significantly more reliable to use TLS, this will ensure that the websocket connection can pass through HTTP proxy servers
 +
 +
Transport1Interface = 192.168.1.106:443
 +
Transport1Type = WSS
 +
Transport1TlsDomain = sip-ws-server.example.org
 +
Transport1TlsClientVerification = None
 +
Transport1RecordRouteUri = sip:example.org;transport=WS
 +
Transport1TlsCertificate = /etc/ssl/ssl.crt/sip-ws-server.example.org-bundle.pem
 +
Transport1TlsPrivateKey = /etc/ssl/private/sip-ws-server.example.org-key.pem
 +
 +
* Notice the domains in the TLS example:
 +
** clients will be configured (in [http://jscommunicator.org JSCommunicator] or whatever client you use) to connect to ''sip-ws-server.example.org''.  The server will present a TLS certificate containing the name ''sip-ws-server.example.org'' to satisfy the security expectations of the WebSocket client.
 +
** the SIP messages will simply contain the name ''example.org'' and only ''example.org'' is used in the '''RecordRouteUri''' parameter.  This is important.
 +
 
== Background ==
 
== Background ==
  
 
'''WebSockets''' is a mechanism for creating sockets from a web browser (typically running Javascript) to a server.
 
'''WebSockets''' is a mechanism for creating sockets from a web browser (typically running Javascript) to a server.
  
[https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/?include_text=1 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 [https://svn.resiprocate.org/rep/resiprocate/branches/b-webrtc branch] in reSIProcate attempting to implement this behavior.
+
[https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/?include_text=1 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.  Code for implementing this protocol was developed on a branch and has subsequently been merged into the [https://svn.resiprocate.org/rep/resiprocate/main trunk] for eventual release in reSIProcate 1.9.
  
 
'''WebRTC''' is related to WebSockets, but it is not the same thing.  WebRTC specifies a way for a browser to act as an RTC endpoint, but not specifically as a SIP endpoint.  There are SIP implementations written in Javascript that use the WebSocket transport to create WebRTC sessions, and a correctly adapted '''repro''' proxy server should be able to interact with such clients.
 
'''WebRTC''' is related to WebSockets, but it is not the same thing.  WebRTC specifies a way for a browser to act as an RTC endpoint, but not specifically as a SIP endpoint.  There are SIP implementations written in Javascript that use the WebSocket transport to create WebRTC sessions, and a correctly adapted '''repro''' proxy server should be able to interact with such clients.
 +
 +
== 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 - [http://code.google.com/p/webrtc/issues/detail?id=1425 bug tracker link]
  
 
== reSIProcate and WebRTC ==
 
== reSIProcate and WebRTC ==
Line 14: Line 53:
 
=== Current support for WebSockets ===
 
=== Current support for WebSockets ===
  
* There is a [ branch] in the repository
+
* There is support for [[SIP_Over_WebSocket_Cookies|using cookies from the browser for authentication and routing decisions]]
* There has been [http://list.resiprocate.org/archive/resiprocate-devel/msg08199.html discussion] in various threads on the [http://list.resiprocate.org/archive/resiprocate-devel/ resiprocate-devel mailing list]
+
* Using options like EnableFlowTokens or full Outbound flow tokens is essential
** and some [http://list.resiprocate.org/archive/resiprocate-devel/msg08203.html test results/observations]
+
* Available in [https://svn.resiprocate.org/rep/resiprocate/main trunk] and the upcoming [[ReSIProcate_1.9_Release|reSIProcate v1.9.0 release]], beta tarballs and packages are currently available
** Using options like EnableFlowTokens seems to be helpful
+
** Was developed on the [https://svn.resiprocate.org/rep/resiprocate/branches/b-webrtc b-webrtc feature branch]
 +
 
 +
=== Outstanding issues for a stable release ===
 +
 
 +
* audit the security and resilience of parser code (e.g. against DoS attacks), as it is likely to be exposed to the hostile environment of the public internet
 +
* WS parser must reject frames with unknown extensions (currently they are just logged)
 +
* compatibility tests
 +
** make a list of products to test against
 +
* unit tests
 +
** develop some unit tests for the new WS code
 +
* check hardcoded df7jal23ls0d.invalid
 +
* ifdef USE_SSL for WS code
 +
* checking the type of frame
 +
** handling ping/pong frames?
 +
* keep alive mechanisms
 +
** SIP CRLF keep-alive over WS
 +
* frame and WS Message size checking
 +
** allocating larger buffer if necessary when receiving a big frame
 +
** sizing the WS Message unit buffer in advance to avoid resizing issues
 +
** must insert Content-Length header if relaying a message from WS to TLS, as WS does not mandate the client includes ContentLength
 +
* dealing with [http://list.resiprocate.org/archive/resiprocate-devel/msg08207.html WS/WSS distinction in different contexts] (e.g. no WSS in a SIP URI transport parameter, see email on list)
 +
* Nice to have (not mandatory for release)
 +
** support WS connections relayed from an Apache server
 +
** SIP over WebSocket client implementation
 +
** better implementation of the WS message unit abstraction
 +
** allowing the via received parameters to be suppressed (as per SIP over WS spec) to hide network topology
  
 
== Related links ==
 
== Related links ==
Line 23: Line 87:
 
=== Javascript SIP clients for WebRTC capable browsers ===
 
=== Javascript SIP clients for WebRTC capable browsers ===
  
 +
* [http://jscommunicator.org JSCommunicator] can be easily embedded into any static HTML or CMS framework
 +
* [http://www.drucall.org DruCall WebRTC module for Drupal]
 +
* [http://www.jssip.net/ JsSIP]
 
* [http://sipml5.org/ sipML5]
 
* [http://sipml5.org/ sipML5]
* [http://www.jssip.net/ JsSIP]
 
  
 
=== WebRTC capable browsers ===
 
=== WebRTC capable browsers ===
Line 33: Line 99:
 
=== Other components ===
 
=== Other components ===
  
* The SIP client must be hosted on a web server such as Apache
+
* The SIP client must be hosted on a web server, any regular Apache instance is fine for this

Latest revision as of 11:51, 22 January 2014

Get started quickly[edit]

AssumePath = true
DisableOutbound = false
EnableFlowTokens = true
  • For local testing, you can use regular HTTP (no TLS) on any port, if you do this, it is necessary to set the record route URI to your host or domain name (not IP):
WSPort = 80
RecordRouteUri = sip:example.org
  • For production use, it is significantly more reliable to use TLS, this will ensure that the websocket connection can pass through HTTP proxy servers
Transport1Interface = 192.168.1.106:443
Transport1Type = WSS
Transport1TlsDomain = sip-ws-server.example.org
Transport1TlsClientVerification = None
Transport1RecordRouteUri = sip:example.org;transport=WS
Transport1TlsCertificate = /etc/ssl/ssl.crt/sip-ws-server.example.org-bundle.pem
Transport1TlsPrivateKey = /etc/ssl/private/sip-ws-server.example.org-key.pem
  • Notice the domains in the TLS example:
    • clients will be configured (in JSCommunicator or whatever client you use) to connect to sip-ws-server.example.org. The server will present a TLS certificate containing the name sip-ws-server.example.org to satisfy the security expectations of the WebSocket client.
    • the SIP messages will simply contain the name example.org and only example.org is used in the RecordRouteUri parameter. This is important.

Background[edit]

WebSockets is a mechanism for creating sockets from a web browser (typically running Javascript) to a server.

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. Code for implementing this protocol was developed on a branch and has subsequently been merged into the trunk for eventual release in reSIProcate 1.9.

WebRTC is related to WebSockets, but it is not the same thing. WebRTC specifies a way for a browser to act as an RTC endpoint, but not specifically as a SIP endpoint. There are SIP implementations written in Javascript that use the WebSocket transport to create WebRTC sessions, and a correctly adapted repro proxy server should be able to interact with such clients.

NAT busting: living the dream[edit]

  • 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[edit]

  • 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[edit]

Outstanding issues for a stable release[edit]

  • audit the security and resilience of parser code (e.g. against DoS attacks), as it is likely to be exposed to the hostile environment of the public internet
  • WS parser must reject frames with unknown extensions (currently they are just logged)
  • compatibility tests
    • make a list of products to test against
  • unit tests
    • develop some unit tests for the new WS code
  • check hardcoded df7jal23ls0d.invalid
  • ifdef USE_SSL for WS code
  • checking the type of frame
    • handling ping/pong frames?
  • keep alive mechanisms
    • SIP CRLF keep-alive over WS
  • frame and WS Message size checking
    • allocating larger buffer if necessary when receiving a big frame
    • sizing the WS Message unit buffer in advance to avoid resizing issues
    • must insert Content-Length header if relaying a message from WS to TLS, as WS does not mandate the client includes ContentLength
  • dealing with WS/WSS distinction in different contexts (e.g. no WSS in a SIP URI transport parameter, see email on list)
  • Nice to have (not mandatory for release)
    • support WS connections relayed from an Apache server
    • SIP over WebSocket client implementation
    • better implementation of the WS message unit abstraction
    • allowing the via received parameters to be suppressed (as per SIP over WS spec) to hide network topology

Related links[edit]

Javascript SIP clients for WebRTC capable browsers[edit]

WebRTC capable browsers[edit]

Other components[edit]

  • The SIP client must be hosted on a web server, any regular Apache instance is fine for this