Tutorial / Guide - Obi202 with Obiline As FXO For An IP Phone

[Usetheforceobiwan]

I set up my 202/Obiline combo to act as an (additional) FXO for my Gigaset C610IP IP phone.  The C610IP has a built in FXO which I use for POTS home phone service.  I connected the 202-Obiline combo to my 610 to add Skype calling via a Freetalk adapter plugged into the Obiline.   I can also use the 202 to add three Google Voice lines to the 610.  On the C610 side, the connection to the 202 appears in the ITSP list of ways to dial out like any other SIP trunk.  Incoming calls to the Obiline are routed conventionally and ring the 610 extensions like any other incoming SIP call.  Caller ID works normally BTW.  

The basis of my setup is from the Obihai blog post here:  http://blog.obihai.com/2012/08/use-your-obi202-as-google-voice-gateway.html .  As you will see below, I used this as a guide but my setup differs somewhat.  What makes this and my setup work with the 202 (and not with the 110 unfortunately) is that it has a built in proxy server that allows you to pseudo register an IP phone as an SP.   Note that per the blog post, you could use this scheme with some dial plan modification to connect an IP phone to the Obi to allow Google Voice calling on the three other SP's as well as using it as an FXO as I am here, at the same time.

On the 202/Obiline side, starting from a default SP1, my settings differ from the defaults as follows:

ITSP A Profile - SIP

ProxyServer:  127.0.0.1
RegistarServerPort:  5060
OutboundProxyPort:  5060
SpoofCallerID:  Checked (enabled)
UseRefer:  Checked (enabled)
MWISubscribe:  Checked (enabled)

SP1 Service

InboundCallRoute:  Li
RegisterEnable:  Unchecked (disabled)
KeepAliveServerPort:  5060
UserAgentPort:  5060
Proxy:  Checked (enabled)
AuthUserName:  A user ID I created
AuthPassword:  A random password I generated by blindly typing on the keyboard .  Type it out in Notepad so you can copy and paste it to the IP phones provisioning setup area as well.
MaxSessions:  10 <<< This could probably be 4 but 10 isn't hurting anything
MWIEnable:  Checked
MWIEnable2:  Checked
VMXIEnable:  Checked (enabled)
VMWIEnable2:  Checked (enabled)
AnonymousCallEnable:  Unchecked (disabled)

Physical Interfaces, Line Port

InboundCallRoute:  {SP1(AuthUserName from above @ LAN IpAddress of IP Phone),ph,ph2}
                   Example:  {SP1(RumpleStillSkin@192.168.1.10),ph,ph2}
OutboundCallConfirmTone:  Checked (enabled)
ChannelTxGain:  2   << Change yours if too loud or soft
ChannelRxGain:  7   << Change yours if too loud or soft

For the C610IP Service Provider Setup screen, I entered the following:

Authentication name:  AuthUserName I created in the Obi
Authentication password:  AuthPassword I created in the Obi
Username:  AuthUserName I created in the Obi
Domain:  IP address of the Obi202 on my LAN
Proxy server address:  IP address of the Obi202 on my LAN
Proxy server port:  5060
Registration server:  IP address of the Obi202 on my LAN
Registration server port:  5060
Registration refresh time:  180 sec
Stun enabled:  No
Outbound proxy mode:  Always
Outbound server address:  IP address of the Obi202 on my LAN
Outbound proxy port:  5060

So with this setup, outbound calling from the C610 works like any other Voip provider, the difference is that it is routed through the Obi202 to the Obiline and goes out as a POTS type call.  Incoming works conventionally too, the calls get routed from the Obiline through the 202 and ring my C610 handset and appear as a VOIP call.  In the C610 ITSP status screen, the trunk to the 202 shows up as "Registered".  In the Obi202 SP1 status area, the trunk to the IP phone says "Registration Not Required;local_client=IP address of IP phone:5060".

Again, I have not tried this with other IP phones but seeing as how the Gigaset IP phones are not known as the most flexible or friendly to unconventional setups, I would assume it would work with Ciscos, Panasonics and the like.

[Usetheforceobiwan]

So after all the work of figuring out my own solution, I came across this Obihai document recently which I had never seen anywhere.  Figures.  While really applicable to ObiPlus but relevant to normal Obi usage, here is Obihai's guide to what I outlined above:

http://www.obihai.com/docs/OBi-VoIP-Device-Attach-Legacy-IP-Phone-Workbook-v1-0.pdf

I am glad I found this however as it inspired me to create a voice gateway in my 202 which I use to dial out a Google Voice call through my Obi110 via Obitalk via the two GV connections I have on the 110.  Works really well, the only thing I wish were a little different is that when the IP phone rings on an incoming GV call that I could identify which GV line it came in on.  It can probably be done, I just haven't figured it out yet.

Edit 6-29-14:  I thought I would post my InboundCallRoute for SP1 which shows how outgoing calls from the IP phone get directed depending on how dialing is prepended with a code, a series of which I set up in the IP phone to be able to dial and pass on to the Obi202:

{AuthUserName>(<1*:>(@@.)):li},{AuthUserName>(<2*:>(@@.)):vg1},{AuthUserName>(<3*:>(@@.)):vg2},{AuthUserName>(<4*:>(@@.)):vg3},{AuthUserName>(<5*:>(@@.)):vg4},{AuthUserName>(<6*:>(@@.)):vg5}, {AuthUserName>(@@.):sp4}

What does this InboundCallRoute mean?  What it basically does is the Obi looks at the SIP stream that is output from the IP Phone when you dial and looks for your AuthUserName (whatever you made it to be) and if it detects that, it first checks to see if you have prepended the dialing codes with a 1*,2*,3*, etc. and if it sees that then it directs it to the various trunks as noted above.   The purpose of the (@@.) is to tell the Obi that if the sip call includes dialing instructions (Note: (@@.) is a wild card dial stream that can include just about anything) after the 1*,2*, etc. then it is to pass those on to the bridged destination having deleted the 1*,2*, etc before passing the rest of the dialing stream forward.  Note that the bridged destination's dial plan must be able to accept your dialing instructions as passed on as this is the only way the bridged call can go through.   Also note the last instruction which does not look for a prepended x* code, it merely looks for a dial out so it sends these types directly to the SP or VG you tell it to.

BTW, after reading this document, I now know what Mark from Obihai was referring to in the VUC conference a couple months ago when he said you could hide an Obi in a Cisco phone base.