What do you mean by that? If RTP is still being received from the extension but stops being sent to the trunk, it’s almost certain that there are relevant entries in the Asterisk log about that time. Please post them.
If RTP is still being sent to the trunk but incoming RTP stops coming in from the trunk, I agree that it is likely that the provider sent a re-invite (that Asterisk didn’t get or didn’t process correctly) and dropped the call after not getting a timely response to the re-invite.
Are both incoming and outgoing calls affected? Does in-dialog communication otherwise work? Test this by calling in from your mobile (or out to your mobile if only outgoing is affected), answer the call and wait 12 minutes, then hang up the mobile. The extension phone should show the disconnect within a second or two. If it takes 30 seconds, Asterisk did not receive the BYE.
Did you also change the listening ports? By default, chan_sip bind_port is 5160 and pjsip Port to Listen On is 5060. Assuming no change, you would have had to configure (on the provider’s portal) to send calls to the new port. And any settings in your router/firewall that mentioned 5160 would have to be changed to 5060. I hope that the firewall isn’t forwarding some external port to a different internal port that pjsip is listening on; this requires complex configuration and is not recommended.
If you still have trouble, with pjsip logger turned on, paste the Asterisk log for a failed call at pastebin.freepbx.org and post the link here.
We only have the issue on outbound calls.
In our PCAP, we see around 15 minutes an UPDATE packet coming from FPBX towards the ITSP… which probably is the root of the issue.
We don’t do any port-forwarding.
Not sure what is different in the way PJSIP trunks are working? We don’t have this problem using CHAN_SIP as trunk type. We are using Asterisk 18.16.
When we add the following, the issue seems to be fixed:
timers = no
Not sure if it has a negative impact on other scenarios?
Is the problematic UPDATE accepted by the provider? If not, you’ll need to determine whether Asterisk is sending something wrong, something in your network (such as a SIP ALG) is butchering it, or the provider is rejecting it inappropriately. If it’s accepted but the result is messed up RTP, you’ll need to see whether either end sent incorrect SDP, or the network gear is causing the trouble.
That could be the problem, depending on details of your router/firewall. Usually, you would forward the RTP port range (default is UDP 10000-20000) to the PBX. Without that, various common scenarios will fail, including external extensions (if not via VPN), or routing a DID to a mobile phone via Misc Destination or extension call forwarding.