[Home]

Summary:ASTERISK-28026: Session timers not updating after reload for active calls
Reporter:Jerry Corrion (dice_telephony)Labels:pjsip
Date Opened:2018-08-27 12:10:25Date Closed:2020-01-14 11:14:10.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Core/General pjproject/pjsip
Versions:13.21.1 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:
Description:When updating a session timer after performing a core reload any call that was in session during the reload gets the following error when attempting to update the session timer.  
Error in refreshing session timer: Transport not available for use (PJSIP_ETPNOTAVAIL)
This results in the call being dropped minutes later.
Comments:By: Asterisk Team (asteriskteam) 2018-08-27 12:10:27.437-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Benjamin Keith Ford (bford) 2018-08-27 17:05:58.580-0500

What does your configuration look like? Mostly interested in endpoint and transport configuration in pjsip.conf. Does this only happen after a core reload? Is there anything else going on at the time, or is it just one active call at the time of the reload, resulting in the error message and the eventual call hangup?

By: Jerry Corrion (dice_telephony) 2018-08-27 17:49:55.981-0500

Hi Benjamin,
Any call that hits 30 minutes drops if a reload was done within the first 15 minutes of the call. This has been consistently replicated.
This is a call center so there are multiple incoming and outgoing calls always going at once. If a reload occurs while any calls are in session,
and then any of those calls reach the 30 minutes mark, the call gets dropped by carrier because the PBX stops sending session timers for the calls active during reload. Most of the calls on this PBX are probably 2-10 minutes for the operators. We have personally tested numerous times over 30 minutes without reload and doesn't happen.
I'll get you some configurations tomorrow morning. Thanks for your response.


By: Jerry Corrion (dice_telephony) 2018-08-29 15:23:53.194-0500

[0.0.0.0-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
external_media_address=192.67.68.58
external_signaling_address=192.67.68.58
allow_reload=yes
local_net=10.47.140.0/23
local_net=10.158.0.4/32
local_net=10.255.0.63/32
local_net=10.158.0.0/24
local_net=10.153.0.0/24
local_net=10.255.0.0/22
local_net=10.47.0.0/16

By: Jerry Corrion (dice_telephony) 2018-08-29 15:24:27.776-0500

[ipx.orig1]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=ulaw
aors=ipx.orig1
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[ipx.orig2]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=ulaw
aors=ipx.orig2
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[ipx.term1]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=ulaw
aors=ipx.term1
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[ipx.term2]
type=endpoint
transport=0.0.0.0-udp
context=from-pstn
disallow=all
allow=ulaw
aors=ipx.term2
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[Main_to_Champ_tie]
type=endpoint
transport=0.0.0.0-udp
context=from-internal
disallow=all
allow=ulaw
aors=Main_to_Champ_tie
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[Main_to_Indy_tie]
type=endpoint
transport=0.0.0.0-udp
context=from-internal
disallow=all
allow=ulaw
aors=Main_to_Indy_tie
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[Main_to_Mad_tie]
type=endpoint
transport=0.0.0.0-udp
context=from-internal
disallow=all
allow=ulaw
aors=Main_to_Mad_tie
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

[Main_to_Hutch_tie]
type=endpoint
transport=0.0.0.0-udp
context=from-internal
disallow=all
allow=ulaw
aors=Main_to_Hutch_tie
language=en
t38_udptl=no
t38_udptl_ec=none
fax_detect=no
t38_udptl_nat=no
dtmf_mode=auto

By: Joshua C. Colp (jcolp) 2018-09-04 05:59:51.522-0500

PJSIP does not natively support reloading/restarting transports, which is why allow_reload defaults to no as it uses a hackish mechanism to achieve it. If you change it to no does that resolve the problem?

By: Asterisk Team (asteriskteam) 2018-09-18 12:00:01.613-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines