Can't get one number to connect but another woks -what to check

[mainenotarynet]

Ok First

PBX in a Flash PURPLE Daemon Status - Version 1.7.9  Released on 110910
Asterisk   = OFFLINE | Dahdi     = ONLINE  | MySQL     = ONLINE
 SSH        = ONLINE  | Apache    = ONLINE  | Iptables  = ONLINE
Fail2ban   = ONLINE  | Internet  = ONLINE  | Ip6Tables = OFFLINE 
BlueTooth  = OFFLINE | Hidd      = OFFLINE | NTPD      = ONLINE   
SendMail   = ONLINE  | Samba     = OFFLINE | Webmin    = LOADING   
Ethernet0  = ONLINE  | Ethernet1 = N/A     | Wlan0     = N/A      

PBX in a Flash Version   = 1.7.5.5
FreePBX Version          = 2.8.0.4                                 
Running Asterisk Version = UNKNOWN                                 
Asterisk Source Version  = 1.8.0                                   
Dahdi Source Version     = 2.4.0+2.4.0                             
Libpri Source Version    = 1.4.11.4                                
IP Address               = aaa.bbb.ccc.ddd on eth0                 
Operating System         = CentOS release 5.5 (Final)             
Kernel Version           = 2.6.18-164.15.1.el5xen - 32 Bit

I send out pages to two different numbers -- same area code just one is a long distance and one is a local.

The long distance works fine and pages get out. The local one however will ring and ring but when called from a (blech) MagicJack line goes through.

Verbose in next post due to character length restrictions.

You ask for details but the limitations make it very irritating to comply when most is code -- so see attached.

What do I need to check for? I had been sending out GV until it stopped with this same issue and now it looks like the same happens on a voip.ms trunk -- so my guess is something is up with my box (RentPBX hosted) I will proobably have them rebuild it so GV Multi-tenant can work correctly again.

I think it did actually work after a system reboot a day or so ago.

Thank you

 

[Astrosmurfer]

First, forget the MagicJack completely. That is a totally different service likely following different routes. It provides no useful information other than the fact that the local number is alive.

Concentrating on the Voip.ms trunk in question, two possibilities come to mind.
1. VoIp.MS has a routing problem to that number. You'll figure out the answer to that in a minute, and if they do, you'll need to get them to fix it.

2. You have an issue with dial rules and dialed digits.

Since you say long distance calls work, I suspect that it is dialed digits. Try dialing the local number as if it were long distance 1+areacode+sevendigits. If it works then the problem is your dialed digits configuration. If it fails, the problem is likely Voip.ms routing.

Assuming it is your dialed digits you must determine if your Voip.ms account is configured to accept 10 digit dialing, as it appears in your log, or if the require 11 or more digits. If they require eleven or more digits, you must set a dial rule on the trunk like below to add the eleventh digit.

1+207Nxxxxxx

This will match 10 digit dials beginning with 207 and prepend a 1 so that Voip.ms sees 1207Nxxxxxx.

P.s. You can post code by wrapping the desired code with code tags, as below. Remove equal signs for code tag.
[=code=]
some code or listing text
[=/code=]

 

[mainenotarynet]

Thanks Astrosmurfer, but let me go just a little mor in detail.

1 I do use the code tags -- always - I can't stand logs place outside of code tags as it take forever to scroll through them whereas if you scroll outside the boundries of code tags the wole block of code can be bypassed if you want.

2- I only mentioned Magic jack as I know its not the pager number that doesn't work.

3 - I should not have used locl/ long distance in the context you are thinking. Local area and a Long Range would have been better terminology to use.

4 - I do not want to put numbers in this post but both are in the 207 area code and I always dial all 10 digits.

5 the reason I think its my system is it did the same thing going out a GV Trunk so I changed the trunk sequence to use Voip.ms first as GV is constantly changing how it wants to play with PiaF.

If you want/need anything else let me know. But strangely enough I had a flight this morning and BOTH numbers went out, so intermittent on just this one number (maybe others too but these 2 I call several times a day)

I hope I don't violate any rules here but these are numbers to inform the Maine Troop Greeters of a military flight either coming home from or going over to Afghanastan/Iraq. To find out more you can visit The Maine Troop Greeters Site and to see the documentary PBS did a while back about 3 of our greeters, ifd you have ---flix you can view it "The Way We Get By". If this does in some way violate a rule the moderators can take out that last part -- but the MTG is a 501(c)(3) non-profit organization.

Thanks again

 

[Astrosmurfer]

Suffering through the log, I see these pertinent bits...

    -- Executing [s@macro-dialout-trunk:19] Dial("SIP/705-00000010", "SIP/voipms1/207xxxyyyy,300,M(setmusic^moh)") in new stack
...
    -- SIP/voipms1-00000011 is ringing
    -- SIP/voipms1-00000011 is making progress passing it to SIP/705-00000010
...
    -- SIP/voipms1-00000011 [B]answered[/B] SIP/705-00000010
...
    -- Locally bridging SIP/705-00000010 and SIP/voipms1-00000011
    -- Executing [h@macro-dialout-trunk:1] Macro("SIP/705-00000010", "hangupcall,") in new stack

As you can see, the call is sent, rings, is answered, and then is bridged before you hang up. So, is the issue that the call is being answered but you are unable to hear audio or, is something else happening that we can't see?

 

[mainenotarynet]

Simply put --in just keeps ringing - 4 or 5 times before I hang up as when it does work it answers and (bridged) by the 2nd ring.

like I said this morning both calls to local and long range pagers went out fine - so its an intermittent thing but happens weather GV or Voip.ms and the chances of having 2 providers have the same issue with the same number where the only common factor is my Piaf -- logic is its my Piaf

BTW the hardware phone is the Nortel 1535 via wi-fi but since the long range goes out fine (always long range sent first) the I doubt its the Nortel

 

[Astrosmurfer]

So the log you provided is actually a working call, not a problem call as described in your first post?

Local and long range make even less sense to me than local and long distance. I doubt that it is relevant. From the VoIP provider's perspective, where your calls are entering the PSTN, there is no meaningful geographical distance difference between two numbers in the same area code. The numbers may be further from your office but, there's no consequential difference from Voip.ms or GV.

 

[mainenotarynet]

Log provided was a FAILED attempt.

The local and Long range refer to the pager types NOT the phone numbers themselves. In one of your posts (#2) it was inferred to try it as a local call since the long distance number worked (mentioning the dial patterns as a cause, but since I dail the exactly the same AC-EXC-#### that wouldn't have been it), which is why I changed to long range instead.

Again the log provided was a failed attempt to a number regardless of distance from me or toll charge, etc.

 

[Astrosmurfer]

Thanks for the clarification. It helps.

Referring to the log provided, it shows that the call was answered and bridged to your extension. That is a successfully completed call. If you are still hearing ringing, when the logs show that the call was answered, then there are two possibilities.

1. There is something really broken in Asterisk/your config. (I don't suspect this.)

2. The SIP packets aren't getting back to your phone. The packet loss theory is further bolstered by the fact that you are using a WiFi SIP extension.

I'd suggest trying to create the problem from another phone that is physically connected to the network. If nothing else is available, try it with the 1535 connected by cable rather than WiFi.

 

[mainenotarynet]

What get me is that it sometimes DOES work on the number that frequently rings and rings and rings. It seems to be intermittent.

As for plugging in a different phone to the network - I have a counterpath XLITE soft phone but direct to machine (even cabling the 1535) wouldn't be possibe -- RentPBX.com hosts this for me.

Where its an intermittent thing on Voip.ms and GV (when that was 1st in the sequence -- leads me to believe that it is me or my config -- but what should I look for to solve this issue is beyond my Piaf knowledge at this point

Thank for everything

 

[mainenotarynet]

[--Update--]
Astrosmurfer, by the info you gave so far - you are right, the call actually does connect. I had to call the broken number last night and in rang and rang and rang. but I decided to see what happens if I started pressing buttons.

Knowing the AA says -- please leave your numeric message after the tone (4s wait) Beep. I started pressing buttones and hit # (all the while the phone is still ringing) and it actually sent the page. So is this an asterisk thing not knowing the call picked up, or a Nortel 1535 thing?

Next page I get I will try from my x-lite ext and see if the same happens.

What gets me is that I do one number (the long range pager number) and its fine, then hang up and do a 2nd call to the local pager number and that is the one that rings and rings, but actually answers. Odd ;confused:

I thought I read somewheres in here that there is a setting or something that will tell asterisk the call was answered (I think it had to do with calling cell phones though) - same problem, different, who knows.

Thank you again

 

[Astrosmurfer]

As I already pointed out, Asterisk is aware that the call has been answered. But, there is some kind of breakdown with that information getting back to the phone.

My initial thought was packet loss due to WiFi, and that may well be. But, at that time I had missed the fact that this was a remotely hosted Asterisk install. Since the connection between the handset itself and Asterisk is over the internet, there is further opportunity for packet loss issues. My suspicion is now leaning toward the Nortel phone.

I think reproducing the problem using x-lite is a good test.