When we teach classes on VoIP networks, we discuss the variety of SIP standards that can be used by working systems. For example, identifying the calling party varies between platforms: One system uses P-Asserted-Identity to indicate the caller, and another uses From. Then there's the codec used for audio: One system uses G.722 and another uses G.722.2. One system expects national telephone numbers, and another system expects international-formatted numbers. The list goes on.
When setup two SIP systems to exchange phone calls, you need to be aware of the issues. If you're lucky, the two systems have a lot in common. If you're not, you may have a lot to fix.
1. Establish format for local telephone numbers.
Not always required.
2. Establish format for national telephone numbers.
E.164 With Plus is recommended, e.g., +12292442099
3. Establish format for international telephone numbers.
E.164 With Plus is recommended, e.g., +12292442099
4. Determine which short codes are supported, such as emergency codes 911, 111, and 0
5. Determine what control codes are supported, such as *67
One of the most common questions for SIP interop is how the called telephone number will be formatted. There are several popular formats, and they occur in the Request-URI (after the "INVITE") and in the To header.
This article is intended to familiarize you with many of the common options. The software you're using -- BroadWorks, Metaswitch, Asterisk, Sonus, Genband, etc. -- will have certain capabilities and defaults. If you can find a way to interop end-to-end between the two call-control servers, without having to rewrite the number in an Session Border Controller in the middle, then you prevent substantial hassle.
Perhaps the most common format is the complete national number. For example, in the United States, you might see this complete national number: 9193160013.
INVITE sip:9193160013@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:9193160013@vwave.net;user=phone>
When the SIP invite represents the digits a user actually dialed on his keypad, the local number will be most common.
INVITE sip:3160013@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:3160013@vwave.net;user=phone>
Within the UK, you might call a London number by dialing eight digits:
INVITE sip:74931232@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "UK User 1" <sip:07981555555@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:442074931232@vwave.net;user=phone>
When a human is dialing the number to place a call across the PSTN, the receiving system (INVITE User Agent Server, UAS) will need to determine the intended PSTN telephone number. One popular method is to apply the local area code of the calling party. For example, if this call is dialed by user "u2292442099", and their US area code is "229", then the UAS may reasonably interpret the dialed digits 3160013 as +1-229-316-0013 by prepending the national and area code to the dialed digits.
This is a very awkward format to support between carriers or systems, and quite impractical if multiple local areas are involved.
In PBX-like environments, "extensions" can be dialed. An extension is a locally-defined telephone number, but which is not useable routing between carriers. You can expect to only see this when the INVITE Request URI represents digits that a user is dialing personally.
INVITE sip:2207@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:2207@vwave.net;user=phone>
The extension 2207 probably only makes sense in the group owned by "u2292442099". The UAS for "vwave.net" has to know what 2207 means in that context.
This model places the call with a leading country code. In the North American Numbering Plan (US, Canada, Caribbean),
INVITE sip:19193160013@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:19193160013@vwave.net;user=phone>
INVITE sip:442074931232@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:442074931232@vwave.net;user=phone>
Preferred: I recommend this format whenever possible, because it's the only one with a token that signals the type of number it is: the leading Plus. By including the Plus before the number, all parties involve understand that the next digits will be the country code, followed by the national and local number.
INVITE sip:+19193160013@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:19193160013@vwave.net;user=phone>
INVITE sip:+442074931232@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:442074931232@vwave.net;user=phone>
While it's easy to say this is preferred, it's not the right fit for most cases where an ordinary human is dialing the call. Most keypads don't have an obvious + dialing symbol, and users conventionally dial a shorter number.
Zounds, it's Historical! Dating from around 1950, when "The subscriber, having dialed the first steering digits, then dials the ordinary number of the distant subscriber and the call is completed without any operator intervening." his method prepends digits to the actual telephone number to mean certain things; for example "99911" prepended to the telephone number may mean to use Long Distance Gateway 1, and "99912" indicates to use Long Distance Gateway 2.
INVITE sip:999119193160013@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:19193160013@vwave.net;user=phone>
Despite the vintage charm, this method is worth avoiding when possible. There are several good alternatives in SIP:
INVITE sip:+19193160013;tgrp=TG-1@vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:+19193160013@vwave.net;user=phone>
INVITE sip:+19193160013@192.168.42.2;dtg=1:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:+19193160013@192.168.42.2;dtg=1;user=phone>
INVITE sip:+19193160013@tg-1.vwave.net:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:u2292442099@vwave.net>;tag=90C2A5B1-AAFDEC86 To: <sip:+19193160013@tg-1.vwave.net;user=phone>
In non-PSTN environments, you can see calls placed to non-numeric identities.
INVITE sip:alice@atlanta.com:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:bob@biloxi.com>;tag=90C2A5B1-AAFDEC86 To: <sip:alice@atlanta.com>
The SIP URI "sip:alice@atlanta.com" makes sense within the SIP network, but has no direct mapping to the E.164-dominated telephone network. This is essentially equivalent to dialing by extension.
Don't be misled by usernames that appear to be a number, such as this:
INVITE sip:ext.6100@26.128.128.1:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.43:5060;branch=z9hG4bK6ae0c87576E0FF92 From: "u2292442099" <sip:bob@biloxi.com>;tag=90C2A5B1-AAFDEC86 To: <sip:ext.6100@26.128.128.1>
The "ext.6100" in this example makes it incompatible with a telephone number; there's no automatic mapping between ext.6100 and a telephone number. This is intended to route a call to the user known to the UAS with the username "ext.6100".
The examples I've shown mostly include "user=phone". This represents that the user portion of the URI (to the left of the @ sign) is to be interpreted as a telephone number. These can be readily rewritten as "tel:" URIs, as described in RFC3966.