Inbound route changes from destination_number to sip_to_user for domain

[mrjoli021]

I have a multi-tenant setup. The FusionPBX version is 5.0.6 running on Debian 11. The OS and FusionPbx are fully updated. All of my domains are setup to use destination_number in the inbound route. One of the domains when I modify the inbound route dial plan transfer extension from one extenstion to another. Automatically the condition changes from destination_number to sip_to_user. I thought I accidently changed it myself by clicking on the wrong button or something, so I deleted the entire inbound route and redid it. It happeneded again breaking the dial plan since this is the only piece that get changed. Any idea why this is happening? I have only noticed it on one domain, but it could be happening on others as well.

 

[dcourtney]

Noticing the same thing everytime I save a destination it changes the route to the above and needs to be manually changed in inbound routes. You find a fix?

5.0.8 on Debian 11

 

[hfoster]

Default to default sip_to_user · fusionpbx/fusionpbx@5fabba6

The value sip_req_user is not working out as a good default. Change this to better default is sip_to_user.

github.com

Default used to be SIP Req User, but is useless for a number of SIP trunks as they do not put the destination number in the 'INVITE URI', it will usually be some sort of UUID or other reference. The SIP TO field, is almost always the destination number.

You can change the default setting back to whatever you want by adding/changing:

Dialplan -> Destination -> Text -> {$sip_req_user}

or whatever you want.

 

[dcourtney]

Late post, but this confirmed fixed the issue, thanks fo much @hfoster really appreciate you pointing us in the right direction. Just change the value in the default settings > Dialplan > Destinations and reload settings.

 

[markjcrane]

The destination_number doesn't work for every VoIP provider. Even for providers it does work for it may not work in every scenario. The reason for the change is when someone us has a phone that is forwarded like a mobile phone and a SIP diversion header is used then destination_number will likely not be enough to work well. In some cases ${sip_to_user} or ${sip_req_user} may be required.