Calls dropping after after a specific amount of time

Asterisk Asterisk Support
#1

Hi,

We have been facing very weird issue with our new asterisk 12 setup. The issue is listed below:

It is a kind of one way after certain time frame such as 1.01mnt call. The other end caller can hear us but we cannot after 1 minute of call. It goes on silent. Abruptly we have to disconnect the call and call them back to continue the conversation. it is not a call dropping I believe, it is a sound issue, the call keeps going, the customer can hear the agent but no the other way around, most of the times the customer hang up. Fact, if the client waits enough time the two way audio COULD be retaken.

Any idea and fix would be appreciated. We are not sure, if the issue with our SIP provider or with Asterisk, they have confirmed that the issue is not from their end.

Sajid.

#2

There’s not enough information here to be able to really help. What channel technology is in use? What’s the configuration? What’s the console output? If VoIP have you looked at a packet capture to see the flow of traffic?

I’d also suggest upgrading to Asterisk 13. The 12 branch is currently in security fix only[1] and will soon become completely unsupported.

[1] wiki.asterisk.org/wiki/display/ … k+Versions

#3

Thanks for looking into it.

We are using Chan SIP trunk for making external calls register with Level3 SIP provider.

Asterisk (Ver. 12.8.2), Freepbx version 12.0.76

Please find few sip debug info given below, hope that helps. Please let me know anything else needed. The calls goes on silent exactly at 1.01 sec, the other end user can hear us but we can not hear anything. This is random, out of 10 calls 8 calls have this issue, 2 calls goes well without any issue. It is like one way call. We have to drop the call abruptly and make it again and again to complete the call.

This is impacting our production. Please let me know if any patch needs to be updated. Currently our asterisk is running on Hyper-V virtual machine and has 2 core cpu and 2GB of RAM with 31mpbs bandwidth.

[2015-08-20 11:08:07] VERBOSE[30517] chan_sip.c: Retransmitting #1 (NAT) to 10.39.90.66:5060:
OPTIONS sip:10.39.90.66 SIP/2.0
Via: SIP/2.0/UDP 10.32.11.63:5060;branch=z9hG4bK6db76332;rport
Max-Forwards: 70
From: “Unknown” sip:nla-sip1-in@10.32.11.63;tag=as22476399
To: sip:10.39.90.66
Contact: sip:nla-sip1-in@10.32.11.63:5060
Call-ID: 584193361a036db66c57682500b987f4@10.32.11.63:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-12.0.74(12.8.2)
Date: Thu, 20 Aug 2015 09:08:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

[2015-08-20 11:08:08] VERBOSE[30517] chan_sip.c: Retransmitting #2 (NAT) to 10.39.90.66:5060:
OPTIONS sip:10.39.90.66 SIP/2.0
Via: SIP/2.0/UDP 10.32.11.63:5060;branch=z9hG4bK6db76332;rport
Max-Forwards: 70
From: “Unknown” sip:nla-sip1-in@10.32.11.63;tag=as22476399
To: sip:10.39.90.66
Contact: sip:nla-sip1-in@10.32.11.63:5060
Call-ID: 584193361a036db66c57682500b987f4@10.32.11.63:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-12.0.74(12.8.2)
Date: Thu, 20 Aug 2015 09:08:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

[2015-08-20 11:08:09] VERBOSE[30517] chan_sip.c: Retransmitting #3 (NAT) to 10.39.90.66:5060:
OPTIONS sip:10.39.90.66 SIP/2.0
Via: SIP/2.0/UDP 10.32.11.63:5060;branch=z9hG4bK6db76332;rport
Max-Forwards: 70
From: “Unknown” sip:nla-sip1-in@10.32.11.63;tag=as22476399
To: sip:10.39.90.66
Contact: sip:nla-sip1-in@10.32.11.63:5060
Call-ID: 584193361a036db66c57682500b987f4@10.32.11.63:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-12.0.74(12.8.2)
Date: Thu, 20 Aug 2015 09:08:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

[2015-08-20 11:08:10] VERBOSE[30517] chan_sip.c: Retransmitting #4 (NAT) to 10.39.90.66:5060:
OPTIONS sip:10.39.90.66 SIP/2.0
Via: SIP/2.0/UDP 10.32.11.63:5060;branch=z9hG4bK6db76332;rport
Max-Forwards: 70
From: “Unknown” sip:nla-sip1-in@10.32.11.63;tag=as22476399
To: sip:10.39.90.66
Contact: sip:nla-sip1-in@10.32.11.63:5060
Call-ID: 584193361a036db66c57682500b987f4@10.32.11.63:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-12.0.74(12.8.2)
Date: Thu, 20 Aug 2015 09:08:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

[2015-08-20 11:08:10] VERBOSE[30517] chan_sip.c: Really destroying SIP dialog ‘584193361a036db66c57682500b987f4@10.32.11.63:5060’ Method: OPTIONS

#4

Normally traces only containing OPTIONS are useless. However, in this case, there is no reply to them, so you need to find out where the request or the response is getting lost.

#5

Thanks,

Could you please help me how to find out where the request is getting lost? Since I am new to asterisk, not much aware of the troubleshooting parts. I am not sure how to trace it. Is there any configuration in asterisk to make changes to capture this?

Sajid.

#6

Do network captures as various points in the network and determine the last place where you can see an OPTIONS packet, or its response.

This isn’t something where one can be more specific at a distance, especially with the amount of time you can expect for peer support.