Allow Header missing UPDATE

We are having an issue with calls dropping from one of our Trunks. We have run a SIP debug and find that there is a timeout on a non-critical invite. During one of the INVITE transactions we are not seeing a response from the provider and the system times out and drops the call. They are claiming this has to do with the lack of UPDATE in the Allow header of the SDP. What is this function and how would this cause the timeout.

We are running V13 FreePBX Distro. I can provide any details needed to solve this. We have been working on it with the provider for 6 weeks now without resolution.

ALLOW headers appear in SIP, not in SDP.

The lack of a suitable ALLOW header value is not a valid reason for ignoring a request. At the very least they should have responded with a rejection.

UPDATE is not a core requirement for SIP.

At least some versions of Asterisk do not support UPDATE incoming, so would not generate ALLOW for it. The peer should use re-INVITEs instead.

Okay that’s what I figured. Currently the canreinvite is set to no, if I change it to yes or update would that potentially satisfy their requirement? I changed it to update but it didn’t change anything as far as the header goes.

Like you said I would expect to see a rejection or an error if there was an issue but it’s only an intermittent problem. The majority of the calls work but this still happens on 10% of the daily calls. The error I’m seeing in the log is no response to one of the OK messages and subsequent retransmissions until the calls fails. Everyone I have spoken with so far says this is a routing issue, what’s your opinion?

canreinvite is obsolete. You should use directmedia=no. However I would say they are complaining about their ability to update, not Asterisk’s, and none of the Asterisks control what the side does with UPDATE or re-INVITE.

It would help to have SIP debug logs.

I wonder if they are objecting to Asterisk sending UPDATE without ALLOWing it, but that is perfectly legal as long as they ALLOW it.

Their engineers are saying that their side wants to use UPDATE and because our side doesn’t allow it their system is not responding to our side during invite transactions. Hence the call dropping due to timeout. They wanted me to program the system to allow update to be used but I explained that was an undertaking not even worth doing. They have now set their side to not use update. We’ll see what happens. I can post logs later, I need to remove phone numbers etc first.

@david551 Just a quick question… I have been fighting with the provider now for several weeks regarding this UPDATE message that their end is forcing which is causing dropped calls. The provider insists that Asterisk can handle UPDATE messages but on our FreePBX setup it is not implemented. Can we implement it or turn it on or whatever is needed to make it work? My client is ready to switch providers as this point… Any assistance here is greatly appreciated.

1.6.1.0 does not support it, although adding it is not that difficult for a programmer, as it is handled almost the same as re-INVITE. I would have to look at the source code to see if support was added in any later version.

@david551 Thats what i figured, Im not a programmer with that level of expertise. We are on Asterisk V13.7.1 with FreePBX Distro V13.

@david551 Just to confirm you are saying that as of 1.6.1.0 UPDATE was not supported which means any prior versions would not have supported it either (natively). My provider shows 1.4.22-3 as being supported which means that they must have changed something since they IOT’d it or they would have had the same issue.

I’ve only looked at 1.6.1.0 in detail, but there is no sensible reason why they would have taken it out once implemented.

That’s what i figured. I found this on Voip-info.org regarding UPDATE but i am not sure this a blanket solution. And would it now be directmedia=update now instead of canreinvite?

http://www.voip-info.org/wiki/view/Asterisk+sip+canreinvite

directmedia=update is only used outgoing, i.e. if is the ITSP that needs to allow update in this case, not Asterisk.

@david551 sorry for my ignorance but if there is the option to send UPDATE using direct media=update why is asterisk not accepting update messages? My issue appears to be that the provider is trying to send them but we aren’t accepting them. If I use directmedia=update will that actually send UPDATE messages to the provider?

Because these are different parts of the code. Also, I suspect that there are or where a number of SIP phones that understood UPDATE, but not INVITE, but there was no need for those phones to be able to send UPDATE to Asterisk.

@david551 Thanks for the info. Is there any way to find out what it would take to implement UPDATE in Asterisk? The provider is not allowing my client out of their contract and are insisting that it our problem to rectify. I am not receiving much assistance from the FreePBX forum as far as a possible solution either.

@david551 Sorry to keep bugging you! The provider has an approved PBX list that they have done testing with which includes Asterisk 1.4 from 2012. My argument to them is that if Asterisk didn’t support UPDATE in that version and does not now in V11 how is it on their IOT list. But I would need to ensure that this is the case. Is there a way to confirm this with the developers? or someone at Digium?

You will need to obtain an implementation of SVN and trawl through the changset comment, or look at the code using svn blame to find when any support for incoming UPDATE was added. That’s more than a two minute job.

Okay, I’m sure it would be! Thanks again for all your assistance. I will speak with the provider again and see what we can hash out.

Thanks,
Tim