All about OpenSIPS

The work that I do has taken a number of twists and turns over the 7 years since I first started as a freelance IT and VoIP consultant. Allowing oneself to be persuaded towards meeting the most prominent demands of potential customers is a 'no brainer' if you want to keep your financial head above water. Consequently, my skills and experience have been inexorably pushed towards open source solutions running on Linux servers - initially Asterisk, but also from an early date, OpenSIPS. (By the way, I plan to add FreeSWITCH to the list very soon).

When I first looked at OpenSIPS in 2006, it was called SER or SIP Express Router. The documentation was not great, but I found a good tutorial that guided you through the configuration step-by-step, adding more and more capabilities until you ended up with quite a useful application for routing SIP-based calls between IP phones and carriers with pretty good NAT traversal capabilities. Unlike Asterisk, it had a vast capacity for handling simultaneous calls and was so robust that it would run uninterrupted for months without even a hint of a problem. By contrast, we had to re-start our v1.2 Asterisk servers every night to prevent random crashes caused by memory leaks. They eventually fixed this in v1.6.

I have remained a loyal devotee of OpenSIPS through its various re-incarnations (SER to OpenSER to Kamailio and OpenSIPS). My knowledge and experience of the product has increased over the years and the documentation available online and in printed form has gradually improved. The developers have done a fantastic job adding new modules, new features and functions while maintaining the original ethos of reliability, conformance to published standards and performance. It is not a replacement for Asterisk - the two products are not designed to do the same job and in many cases the best ITSP solutions require both.

In the last 1 to 2 years, demand for support and advice about setting up OpenSIPS has mushroomed, especially from innovative businesses and small-to-medium-sized ITSP's in the USA and Canada. This convinced me to promote consultancy services for OpenSIPS as a major part of our ongoing business strategy. The final results of this push are now complete - it involved creating a new web site focussing exclusively on OpenSIPS consultancy services; registering a service-specific domain name for the site; using Google's adwords - linked to appropriate key words and phrases - to attract visitors to the site; creation of documentation suitable for downloading from the site; and finally the creation of some online articles, the first of which was completed earlier this week.

So please take a look and see what you think. The service-specific web site (and document download link) can be reached using this link:   http://www.open-sip-solutions.com

The new online article which explains what OpenSIPS is and what it can do is here:

http://kb.smartvox.co.uk/opensips/opensips-explained/

Feedback or enquiries are very welcome. E-mail to:  info(at)smartvox.co.uk

Or use the web-based enquiry form here:

http://open-sip-solutions.com/contact-us/

QoS for VoIP - How it works and when does it make a difference

Installers of VoIP (Voice over IP) often stress the importance of having QoS for the network. On a so-called 'experts' forum, I have even seen QoS put forward as the solution to one-way audio problems, even though it is of little or no relevance to such problems. QoS is undoubtedly a powerful and useful tool for VoIP engineers and can make a great difference in the right circumstances, but on the other hand is likely to make no difference at all to the handling of IP packets sent out to the Internet on a standard small-business broadband connection.

Want to know how QoS works in practice and understand where it makes a difference and how? Then read my article on the Smartvox Knowledgebase:
http://kb.smartvox.co.uk/index.php/ip-network-design/voip-qos-network-congestion/

Why does NAT cause such a problem for SIP?

This question comes up time and again. Finding this week that I needed to brief a network consultant about the problems of SIP and NAT, it seemed like a good idea to write my summary here as a new blog article.

Why is NAT such a big deal for SIP communications:

