Skip to main content

Phones won't stop ringing

Posted by owenc on Wed, 03/10/2010

We're having an issue that isn't easily googleable so I thought I might might try here. I'm not sure this problem is specific to the way Thirdlane sets things up or not.

We have several customers who want all their extensions to ring on incoming calls. Frankly I think it is craziness to ring 11 extensions all at once but that is how they want it.

We're doing this by creating an incoming route that goes to a hunt list containing all the extensions.

This normally works fine but occasionally when someone picks up the call other phones don't seem to realize the call has been answered and will continue to ring. On at least once occasion I saw a call that went to voicemail and all the phones continued to ring. When this happens the phones will continue to ring forever. The only way to stop them from ringing is to pickup the handset at which time they realize there is no call and reset.

I'm pretty sure the underlying cause of this problem is funkiness in their network but it just seems to happen too easily and then once it stops it won't stop. Even if this is caused by network issues is there anything I can do to mitigate the problem. Just seems wrong that the phones would continue to ring forever.


Submitted by eeman on Wed, 03/10/2010 Permalink

sounds like a NAT problem keeping the phones from receiving their SIP messages properly. can you confirm NAT translation on the phones talking to the PBX?

Submitted by owenc on Wed, 03/10/2010 Permalink

NAT is definitely working at least most of the time.

I do think there may be some underlying network issues. In particular I'm suspicious of the Edgemarc routers that are in play at these customer locations. They just seem flakey.

Initially the customer that has the most problem with this was on a borrowed Cox connection (long story).

At first they were behind double NAT and this was happening all the time.

Then we did some tunnel magic to get them public IP addresses with no NAT but still on the same borrowed Cox connection. In this solution there was no NAT but not the greatest internet access. This problem happened occasionally then.

Then after a week we finally got them on our own network and behind the Edgemarc. It is doing NAT with a built in ALG. Now this problem is not happening all the much but how many times does it have to happen to be really annoying.

I do see LAGGED messages in the asterisk logs for this customer from time to time which is why I still suspect network issues.

I've seen the same thing happen at 2 other customers. All on our own network. The network is rock solid. The Edgemarcs I can't say the same for necessarily. So far I've not been impressed.

I'm just surprised I guess that a brief period of high latency would cause this though. Whatever is going on hasn't impacted them in any other way. No complaints about echo, delayed audio or anything like that. Just this one issue but it is a pretty big one.

Chris

Submitted by eeman on Wed, 03/10/2010 Permalink

NAT can cause a sip message to not find its way to the correct phone. When you do a sip show peers for this location.. are they all on port 5060 or are you seeing ports all over the map?

Submitted by owenc on Wed, 03/10/2010 Permalink

All this and other customers are on port 5060 when i do a 'sip show peers'.

Only exception is one of our employees at a remote location. May have to look into that ;-]

Submitted by eeman on Wed, 03/10/2010 Permalink

well if they are all 5060 then you dont have a nat issue, its being proxied (which means you can and should uncheck NAT in their extensions)

Submitted by owenc on Wed, 03/10/2010 Permalink

Interesting. I do have NAT checked in all the extensions. I remember when I set the first one up I wasn't sure if there was any downside to having it on.

Everything we have on the network today is either proxied or has a public address so I suppose I don't need it for any of them.

So you are saying that I should definitely turn this off?

The manually doesn't really say what this does and I wasn't aware that behind a proxy meant no NAT (although that does make sense).

Chris

Submitted by eeman on Wed, 03/10/2010 Permalink

it means, ignore the IP in the sip URI and send the response to the IP that sent you the packet. If your using a proxy theres nothing wrong with sending a sip message to an RFC1918 address because the proxy actually CAN see that address. without a proxy thers no route to that rfc1918 address.