Asterisk Server Dropping Calls at 1 HR. Mark

General Help
1

To all,

I will preface this post with the fact that I am a complete newbie when it comes to FREE PBX and Asterisk, which is the topic of my outreach today. We are having an issues with our conference bridges on Asterisk where calls are being dropped at the 1 hr mark. We could set a stop watch to it. We have a trunk port between our system and our Cisco UCM. We also have a direct inbound DID to the Asterisk Server from an 800# for external calls to the Asterisk Server. We are on version: 11.14.2 with PBX firware version 6.12.65.23 SP 1. I have poked around as much as I can but I am at a loss. Hoping for some assistance from the community. Need to know what to focus on.

Brian

2

Asterisk has no such timer. Does this happen on calls direct to the bridge from a SIP device attached to asterisk like a phone or does it happen to people calling in from your SIP trunk or UCM system.

3

I think I have tracked down the error in the logs.

[2017-10-02 07:30:58] WARNING[2063] chan_sip.c: Retransmission timeout reached on transmission [email protected] for seqno 105 (Critical Request)
Packet timed out after 31999ms with no response
[2017-10-02 07:30:58] WARNING[2063] chan_sip.c: Hanging up call [email protected] - no reply to our critical packet

Brian

4

Any thoughts?

5

Some VSP’s limit the call length, checxk with them.

6

I had a similar issue a while back, had to do something with the firewall and the udp timeout settings.

I forgot the correct name for the setting and I’m not in front of any devices I can look at. This was also on a sonicwall.

One thing to look at, enable keepalives, they need to be less than the udp timeout on the firewall.

It’s been a while since we fixed it, so I can’t remember all the details.

7

Just in case, check DHCP renewal times.

8

Guys, why was @tonyclewis question ignored? It was the only thing asked/mentioned that actually has any real bearing. There is a UCM in between the calls. That small log snippet shows a private IP address. So I’m going to guess that the UCM is between the ITSP and the PBX. If that is the case, you need to look at the UCM. Is the UCM the one sending the BYE on the bridge? Is the PBX not talking to the UCM right?

I mean let’s be clear, this is a conference call. If 5 people call in from the PSTN it is five different calls not all of them are going to drop due to time limits at the same time because their time limits would be different (unless all five manage to call in at the exact same time, down to the second, to the bridge).

If multiple calls going through the UCM are dropping at once, that is where you should be looking. Unless you have some absolute proof that Asterisk somehow trashed the conference.

Do you have this setup with an Admin member and it will dump all the members if the admin leaves? That right there could be something too. As Tony asked, are there directly PBX devices calling the bridge? If the “Dump all members when Admin leaves” and the admin is the one having the issue then looking at all the other parts is a waste.

9

We’ve seen this question before and (IIRC) the problem was a session timeout on the firewall.

10

The issue that we have is related to inbound call that are direct from the PSTN to the PBX. It has nothing to do with the trunk between our UCM and the PBX. Also, there is no firewall between our voice gateway and our PBX. It is direct. I have logs from our SIP provider showing that the PBX is dropping the call at the one hour mark. I just tested again this morning and the same issue. This is the PBX log:

[2017-10-10 06:14:00] VERBOSE[28780][C-00000514] file.c: – <SIP/10.50.107.11-00000507> Playing ‘digits/7.ulaw’ (language ‘en’)
[2017-10-10 06:14:01] VERBOSE[28780][C-00000514] file.c: – <SIP/10.50.107.11-00000507> Playing ‘conf-otherinparty.ulaw’ (language ‘en’)
[2017-10-10 06:14:02] WARNING[2063] chan_sip.c: Retransmission timeout reached on transmission [email protected] for seqno 104 (Critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 31999ms with no response
[2017-10-10 06:14:02] WARNING[2063] chan_sip.c: Hanging up call [email protected] - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
[2017-10-10 06:14:02] VERBOSE[26166][C-0000050b] res_musiconhold.c: – Stopped music on hold on SIP/10.50.107.2-000004fe
[2017-10-10 06:14:02] VERBOSE[26166][C-0000050b] file.c: – <Bridge/0x7f7ba00b4398-input> Playing ‘confbridge-leave.gsm’ (language ‘’)
[2017-10-10 06:14:03] VERBOSE[26166][C-0000050b] pbx.c: – Executing [h@ext-meetme:1] Hangup(“SIP/10.50.107.2-000004fe”, “”) in new stack

Here are the logs from our SIP provider from our previous instance:

2017-10-02 11:57:30.214 Wightman-ISC-1 Outgoing SIP message sent : INVITE (SDP) From: [email protected]:5060 To: 519*******@10.1.0.18 519*******@10.1.0.18:5060
2017-10-02 11:57:30.218 Wightman-ISC-1 Incoming SIP message received : 100 Trying From: “Anonymous” sip:[email protected]:5060 To: sip:519*******@10.1.0.18
2017-10-02 11:57:30.221 Wightman-ISC-1 Incoming SIP message received : BYE 519*******@10.1.0.18->[email protected]:5060
2017-10-02 11:57:30.221 Wightman-ISC-1 A SIP message was received with authentication information.
2017-10-02 11:57:30.221 Wightman-ISC-1 519*******is disconnecting from the call.

There are a few instances earlier in the call where we send the INVITE, receive a TRYING followed by a 491 Request Pending message before we get the expected ACK message.

2017-10-02 11:42:10.835 Wightman-ISC-1 Outgoing SIP message sent : INVITE (SDP) From: [email protected]:5060 To: 519*******@10.1.0.18 519*******@10.1.0.18:5060
2017-10-02 11:42:10.840 Wightman-ISC-1 Incoming SIP message received : 100 Trying From: “Anonymous” sip:[email protected]:5060 To: sip:519*******@10.1.0.18
2017-10-02 11:42:10.841 Wightman-ISC-1 Incoming SIP message received : 491 Request Pending From: sip:[email protected]:5060 To: sip:519*******@10.1.0.18
2017-10-02 11:42:10.842 Wightman-ISC-1 Outgoing SIP message sent : ACK From: [email protected]:5060 To: 519*******@10.1.0.18 519*******@10.1.0.18:5060

Still struggling to figure this one out. I read that updating the rtpkeepalive helps. Default is 0 and I set it to 30. Any feedback?

Also, don’t know if this is related? I see this quite often in the logs:

[2017-10-10 06:14:32] WARNING[2063][C-00000517] channel.c: Unable to find a codec translation path from (ulaw) to (g729)
[2017-10-10 06:14:32] WARNING[2063][C-00000517] channel.c: Unable to find a codec translation path from (ulaw) to (g729)

[2017-10-10 06:14:33] ERROR[28825][C-00000517] channel.c: Could not return write format to its original state

Any assistance or guidance is appreciated.

11

Is member timeout enabled on the conference? This was affecting us at the default timeout period of 6 hours.

This specifies the number of seconds that the participant may stay in the conference before being automatically ejected. 0 = disabled, default is 21600 (6 hours)

12

Where is this setting in the GUI?

13

Looks like the remote end is using a re-INVITE as a keepalive mechanism and for some reason Asterisk isn’t able to respond to it properly. You might want to configure your trunk with “session-timers=refuse” (see Asterisk Session Timers!) or just get more thorough SIP traces to see why that transaction is failing.

14

I have Reinvite Behaviour set to “NO” Does that matter?

15

No. -

16

Is there a way to change the session-timers setting from the GUI?

17

You just add that line to your trunk config in the “peer settings” box.

18

There is no trunk config for the outbound calls to the PBX.

19

Outbound calls by definition are calls that use an outbound route which has a trunk defined.

20

Sorry inbound calls to the PBX