Call recordings - Outbound calls, attended transfers not recording

Asterisk Asterisk Support
1

Hi

I have upgraded to asterisk 13.10.0 and experience problems with MixMonitor and Attendant transfer calls:

Extension 4001 calls an external number 0123456789

  • This call is recorded
    Extension 4001 then calls 4002 and says its putting through 0123456789
  • This call is recorded
    Attendant transfer between 4001 and 4002 takes place and MixMonitor stops recording
  • No record is found

CLI events when Attendant transfer takes place:
== End MixMonitor Recording SIP/4001-00000016
== End MixMonitor Recording SIP/4001-00000015

In Asterisk 11 I used
AUDIOHOOK_INHERIT() to fix the problem, however I see in Asterisk 13 that it has been DEPRECATED

Can someone assist in explaining why this is happening?

Regards

2

Incoming calls on Attendant transfers works perfectly fine.

0123456789 calls into 4001

  • Call recording exist (1476718094.31.wav)
    4001 calls 4002 says its putting 0123456789 through
  • Call recording exists (1476718107.34.wav)
    4001 and 4002 Attendant transfer takes place and MixMonitor continues
  • Call recording continues on original recording (1476718094.31.wav)

What am I missing with Outgoing calls?

3

Any one else experienced the same problem?

4

Below is CLI information:

-- Called SIP/4002
-- SIP/4002-0000002d is ringing
-- SIP/4002-0000002d answered SIP/4001-0000002b
-- Channel SIP/4002-0000002d joined 'simple_bridge' basic-bridge <e1aace1d-b332-4a42-ad29-05d7baf6912f>
-- Channel SIP/4001-0000002b joined 'simple_bridge' basic-bridge <e1aace1d-b332-4a42-ad29-05d7baf6912f>
-- Channel SIP/4002-0000002d left 'simple_bridge' basic-bridge <e1aace1d-b332-4a42-ad29-05d7baf6912f>
-- Channel SIP/4001-0000002a left 'simple_bridge' basic-bridge <bdc31fcb-2755-4170-b7a6-e5a62c8ad85f> 
-- Channel SIP/4002-0000002d swapped with SIP/4001-0000002a into 'simple_bridge' basic-bridge <bdc31fcb-2755-4170-b7a6-e5a62c8ad85f>
-- Channel SIP/4001-0000002b left 'simple_bridge' basic-bridge <e1aace1d-b332-4a42-ad29-05d7baf6912f>
== Spawn extension (macro-exten, s-DIAL, 1) exited non-zero on 'SIP/4001-0000002b' in macro 'exten'
== Spawn extension (internal, 4002, 1) exited non-zero on 'SIP/4001-0000002b'
== Spawn extension (macro-trunk, s-OK, 3) exited non-zero on 'SIP/4001-0000002a' in macro 'trunk'
== Spawn extension (internal, 0123456789, 3) exited non-zero on 'SIP/4001-0000002a'
== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476770690.54]
== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476770670.52]  
== End MixMonitor Recording SIP/4001-0000002b
== End MixMonitor Recording SIP/4001-0000002a
-- Channel SIP/4002-0000002d left 'simple_bridge' basic-bridge <bdc31fcb-2755-4170-b7a6-e5a62c8ad85f>
-- Channel DAHDI/i1/0720163530-b left 'simple_bridge' basic-bridge <bdc31fcb-2755-4170-b7a6-e5a62c8ad85f>
-- Hungup 'DAHDI/i1/0720163530-b'

MixMonitor is stopping as soon as the attendant transfer is processed and not when the call finishes.

5

The MixMonitor follows the channel always, this means you need to ensure that it is placed on the right channel using pre-dial handlers. If you put it on the transferer then it will not follow.

6

Thanks it make sense that the original channel is associated with MixMonitor and when the call gets transferred away, that the call disconnect and MixMonitor will stop.

The follow explains the same problem I am having:
http://lists.digium.com/pipermail/asterisk-dev/2016-May/075520.html

I will look at making use of DIAL commands handlers: b, B or U as an interim fix.

Regards

7

I can confirm that doesn’t matter if I use b, B or U it doesn’t resolve my problem. MixMonitor continues to be associated to the first channel:

== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476794692.77]
== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476794692.77]
== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476794675.75]
== End MixMonitor Recording SIP/4001-0000003e
== End MixMonitor Recording SIP/4001-0000003e
== End MixMonitor Recording SIP/4001-0000003d

Since MixMonitor is associated to SIP/4001, doesn’t matter what the uniqueid of the channel will be or even if I force the file to a specific name, it still won’t record.

Any suggestions to force MixMonitor to another channel?

Regards

8

The following does seam to fix the recording problem but now it doesn’t associate it to the CDR record:

exten => s-OK,3,Dial(${ARG1}/${ARG2},300,TU(record))

[record]
exten => s,1,Macro(check-record)
exten => s,2,Return

MixMonitor now runs until the call is completed:
== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476797717.115]
== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476797734.117]
== End MixMonitor Recording SIP/4001-0000005e
== End MixMonitor Recording SIP/4001-0000005d
– Hungup ‘DAHDI/i1/0123456789-17’
== MixMonitor close filestream (mixed)
== Executing [/usr/local/bitco/convert 1476797717.116]
== End MixMonitor Recording DAHDI/i1/0123456789-17

Now need to find a way of getting the information to CDR table.

9

I resolved the CDR problem. I have moved my U(record) to the internal dialing macro and its now associated to the correct uniqueid.

Down side to this fix, it will cause duplicated call recordings for every internal call on the system.

10

I ran into the same problem and was surprised that this still is kind of an issue that seems not really to be addressed since the deprication of AUDIOHOOK INHERIT().

Thanks for pointing me to the U(record) option of the Dial command in this fairly old post! :slight_smile:

I managed to change my dial plan in such a way that I only use this construction to start a MixMonitor for calls from internal to external numbers. This is actually the only scenario where this goes wrong. In this way I don’t have duplicated call recordings since my other internal calls use the ‘normal’ MixMonitor (without adding the U(record) option to the Dial command.

11

I know this is a old post but my freepbx 16 still has this issue I tried implementing this fix but I’m clearing doing something wrong can someone please help going crazy. This is how my current dialplan looks and no matter where i put in the fix it breaks causing no calls to work both internal & external. Thank you in advance.

[from-internal]
include => from-internal-noxfer
include => from-internal-xfer
include => bad-number ; auto-generated
exten => h,1,Macro(hangupcall)

12

You are including three undefined contexts.