News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Possible to use OBi110 to as an FXO port on an Asterisk server?

Started by MichiganTelephone, January 22, 2011, 04:14:15 PM

Previous topic - Next topic

MichiganTelephone

I'm just wondering if there is any documentation, or perhaps an article somewhere, that explains how to use an OBi110 as an interface to a PSTN line for an Asterisk PBX.  I know it can be done with the old Sipura/Linksys 3000/3102's and I figure if those devices can do it the OBi110 ought to be able to do it also (if you wonder how it's done with those devices see http://www.freepbx.org/support/documentation/howtos/howto-linksys-spa-3102-sipura-spa-3000-freepbx ).  The main thing is to make the device appear as a SIP trunk from a provider as far as Asterisk is concerned.  If anyone can point me in the direction of a document or article that might give me some clues as to how to do this I'd much appreciate it.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

OBi-Guru

Yes, register the SP1 to the asterisk as a normal SIP client.
Then work on the call route to send calls in/out of SP1 directly to the FXO line (Li)

Go the device webpage -> wizard ->

ITSP inbound callroute = Li    --> this will off hook the FXO line and the dial tone will be passed on to the SP1, the user will then dial the digits out directly to the PSTN line.

PSTN inbound callroute = sp   --> sp by default means sp1


OBi-Guru

Here is an outline on how to interface with an IP PBX such as Asterisk (requires OBi firmware version 1.1 or later).
1.   You can use either SP1 or SP2 to interface with Asterisk. Let's use SP1 as an example
2.   Assign a userid (AuthUserName parameter) to SP1, such as 1000 (or anything that Asterisk admin desires).
       a.   Asterisk MUST be set up to recognize this extension as the "gateway".
       b.   You may also assign AuthPassword if Asterisk wants to challenge the INVITE from OBi
3.   Set up SP1 to use ITSP Profile A, with
       a.   Proxy = IP address (or domain name) of the Asterisk server
       b.   X_SpoofCallerID checked (parameter under ITSP Profile – SIP section). This tells the OBi to use the original (PSTN) caller's Caller ID in the FROM header of the INVITE sent to Asterisk for incoming calls from PSTN.
4.   SP1 may REGISTER to Asterisk; or can use static config on Asterisk, whichever appropriate
5.   Set SP1 - InboundCallRoute = LI
       a.   This rule tells OBi to send all incoming calls (from Asterisk in this case) to the PSTN PORT
       b.   The number-to-dial will be taken from the incoming INVITE's request-URI (assuming this is what Asterisk do when talking to a gateway)
       c.   Note: Under LINE Port – you can fine tune DialDelay, DialDigitOnTime, DialDigitOffTime, DTMFPlaybacklevel parameters, if needed. The default should just work with most PSTN services
       d.   NOTE: OBi SP1 does not challenge inbound INVITE. However you can setup a list of trusted IP addresses in the X_AccessList paramete (under ITSP Profile – SIP) to limit who can send SIP messages to the OBi SP1. Usually the gateway (OBi) and asterisk machines are in the same subnet; normally not a big issue
6.   Set LINE Port - InboundCallRoute = SP1(2000)
       a.   This rule tells OBi to route all incoming calls from PSTN to the extension 2000 (as an example)
       b.   2000 may be a real extension; OR an extension that the Asterisk will intercept to perform more processing, such as hunting, voicemail, etc.
       c.   Since SP1 has the CID spoofing option on, the FROM header will carry the caller-id detected on the PSTN line
       d.   By default OBi waits for 5.5s (LINE Port – RingDelay parameter) after initial PSTN ring detection before calling out on SP1, to make sure it can completely decode the CID first. You can try to reduce it for your own PSTN service.
7.   To track the status of the LINE port, Asterisk can SUBSCRIBE to the x-line-port-status event pacakage to check if the LINE is available to make new call. This is a proprietary event package so some new code may be needed on the Asterisk to handle it properly. OBi will NOTIFY the subscriber when the status of the LINE port changes, with one of the following states:
       a.   onhook
       b.   line in use         (being used by a parallel handset)
       c.   ringing
       d.   offhook
       e.   pwr down          (no LINE voltage)
8.   Asterisk can also SUBSCRIBE to the dialog event package on OBi SP1 trunk. This is a standard event package, which tells the subscriber all the SIP call status on SP1 trunk, which indirectly indicates the status of the LINE port in this case
9.   If you need more PSTN lines, you can setup more OBi devices like this; just assign a different AuthUserName (userid) to each SP1 interface, such as 1000, 1001, 1002, 1003, etc.

Note that the InboundCallRoute parameter supports a rich syntax that can do more than what is outlined here. Please refer to our admin guide for more details.

MichiganTelephone

Thank you very much for clarifying this.  I removed an earlier post where I had made several incorrect assumptions (I didn't want to confuse anyone who might find this thread).  You might want to make this post sticky, or copy it to a document in your documents section so that those who need it can find it.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

MichiganTelephone

#4
I've added to my review series on the OBi110:

Review of the Obihai OBi110 VoIP device, Part 4: How to use the OBi110 as an FXO port with Asterisk and FreePBX

This should especially help any FreePBX users that are visiting this thread.

EDIT:  I just want to make an additional observation.  Although I've not attempted to go quite this far yet, I believe there's absolutely no reason you could not use the SAME OBi110 device as both an FXO port with Asterisk, and as a gateway between Asterisk/FreePBX and Google Voice and/or the OBiTALK network.  In theory, you could create ONE Asterisk trunk (on SP2) and route calls to it from THREE sources: A PSTN line connected to the LINE port, the OBiTALK network, and Google Voice or whatever other service you may have on SP1.  Outgoing calls could be directed to any of those services by using digit maps (or possibly adding a prefix in Asterisk that the OBi would recognize for routing purposes and then strip off) and you could even still use the PHONE port as an Asterisk extension by piggybacking it on the trunk connection.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

Ad_Hominem

I've revised the guide and reposted it below.

MichiganTelephone

#6
Quote from: Ad_Hominem on April 10, 2011, 07:41:53 PM
P.S.  I've been in touch with Obi am going to update my instructions to:

1.  Allow use of the FXO port for inbound and outbound calls.
2.  Allow use of Google Voice for outbound and inbounc calls.
3.  Allow use of the FXS port as a FreePBX extension.

and I think I can get it working all at the same time!!

I am 100% sure you can, I'm just not sure why you are reinventing the wheel.  All of what you're wanting to do has pretty much been covered in one or more of these articles (or in the comments underneath the third article mentioned below):

Review of the Obihai OBi110 VoIP device, Part 4: How to use the OBi110 as an FXO port with Asterisk and FreePBX

How to use the Obihai OBi100 or OBi110 VoIP device as a gateway between Asterisk/FreePBX and Google Voice and/or the OBiTALK network

How to use the Obihai OBi100 or OBi110 VoIP device as a gateway between Asterisk/FreePBX and Google Voice and/or the OBiTALK network — Part 2: Using the Phone port as an Asterisk extension

EDIT: About a year after originally posting this message, I've developed another method of doing this that I believe is easier to implement and meets all the desires mentioned in this message — see How to use the Obihai OBi100, OBi110, or OBi202 VoIP device as a gateway between Asterisk/F—PBX and Google Voice and/or the OBiTALK network (UPDATED) (END EDIT)

I've actually been meaning (for about two months now) to write yet another article showing how to do this, but this time using the OBi Expert Configuration mode of the OBiTALK portal to set it up. But every time I have thought about it, either something more pressing came along or I ran up against some bug (such as the OBiTALK portal changing > characters to > before sending them to the device — I'm hoping maybe they'll fix that today, since I probably reported it after everyone had gone home on Friday night).

You said you wanted to:

1.  Allow use of the FXO port for inbound and outbound calls.

That's simple enough...

2.  Allow use of Google Voice for outbound and inbound calls.

Also simple... you can put that on SP1

3.  Allow use of the FXS port as a FreePBX extension.

This is where it gets just a little tricky.  You can use SP2 to connect to your FreePBX/Asterisk server, but normally you'll need to have that as a trunk connection if you want your device to act as a gateway for your Asterisk box, which leaves no open slots for an extension connection.  But by using a Custom extension in FreePBX, as described in the third article above, you can "piggyback" the extension connection onto the trunk connection and put both on SP2 (it may also be possible to do some tricky stuff using one of the Voice Gateways; I haven't really explored the possibilities there, since you can only place outgoing calls through a Voice Gateway).

And you can do one other thing:

4.  Allow use of the OBiTALK network for outbound and inbound calls.

...because the OBiTALK network is treated as yet another service that's available for use, in addition to Google Voice on SP1 and the PSTN or similar line coming into the Line port.

As I have said before, it amazes me how flexible these units are and how they can be used for call routing in ways the developers may not even have thought of.  And if you understand Voice Gateways, that probably opens up even more possibilities for connections, as long as they are outgoing only (while that might be of only limited usefulness if you have a FreePBX/Asterisk server, they could be useful in certain circumstances such as getting around geographic IP blocking).
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

Ad_Hominem

Michigan,

Yes, actually I used your guides as a starting point.  However, I didn't like your method for several reasons.

1.  Your guide suggests using the phone number as the trunk name and SIP Username.  I found that doing so causes problems if you call in on another trunk and your CID is the trunk #.  You end up getting a disconnect recording.  Not sure why.  I found that if you change that from the phone # to OBITRUNK1, everything works as it should.

2.  Your guide includes parameters that don't seem to be essential making the thing work.  The user parameters, for example, are unnecessary.

3.  Your guides are awfully long.  I'm trying to condense the steps down into a very short guide.

4.  I didn't see that your guides allowed easily routing calls to and from both Google Voice and the line port.  As I recall, it was an either/or situation.  I'm working on coming up with something that allows you to do both, i.e. to route calls to the line port or Google Voice, based upon what number you dial.

As you'll see, what I've come up with fulfills that function.  You can dial 81 to get the line port, 85 to get Google Voice, or dial regularly and route according to some default rules.

Ad_Hominem

Revised:  4/11/2011

I've got the Obi 110 working with FreePBX and Google Voice.  Using this set-up, I can dial calls from a PBX phone normally, and have them routed to either the Line Port or Google Voice.  By default, these instructions will route ordinary calls (seven digit, ten digit, and eleven digit calls) to Google Voice and 911 calls to the line port.  Optionally, users can dial 81 to force calls to the Line Port, or 85 to force calls to Google Voice.  You can easily modify these instructions to meet your needs.

My thanks to MichiganTelephoneBlog, to Obi Tech Support, and to FreePBX's page on configuring the SPA3102, all of which I used in order to develop these instructions.

Here's my set-up:

Obi 110 Web Interface Settings

System Management – Auto Provisioning
Method: Disable

To Use Google Voice to Place and Receive Calls (If you aren't going to use Google Voice, skip down to the "To Use the Line Port" section)

ITSP Profile A- General-
Name:  Google Voice
Signaling Protocol:  Google Voice
X_UseFixedDurationRFC2833DTMF:  Checked

SP1 Service- SIP Credentials
X_InboundCallRoute:  SP2(2120000000)    (Replace 2120000000 with your Google Voice #)
AuthUserName:  yourgmailaddress@gmail.com
AuthPassword:  YourGmailPassword

To Use the Line Port to Place and Receive Calls

Service Providers – ITSP Profile B – SIP
Proxy Server:  192.168.1.50 (REPLACE 192.168.1.50 WITH YOUR PBX IP ADDRESS)
RegisterExpires=300
X_SpoofCallerID:  Checked
X_AccessList:  192.168.1.50 (REPLACE 192.168.1.50 WITH YOUR PBX IP ADDRESS)

Voice Services – SP2 Service

X-ServProvProfile:  B
X_CodecProfile:  B
X_InboundCallRoute:  (You have two choices here)

To route all outgoing calls from your FreePBX to the Phone Line port, use this:

LI

If you'd like to be able to be able to easily select between both Google Voice and the phone port, you can use this:

{>(<85:>xx.):sp1}, {>(<81:>x.):li}

This parameter will route calls that begin with 85 to Google Voice, and will strip the 85 off the number before sending the call to Google Voice.  All calls that start with 81 will go to the phone line, and the 81 will be stripped off.  If you are going to use this method, you'll need to set up your outbound routes and trunks so that numbers are always prefixed.  I'll discuss that below.

X_KeepAliveEnable:  Checked

SIP Credentials:

AuthUserName: OBITRUNK1  (DO NOT MAKE THE USERNAME THE SAME AS YOUR PHONE NUMBER!!)
AutPassword:  PASSWORD   (Replace PASSWORD with a password of your choice)

URI:  OBITRUNK1@192.168.1.50  (Replace 192.168.1.50 with your PBX Address)

Physical Interfaces – Line Port
InboundCallRoute:  SP2(2125551212)   (Replace 2125551212 with your phone number)
RingDelay:  3500  (0 if you don't have Caller ID, longer if you sometimes get no Caller ID on incoming calls)
DialDigitOnTime:  100  (you can lower this to get calls to go out faster)
DialDigitOffTime:  100 (you can lower this to get calls to go out faster)
SilenceTimeThreshold:  600 (you can change this if you want Obi to disconnect calls quicker after xx seconds of silence)

FreePBX/Trixbox Configuration

Trunk Configuration:

Trunk Description:  OBITrunk1
Outbound Caller ID:  2125551212 (Replace 2125551212 with the phone number of the line plugged into your OBI 110)
CID Options:  Allow Any CID
Maximum Channels:   2

(for now, use 2.  If Obi patches the firmware, you may be able to delete this.  If the Line port is in use, Obi sends an asterisk friendly response that tells Asterisk that the channel is in use and Asterisk will try another route.  However, if Google Voice is busy (which happens after 2 outbound calls), Obi appears to still send 486/Line Busy, and Asterisk delivers a busy signal.  If they change the Google Voice busy issue to make it work as the Phone Port does, then you could leave this blank).

Dialed Number Manipulation Rules:

81911+911|
81911+81911|
8512125555555+85911|   (replace 2125555555 with your local police department #)
8518005558355+411|
8118005558355+81411|
8518005558355+85411|
85+|1XXXXXXXXXX
851+|XXXXXXXXXX
851212+|XXXXXXX
811+81|XXXXXXXXXX
811212+81|XXXXXXX
851+85|XXXXXXXXXX
851212+85|XXXXXXX

Replace 212 in the above examples with your area code.

The above is where all the call routing happens.  If you chose to configure X_InboundCallRoute for SP2 as {>(<85:>xx.):sp1},{>(<81:>x.):li} instead of LI, then your FreePBX needs to prefix every dialed number with either 81 (to indicate that the call will go to the Line Port) or 85 (to indicate that the call is going out on Google Voice's service.  The routes above do so.  If you chose to go with LI only, you can use a more traditional set of Dialed Number Manipulation Rules instead of these.

The first three lines in the rules above handle 911 calls.  A call to 911 without a prefix gets converted to 81911, which Obi then sends to the Line port.  A call to 81911 doesn't get changed at all (you could actually remove this line, but I left it in for completeness).  A call to 85911 gets changed to your local police department number and sent on Google Voice. 

The next three lines handle 411 calls in a similar fashion, except by sending them to TELL ME.  You can substitute your own Free 411 service if you prefer.

The next three lines handle calls that are dialed without a prefix, by adding 85 to them so that Obi will send the calls out on the Google Voice line.  If you prefer these calls to go out on the Phone port, change 85 to 81 in these lines.

The next two lines handle calls that are dialed with an 81 prefix, but without the 1 or without the area code.  The 1 or 1+Area Code are added and then the call is passed on to the Obi with an 81 prefix to indicate that the call is going out on the Line Port.  And the final two lines handle calls that are dialed with an 85 prefix in the same way.

Trunk Name:  OBITRUNK1 

Note:  This must match AuthUserName and words before @ in URI in OBI device.  DON'T USE TEN DIGIT # here, or inbound calls from that number to other trunks will fail.

Peer Details:

username=OBITRUNK1  (must match Trunk Name, above)
type=friend
secret=PASSWORD (replace PASSWORD with your selected password)
disallow=all
allow=ulaw
qualify=yes
host=dynamic
dtmfmode=rfc2833
canreinvite=no

FreePBX Inbound Routes:

DID Number:  2125551212    (Replace 2125551212 with the phone number of the line attached to the Line Port).  Have it route wherever you want

DID Number:  2120000000    (Replace 2120000000 with your Google Voice Number).
Have it route wherever you want

Set-up your outbound routes as follows:

Route Name:  Emergency
Dial Patterns:
911

Trunk Sequence:   ObiTrunk1

Route Name:  X11
Dial Patterns
N11

Trunk Sequence:   ObiTrunk1

Route Name:  81DialsOBITRUNK1
Music On Hold?  None
Dial Patterns:
811NXXNXXXXXX
81NXXNXXXXXX
81NXXXXXX
81X11
81011.
81

Trunk Sequence:   ObiTrunk1

Route Name:  85DialsGoogleVoice
Music On Hold?  None
Dial Patterns:
851NXXNXXXXXX
85NXXNXXXXXX
85NXXXXXX
85X11
85011.

Trunk Sequence:   ObiTrunk1

Route Name:  Normal
Music On Hold?  None
Dial Patterns:
1NXXNXXXXXX
NXXNXXXXXX
NXXXXXX
X11
011.

Trunk Sequence:  Obitrunk1

Note:  I've broken down the outbound routes into separate parts because I often choose to send 911 calls, 411 calls, etc. to different trunks.  If you only use an OBI device and no others, you could easily combine some of these into a single outbound route.  Also, if you choose to use the LI setting for X_InboundCallRoute, then you can greatly simplify the outbound routes used in FreePBX.

MichiganTelephone

#9
Quote from: Ad_Hominem on April 11, 2011, 12:25:33 PM
Michigan,

Yes, actually I used your guides as a starting point.  However, I didn't like your method for several reasons.

1.  Your guide suggests using the phone number as the trunk name and SIP Username.  I found that doing so causes problems if you call in on another trunk and your CID is the trunk #.  You end up getting a disconnect recording.  Not sure why.  I found that if you change that from the phone # to OBITRUNK1, everything works as it should.

I was not aware of that, and sort of wish you'd posted a comment to that effect.

Quote from: Ad_Hominem on April 11, 2011, 12:25:33 PM2.  Your guide includes parameters that don't seem to be essential making the thing work.  The user parameters, for example, are unnecessary.

The falls into the category of "there's more than one way to skin a cat" (why anyone would want to skin a cat, I have no idea).  :) I found that I had no luck making it work without using the user parameters, but that's not to say it can't be done, and in fact a user named "Martin" left a comment under the first of the articles I posted and said that he did it.

Quote from: Ad_Hominem on April 11, 2011, 12:25:33 PM3.  Your guides are awfully long.  I'm trying to condense the steps down into a very short guide.

My philosophy is to try to give people all the information they need to accomplish something, including (where I think it's helpful and it's not too much trouble) screen shots.  I have muddled through too many sets of written instructions where the author tried to keep things concise, only to find that in doing so he makes some huge assumptions about what the reader already knows.  I realize you have to assume some prior knowledge in any technical article (for example, I assume that readers of those articles already know the basics of how to set up a FreePBX trunk, and how to use inbound and outbound routes to route their calls in FreePBX).  I tend to assume that others may have as much trouble as I do following someone else's instructions, so I try to write for clarity rather than brevity.  Whether I am successful in that endeavor I will leave up to the readers, but I've never took a writing class in my life (not since high school, anyway) so I'm probably going to make a few mistakes along the way.

I wrote those articles back in January and February, and it took me a lot of experimentation to get everything working. And once I did, I just wanted to publish what had worked for me.  Was the method I used perfect?  Probably not.  But then, I sort of doubt anyone's is.  I really do appreciate it when people leave a comment showing how something I've written can be improved upon.

Now, since we are talking about what we dislike about other people's methods, what I don't like about yours is the use of prefixes that the user is forced to dial. Or at least I think that's the case, because you really aren't explaining what you're doing here, you just sort of jump into using prefixes of 81 or 85 without really explaining why.  My philosophy is that users of a FreePBX system should never have to dial route selection codes — the PBX should be making those decisions for them.  The user should only need to dial the number they want to call, period, and FreePBX should route the call correctly.  I'm looking at your instructions and I do not have the foggiest clue what the heck you are doing, so if my assumption that the user has to dial those prefixes is wrong, it's because I really do not understand much of anything about your method based on what you have written.  Maybe I'm too verbose sometimes, but I'll take my form of instructions over yours any day of the week.  At least I hope that people can actually understand what I've written and and follow along, without having to do a huge amount of guessing and head scratching along the way.

That said, to each his own - maybe some folks will prefer your way, assuming they can actually figure it out.  ::)

EDIT: I wrote the above two paragraphs before you did your edits, which do make my criticism moot. I'm still pretty sure I wouldn't do things exactly as you have, but at least now I have a somewhat better understanding of what you are trying to do and how you are going about it.  So, thanks for the revision — I'm sure it will be helpful to those who wish to give your method a try.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

Ad_Hominem

First, let me say that I LOVE your blog.  I read it everyday.  And you and I agree on a lot (including the political stuff).  Keep up the good work!  I've found half the answers that I need on your blog alone.  :)

I also liked your guides a lot, but they didn't quite do what I'm trying to do, which is to allow FreePBX to route outbound calls to EITHER Google Voice or the FXO port, depending upon the number you're dialing.  Since I've got it mostly working, I, like you, want to share how I got it working with anyone else, to save them the trouble.  I do not intend my efforts to be critical of yours.  To the contrary, I started with your instructions and I believe that I've made some improvements, and so I want to share them with the world, just as you did.  :)

My method does not require the dialing of a prefix.  By default, what I've posted (now) allows users to simply dial a number, and reach the destination programmed by the person setting up the PBX.  If you follow my instructions, 911 goes to the Line Port, and other calls go to Google Voice, but you could change it however you like by modifying the Dialed Number Manipulation Rules in the ObiTrunk1 trunk settings.

It is true that I've also allowed users to dial 81 to reach the line port and 85 to reach Google Voice, but those are options.  In looking at my instructions, you can easily remove those options if you like, simply by modifying the Dialed Number Manipulation Rules in the ObiTrunk1 trunk settings.

I understand that it is confusing.  There's no easy way to tell the Obi 110 which way to send a call, i.e. to the line port or to Google Voice.  Originally, I wrote instructions that made using the Line Port the default route (so that 911 calls dialed without a prefix would go there), but that was unsatisfactory since the vast majority of calls aren't to 911, and most people would prefer to dial them without a prefix.  So, I ultimately changed the instructions so that all calls routed to the Obi must be prefixed, but FreePBX handles the prefixing in the trunk rules.  So, as it is now, you can just dial if you want, and the calls will go out. 

One of my philosophies is that more information is better, and the best written instructions will give the user sufficient information to modify the instructions to meet their needs.  As currently written, my instructions make it pretty easy to delete the parts that you don't need.

If fairness to you, I've been revising my instructions all afternoon, so your comments may have been based upon an earlier version.  :)



Ad_Hominem

If you come up with an easier way of routing some calls to Google Voice and some calls to the Line port, let me know, and I'll try to work on it. :)

Also, please feel free to steal all of this and use it in your future modifications.  As I said, I've built on a lot of your blog here.  I do plan to add the instructions on getting the FXS port working, and that's going to come straight from your blog, with little (if any modifications).

MichiganTelephone

Quote from: Ad_Hominem on April 11, 2011, 04:10:01 PM
First, let me say that I LOVE your blog.  I read it everyday.  And you and I agree on a lot (including the political stuff).  Keep up the good work!  I've found half the answers that I need on your blog alone.  

I also liked your guides a lot, but they didn't quite do what I'm trying to do, which is to allow FreePBX to route outbound calls to EITHER Google Voice or the FXO port, depending upon the number you're dialing.  Since I've got it mostly working, I, like you, want to share how I got it working with anyone else, to save them the trouble.  I do not intend my efforts to be critical of yours.  To the contrary, I started with your instructions and I believe that I've made some improvements, and so I want to share them with the world, just as you did.  :)

My method does not require the dialing of a prefix.  By default, what I've posted (now) allows users to simply dial a number, and reach the destination programmed by the person setting up the PBX.  If you follow my instructions, 911 goes to the Line Port, and other calls go to Google Voice, but you could change it however you like by modifying the Dialed Number Manipulation Rules in the ObiTrunk1 trunk settings.

It is true that I've also allowed users to dial 81 to reach the line port and 85 to reach Google Voice, but those are options.  In looking at my instructions, you can easily remove those options if you like, simply by modifying the Dialed Number Manipulation Rules in the ObiTrunk1 trunk settings.

If fairness to you, I've been revising my instructions all afternoon, so your comments may have been based upon an earlier version.  

They were, and I added an edit to my post above to reflect that.  My original criticism is no longer valid with your new edits, and I appreciate the work you've done in documenting this.  And, it's fair enough that if my instructions didn't do what you wanted, you should revise them and make them work the way you want.  I'm certainly not trying to discourage anyone from improving upon a posted method, be it mine or anyone else's — that's the only way we make progress.

I'm sorry if I came off a bit thin-skinned but it sometimes gets to me when I put a lot of effort into trying to make something as clear as possible and then get criticized for in effect being too verbose.  It's like one of those "can't win" situations.  Some people appreciate brevity, and then there are people (and I'm one of them) that just hates trying to follow someone else's instructions when they don't explain what they're doing, and it's not immediately obvious.  But be that as it may, you have really fleshed out your original post, so now it actually makes sense.  And I would encourage you to add or revise further if you find a better way to do things.

The more people we have that understand this stuff and share what they know, the better.  Thank you for sharing what you've done here, it may be just the solution that some folks are looking for.

As for the routing, the only thing I might have done differently is use a prefix that would not conflict with any dialable number.  For example, if you have a local exchange of 852, and you also use 85 as a dialable prefix, then you either have to introduce unnecessary delays or forgo 7 or 10 digit dialing.  For internal routing (things no one has to actually dial) I like to use prefixes starting with 0000, because in the USA there's no reason anyone would have to dial that, or if I really want to forbid people from dialing it directly then I might even use **** followed by a number (which both an Obihai and a Linksys/Sipura device would intercept).  If I do want folks to be able to dial it, then I might use a 11x or 10x code since again those codes would not conflict with any 7, 10, or 11 digit number.  But, those are just my personal preferences.

And, if it helps at any point, you may feel free to quote anything from my blog (with attribution, please) rather than having to try and re-word it.  As long as people don't take what I've written and repost entire articles, or fail to give proper attribution, I'm not too concerned about folks re-using what I've written.  And I'll keep your offer in mind if I ever get around to rewriting and consolidating those articles (I really do hope to do it someday in the not too far distant future).

Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

Ad_Hominem

Michigan,

My comments about your verbosity was not intended to sound negative.  I think its good to have both a verbose description of how things work and a concise description.  I like your idea of having a different internal routing system, and so I may revise the instructions later to adopt that.  I haven't quoted anything from your blog as of yet.  I did read and internalize all the articles you've written about the Obi 110, and then tried to harmonize and simplify what I read from the FreePBX.com article on configuring the SPA3102.  I then deleted as much as I could and tested and re-tested. 

As a result, I apparently found a bug in the Obi 110 firmware which causes it to randomly reboot when making an outgoing call on the FXO.  Obi Tech support was good enough to duplicate my setup, duplicate the problem, and create a fix.  It's not out yet, but it will be in a few weeks.

You make the point that there could be conflicts in routing with 7 digit diailing if I use 85 or 81 as a prefix.  Given how I've set it up, I can't see how.  Could look through the routes and the trunk rules that I've set up and see if there's any actual 7 or 10 digit number you could dial that would be misconstrued?  I'd appreciate it.

MichiganTelephone

Quote from: Ad_Hominem on April 11, 2011, 07:12:52 PMYou make the point that there could be conflicts in routing with 7 digit diailing if I use 85 or 81 as a prefix.  Given how I've set it up, I can't see how.  Could look through the routes and the trunk rules that I've set up and see if there's any actual 7 or 10 digit number you could dial that would be misconstrued?  I'd appreciate it.

Well, for example, you have three outbound routes.  In route 85DialsGoogleVoice, you have this pattern:

85NXXXXXX

And then in route Normal, you have these patterns:

NXXNXXXXXX
NXXXXXX

Now, let's say I pick up a phone on a connected extension and dial 8523456.  I could be doing any of the following:


  • Calling a local 7 digit number 852-3456
  • Calling a number in the 852 area code, such as 852-345-6789
  • Trying to force a call to go out Google Voice - 85-234-5678

Because of that level of ambiguity, the endpoint cannot send my call to Asterisk without waiting a few seconds to see if I am going to dial more digits.  So that is why I generally only allow 7 and 11 digit dialing.  In that case, when someone dials 852-3456, that's assumed to be a local 7 digit call and it goes through right away.  On the other hand if the first digit dialed is "1" and the next (second) digit is 2-9, then it's assumed that an 11 digit call is being made (1+area code+number).

As far as FreePBX/Asterisk is concerned there is no conflict, because FreePBX takes whatever it's sent by the endpoint.  It only checks to see if a number matches one of its patterns, and by the time it gets the call it's getting the number in a single string and already knows what the final length of that string will be.  The conflict occurs at the endpoints (whether Obihai or someone else's), and what I'm trying to avoid is having the user encounter post-dial delays while the endpoint waits to see if more digits will be dialed.

Hope that explains, since it's the early AM as I write this and my brain stopped functioning on all cylinders a couple hours ago.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

MichiganTelephone

Just an update... early this morning I posted this:

How to use the Obihai OBi100, OBi110, or OBi202 VoIP device as a gateway between Asterisk/F—PBX and Google Voice and/or the OBiTALK network (UPDATED)

I believe that for many people this will be a better approach, as it is easier to set up and lets you configure your Asterisk extension in the normal manner.  It uses a Voice Gateway to send calls from the OBi device to Asterisk (rather than a Service Provider) and it has a slightly different way of sending outgoing calls from Asterisk to the OBi device as well.  It's basically the method I would have used a year ago if I'd known then what I know now about Obihai devices (note I still don't claim to be any kind of expert, just that I know more now than I did back then).  I think that perhaps some folks to didn't like my original method or found flaws in my implementation might like this one a lot better.
Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

Ad_Hominem

REVISED (too many times to count)
--------------------

I just had an idea that I think will work, that will allow the trifecta without setting up any custom dialplans in FreePBX, and preserving all Caller ID information.  It would allow using a single Obi 110 to provide an FXO using Line Port, an FXS using Phone port, and Google Voice, at the same time!

Here are my general thoughts.  I'm going to have to experiment to get it to work, but I think it can be made to work.  

I'm essentially using your new method, EXCEPT that instead of sending calls from GV/FXO back through a Voice Gateway, I'm just going to send them back through a context=from-internal trunk, and instead of setting up inbound routes, I'm going to set up Ring Groups that acheive the same effect as inbound routes.  To avoid confusion, I'll use fictional DID's for GV and the FXO, but only FreePBX and Obi will know about them.

1.  SP1 would connect to  Google Voice in the way I described in my older instructions above.  All incoming calls to Google Voice would be routed to SP2 using SP1's X_InboundCallRoute (as described in my article above), except that instead of using my actual GV # as the DID inside SP2(xxx), I'll use a fake DID, i.e. SP2(801).

2.  SP2 would connect to a FreePBX Trunk that has context=from-internal.

SP2 would route inbound calls, i.e. calls from FreePBX/Asterisk according to the dialed digits, i.e. 001xxx would go to Google Voice, 002xxx would go to the LINE PORT, and whatever extension number you decide to assign to the extension number  would go to the PHONE port.  This would be done using the X_InboundCallRoute for SP2 similar to what I posted previously.

i.e.

{>(<001:>x.):sp1}, {>(<002:>x.):li}, {>(50):ph}

The above **should** route calls from FreePBX to SP1 (i.e., Google Voice) if they are prefixed with 001, to the LINE port if they are prefixed with 002, and to the phone port if the number dialed is 50.  It would strip the 001 and 002, but not the 50.

3.  The Line Port would route outgoing calls to SP2 with a DID Number, just like it does in my other set of instructions for using the Obi 110 as an FXO.  This would mean that calls to the FXO port would come into FreePBX as if the extension dialed the DID Number listed.  Instead of using a real DID, I'd create a fake one, i.e. 802.

4.  The Phone Port would route outgoing calls to SP2 with the dialed number, just as it does in my other set of instructions for using the Obi 110 as an FXS.

In addition, the Phone Port OutboundCallRoute will be modified to send a Caller ID reflecting the extension number we've decided to assign to this particular extension on the Phone Port.

i.e.,

Change the first part of the outbound call route on the Phone Port as follows:

{([1-9]x?*(Mpli)):pp(50>)}

This will cause calls going out on the Phone Port to the Primary Line (in this case to SP2) to have 50 show up as their Caller ID.

5.  A Ring Group or Misc. Application would be set up in FreePBX to match the DID transmitted by the LINE Port and the DID transmitted by GV.  This is necessary because you are using an extension with a context=from-internal, so inbound routes won't work.  This isn't a huge deal, however, as Ring Groups/Misc. Application can both route calls with all the very same options as an Inbound Route.

6.  Since the Obi will process any SIP URI calls, just create a separate SIP URI trunk (as you have proposed in your new instructions) for outbound calls using SIP/$OUTNUM@192.168.1.xx:PORTNUMBEROFSP2.

The outbound routes would be set-up similar to what I've set up in my initial Google Voice guide, prefixing calls that you want to go to Google voice with 001 and prefixing calls to the FXO with 002, or whatever prefixes you want.  As noted  above, you'd program the X_InboundCallRoute for SP2 to strip these prefixes and send the call to the correct destination, i.e. SP1 for Google Voice, LI for FXO calls, and PH for calls to the particular extension.  You'd also want an outbound route for the extension #, in this case, 50, that would route to the SIP URI Trunk as well.

This method could also easily be expanded to allow use of the ObiTalk service as well.  Just use SP2(803) for the ObiTalk's X_InboundCallRoute, create a Ring Group/Misc. App for 803 in FreePBX, modify SP2's X_InboundCallRoute to set-up a prefix for OB calls (i.e. 003), and then set-up your OB routes in FreePBX to prefix OB calls with 003 and send them to the SIP URI Trunk that delivers calls to SP2.

I'm going to look into whether there's a way to combine all three (FXO, FXS, and GV) using the Voice Gateway method you've suggested when I have a chance.  It should be easy enough to change option 2 to an extension, route the Phone Port through SP2,  send FXO and GV through the Voice Gateway as you've proposed, and use SIP URI Dialing to send calls out to the FXO and GV, using the prefixes as I've proposed.

jchonig

Thanks to MichiganTelephone I am the proud owner of an Obi100 to use with my Asterisk system.  It arrived today and so far I have it working as an Asterisk extension and for outbound Google Voice calls.

One variation on MichiganTelephone's instructions were to use an X_InboundCallRoute of:

{>(<+:>x.):sp1},{ph}

So that any calls from Asterisk prefixed with a + will be routed to Google Voice with the + stripped.  This will allow me to make international calls via Google Voice.

Expanding this to ObiTalk I would probably add {>(<***9:>x.):pp}, but I have not gotten that far.

MichiganTelephone

#18
Quote from: jchonig on April 03, 2012, 07:02:43 PMOne variation on MichiganTelephone's instructions were to use an X_InboundCallRoute of:

{>(<+:>x.):sp1},{ph}

So that any calls from Asterisk prefixed with a + will be routed to Google Voice with the + stripped.  This will allow me to make international calls via Google Voice.

Hey, why didn't I think of that? :-[  I modified my instructions to use this.  Goes to show that there's always a better way to do something!  Thanks very much jchonig (and I did give you credit near the bottom of the article)!


OOPS... After further testing I discovered this does not work reliably for me, and I don't know why (perhaps the "replacement" syntax that works in an OutboundCallRoute doesn't have the same effect in an InboundCallRoute?  Anyway, since I never make international calls, I don't have a huge interest in figuring it out).  So, I now recommend using this if you want to be able to send international calls through your OBi:

{>(011x.|1xxxxxxxxxx):spx},{ph}

Change spx to whichever of sp1, sp2, etc. you use for Google Voice.

That way, if you send an 11 digit call where the first digit is a "1" or if you send an international call that starts with "011" to the OBi it will put it through to Google Voice.   You can prepend the "1" (to 10 digit U.S.A./Canada numbers) and/or "011" (to international numbers that don't have it) in your trunk's "Dialed Number Manipulation Rules" if necessary.


Inactive, no longer posting or responding to messages.  Goodbye and good luck.  Some of my old Obihai-related blog posts have been moved to http://tech.iprock.com - note this in NOT my blog; I have simply given the owner permission to repost some of my old stuff.

twinclouds

I know this is an old thread.  I tried to get some of the "how-to" cited in the posts but cannot not find any.  Can someone tell me where to find these.   Essentially, I just want to use obi110 as a gateway for asterisk "Allow use of the FXO port for inbound and outbound calls."  I am able to set it up on freepbx.  However, I really want to use plain asterisk but cannot find any step by step instructions.  Are there still some available?  Please let me know.  Thanks in advance.