BUG : Sort of - Ring Groups Forwarding off call does not match e.164 requirements

FreePBX Applications / Modules
1

BUG : Or at least not expected - provider required - behavior - “FreePBX 17.0.28”

We have a client that is now using an AI bot to take calls. If no one at their office answers the phone, they want us to forward the unanswered call to their new AI Bot. We got it to work, but it was very much trial and error.

I set up a Misc Destination, and put the AI Bot phone number into it. FYI, The Misc Destination number does NOT permit the + Sign in the number to be e.164 compliant. (inconvenient, but Dial Patterns resolves that)

We have a ring Group set up for their 4 office phones. No One answers.

In the “Destination if no answer” - I put in the Misc Destination.

a) The call fails to forward to the AI Bot, as our SIP provider is seeing the INBOUND caller ID as the original person that is calling in, and the forwarding of a call is considered an outbound call. SO - the outbound caller ID MUST match the clients account CallerID.

b) (the bug) In the Ring Group, I change “Change External CID Configuration” to “Use Dialed Number: Transmit the number that was dialed as the CID for calls coming from outside” - We would assume the phone number the person dialed - the clients account - matches the caller ID. - This also failed. When I look at the SIP provider logs, the number was correct, but it was missing the + sign, even though the “call event logging” shows the plus sign in the call log as the “Dialed” number. So using the preset “Use Dialed Number” - does NOT meet e.164 requirements as an outbound caller ID, and since it is a caller ID it does not pass though “Dial Patterns”

c) We had to set “Change External CID Configuration” to “Fixed Value” where we could put in the + sign to be e.164 compliant. Then the call forwarding worked.

So, I think that "Use Dialed Number - needs to be updated in FreePBX to be e.164 compliant.

Bonus, It treats the call forwarding as a pass through (not a hand off) and still records the entire conversation on our local system. So if there is a problem with the AI bot interpreting something, the client can still listen to the entire conversation from our system

2

You can prefix the number in Misc Destinations or Ring Groups with whatever you like, for example 1000018884333620, and match it in a dedicated outbound route for the AI Bot. From there, set the Caller ID and strip and prepend digits as required in the dial patterns.

3

Not a bug, it works as it should be working. Use Dialed Number and Force Dialed Number basically set the same value on different variables. Here’s their dialplan for the function. The key thing to note here is ${FROM_DID} is set to the number match of the Inbound Route. So if the number match is 1808NXXXXXX then that’s the value of ${FROM_DID}. If the number match is 808NXXXXXX then that’s that value. If the number match was +1808NXXXXXX then that’s the value.

Then again, if you have an old school PRI style setup the Inbound Route might just be the last 4 digits of a number then that would be the value of ${FROM_DID}.

If your Inbound Route is E.164 it will accept it and pass it through.

exten => s-did,1,ExecIf($["${REGEX("^[\+]?[0-9]+$" ${FROM_DID})}" = "1"]?Set(__REALCALLERIDNUM=${FROM_DID}))
exten => s-did,n,Return()

exten => s-forcedid,1,ExecIf($["${REGEX("^[\+]?[0-9]+$" ${FROM_DID})}" = "1"]?Set(__TRUNKCIDOVERRIDE=${FROM_DID}))
exten => s-forcedid,n,Return()

Basically, whatever format your Inbound Route match is using is the format the CallerID number will be in when using “Dialed Number” or “Force Dialed Number”. Since that match can be variable length and not even a full DID format, it makes what @kierknoby suggested the best solution for this. Prefix the destination and set the callerID format in the outbound route