Be sure to use the very latest firmware. Earlier versions had a bug with the X_UseRefer option which have now been fixed!

Note that I've made a lot of changes to these instructions since I wrote them a few years ago, and so if you set-up your Obi 110 based upon these instructions before the date listed above, you should double check your settings now. The updates include ensuring that the Obi 110 can transfer calls correctly (and allow you to continue making and receiving calls), process calls more quickly (by knowing when you're done dialing without waiting for 3-5 seconds), and I now include an option to allow you to choose whether your 911 calls should be routed to your PBX or direct to your FXO line (by default with the Obi, they are routed to your FXO line - even if you don't have one).

-----------------------------

Here’s how to set up an Obi 110 to act as both an FXS and an FXO for any FreePBX -based PBX (including the FreePBX Distro, AsteriskNOW, PBX In A Flash, Elastix, and Trixbox):

2. Set-up the Obi 110 to act as an FXS Port (i.e., to make the PHONE port work as an extension on your PBX):

a. First, set-up an extension on your FreePBX just like you’d set-up any other extension. Make a note of the extension # and password, as you'll need them for step 2.b.

b. Once you’ve determined the IP Address of your FreePBX and your extension # and your extension password, you can configure the Obi 110 device as follows:

Service Providers: ITSP Profile A: General: General: DigitMap:

(911S0|1xxxxxxxxxxS0|011xx.S2|xx.S2|xS2|xxS2|*X.S2|(Mipd)|[^*#]@@.)

Note: The standard Obi 110 “DigitMap” will allow you to dial calls from your FXS Port that are 3 digits or longer, and will put the call through after three seconds. It will also automatically add "1" to the beginning if you dial an area code and telephone number.

These behaviors may be undesirable. Some people prefer to have calls go out after 2 seconds, or immediately. In addition, PBX users often want to be able to dial one and two digit extension numbers, or feature codes that begin with an asterisk. Finally, some telephone companies that require the dialing of area codes for local calls do not allow the calls to be prefixed with a "1".

The Digit Map above eliminates the prefixing of calls with a 1, forces calls to 911 and to 1+Area Code+Number to go out immediately, sends all other calls out after 2 seconds of inactivity, and allows the dialing of feature codes starting with asterisk and one and two-digit extensions.

Note that the "S0" and "S2" in the digit map reflect how long the Obi will wait after receiving a matching pattern before putting the call through. In the above-example, most calls will go through 2 seconds after dialing is completed, but a 1 + area code + number call will go through immediately without waiting for further digits. You can change the numbers after the S to whatever delay suits your needs. For example, if you change 011xx.S2 to 011xx.S5, then the device will wait 5 seconds before putting through a call that begins with 011. Obi will always put a call through immediately if you dial # when you are finished dialing.

Note: You can change the above to something less than 10 if security is an issue. The default of 2, however, will block you from making any calls if you transfer a call using the "flash" hook feature until the persons on those calls hang up. Ten should be more than enough, but you can also increase it if you prefer.

Note: The above is necessary to prevent SP2 service from attempting to utilize ITSP A. For some reason, even if SP2 is disabled, it will still attempt to subscribe to the MWI feature from Port 5061, causing error messages to show up in the Asterisk Logs.

Physical Interfaces: Phone Port Phone Port OutboundCallRoute:

If you have a phone line plugged into the Line Port, then no changes are necessary. By default, the Obi will route 911 calls to the phone line and NOT to your PBX. If you want to change this behavior, then find the part of this entry that reads:

{(<#:>|911:li}

and change it to

{(<#:>|911:sp1}

or just delete {(<#:>|911:li} from the OutboundCallRoute altogether.

This will route 911 calls through the Asterisk PBX instead of routing it directly to the Line Port.

Note: The information below, regarding speed dials, appears to no longer be necessary. Obi probably fixed this in a firmware update.

By default, the OBI 110 uses all two digit #s between 1 and 99 as speed dials. If you want to use two digit extension numbers and/or you want to use 70 as the transfer destination for parking lots and 71-79 as the way to pick-up parking lots, you’ll need to create speed dial entries mapping each of these to themselves. In other words, in the area for speed dial 70, type in 70. In the area for speed dial 71, type in 71, and so on.

3. Set-up the Obi 110 as an FXO Port (i.e., to allow you to connect a phone line to the LINE port and then make and receive calls on it using your PBX):

Note: Change 2125551212 to the phone number of the line that will be attached to your LINE port.

RingDelay: 3500

This is how long the Obi 110 will allow the phone to ring before giving up on waiting for Caller ID. If the Obi 110 gets a Caller ID signal during this period, it immediately puts the call through. If you do not have Caller ID, you may wish to set this to 0.

DialDelay: 1000

Note: My POTS line can sometimes take longer to pull a dial tone because I have an alarm on it. You may not need to change this figure from the default.

DialDigitOnTime: 50 DialDigitOffTime: 50

Note: You don’t need to change the above two settings either, but your calls will go out faster if you do.

PSTN Disconnect Detection: SilenceTimeThreshold: 600

Note: The above increases the amount of time that the Obi will wait to disconnect a call if it hears silence. 600 equals ten minutes. You may not want to change the default.

Port Settings: ACImpedance: 600

Note: You may need to change this to eliminate echo problems. Good luck!

ChannelTXGain: 0 ChannelRXGain: 5

Note: You don’t need to change the above, but if you experience echo, you might want to reduce one or both of them.

4. Set-up a Trunk in FreePBX:

Now, you need to tell FreePBX how to make and receive calls from the Obi 110’s connected line. You start by creating a trunk:

Note: The “username” above must match the Trunk Name and the AuthUserName you entered when you set-up the FXO Port in the Obi 110.

Note: The secret you enter above must match the AuthPassword you entered when you set-up the FXO Port in the Obi 110. It does not need to be “FXOPASSWORD”. You can select any password you like.

5. Set-up an inbound route in FreePBX

The Inbound Route in FreePBX tells FreePBX how to route calls that ring in to the Obi 110.

Description: Obi110DID Number: 2125551212

NOTE: This must match the number you put in the Obi 110 FXO setup (above) inside the parenthesis in the InboundCallRoute after you entered SP2(. Normally, it should be the phone number of the line attached to the LINE port of the Obi 110.

CID name prefix: L1-

NOTE: You can put whatever you want in the above field. I like to have L1- to indicate that this call came in on Line 1.

Set Destination: Ring Group/Extension of Your Choice

6. Set-up an Outbound Route in FreePBX

81DialsPOTS

Route Name: 81DialsPOTS

Dial Patterns:81|81|1NXXNXXXXXX81|NXXNXXXXXX81|NXXXXXX81|X11

Trunk Sequence: OBITRUNK1

Note: You can obviously set-up any outbound route you want. This route allows you to force calls to the Obi device by dialing 81. The very first line will allow you to get a dial-tone if you dial 81 by itself. If you don’t want that ability, delete line that reads: 81|

If you want to make the dialing code something else, just change 81 wherever it appears to whatever you want it to be (i.e., 081).

Emergency

Route Name: EMERGENCYDial Patterns:911

Trunk Sequence: OBITRUNK1

Note: This route forces emergeny calls, i.e. 911 calls, to go out over the Obi 110.

Some people may prefer one set of instructions to the other, or may pick up some hints in one that are not in the other. Thanks for posting yours.

I think the main difference is you suggest using dial prefixes and I'm kind of philosophically opposed to that, figuring that people should be able to dial calls as they always do, and the switch should be smart enough to route the call appropriately. But, everyone has a different "right" way to do things!

Of course all this has been hashed and rehashed in this (sticky) thread:

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.

I haven't been able to find a straightforward guide to use the Obi 110 as an FXO/FXS, similar to the way that people used to use the Cisco SPA3102. So, after consulting with Obi Technical Support, I got mine working and wrote this one.

My previous guide was for using the Obi 110 as an FXO and Google Voice. This guide eliminates the routing issue that you didn't like because it simply doesn't use Google Voice at all. As I explained at the link you provided, the old guide that I wrote gives users the option of just dialing, without using any kind of prefix. However, it also gives users the option of forcing a call on a particular route using a prefix. I'm a big believer in giving users and admins options, because they make troubleshooting much easier.

Your article talks about using the Obi as an FXS, but not with a simple extension configuration, which is what I wanted to do. Also, in using the Obi 110 as an FXS with my cordless phones, I found that it was unable to dial two digit extensions and unable to dial *-feature codes, but I found the solution and included it in this guide. I don't believe your guide addresses that issue.

Also, you may recall that I found a potential issue with your suggestion of using the LINE DID as the Trunk Name (incoming calls on other SIP trunks with a CID equal to the Obi Trunk name resulted in an Asterisk generated "not in service" type recording instead of being routed according to the inbound route for that DID), and so I continue to use the "OBITRUNK1" trunk designation.

The Obi 110 is SOOOOOO good at dealing with echo that it just begs to have a guide to set it up the same way that the old SPA3102s were set-up (and we all know that they were AWWWFULLL with echo). So, here it is.

I'm glad to see that yo're still blogging as well. Keep up the good work.

Ahhh, I get it now (I'm a little slow sometimes)! In that case this is a GREAT addition to the knowledge base on these devices, and I'm glad you posted it. And yes, you are absolutely right about the Sipura/Linksys devices and their awful echoecho.

You're one of two people that have reported issues with using the DID as the Trunk Name (there may be others, of course, but I haven't heard from them) so I amended my article a bit to mention it and suggest using OBITALK1 as an alternative. So I think we are both borrowing ideas from each other but that's okay, in the end it helps other users get their devices configured.

I'm not back to blogging the way I used to and perhaps never will be, but one thing I haven't mentioned (I don't think) is that I got hit with a pretty nasty skin infection a little over a month ago that among other things caused my feet to swell up like a couple balloons. It's taken about a month to get it under control, and during most of that time I've felt like I've had about 1/50th my normal energy (a couple of days I actually thought I might be dying, it was that bad). If you've ever had mono it was a bit like that, but without the jaundice. So as you can possibly imagine, trying to blog was not only the last thing on my mind, but for a few days there I was actually thinking I might never have the strength or mental acuity to ever do it again. The infection's mostly gone and my feet are back to normal size, and even the itching and burning has mostly gone away, but my energy levels still haven't come back up to where they were before. So that's one big reason I wasn't around much, for whatever it's worth.

Anyway thanks for the explanation, and sorry if I'm a little dense at times!

Logged

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.

One thing that I've run into with this setup is it takes forever like 20 or 30 min. before the obi will successfully register with freepbx. This was driving me crazy. it took me a while to just be patient and let it work for a while.

I''m new to asterisk so it may be a setting that I have screwed up but I thought I'd throw this into the mix in case anyone else runs into this problem.

And thanks to Ad_Hominem and MichiganTelephone for doing the heavy lifting on this. When it does finally register it works perfectly.

I have a Dlink router and I checked. It does have the SIP-ALG enabled. I don't know if that would cause problems for me locally though. I will say though that I gave up trying to register my voip.ms accounts as SIP. I ended up using IAX and they worked perfectly. I probably have one of the 10,000 settings in freepbx screwed up but it's working great right now so until it breaks I'm not touching it!

I wanted to add this to the thread in case someone is searching this out. I hope it's appropriate.I have Groundwire on my iPhone and I wanted to enable TCP for registration in order to save battery life. I went into FreePBX, Asterisk SIP settings and added the following two items to "Other SIP Settings"tcpenable=yestransport=udp,tcp

This worked great until the OBI went to re-register and it threw out an error. I went into the OBI trunk and added:transport=udpto the peer section and all is well. Not sure if this is the right way to do it but it accomplished what I wanted to do.

I followed this process and had very good success with it. Big THANKS! My question is about voice mail notifications. I have my PBX using Google Voice Mail to answer my missed calls. I got tired of fighting it and decided to use it since it jumped in from time to time when I didn't want it. What is the best way to get missed call voice mail notification with POTS phones? I can not get the message light or the double dial tone ring to work on my Panasonic DECT 6.0 phones. I would love to hear what others are doing.

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'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.

Logged

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.

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.

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).

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.

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.

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.

« Last Edit: April 01, 2012, 12:34:40 pm by MichiganTelephone »

Logged

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.

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.

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.

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). 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.

« Last Edit: April 01, 2012, 10:26:32 pm by MichiganTelephone »

Logged

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.

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.

Logged

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.

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.

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.