sip


Last weekend I attended a session about Homer Sipcapture at Fosdem in Brussels. Homer is a software that is built in to Kamailio. In Kamailio has there are two modules that is specially adopted for use with this 3rd party Open Source software – Homer SIPcapture.  Homer was awarded a Kamailio Award last year for it’s unique innovation. With Kamailio and Homer, you can capture SIP messages from a running Kamailio production server or from a mirrored port in a switch in your network. What do you get? A searchable database of your SIP traffic and easy to understand visual diagrams of individual SIP sessions. All in a web interface powered by a database of your traffic. I installed it and after a few hours it was a critical tool in my network, helping me to solve problems.

Two components – sender and receiver

Homer has two major components. The packet sender captures traffic and forwards to a receiver. You can use Kamailio in both places, but you can also enable a sender within FreeSwitch as well as use the Homer capture sender that reads off a network interface and sends to the receiver. To use the Homer software with Kamailio, you need a database server (with capacity to handle your traffic) and a web server with PHP support. (more…)

SIPitSIPit is one part of the SIP development. IETF develops new proposed standards and additions to existing standards – but they need to be tested for interoperability. Just writing documents is not enough. We need code and we need agreements that the standards actually work and deliver interoperability to the users. One implementation following the standards should be able to interoperate fully with another implementation of the same standards. If not, we have a huge problem.

The SIP Interoperability Testbed

SIPit is organized by the SIP forum and lead by Robert Sparks, one of the engineers in the IETF. Robert has organized 29 SIPit events around the world and the next one, SIPit 30, will be hosted by Cisco Systems in Raleigh-Durham, North Carolina, USA. At SIPit we test both the base SIP standard, as documented in RFC 3261, and the new additions, like SIP Outbound, SIP identity, GRUU and ICE. We have phones, proxys, conference bridges, session border controllers and all kinds of devices as well as SIP stacks under development. We have a gentleman’s agreement not to reveal anything else than generic test results. I can’t use Facebook and say “ha ha, Saul’s new SIP server sucks!“. This leads to a very open and helpful environment. We teach each other, wants everyone to succeed and learn a lot in the process.

Here’s a presentation with a few bullet points to explain to you and your employer why you need to register now! The company will earn on it, get a better product. You will learn more. See you at SIPit!

 

RFC 3261, The Session Initiation Protocol, was published in 2002, six years after the initial work on SIP. Wikipedia writes

“SIP was originally designed by Henning Schulzrinne and Mark Handley in 1996. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IP Multimedia Subsystem (IMS) architecture for IP-based streaming multimedia services in cellular systems. The latest version of the specification is RFC 3261 from the IETF Network Working Group published in June 2002.

The SIP 2012 Realtime Communication Framework - a specification that we need!The problem here is that SIP 2.0 has changed a lot. It’s been formally updated by  a number of RFCs: 3265, 3853, 4320, 4916, 5393, 56215626, 5630, 5922, 5954, 6026, 6141 (according to tools.ietf.org). And that’s the updates that changes the core protocol. In addition, there is a lot of extensions and additions to what now could be called The SIP 2012 Realtime Communication Framework. The core protocol is now just one piece of the puzzle.

Customers need to change requirements

I’ve seen too many public tenders and requirements that refer to “SIP according to RFC 3261″. This is like buying a PC referring to Windows 95 as the base requirement for compatibility. So what should be referred to? Here’s the core of the problem. There’s no simple document or reference profile to refer to. And there is a huge gap between the IETF and the current implementations, something that we see every year at SIPit events. Only customer requirements can push vendors to move forward.

An example: The SipConnect specification from the SIP forum

The SIP Forum SIP Connect 1,1 specification is a good example of a reference profile that customers can use. It focuses on the SIP trunk – the connection between a PSTN gateway provider (ITSP) and an enterprise PBX. SIP connect makes it possible for customers not to refer to RFC 3261, but a more complete specification that builds a framework on top of the specifications. During the work with SIP connect, it was revealed that many PBXs used SIP in a way that was actually not supported by the current set of RFCs. The SIP forum took this issue back to the IETF and the result is GIN – a way to register for many E.164 phone numbers (RFC 6140). Building a reference framework with customer focus actually added to the standard framework, based on the use in the current implementations.

There are more frameworks built on SIP – IP Multimedia System (IMS) from 3gPP is another example, but not for business users or vendors selling SIP solutions to consumers. The 3gpp is active in the IETF, trying to make sure that changes and additions are documented in RFCs and made compatible with the rest of the SIP framework.

Wanted: A reference profile for SIP phones and servers

If you look at the original set of SIP RFCs, there was a lack of solutions for NAT handling. In the current SIP framework the IETF have added new standards like ICE/TURN/STUN and SIP outbound. There are also standard frameworks for configuration update notifications, registration management and TLS certificate management – something that most vendors implement in a proprietary way. We see more implementations of these additions at every SIPit test event, but most phones on the market (and most servers) are still not supporting these new standards. We need a reference profile (maybe from the SIP Forum?) that customers can refer to in order to put pressure on vendors to update their implementations.  SIP implementations that is based on more current work will lead to better products, more NAT and IPv6 friendly solutions and improved security. Standardization in configuration and security management will lead to lower costs and less vendor lock-ins.

The question is who starts the work specifying the new reference profile? 

 

In a SIP network, you often have multiple servers communicating with each other. As soon as you add TCP and TLS to the mix, you will want to reuse connections. Why? Setting up A TLS connection involves a lot of messages going back and forth in the process up validating certificates and coming up with keying material for the encrypted session. Now if you have a re-invite that wants to put a call on hold, you don’t want to loose a lot of packet-roundtrip-times while this happens. A better solution is to keep connections open where possible and allow communication both ways.

RFC 3261 states that if you open a connection with a connection-oriented protocol, like TCP or STCP, the connection should stay open to cover the whole transaction. This means that if the other end sends a message in the dialog, a connection needs to be opened in the other direction. This is of course a problem with NAT between a device and a server, something that the SIP Outbound standard handles. Between servers, like B2bua’s and proxys, the problem still exists. This is managed by the Connection Reuse RFC, RFC 5923.

Mutual TLS authentication opens up for two-way communication

RFC 5923 – SIP Connection reuse – explains how this can work. One requirement is that the TLS connection has mutual connection, which means that the server ask the client for a certificate. The client indicates in the request that it is prepared to receive inbound requests, not only the response to the request, on the same connection. When that happens, the server and client sets up a connection table where the content of the certificates are stored – the domains and host names. Now if one of them has a request that is targeted to the same domain and the same IP and port (after DNS SRV lookups), the connection can be reused.

Checking and caching the certificate content

When the connection is initiated, both ends provide TLS certificates that contain one or multiple names or SIP uri’s. This list is cached and associated with the session. Now, if the same server host multiple domains, you can’t use the connection if the domain that is the target of the request doesn’t match the names in the certificate. In that case, you need to open a new connection to the same server.

Use DNS host names instead of IP addresses

On a related topic, notice that the RFC always use host names and not IP addresses in the Via: headers. This is of course a requirement if you want to match certificates. For TLS to work in all directions, host names should be used in Via: and Record-Route/Route headers. With a GRUU, you can also have a domain in the Contact. This also helps IPv4/IPv6 dual stack handling, letting every path select the optimal connection.

Combined with SIP outbound we have open connections all the way

Connection reuse is an important feature for all SIP servers, B2BUAs like Asterisk and SIP servers like Kamailio. Without it TLS will be hard to use and cause delays that will affect the calls. In combination with SIP Outbound, where the UA manages the connections to the first-hop servers, it is a working solution for TLS over NAT as well. Keeping TCP/TLS connections open like this is not new, Jabber/XMPP has done this from start. It’s just new to SIP.

I think SIP Connection Reuse support should be on the list of requirements when you select your next SIP application server for your Open Unifed Communication platform.

Lately, I’ve been going through a lot of SIP RFCs and drafts, trying to get an overview of the security suggested in all of these documents. The quality of this work, seen from a developer’s perspective, is quite poor. Sometimes it seems like authors think, “oh, we need to add that security stuff, so let’s add a few keywords like TLS and S/MIME here and there“. We need to get better in reviewing the drafts from a security perspective. Here are  some thoughts on instructions to RFC authors:

  • S/MIME: If you refer to S/MIME, make it very clear which certificates that are going to be used and how the certificate verification process should happen – which part of the SIP message should match with which part of the certificate? And which certificate should be used to encrypt?
  • TLS: If you refer to TLS, you need to be very clear on why – is this to provide authentication, confidentiality or something else? Does the solution require mutual authentication or just server authentication? If authentication is part of your solution, make it very clear how you verify the certificate with the message, down to SIP header fields and X.509v3/PKIX fields.
  • SIPS: If you suggest usage of SIPS, make it very clear on what this adds and how the message flow is supposed to look like. Is SIPS used in the request uri, the Contact or somewhere else? What is the effect? Make sure you really understand SIPS before this is added. Or even better, just avoid SIPS and let it fade away.
  • Certificate matching: If you refer to a certificate SubjAltName, make very clear if it’s a URI or a dnsName field that is required and preferences if there are multiple SubjAltNames in addition to the certificate subject.
The worst documenst so far are the RFCs related to SIP subscriptions. They suggest using S/MIME for encryption, but does not explain how. Now, if I subscribe to the presence status of sip:bob@example.com, my SUBSCRIBE request will end up at the presence server for the domain example.com. Should the user agent somehow find the certificate for sip:example.com to encrypt the message? Should we use the certificate of sip:bob@example.com – which would require the presence server to have the private key belonging to Bob? The RFCs doesn’t help at all.
RFC 3857 states the following on the topic of eavesdropping on SUBSCRIBE/NOTIFY requests:

“To prevent that, watchers MAY use the sips URI scheme when subscribing to a watcherinfo resource.  Notifiers for watcherinfo MUST support TLS and sips as if they were a proxy (see Section 26.3.1 of RFC 3261).”

This means that a UA should be able to SUBSCRIBE over a TLS connection, and get NOTIFY over – what? Remember that this was written before SIP Outbound was standardized. For a developer this means that the subscriber is required to have a TLS certificate and accept incoming connections on the TLS port if the Contact in the SUBSCRIBE is a SIPS uri. The RFC should discuss this in more detail.

Nine years after RFC 3261 we have a larger toolbox, including GRUUs, SIP Outbound, SIP Domain certificates, DNSsec and much more. It’s time we restart the work with a SIP security architecture and provide something that developers can implement and that users will clearly feel is a better and more trustworthy solution. The IETF mantra is “rough consensus and running code”. RFCs should make it easy to produce running code. The SIP RFCs fails do this on the topic of SIP security.

/Olle

 

 

 

I’m currently swimming through the deep waters of SIP RFCs in order to get an overview of TLS implementation requirements. Reading RFC 3428 – The SIP Message Extension- I found something I did not know. In section 11, Security Considerations, the RFC states:

In normal usage, most SIP requests are used to setup and modify communication sessions. The actual communication between participants happens in the media sessions, not in the SIP requests themselves. The MESSAGE method changes this assumption; MESSAGE requests normally carry the actual communication between participants as payload. This implies that MESSAGE requests have a greater need for security than most other SIP requests. In particular, UAs that support the MESSAGE request MUST implement end-to-end authentication, body integrity, and body confidentiality mechanisms.

I have seen quite a few implementations of MESSAGE, but none has been compliant with RFC 3428.

The SIP MESSAGE implements a way to send short messages over SIP, within a dialog or outside of a dialog. MESSAGE requests does not create dialog, thus there’s no “session”. For chat sessions that , MSRP – the message session relay protocol – was developed. I’ll try to write more about that protocol in another blog post.

Last week I talked at the Voip2Day conference in Madrid, organized by Avanzada7. The talk, named “Watch out!” covers new areas developed in SIP, but not implemented in many devices or servers out there. Solutions for NAT traversal, PSTN trunk registration and new work with the real time web is covered, along with a small update to the list of 10 bullets to remember when implementing a new SIP platform.

Some topics covered:

  • ICE, Interactive Connection Establishment, a complex but working solution to find a working media path between two Sip phones, either directly or using a media relay (A TURN server). Used both for NAT traversal and IPv4/IPv6 dual stack deployments.
  • SIP Outbound, the way to handle NAT traversal for SIP signaling. With SIP outbound, the client sets up multiple IP connections, called flows, to servers while indicating that it’s actually the same device that registers on all these connections. The proxy can then do failover if one connection fails. It’s up to the SIP phone, the user agent, to maintain the connections and re-open them when they fail.
  • GIN – the way SIPconnect sends a registration for a SIP trunk with multiple phone numbers. Before GIN, every vendor used it’s very own hack which raised the cost for service providers that wanted to support multiple vendors.
  • GRUU – Globally Routable User URI’s – a domain-based address for every device that registers for an account. Makes it possible to do more complex operations over domain boundaries. Without a GRUU, many URI’s are unusable since they’re referring to an IP address hidden behind a NAT device.
I feel that ICE and SIP outbound are good candidates on solving the NAT puzzle as well as the IPv6 transition. We need more Open Source implementations as a reference!
The presentation also covers RTCweb briefly. On the conference, there was a live demonstration by Iñaki Bas Castillo and a colleague of a SIP implementation in JavaScript connecting over WebSockets to a SIP proxy. They lacked RTCweb so there was no media in the calls, but it showed that it’s possible to implement SIP in the browser!

The talk is now published on Slideshare and can be viewed online. Enjoy!

/Olle

Realtime communication in web browsersVideo sessions in the browser opens up for a lot of new applications. While this has been working with various plugins, new opportunities will open up when it becomes part of your standard web browser. HTML5 introduced native video in the browser. New standardization are looking into peer2peer multimedia sessions in the browser, not just broadcast. This opens up for a large set of applications, from “click2call” without plugins to video chats like in Facebook and Google+. This is exciting. And all the old SIP architects seems to have jumped onto this project, trying to get things right from start in this second generation effort. (more…)

The benefit of open standards is that it put the customers in control. They can use any SIP-compatible phone with any SIP-compatible server. We can place calls between companies. We can freely choose a SIP PSTN-gateway service provider. There are no vendor lock-ins.

To reach this, a lot of work is needed. A lot of testing, code changes, discussions between developers and regular meetings as standards evolve. The SIP Forum, an organization for vendors that sell SIP based services or products, organizes SIPit events where developers meet to run tests, discuss standards and improve their products. The winners here are the customers. A result of SIPit is better interoperability between products, something that expands the market and makes it easier to integrate solutions from different vendors.

As a customer, please ask your vendor if they send teams to SIPit. That’s enough. There are no formal tests involved, no official test results that you can ask for. Participation means that a vendor is interested in interoperability, which is good for you.

Registration for the next SIPit in Monte Carlo, Monaco, is now open. It’s hosted by ETSI, an European Union standardization organization. If you develop SIP products – make sure you register now!

Imagine working at your desk, getting a phone call from your friend Randy. You answer on your IP phone. Being Randy, he suddenly wants to play a new jingle he created while being in the mood the day before. The phone speaker is not a good device for a cool guitar riff – is it? On the same desk you have your PC with a softphone that supports HD voice and really cool loudspeakers. Why not transfer the audio to the PC while still using the phone’s microphone? After that, you want to play a video for Randy. Now you want to add media from your laptop to the call – while the call is still managed by the IP phone.

This is a true multimedia session, that is not that far away. But it’s too complex to manage in the SIP protocol today. I just found out about the SPLICES working group in the IETF that is working on this issue. I also know that the Asterisk development team is working on a new media architecture - something we’ve needed for many years. My presentation about the new media architecture from Astridevcon 3 years ago talks about being able to add streams, have multiple streams of the same kind and remove streams dynamically during a call. SPLICES, when finished, will help us implement it in a really cool way in SIP.

Another mailing list to follow.

Do you know another thing? Randy and I wouldn’t be able to have this call as easily if we did not use SIP over IPv6. Doing a call like the one above over two NATs would be awfully complex…

Next Page »