callwithus.com’s SIP service: new findings

After a few weeks playing with callwithus.com, a SIP provider that supports concurrent outgoing & incoming calls that I have introduced in my previous post, I decided to post here a few interesting things that I have observed, for the benefits of those who decided to use callwithus service.

Call Routing

There are different trunks through which a SIP call to a destination number can go through. By default, callwithus will try the least cost trunk. If the call is not successful via a particular trunk, the server will try the next available trunk, in ascending order of call cost per minute. While the SIP server is trying the different trunks, the client will receive 183 (Session Progress) or 180 (Ringing) so the process of switching between different trunks is transparent to the client. The Call History in the Web portal will show the last trunk which was attempted.

The automatic method of trying different trunks has a drawback. If, for example, a call successfully reached the destination (e.g. the phone rings) but was not answered by the recipient, the SIP trunk on which the call was attempted will report the number as not available, making callwithus retry on the same number again and again until the call is answered, or until all trunks have been attempted.

To prevent this from happening, we can tell callwithus to route all calls via the specified trunk by appending *4XXX in front of the number to dial where XXX is the trunk code. For example, to dial +6500000000 via trunk 020, invite the following SIP address:

sip:*40206500000000@sip.callwithus.com

Once a particular trunk is specified, callwithus will not try to make the call via other trunks. For more information, see the callwithus FAQ.

Caller ID

callwithus website says that caller-ID delivery is not stable outside US & Canada. However, in my tests, caller-ID delivery seems to be more stable with expensive premium trunk. I tried trunk 020, which is the most expensive trunk to call Singapore numbers, and caller ID seems to be delivered most of the time. Other trunks may or may not deliver caller-ID, and in some cases, the caller-ID displayed on the destination phone is slightly different from what was set. For example, +6500000000 may be displayed as +0191 65 00000000.

DTMF

When a SIP call is made using a callwithus’s low cost trunk (e.g. trunk 070 for Singapore numbers), DTMF detection may not be possible. The reason is probably that low cost trunks use low quality sampling rate to save bandwidth, making it impossible to maintain high frequency signals. This may result in failure to detect some or all of the DTMF digits.

In one of my test cases, I have a situation where my IVR application could only detect DTMF digit 1, 4, 7, * and ignore all other digits. I had a hard time finding out the root cause of the problem. The call was routed via the least cost trunk 070, which distorted all frequencies higher than ~1200Hz. Digit 1, 4, 7, * will generate a column frequency of 1209Hz and a row frequency of 697Hz, 770Hz, 852Hz, 941Hz respectively and will still work. However, other digits won’t work as their column frequencies (1336Hz, 1477Hz, 1633Hz) have been distorted. For more information about DTMF, see wikipedia

The distortion is probably not audible to even the most sensitive ears. However, it can easily be seen by performing a recording of the audio and using a sound editor software such as GoldWave to view the frequency response.

The workaround is to use a premium route that has better audio quality. For Singapore numbers, DTMF detection should work fine using trunk 111 and other more expensive trunks.

Fax

I attempted to send a fax via SIP using callwithus SIP service. I managed to find Kapanga Softphone that offers fax capabilities via SIP. However, even with the best premium route (highest cost!), I found it extremely difficult to send a fax to Singapore numbers. Most of the times, the softphone would get stuck at ‘Sending CNG‘, which is the first handshaking phase of the fax protocol. Once or twice it managed to get passed the handshaking process, but the call was disconnected when the client was attempting to send the first page. The destination fax machine reported ‘Timed-out’ and printed the first few lines of the original faxed document.

Not having the patience to research the fax protocol, record the audio and perform analysis to see what actually went wrong, I would assume the failure was because the codecs that callwithus server uses is not optimized for fax, thus distorting high frequency signals required by the fax protocol, even when the highest cost trunk is used.

For fax purpose, I would suggest another provider that supports fax (via T38 codecs) better, such as flowroute