Using the Obi 110 as an FXO and FXS Port for FreePBX
Ad_Hominem:
I think you may have missed step 2.a. in my instructions. The FXS port isn't routed to the trunk. It is routed to an extension in FreePBX.
In fairness to you, step 2.a. used to be just be the first sentence in Step 2. I've broken down step 2 into a. and b. to clarify that you have to create an extension in your PBX before you set-up the Obi to act as an FXS on it.
I learned about the S# option from Obi support. I really like being able to dial x11 or 1xxxxxxxxxx and have the call go out immediately, and it increases the wife acceptance factor as well...
Quote from: DocM on April 03, 2012, 04:48:55 pm
Ad_Hominem, your digitmap rocks. I never knew about S functions.
My personal system is a combination of your tutorial and MichiganTelephones. Everything works except for the CDR :( and flash... :'(
One thing that has confused me for the longest time is how your setup would distinguish between calls from the trunk and calls made via the FXS port without customizing your context? I would think calls made from the FXS port needs to be routed to from-internal and instead of from-trunk.
Ad_Hominem:
It appears that the X_UseRefer option should solve the call transfer issue. When enabled, the Obi should transfer Call #1 to Call #2. However, instead, the Obi creates a Call #3 (to the identical destination as Call #2), refers call #1 to Call #3, and then drops call #2. This is not how SIP Refer should work (at least, it isn't how my Aastra phones do it).
I've reported the bug to Obi.
Michigan- since you're an official beta tester, you might wish to do the same.
MichiganTelephone:
Quote from: Ad_Hominem on April 01, 2012, 09:53:54 pm
UPDATE: It seems that the way OBI handles X_UseRefer is a bug. One of you beta testers should bring it to their attention. I've sent an email to Obi support to alert them to the issue.
I have also, but for some reason they can't duplicate the behavior on their setup. That may mean that there is a bug in the way Asterisk handles REFER packets in some cases. Unfortunately it is far too common for Asterisk to change its behavior in significant ways between versions. I just got bit by this — I discovered that using my new method the correct caller number was not being shown in the CDR records (it was showing the trunk name instead), even though it was being delivered to the phone. Turns out that in Asterisk 1.8 and later the number used in the CDR records is apparently CALLERID(ani) rather than CALLERID(num), which is a change from previous versions — and even though someone provided a patch to fix it, the Asterisk folks won't do that because, well, just because. I had to update my instructions to take this into account.
Unfortunately I am not a SIP expert so I have no way to tell what's really causing the problem here. As I noted, I do not have the issue when using the Zoiper softphone. I'm not sure what they are doing differently. I just wish developers would realize that sometimes you have to yield a bit and not be so pedantic about standards if you want your equipment to work in the real world. It does no good to say "I'm following the standards properly" if something that you (or your customers) want to connect to is not. But all that said, absent any evidence to the contrary, I'd be much more inclined to believe the problem is with Asterisk than with the Obihai, since Asterisk commonly breaks things from version to version (one of the reasons I keep hoping that one of the GUI's for FreeSWITCH will actually become usable at some point—I am soooo sick of Asterisk's quirks).
Quote from: Ad_Hominem on April 01, 2012, 09:53:54 pm
Since these effects are a bit kludgy and unintended, I recommend that you use the new method of allowing the OBI to handle the transfer and increasing the maximum number of channels it can handle at once using the MaxSessions option in the Service Provider configuration. I've updated my instructions, above, to change this setting to 10, which is an arbitrary number that should meet most people's needs.
Yep, that works, and it's an acceptable solution if your device is on a fast local network and your Asterisk server is on the same network. It's not such a great solution if the device is at a remote location and they have limited or usage-capped bandwidth. I only wish Obihai could duplicate this issue on their test server so they could see what you and I are seeing. EDIT: They've got the problem mostly resolved in beta firmware — see my second post after this one.
MichiganTelephone:
Quote from: DocM on April 03, 2012, 04:48:55 pm
Ad_Hominem, your digitmap rocks. I never knew about S functions.
My personal system is a combination of your tutorial and MichiganTelephones. Everything works except for the CDR :( and flash... :'(
See my previous post — your CDR issue is likely the same one that bit me. The solution is that in the [custom-from-Obihai] context, right after the first line, which should be...
exten => _X!,1,Set(CALLERID(num)=${CUT(EXTEN,/,2)})
...insert this line:
exten => _X!,n,Set(CALLERID(ani)=${CALLERID(num)})
Hopefully that will fix your CDR issue. It took me THREE HOURS to figure this out, and all because Asterisk changed something in Asterisk 1.8 and refuses to fix it even though a user graciously provided a patch! So this is really a workaround that should not be necessary, but it does appear to solve the problem.
MichiganTelephone:
UPDATE: Obihai support IS working on the X_UseRefer issue — they just pushed out a beta firmware for me to test on my OBi202, which appears to fix the problem as long as you don't use *98 to transfer. In other words, if you flash, dial the number you want to transfer the call to, and when ringing commences you hang up, it works. If you flash, dial the number you want to transfer the call to, wait for the called party to answer, maybe talk a bit to explain why you are transferring the call, and then hang up, it works. If you flash, dial the number you want to transfer the call to, wait for the called party to answer, flash again to have a three-way call, and then hang up, the original caller gets transferred to the other party on the three way call but my OBi202 drops out of the conversation. :) :) :)
The only way it does NOT work is if you flash, dial *98 and the number you want to transfer the call to. If you do that, the call disconnects. My suspicion is that the OBi may be dropping out of the call before Asterisk has a chance to complete the transfer, based on what I've seen on the Asterisk CLI, but I might be wrong about that. Anyway, I've let Obihai Support know that they have the problem mostly solved, and I suspect they might want to take a stab at fixing the *98 issue, but even if they don't, this is a huge improvement and hopefully it will make its way into the general firmware updates at some point in the near future. Thanks to Obihai Support for looking into this, and with any luck this will be completely resolved by the time the OBi202's start shipping (which I am told should happen next week). Of course, I would hope the fix will also be included with the next OBi1x0 firmware release as well.
Navigation
[0] Message Index
[#] Next page
[*] Previous page