Using the Obi 110 as an FXO and FXS Port for FreePBX
Ad_Hominem:
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.
------------
Forget the UseRefer option. Leave it unchecked. Change the MaxSessions in the SP for the FXS to something higher. I changed it to 99, and now the Obi will forward a call (just like any other endpoint) and still let me make and receive other calls.
If you want to use the UseRefer, you have to understand how it works.
1. Place or receive the first call.
2. Hit Flash.
3. Dial the second call. The second person will receive a call from the ATA.
4. Hang-up. The call from the ATA to the second caller will end.
5. The Obi will send a REFER message and the original call will be re-routed to the second caller.
6. The second person will receive the referred call, i.e. a new call from the original caller.
7. Since this all happens very quickly, you may be occupying more than 1 channel on the second person's endpoint, and if they can only handle one, then the call in step #6 will reach voicemail.
Note that if, in step #4, you hit flash instead, you'll be in a conference. If you then hang-up before the first party (i.e., the party you called in step 1) hangs-up, the REFER message will get sent and steps 5 and 6 will occur anyway.
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.
MichiganTelephone:
Quote from: Ad_Hominem on April 01, 2012, 09:53:54 pm
Forget the UseRefer option. Leave it unchecked. Change the MaxSessions in the SP for the FXS to something higher. I changed it to 99, and now the Obi will forward a call (just like any other endpoint) and still let me make and receive other calls.
If you want to use the UseRefer, you have to understand how it works.
1. Place or receive the first call.
2. Hit Flash.
3. Dial the second call. The second person will receive a call from the ATA.
4. Hang-up. The call from the ATA to the second caller will end.
5. The Obi will send a REFER message and the original call will be re-routed to the second caller.
6. The second person will receive the referred call, i.e. a new call from the original caller.
7. Since this all happens very quickly, you may be occupying more than 1 channel on the second person's endpoint, and if they can only handle one, then the call in step #6 will reach voicemail.
Note that if, in step #4, you hit flash instead, you'll be in a conference. If you then hang-up before the first party (i.e., the party you called in step 1) hangs-up, the REFER message will get sent and steps 5 and 6 will occur anyway.
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.
Okay, that's freaky, I was working on this at exactly the same time you were, testing some of your earlier messages (that you deleted JUST as I was about to reply). :P But I came to the same conclusion you did — X_UseRefer just isn't going to work the way you expect, but upping the MaxSessions to 10 (which is exactly the value I used also) at least makes it so that when you have a transferred call running through your device, you won't be prevented from making more calls. This, of course, assumes that your PBX isn't limiting the number of simultaneous calls per account to some unreasonably low value.
EDIT: This still means that transferred calls are going through the Obihai device, rather than being sent back to Asterisk. What sort of complicates things is that the Obihai can do transfers that might be impossible using Asterisk alone - prime example, someone could call you via the OBiTALK network and you could then transfer them to a number that you can call via the Asterisk server. But still, when a transfer takes place that would use two call legs to the same service provider, the Obihai should be able to do a proper transfer, as Zoiper does (and, I am told, certain other bands of VoIP adapter do). It probably doesn't matter as much when the Obihai and the Asterisk server are on the same local network, but if the Obihai is at some remote location and the user has sub-optimal broadband service, then it could make a huge difference in call quality.
MichiganTelephone:
Quote from: Stewart on April 01, 2012, 07:58:18 pm
Turning off ReferAOR might help.
I tried that last night. Doesn't help
Quote from: Stewart on April 01, 2012, 07:58:18 pm
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.
I know there are some people who can look at Asterisk log files and glean useful information out of them, but I've only rarely ever found them useful, mostly because looking for anything in them is like looking for the proverbial needle in the haystack. Wireshark is another thing that's way too complicated to set up and use unless you do it frequently. These are things that someone might be able to use to figure out what the difference is, but unfortunately I'm not one of those people. I did try to look at the Asterisk CLI outputs to see if I could figure out anything from those, but it was hopeless.
Stewart:
Though I've not tried on the OBi, my IP phones (Polycom and Aastra) have no problem with transfers on a free PBXes account. The phones use SIP Refer to transfer; PBXes uses Asterisk.
Try your OBi on PBXes; if it fails, sending a comparison to the Obihai folks may help them fix the bug. If it works, comparing the respective OBi SIP Debug and syslog outputs should show what your Asterisk is doing wrong.
DocM:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page