SOLVED information about incoming short numbers

[Nedo]

Hi, I have a fusionpbx instance installed by another technician, it has a sip trunk which provides 10 numbers, example: 0573600 <-root number and 05736001 to 9 for dialing directly with extension 401 to 409.
I have to recreate a new installation with this function, unfortunately this technician no longer works in our country, so I have no way to ask him how he did it, unlike other instances I see some exports about real callee id, but it is really hard to understand what it did, I was wondering if the pre-installed "number translation" function could do this.
Could you please give me some information to accomplish all this?

Thanks in advance.

 

[hfoster]

They just probably added inbound destinations to the appropriate places, or have misunderstood the requirements?

 

[Nedo]

They just probably added inbound destinations to the appropriate places, or have misunderstood the requirements?

It is also difficult to explain, those numbers are migrated, i use a login 055035xxx but this login receive call for this kind of numbers: 05589xxx-0-9
I did as you say in the new istance but all calls directed to extensions are intercepted by the ivr as if I had not typed the extension number:
Seems that the last part of the number was not interpreted
example 05589000-> which is the root number must go towards the IVR while 0558900111 should go towards the extension 111 but if I call it from outside the number 0558900111 IVR answers.
in the old instance currently running I can see some unusual exports in inbound routes:
name: 055035xxxx
number: 05589xxx
condition destination numbers ^(055035xxx)$
action set real_callee=${sip_to_user}
action export real_callee=${sip_to_user}
Under this there is a series of other rules:
Example:
name: 05589xx123
number: 055035xxx
condition:${real_callee}
data: ^(05589xx123)$

action: tranfer
data: 123 XML

it's a nightmare to understand how it works

 

[hfoster]

Ah, right. Yeh, I forget what it's like on out of the box installs but I have to ensure that the SIP TO User is treated as the destination number. I've got this default setting which I believe is used for new inbound routes.



I can't remember if this is changed either, but the caller-details in the dialplan also sets the caller_destination to the sip_to_user.



I reckon this might be your problem.

 

[Nedo]

Ah, right. Yeh, I forget what it's like on out of the box installs but I have to ensure that the SIP TO User is treated as the destination number. I've got this default setting which I believe is used for new inbound routes.

View attachment 3136

I can't remember if this is changed either, but the caller-details in the dialplan also sets the caller_destination to the sip_to_user.

View attachment 3137

I reckon this might be your problem.

Not understand, i dont have dialplan category in default setting, i have addes this like your screenshot, now how i can use it?
I can find the second screenshot in caller details option in my dialplan manager.


I have a much simpler test case: have a number 0564xxx that redirect incoming call to 055xxx<-This is my gateway in this istance of fusion
How i can do this:
If i call from outside the number 055xxx the call goes to IVR and this is already working because i have added a row in destinations: 055xxx Action: 1020 IVR
If i call from outside the number 0564xxx the call goes wrongly in 1020 IVR how i can do for intercept destination 0564xxx and redirect to another destination?

 

[hfoster]

When you create a destination, it uses the SIP TO User as the destination condition. Now if you create a destination for 0564xxx and point it to where you need to, I believe it might work.

 

[Nedo]

When you create a destination, it uses the SIP TO User as the destination condition. Now if you create a destination for 0564xxx and point it to where you need to, I believe it might work.

Hi, i have do some tests but in the log i see that variable is not set correctly seems the provider operating the forward mask the correct destination number overwriting it. In new installation of fusion in inbound route i can see new variables like ${sip_req_user} there is some documentation about this? I cant find nothing relevant...

 

[hfoster]

Github usually. Mark J Crane submitted a change 11 days ago adding {sip_req_user} to the master branch for inbound routes:

Inbound routes use destination sip_req_user · fusionpbx/fusionpbx@cb96c4a

This setting allows adjusting the variable that is used for match the inbound number. For many years inbound routes have used destination_number as the variable to match inbound calls. When SIP div...

github.com

And his comment appears to match your problem:

This setting allows adjusting the variable that is used for match the inbound number. For many years inbound routes have used destination_number as the variable to match inbound calls. When SIP diversion header is used the destination_number is not always dependable. The variable sip_to_user is more dependable but still fails with how some providers have implemented the SIP diversion header. It appears the sip_req_user is the seems to be the most dependable.

 

[Nedo]

Github usually. Mark J Crane submitted a change 11 days ago adding {sip_req_user} to the master branch for inbound routes:

Inbound routes use destination sip_req_user · fusionpbx/fusionpbx@cb96c4a

This setting allows adjusting the variable that is used for match the inbound number. For many years inbound routes have used destination_number as the variable to match inbound calls. When SIP div...

github.com

And his comment appears to match your problem:

Very interesting, i am working now on a new instance, i have created a destination from the only gateway that i have registered towards extension 401 registered.
I call from outside but the call drop and the log say:

