Playback disappears after 10 minutes on blind transferred calls (ARI Playback not found error)

When I start a long audio file (around 15 minutes) on a channel after performing a blind transfer, the playback works fine initially. However, if I try to manually stop the playback after about 10 minutes, ARI responds with a “Playback not found” error. But if i try to stop the playabck before 10 minutes, it can be stopped without any error.

For normal (non-transferred) calls, playback continues normally and can be stopped correctly, even when the audio is longer than 10 minutes.

Does anyone know why this issue occurs and how it can be solved?

You’d need to provide logging including showing the events that have occurred and any other ARI requests.

We have encountered an issue with Asterisk playbacks. The problem occurs when playing audio files longer than 10 minutes — the playback cannot be stopped properly once it passes the 10-minute mark. This issue only happens on blind-transferred calls.

Flow

  1. A channel is created, and we start a playback with a duration of more than 10 minutes.

    • If we stop it manually, it works perfectly.
  2. Later, we create a bridge and add another channel to it.

  3. After some time, the second channel performs a blind transfer to a different extension.

    • After receiving the REFER, we remove the first channel from the bridge.

    • Then, we start a new playback (also longer than 10 minutes) on that channel.

  4. Once the playback passes 10 minutes, we try to stop it using ARI, but we get an error: “Playback not found.”

    • The playback continues until the audio file ends, and only then does it stop automatically.

We are using Asterisk 22.5.1 with Node.js and the node-ari-client npm package.

Code snippets

Start playback:

ari.channels.play({
  media: 'file:///var/lib/asterisk/sounds/en/4499a617-c701-4ce8-82d8-3dbccd23d4c1.slin',
  channelId: channel.id,
  playbackId: playback.id
});

Stop playback:

ari.playbacks.stop({ playbackId: playback.id });

Logs from Asterisk CLI

[2025-08-01 13:11:01.484] VERBOSE[1871600][C-000090f6] bridge_channel.c: Channel PJSIP/sipcore-0002e8c3 joined 'simple_bridge' stasis-bridge <BR4fTH2Kak3GklxMtbOBI-p>
[2025-08-01 13:11:59.811] VERBOSE[1871600][C-000090f6] file.c: <PJSIP/sipcore-0002e8c3> Playing '4499a617-c701-4ce8-82d8-3dbccd23d4c1.slin' (language 'en')
[2025-08-01 13:27:57.364] VERBOSE[1871600][C-000090f6] bridge_channel.c: Channel PJSIP/sipcore-0002e8c3 left 'simple_bridge' stasis-bridge <BR4fTH2Kak3GklxMtbOBI-p>

So… two different users, posting the same thing:

Are you working for the same company, or working on the same project? If so - please don’t start multiple threads.

I found a solution for this. Playing audio on bridge doesn’t cause this issue event if the file is longer than 10 minutes. I can stop the playback after 10 minutes without causing any error. But still there is a question why this is not working in channel for this specific case. Tried it on asterisk version 20.10.0 and 22.5.1

Providing logs

