SIP User ID vs. Auth ID

When you are configuring a SIP device, setting the Auth ID to the same value as the SIP User ID will always make for an easier life. If you set them to different values, it is much more likely you will have problems with registration.

For a typical Internet Telephony Service Providers (ITSP), handling unmatched SIP User ID's and Auth ID's is surprisingly tricky. For this reason, they generally instruct users to set the same value for both fields.

While this keeps things simple in some respects, it can be an unwelcome and inconvenient restriction: Firstly, on simple SIP devices the Caller ID for outbound calls is generally taken from the 'SIP User ID', so being obliged to always match the account's 'Auth ID' would take away your flexibility to change the Caller ID. Furthermore, it can be quite convenient sometimes to be able to use a single "User ID-password" pair for several different SIP devices or for all the lines on a multi-line analogue adaptor. Finally, it could be argued that a SIP account that has the same value for the SIP User ID and the Auth ID is not as secure as one where the ID's are different.

My most recent online article discusses this topic in much more detail. It tries to look at the problem from the point of view of the Service Provider, especially using OpenSIPS as their main portal or SIP Proxy. Please follow the link and read the whole article:
http://kb.smartvox.co.uk/opensips/sip-user-credentials-itsp/

OpenSIPS vs Asterisk

In my previous post, I explained how I had written an online article reviewing what OpenSIPS is and what it does. For some reason, no matter how hard you try to avoid it, the question always comes up about how OpenSIPS differs from Asterisk. I got half way through my review of OpenSIPS and realised that this question could not be ignored. However, I always tend to write a lot and I didn't want the article to get even bigger so I decided to push the whole question off into a new post dedicated just to that one question - the difference between OpenSIPS and Asterisk.

Asterisk and OpenSIPS are undoubtedly two of the biggest beasts in the jungle of open source VoIP server applications so, if you want to get a better understanding of how they compare, just click here.

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.