xxx.alia.it Regex (FAIL) [0583xxx] ${sip_req_user}(gw+1b924325-6b24-43c6-ac7a-xxxxxx) =~ /^(0583xxx)$/ break=on-false
2022-11-09 16:40:01.465308 90.10% [INFO] switch_core_state_machine.c:306 No Route, Aborting
If in inbound route i change the default condition from "condition ${sip_req_user}" to "condition destination_number" and i test calling from outside it work.
I am missing something? Why it not work out of the box?

 

[hfoster]

Long and short of it is your SIP provider. ${sip_req_user} is useless for me, because our SIP trunks send INVITES with the URI in the form of:

INVITE sip:gw+aa21fa11-1803-475f-ad01-8e28312b44d0@[PBXIPAddress]:5080;transport=udp;gw=aa21fa11-1803-475f-ad01-8e28312b44d0 SIP/2.0

Whereas the important information is in the TO field:

To: <sip:4420XXXYYYY@SIPTrunkIP>

You might find that without explictly setting the caller_destination to the SIP TO User, FreeSWITCH will pick the trunk number.

 

[Nedo]

Good morning I still take advantage of your availability.
I was trying to understand more about how the sip stream works, I was analyzing sngrep.
The test situation is this:
I have a trunk registered with a number 0583xxx
I have another number 0564xxx of an isp from which I forwarded the calls to 0583xxx
The flow is this:
Call from outside the 0564xxx <redirect> 0583xxx.
In sngrep i can see this that seems relevant:
History-Info: <sip:0564xxx@clouditalia769.it;user=phone?Privacy=none>;index=1, <sip:0583xxx@clouditalia769.it;user=phone;cause=302>;index=1.1
In the history info i can see the real called number, so the question is: Is possible to obtain this for diversify the destination?
Thank you.

 

[hfoster]

It's the variable: ${sip_history_info} However, from reading about it, it seems to be used mainly in LUA scripts to format what the diversion history looks like.

Are you sure that the called number is not in the SIP To header?

 

[Nedo]

Yes sip to in sngrep report this:
To: <sip:0583@voip.xxx.cloud>

 

[hfoster]

So you want to make sure your inbound routes make use of the ${sip_to_user} field to route to the extensions then. Some providers put it in the VIA, some in the SIP To.

 

[Nedo]

OMG It works... hfoster what to say? thank you very very very much. You helped me in a problem that I had been going through for days.
condition $[sip_history_info} \b0564xxx\b
action transfer desired extension XML

 

[hfoster]

No problem, I will say I don't know exactly if that's what the SIP History is for, so it might get weird in the future. I really think it should be sip_to_user. Oh well! If it works, it works.

 

[Davesworld]

Ah, right. Yeh, I forget what it's like on out of the box installs but I have to ensure that the SIP TO User is treated as the destination number. I've got this default setting which I believe is used for new inbound routes.

View attachment 3136

I can't remember if this is changed either, but the caller-details in the dialplan also sets the caller_destination to the sip_to_user.

View attachment 3137

I reckon this might be your problem.

My issue is similar and started happening when I did the upgrade where this was added. I was able to change it in default settings but in the dialplan I cannot seem to find the section you showed below the destination default setting screenshot. What is it called in the dialplan? I don't wish to hijack this thread. Any other details I will start a new thread but link to this.

 

[hfoster]

Usually right near the top, order 10 or 15. It's set globally and in the domain to capture internal and external calls.

fusionpbx/app/dialplans/resources/switch/conf/dialplan/010_caller_details.xml at master · fusionpbx/fusionpbx

Official FusionPBX - A full-featured domain based multi-tenant PBX and voice switch for FreeSwitch. - fusionpbx/fusionpbx

github.com

fusionpbx/app/dialplans/resources/switch/conf/dialplan/015_caller_details.xml at master · fusionpbx/fusionpbx

Official FusionPBX - A full-featured domain based multi-tenant PBX and voice switch for FreeSwitch. - fusionpbx/fusionpbx

github.com

Setting it in the default settings I believe only applies it for new domains...or possibly new inbound routes. I can't remember exactly. I think it's new inbound routes.

 

[Davesworld]

Usually right near the top, order 10 or 15. It's set globally and in the domain to capture internal and external calls.

fusionpbx/app/dialplans/resources/switch/conf/dialplan/010_caller_details.xml at master · fusionpbx/fusionpbx

Official FusionPBX - A full-featured domain based multi-tenant PBX and voice switch for FreeSwitch. - fusionpbx/fusionpbx

github.com

fusionpbx/app/dialplans/resources/switch/conf/dialplan/015_caller_details.xml at master · fusionpbx/fusionpbx

Official FusionPBX - A full-featured domain based multi-tenant PBX and voice switch for FreeSwitch. - fusionpbx/fusionpbx

github.com

Setting it in the default settings I believe only applies it for new domains...or possibly new inbound routes. I can't remember exactly. I think it's new inbound routes.

Yep, you pointed me in the right direction, it is under caller-details and it shows changes I made in default settings under dialplan. Thank you very much!

 

[Davesworld]

It should be noted that a recent update in the last few days sets the default to ${sip_to_user} since the sip request user was not working out as expected.