[asterisk-bugs] [JIRA] (ASTERISK-29393) MixMonitor B option can cause fallthrough errors (and not work)

[Asterisk Team (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Asterisk Team updated ASTERISK-29393:
-------------------------------------

    Assignee: Asterisk Team  (was: N A)
      Status: Triage  (was: Waiting for Feedback)

> MixMonitor B option can cause fallthrough errors (and not work)
> ---------------------------------------------------------------
>
>                 Key: ASTERISK-29393
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29393
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_mixmonitor
>    Affects Versions: 18.3.0
>         Environment: Debian 10
>            Reporter: N A
>            Assignee: Asterisk Team
>         Attachments: debug.txt
>
>
> I'm not sure how much of this is related to ASTERISK-24397, but it seems to be a bit different, so I'm filing this just in case.
> Two things:
> 1. When using the B option, I don't hear a beep every 15 seconds on either the calling or called channel as the documentation suggests, or in the finalized wav recording. But this might very well be because of the limitations of ChanSpy discussed in ASTERISK-24397. I gave up using ChanSpy and had to develop a hacky ConfBridge workaround for certain applications for the same reason. However, even with constant media flow, the beeps do not sound. Per the CLI printout below, they are getting played, but not audibly into the channel. This diverges from my experiences with ChanSpy, which did work when there was a media flow. I'm not getting beeps anywhere even with a good constant media flow.
> 2. Something I am more certain is not expected is that I get this each time the audiohook channel hangs up:
> {noformat}
> [2021-04-14 22:15:47] WARNING[12757][C-0000140e]: pbx.c:4576 __ast_pbx_run: Timeout, but no rule 't' or 'e' in context '__func_periodic_hook_context__'
> {noformat}
> Of course, I didn't write the func_periodic_hook_context context, so it's not something with the dialplan configuration.
> This happens every time ChanSpy hangs up - every 15 seconds as we start the beep cycle over. Likely unrelated to why the beep doesn't sound, and seems to be some kind of fallthrough somewhere, but in case that is relevant to the way other things may not work properly, thought I'd surface that here.
> Below, I have posted everything pertinent to MixMonitor, cutting out other things that were going in-between:
> {noformat}
> [Apr 14 22:15:36]   == Begin MixMonitor Recording SIP/ATAxLA1-000006d0
> [Apr 14 22:15:36]     -- Called hook at __func_periodic_hook_context__
> [Apr 14 22:15:36]     -- Executing [hook at __func_periodic_hook_context__:1] Set("Local/hook at __func_periodic_hook_context__-000011c1;2", "EncodedChannel=SIP/ATAxLA1-000006d0") in new stack
> [Apr 14 22:15:36]     -- Executing [hook at __func_periodic_hook_context__:2] Set("Local/hook at __func_periodic_hook_context__-000011c1;2", "GROUP_NAME=SIP/ATAxLA1-000006d02") in new stack
> [Apr 14 22:15:36]     -- Executing [hook at __func_periodic_hook_context__:3] Set("Local/hook at __func_periodic_hook_context__-000011c1;2", "GROUP(periodic-hook)=SIP/ATAxLA1-000006d02") in new stack
> [Apr 14 22:15:36]     -- Executing [hook at __func_periodic_hook_context__:4] ExecIf("Local/hook at __func_periodic_hook_context__-000011c1;2", "0?Hangup()") in new stack
> [Apr 14 22:15:36]     -- Executing [hook at __func_periodic_hook_context__:5] Set("Local/hook at __func_periodic_hook_context__-000011c1;2", "ChannelToSpy=SIP/ATAxLA1-000006d0") in new stack
> [Apr 14 22:15:36]     -- Executing [hook at __func_periodic_hook_context__:6] ChanSpy("Local/hook at __func_periodic_hook_context__-000011c1;2", "SIP/ATAxLA1-000006d0,qEB") in new stack
> [Apr 14 22:15:36]     -- Local/hook at __func_periodic_hook_context__-000011c1;1 answered
> [Apr 14 22:15:36]     -- Executing [beep at __func_periodic_hook_context__:1] Answer("Local/hook at __func_periodic_hook_context__-000011c1;1", "") in new stack
> [Apr 14 22:15:36]     -- Executing [beep at __func_periodic_hook_context__:2] Playback("Local/hook at __func_periodic_hook_context__-000011c1;1", "beep") in new stack
> [Apr 14 22:15:36]     -- <Local/hook at __func_periodic_hook_context__-000011c1;1> Playing 'beep.ulaw' (language 'en')
> [Apr 14 22:15:36]   == Spying on channel SIP/ATAxLA1-000006d0
> [Apr 14 22:15:36]     -- Attaching spy channel Local/hook at __func_periodic_hook_context__-000011c1;2 to SIP/ATAxLA1-000006d0
> [Apr 14 22:15:36]     -- Attaching spy channel Local/hook at __func_periodic_hook_context__-000011c1;2 to SIP/ATAxLA1-000006d0
> [2021-04-14 22:15:47] WARNING[12757][C-0000140e]: pbx.c:4576 __ast_pbx_run: Timeout, but no rule 't' or 'e' in context '__func_periodic_hook_context__'
> [Apr 14 22:15:47]   == Done Spying on channel SIP/ATAxLA1-000006d0
> [Apr 14 22:15:47]     -- Stopped spying due to the spied-on channel hanging up.
> [Apr 14 22:15:47]   == Spawn extension (__func_periodic_hook_context__, hook, 6) exited non-zero on 'Local/hook at __func_periodic_hook_context__-000011c1;2'
> [Apr 14 22:15:51]     -- Called hook at __func_periodic_hook_context__
> [Apr 14 22:15:51]     -- Executing [hook at __func_periodic_hook_context__:1] Set("Local/hook at __func_periodic_hook_context__-000011c2;2", "EncodedChannel=SIP/ATAxLA1-000006d0") in new stack
> [Apr 14 22:15:51]     -- Executing [hook at __func_periodic_hook_context__:2] Set("Local/hook at __func_periodic_hook_context__-000011c2;2", "GROUP_NAME=SIP/ATAxLA1-000006d02") in new stack
> [Apr 14 22:15:51]     -- Executing [hook at __func_periodic_hook_context__:3] Set("Local/hook at __func_periodic_hook_context__-000011c2;2", "GROUP(periodic-hook)=SIP/ATAxLA1-000006d02") in new stack
> [Apr 14 22:15:51]     -- Executing [hook at __func_periodic_hook_context__:4] ExecIf("Local/hook at __func_periodic_hook_context__-000011c2;2", "0?Hangup()") in new stack
> [Apr 14 22:15:51]     -- Executing [hook at __func_periodic_hook_context__:5] Set("Local/hook at __func_periodic_hook_context__-000011c2;2", "ChannelToSpy=SIP/ATAxLA1-000006d0") in new stack
> [Apr 14 22:15:51]     -- Executing [hook at __func_periodic_hook_context__:6] ChanSpy("Local/hook at __func_periodic_hook_context__-000011c2;2", "SIP/ATAxLA1-000006d0,qEB") in new stack
> [Apr 14 22:15:51]     -- Local/hook at __func_periodic_hook_context__-000011c2;1 answered
> [Apr 14 22:15:51]     -- Executing [beep at __func_periodic_hook_context__:1] Answer("Local/hook at __func_periodic_hook_context__-000011c2;1", "") in new stack
> [Apr 14 22:15:51]     -- Executing [beep at __func_periodic_hook_context__:2] Playback("Local/hook at __func_periodic_hook_context__-000011c2;1", "beep") in new stack
> [Apr 14 22:15:51]     -- <Local/hook at __func_periodic_hook_context__-000011c2;1> Playing 'beep.ulaw' (language 'en')
> [Apr 14 22:15:51]   == Spying on channel SIP/ATAxLA1-000006d0
> [Apr 14 22:15:51]     -- Attaching spy channel Local/hook at __func_periodic_hook_context__-000011c2;2 to SIP/ATAxLA1-000006d0
> [Apr 14 22:15:51]     -- Attaching spy channel Local/hook at __func_periodic_hook_context__-000011c2;2 to SIP/ATAxLA1-000006d0
> {noformat}
> The strange thing is that while this happens consistently on my Asterisk 18.3.0 both directly on a device channel (e.g. SIP/something) and on a Local channel, it does not on another 18.2.0 system if I add this on an incoming IAX2 call (in this case, neither issue occurs). I don't think this is related to the version but more likely some difference between the two environments that is causing such failures. As such, this may be hard to replicate, but I can provide debug logs if needed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)