CDR fields empty and Hangup fired from AudioSocket channel when call routed to Stasis app

Asterisk Asterisk APIs
1

Hi, we’re running Asterisk 20(via MikoPBX) with a Stasis application connected via AudioSocket. When a call is routed into Stasis, the final AMI Hangup event comes from the AudioSocket channel instead of the original PJSIP channel — and as a result, CDR fields are empty.

Normal call (internal → internal), SQLite CDR:

src_chan = PJSIP/554-00000003

dst_chan = PJSIP/666-00000004

to_account = 666

dialstatus = ANSWERED

Call routed to Stasis (both internal and external), SQ Lite CDR:

src_chan = PJSIP/554-00000006

dst_chan = (empty)

to_account = (empty)

dialstatus = (empty)

dst_num = 123 ← this is filled

AMI Hangup — normal call:

Channel: PJSIP/554-00000003

CallerIDNum: 554

ConnectedLineNum: 666

CDR(lastapp)=Dial

CDR(src)=554

CDR(dst)=666

AMI Hangup — Stasis call:

Channel: AudioSocket/ 127.0.0.1:8090-b58fcafb-. ..

CallerIDNum:

ConnectedLineNum: 554

CDR(lastapp)=Stasis

CDR(src)=

CDR(dst)=s

Current dialplan:

exten => 123,1,NoOp(User calling AI)

same => n,Answer()

same => n,Set(CONNECTEDLINE(num)=ai_agent)

same => n,Gosub(dial_answer,s,1)

same => n,Stasis(asterisk-ai-voice-agent)

same => n,Hangup()

Questions:

1. Is this expected Asterisk behavior when routing to Stasis — that the final Hangup comes fro m the AudioSocket channel rather than PJSIP?

2. Is there any way to influence which channel generates the final Hangup event?

3. Is there a dialplan-level workaround to properly populate `dst_chan` , `CDR(src)`, `CDR(dst)` for Stasis scenarios?

We tried setting CDR variables and firing a UserEvent before Stasis — the UserEvent appeared in AMI with correct data, but the final Hangup still comes from AudioSocket with empty fields.

Thanks!

2

When something is hung up it generates the event, so if both channels are hung up then there would be two events. It depends what has happened to the channels.

You haven’t stated what actually happens in ARI, how channels are controlled, etc, which are important when it comes to ARI applications to be able to answer questions.

3

Thanks for the reply!

To be honest, we don’t have full visibility into the ARI application internals — it’s a third-party AI voice agent. What we can observe from the outside:

— The original PJSIP channel receives the call — The Stasis app creates an AudioSocket channel (127.0.0.1:8090) — We do see two Hangup events: one from the original PJSIP channel, and one from AudioSocket — The PJSIP Hangup fires first and contains correct CDR data — The AudioSocket Hangup fires last with empty CDR fields

Our integrations (third-party 1C CRM connectors) appear to pick up the last Hangup event, which is AudioSocket — and that’s where the problem lies.

Is there a way to ensure the PJSIP channel’s Hangup is the one that carries complete CDR data, regardless of what the ARI app does internally? Or is the CDR outcome entirely determined by the ARI application’s channel handling?

4

What the ARI application does controls CDR things, and you can’t guarantee ordering either.

5

Thank you, this really helped!

Just to make sure I understood correctly :

The CDR fields (src, dst, channel) are controlled by what the ARI application does with its channels internally. In our case the Stasis app creates an AudioSocket channel for the actual conversation — that’s by design, since it’s a realtime AI voice agent. The final Hangup comes from that AudioSocket channel with empty CDR fields, and there’s no way to change that from the dialplan side without modifying the ARI application itse lf.

Ordering of Hangup events is also not guaranteed, so relying on event order is not a viable approach either.

Thanks again!

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.