Using OBi Voice Gateways with SIP Providers

[RonR]

Ever wish the OBi supported using additional SIP providers for more outbound calling options?  Ever wish you could call people on other VoIP networks directly from your OBi using Sip Broker?  Ever wish you could call people directly from your OBi using their iNum number?  Well, you can, thanks to the Voice Gateways present in the OBi.  In this example, I'll show you how to add two additional SIP providers, calling via Sip Broker, and iNum calling.

NOTE:  You must have at least one OBi Voice Service (SPx/ITSPx) configured for SIP.  If you don't wish to configure a SIP provider on an SPx/ITSPx, simply set Service Providers -> ITSPx -> SIP -> ProxyServer to 127.0.0.1 and uncheck Voice Services -> SPx -> X_RegisterEnable.  Also, the SIP providers used in Voice Gateways must allow calling without SIP registration (many do, some don't).  Sip Broker and iNum calling do not use SIP registration.

The additional calling capability is added through the use of **3, **4, **6, and **7 dialing prefixes.  [**5 cannot be used as a dialing prefix because it's hard-coded into the OBi for use by Obihai.]  In this example, **3 and **4 will be used for additional SIP providers, **6 will be used for calling via Sp Broker, and **7 will be used for iNum calling.

To begin, you'll need to make a couple of additions to your PHONE Port DigitMap and PHONE Port OutboundCallRoute to add support for the new dialing prefixes:


Phone Port DigitMap:

|**1(Msp1)|**2(Msp2)|**3(Mvg3)|**4(Mvg4)|**6(Mvg6)|**7(Mvg7)|**8(Mli)|**9(Mpp)|

PHONE Port OutboundCallRoute:

{(<**1:>(Msp1)):sp1},{(<**2:>(Msp2)):sp2},{(<**3:>(Mvg3)):vg3},{(<**4:>(Mvg4)):vg4},
{(<**6:>(Mvg6)):vg6},{(<**7:>(Mvg7)):vg7},{(<**8:>(Mli)):li},{(<**9:>(Mpp)):pp},{(Mpli):pli}


This creates the following associations:

**3 -> Voice Gateway3 (VG3)
**4 -> Voice Gateway4 (VG4)
**6 -> Voice Gateway6 (VG6)
**7 -> Voice Gateway7 (VG7)


Now, let's set up additional VoIP providers on Voice Gateway3 and Voice Gateway4.

Voice Gateway3 will be used with Whistlephone:

Name : Whistlephone
AccessNumber : SPx(proxy.whistlephone.com)
DigitMap : (Mste)
AuthUserID : your_whistlephone_user_id
AuthPassword : your_whistlephone_password


Voice Gateway4 will be used with IdeaSIP:

Name : IdeaSIP
AccessNumber : SPx(proxy.ideasip.com)
DigitMap : (Mste)
AuthUserID : your_ideasip_user_id
AuthPassword : your_ideasip_password


Next, let's configure Voice Gateway6 for calling via Sip Broker:

Name : Sip Broker
AccessNumber : SPx(sipbroker.com)
DigitMap : (<*>[x*][x*].|*[x*][x*].)


Next, let's configure Voice Gateway7 for iNum calling:

Name : iNum
AccessNumber : SPx(sip.inum.net)
DigitMap : (<8835100>xxxxxxxx|8835100xxxxxxxx)


And finally, let's configure the User Defined DigitMap referenced in Voice Gateway3 and Voice Gateway4:

Label : ste
DigitMap : (1xxxxxxxxxx|<1>[2-9]xxxxxxxxx|<1aaa>xxxxxxx|011xx.|(Mipd)|[^*]@@.'@'@@.)

where aaa is your local area code.


Following a reboot, the OBi should be ready to use its new capabilities.

Dialing **3 + number should place a PSTN call using Whistlephone.

Dialing **4 + number should place a PSTN call using IdeaSIP.

Dialing **6 + SIP code + number should place a VoIP call via Sip Broker.

For example:

Dialing **6 011 188888 should connect you with the Sip Broker test announcement.
Dialing **6 010 123456 should connect you with the Voxalot number 123456.
Dialing **6 747 17471234567 should connect you with the Gizmo5 number 1-747-123-4567.

For more details on Sip Broker, please visit : http://www.sipbroker.com/

Dialing **7 + number should place a VoIP call to an iNum number.

NOTE: Use only the last 8 digits of the iNum number (8835100 will be prepended for you).

For example:

Dialing **7 00000091 should connect you with the iNum echo test.
Dialing **7 04123456 should connect you with the Voxalot number 123456.
Dialing **7 71234567 should connect you with the Gizmo5 number 1-747-123-4567.

For more details on iNum, please visit : http://www.inum.net/

[srhuston]

I'm looking around their website, but maybe one of the gurus here knows; does Sipgate "allow calling without SIP registration"?  If so my plans for 911 capability with my OBi110 just got easier; two GV accounts setup as SP1/SP2 and Sipgate in one of the voice gateways with my E911 data registered with them (and the associated monthly fee).

[RonR]

two GV accounts setup as SP1/SP2 and Sipgate in one of the voice gateways with my E911 data registered with them (and the associated monthly fee).

You missed a major restriction the OBi developers placed on using Voice Gateways with SIP:

NOTE:  You must have at least one SIP provider already configured on the OBi using SPx/ITSPx.

Google Voice is not a SIP provider.

[oleg]

Hi RonR,

**5 cannot be used as a dialing prefix because it's hard-coded into the OBi for use by Obihai.

Could you point out where is that said / documented?


BTW, I am glad your philosophy is turning toward mine 

My general philosophy is to leave the PHONE Port DigitMap and OutboundCallRoute unmodified.  

[RonR]

**5 cannot be used as a dialing prefix because it's hard-coded into the OBi for use by Obihai.

Could you point out where is that said / documented?

Dialing **5 + number unconditionally sends number to the OBiTALK server.  You can try it yourself (no changes are necessary).  I tried to override it in the DigitMap/OutboundCallRoute, but was unsuccessful.

BTW, I am glad your philosophy is turning toward mine 

My general philosophy is to leave the PHONE Port DigitMap and OutboundCallRoute unmodified. 

I knew someone would call me out on that the instant I wrote it.   

I also said "it's generally a good idea to leave them both unmodified unless you fully understand the ramifications of changing them."  I do.   

I'm sure you understand that these 'modifications' are totally non-controversial and maintain the 1-to-1 philosophy of the default settings.

[yhfung]

RonR,

Thank you for providing these useful examples such that we can know how to use the gateway for making outbound calls without registration.

Is it possible replace SPx by PP?

（I have tried it with PP and SP1(GV), it does not work. It works with SP2( my own Asterisk server), as a result, we may request OBihai to allow us to make Voice Gateway calls via the PP)

