all circuts are busy on certain numbers

plazma283

Joined
Jun 21, 2008
Messages
23
Likes
0
Points
0
#1
Hello all,

I've got a bit of a problem with one of my elastix installs. I have a call centre setup using elastix that i've just updated from 1.1 to 1.5.2-2 (the problems existed before the update though). If your attempt to dial a 1800, 1300 or 13 (special number services in Australia, my location) you get the "all circuts are buy" msg, landline and mobile numbers works fine but all calls to any 1800, 1300 or 13 number fail.

I have the same version of elastix running on other installs with the same dial plan / pattern and the same VSP which work without issue.

I can also see from the CLI that the number going to the VSP is correct and the same as in my other installs.

I've checked a sip debug from the CLI and after getting a 100 trying I get a 404 not found which is the producing the "all circuts are busy"

Can anyone offer some advice here at all, I'm running out of idea.

I can post a debug + the dial plan / patterns if need be.

Thanks in advanced.

Regards,

plazma.
 

plazma283

Joined
Jun 21, 2008
Messages
23
Likes
0
Points
0
#2
bump

Anyone?
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#3
I would check with your VSP why the accept your call but then reject it (how long between the 100 and the 404? is it possible that you are attempting to use a CLID that is not allowed/acceptable/recognisable to these numbers?
 

plazma283

Joined
Jun 21, 2008
Messages
23
Likes
0
Points
0
#4
Thanks for the reply dicko, I was hoping you'd come across this, you seem to be the resident expert on here.

Anyway, the callerID is done at the VSP end, the username gets translated into the Caller ID from the VSP's switch so it doesnt matter what i put in the caller ID field it gets ignored.

I have the same setup on all other machines with the same VSP working without issue, its just this machine that is producing the fault.

The 404 is right after the 100 trying in the sip debug
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#5
I don't quite know what to say here.


Does a vanilla extension exhibit the same behavior?

You have several deployments using "similar" (used here in it's strict mathematical context) boxes.
They are all "Elastix" distributions (Are they all call-centers?), the all respond to (from bash) :

rasterisk -x "show version"

in an identical fashion? and they all work apart from this red-headed bastard stepchild?

A "fine tooth comb" examination of the /etc/asterisk/sip*.conf files shows no divergence?

A comparison of sip sessions on the various boxes to the same number show no divergence?

If all the above, and I'm guessing you've done "all that" already, I would have to go cap-in-hand to the VSP to debug a session (I hate that) in a co-operative fashion. If you have to go that route and to prepare you, a 100 from them means they expect nothing from you until they respond, hopefully with a 2xx when you can carry on the session, If you get a 4xx then only they can tell you why, (to debug, you are using g711a I assume)
 

plazma283

Joined
Jun 21, 2008
Messages
23
Likes
0
Points
0
#6
Thanks for taking the time Dicko.

Viniall extension exhibits the same behavour.

They all exlastix distros, not all call centres.

Versions are the same as I installed from 1.1 on each and just updated each to 1.5.2-2 (updated to the same point with Freepbx also, just updated using yum -y update)

And all work except for this box.

I've campared sip sessions together using 2 open putty sessions and 2 remote extensions and both show the same output from the CLI with no sip debug but verbose set to 3 expect the call falls on the call centre box, when running a sip debug i can see after the 100 trying i get the expected 200 ok and the call proceeds (with other activity but this is where the difference lies).

I'm using 711a to debug.

Might have to contact the VSP and get them to advise from their switch whats going on.

Thanks dicko, appreciate your time.
 

DaveD

Joined
Nov 12, 2007
Messages
597
Likes
0
Points
16
#7
Try adding 13. into outbound and see if it works, the . being a wild card
 

dicko

Joined
Oct 24, 2008
Messages
4,099
Likes
0
Points
0
#8
Time is itself ephemeral (as is plasma), but you're more than welcome.

To clarify, the problem box get's a 200 back after the 100 or not?
 

plazma283

Joined
Jun 21, 2008
Messages
23
Likes
0
Points
0
#9
I'll have to recheck it later tonight when no one is making loads of calls. I'll post back later tonight.
 

Members online

No members online now.

Latest posts

Forum statistics

Threads
30,902
Messages
130,887
Members
17,565
Latest member
omarmenichetti
Top