1. Although one SIP device is nominally the client device and another is nominally the server, all SIP end-points may need to act as a server or client at certain points in the dialogue – for example, the client device may initiate a call, but the server may end it.
2. SIP requests may be relayed through a series of SIP Proxy servers (similar to email being relayed by SMTP servers)
3. If Proxy servers want to be kept in the signalling path, they add a special “Record-Route” header containing their own address. They must respect any existing Record-Route headers.
4. SIP requests always contain a “Request URI address” which describes the ultimate destination, but SIP devices and SIP Proxies may relay the request to an intermediate address which they know will relay it to the final destination.
5. SIP requests contain IP addresses embedded in various headers and also in the SDP payload – see below for details
6. The media path may not be the same as the SIP signalling path. The end points for the media are given in the SDP payload. The idea is that the media path needs to be as direct as possible, but the SIP signalling is less susceptible to latency so it is acceptable for it to go via a more convoluted path (e.g. via a billing server)
7. SIP requests contain a Via header to tell the destination which IP address (and port) to send their replies. The source device that constructs the SIP request may not be aware of NAT traversal further downstream so is likely to specify its own local IP in the Via. To alleviate this known problem, many SIP devices have features (e.g. STUN) to allow them to examine their own networking environment and determine if they are behind NAT. It is also quite common to be able to manually program the device with an “external” IP address.
8. The port specified in the Via address does not have to be the same as the port that the request was sent from.
9. SIP requests contain a Contact header which specifies the address where the sending device can be reached by the remote end-point when the remote end-point wants to initiate a new request (as opposed to responding to the existing request, which is handled by the Via)

If you want some further reading on this topic, please take a look at the following articles on the Smartvox knowledgebase:

http://kb.smartvox.co.uk/voip-sip/sip-nat-problem/

http://kb.smartvox.co.uk/voip-sip/sip-devices-nat/

VoIP QoS Settings

If you're confused by the QoS settings on VoIP equipment or just want to know what value you should assign to the DiffServ/TOS field on a Linksys IP phone, then you need to read the 2-part article on the Smartvox Knowledgebase:

VoIP QoS Settings - Part 1: Overview and Layer 2 settings

VoIP QoS Settings - part 2: Layer 3 settings, DSCP/TOS

Protecting Asterisk from Toll Fraud

Toll fraud on poorly protected Asterisk servers seems to have mushroomed in the last 12 months. I constantly see evidence of scanning and brute force password guessing attempts on port 5060 of many different servers and PBX's.

If you operate a Trixbox or any Asterisk based PBX then you urgently need to review how secure it is and make sure you have not left any gaps in your defences. Failure to do so could leave you with an astronomical phone bill and very little, if any, redress.

Learn about the vulnerabilities and how to protect your Asterisk based PBX by reading my three part article:

How secure is your Asterisk PBX? Part 1
How secure is your Asterisk PBX? Part 2
How secure is your Asterisk PBX? Part 3

If you find the articles useful, please pass the link on.

Caller ID in SIP and Asterisk - Part 2

Caller ID, ANI, PAI, RPI, Privacy - what Asterisk does

We're moving! Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at: http://kb.smartvox.co.uk/. To read the latest revision of this article on Caller ID in SIP and Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-2

I didn't plan on writing a "Part 2" to this article, but since nobody has posted any answers to my questions in Part 1, I had no option other than to test it for myself. In some ways, the answers are quite simple, but there are some subtle details that are not at all intuitive.

P-Asserted-Identity
First, what does Asterisk do when it receives a P-Asserted-Identity header. The answer is an unqualified nothing! As far as I could ascertain, it ignores it totally no matter what settings you use for "trustrpid" or "sendrpid". It does not copy it from an inbound call leg to an outbound call leg for a bridged SIP-to-SIP call.

Remote-Party-ID
Next, what about the Remote-Party-ID header? Well, if you have set "sendrpid=yes" in the settings for the destination peer in sip.conf then Asterisk will always add an RPI header. Here is a typical example:

Remote-Party-ID: "Johns Linksys" <sip:1001@192.168.1.15>;privacy=off;screen=no

The name "Johns Linksys" and the number, 1001, were taken from the From header of the inbound call leg. The IP address 192.168.1.15 is the IP of the Asterisk server, but can be over-ridden using the "fromdomain" parameter in the definition of the destination peer in sip.conf.

If you set "trustrpid=yes" in the definition of the source peer in sip.conf, then Asterisk will use the number from the RPI header in the request it received on the inbound call leg.

Privacy
Asterisk respects the privacy setting in the RPI header it receives (if there is an RPI header in the request) irrespective of any setting for "trustrpid". However, I have not found a way to tell Asterisk to change the privacy setting for a call it is bridging. Asterisk ignores the PAI Privacy header if the inbound call leg includes one.
<1001@192.168.1.15>