YH

[srhuston]

You missed a major restriction the OBi developers placed on using Voice Gateways with SIP:

NOTE:  You must have at least one SIP provider already configured on the OBi using SPx/ITSPx.

Google Voice is not a SIP provider.

I know GV isn't a SIP provider.  And I wouldn't say I missed it, more like I didn't read much more into it than thinking "Oh this would be nice" when I read your initial post and wanted to get a quick clarification before I left work to head home.

This just puts me back in the idea of a second device to connect to my sipgate account all the time and plug into the LINE port of my 110.  No big deal :>

[oleg]

RonR,
I think my approach is more consistent and better fit to non-trivial routing (like in your setup above).
But I would not proceed with "philosophy" discussion  

I tried "**52008xxxxx" (with real number of another OBi110) - voice response was "the number you dialed star-star-five-two-zero-zero-eight has been sent to the server". Just that, not entire number. The records in syslog show the same (action started right after **52008) and than following:

Code Select Expand


3/29/2011 6:39:28 PM <7> OBHSN_SIGNUP:ssl connected
3/29/2011 6:39:28 PM <7> BASESSL:get common name:root.pnn.obitalk.com
3/29/2011 6:39:29 PM <7> OBHSN_SIGNUP:buflen=10087
3/29/2011 6:39:29 PM <7> OBHSN_SIGNUP:buflen=5048
3/29/2011 6:39:29 PM <7> OBHSN_SIGNUP:Sending cfg : 5048

Can you explain this?
I guess it may be one of features implemented for the troubleshooting, but it would be good if OBi mentioned it in the admin guide.

[RonR]

Can you explain this?
I guess it may be one of features implemented for the troubleshooting, but it would be good if OBi mentioned it in the admin guide.

Obihai uses this during device registration with the OBiTALK Web Portal.  I suspect they're capturing/validating/whatever the OBi's phone number/serial number/mac address/who knows for a bit of security with the Circle of Trust business.  I haven't spent any time trying to figure it out.  It appears to be hard-coded into the OBi, so I let it go as such.

[murzik]

Can you actually place a call through sipbroker or voxalot gateways?

[oleg]

**N is not the only dialing prefix. I used to have #N (e.g. '#2' rather than '**2') - it worked with Linksys adapters and works with OBi. Phone Port DigitMap and OutboundCallRoute have to be changed accordingly (just replace '**' with '#').

