Securing the Association of the DTLS Certificate With the User’s SIP-URI


imagesThe SIP protocol can be used to establish SRTP security using DTLS protocol. The DTLS extension ([RFC 5764]) is used. It describes a mechanism to transport a fingerprint attribute in SDP. So the fingerprint of the self-signed certificate can be inserted by the user agent (UA) in the SDP and sent over SIP to the proxy over an integrity protected channel (carried over TLS transport protocol). The fingerprint in the SDP looks like this:

a=fingerprint:sha-1 99:41:49:83:4a:97:0e:1f:ef:6d:f7:c9:c7:70:9d:1f:66:79:a8:07

Then after the user has been authenticated, the proxy generates a hash where the certificate’s fingerprint and SIP user ID are among others included in the calculation. The proxy signs the hash using its private key and inserts the signature in a new header field in the SIP message (the Identity header field). This secure the association between the DTLS certificate and the user’s SIP URI. The Identity-Info header field helps the verifier (the receiver of the SIP/SDP message) in the verification of the signature included in the Identity header field.

The certificates are being used as a carriers for the public keys and used to authenticate the counterpart and negotiate the session keys (symmetric keys). Then the session keys are used by SRTP to encrypt/decrypt the media. The offerer sends its fingerprint in the request and the answerer sends its fingerprint in the corresponding response after accepting the offer.

Using SIP Identity and Identity-Info

The solution as i mentioned above is using the SIP Identity ([RFC 4474]) to sign the binding of the fingerprint to the user. This is done by the proxy responsible for that user. The proxy is the holder of the private key of its domain. After the user is successfully authenticated, it is authorized to claim the identity (AOR of the user). The proxy creates the signature of the hash using its private key and inserts it in Identity header field. The proxy also inserts the place where the verifier can acquire the proxy’s certificate (public key) using the Identity-Info header field.


Identity: CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja9k

Note the part “/cert” in the Identity-Info URL which addresses a certificate.

The Hash Generation

The signature of the hash is added as an Identity header field in the SIP message. The calculation of the hash must contain mainly the AOR of the user and the fingerprint included in the SDP in the body of the message.  According to RFC [4474], the signature/hash is generated from certain components of SIP message, among others:

  • The AoR of the UA sending the message (or addr-spec of the From header field)
  •  The addr-spec component of the Contact header field value.
  • The whole SDP body (the fingerprint is here)
  • …….

Fingerprint Verification

Using the header Identity-Info, the user agent verifies that the fingerprint of the certificate received over the DTLS handshake matches the fingerprint received in the SDP of SIP request/response.



WebSocket as a Transport for SIP


Here I just want to write a few words that summarize the RFC 7118:


  • The WebSocket protocol enables message exchange between clients and servers on top of a persistent TCP connection

  • The connection is optionally secured with TLS

  • The WebSocket handshake is based on HTTP and uses the HTTP GET method with an Upgrade request → HTTP 101 response on success .

  • During the connection handshake, the client and server agree on the application-level protocol on top of Websocket transport (Websocket subprotocol) -In this document it is SIP

  • Websocket messages can be sent in either UTF-8 text frames or binary frames. SIP allows both. UTF-8 is recommended for Javascript and WebSocket API

  • Each SIP message must be carried in a single WebSocket message and the WebSocket message contains only one SIP message → simplifies the SIP message parsing – no need for message boundaries (Content-Length header)

  • “ws” is used for plain websocket connections and “wss” for secure Websocket connections. These are for “via” transport parameter and SIP URI transport parameter

  • The SIP WebSocket server may decide not to add the parameter “received” in the top via header. The Client must accept the responses without this parameter

  • The SIP webSocket client is not manadated to implement support of UDP and TCP.

  • “SIP+D2W” DNS NAPTR service value for plain Websocket connections and “SIPS+D2W” for secure websocket connections.

  • The authentication can be on SIP level or Web level (token/cookie is used) – Appendix A

  • Using GRUU is valuable here (must be implemented on the client and server)

  • The Contact URI provided by SIP UAs is not used for routing requests to those UAs.

  • When SIP WebSocket server behaves as edge outbound proxy (Outbound + Path support), the proxy performs loose routing and remains in the path.

More Information

First Step In WebRTC



Here i will show you how to execute very simple WebRTC demo served by Apache web server . The example is how to get the media stream of the local device. I will take as an example the WebRTC “getUserMedia” example from the book “Real-Time Communication with WebRTC by Salvatore Loreto and Simon Pietro(O’Reilly)”. You can find the source code on the book’s GitHub page. Follow these steps:

  • Create a folder for your WebRTC project: # mkdir /var/www/html/webrtc
  • Create subdirector for Javascript files: # mkdir /var/www/html/webrtc/js
  • Open Apache configuration file “/etc/httpd/conf/httpd.conf” and add this line:

Alias  /webc  /var/www/html/webrtc

    Restart Apache: # systemctl restart httpd.service

Screenshot from 2015-03-08 20:20:28To debug your project, open the browser console (e.g. Chrome: More tools –> Javascript Console).

JSFIDDLE Framework

You can use jsfiddle framework to write, save, validate, and run your application online.


  • Update your browser (bug fixes). Using the developer edition is a good choice (e.g. Firefox Developer Edition).
  • Test your application on different browsers