Using the Obi 110 as an FXO and FXS Port for FreePBX
MichiganTelephone:
Quote from: Ad_Hominem on March 14, 2012, 04:39:47 pm
I've made some updates to these instructions, including adding information about how to specify the dialing delay and how to decide whether 911 calls are routed directly to the FXO (bypassing your PBX) or to force 911 calls to go through the PBX.
I was looking at your information again and realized there is one error that could prevent this from working if an inexperienced user doesn't know any better — you have no "context=from-trunk" or similar statement in your Peer Details. Without a context statement, Asterisk has no idea what to do with the calls. It might still work if you allow anonymous inbound SIP calls (I doubt it, but if it works for you, that's probably why) but I don't do that.
I've developed a new method that does not require using one of the Service Provider accounts to send calls to and from Asterisk (it uses a Voice Gateway rather than a Service Provider), and that (for Google Voice accounts, anyway) is easier to set up, at least in my opinion. The downside is that you have to do a little extra work if you try to use it with something other than Google Voice and you want to get the Caller ID name from the device. Since Google Voice doesn't send a Caller ID name anyway, that's not an issue for Google Voice users.
Anyway, my new approach still requires that at least one of your Service Providers be configured to use a SIP service (not Google Voice, else the Voice Gateway won't work in this application) but you can make it an extension off your Asterisk server and that qualifies, and that extension can be configured like a normal extension (no piggybacking on a trunk, as in one of my earlier approaches) which means that certain features such as Voicemail Message Indication still work. The Voice Gateway won't pass a Caller ID name at this time (there's no exposed system variable that I can get it from) but by running a small AGI script you can scrape the device's web interface once when a call comes in and grab the caller name from there. So it's possibly a bit simpler if you're only using it for Google Voice, and maybe about the same level of complexity if you are using it to get calls from the OBiTALK network or the LINE port on an OBi110. When you get a chance you might want to take a look and see what you think.
Ad_Hominem:
Michigan,
I have no idea why context=from-trunk did not appear in my original instructions, as I have that in my own trunk settings and in my "internal" documentation. I've corrected it. Thank you for bringing that to my attention.
Since I subscribe to your blog, I was notified when you posted the idea of using a voice gateway to handle FXO calls and creating a SIP URI trunk in FreePBX to handle outgoing calls, and I was intrigued. I suspect that many users (myself included) only have an FXO for emergency calling and to keep my longstanding phone number tied to a provider that has no risk of going out of business. In fact, I receive no incoming calls at all on my FXO because they all forward to VOIP provider instead. I use the FXO for local outbound and 911 calls only, and so I'd simply ignore the Caller ID related issues. Attempting to integrate your instructions into mine is on my list of things to do! :)
Along those same lines, I urge you to take a close look at the modifications that I've made to the instructions recently, particularly regarding the digit map's handling of 911 calls, the dial plan, the use of X_UseRefer, and the means to enable message waiting, and to incorporate those into your instructions as well.
Ad_Hominem:
I'd like to add one other thing that most users may want to consider. There's really NO reason to configure the FXO port on the Obi 110 to register with your PBX. Registration is needed when you don't have a fixed IP address, and so the device needs to register with your PBX so that your PBX knows what that address is. If you've followed my instructions, your Obi 110 device WILL have a fixed IP address. Furthermore, when registration is ENABLED, there may be times that calls won't be able to get through (for example, if you reboot the PBX or your Obi, there will be a period of time where the Obi is not registered and is waiting for the retry period to elapse). If you disable registration, all calls will be sent through immediately. Registration is different than authentication. As Michigan has noted in his instructions, the Obi NEVER authenticates, but you can limit any risk by using the X_AccessList field.
If you prefer NOT to use registration make the following changes to my instructions:
1. In the FreePBX PEER Details for the trunk, change:
host=dynamic
to
host=192.168.1.50
(where 192.168.1.50 is the IP of your Obi 110)
and then add
port=5061
at the end of the PEER details.
The change to host is needed because without registration, the PBX needs to know where to find the Obi 110 device. The port entry is needed so that the PBX knows which port to expect calls from and which port to send calls to. Normally, that information would be sent during registration, but since we're not registering anymore, you need to tell FreePBX and Asterisk which port to use manually. Note that if you have your FXO set up as SP1 (rather than SP2 as my instructions suggest), you would use port=5060.
2. In the Obi Configuration screen
Voice Services
SP2 Service
SP2 Service
X_Register Enable: (Uncheck)
This change is needed to tell the Obi device not to attempt to register.
Once again, I'd like to thank Michigan, who gave me necessary ideas for this method to work in his latest articles (which avoid registering an FXO at all by using Voice Gateways and SIP dialing).
MichiganTelephone:
Quote from: Ad_Hominem on March 28, 2012, 11:54:49 pm
Michigan,
I have no idea why context=from-trunk did not appear in my original instructions, as I have that in my own trunk settings and in my "internal" documentation. I've corrected it. Thank you for bringing that to my attention.
You're quite welcome. Can't begin to tell you how many times I've done things like that.
Quote from: Ad_Hominem on March 28, 2012, 11:54:49 pm
Since I subscribe to your blog, I was notified when you posted the idea of using a voice gateway to handle FXO calls and creating a SIP URI trunk in FreePBX to handle outgoing calls, and I was intrigued. I suspect that many users (myself included) only have an FXO for emergency calling and to keep my longstanding phone number tied to a provider that has no risk of going out of business. In fact, I receive no incoming calls at all on my FXO because they all forward to VOIP provider instead. I use the FXO for local outbound and 911 calls only, and so I'd simply ignore the Caller ID related issues. Attempting to integrate your instructions into mine is on my list of things to do! :)
Well, just so you know, there actually IS a way to get the OBi to give up the Caller ID name, but you have to use a Perl AGI script (could be rewritten in PHP, I suppose, but I don't know PHP). The script scrapes the web interface and pulls the name out of that. I added the details as an addendum to the article.
Quote from: Ad_Hominem on March 28, 2012, 11:54:49 pm
Along those same lines, I urge you to take a close look at the modifications that I've made to the instructions recently, particularly regarding the digit map's handling of 911 calls, the dial plan, the use of X_UseRefer, and the means to enable message waiting, and to incorporate those into your instructions as well.
I don't really get much into dial plans; those aren't exactly my strong point. But I did try your use of X_UseRefer, and unfortunately, at least on our system it didn't work well at all. If I left it unchecked, it was as you said, you can use the OBi to transfer a call, but then you have no channels left to place another call — and this was on an OBi202. And this apparently happens whether you use *98 to transfer, or simply flash, place a call to the desired extension, and hang up, or if you actually do a three way call and then drop out of the connection. In any of those cases, until the other party stops talking, when you try to place another call, you get "There is no service available to complete this call"! So you are correct about that.
However, when I tried using X_UseRefer, for whatever reason it just didn't work as it should have. What would happen is that the original caller (the one I was trying to transfer) would go directly to voicemail. If the other intended transferee was on the line (because I had done a three-way call), the act of hanging up would cause them to be disconnected, and the caller would go to voicemail. If I tried to do *98 or flash, dial the other extension and hang up, the original caller got transferred to voicemail, got a busy signal, or got sent to a different extension in the same ring group. Note that in all cases these tests were done using three extensions off the same Asterisk server. There was simply no way I could successfully transfer a call to the intended extension with X_UseRefer checked.
I do not know if this is a problem with the OBi, with FreePBX, or with Asterisk (wouldn't surprise me at all if it's one of the latter two — the box I was testing it on has FreePBX 2.9 and Asterisk 1.8.7.1). But since I couldn't get it to work after quite a few tests, I don't think I'm going to recommend it, at least until the problem is fixed.
Believe me, I wish it did work to solve the problem you mentioned. Personally, I always use ## to transfer a call in Asterisk (which bypasses the VoIP device altogether) but still it seems like this should work better than it does.
EDIT: What's even stranger is that I tried doing a transfer using the Zoiper softphone program, and it worked fine (and I could shut Zoiper down once the transfer button had been clicked, and the call continued, so it wasn't being bridged through Zoiper). So maybe Obihai should try to figure out how Zoiper is doing a call transfer, and attempt to emulate that. I have no idea what they are doing differently.
EDIT 2: I've also started a thread on this in the PBX in a Flash forum in the hope that perhaps someone there with more expertise than I can help nail down the exact source of the problem. I don't want to say it's a problem with the OBi device if it's really Asterisk that's at fault or vise versa, and I'm personally at a loss to figure out why this wouldn't work in my testing.
Stewart:
Turning off ReferAOR might help.
Though I know very little about Asterisk, you may find a clue by comparing the behavior of the Obi (using SIP Debug) with Zoiper (running Wireshark on the Zoiper PC). Asterisk's log may also show an error or other useful info.
Linksys ATAs (with recent firmware) do handle call transfer properly with Asterisk-based providers such as Future-Nine and VoIP.ms. If you have one, testing it on your FreePBX may help determine at which end the problem lies. To be able to transfer after establishing a three-way call, set Xfer When Hangup Conf.
Navigation
[0] Message Index
[#] Next page
[*] Previous page