Congestion problem

[alevene]

No, I don't have a cold, but perhaps my current PIAF does!

Periodically I start getting congestion emails. I call my own PIAF from my cell to confirm the busy signal, and once confirmed log into the GUI. I select Inbound Routes and just save and apply the settings WITHOUT changing anything.

The busy signal stops and everything goes back to normal. I realize that this is a band-aid fix to a problem but I don't have an idea why I get these congestion messages. Do you?

 

[rugby]

I've had the same issue the past few days as well. It sucks that my clients will call and get the "This # is no longer in service" message. I can see * picking up the line so it's not my provider.

It's so completely random that it drives me nuts.

 

[jroper]

Hi

What you are doing with the orange bar reload is the same as the asterisk reload command.

I've seen this where a trunk loses its registration for a while, and for some reason, when the trunk is available, Asterisk does not reconnect the trunk.

Just to confirm this, when it happens again, type sip show peers at the command line, or iax show peers as appropriate, and I reckon you will find that the trunk says its unreachable, or deregistered.

type reload, and it all comes back again.

Joe

 

[wardmundy]

A reboot sometimes works wonders.

 

[marv]

You may also want to check the logs. I have been having problems with my provider becoming lagging and/or unreachable at times.

Logon as root
cd /var/log/asterisk
cat full | grep -i notice

or you can change out 'notice' with 'warn' or the sip/aix name

i.e. for vitelity
cat ful | grep -i vitel

or maybe download pingplotter and trace the route to your provider and see where you get the most lost packets?

I think I have a thread on here somewhere that talks about how to bump up the registration renewal times if it goes down.

 

[alevene]

More information

I've noticed that if I reload Asterisk using the update-fixes command everything gets back to normal. So I think that its either a lack of proper registration or more likely, that a folder permission has changed for some reason and the IVR is not reachable so the system just rings busy and Vitelity sends a congestion (red herring) message.

 

[jroper]

Again, update fixes restarts asterisk, so it comes to the same thing.

In essence, an asterisk reload sorts everything out, the question is, why is it losing registraton in the first place.

Joe

 

[alevene]

Busy signals

I worked on this problem at the weekend, and although the SIP accounts are registered with two separate providers I can create a failiure by doing the following -

I wait 20 minutes and then call the main DID, which gives a busy signal. I can then call again in about 15 seconds and the call connects.

It appears that the inbound call isn't answered and just bounces the call, with a busy signal.

Is they a way to make sure that the MySQL engine is listening to Asterisk and sends the call to the correct IVR?

I've rebuilt the IVR without any change in outcome.

 

[alevene]

After months of this problem I finally figured it out... the DNS lookup for the SIP provider was too slow for the PIAF box. As such when I changed the FQDN to the underlying IP address, the problem stopped instantly.

 

[jroper]

Hi

Well done for finding this out.

I install Bind on all the boxes I put out - you can do this with one click in Webmin. Then set the DNS server to look at 127.0.0.1

The more control you can have over the network and the elements of VoIP, the easier this job gets. Installing DNS on the box is one less thing to go wrong, and I trust Bind on my PBX more than I trust a "Free with your broadband" router to do my DNS lookups.

Joe