{
“type”: “ChannelUserevent”,
“timestamp”: “2025-08-29T14:07:53.655+0000”,
“eventname”: “BlindTransfer”,
“userevent”: {
“extension”: “5002”,
“agentId”: 24,
“practiceId”: 22,
“callId”: “CLpZ1NzY-mi86Cmwmn1A2Dc”,
“timestamp”: “2025-08-29T14:07:53.652528Z”,
“eventname”: “BlindTransfer”
}
}
{
“cause”: 32,
“soft”: true,
“type”: “ChannelHangupRequest”,
“timestamp”: “2025-08-29T14:07:53.661+0000”,
“channel”: {
“id”: “CHr9L_HxZUDt0JOIrZAeIc0”,
“name”: “PJSIP/sipcore-00000097”,
“state”: “Up”,}}
{
“variable”: “BRIDGEPEER”,
“value”: “”,
“type”: “ChannelVarset”,
“timestamp”: “2025-08-29T14:07:53.661+0000”,
“channel”: {
“id”: “CHr9L_HxZUDt0JOIrZAeIc0”,
“name”: “PJSIP/sipcore-00000097”,
“state”: “Up”,}}
{
“variable”: “BRIDGEPVTCALLID”,
“value”: “”,
“type”: “ChannelVarset”,
“timestamp”: “2025-08-29T14:07:53.661+0000”,
“channel”: {
“id”: “CHr9L_HxZUDt0JOIrZAeIc0”,
“name”: “PJSIP/sipcore-00000097”,
“state”: “Up”,}}
{
“type”: “ChannelLeftBridge”,
“timestamp”: “2025-08-29T14:07:53.661+0000”,
“bridge”: {
“id”: “BRmw-JpDycNUZPPEfXqBOWz”,
“technology”: “native_rtp”,
“bridge_type”: “mixing”,
“bridge_class”: “stasis”,
“creator”: “Stasis”,
“name”: “”,
“channels”: [
“1756476457.262”
],
“creationtime”: “2025-08-29T14:07:37.765+0000”,
“video_mode”: “talker”
},
“channel”: {
“id”: “CHr9L_HxZUDt0JOIrZAeIc0”,
“name”: “PJSIP/sipcore-00000097”,
“state”: “Up”,
“protocol_id”: “e8cd8366-2053-4e38-b9d5-047790f28fd8”,
“caller”: {
“name”: “”,
“number”: “”
},}}
{
“type”: “StasisEnd”,
“timestamp”: “2025-08-29T14:07:53.661+0000”,
“channel”: {
“id”: “CHr9L_HxZUDt0JOIrZAeIc0”,
“name”: “PJSIP/sipcore-00000097”,
“state”: “Up”,}}
{
“variable”: “STASISSTATUS”,
“value”: “SUCCESS”,
“type”: “ChannelVarset”,
“timestamp”: “2025-08-29T14:07:53.661+0000”,
“channel”: {
“id”: “CHr9L_HxZUDt0JOIrZAeIc0”,
“name”: “PJSIP/sipcore-00000097”,
“state”: “Up”,}}
{
“type”: “ChannelDestroyed”,
“timestamp”: “2025-08-29T14:07:53.665+0000”,
“cause”: 16,
“cause_txt”: “Normal Clearing”,
“channel”: {
“id”: “CHr9L_HxZUDt0JOIrZAeIc0”,
“name”: “PJSIP/sipcore-00000097”,
“state”: “Up”,}}
{
“type”: “PlaybackStarted”,
“timestamp”: “2025-08-29T14:07:53.697+0000”,
“playback”: {
“id”: “CTzq8NEh0C9BnrHF3FFrUtK”,
“media_uri”: “sound:644615ce-e3b2-486d-9dc0-ad80124931af”,
“target_uri”: “channel:1756476457.262”,
“language”: “en”,
“state”: “playing”
},
}
{
“type”: “Dial”,
“timestamp”: “2025-08-29T14:07:53.710+0000”,
“dialstatus”: “”,
“forward”: “”,
“peer”: {
“id”: “CHsHYHNmNogHDQ1BprYkC6g”,
“name”: “PJSIP/sipcore-00000099”,
“state”: “Down”,}}
{
“type”: “ChannelStateChange”,
“timestamp”: “2025-08-29T14:07:54.039+0000”,
“channel”: {
“id”: “CHsHYHNmNogHDQ1BprYkC6g”,
“name”: “PJSIP/sipcore-00000099”,
“state”: “Ringing”,}}
{
“type”: “Dial”,
“timestamp”: “2025-08-29T14:07:54.039+0000”,
“dialstatus”: “RINGING”,
“forward”: “”,
“peer”: {
“id”: “CHsHYHNmNogHDQ1BprYkC6g”,
“name”: “PJSIP/sipcore-00000099”,
“state”: “Ringing”,}}
{
“cause”: 18,
“type”: “ChannelHangupRequest”,
“timestamp”: “2025-08-29T14:09:04.035+0000”,
“channel”: {
“id”: “CHsHYHNmNogHDQ1BprYkC6g”,
“name”: “PJSIP/sipcore-00000099”,
“state”: “Ringing”,}}
{
“type”: “Dial”,
“timestamp”: “2025-08-29T14:09:04.035+0000”,
“dialstatus”: “NOANSWER”,
“forward”: “”,
“peer”: {
“id”: “CHsHYHNmNogHDQ1BprYkC6g”,
“name”: “PJSIP/sipcore-00000099”,
“state”: “Ringing”,}}
{
“type”: “ChannelDestroyed”,
“timestamp”: “2025-08-29T14:09:04.035+0000”,
“cause”: 18,
“cause_txt”: “No user responding”,
“channel”: {
“id”: “CHsHYHNmNogHDQ1BprYkC6g”,
“name”: “PJSIP/sipcore-00000099”,
“state”: “Ringing”,}}
{
“type”: “StasisStart”,
“timestamp”: “2025-08-29T14:18:08.051+0000”,
“args”: [
“outgoing”,
“”,
“”,
“”,
“”
],
“channel”: {
“id”: “1756477088.267”,
“name”: “PJSIP/sipcore-0000009a”,
“state”: “Ring”,
“accountcode”: “”,
“dialplan”: {
“context”: “internal”,
“exten”: “752”,
“priority”: 7,
“app_name”: “Stasis”,
“app_data”: “stasis-bifrost-dev,outgoing,”
},
},
}
{
“type”: “ChannelStateChange”,
“timestamp”: “2025-08-29T14:18:08.083+0000”,
“channel”: {
“id”: “1756477088.267”,
“name”: “PJSIP/sipcore-0000009a”,
“state”: “Up”,}}
{
“variable”: “BRIDGEPEER”,
“value”: “”,
“type”: “ChannelVarset”,
“timestamp”: “2025-08-29T14:18:08.085+0000”,
“channel”: {
“id”: “1756476457.262”,
“name”: “PJSIP/sipcore-00000096”,
“state”: “Up”,}}
{
“variable”: “BRIDGEPVTCALLID”,
“value”: “”,
“type”: “ChannelVarset”,
“timestamp”: “2025-08-29T14:18:08.085+0000”,
“channel”: {
“id”: “1756476457.262”,
“name”: “PJSIP/sipcore-00000096”,
“state”: “Up”,}
}
{
“cause”: 16,
“type”: “ChannelHangupRequest”,
“timestamp”: “2025-08-29T14:20:13.047+0000”,
“channel”: {
“id”: “1756476457.262”,
“name”: “PJSIP/sipcore-00000096”,
},
}
[2025-08-29 14:20:13.048] WARNING[1068467][C-00000038]: res_stasis_playback.c:280 playback_final_update: 1756476457.262: Playback failed for sound:644615ce-e3b2-486d-9dc0-ad80124931af
[2025-08-29 14:20:13.048] DEBUG[1068467][C-00000038]: res_stasis_playback.c:387 play_on_channel: Channel: PJSIP/sipcore-00000096 already hangup, stop playback

So… did the channel hang up because it wasn’t getting any audio?

Nop channel was hung up manualy

Okay, you’re going to need to provide an actual log with context, describe the complete flow for what you’re trying to achieve and do, and include ARI requests. The more information you provide with context the better for someone to look at if they choose otherwise it results in back/forth as we try to extract details out of you.

The more information and details you provide, the more likely someone will know.

As it is though I suspect it’s something you are doing, or assumptions that aren’t proving true.

ok