Someone may find it more convenient...

[RonR]

**N is not the only dialing prefix. I used to have #N (e.g. '#2' rather than '**2') - it worked with Linksys adapters and works with OBi. Phone Port DigitMap and OutboundCallRoute have to be changed accordingly (just replace '**' with '#').

Someone may find it more convenient...

Of course.  That's one of the nice things about the PHONE Port DigitMap/OutboundCallRoute processing scheme - you can throw the current one's out the window and make up a totally new dialing syntax if you wish.

[RonR]

Can you actually place a call through sipbroker or voxalot gateways?

If you mean a free call to a PSTN phone, the answer is no.  You can, however, place free calls to others whose service provider peers with Sip Broker.

[murzik]

Can you actually place a call through sipbroker or voxalot gateways?

If you mean a free call to a PSTN phone, the answer is no.  You can, however, place free calls to others whose service provider peers with Sip Broker.

What I meant if sipborker and voxalot are work for you, because what I get is just one way audio.
Especially calling any peers through sipbroker.

[oleg]

I believe the reason is that OBi110 build 2101 does NOT use STUN for outgoing SIP calls via alternative providers (only use STUN for the provider configured in corresponding SPx service). In other words OBi110 sends your local IP:port in RTP stream information.

For most of us OBi adapter is located on local network behind NAT. Some destinations are smart enough to recognize local IP sent by OBi, disregard it and try to send RTP just in opposite direction (to the same IP/port where your voice stream comes from). Often this works, sometimes not...

Build 1892 used STUN in the same situation. I've suggested developers to re-think STUN usage decision, waiting for response...

P.S. Please let me know if someone needs more details / explanations.

[RonR]

What I meant if sipborker and voxalot are work for you, because what I get is just one way audio.
Especially calling any peers through sipbroker.

I agree with oleg that it's a NAT/RTP issue.  I haven't had any problems so far, but I also forward all applicable SIP and RTP ports to the appropriate devices as well as use a STUN server whenever possible.  VoIP audio is a problem waiting to happen when NAT is involved with SIP/RTP.

A good test to see if your router is possibly the culprit is to simply bypass it, if possible.  Connect the OBi directly to your Cable/DSL modem and see if your audio issues go away.  If they do, your router is definitely a suspect.  Make sure you reboot both devices after connecting them directly to each other.

[JohnLennon]

Great solution!

[oleg]

A good test to see if your router is possibly the culprit is to simply bypass it, if possible.  Connect the OBi directly to your Cable/DSL modem and see if your audio issues go away.  If they do, your router is definitely a suspect.

Bypassing router you eliminate NAT and thus the need in STUN detection. Audio issues may go away. But how it makes "router a suspect" That only proves that router has NAT inside and that router separates local network from the internet. Anybody doubts?  
Normally it is responsibility of SIP device to detect internet address / port and send them to another SIP device. STUN protocol serves that purpose. Routers usually do not care about SIP protocol.

There are a few rare exceptions though:
- some NAT implementations may be practically impossible to traverse even using STUN.
- some rare routers (VOIP routers, SIP proxies) may recognize SIP protocol and substitute local address / port with internet address / port.

[RonR]

Audio issues may go away. But how it makes "router a suspect"

The very first paragraph of the article linked below does a much better job of describing the problem than I ever could:

"The very first thing to note is that SIP was NOT designed to work with NAT. There are subsequent standards, hacks, workaround, kludges etc. to try and make it work but the original SIP designers somehow deemed it beneath them or put it in the too hard basket to bother coming up with a proper solution (there is not one instance of the string "NAT" in the whole SIP RFC)."

http://sipsorcery.wordpress.com/2009/08/05/nat-rtp-and-audio-problems/

If taking your router of the loop eliminates your audio issues, there's an excellent chance your router has a NAT implementation that's not SIP/RTP friendly.  I've got a number of older routers in the store room that fit that description.  Newer routers tend to do a lot better job, but they're still not all created equal and depending on the service provider's SIP implementation, one router may work in a particular situation  but not in another.  IOW, it's a crap shoot.

[oleg]

Indeed, SIP was not designed to work with NAT. But most contemporary SIP implementations (including all Linksys ATAs) use STUN and successfully traverse most NATs.

Try another experiment - replace OBi110 build 2101 with build 1892, make sure STUN enabled and configured. There is an excellent chance that audio issues go away with the same router (unless router belongs to first of two exceptions I mentioned above). According to your logic that proves OBi110 build 2101 "is definitely a suspect". Here I agree with you