Sunday, September 27, 2009

FreePBX - IVR Options Not Working [fixed!]

Funny times again in FreePBX Land.

As excited as I am at how close I am to having my 'own Google voice' catch-all number, it seems I'm bumping into an issue with the IVR. I am able to record the IVR, reach the IVR when calling the inbound route, but when the IVR recording plays, I am unable to actually do anything. When the voice says 'Press 1' and I press 1, nothing happens. It's not picking up the DTMF tone or something. Or permissions are wacky. I've emailed Disposable Joe to see what he thinks about the scenario...

EDIT:

DTMF was the problem. In the PEER details of the Trunk in FreePBX:

Change dtmfmode=rfc2833 to dtmfmode=inband

Or add it if isn't there...

Why?
The device that you press the key on will generate the DTMF tones. - If the codec is not ulaw or alaw then the DTMF tones will be distorted by the audio compression and will not be recognised. If the phone is set for RFC2833 and asterisk is set for inband then you may not hear anything

That's why!

If you are calling from an external line then it's a different codec or somthing.

Another option is to use dtmfmode=auto, but that didn't seem to work either.

DJ

Thursday, September 17, 2009

What to do when my PAP2 Web browser Interface keeps freezing

I was battling the user interface of my Linksys PAP2 web browser interface. Every time I would try to change a setting in the advaced area, it would freeze up and I'd have to force-close the browser and restart my job. I found that it helped to power-cycle the device after force-closing the browswer, but it wouldn't stop the problem from reoccuring. Finally, what i found that works great, is that you just disconnect your internet connection from the device. Likely you are behind a router, so just unplug the cable that goes from the router to the modem. Then, log into your device (it might be wise to power-cycle it again before opening your browser). Do all your settings, save your settings, and then power cycle your device again. Reconnect the internet and you should be good to go. This worked well for me.

Inbound calls failing on PAP2 with FreePBX

Also related to this topic, look for my post about "What to do when my PAP2 gui keeps freezing." here

FINAL EDIT 092709

My perseverance finally paid off. I almost went crazy but everything works now. The problem was two part:

1. For some reason when I changed the static IP of the PAP2 to .107, the gui changed over and I could now access the gui from that IP in the browser. HOWEVER...and very strangely, when I went into the 'system' settings I noticed the PAP2 static IP was still reading .100! How, I don't know, so I simply changed it to .107 one more time, saved, and power-cycled the device - and it started working.

2. I changed the nat settings to 'yes' and 'keep alive' in both lines.

3. I put all the SIP ports of both lines back to 5060

What a battle!

EDIT 091909

It turns out that everything I wrote below wasn't actually... that worth following but it may be of educational interest for anyone on our path. I would recommend reading it just to pick up a few troubleshooting ideas, maybe. The new update on this is this:

It seems as though the Nokia E71 was in conflict with the Linksys PAP2. The way I finally found this out (and an interesting and fast troubleshooting method, by the way) is I went to the 'active session' of my DI-524 router (D-link) and kept clicking it and watching the IP address activity. What I figured out by doing that was that, even though I had removed all the static IP address from my actual Nokia and changed it back to 'automatic' under the advanced access point settings, I was still seeing an IP address of .107 showing up in the active session list! That was my old Nokia static IP address. Why was it still showing up if it wasn't in the phone? Then it dawned on me that I had, under the home/DHCP section of the router, left the MAC address of the Nokia in the static DHCP client list. So, I guess what was happening was the router was registering the MAC address of my Nokia and force-feeding it an address of .107. Why my Nokia doesn't register with our PBX with that static IP manually in there is another question, but it seems that once I removed that and put the phone back to automatic (NOkia) and the PAP2 to 'static' but still with DHCP ability active, everything worked, including PSTN inbound calls to the PAP2.

We'll see if it lasts this way overnight!

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

The archives of this are here:

After hacking a vonage box successfully (I'll post about that soonish) I had a random problem occur. I believe it's a good and quick learning experience to read through the process I went through, but you can skip to the '1 second solution' at the end if you'd like. There is an edit in the middle that was an interesting turn of events (if you think this stuff is interesting! ha)

I had set up two different extensions within the PAP2 device. All of the following were working perfectly:

-inbound calls from PSTN
-outbound calls to PSTN
-Extension-to-extension calls from within the same LAN (i.e. phone1 port to phone2 port call withing selfsame PAP2) (inbound and outbound)
-Extension-t0-extension calls from one LAN through a WAN and terminating at an extension at a different LAN (both directions) (inbound and outbound)

Then, without notice, I totally lost all functionality of phone2 of the PAP2, including all voicemail recordings we had done (the voicemail recording loss remains a mystery at the time of this posting). At the same time, though, it appeared that phone1 of the adaptor was ok.

The first thing I did was log into the PAP2 device. I assumed that the problem was because there were too many devices sharing the same 5060 port. So, I changed phone1 to 5062 and phone2 to 5063. They both registered and were able to call out. However, after a few hours, I figured out that all calls within that LAN were now only able to call out, but not receive calls from anywhere (LAN, WAN, PSTN, etc). All extensions within that LAN were now basically only able to to outbound calls.

So, I decided to go into my router and do a DMZ where I discovered that it seemed to work! So it was definitely a port problem in my LAN that was restricting inbound calls. But, I had all the ports open for this kind of application.

Randomly (and here comes the solution so far), I decided to set both phone1 and phone2 of the PAP2 to 5060. I was expecting a conflict but lo and behold - they both not only registered by were able to receive inbound calls from my separate Nokia E71 which was at a different extension in the same LAN.

I went back into my router and cleared out all the new ports I had opened during testing and it seemed to work just fine.

I now, however, have one remaining problem! It seems that the PAP2 device is working just fine in my LAN but now my Nokia E71 can register but cannot receive inbound calls from the PAP2 extensions! Grr. I hope to post a follow up to this with a solution soon.

EDIT:

It turns out that it was not much related to what I thought above either! After doing everything above, I still started encountering the same problems once I started making random calls to and fro internal extensions on my LAN. I remembered reading somewhere something about NAT and how it offers a helping hand when you are behind a router. However, in the Linksys PAP2 they call it 'NAT mapping' and I had never heard of the word 'mapping' attached to NAT so I was afraid to try it out. Finally, I just enabled it as a last resort and did a test to and from all the extensions and it worked...almost. And here is an interesting note for troubleshooting. I didn't want to wake up my family while I was ringing the extensions so I just engaged the extension to which I would be calling (picked up the phone) so that when I called it, if it was working, I would get the 'on the phone' message, instead of the 'unavailable' message. I assumed that if I got the 'on the phone' message that everything was working perfectly for receiving calls. All the extensions worked perfectly after enabling 'NAT mapping'. I was happy, but at the last second I decided to do one actual call to an extension to make it ring. It failed! It went straight to the 'unavailable' message. Discouraged I did a quick power-cycle of the PAP2 and boom. Everything worked again. It seems that now, I am fully back in action.

1 second solution:

in PAP2 interface enable "NAT MAPPING" for each line if you are behind a router.

What I learned (Summary):

1. After doing any major changes in the PAP2 settings, always power cycle when you are done to make sure everything is 'engaged'

2. Always try a DMZ on the device before going too far. At least then you can isolate the source (LAN, device, WAN, otherwise)

3. write down a list of your extensions and all the possible combinations that you will test like a spreadsheet like this:


.............................| setting change | result | setting change | result
ext1 > ext 2
ext 1 > ext 3

ext2 > ext 1
ext 2 > ext 3

ext3> ext1
ext3> ext 2

that way you are tracking your setting change and making sure you are testing both inbound and outbound calls




Wednesday, September 16, 2009

How to fix a 'An Error has occurred' message in FreePBX voicemail

I was messing around with ports in my hacked Vongage adaptor when something went wacky. After that, every time I picked up my extension, I got a message waiting indicator beep, but when I went to go in and check the message I got the 'An error has occurred' robot chick. I know she's just doing her job but it frustrated me. So, I decided to fix it before I went to bed. After a bunch of further messing with the ports, the solution turned out to be nice and simple. I love it when that happens. Here's how to fix it:

1. Log into your FreePBX
2. Go to your admin gui
3. go to the extension that's messing up
4. Disable the voicemail completely, submit, and then apply changes (reload)
5. Re-enable voicemail for that extension, submit, and then apply changes (reload)

Done. Your voicemail should be cranking out the sweet voice of your mother inviting you for dinner on Sunday....

Sunday, September 13, 2009

Uploading Audio Files - FreePBX finicky settings

In addition to my post here:

I re-read my post and tried to follow it, but I realized that I forgot to do a post about how picky FreePBX is about how you go about uploading your completed (and correctly formatted, of course!) file. By following these steps, you'll reduce significantly the amount of hair you have to pull out:

1. Go to your "System Recordings' area
2. Browse for the file you wish to upload
3. Enter a name for the file in the 'name this recording' field below
4. Go BACK up and click the 'upload' button
5. A window will pop up with a message from your server warning you to wait. Wait!
6. When you see 'Successfuly uploaded ....." message appear in the background, then you can close the dialogue box warning by clicking 'ok'
7. Save your settings

It is currently NOT intuitive so you have to follow these instructions. If you try to upload the file before putting something in the 'name this file' field, for some reason it fails.

REMINDER NOTE! Another big reason for a failed upload is incorrect formatting. See my post here about that here.

Saturday, September 5, 2009

Peopleline.net - Inbound Calls not working - the solution

After about 5 hours with Disposable Joe and no success, I decided to wake up early and tackle the issue again.

Background: I had recently ported my vonage number over to Peopleline.net, a Vancouver VOIP provider (so far so good, by the way!). Outbound calls were always working well with x-lite with a temporary number they gave and masked the vonage number with. Inbound calls, of course, I had to wait for until the porting was complete. Once the porting was complete, I started working on setting up the inbound calls for Freepbx in the Peopleline trunk we set up. Unfortunately it was not working at all. Here is the saga with the solution at the end:

type=friend
host=customdomain.ucantalk.net
qualify=yes
canreinvite=no
context=from-trunk

I decided to try this:

1. Erasing all settings for inbound because i found a post where you shouldn't enter it and their email said it to..kind of...but not clearly.
2. Adding nat=yes to the outbound area because I was thinking that maybe it's because the box is behind the router that the inbound isn't working....

result:

fail...but...oddly,... with nothing at all in the inbound settings, i'm still getting the same results in the asterisk -rvvvvv action. It's still showing the call coming into the box...so..the call is going into the box...so it must be a small tweak in the existing setttings. i will mess again with the registration string based on this suggestion I found somewhere:

this works as regirstration:

Lexicon:

XXX = three digit user number assigned by Peopleline
YYYYYYYYYY=your ported or Peopleline VOIP number
customdomain = a custom subdomain assigned to you by Peopleline when you buy service
secret=random password Peopleline gives you

XXX:secret@customdomain.ucantalk.net/XXX

but i wonder if the front or back needs to have the 303 numjber.... i"ll try this first:

----- YYYYYYYYYY:secret@customdomain.ucantalk.net/XXX

result = 'all circuits are busy' but it still was doing something in the box (this is after calling a ...oh..crap. that's why. I was calling the 303 number. ha....let me try a cell

result = success! So, strangly, I changed to the setting above with the YYY number at the front and I can successfully call KA's cell phone as an internet call through the box. now i know that first number works interchangeably with the phone number. Now I'll try a call from the cell to the YYY number and watch the command line:

result = busy signal and no CLI activity whatsoever :(

now i'll try changing the last XXX to the phone number and try the steps above again. So, with this:

YYYYYYYYYY:secret@customdomain.ucantalk.net/YYYYYYYYYY

call from 1447 to cell: success!

call from cell to YYYYYYYYYY: busy signal and no CLI activity whatsoever :(

now i'm keeping the above settings and just adding 'from-trunk' to the 'USER context' field in the trunk

result: busy signal and no CLI activity whatsoever :(

So, it would seem that it's the

Now I"m adding this back in:

type=friend
host=customdomain.ucantalk.net
qualify=yes
canreinvite=no

Result: nothing. Busy, no CLI

Now I'll change this:

YYYYYYYYYY:secret@customdomain.ucantalk.net/YYYYYYYYYY

back to this:

XXX:secret@customdomain.ucantalk.net/XXX

and everything is back to 'not working' normal. CLI activity like last night, now i"m getting the ULAW voice stuff read to me.

Registration string seems to be the key..... maybe a bunch more combinations. Maybe we don't need both sides at all.... maybe one side was a temporary XXX while the number was porting...? maybe it's messing things up now?

trying this (no XXX at the end)

XXX:secret@customdomain.ucantalk.net

Result: It works just as well as if I didn't have it there. I see the CLI stuff happening and ULAW was read to me audibly

I'll try a call from 1447>PSTN : no problem! weird! So that terminating XXX didn't seem to do anything at all...

I just realized I didn't try this:
XXX:secret@customdomain.ucantalk.net/YYYYYYYYYY

here goes:
1447>pstn= works!
pstn>YYYYYYYYYY= IT.....................WORKS!!!!!!

something is happening! it's ringing...but strangely not t 1447 which is logged on

IT WORKS!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

we are in action.

SOLUTION in 1 second:

Registration string should be like this:
XXX:secret@customdomain.ucantalk.net/YYYYYYYYYY

that was it. That was all.

Now to learn how to hack a PAP2 (vonage box)

Tuesday, September 1, 2009

Peopleline.net Free PBX Outbound Trunk Settings

After much web search and randomly trying different settings (that's what I do because I don't know what I'm doing), we couldn't get our box to call our locally using Peopleline service. However, it worked perfectly and with almost zero latency when using x-lite. At least we knew that it was a simple setting problem in the box. Peopleline clearly states that they do not support Asterisk (because they know how messy it can get, I guess!) but after an email to their support clearly stating that I would not be asking for further support from them if I messed up anything, they gave me something that they found in one of their searches (I'd love to know what search engine they use!). After applying these settings, it worked like a charm. I think one of the key settings was the slash and username after the registration key. Here they are (note: i don't have incoming settings yet because my number isn't ported):

XXX = your phone number or temporary three digit user name, depending on whether you are porting a number or not. I'm assuming the XXX will be the number they give you if not and finally your ported number once ported

YYYYYYYY = your secret password provided by peopleline

[general]
register => XXX:YYYYYYYY@yourcustomsubdomain.ucantalk.net/XXX

[peopleline] <--trunk name
type=friend
username=XXX
secret=YYYYYYYY
fromuser=501
host=yourcustomsubdomain.ucantalk.net
dtmfmode=rfc2833
fromdomain=yourcustomsubdomain.ucantalk.net
context=default
insecure=very


They also gave this information which I have not yet used:


The corresponding entry in extensions.conf would be:

exten => 501,1,Dial(SIP/extension)
exten => _0[1-9].,1,Dial(SIP/
peopleline/${EXTEN})
exten => _00[1-9].,1,Dial(SIP/peopleline/${EXTEN})