Genesys Cloud - Developer Community!

Hi all,

We're building automatic retry logic for outbound sales callbacks (created via POST /api/v2/conversations/callbacks) and need to reliably detect when the customer did not actually answer. We've hit a wall and would appreciate input before redesigning.

Setup: Agent-first ACD callback, voice, mobile numbers in Colombia.

Test performed: We placed a callback to our own mobile and deliberately did not answer. It rang ~33 seconds, the carrier voicemail picked up, the agent heard the greeting and hung up ~13 seconds later.

Observed on v2.analytics.conversation.{id}.metrics:

18:34:09.176  nOffered
18:34:16.835  tAnswered
18:34:17.154  tAcd
18:34:17.461  nOutbound, tTalk
18:34:19.744  tContacting, tFirstDial
18:34:53.150  nConnected, tDialing, tFirstConnect   <-- carrier voicemail answered
18:35:00.212  tConnected, tTalk, tActiveCallback
18:35:06.296  tAcw, tHandle, tTalkComplete, tActiveCallbackComplete

tCallbackNotReached was never emitted. Genesys recorded this callback as successful.

What we have ruled out:

• tCallbackNotReached - appears to fire only when nothing answers at all. Since virtually every mobile here has carrier voicemail enabled by default, this covers almost none of our real "no answer" cases.
• tFirstConnect and participant connectedTime - populated identically whether a human or a voicemail answers.
• WebSocket v2.routing.queues.{id}.conversations.callbacks - same limitation; the customer participant reaches connected either way.
• EventBridge analytics detail events - we checked the published schemas for .outbound, .customer.start, .customer.end, .acd.start and .acd.end; none carry dispositionAnalyzer / dispositionName.

We understand agent-first callbacks don't run call analysis, so the information may simply not exist. Our questions:

1. Is there any supported way to obtain answering machine detection on an callback?
2. With customer-first callbacks, is the AMD result exposed anywhere beyond routing to an Architect flow - a field on the conversation/participant, or an analytics dimension indicating machine vs. live voice? Or is a flow outcome the only way to surface it?
3. In customer-first, does tCallbackNotReached fire when carrier voicemail answers, or is that also counted as delivered?
4. In customer-first, does each automatic retry reuse the same conversationId or create a new one?
5. Has anyone solved this without moving to Outbound Dialer campaigns?

Wrap-up codes are our current fallback, but we'd rather not depend on agent input.

Thanks!

Hi Raphael,

Thank you, this was really helpful, and we followed your suggestion all the way through. Sharing the results in case they're useful to others.

1. The SIP Traces API does not expose headers

GET /api/v2/telephony/siptraces returns only per-message metadata (method, ruriUser, ruriDomain, fromUser, toUser, callid, cseq, userAgent). There is no header content, so Diversion / History-Info / Reason cannot be evaluated from this endpoint even if the carrier does send them.

For our unanswered test call it returned just the method sequence:

INVITE → 100 → 180 → 183 → 200 → ACK → BYE → 200

2. So we pulled the PCAP instead

Our trunk is BYOC, so the PCAP was available from the Interactions Detail page. We inspected every message in the dialog.

No Diversion, no History-Info, no Reason anywhere.

The revealing part is that the carrier explicitly advertises support for the extension in every response:

SIP/2.0 180 Ringing
Supported: 100rel,timer,replaces,histinfo
To: "Mobile Number, Colombia" <sip:57XXXXXXXXX@x.x.x.x>;tag=BD2ECEB

histinfo is History-Info (RFC 7044). So this is a signaling policy decision on the carrier's side, not a technical limitation, they can send it and choose not to.

3. Why it ends up indistinguishable

The remote To tag (BD2ECEB) is identical across 180, 183 and 200 OK a single dialog with a single remote endpoint from Genesys' perspective. The forwarding to voicemail happened entirely inside the carrier's network. Genesys never saw a redirect, a retarget, or a change of destination.

Conclusion: at this point there is no viable path for us. The carrier doesn't signal the forwarding, and the SIP data isn't reachable programmatically. 

Thanks again for pointing us at the SIP angle.