Hi,
We just migrated our chan_sip trunks to pjsip and now we see an issue with calls with RTP being stopped sending after aprx. 15 mins in call.
I’ve already checked the PCAP traces takes on the server, and it may be an issue with re-invite’s… but I’m not sure. From the Asterisk log files I do not see anything strange…
This is the configuration of the PJSIP trunk:
Does anybody has had the same issue or does anybody know what’s wrong? 
Thanks in advance!
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:
[pjsip_trunk](+type=endpoint)
timers = no
Not sure if it has a negative impact on other scenarios?
Probably not, but you should confirm that the provider has at least one of:
Otherwise, if your system crashes and the remote party fails to hang up, the call could stay up for days and you’ll get a whopping bill.
Ok, will check that with our ITSP.
Why is this issue only showing up on PJSIP trunks?
Usually, it doesn’t. I’ve never seen this before.
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.
We don’t use SIP ALG or port-forwarding, since all traffic is flowing between public IP’s.
Should anyone else have an idea what else could cause this, let me know ;)!
This should not be hard to debug, since it happens consistently. Just look at the UPDATE being sent and the reply (if any). If everything looks good at your end, open a ticket with the provider.
If I check my PCAP, the UPDATE message doesn’t include any SDP… shouldn’t this be the case?
No SDP is good. It can’t mess with the media streams.
The most likely update at 15 minutes would be for session timers, and it is better that such requests don’t include SDP. If they do, it should be the same serial number as before, so it is ignored.
Ok… Does someone has a “valid” UPDATE message example? Which I can compare to mine?
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.