[asterisk-bugs] [JIRA] Created: (ASTERISK-20327) Document usage of the AUDIOHOOK_INHERIT function on the Asterisk wiki

[Matt Jordan (JIRA)]

Document usage of the AUDIOHOOK_INHERIT function on the Asterisk wiki
---------------------------------------------------------------------

                 Key: ASTERISK-20327
                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20327
             Project: Asterisk
          Issue Type: Bug
      Security Level: None
          Components: Applications/app_mixmonitor
         Environment: CentOs 5.5 & 5.6
            Reporter: Ishfaq Malik


I have the following scenario...

SIP call comes in and gets answered by extension A (MixMonitor is executed as part of this inbound dial plan of the number being called)

Extension A puts call on hold and calls extension B

Extension A then does an attended transfer of incoming call to extension B

I'm finding that the recording only lasts up to the point that the transfer is made.

Here is a section of the logs for such a call

[2011-08-02 13:47:13] VERBOSE[6475] rtp_engine.c:     -- Locally bridging SIP/A-00000049 and SIP/B-0000004a
[2011-08-02 13:47:20] VERBOSE[6475] rtp_engine.c:     -- Locally bridging SIP/inbound-00000047 and SIP/B-0000004a
[2011-08-02 13:47:20] VERBOSE[6463] pbx.c:   == Spawn extension (inbound, s, 4) exited non-zero on 'SIP/A-00000049<ZOMBIE>'
[2011-08-02 13:47:20] VERBOSE[6464] app_mixmonitor.c:   == MixMonitor close filestream
[2011-08-02 13:47:26] VERBOSE[6475] app_macro.c:   == Spawn extension (macro-stdexten, s, 1) exited non-zero on 'SIP/inbound-00000047' in macro 'stdexten'
[2011-08-02 13:47:26] VERBOSE[6475] pbx.c:   == Spawn extension (local, B, 1) exited non-zero on 'SIP/inbound-00000047'
[2011-08-02 13:47:26] VERBOSE[6464] app_mixmonitor.c:   == End MixMonitor Recording SIP/inbound-00000047

Obviously, I've obscured some of the more sensitive details in there

The thing to notice here though is that MixMonitor closes the filestream when I hit the transfer button but actually Ends the recording 6 seconds later when the whole call was ended.

This seems like inconsistent behaviour and more like an unintentional consequence of changes rather than intended behaviour, i.e. why would you close the filestream yet not end the recording?

Also, this is a departure from the behaviour in 1.4 where the entire call would be recorded.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira