Can anyone help. We seem to have an issue with a new installation of FPBX whereby external calls via a sip trunk can be answered, held, transferred all without issues but if a call is picked up via another extension either via *8 or a directed pick up the external caller is connected for around 10 seconds and the extension seems to hang up.
Changing the sendrpid=no in the trunk peer details resolves the issue but at the unacceptable cost of then losing outbound CLI info. We have around 50 CLIs and need these to be presented correctly for outbound calls.
I have looked as much as I can via wireshark and the log files and it appears to be due to x-asterisk-rpid-update: yes that are not being accepted by our provider.
After engaging the provider they have said :
"I have been advised that you will need to look into the PBX as it shouldn’t be sending update information to us, particularly when the update information seems to be internal information (the update appears to be indicating the extension doing the update). Also the RPID is showing as the extension number before the pickup takes place when it should ideally be the external number without the 44 of course.
And probably most importantly there may be a bug on the PBX as the UPDATE message seems to be reversing the From & To tags which it shouldn’t be doing. The PBX may also not be honouring the incoming BYE in these cases as it looks like it is looking for the tags to also be reversed in the BYE message when they shouldn’t be. If the tags a reversed by one end of the SIP session then the other end will not recognise it as part of that session as the tags a now different."
I can see on the web something very similar being reported:
and that person is also using FPX, so I am hoping there is some option of disabling the additional call updates sent.
Is there anyone out there who has cracked this ?
I am running FreePBX 18.104.22.168
Turn off RPID on the trunk to the provider.
Sadly, if that doesn’t work you may have to turn it off system wide.
Thanks SkykingOH - Is there no other way ? It just seems odd that on our old trixbox CE test system that was using asterisk 1.6 the call pick up works fine with the same provider.
I read somewhere that all of these additional invites was to pass the CLI during a pickup. If this is true I would hope there would be an option to disable this behaviour.
If not, I have read that sendrpid=no can be complemented with something in the cfg that specifies PAI. Would this type of tweak allow CLI presentation outbound to work with sendrpid=no and if so is there any ideas how to incorporate this into FreePBX.
I feel quite shocked at the small amount of attention this issue has on the web when it affects the user experience so much - in essence either lose the ability to present outbound CLI or lose the ability to have group and directed pick ups.
RPID sends, what appears to you, as CLID updates, and can be disabled on a system wide or peer basis.
RPID was not supported in 1.6.
Some phones and providers don’t like the updates, and the media ends up getting anchored off and times out. It’s not a call transfer issues, it’s a corner case RPID issues. I think it is yet another reason why Asterisk is looking at an outside SIP stack for the next release. We have reached the architectual limits of monolithic channel_sip.
Thank you once again. Where we are only using one trunk provider, who appear to ignore/discard the COLP updates sent by fPBX when sendrpid=on. This problem seems almost like a deal breaker.
Unless I am being incredibly dim (would not be the first time) this means that we cannot have outbound CID and support the ability for group & directed pickups. For all I almost understand what you say about asterisk 1.6 not supporting RPID, the fact is it worked great - I just foolishly thought that fPBX was better with it being more maintained and having Asterisk 1.8 underneath it.
The shocking part of this seems to be down to a new feature that is supposed to display the originating CLI to a forwarded / picked up extension - something that does not happen in our Polycom IP335 environment.
I noticed that for mISDN configs there is a COLP disable flag but cannot see anything for SIP.
My sip trunk provider seem to indicate that they have other customers using asterisk 1.8 with no issues so I do wonder if there is anything that fPBX can do to offer a different means of performing the pick up functionality.
No, that function has nothing to do with Caller ID (per se). You are speaking of CLID, or station ID that is the RPID being displayed on the calling parties phone.
Turning off RPID on the trunk will not disable outbound CID and is actually good practice as the carrier pointed out to keep internal topology from leaking out.
I have tried :
in the peer details for the trunk, and also tried adding it into the sip_custom.conf but it appears to have no affect and the call is still dropped due to no response from the sip updates being sent back to the trunk provider.
In both instances I have issued a CORE RESTART NOW hoping that it would be sufficient to apply the changes.
Just a quick update Skyking - I have been trawling through old posts and saw someone having similar problems in 2011. You were quite active in helping, initially thinking it was a NAT issue (I believe a juicy steak was lost in the debate).
I have tried setting sendrpid=pai and my issue still persists, whereby a group or directed pick up loses the call since asterisk continues to send updates. I also lose the CID outbound, but understand that there is a hack to insert PAI to hopefully restore this, a pointless exercise since it does not stop the issue.
I don’t know those settings and I doubt a core upload is sufficient.
You just need to do a reload sip or sip reload whatever it is.
The Asterisk variable is sendrpid and it works in both the global sip settings and at a peer level. You can debug with sip show settings and sip show peer xxx where xxx is your peer name. Both commands will show you current RPID state.
Can I just recheck this since its starting to feel a little like goundhog day. My single trunk provider does not appear to support the extra chatty sip update messages that asterisk 1.8 sends out when someone performs a group or directed pickup. These updates are attempting to inform the trunk provider of the internal extension number who picked the call up. Since they do not support it, it is ignored. Asterisk resends several and then terminates the call between the extension and the onsite PBX (leaving the external caller connected to some quality silence).
Now I agree that it is bad practise to advertise the internal topology of the PBX to external suppliers, even when they rudely ignore the info and make the PBX go off in a huff - but the only solution I have found is to set sendrpid=no on either the trunk or the global system. This would be great if it then did not stop use being able to specify the CID required for over 50 different extensions when making an external call.
Do you know a method of stopping asterisk sending these unsolicited SIP update messages yet retain the ability to specify a CID for outbound calls?
I think our provider may be close to a solution, but I would greatly appreciate a direct answer to the above question since it appears it is one that has been asked in various ways for the the two years without a definitive answer.