We just completed a DID number port from our previous carrier (Vonage) to Genesys Cloud Voice. The porting confirmation came through on May 12th and the number shows as “Active” in Admin > Telephony > DID Numbers. The number is assigned to an Architect inbound call flow.
The problem: when we call the ported number from an external phone, it rings endlessly and eventually goes to the carrier’s generic voicemail. The call never reaches Genesys Cloud. No interaction appears in the admin UI, no entry in the call logs, nothing.
I have verified:
- The DID is assigned to the correct flow in Admin > Call Routing
- The flow is published and active (other DIDs on the same flow work fine)
- The number format matches E.164 (+1XXXXXXXXXX)
- Genesys Cloud Voice is the telephony provider (not BYOC)
When I call the number from a Genesys Cloud station (internal call), it routes correctly through the flow. It is only external inbound calls that fail to arrive.
This is blocking our production cutover. We are training 45 agents on the new platform and cannot go live without this number. Has anyone experienced a ported DID not receiving external inbound calls despite showing as active in the admin panel?
This is almost always a DNS/SRV record propagation issue on the carrier side, not a Genesys Cloud configuration problem. Let me walk through the diagnosis path!
When a number is ported to Genesys Cloud Voice, the losing carrier (Vonage) must update their LNP (Local Number Portability) database entry to point the number to the Genesys Cloud Voice carrier (Bandwidth/Intelemedia depending on your region). This update propagates through the PSTN routing fabric, but it does not happen instantaneously.
Step 1: Verify the port is complete at the PSTN level. Call your number from a mobile phone and check the audio carefully. If you hear Vonage branded hold music or voicemail, the LNP record has not fully propagated. If you hear dead air or a fast busy, the record updated but something else is wrong.
Step 2: Check the Genesys Cloud Voice trunk status. Go to Admin > Telephony > Trunks and find the Genesys Cloud Voice trunk. Click on it and check the “Health” tab. If it shows any SIP registration failures for your DID range, the number might not be properly provisioned on the Genesys side.
Step 3: Open a ticket with Genesys Cloud Voice support (not regular GC support - this is a different team). Include the DID, the porting confirmation number, and the losing carrier details. They can check the Bandwidth/Intelemedia provisioning directly.
In our MuleSoft integration project, we ported 200 numbers and about 15% took 48-72 hours beyond the confirmed port date to actually start receiving calls.
From an operations perspective, this is a known risk with number porting that needs to be factored into any migration timeline. We always schedule ports for a Friday and plan a Monday go-live to give the weekend as buffer for LNP propagation.
The suggestion to contact Genesys Cloud Voice support specifically is correct. The regular Genesys Cloud support team cannot see carrier-level provisioning. You need to request a “DID provisioning verification” from the voice team. They can force-refresh the carrier routing table on their end.
For your immediate go-live blocker: set up a temporary call forwarding from your old Vonage number to a different Genesys Cloud Voice DID that is already working. This buys you time while the port propagates. Vonage can configure unconditional call forwarding on the ported number even while the port is in progress.
One more thing to check: if you are porting number to Genesys Cloud Voice in region outside of North America, the porting process uses different carrier partner. For EMEA it is Vodafone/BICS, for APAC it is Telstra. Each has different propagation time.
Also verify in Admin > Telephony > Number Management that the number does not have “Call Forward” or “Voicemail” configured at the platform level. There is a rarely-used feature where Genesys Cloud Voice numbers can have platform-level voicemail that intercepts calls before they reach the Architect flow. If someone accidentally enabled this during testing, it would explain why external calls go to a generic voicemail.
Go to the DID detail page and check if there is a “Voicemail” toggle. If it exists and is enabled, disable it and test again.