When an ENUM user sends us a Create command, we validate the XML against the schemas and that the XML signature chain of trust to our CA is OK. When this doesn’t work, there isn’t much feedback that we can return to the user, and it’s difficult to diagnose what caused the failure.

It’s possible to validate a signature with oXygen but all that says is “Invalid Signature” if there’s an error.

So I’ve put together some Java code which produces a bit more diagnostics; see ValidateEnumCreateJava.zip (or as a .jar file if you don’t have a Java compiler)

Before you start

I recommend doing an XML validity check first: don’t waste time trying to debug XML signature problems if you haven’t.

One way to do this is to use Sun’s Multi Schema Validator - https://msv.dev.java.net/ as suggested in the README in our schema bundles, i.e.
java -jar /path/to/msv.jsr /path/to/nom-enum-root-2.0.xsd your_file.xml


Running the ENUM signature checker

• compile as:
  
javac ValidateEnumCreate.java


• run as:
  
java ValidEnumCreate <yourfile>


or if you don’t have a Java compiler…

• run from a .jar file:
  
java -jar ValidEnumCreate.jar <yourfile>


Results:

Valid Signature

If all is well, the result should be

Signature Validated OK

The response for an invalid signature depends on what was wrong:

Bad DigestValue

If the digest is different but the signature of that digest is correct, the result will be

Signature 0 failed core validation:

Checking that the digest matches the data:
FAIL: DigestValue does not match data
    (Signature 0 ref[’0′] validity status: false)

Checking the signature of the digest:
PASS: SignatureValue verifies DigestValue
    (Signature 0 validation status: true)

This is possibly due to munging of whitespace. The signed XML is fragile and even sensitive to changes in whitespace between tags (I commented on this in an earlier blog article)

Bad Signature or certificate

If the signature is invalid or the wrong certificate is included, the results will be:

Signature 0 failed core validation:

Checking that the digest matches the data:
PASS: DigestValue matches data
    (Signature 0 ref[’0′] validity status: true)

Checking the signature of the digest:
FAIL: SignatureValue does not verify DigestValue
    (Signature 0 validation status: false)

Other errors

• Failure to parse the XML - error message
• Failure to decode the Digest/Signature/Certificate - Java exception + stack trace

References

http://jtute.com/java6/0904.html
http://java.sun.com/developer/technicalArticles/xml/dig_signature_api/
http://weblogs.java.net/blog/mullan/archive/2006/01/my_xml_signatur_1.html
http://weblogs.java.net/blog/2007/08/03/even-more-xml-signature-debugging-tips

I’m pleased to announce the release of enumdroid.

This application adds ENUM (E.164 Number Mapping) support to your Android phone.

Each time you dial a full international number (i.e. starting with a ‘+’) your phone will check the DNS for additional routing information and offer you a list of alternate contact methods.

The application is open source (under the Apache License) and the code is available for download from Google Code.  The application can be downloaded from the Google Market under Applications -> Communication

Here are some screenshots, which show in turn:

1. Nominet’s switchboard number being dialled
2. ENUM results being returned
3. A call being placed over the PSTN to a tel: URI
4. The ENUM application’s settings page

In order to register an ENUM, a XML token (RFC5105) is signed by a Validation Agency to say that the user has a given phone number & so has the right to a ENUM registration; this token is sent by an ENUM Registrar to Nominet’s EPP server.

This process of signing a token isn’t entirely straightforward:

The simplest way to sign a token is to use the templatesign tool from the Apache XML Security project.

$ templatesign -r testVA.key password -c -x testVA.cert unsigned_token.xml > signed_token.xml

A token signed by templatesign is valid, as can be checked using checksig (from the same toolkit) or Oxygen.  However when this token is included as part of an EPP Create command, the signature becomes invalid.  It seems that templatesign doesn’t do the XML canonicalization quite right.

Aside:
To make an XML signature, a digest is taken of the XML data being signed; the data is “canonicalized” before calculating the digest.  It seems that canonicalisation is more-or-less just a standard way of inserting whitespace.  I’m surprised this is how it works because it’s rather fragile, compared to calculating the digest using the element names, attributes etc & ignoring the formatting.

One workaround for this is to run templatesign on the entire Create.  Although this is satisfactory for testing, it does not work in the situation where a Validation Agency has to send a signed token to a Registrar, who then wraps this up into a Create command & sends that to Nominet’s EPP server.

It is possible to use Oxygen to sign a token (example) and this will do the canonicalization in such a way that when enveloped in a Create command, the signature remains valid.  However, Oxygen is an interactive GUI tool and not suited to making an automated system.

Oxygen says that it uses the Java version of Apache XML Security. Looking at the examples that come with the Apache package (specifically GenEnveloped.java) gives us another option:

We’ve taken this example from the Apache library and made the appropriate changes to sign an ENUM token. I’ve packaged some example code which contains:

• EnumTokenSigner.java - signs a token in such a way that it will validate even when enveloped in a Create command.  It takes an unsigned token (as a Java String) for input, signs it and returns the signed token
• EnumTokenCreator.java - is one way to create an unsigned token.  This could be done in any number of ways but using a DOM implementation easily handles absent optional elements.
• EnumTokenSignExample.java - is a simple test harness - it just loads files & calls the two above utility classes.  You will at least have to edit this to set the path names of the keys & token properties.  It does not (for example) do any of the error-checking that you would expect in production code.
• a Makefile

Key formats

Java uses a different key format (DER) than OpenSSL (PEM).  It is necessary to convert a key+certificate to this format before using the Java tools.  OpenSSL can perform the conversion:

$ openssl pkcs8 -topk8 -nocrypt -in yourVA_key.key -inform PEM -out yourVA_key.der -outform DER
$ openssl x509 -in yourVA_cert.pem -inform PEM -out yourVA_cert.der -outform DER

We have been using the apache xml security (java) libraries to produce RFC 5105 type signed XML tokens. There are a number of steps involved which were not obvious (to me) from the documentation or the examples; so here are some of the things that we had to do.

Firstly turn your ascii-armoured private key and certificate into DER format:

openssl x509 -in enum.crt -inform PEM -out enum-cert.der -outform DER
openssl pkcs8 -topk8 -nocrypt -in enum.key -inform PEM -out enum-key.der -outform DER

NB: in this format your private key is unencrypted, if you are more comfortable doing this on the fly then I’m sure that is possible.

In this format you can read the files into your code by doing something like:

CertificateFactory cf = CertificateFactory.getInstance("X.509");
X509Certificate cert = (X509Certificate) cf.generateCertificate(new
ByteArrayInputStream(JavaUtils.getBytesFromFile("enum-cert.der")));

and similarly with the private key:

KeyFactory keyFactory = KeyFactory.getInstance("RSA");
PKCS8EncodedKeySpec privSpec = new PKCS8EncodedKeySpec(privKeyBytes);
PrivateKey privKey = (PrivateKey) keyFactory.generatePrivate(privSpec);

where privKeyBytes is a byte array from your enum-key.der.

Now you need a String which contains your unsigned token XML, see rfc5105.

For a starting point, we used the code distributed as GenEnveloped.java in the samples directory. This has a number of issues with it; the KeyInfo is not in X.509 format and the transform lacks the InclusiveNamespaces parameter.

The first issue is dealt with by generating your KeyInfo object like this:

X509Data ki5 = kif.newX509Data(Collections.singletonList(cert));
KeyInfo ki = kif.newKeyInfo(Collections.singletonList(ki5));

Now set up your Reference object like this:

List<Transform> transformList = new ArrayList<Transform>();
transformList.add((fac.newTransform(Transform.ENVELOPED, (C14NMethodParameterSpec) null)));
transformList.add((fac.newTransform
(CanonicalizationMethod.EXCLUSIVE, new ExcC14NParameterSpec(Collections.singletonList("enum-token enum-tokendata")))));

Reference ref = fac.newReference
("#TOKEN", fac.newDigestMethod(DigestMethod.SHA1, null),
transformList, null, null);


The rest of the example code is largely unchanged. This should produce a signed token that you can imbed in other XML documents and still have it validate.

So you’ve got your VoIP servers, you understand the basics of ENUM and you will be registering your numbers, but one question remains:

How do I add support for ENUM into my enterprise VoIP system so we can start to get free calls?

well here is a guide to help understand how it all fits together

Scenario 1 - the basic setup

This is the classic enterprise VoIP deployment that you will have been sold by Cisco, Avaya or any other enterprise telephony provider:

As you can see:

• we have a clearly delineated border;
• the VoIP server and all the internal phones sit inside the border;
• PSTN connectivity is through a specialist border device (like a Cisco 28xx router or a Session Border Controller (SBC)), which is the single point of entry;
• the internal phone uses SIP or possibly SCCP or another proprietary protocol internally;
• the border device deals with signalling protocol translation and media transcoding;
• calls in either direction use the same paths (signified by the double headed arrows).

Scenario 2 - Receiving incoming VoIP calls

Taking this one step at a time let’s just look at receiving VoIP calls. I’m going to assume your border device does that:

What this diagram shows is:

1. The external VoIP caller does an ENUM lookup to find your public SIP servers (the border device).  Strictly they might not have used ENUM for this, they might have dialled an alphanumeric SIP address or found your details some other way, but let’s assume ENUM for now.
2. The VoIP phone uses SIP to talk to the border device.
3. The border device proxies this SIP to the PBX.
4. The PBX proxies the SIP to the internal phone and the connection is made.
5. The media stream then comes from the external VoIP phone to the border device, which then
6. terminates and reconnects the media stream to the internal phone.

At no point does the external VoIP phone see any internal infrastructure or talk to it directly.

Scenario 3 - Ideal bi-directional VoIP calls

Ideally we want outgoing calls to mirror the process for incoming calls:

This preserves the single point of entry, the proxying of protocols, media transcoding and so on. Don’t forget, whilst the diagram shows SIP internally, it will might well be a different protocol entirely.

However for this to work the border device needs to be able to do an ENUM lookup and act on that.  Unfortunately this is a rarity at present, though the investment in the UK Central Numbering Database should change that.  Some attempts have been made, for example Cisco sell an add-on called CUBE  (which you need just to do the basic incoming VoIP of scenario 2) that claims to do ENUM, but it is pre-standard version and so not a lot of use.

Scenario 4 - a drop-in ENUM box for outgoing VoIP

To get around the lack of support for ENUM for making outgoing VoIP calls, we drop in an ENUM box:

This shows:

1. The internal phone talks SIP to the PBX;
2. the PBX proxies that to the ENUM box;
3. the ENUM box does the ENUM lookup (which might succeed, fail, or timeout);
4. the ENUM box then tells the border device where to send the call to, either the original destination asked for by the phone (that will then use PSTN) or the new VoIP destination discovered from the ENUM lookup;
5. the border device contacts the external VoIP phone and the connection is established (if this connection fails then it falls back to PSTN);
6. the internal phone sends its media to the border device;
7. which then terminates and resends the media on to the external VoIP phone.

Where the border device does not support ENUM this is easily the neatest way forward.  You have one new device that only contacts the outside world by DNS and the border device still acts as the single point of entry for signalling and media.

Scenario 5 - Border device does not do VoIP

Things could be worse though, maybe your border device does not support VoIP at all and so you need an entirely new box to do all of that:

The ENUM box is more than just an ENUM box, it is also a border device in itself.  The call flow is pretty straightfoward:

1. The internal phone contacts the PBX by SIP;
2. the PBX proxies that SIP to the ENUM box;
3. the ENUM box does an ENUM lookup (if it fails it passes the call back to the PSTN border device);
4. assuming the lookup is a success the ENUM box contacts the external VoIP phone on SIP and the connection is established (if that fails then it send the call back to the PSTN border device);
5. the internal phone sends the media to the ENUM box;
6. which then terminates and resends the media to the external VoIP phone.

So the border is still preserved but you now have a whole new VoIP infrastructure in there.  Of course many people would then be tempted to throw out the rubbish border device that does not do VoIP and get the ENUM box to also do the PSTN connectivity.  Asterisk anyone?

Scenario 6 - all very messy

Let’s suppose your border device still doesn’t do VoIP but you don’t want or can’t have the ENUM box do all of that and want to keep it as just a lightweight SIP proxy. In that case you have no choice but to expose your internal phones:

The call flow is again pretty simple but with a horrible ending:

1. The internal phone contacts the PBX by SIP;
2. the PBX proxies that SIP to the ENUM box;
3. the ENUM box does an ENUM lookup (if it fails it passes the call back to the PSTN border device);
4. assuming the lookup is a success the ENUM box contacts the external VoIP phone on SIP and the connection is established (if that fails then it send the call back to the PSTN border device);
5. the internal phone sends the media directly to the external phone, exposing itself in the process!

And finally …

Support for ENUM amongst enterprise telephony vendors is woefully inadequate, yet history clearly shows that the Internet has left graveyards full of companies that tried to resist it. If your vendor is one of those dinosaurs then hopefully this article will help you bypass their ignorance to take control of your own telephony.

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

SJphone is a popular free VoIP client (or “softphone”), available for Windows, Linux, and MacOSX.

Most softphones have separate settings for the username and password used to authenticate the SIP REGISTER command, and another to set the SIP Address of Record. SJphone, by default, does not. It has the username and password fields, but it generates a default SIP AoR of username@domain.

There didn’t appear to be any way to support our configuration where the Authentication username is different to the left-hand side of the SIP AoR. After much digging a solution was finally found. In the “Profiles” dialog box there is an “Initialization” tab. On this tab there is a “Caller ID” setting and a tick box marked “Inquired”:

Ticking this box tells SJphone to prompt for the left-hand side of the SIP AoR along with the username and password fields. The other two tick boxes control whether the application remembers the supplied value, or prompts for it each time.

If necessary you can tick the “Full Address of Record” box instead, should you need to supply a SIP AoR with a different right-hand side.

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.