PAP2T dropouts in random times

[support0208]

Hi guys,

I am in big need of help, I have no ideas left.

In our company we had analog and voip lines together, now we changed all to voip with an external provider. The problem is: 

In random times the calls are just simply drop out and going to a busy line. It can happen in 2 minutes to 20 minutes, even 50 or whatever.

What we had done:

Upgraded the firmware to the latest version.

On the firewall we gave QoS VoIP top prio to the PAP2Ts.

We managed to connect the PAP2Ts directly to Cisco L3 switches, not to small office switches (d-link or something crap like that).

Options are mostly factory defaults, expect the registration information that the provider provided us.

On provider side: the line is alive for 36k seconds (10hours) before hang up. On their side they see no problem, there are 2 more companies on the switch where our lines are in too, others experience no problems.

All PAP2Ts are in DHCP reservation but I'm thinking about getting them off-DHCP with static IP.

Any kind of help would be appreciated, I'm out of ideas completely.

Thanks in advance

Mátyás

[Dan Lukes]

Catch SIP packets between affected device and PBX. Catch all ICMP. Turn on syslog&debug on PAP2T and catch those messages as well.

I'm pretty sure the analysis of logs and SIP dialog will help you to identify the issue source.

[support0208]

Hi Dan,

Thanks for your reply!

We checked the packets and the only thing we see: a BYE packet from the provider. We don't see anything else in our intranet. We also see Code 16 HangUpCauseCode which means problem at provider side. 

The lines are OK, the provider says they don't see anything on their side. We discovered 1ms time-outs on the line but the dropouts didn't appear when the time-outs happened.

Could it be an attack? Like IoD? Or the provider is dumb and they try to hide a hole until they fix this and want us to stay in contract?... Weird.

We are logging more data and I check back with new info.

+++++++

Looks like the primary outbound IP, where every application and internet connection goes out, from the outside it can easily go crazy in latency: some of the testers measured 3000ms ping on that IP. We are trying to get the voip traffic to a different IP.

[Dan Lukes]

Code 16 doesn't claim error. Q.850 hangup cause code 16 mean "normal clearing". E.g. standard disconnect, no error, no premature end.

Note that end-to-end delay should not be more than about 150ms. Delay over 500ms turn quality unacceptable.

[support0208]

Now we have 10-50ms on each phone but the dropouts still exist. The BYE packet doesn't let me stop wondering... We are really thinking of changing provider now.

[Dan Lukes]

Catch the RTP stream of an affectected call. There may be either packet loss or some packets are delivered so late.

Try reconfigure PAP2T to have jitter buffer highest possible - it will help with late packets unless they are so late.  If you are using uncompressed codec like aLaw/uLaw and you are not using line for data/fax connections consider to move to a compressed codec like G.729 or so (according support of your VoIP operator).  It may help at the cost of  lower voice quality.

Be sure the problems are caused by your ISP and/or VoIP provider. If their origin is on the other side of call the change of provider on your side will not help so much.