Possible to use OBi110 to as an FXO port on an Asterisk server?
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).
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 pm
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.
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-3456Calling a number in the 852 area code, such as 852-345-6789Trying 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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page