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:25 | Date Closed: | 2020-01-14 11:14:10.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | 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 |