Flowroute - Outbound calling with multiple DIDs

[residential]

Hi,

Can anyone provide some guidance on how to configure outbound rules for a single Flowroute trunk that has multiple DIDs assigned to it? Our inbound routing and text messaging for all DIDs is working fine but all outbound calls continue to route over the trunk using the primary number, not the individual DIDs that are assigned to various extensions.

Extension Settings
Assigned DID number: Each extension is configured with its own dedicated DID that was setup under Voice & Chat / Trunk / DID Numbers
Outbound Caller ID: Each extension is configured with its own dedicated DID, the same as the assigned DID number.

Voice & Chat / Trunk / Options / Caller ID Control
I do have the following set based on my findings: From: Display Name to: "OutboundCallerId"

Outbound Rules
I also tried creating a new outbound rule using "Calls from extension(s)" and filling in one extension that has an assigned DID, then selecting the same trunk for route 1 and then filling in the "Outbound caller ID" field for that user/extension with the assigned DID number. After saving I ensured we tested with the correct set length of digits for that rule from that extension but it still routed that call over the main trunk number.

I'm not sure what else to try at this point. I want to make sure whatever solution we come up with is scalable for many DIDs.

Thanks

 

[positron]

DIDs from Flowroute are formatted E.164 (+1xxxxxxxxxx) but outbound caller ID should not contain the leading + for domestic calls. It used to be an open field to type the outbound caller ID for the extension, but now you have to select from a DID list, so the formatting may not work.

You can fix it in the Flowroute trunk setup in Options, Reformat incoming or outgoing caller ID.
Add an Outbound rule
- Source pattern: (+1)(..........)
- Replace pattern: 1\2

The source pattern has 10 periods in the second group.

Also, you can reset the "From: Display Name" to "OutboundCallerId" to default as that just affects the name field, not the number.

 

[residential]

positron,

Thanks for your feedback. My DIDs are configured in e164 format with the leading +. I followed your suggestions and made the changes but continue to experience the same problem for outbound calling. Anything else you can think of I might be missing?

 

[residential]

One more piece of information to share.... I am currently prepending my tech prefix to all outbound calls in my outbound route. I want to change this soon but it's required at this time. Could this be the issue?

 

[positron]

How long ago did you set up the Flowroute trunk with 3CX, and what version of 3CX are you using now? There was a change to the trunk template in the past which mostly affected the incoming DID format. I know the current template assumes it is set up for registration. Is your Flowroute setup using the 3CX template?

I can't say if it's related to the tech prefix, but I wouldn't think so as it shouldn't affect the outbound caller ID. I tested the tech prefix auth method a long time ago and abandoned it when the tech prefix appeared in the dialed number in call records.

You may need to do a packet capture and check the "Contact" field in the message header of the INVITE packet to see if it has the correct outbound DID and is formatted properly.

 

[residential]

It's been 3-4 years now since the trunk was created. I believe I used a template but it sounds like it may have changed. I'm currently on 3CX v20 Update 4.

Yeah, I need to make that change soon too. Everyone hates the call records as they appear now.

I'll temporarily disable the current trunk and create another trunk instance using the new template and test again.

Thanks!

 

[leejor]

If you put a correctly formatted caller ID in the trunk settings of the outbound rules, is that number sent? The 3CX Activity Log, in Verbose, should show you what is being sent, if it isn't to your providers liking, then it's probably overwritten.

 

[residential]

Just to follow up on this thread. I was able to fix the problem by deleting the existing trunk configuration and re-creating one using the updated built-in Flowroute template. While it looked identical within the 3CX UI, there were obvious backend changes that occurred when using the newer template.

Thanks to all getting things resolved for me, cheers!