Background

OFCOM (the UK telecommunications regulator) recently mandated that any VoIP Service Provider that allows end users to make calls to the PSTN must also provide access to the Emergency Services number.

They also mandated that “to the extent technically feasible” the Emergency Handling Agencies (EHAs) must be supplied with the location of the caller. This speeds up the emergency response, and also helps in those cases where the caller is unable to provide their location.

This is already done by the existing PSTN and mobile telephone companies and is not a particularly difficult problem for them as they control all elements of the telephony service. However for VoIP the problem is substantially more difficult - VoIP users can connect to their VoIP service provider over any internet connection, from anywhere in the world.

In some parts of the world the customer is required to notify their VoIP service provider of their location. This isn’t feasible however for users who regularly use their VoIP service away from home, e.g. with a WiFi VoIP handset. Also, if this information is out of date then the consequences can be tragic as seen recently in Canada where the initial ambulance dispatch went to the customer’s previous address, 2500 miles away from where it was needed.

Proposed Solution

The proposed architecture currently being developed by NICC (the UK telecoms industry standards group) is to have the VoIP Providers, the Internet Service Providers, and the Access Network Providers all cooperate to provide location information in real-time.

The VoIP provider will know what the end user’s public IP address is, but they don’t know where it is. When they receive an emergency call they’ll pass the call over the PSTN to the EHA, but at the same time they’ll also send a separate message (using TCP/IP) containing that end user IP address.

The EHA will maintain a database derived from BGP4 real-time routeing data that maps from IP addresses to ISPs. Once they know the ISP, they’ll send the ISP’s “Location Information Service” a HELD protocol request containing the IP address as the lookup key (see IETF Draft geopriv-http-location-delivery). The response from the ISP is an XML document in PIDF-LO format (see RFC4119 and RFC5139) which contains either a “civic address” or a “geodetic location” (i.e. latitude/longitude).

A further complication is that many types of internet access run over a separate Access Network Service which is independent of the ISP. Most ADSL in the UK, for example, is provided using BT Wholesale’s “IPStream” access product which is then packaged up by hundreds of different ISPs.

In these networks it’s common for individual users not to be tied to a specific access line. Hence the Access Network needs to tell the ISP exactly which line is being used. In some cases that might be sufficient for the ISP to determine the address, but in many cases it’s expected that the ISP LIS will need to proxy the HELD request onwards to the Access Network where they should have the most accurate and up-to-date address information.

The diagram below is a simplified representation of how it’s expected to work.

Policy Issues

In my opinion the biggest problem with the architecture at the moment is that neither the ISPs nor the Access Networks actually operate Location Information Services. Partly this is because the relevant standards are still in development, but particularly because as yet there’s no regulation requiring them to do so.

All of the OFCOM regulatory changes so far have been focussed on the VoIP providers, without sufficient acknowledgment of the fact that it’s only the ISPs and the Access Networks that really know where any particular IP connection is being made from. However Ofcom are committed to revisit the regulations for the location issue very early next year, once technical standards (national and international) are clarified.

In my opinion most ISPs are at the moment completely unaware that they might need to do anything, and I hope that this article will stimulate further involvement from the ISP industry. I believe that regulation requiring ISPs and Access Networks to operate Location Information Services is inevitable and it would be better to work now towards a practical solution than to be stuck with an unworkable one later.

It should be noted that the implementation costs for this will be significant, and ISPs looking to recover their costs might start looking at how they could sell-on their customers’ location information to third parties. The potential market for location-based advertising is enormous, but so too are the privacy implications.

Ray Bellis - Senior Researcher

We have a Cisco CallManager (CCM) VoIP telephone system here at Nominet and I’m currently investigating how this system might be adapted to support ENUM lookups for outbound calls so that calls can be made directly to other VoIP systems without going over the PSTN. There’s no built-in support for ENUM in CCM at all, so some sort of plugin would be required.

I’ve not been able to find any internal plugin APIs, but CCM does support most of Version 1.2 of the Java Telephony API. My hope is that this API will provide tight enough integration with the system to allow the necessary outbound call routeing.

I found that there are very few examples around of how to use JTAPI to actually do anything. Cisco does provide a sample application, but it’s unnecessarily complicated. The code below is therefore presented as a much simplified version of that application that does nothing except tell a CCM extension to dial a specified number.

To use this code you’ll need to obtain the jtapi.jar file from the CCM Administration software via Applications->Plugins->JTAPI. You’ll also need to create a new “Application User”, and add that user into the JTAPI Groups, and also grant that user access to some terminals.

With jtapi.jar in your CLASSPATH, this application can be run as:

% java MakeCall {host} {user} {password} {extension} {number}

As soon as the program has told CCM to place the call it will exit.

As this is only an example there’s only minimal input and error checking, but the application will generate an appropriate error message if you supply incorrect JTAPI login details, or if you try to trigger a call from an extension that your JTAPI user doesn’t have access rights to.

There are two specific parts of the code that deserve special mention:

1. The com.cisco.cti.util.Condition class is not part of the JTAPI standard, but provides a useful semaphore object. In this case it’s used to make the main thread block until the ProvInServiceEv event is received by the anonymous ProviderObserver object.
2. It appears that it’s always necessary to add a CallObserver to the Address object (even if that observer subsequently does nothing useful itself) since the JTAPI library throws an exception if you don’t. I couldn’t find this behaviour documented anywhere.

MakeCall.java

import javax.telephony.*;
import javax.telephony.events.*;
import com.cisco.cti.util.Condition;
 
public class MakeCall
{
	public MakeCall(String[] args) throws Exception
	{
		String hostname = args[0];
		String login = args[1];
		String passwd = args[2];
		String src = args[3];
		String dst = args[4];
 
 		/* start up JTAPI */
		JtapiPeer peer = JtapiPeerFactory.getJtapiPeer(null);
 
 		/* connect to the provider */
		String providerString = hostname;
		providerString += ";login=" + login;
		providerString += ";passwd=" + passwd;
		Provider provider = peer.getProvider(providerString);
 
		/* wait for it to come into service */
		final Condition	inService = new Condition();
		provider.addObserver(new ProviderObserver() {
			public void providerChangedEvent (ProvEv [] eventList) {
				if (eventList == null) return;
				for (int i = 0; i < eventList.length; ++i) {
					if (eventList[i] instanceof ProvInServiceEv) {
						inService.set();
					}
				}
			}
		});
		inService.waitTrue();
 
		/* get an object for the calling terminal */
		Address srcAddr = provider.getAddress(src);
		srcAddr.addCallObserver(new CallObserver() {
			public void callChangedEvent (CallEv [] eventList) {
				/* ignored */
			}
		});
 
		/* and make the call */
		Call call = provider.createCall();
		call.connect(srcAddr.getTerminals()[0], srcAddr, dst);
	}
 
	public static void main(String[] args) {
		try {
			new MakeCall(args);
		} catch (Exception e) {
			e.printStackTrace();
		} finally {
			System.exit(0);
		}
	}
}

I’m currently writing a Java library to implement client-side ENUM lookups [RFC3761].

The standard class libraries don’t provide access to NAPTR records, so I’m using the dnsjava library to perform the actual DNS lookups.

I was puzzled to find that the result of calling (String)NAPTRRecord.getRegexp() on any RR containing backslash escaped strings (i.e. !^\+441865332...) ended up with the backslashes apparently doubled-up, i.e I’d see !^\\+441865332... in the result of the function.

At first I thought that it was the actual zone data that had the extra backslashes in it, and this was further confused by the fact that dig’s output also showed two backslashes. However tcpdump showed that the wire format of the DNS responses was in fact correct and only contained single backslashes.

It turns out that dnsjava intentionally stores and returns all string fields in escaped format. If the data itself contains a backslash then that backslash in turn is escaped

If you want to use dnsjava to output a zone file for loading into your favourite name server that’s very useful, since name servers typically expect to read escaped data from their zone files. This is why dig works the way it does - the output from dig is a legal zone file.

However if you actually want to use these strings as data in your own code, make sure you unescape the values yourself!

This is a basic explanation on how to set up VoIP at home because there are a number of different configurations possible using a variety of kit. First, I need to explain some terminology:

• PSTN - Public Switched Telephone System. This is the ordinary public telephone system.
• DECT. This is the technology behind the wireless telephones that are in common use within homes. It consists of a base station that connects to the PSTN and one or more DECT phones that are registered with that base station.
• FXS. This is the name for the telephone socket on a piece of kit into which you plug a handset, a DECT base station, a fax machine and so on.
• FXO. This is the name for the telephone socket on a piece of kit that connects to the telephone provider’s socket. In other words, if you want some kit to connect to an existing PSTN line then you need one of these in it.

VoIP provider

There are two things you need to make this work:

As well as an ADSL (broadband) or cable Internet connection, you also need a VoIP provider in order to make this work. That is a company who will route your VoIP calls for you and provide interconnection to the PSTN for both incoming and outgoing calls.

VoIP providers come in three flavours:

1. Closed network using proprietary technology. Such as Skype. You can connect to the PSTN through them but not directly to other VoIP providers.
2. Closed network using open standards. Such as Vonage. They use industry standard technology like SIP so you can use different software and hardware to connect to them. But again you can connect to the PSTN through them but not directly to other VoIP providers.
3. Open(ish) network using open standards. Such as Sipgate or Gradwell. Through them you can also call subscribers to other VoIP networks and the calls are free of charge.

Option 1 - Existing phone with only a VoIP provider

This is the configuration that many manufacturers assume we want to use, though I doubt that many of us actually do. It works by adding a VoIP adapter in between your existing PSTN phone and your broadband modem. All calls then go out to your VoIP provider over your broadband connection. If you want access to the PSTN (incoming or outgoing) then your VoIP provider does that.

However you normally cannot do 999 calls or can you reach premium rate services. There are also limitations on whether or not you can move your existing telephone to a VoIP provider.
The setup looks like this:

Option 2 - Existing phone with VoIP adapter and retaining PSTN line

It is perfectly possible to retain your existing PSTN line and use just one phone to access both lines, you just need a VoIP adapter that also has an FXO port to plug into the PSTN socket. This gives you the best of both worlds.

The only real problem with this setup is choosing what calls go down what line. Some of the adapters are very basic in the functionality they provide. Another tip is to make sure any VoIP adapter you buy has a PSTN failsafe or similar. This ensures that you can get to the PSTN through the adapter even if the power to it fails.

This setup looks like this:

If you have a DECT phone then the setup will look much the same:

Of course you may be unlucky enough to have your PSTN socket and your ADSL modem in different rooms, in which case some VoIP adapters can use a WiFi dongle to access the ADSL modem. I only know of one, which is the Linksys WPB54G. This setup looks like this:

Option 3 - New hybrid DECT phone retaining existing PSTN line

You may wish to throw caution to the wind and buy a completely new phone system that does both PSTN and VoIP. One such example is the Siemens Gigaset C460IP (called the C450IP on Siemens website, C460IP is the UK-specific model) which is also a DECT phone.

This setup does not require and adapter since the DECT base station has that functionality built-in. It looks like this:

Option 4 - New WiFi phone with only a VoIP provider

Finally we come full circle to the most Internet way of doing things that uses the least amount of kit. This is using a WiFi telephone that connects directly with your WiFi ADSL modem and on to your VoIP provider. As mentioned above, there are potentially some issues with relying solely on a VoIP provider.

This setup looks like this:

That’s all for this post but we hope to have some future posts that review VoIP adapters and a few Hybrid or WiFi phones.

To start off, if you don’t know much about ENUM then read our brief introduction on our website.

ENUM as a technology is all about telephone numbers, but just how long will telephone numbers actually last and so how long will ENUM be with us?

Surprisingly it turns out that for VoIP we could do away with telephone number immediately. By using SRV records it is possible to have fully alphanumeric VoIP addresses that look just like email addresses. However there are some very big problems with this:

Dialling names not numbers

Most devices capable of dialling do not support dialling a name instead of a number. Obviously for VoIP phones and clients this is an omission that could be corrected just by greater awareness amongst developers. The really interesting bit though is mobile phones. The technical platform that mobile phones work on could support name dialling with limited changes, so they might do it one day.

Social exclusion

One of the big themes in the ongoing IGF is access to the Internet. Switching to alphanumeric addresses for VoIP could make the problems of exclusion much wider. Technologies will probably be developed to bridge the gap, but the problem will still be there.

In conclusion I think that telephone numbers, and ENUM by implication, will phase out over perhaps ten or twenty years, whilst we are weaned from our addiction to telephone numbers. But then given that Nominet is only ten years old and so much has happened in that time, I don’t think that makes ENUM any less worthwhile.

