A while ago we set-up Translate on our outbound trunks so all calls would be sent to our carriers in e164 (and to help standardise numbers in CDRs).
We received a customer complaint about Call Forwarding not working not long after we implemented translate. The customer didn't end up persisting with Call forward, so we put it to one side. Different customer, new complaint so we began looking into it a bit more again today.
In a nutshell;'
When we set call forward, either through the feature codes (*72 etc) or through the fusionpbx gui (e.g. Accounts->Extensions->1005->Call Routing), the call forward is set in the gui, but when a call comes into that extension, the forward fails. Watching fs_cli as the dialplans run through, we've noticed that it sets all the variables for call forwarding correctly e.g.
However, when it attempts to send it out via a trunk, we see the following:
The bit that's wonky is the "sofia/external/" bit - it should have the number 61288889999 after the trialing '/' e.g. "sofia/external/61288889999".
Checked all the obvious places and all seems correct. The one thing I did notice when looking editing the extension and clicking on the 'advanced' button, it shows a Dial String box, which contained the following:
We noticed at the end of that string it contains '${translated}'. It appears directly related to the translate module, as when we manually update this to the number '61288889999', the forward works as expected.
It appears that the call forward feature takes the 'bridge' command from the dialplan that matches and creates this dial-plan for the extension, but not looking at the rest of the dialplan and thus not applying the translate rule.
We implemented translate based on the Freeswitch wiki and works great for calls, just not for call forwarding.
Has anyone else come across this? Is this likley to be a fusionpbx bug or a freeswitch bug? I've assumed that fusionpbx rewrites the dialplan for the extension, but could be wrong?
We received a customer complaint about Call Forwarding not working not long after we implemented translate. The customer didn't end up persisting with Call forward, so we put it to one side. Different customer, new complaint so we began looking into it a bit more again today.
In a nutshell;'
When we set call forward, either through the feature codes (*72 etc) or through the fusionpbx gui (e.g. Accounts->Extensions->1005->Call Routing), the call forward is set in the gui, but when a call comes into that extension, the forward fails. Watching fs_cli as the dialplans run through, we've noticed that it sets all the variables for call forwarding correctly e.g.
Code:
2018-01-25 15:37:08.606640 [DEBUG] mod_dptools.c:1527 SET sofia/internal/1006@domain.com:5060 [forward_all_enabled]=[true]
EXECUTE sofia/internal/1006@domain.com:5060 set(forward_all_destination=61288889999)
2018-01-25 15:37:08.606640 [DEBUG] mod_dptools.c:1527 SET sofia/internal/1006@domain.com:5060 [forward_all_destination]=[61288889999]However, when it attempts to send it out via a trunk, we see the following:
Code:
018-01-25 15:37:08.798883 [DEBUG] sofia.c:7042 Channel sofia/external/ entering state [terminated][404]
2018-01-25 15:37:08.798883 [NOTICE] sofia.c:8216 Hangup sofia/external/ [CS_CONSUME_MEDIA] [UNALLOCATED_NUMBER]
2018-01-25 15:37:08.798883 [DEBUG] switch_core_state_machine.c:584 (sofia/external/) Running State Change CS_HANGUP (Cur 2 Tot 52253)
2018-01-25 15:37:08.798883 [DEBUG] switch_core_state_machine.c:850 (sofia/external/) Callstate Change DOWN -> HANGUP
2018-01-25 15:37:08.798883 [DEBUG] switch_core_state_machine.c:852 (sofia/external/) State HANGUP
2018-01-25 15:37:08.798883 [DEBUG] mod_sofia.c:438 Channel sofia/external/ hanging up, cause: UNALLOCATED_NUMBERThe bit that's wonky is the "sofia/external/" bit - it should have the number 61288889999 after the trialing '/' e.g. "sofia/external/61288889999".
Checked all the obvious places and all seems correct. The one thing I did notice when looking editing the extension and clicking on the 'advanced' button, it shows a Dial String box, which contained the following:
Code:
{presence_id=61288889999@domain.com,instant_ringback=true,domain_uuid=72ed5fb3-83ae-45fe-a40f-954a390aa968,sip_invite_domain=domain.com,domain_name=domain.com,domain=domain.com,extension_uuid=f63d8250-fdba-4a33-b141-047d3bfef34a,toll_allow='',sip_h_Diversion=<sip:1005@domain.com>;reason=unconditional,sip_h_X-accountcode=domain.com,accountcode=domain.com}sofia/gateway/e3a25da3-1b7c-4303-8fff-ea50d42585cf/${translated}We noticed at the end of that string it contains '${translated}'. It appears directly related to the translate module, as when we manually update this to the number '61288889999', the forward works as expected.
It appears that the call forward feature takes the 'bridge' command from the dialplan that matches and creates this dial-plan for the extension, but not looking at the rest of the dialplan and thus not applying the translate rule.
We implemented translate based on the Freeswitch wiki and works great for calls, just not for call forwarding.
Has anyone else come across this? Is this likley to be a fusionpbx bug or a freeswitch bug? I've assumed that fusionpbx rewrites the dialplan for the extension, but could be wrong?