Action success monitoring (BYE / transfer)

When the bot ends or transfers a call, several components co-operate: the voice PBX (TelSys) decides and hangs up its leg, the SIP edge (TelPro / Kamailio) sends the BYE or REFER to the carrier with the intended headers, and the carrier acknowledges. A failure anywhere in that chain historically looked identical from the application's point of view — the call "ended" — which made TelSys/Kamailio "ping-pong" incidents (VGWK-136) hard to troubleshoot.

This page documents the end-to-end proof chain available in structured logs today, and the alert set proposed on top of it.

The proof chain for a bot-initiated BYE

A hangup with SIP metadata (reason, custom headers) is proven end to end by three records, joined on sipCallId and trace_id:

Step	Service	Record to look for	Proves
1	telphi (TelSys)	action=sip_egress_intent_published with method=BYE, intentId, indexedBySipCallId=true	The PBX wrote the BYE intent (reason + headers) for the edge to pick up
2	telpro (Kamailio)	xlog line Applied SIP egress intent … for BYE with the same SIP Call-ID	The edge consumed the intent and stamped the outbound BYE
3	telpro	recordKind=sip_message with method=BYE (outbound) followed by the matching statusCode=200	The BYE reached the carrier and was acknowledged

Two adjacent TelSys records complete the picture:

• action=termination_signal_selected — which platform hangup reason/cause mapping was chosen.
• action=hangup_success — the PBX-side hangup API succeeded. This alone is not end-to-end proof; it only confirms the TelSys leg was torn down, not that the carrier received a BYE.

Failure signatures on step 1: sip_call_id_unavailable (intent could not be indexed by SIP Call-ID — the edge will not find it) and sip_egress_intent_failed (Redis write failed; hangup continues fail-open, headers are lost). Header policy enforcement shows up as hangup_headers_sanitized / hangup_headers_dropped before publish.

The same pattern applies to transfers: the intent is published for REFER/INVITE, and the wire proof is the corresponding sip_message records.

How to run the check manually

1. Find the call in SigNoz by its call identifier; see Application and flow logging.
2. Confirm sip_egress_intent_published with method=BYE on the TelSys side and note the sipCallId.
3. Filter TelPro logs by that sipCallId: expect the intent-applied line, then sip_message BYE with a 200.
4. If step 3 shows no outbound BYE, the edge either never saw the dialog (Call-ID mismatch, see sip_call_id_unavailable) or rejected/failed routing — the SIP signaling reference covers response-code interpretation. The Debug SIP ladder shows the same wire view per call.

Proposed alerts (implementation plan)

The spike concluded with this alert set, to be added alongside the existing SigNoz alert pack (call error-rate spike, SIP trunk down, provider failures):

Alert	Signal	Rationale
BYE intent without wire BYE	sip_egress_intent_published (method=BYE) count minus matching TelPro sip_message BYE count over a 5-minute window > 0	Direct detector for the VGWK-136 class of failure: PBX decided to hang up, carrier never saw the BYE
Egress intent publish failures	Rate of sip_egress_intent_failed + sip_call_id_unavailable > 0 over 15 minutes	Headers/reasons silently lost even though calls still end; early indicator of Redis or Call-ID linking trouble
Header drop spike	Rate of hangup_headers_dropped above baseline	A bot or flow suddenly sending invalid headers — usually a config regression on the bot side

These are intentionally count-based on structured log events, so they need no new instrumentation — only alert definitions. Building them is follow-up implementation work pending VF approval of this plan.

See also

• SIP signaling reference — response codes and ladder capture.
• Monitoring in SigNoz — existing alert pack and query how-to.