There are a number of technologies, such as Jabber or SIP that use what look like email addresses but actually aren’t. These addresses look just like email address of the form name@domain and they rely on SRV records to make them work.

In other words, how do I use jay@nominet.org.uk as my email address, my jabber address and my SIP address? How does the client know how to find the appropriate server if all it knows is the domain name part of nominet.org.uk?

Mail servers as we know have the special DNS record, the MX record. To specify the mail servers for a domain you just add appropriate MX records under that domain. However there aren’t special DNS records for SIP or Jabber. WE might assume that all we need do is find the address for the domain but then that would mean that all services have to run on the same server. What we need is some way to specify the address of the SIP server that is different from any other server address for that domain. So as well as SRV records we have a special way of showing protocol they refer to.

An MX record for say nominet.org.uk is specified like this in DNS:

nominet.org.uk.                      86400  IN   MX  10  mx3.nominet.org.uk

Whereas an SRV record for say SIP has a specially constructed left hand side, which looks like this:

_sip._tcp.nominet.org.uk.            86400  IN    SRV  1  0  5060  sip.nominet.org.uk

As you can see this DNS name is unique to SIP over TCP, which is how we can identify that this particular SRV record is that of the SIP server.

Similarly the SRV record for Jabber looks like either of these (xmpp is the standard name for jabber):

_jabber._tcp.nominet.org.uk.         86400  IN    SRV  1  0  5269  im.nominet.org.uk
_xmpp-server._tcp.nominet.org.uk.    86400  IN    SRV  1  0  5269  im.nominet.org.uk

All of these SRV records can happily co-exist and applications will only find those they need.

The final thing is to explain the numbers in the record. To the right of the SRV part we have Priority, Weight, Port, Server name.

• Priority. Clients should connect to the server with the lowest priority but should not try any servers with a a higher priority unless the first ones are not responding. This allow you to specify backup servers that you know will only be used if the primary servers are down.
• Weight. Clients should distribute their hits across all servers with the same priority in proportion to the weights. In other words if two servers have a weight of 50 then they both 50% of the hits.
• Port and Server. Obvious really, what server to connect to and what port to do it on.

SRV records could really make MX records redundant though nobody uses them that way. But they probably make it unlikely that any DNS record similar to MX will ever be developed in the future.

NAPTR stands for Naming Authority Pointer. This is a form of DNS record which allows for one or more services to be associated with a unique string, and for the string to be re-written using regular expressions. The main usage of NAPTR records is within ENUM, the application which maps phone numbers onto other, IP-based services in VoIP. However, NAPTR is part of a more abstract system: DDDS, the Dynamic Delegation Discovery System. The DDDS is discussed below with reference to ENUM as an example DDDS application.

DDDS

The DDDS “is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems” [RFC 3401]. In DDDS, a unique string is mapped by an application onto a set of services using a rule database, which consists of a set of rewrite rules, applied recursively until a terminal condition is reached. The terminal condition must make sense to the application, whilst the intermediate output of rewrite rules must be keys into the rule database.

In ENUM, there is only ever one rewrite rule applied, the NAPTR record. The output of this rule is terminal, and is a URI pointing to a VoIP service.

DDDS Applications are specified in terms of:

• The Application Unique String (AUS). This is the thing that the rules act on. In ENUM this is a phone number with no spaces and no punctuation, save for a ‘+’ in front of the country code. The AUS for Nominet’s phone number is therefore +441865332211.
• The First Well Known Rule. This rule says where the process starts. In ENUM the database is DNS, specifically the e164.arpa tree. This is organised in the exactly the same way as the E164 numberspace. The transformation is therefore the identity function. No transformation occurs.
• A list of valid databases, in this case DNS. To allow for DNS lookups the resolver called by the application must translate from a phone number into a leaf in the e164.arpa tree. Nominet’s number translates into 1.1.2.2.3.3.5.6.8.1.4.4.e164.arpa.
• The final expected output. ENUM is an application which turns phone numbers into VoIP services, such as email, so the expected output is a valid URI pointing to a service such as SIP or email.
• The algorithm used in DDDS, and the specific requirements for applications and databases are defined in RFC 3402.

Format of NAPTR records

