[bug]: When there is no audio stream on the spyee channel, the spyer channel could not hangup by Hangup action.

Tinet-mucw commented 3 weeks ago

Severity

Trivial

Versions

18.10

Components/Modules

app_chanspy

Operating Environment

centos 8

Frequency of Occurrence

None

Issue Description

When a call is sent to Asterisk and the Dial application is executed in the dial plan to forward the call to the callee, the callee is actually a robot. For some reason, there is no audio stream on the incoming channel. After the robot plays the welcome message, it no longer plays any audio stream.

At this point, an originate action is used to create a channel to spying the incoming channel. After a few seconds, the spyer channel sends a hangup action, but the hangup fails until the incoming channel hangs up.

The issue with the inability to hang up occurs because the spy_audiohook status does not change from AST_AUDIOHOOK_STATUS_SHUTDOWN to AST_AUDIOHOOK_STATUS_DONE. When writing frames to the audiohook, if the status is checked as AST_AUDIOHOOK_STATUS_SHUTDOWN, it will be set to AST_AUDIOHOOK_STATUS_DONE.

However, since there is no audio stream on the spyee channel, the audiohook status remains unchanged. Only when the spyee channel is hung up does the audiohook status update during its destruction.

Relevant log output

(gdb) bt
#0  0x00007f152f31f74a in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x000000000051f89a in __ast_cond_timedwait (filename=0x6622ba "audiohook.c", lineno=1178, 
    func=0x6627d0 <__PRETTY_FUNCTION__.14555> "ast_audiohook_trigger_wait", cond_name=0x6622c6 "&audiohook->trigger", 
    mutex_name=0x6622a9 "&audiohook->lock", cond=0x7f152dc11728, t=0x7f152dc116f0, abstime=0x7f152dc11500) at lock.c:653
#2  0x000000000046f9d3 in ast_audiohook_trigger_wait (audiohook=0x7f152dc116f0) at audiohook.c:1178
#3  0x000000000046d712 in ast_audiohook_detach (audiohook=0x7f152dc116f0) at audiohook.c:583
#4  0x00007f14cb529999 in channel_spy (chan=0x7f1504017030, spyee_autochan=0x7f1510021e30, volfactor=0x7f152dc157cc, fd=0, 
    user_options=0x7f152dc1781d, flags=0x7f152dc17820, exitcontext=0x7f152dc16470 "") at app_chanspy.c:915
#5  0x00007f14cb52af25 in common_exec (chan=0x7f1504017030, flags=0x7f152dc17820, volfactor=0, fd=0, user_options=0x7f152dc1781d, 
    mygroup=0x0, myenforced=0x0, spec=0x7f152dc16700 "PJSIP/minisbc_test_agent-00000007", exten=0x0, context=0x0, mailbox=0x0, 
    name_context=0x0) at app_chanspy.c:1220
#6  0x00007f14cb52b9e0 in chanspy_exec (chan=0x7f1504017030, data=0x7f152dc179a0 "PJSIP/minisbc_test_agent-00000007,bqE")
    at app_chanspy.c:1379
#7  0x000000000055160d in pbx_exec (c=0x7f1504017030, app=0x3ac2880, data=0x7f152dc179a0 "PJSIP/minisbc_test_agent-00000007,bqE")
    at pbx_app.c:495
#8  0x000000000053ce39 in pbx_extension_helper (c=0x7f1504017030, con=0x0, context=0x7f1504017aa0 "spy", exten=0x7f1504017af0 "6000001", 
    priority=9, label=0x0, callerid=0x7f1504016fd0 "01089193631", action=E_SPAWN, found=0x7f152dc1ac4c, combined_find_spawn=1) at pbx.c:2945
#9  0x0000000000540e0b in ast_spawn_extension (c=0x7f1504017030, context=0x7f1504017aa0 "spy", exten=0x7f1504017af0 "6000001", priority=9, 
    callerid=0x7f1504016fd0 "01089193631", found=0x7f152dc1ac4c, combined_find_spawn=1) at pbx.c:4214
#10 0x0000000000541b0c in __ast_pbx_run (c=0x7f1504017030, args=0x0) at pbx.c:4388
#11 0x00000000005434ad in ast_pbx_run_args (c=0x7f1504017030, args=0x0) at pbx.c:4775
#12 0x00000000005434d7 in ast_pbx_run (c=0x7f1504017030) at pbx.c:4784
#13 0x000000000054b86a in pbx_outgoing_exec (data=0x7f1504014010) at pbx.c:7708
#14 0x00000000005dfdf7 in dummy_start (data=0x7f150400e430) at utils.c:1574
#15 0x00007f152f31917a in start_thread () from /lib64/libpthread.so.0
#16 0x00007f152e2d4dc3 in clone () from /lib64/libc.so.6

(gdb) list
578             }
579
580             ast_audiohook_update_status(audiohook, AST_AUDIOHOOK_STATUS_SHUTDOWN);
581
582             while (audiohook->status != AST_AUDIOHOOK_STATUS_DONE) {
583                     ast_audiohook_trigger_wait(audiohook);
584             }
585
586             return 0;
587     }

Asterisk Issue Guidelines

[X] Yes, I have read the Asterisk Issue Guidelines

Tinet-mucw commented 3 weeks ago

There is also a bug in WaitForCondition under certain conditions that causes audio stuttering. I'm not sure if it's necessary to raise this issue.

Tinet-mucw commented 3 weeks ago

I feel this bug shouldn’t be raised, because if we skip this wait, writing frames to the spyee channel afterward could cause a crash. The solution I can think of is writting a silent packet to the spyee channel.

or call ast_audiohook_remove?

asterisk / asterisk