Here's the situation. These are some standalone single user handsets, and as there's going to be a number of strange SIP devices on the end we can't rely on feature key sync for diverting. It's essentially a response to the PSTN shutdown in the UK
My problem however is when a Yealink deskphone...
Yeh, I don't know if prefix 0 is a British only thing. Every number has a 0 at the start here for national dialling, and 00 for international exit code.
Theoretically, it's only the 'display' part of the number, so it should be fine. You probably just won't see updates when the call is transferred elsewhere on the phone.
Well do you want to remove the PIN number or just change it? Do you want the feature code to always forward the same ring group or do you want it to prompt for it (the default)? Do you want the destination to be the same or do you want it to ask each time (the default)?
I dunno what else I can say, its:
https://{if isset($http_auth_username)}{$http_auth_username}:{$http_auth_password}@{/if}{$domain_name}/app/provision/?file=directory.xml&contacts=users
What does the 200 OK (SDP) show for the second image? It almost looks like it's replied back with codecs that don't intersect. In the Freeswitch logs at /var/log/freeswitch.log this should show as a mismatch during the 'Audio Codec Compare' stage.
Nothing FreeSwitch about it. It's FusionPBXs provisioning app.
You have to replace the variables with your own. No point me telling you my domain name or http_auth_password.
If you run an sngrep from the server, is it the client that is rejecting the call or the server? It might not be the codec, it might be SRTP or something similar.
I think you should be able to set:
ignore_display_updates=true
In your outbound routes
https://developer.signalwire.com/freeswitch/Channel-Variables-Catalog/ignore_display_updates_16353145/
Sorry, I don't touch Grandstreams. From your picture it looks like the field is right there under XML server path. Check the Grandstreams templates to see if the URL is any different.
If it's an outbound call, surely it's your clients that sending it like that? Or is it that your carrier is sending a SIP UPDATE with the new destionation number in?