There seems to be a fair bit of confusion over URIs in SIP, specifically in the area of representing telephone numbers and dial strings.
Before continuing, it's worth spending a few moments considering what a telephone number really is - or perhaps what it represents.
Let's assume my telephone number on the PSTN is +442079460000. The PSTN uses a numbering plan called E.164 which defines the structure of the numbers, including country codes.
In addition to the global E.164 numbering plan, there are a few other types. When you plus your PSTN phone into the socket on the wall, it is going to have a numbering plan. this varies from country to country, and also even from provider to provider in some countries.
As i'm (mostly) English, i'll use the UK numbering plan as the example here, although the country in question is irrelevant really for this discussion.
The UK numbering plan
Note that a lot of the old school bell heads won't agree with some of the following section - and isn't necessarily how other people would approach the same subject - as it's very IP/globally oriented. The telecommunications world is changing (much to the dismay of carriers that employ the very same bell heads), and with it the concepts of terms previously used in other ways in the PSTN world. For example, NANP uses the terms "Numbering Plan", despite the fact from what I can see it's both a numbering plan and a dial plan using my definitions of the terms explained below. Suggestions for better names on a postcard totheo@crazygreek.co.uk please!
UK phone numbers are split up into groups. For this discussion we only need to differentiate between these categories:
- Geographic (01, 02)
- Non-Geographic (03), VoIP & Corporate (05), Mobile & Personal Numbering (07), Freephone and Special Rate (08), and Premium Rate (09)
- Operator Services (short code starting with 1 - e.g 100 for operator, 123 for speaking clock, 1471 for call return, etc)
- Directory Enquiries (118xxx)
- Emergency Services (999 and 112)
An important differentiation between the first two categories and the others is that the first two are part of the E.164 numbering plan, and thus the UK number 02079460000 is also part of the E.164 dialplan, as +442079460000, as +44 is the country code assigned to the UK.
All of the other categories are not part of the E.164 numbering plan, but can be reached from any UK phone line - so this is where dial plans come in. A dial plan and a numbering plan are 2 different things in my world. A numbering plan specifies how numbers are allocated (e.g, the UK numbering plan), and a dialling plan specifies what an end user actually dials on a phone to get to a number. A phone (as a logical concept) has a dial plan associated with it.
The third category of numbers, Operator Services are unique to an operator. If i dial 123 on my land line phone provided by BT, it's not the same thing as calling 123 on my mobile phone provided by Vodafone, as Operator Service numbers are unique to the operator.
In the UK, our directory enquiry services are available on 118xxx, and is indeed part of the UK numbering plan. Dialling 118500 will get you through to BT's directory enquiry service if you're on a BT provided phone line or a Vodafone one. However, again, they're not part of the E.164 numbering plan.
To consider why this is the case, think about this: 02079460000 is +442079460000 in the E.164 numbering plan. To call it from any phone in the UK, you could dial02079460000. Using a phone in America, you'd dial 011442079460000, as '011' is the dial string used in America to indicate what follows is an E.164 number (minus the '+').
But if I wanted to dial BT's directory enquiries (reachable on 118500 from a UK phone), what would I dial in America? 01144118500? - no! that's 0118500, an invalid number in the UK 01 numbering plan (specifically, 0118 is Reading, a rather boring town which wouldn't really bother me if you couldn't call it, but i'm sure people living there might complain :-)).
Now, in the UK we also have 2 network features: 141 and 1470. Prefixing any call with 141 will cause your number to be withheld, and prefixing with 1470 will cause it to be released (assuming your default is to withhold you number). Both of these are dial plan features, as opposed to be any part of the numbering plan.
Back To SIP
Because SIP is an IP protocol and can (and often does) run over the Internet, it doesn't have the same physical properties the PSTN does. A phone call can be made using SIP from my laptop, and then the next day using the same SIP account from somewhere in America.
So, when I dial a number into my SIP phone, what should the phone do with that number, and how does it indicate to the SIP service provider it's sending the call to?
Following the End-To-End principle that we all hold so dear to SIP (cough, splutter), the idea as that a SIP phone should be configured with a dialling plan, that takes the input the user has dialled, and converts it into something that the service provider knows what to do with, without any configuration on it's part.
However, how the URI is then represented in a SIP request URI is where confusion arises.
Firstly, let's assume we're talking about the PSTN here, and calling numbers on the PSTN.
The tel / user=phone approach
A SIP device can often be configured with a dial plan (also known as a digitmap). One of the reasons for this is to allow a SIP device to dial as soon as a number has been entered, rather than needing to wait for a user to press the "dial" button to place the call. It also allows a user to configure how it translated the number dialled into a number within a given numbering plan.
The dial plan configured on the phone can then modify the input string dialled by the user, and convert it into a telephone number that is globally unique. There is a URI scheme defined by the IETF (RFC 2806) to indicate a telephone number, "tel". In it's most simple form, a tel URI contains just an E.164 number. So, if I dial 02079460000 on my phone, the dial plan configured on it would convert that to call +442079460000, and request line could be:
INVITE tel:+442079460000 SIP/2.0
However, SIP URIs also have a way of representing a tel URI while being a valid SIP URI. Auser=phone parameter in the SIP URI indicates that the user part of the URI (i.e, the bit between the "sip:" and the @) is actually a telephone number (the whole of the "tel:" URI without the leading "tel:"), as defined in RFC 2806. So you could instead send:
INVITE sip:+442079460000@voip.co.uk;user=phone SIP/2.0
Which is identical to the first example, except asking voip.co.uk to terminate the call rather than wherever you're sending the request to.
In order to be globally unique, a number needs to be scoped to a particular context (think about different numbering plans). A "phone-context" parameter of the tel URI defines the scope that the number is valid within. The default context of a tel URI is the global one - i.e, E.164, and the number itself must always be prefixed with '+'. The context changes the meaning of the number to indicate that it is valid within the environment where the local entities global phone number starts with the given string.
So, to call a number that is not in the E.164 context, we need to append the right phone-context. In the case of 118500 (a UK directory enquires service), it is available anywhere in the UK. Thus, a good phone-context would be "+44":
INVITE sip:118500;phone-context=+44@voip.co.uk;user=phone SIP/2.0
or it's tel URI brother:
INVITE tel:118500;phone-context=+44 SIP/2.0
Again, this would presumably be done by configuring a dial plan on the phone itself.
In order to handle privacy (such as 141 and 1470 in the UK), a SIP user agent must populate the Privacy header with the values it wishes to use itself rather than including the prefix in the number sent to the service provider. A dial plan configured on the phone could be utilised to do this. So dialing '14102079460000' should result in:
INVITE sip:+442079460000@voip.co.uk;user=phone SIP/2.0
Privacy: xxx
Note that although RFC 2806 has been updated by RFC 3966, RFC 3261 (the core SIP spec) references 2806. Specifically, RFC 2806 is ambiguous as to wether the "phone-context" MUST be included; In one paragraph it says it SHOULD, and another it says MUST. RFC 3966 updates for the inclusion of a phone-context parameter to be MUST.
The user=dialstring approach
Assuming the SIP device isn't smart enough to be configured with a dial plan - or perhaps it doesn't want to be - and wishes to offload the dial plan handling the network, we need some way of indicating this.
Luckily for us, RFC 4967 provides a mechanism for exactly that. The server can then apply rules configured in "the network" for the number.
Note that a dial string URI MUST contain a phone-context parameter, so the question then arises what the value of this should be. While it depends very much on a deployment by deployment basis, I see 2 general ways of handling it:
- A set of pre defined contexts are created, and the user selects the one they want. For example, uk.dialplan.voip.co.uk could be the standard UK dialplan defined above.
- Each user can create their own context - presumably under the domain of the service provider. For example, I use theo.dialplan.voip.co.uk. I then configure this context using tools provided by VoIP.co.uk
I then configure my phone to use "user=dialplan", and tell the phone which context i wish to use - let's say uk.dialplan.voip.co.uk.
Thus, if I wanted to call 118500 (UK directory enquiries), it would be sent as:
INVITE sip:118500;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0
Similarly, calling my London number 02079460000:
INVITE sip:02079460000;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0
an international call would be:
INVITE sip:0015001234567;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0
Using our withhold CLI feature also works using this approach, so I could call my london number while requesting the network withholds my number by indicating it in the dial string, assuming the uk.dialplan.voip.co.uk dial plan has been suitably configured:
INVITE sip:14102079460000;phone-context=uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0
Of course, in reality, very few SIP devices are ever configured with dial plans, and most networks don't even support phone-context! Generally, when you send a call to a service provider, it will currently perform analysis of the number and look at settings for the user trying to place to call to extract what it means. While this works most the time, it does require logic in the network, which means you're never really sure what the network is doing for you.
urn:sos
One issue with phone-contexts is they are not aware of your current location, and some - in reality one - location really needs to know where you are: the emergency services.
When you dial 999 (or 112, or 911 perhaps), you really want to speak to the emergency services near where you are, not wherever your phone-context is configured!
So, to let the network know that, a special URN service has been defined in RFC 5031. When your phone detects you've called the emergency services (by looking at the number you dialed), it would convert that to a emergency services URN:
INVITE urn:service:sos SIP/2.0
You can also qualify it with a more exact service - as some countries have different numbers for different services - for example:
- urn:service:sos.ambulance
- urn:service:sos.fire
- urn:service:sos.gas
See the IANA registry for all the currently registered services.
The idea with these is that the SIP proxy receiving the request would use location based information to route the call to the correct place.
ENUM
ENUM provides a few funky solutions to some problems in SIP.
A NAPTR lookup could allow a phone to look up how many digits are needed to reach a valid number as the user is dialling by using Ray Bellis' Send-N draft. By using phone-context with DNS entries, even a local phone-context can also be handled this way.
Linked Numbering Schemes
It's common on a fixed PSTN line to be able to dial a local number without including the full prefix, for example, if I had the telephone number 02079460001, I could call 02079460000 by dialling 79460000. This is simply a feature of a phone context. Using user=dialstring, you could either set the context to the global number you're calling from, i.e:
INVITE sip:79460000;phone-context=+4402079460001@voip.co.uk;user=dialstring
or set the context to be a dialplan that has been configured to handle that, perhaps:
INVITE: sip:79460000;phone-context=london.uk.dialplan.voip.co.uk@voip.co.uk;user=dialstring SIP/2.0
