sudo Posted September 18, 2013 Report Share Posted September 18, 2013 Running Version: 5.0.10 (CentOS64) and Im having issues on one domain. I migrated this domain off an old pbxnsip box. They complained almost immediately that there was a degradation on call quality and call drops. On my voip gateway I see these calls in the Failed Calls log with a 204 error. I called my upstream provider and they said that they see the INVITE come through then milliseconds later a CANCEL gets sent through prompting them to respond with a 481. Thinking this could be a bug carried over from the old system, I completely rebuilt it from scratch with no avail. The problem persists and has even gotten worse. What in the world could be causing this? The PBX? Their ISP? My gateway? In the wonderful world of VoIP im sure its all of the above. I do not think its the gateway and Im leaning tward the pbx/domain. I have not heard of this issue on any other domains. Thank in advance. Sudo Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 18, 2013 Report Share Posted September 18, 2013 Well according to the RFC, CANCEL cannot be sent before a provisional response (e.g. 100 Trying) has been received. This is not easy to implement, as the PBX then has to hold back the CANCEL until a response has been received; and keeping in mind that the response can be a 2xx class response, or even worse first a 18x response and then a 2xx response, the PBX has to then send the CANCEL and possibly also a BYE after this (actually it is also allowed just to send the BYE). It even gets worse, because all that stuff also depends on the transport layer, as TCP and TLS do not loose packets. Also keep in mind, that the PBX has to keep the transaction in memory for a long time, e.g. when there is absolutely nothing coming back from the other side. Anyway, I would start with looking at the traffic that the PBX sends out on trunks. If the PBX really immediately sends out CANCEL after INVITE, we would have to check the reason why is that so. For example, if could be that the transaction timeout was explicitly set to 0 seconds, which would explain such a behavior. Quote Link to comment Share on other sites More sharing options...
sudo Posted September 30, 2013 Author Report Share Posted September 30, 2013 Well according to the RFC, CANCEL cannot be sent before a provisional response (e.g. 100 Trying) has been received. This is not easy to implement, as the PBX then has to hold back the CANCEL until a response has been received; and keeping in mind that the response can be a 2xx class response, or even worse first a 18x response and then a 2xx response, the PBX has to then send the CANCEL and possibly also a BYE after this (actually it is also allowed just to send the BYE). It even gets worse, because all that stuff also depends on the transport layer, as TCP and TLS do not loose packets. Also keep in mind, that the PBX has to keep the transaction in memory for a long time, e.g. when there is absolutely nothing coming back from the other side. Anyway, I would start with looking at the traffic that the PBX sends out on trunks. If the PBX really immediately sends out CANCEL after INVITE, we would have to check the reason why is that so. For example, if could be that the transaction timeout was explicitly set to 0 seconds, which would explain such a behavior. Its within milliseconds that the cancel is sent out. This is confirmed from the PBX in a packet capture. Where is the transaction timeout set? Can I send you a pcap to look over? Quote Link to comment Share on other sites More sharing options...
sudo Posted October 2, 2013 Author Report Share Posted October 2, 2013 Ive incresed the logging on all SIP, trunk, and general to 9. One more interesting tidbit - The customer is complaining that when he gets to the office in the morning, the phones display is off and pixelated. He says that he has to restart the phone to get it back to normal. He has a PolycomSoundPointIP-SPIP_550 phone. Does this trigger any thoughs as to what could be causing this issue? Ill be watching the logs and post what I see. I have heard complaints from customers on different domains on the same box so it appears to be a global issue. This happens on external as well as internal calls. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted October 2, 2013 Report Share Posted October 2, 2013 We had an issue with too many Polycom phones on an older PoE switch, where the phones were behavior erratic, especially with long Ethernet packets. Swapping out the switch solved the problem, or having less phones on the old switch. But if the PBX sends out a CANCEL, it should be possible to figure out by looking at the logs why it think it had to cancel the call. I am pretty sure that the power supply of the PBX host is not the problem here. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.