Defining Routes: Mobile To LAN
My initial use of the MV-370 was going to be in making calls to the UK from my US cell phone and leveraging the hosted PBX service. I was pleased to find that gateway provides considerable flexibility to route calls right in its own firmware. In some simple installations, its internal logic could eliminate the need for a local IP-PBX.
The first item on the Route menu of the GUI is the "Mobile To LAN" table (Figure 3). This sets up a list of phones that will be accepted to pass calls through the gateway from the cellular network to the IP network.
Figure 3: MV-370 Mobile-to-Lan routing table
This table supports 50 entries. Each entry can be a specific as the caller ID of a single phone, or as broad as an * indicating any incoming caller ID. By specifying a portion of a phone number, you can restrict the access to phones only from a certain area code, local exchange, etc. Since I was only concerned about my personal cell phone, I set the CID for item 0 to be my cell phone number.
Each incoming CID is mapped to a SIP URI or IP address. In this way you can hard code that any incoming call from a specific cell phone rings a specific IP phone. This creates a secure, albeit inflexible, system.
You can also specify a portion of an IP address or extension with the remainder indicated by an *. This restricts the numbers you can call based upon some prefix or range of IP addresses. Dialing an IP address into the call is done using the * in place of the decimal and # to terminate the number.
For example: 192.168.1.206 = 192*168*1*206#
One alternative to dialing by IP is to use "two-stage dialing", which is like using a calling card. This mode is invoked by using * in place of the SIP URI or IP address. You first dial the number of the gateway from your cell phone. The gateway answers, then gives you a second ring tone. You then dial the number or extension you wish to call and the call completes.
Two-stage dialing is very flexible, but adds the overhead of waiting for the second dial tone and dialing extra numbers all the time. The MV-370 also provides a list of Mobile-to-LAN Speed Dials that makes this more convenient.
The ten available speed dials map a single digit to a specific SIP URI, which worked well with the hosted PBX service. Within their system, every extension and commonly-used external numbers are exposed as SIP URIs. So it was easy to add ten extensions to the speed dial table (Figure 4). Since this reduced the amount of DTMF passed to the gateway, it also made for more reliable calling.
Figure 4: MV-370 Mobile-to-Lan Speed Dial table
Since I typically call only a handful of people at our head office, the speed dials became my preferred means of access. They effectively create a single digit extension for each person on the list. To reach anyone on the speed dial list, I only had to call the gateway's cell number, pause three seconds, then dial 0-9, corresponding to the person desired.
For each person on the speed dial list, I also added a phone book entry into my cell phone. These all pointed to the same US phone number for the gateway, but with a different single digit extension after the pause.
As you can see in position #4 in Figure 4, I also set up a speed dial mapped to the SIP URI for accessing the Voice Users Conference IP conference bridge at www.talkshoe.com. In that way, I could sit in on the VUC calls from my cell, but via an IP connection. I accept that this is silly, since they also offer PSTN access. But I just did it on the principle of avoiding the PSTN where possible. Since VUC calls typically run 60-90 minutes, being able to attend using unmetered mobile-to-mobile minutes was also handy.
In Use: Cell-to-Hosted PBX
Once configured for use with OnSIP, I used the MV-370 as my principal means to call the UK from my US cell for two months. I used two-stage dialing to reach people not in the speed dial table.
The cellular signal in my office registered between 16 and 21 according to the MV-370's Mobile Status menu, which is within acceptable limits. Once connected, the call quality was as good as a typical cell call, which makes perfect sense.
I occasionally had some trouble making connections through the gateway. In the case where I had programmed a speed dial into a cell phone memory, I found that sometimes the extra digit passed to the gateway would be ignored. When this happened, I just had to manually press the digit and the call would proceed.
I suspect that this had more to do with the default duration of DTMF tones on my Blackberry 8100 than the gateway itself. Both "in-band" and "RFC2833" types of DTMF work with OnSIP if I used the G.711 codec. Switching to the low bandwidth G.729 codec forces the use of RFC2833 type DTMF.
The gateway provides a "mobile dtmf debounce" adjustment setting (Figure 5) to overcome just such trouble. By setting this to 120 ms, passing DTMF was a little more reliable.
Figure 5: DTMF debounce
There was also a little extra latency to calls placed through the gateway compared to dialing the UK directly. This makes sense, since the call is passing through significantly more processing by being bridged into the IP domain.
The effect of the added latency was not so bad as to be a problem. But it might keep me from considering such a gateway as a primary trunk. At no point did anyone I called think that I was using anything more than a direct cellular call.