Free USA DID Number (Part 2) - Forward DID incoming calls to PSTN

In my previous post, I've shown you how to get a free USA DID number and receive all DID incoming calls using a SIP client for free using a SIP softphone such as X-Lite. In this post, I will show you how to forward the DID incoming call to a PSTN number, which will allow you to receive DID incoming calls at any time without needing to have a softphone connected and registered with your SIP provider.

Keeping in mind that ipkall allows us to forward DID incoming call to any SIP URI (provided that the destination SIP server does not require SIP registration) and flowroute allows SIP authentication by IP address, we have a perfect combination to make the above mentioned possible:

1. Go to www.flowroute.com and get a free account. You''ll be given USD 0.25 trial credits which is enough for test purpose.

2. Login to your account, open the tab Interconnection

3. In the section for Outbound Allowed IPs, add the following IP address

66.54.140.46
66.54.140.47

I will explain the reason for this later.

4. In the section for Tech Prefix, notice the prefix for your account (e.g. 51111111#), we will need this later.

5. Login to your ipkall web portal and change the DID settings

SIP Phone Number: 51111111#xxxx
SIP Proxy: sip.flowroute.com

where 51111111 is the prefix you found in step 4 and xxxx is the destination number to forward the DID incoming call to, in the format country code + area code + phone number. (no IDD code such as + or 00 should be included).

6. Try to make a call to your ipkall DID number. Your destination phone number xxxx should ring.

How it works

We have set up ipkall to route all DID incoming calls to the following URI hosted by flowroute

51111111#xxxx@sip.flowroute.com

Basically we tell flowroute to use account 51111111 to call the destination number xxxx. flowroute will verify that the call is made from an allowed IP address (e.g. IP-based authentication) , which is the IP addresses of the ipkall server that we added in step 3. If the account number and the IP address pass the check, flowroute will call the destination number and ipkall will connect the caller to the destination number. The cost for routing the call to xxxx will be deducted from the flowroute account balance.

The list of allowed outbound IP addresses that we see in step 3 is important; without this flowroute will not make any outgoing calls unless the SIP client is registered, which is not possible with ipkall's free DID number.

Limitations

1. Call may take some time to connect due to complicated routing between ipkall and flowroute server. If flowroute takes too long to connect the call, ipkall may give up and disconnect the DID incoming call before it can reach the destination number.

2. Also because of complicated call routing, it is unlikely that the correct caller ID is shown on the destination phone number. You'll most likely see a private number or US number as the caller ID. Although flowroute sends the caller ID as specified by the presence of one of the following header fields in order of preference "P-Asserted-Identity", "Remote-Party-ID" or "From", it is unknown if ipkall sends any of the above headers when it routes the DID incoming call to flowroute.

Read More »

Free USA DID Number

If you're not staying in the US and need to register for a service that requires a US number for verification, a US DID number will be useful. For those who don't know what a DID number is, see this.

There are services that give you a DID number in the US, e.g. +1 (xxx) xxx-xxxx. When someone calls this number, it can be set to forward the incoming call to a physical number (e.g. PSTN or mobile phone number), or to a SIP client which will handle the incoming call.

I found the following 2 free services that give me a free US DID number which, upon called, will forward the call to a SIP client:

* ipcoms. This service will allow you to set an IP address of a SIP server/client where all incoming DID calls will be forwarded to. Unfortunately, that's all that can be set. When an incoming call comes, a SIP packet describing the incoming call will be sent to this IP at port 5060, and it's up to the software listening to port 5060 at this IP to decide how to handle the incoming call. This can only work well if you have a static IP address and a dedicated server to handle SIP incoming call. Dynamic DNS services (such as noip) cannot be used as the Web control panel does not accept domain names as destination.

I managed to make this work somewhat by using a Starhub Mobile Broadband SIM card that gives me a public IP (e.g. 117.x.x.x). By using SJPhone as the SIP client and configuring the DID number to point to 117.x.x.x, SJPhone is able to ring when I call the DID number. Voice quality is fine when using Singtel IDD 019 to make the call. However, sometimes for a single call to the DID number, SJPhone will report multiple incoming calls. Also, the IP address will change periodically and will have to be manually updated from the ipcomms web portal.

* ipkall. This is just like ipcomms above, but it allows you to forward incoming DID call to a SIP URI, e.g. sip:1234567@sip.example.com. The SIP URI can be hosted on your own SIP server, or on one of the many existing free SIP providers.

I register for a free SIP account at callwithus, run X-Lite on this account, configure the ipkall DID to point to my callwithus account and I am able to receive DID incoming calls for free! Interestingly, since both ipkall and callwithus support concurrent calls, it is possible to answer more than one call at a time.

For this to work, your SIP provider must allow incoming SIP calls from external IP addresses, e.g. calls not made from the same provider. Many providers will disallow incoming call until SIP registration is performed, or will only allow incoming call from a list of allowed IP addresses. callwithus is among those few providers that do not have any restrictions.

However, using this method, caller id is not available. Most DID incoming calls will appear to be from ipkall server, e.g. "202 224 4545@66.54.140.46". ipcomms, on the other hand, reports the caller number correctly.

Read More »

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

Read More »

SJPhone: free SIP client for Pocket PC

If you are looking for a freeware SIP client that can run on your Pocket PC, SJPhone is recommended. It is a cross-platform program that can run on Linux, MAC, Windows CE and Windows XP. You can have configurations for different SIP providers and easily switch between these providers.

Upon installation, select Menu->Options->Profile tab. Choose to add a new 'call via SIP Proxy' profile. Most likely you'll only need to change the SIP Proxy and the STUN tab according to your service provider settings. You will be prompted for username, password and caller-ID the first time your connect to this provider using SJPhone.

SJPhone won't automatically establish a connection. You must manually make a connection (either Wifi or GPRS/3G) first before starting SJPhone. Audio will also be played to loudspeaker/headset. However, if your device supports the necessary APIs, there are tools to route the output audio to the earpiece, see this for more information.

Notice that if you attempt to install the WM2003 versions on WM5 or later, everything will appear fine until you receive an incoming call. The incoming call notification will still appear but there will be no options to Answer/Reject the call - just a 'Hide' button. This is probably due to the differences between the SHNotificationAdd API in WM2003 and WM5.

No version is available for Smartphone yet.

Download links:

http://www.sjphone.org/preview/ (all versions)
http://www.sjphone.org/preview/SJphone-1.60-WindowsCE(preview)/ (Windows CE)

Read More »