The NAPTR record is defined in RFC 3403. It was designed specifically to represent rewrite rules in DNS, so allowing DNS to be a valid DDDS database.

NAPTR records have six fields. The first two, order and preference are used to distinguish between several possible rewrite rules through defined priority. They are specifically NOT for load balancing. The important difference between the two fields is that, once a matching record is found, “the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences”. The preference field is a way of expressing the hierarchy of quality of services that are available

Another way of looking at this is that the order specifies how the holder of the delegation wishes the rules to be processed, whereas the preference is may be over-ridden by the client depending on which service it wishes to use. Interpreting it in this way, the order
field is analogous to the MX preference value.

The third field is a flag. In the DDDS algorithm this flag is intended to signal where in the process the rewrite rules have reached. In ENUM NAPTR records it is always “u” to indicate that the output is terminal and results in a URI. That is, processing finishes with this rule.

The fourth field is service. This is a character string that is defined in the application specification. For ENUM this always start “E2U+”, though case is insignificant. This is immediately followed by the type of service. SIP is represented as “e2u+sip”, therefore. Some service types may include further subtypes, such as “e2u+sms:tel”, for text messaging and “e2u+sms:mailto”, for SMS delivery over SMTP. A full list of ENUM services can be found at http://www.iana.org/assignments/enum-services.

Next comes regular expression. This is a Perl-like regex which rewrites all or part of the AUS. Note, it is not the key that is being rewritten. In ENUM terms this means that the phone number is being translated, not the e164.arpa domain name.

Finally comes the replacement field. This is a FQDN which is the next step in the DDDS chain, ie. the next key to look up. As NUM NAPTR records are always terminal this is always a single dot.

ENUM Example

An example NAPTR record set may clarify things. This is lifted from RFC 3761. As it states there, the services listed do not necessarily tally with real enumservices, but the example is valid.

$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.        NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
                                                  NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
                                                  NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .

This record set maps the phone number +441632960083 onto three possible identically ordered URIs, with a preference for SIP, then H323, and finally email. In each case, the regular expression matches the full AUS (^.$), and replaces it with a URI (e.g., sip:info@example.com). As this is a terminal record, this URI is returned to the client.Though most NAPTR records replace the full AUS, it is possible for the regular expression to back-reference part of the AUS, to grab an extension number, say:

$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. *   NAPTR 10 100 "u" "E2U+sip""!^+441632960(.*)$!sip:1@example.com!" .

Once the client has the URI it must be resolved using DNS, but this is no longer part of the DDDS algorithm..

Other Applications using NAPTR records

But then again, it could be. RFC 3404 describes “DDDS Based URI Resolution”.

It is a long stated goal to use persistent, location-independent Uniform Resource Names (URNs) in preference to more brittle URIs. This would allow publication of persistent pointers to resources that are not dependent on service configuration. The Knoxville framework, referenced in RFC 3404, adopts the approach of separating name assignment from resolution. DNS is an established and widely used resolution framework, but it is not suitable for URNs, for reasons of scale amongst other things. DDDS is recommended as a mechanism which can use DNS to locate URN “resolvers” through URI rewriting.

The URI and URN resolution applications are technically identical, but operate independently. Both use DNS as the valid database, and each has either the URI or URN as its AUS. The First Well Known Rule extracts the key from the AUS. In the URI case this is the URI scheme, for URNs it is the Namespace Identifier. To use DNS with these keys it is necessary to request NAPTR records in the ‘.uri.arpa.’ and ‘.urn.arpa.’ trees.The database contains NAPTR records of the format described above. Four flags are defined, of which three describe terminal conditions:

• “S” means the out put of the rule is a domain-name for which SRV records exist.
• “A” means the out put is a domain-name that can be used to find A and AAAA records.
• “U”, as above, yields a URI.
• “P” means that the rest of the process is application-specific, and is out of the scope of DDDS.
• An empty flag indicates that a further DDDS loop is required.

The service field may contain protocol information. It will probably contain some service information allowing URIs to be resolved to one or more URIs, resources or descriptions of resources.

The RFC contains complex and detailed NAPTR examples for URN and URI resolution. These examples are very detailed, and repetition here would be mere plagiarism. What they do show is the versatility of DDDS and the NAPTR record for resource discovery.