Dropping calls due to lack of RTP activity

I have been working with my provider on an issue we have with some calls dropping due to lack of RTP activity - here is the response from our provider
I reviewed the call in question and found that in your SIP Allow headers it is missing the “UPDATE” in the list. When you made the change was it only for your SIP INVITES? If so you would need to include this header on your SIP 200 OK responses to ensure inbound calls will allow SIP UPDATES. With the SIP Re-INVITES including the SDP/RTP information to be negotiated every five minutes I suspect is causing the issue. However, I was able to confirm there were no port changes throughout the duration and the RTP signaling was constant throughout so I am unsure if this is causing an issue further into your equipment past the SBC IP to the end user device. Once you have made the change to add UPDATE to the allow list for the SIP 200 OK responses please retest

Can someone tell me where/how to add UPDATE to the allow list for SIP 200 OK?

The provider should not be relying on UPDATE support. Frequent re-INVITEs shouldn’t harm Asterisk.

chan_sip, which you should no longer be using, has the Allow header hard-coded, in channels/sip/include/sip.h. You should not add it unless you are prepared to fully implement UPDATE Noting the following, this would be a major job, and will not happen, as chan_sip is dead.

  • XXX This is not even close to being RFC 3311-compliant. We don’t advertise
  • that we support the UPDATE method, so no one should ever try sending us
  • an UPDATE anyway. However, Asterisk can send an UPDATE to change connected
  • line information, so we need to be prepared to handle this. The way we distinguish
  • such an UPDATE is through the X-Asterisk-rpid-update header.
  • Actually updating the media session may be some future work.

I don’t know my way around chan_pjsip well enough to see what support it has, and there seems to be only one legitimate posting on the pastebin server in the last three weeks (and some that look distinctly illegal), and that one doesn’t include an outbound request, so I can’t quickly check what chan_pjsip sends.

A chan_pjsip INVITE contains:

1 Like

My FreePBX does include UPDATE in the Allow header sent with a 200 OK response to an incoming INVITE (using pjsip). Do your logs show otherwise?

Is this a new setup with this provider? If not (it used to work but doesn’t anymore), are you aware of any change that may have caused this?

Which calls drop (for example, all incoming calls after 15 minutes)?

If you are using chan_sip, why?

Is your PBX behind a NAT? If so, post firewall make/model or cloud platform.

What does pjsip logger show (if anything) shortly before the call drops? Does one side send a request that the other rejects? Or does the PBX send a request and get no response?

Your provider’s message refers to an SBC; is that one at your site supplied by them? If it’s yours, do you see a problem on the WAN side of it?

The provider suggested that the problem may relate to the end user device. Can you refute that (internal calls don’t drop, or calls via a different provider don’t drop)?

A little background… we have 30 sites using the same provider and same FreePBX setup (yes it’s old) - only one site is dropping calls - first the audio drops, then 31 seconds later the calls drops. This was working on our old voice provider. We changed providers and the FreePBX is now behind an SDWAN appliance that is also managed by the same provider. I feel like the issue is in the SDWAN configuration, but they pointed me to adding the UPDATE

This does not seem to be a hard problem. Your background data is somewhat ambiguous; I am assuming that you have 30 sites all using the ‘new’ provider and all using the same SD-WAN appliances, with 29 working fine and one dropping calls. If that’s not correct, please be more specific.

Two possible general approaches:

  1. Make the PBX support UPDATE, hoping that this fixes the problem. First, confirm (using pjsip logger or sip debug) that the failing PBX indeed does not include UPDATE in its Allow header. If it does, either the SD-WAN (or some other router/firewall) is butchering the traffic, or the provider erred in their analysis. Next, check whether a working PBX sends UPDATE in Allow. If so, it should not be hard to make the failing one behave the same. Otherwise (neither good nor bad sends UPDATE), take an image backup of the failing system, update to Asterisk 16 or newer with asterisk-version-switch, change trunk to pjsip if presently chan_sip, test. If things go south, restore from the backup.

  2. Demonstrate that the system should work without UPDATE; the SD-WAN or some other networking component is responsible for the trouble. IMO this is a better approach, unless you run into administrative difficulty looking at the internet side of the SD-WAN. I’d start by capturing SIP traffic on both the failing PBX and a working one. I’d expect that the provider sends a re-invite after some time (usually 5 to 30 minutes) and the working system responds immediately with a 200 OK. Now, what happens on the failing system? If the re-invite doesn’t come in, the SD-WAN is likely blocking it. If it comes in but Asterisk rejects it or doesn’t reply, compare details of what was received. If Asterisk replies with a 200 but the provider keeps retransmitting the re-invite, the 200 is likely blocked or butchered by the SD-WAN.

Note: All of this assumes that when the trouble occurs, RTP stops coming from the provider but Asterisk is still sending RTP to the provider. If not, provide details.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.