Hi Prasoon,
We evaluated a very similar architecture recently and one important thing we learned early is that this integration behaves much more like a SIP federation scenario than a native Genesys ↔ Salesforce integration.
From the Genesys side, your understanding is correct:
typically you end up introducing:
a dedicated Site
a BYOC PBX trunk
DNIS-based routing in Architect
and controlled call handoff logic
One important clarification:
Genesys Cloud Voice and BYOC PBX can coexist without breaking the existing managed telephony setup, because the routing domain is isolated by Site/Trunk configuration. So operationally the risk is usually low if you keep the new SIP routing segregated properly.
That said, we strongly recommend creating:
dedicated trunks
dedicated sites
dedicated DIDs/test numbers
during the POC phase to avoid accidental routing overlap with production voice traffic.
For SIP transport, we had the most stable behavior using:
TLS
SRTP
G.711 μ-law
with conservative codec negotiation enabled.
Some SBCs advertised additional codecs that caused intermittent negotiation failures during transfers/re-invites, especially when the bot escalated back to a human queue.
One hidden complexity is actually the return escalation leg.
The cleanest pattern we found was:
Genesys → Salesforce Bot → return to dedicated Genesys ingress DNIS
instead of trying to "resume" the original SIP dialog directly.
In practice, treating the escalation as a controlled re-entry into Genesys routing logic produced much more predictable behavior operationally.
That allowed Architect to:
reattach routing logic
set participant data
perform queue selection
restore context
apply reporting logic
without relying on fragile SIP transfer assumptions.
Another important consideration:
preserving context across the handoff becomes critical.
Because once the bot escalates back, Genesys does not automatically inherit all conversational metadata unless you explicitly persist and restore it.
The implementations we saw working best usually persisted:
original ANI
bot outcome
intent detected
authentication state
collected entities
conversation correlation IDs
either via SIP headers, external context store, or Salesforce-side APIs before returning to Genesys.
One thing I would validate very early:
how Salesforce Agentforce handles SIP REFER versus new INVITE escalation behavior.
That distinction can impact:
call recording continuity
conversation IDs
transcription continuity
reporting attribution
agent leg visibility
transfer metrics
quite significantly.
Regarding licensing/costs:
typically BYOC PBX itself does not replace Genesys Cloud Voice, but introducing external SIP connectivity may introduce:
carrier/SBC costs
external routing costs
Professional Services involvement
possibly additional telephony architecture requirements
depending on the environment.
The biggest operational risk we observed was not telephony itself, but troubleshooting ownership.
Once calls traverse:
Genesys → Salesforce → external SBC → back to Genesys
isolating failures becomes much harder unless you already have:
SIP tracing
call correlation IDs
centralized logging
clear SIP ladder visibility
end-to-end observability
in place.
Architecturally, the pattern is definitely possible, but I would strongly recommend designing it as:
loosely coupled SIP orchestration
with explicit context persistence
rather than trying to make both platforms behave like a single native voice stack.
That usually scales and debugs much better in production.
------------------------------
Gabriel Garcia
NA
------------------------------