Trunk Group - Number Change Propagation

Voice & Telephony
1

Hey all,

So we just finished up a number port for a new client - 20 numbers total, coming in on a new trunk group, US-West-01. Registration’s solid, SIP options are passing, everything looks good on the trunk config side. But the numbers aren’t showing up as available in outbound routing - Architect flows are still trying to route to the old numbers.

It’s like there’s a delay between the number change being completed in the number management portal and it actually propagating to the routing logic. We’ve seen this before, but it’s usually just a few minutes. This time it’s been over an hour and it’s still broken. The client’s pretty upset, obviously.

We’ve tried the usual stuff - flushing the cache on the trunk group itself (the little recycle bin icon, does jack all most of the time tbh), toggling the ‘active’ status on the trunk, even just re-saving the trunk configuration. Nothing seems to be shaking things loose.

I’m poking around in the API logs, and I’m seeing successful responses when I query the trunk details via the API. It shows the new numbers associated with the trunk, but it’s like Architect isn’t picking them up. I’m using the Genesys Cloud Resource SDK for JavaScript, version 3.1.2 - I’m not seeing anything obvious in the SDK itself. The API calls are succeeding, but the UI isn’t reflecting the changes.

Anyone else run into something similar? We’ve got a workaround in place - manually updating the DNIS values in all the outbound flows, but that’s… not ideal.

The client’s numbers are all in the E.164 format, no weird characters or anything. The trunk group is set to use North American Numbering Plan, standard stuff. We’re running a pretty standard outbound dialing strategy - a simple dial plan expression that selects the outbound trunk group and then tries to match the dialed number to a DNIS.

I’m wondering if it’s something to do with the carrier - we’re using Bandwidth. They’re usually pretty reliable, but maybe there’s some caching on their end. I’ll reach out to their support, but figured I’d see if anyone’s experienced a similar delay with number changes.

2

Is the trunk group configured with the correct CLID for outbound dialing? Because that’s usually where this breaks down. Think of it like a postal service - if the return address is wrong, the letter gets kicked back. The numbers are registered, the system knows they exist, but it doesn’t know which trunk to use when outbound calls happen.

You need to check the trunk group’s outbound settings. Specifically, the “Caller ID” field. It needs to match the number range you ported. It isn’t automatic. The system doesn’t just magically infer it.

To update it via the API, you’ll need to use the trunk settings. The payload looks like this:

{
 "name": "Your Trunk Group Name",
 "outboundSettings": {
 "callerId": "YourNewNumberRange",
 "allowedCallerIdPrefixes": ["YourNewNumberRange"]
 }
}

Don’t forget the allowedCallerIdPrefixes - that’s a common mistake. It needs to mirror the callerId.

edit: It’s also worth checking the associated phone numbers, make sure the ‘Available for Outbound’ toggle is enabled for each number within the number management portal. It seems obvious, but it’s always the simple thing.

3

Right. Number propagation isn’t always instant - we’ve found it can take up to fifteen minutes, even after the number management portal shows ‘complete’. Is the trunk group using AWS ect as the carrier?

If so, check the flow logic - we had a similar issue last year where the outbound dial plan wasn’t picking up the new numbers until a CloudFormation stack update forced a re-sync. It’s a pain, but sometimes it’s faster to redeploy than wait it out.

1 Like