Caller ID in SIP and Asterisk - Part 1

Caller ID, ANI, PAI, RPI, Privacy - can Asterisk cope?

We're moving! Blogspot has been a great way to start blogging, but it has limitations. We've just completed a brand new annex to the smartvox web site called the Smartvox Knowledgebase - it is a combined blog plus a complete archive of all the blogs and VoIP articles I've written in the last few years. Please visit the new Smartvox Knowledgebase at: http://kb.smartvox.co.uk/. To read the latest revision of this article on Caller ID in SIP and Asterisk at the new site, follow this link: http://kb.smartvox.co.uk/asterisk/how-it-works/caller-id-in-sip-and-asterisk-part-1

Equipment receiving calls, whether a humble handset or a sophisticated Call centre ACD system, likes to know the identity of the caller. It may simply display the caller's number on an LCD display, look it up in a directory so the caller's name can be displayed or pre-populate a screen with information about the caller recovered from a database. However, the network also needs to know the caller's identity because it may be important for billing or to notify the emergency services of the caller's location.

In the UK, a caller may choose to block their ID so it is not visible to the called party by prefixing the dialed number with 141. However, this must not interfere with the more serious network requirements like billing or 999 call location. To accommodate both requirements, telephony signalling protocols tend to use two different pieces of data - a display ID that can optionally be blocked and an asserted ID or ANI that cannot. Protocols such as ISDN also include single bit privacy flags that show if the ID should be hidden.

The SIP protocol also has elements that allow for all the caller ID requirements. The From header provides basic caller ID data but it is too easily modified, blocked or spoofed to be of use to the network. Alongside this, the SIP protocol was extended to support the use of the Remote-Party-Id (RPI) header which should be added to an Invite by the first server within the trusted network cloud. It is described in an IETF memo:
http://tools.ietf.org/id/draft-ietf-sip-privacy-04.txt

The RPI header is added by one of the network servers so it should provide a much more reliable and trustworthy identification than the From header which can be set by users at the client device. The IETF memo also makes provision for the inclusion of certain tag values on the RPI header: "privacy" indicates to what extent the ID should be hidden and "screen" indicates what level of trust the network associates with the Remote-Party-ID information.

Another approach is described in RFC 3325. It explains the requirements for provision of an authenticated caller ID within a trusted network using the P-Asserted-Identity (PAI) header to convey the authenticated identity of a caller along with a separate Privacy header to show if this data must be hidden.

Decisions about adding or removing these ID headers depend partly on whether the call is entering or leaving your own infrastructure cloud and whether the remote peer or UA is trusted or not. If necessary, servers must use authentication challenges to ensure that a remote device can be trusted and only then should they add a P-Asserted-Identity header. When a request is sent to an untrusted device, it is necessary first to delete any such headers.

What control is provided within Asterisk?
Regrettably, all I have here are questions. Lots of questions and very few answers. Lets start with some basic facts about the configuration settings available in sip.conf:

Asterisk has two parameters for controlling handling of Remote-Party-Id as follows:
sendrpid=yes¦no : If an RPI header should be sent to the peer
trustrpid=yes¦no : If the RPI from this peer can be trusted

However, I am not sure what these parameters mean in practice. For example, will Asterisk automatically add an RPI header when sendrpid is set to "yes" or will it remove the header when set to "no". When I get time I will do some testing to see how it actually behaves.

To see the results of my testing, take a look at Part 2.

How does Asterisk handle caller ID when bridging calls from SIP to ISDN? For example, does it automatically populate the ANI and other caller ID fields using data sent in the RPI and From headers? If so, does this behaviour depend on the setting of trustrpid?

Areas where Asterisk seems to be very weak include:
1. The handling of P-Asserted-Identity. The only control I am aware of is the ability to add a PAI header (and a Privacy header) using the SIPAddHeader() function. Why doesn't Asterisk have a SIPDeleteHeader() function?
2. Access to the Privacy settings of ISDN calls. You can see the setting using the pri debug command at the CLI, but there seems to be no way of accessing the data within the dial plan.