| Summary: | ASTERISK-29314: MixMonitor stops when use Transfer key of a IP Phone | ||
| Reporter: | Celso Annes (celsoannes) | Labels: | |
| Date Opened: | 2021-02-24 11:32:52.000-0600 | Date Closed: | 2021-02-24 11:39:57.000-0600 |
| Priority: | Major | Regression? | |
| Status: | Closed/Complete | Components: | Applications/app_mixmonitor |
| Versions: | 16.4.0 16.16.1 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | OS: Debian 9.11 (stretch) CPU: Intel Xeon E5620 (4) 2.40GHz MEM: 4G VMware Virtual Platform | Attachments: | |
| Description: | Hello, I am having a problem in a specific method of transfer on Asterisk 16.4.0.
When I am use a **Transfer key** of an IP Phone it didn't record the call when the IP Phone is the source of the call and the source of the transfer. Let me give an exemple: *9002* is my *IP Phone* an Yealink T21P-E2 and I have two more for this exemple, 9000 and 9001. 1. *9002* make a call to 9000 1. 9000 answer *9002* and they start to talk 1. *9002* use the *Transfer Key* to 9001 1. 9001 answer *9002* and they start to talk 1. *9002* hangup and complete the transfer between 9000 and 9001 (At this point the call aren't recorded anymore.) 1. 9000 start to talk with 9001 MixMonitor record the followed calls: * 9002 with 9000 * 9002 with 9001 *The transfered call 9000 with 9001 is not recorded.* Here is the `sip.conf` {code} [9000] host=dynamic type=friend hasvoicemail=yes fullname=9000 callgroup=0 pickupgroup=0 secret=9000 context=jail disallow=all allow=alaw,ulaw callerid="9000" <9000> qualify=yes nat=force_rport,comedia [9001] host=dynamic type=friend hasvoicemail=yes fullname=9001 callgroup=0 pickupgroup=0 secret=9001 context=jail disallow=all allow=alaw,ulaw callerid="9001" <9001> qualify=yes nat=force_rport,comedia [9002] host=dynamic type=friend hasvoicemail=yes fullname=9002 callgroup=0 pickupgroup=0 secret=9002 context=jail disallow=all allow=alaw,ulaw callerid="9002" <9000> qualify=yes nat=force_rport,comedia {code} Here is the `extensions.conf` {code} [jail] exten => _900X,1,NoOp( ----------------- GRAVANDO: ${CDR(src)} -> ${CDR(dst)} | LINKEDID: ${CDR(LINKEDID)} ----------------- ) same => n,Set(CDR(userfield)=${CDR(LINKEDID)}.wav) same => n,MixMonitor(${CDR(LINKEDID)}.wav,a) same => n,Dial(SIP/${EXTEN},,tT) same => n,HangUp() {code} Step 1 - *9002* make a call to 9000 {code} [Jan 15 19:09:24] == Using SIP RTP CoS mark 5 [Jan 15 19:09:24] -- Executing [9000@jail:1] NoOp("SIP/9002-00000177", " ----------------- GRAVANDO: 9000 -> 9000 | LINKEDID: 1610748564.2849 ----------------- ") in new stack [Jan 15 19:09:24] -- Executing [9000@jail:2] Set("SIP/9002-00000177", "CDR(userfield)=1610748564.2849.wav") in new stack [Jan 15 19:09:24] -- Executing [9000@jail:3] MixMonitor("SIP/9002-00000177", "1610748564.2849.wav,a") in new stack [Jan 15 19:09:24] -- Executing [9000@jail:4] Dial("SIP/9002-00000177", "SIP/9000,,tT") in new stack [Jan 15 19:09:24] == Begin MixMonitor Recording SIP/9002-00000177 [Jan 15 19:09:24] == Using SIP RTP CoS mark 5 [Jan 15 19:09:24] -- Called SIP/9000 [Jan 15 19:09:24] -- SIP/9000-00000178 is ringing [Jan 15 19:09:26] -- SIP/9000-00000178 answered SIP/9002-00000177 [Jan 15 19:09:26] -- Channel SIP/9000-00000178 joined 'simple_bridge' basic-bridge <977e4c9d-05f9-49bf-b145-2251ba7a3db0> [Jan 15 19:09:26] -- Channel SIP/9002-00000177 joined 'simple_bridge' basic-bridge <977e4c9d-05f9-49bf-b145-2251ba7a3db0> {code} *`mixmonitor list`* {code} finti*CLI> mixmonitor list SIP/9000-00000178 SIP/9002-00000177 finti*CLI> mixmonitor list SIP/9000-00000178 MixMonitor ID File Receive File Transmit File ========================================================================= finti*CLI> mixmonitor list SIP/9002-00000177 MixMonitor ID File Receive File Transmit File ========================================================================= 0x7fda8c001020 /var/spool/asterisk/monitor/1610748564.2849 {code} Step 2 - *9002* use the *Transfer Key* to 9001 {code} [Jan 15 19:11:00] -- Started music on hold, class 'default', on channel 'SIP/9000-00000178' [Jan 15 19:11:05] == Using SIP RTP CoS mark 5 [Jan 15 19:11:05] -- Executing [9001@jail:1] NoOp("SIP/9002-00000179", " ----------------- GRAVANDO: 9000 -> 9001 | LINKEDID: 1610748665.2858 ----------------- ") in new stack [Jan 15 19:11:05] -- Executing [9001@jail:2] Set("SIP/9002-00000179", "CDR(userfield)=1610748665.2858.wav") in new stack [Jan 15 19:11:05] -- Executing [9001@jail:3] MixMonitor("SIP/9002-00000179", "1610748665.2858.wav,a") in new stack [Jan 15 19:11:05] -- Executing [9001@jail:4] Dial("SIP/9002-00000179", "SIP/9001,,tT") in new stack [Jan 15 19:11:05] == Using SIP RTP CoS mark 5 [Jan 15 19:11:05] -- Called SIP/9001 [Jan 15 19:11:05] == Begin MixMonitor Recording SIP/9002-00000179 [Jan 15 19:11:05] -- SIP/9001-0000017a is ringing [Jan 15 19:11:09] -- SIP/9001-0000017a answered SIP/9002-00000179 [Jan 15 19:11:09] -- Channel SIP/9001-0000017a joined 'simple_bridge' basic-bridge <ec1b1108-8f7c-439f-959e-5becd5ccb16e> [Jan 15 19:11:09] -- Channel SIP/9002-00000179 joined 'simple_bridge' basic-bridge <ec1b1108-8f7c-439f-959e-5becd5ccb16e> {code} *`mixmonitor list`* {code} finti*CLI> mixmonitor list SIP/9000-00000178 SIP/9001-0000017a SIP/9002-00000177 SIP/9002-00000179 finti*CLI> mixmonitor list SIP/9000-00000178 MixMonitor ID File Receive File Transmit File ========================================================================= finti*CLI> mixmonitor list SIP/9001-0000017a MixMonitor ID File Receive File Transmit File ========================================================================= finti*CLI> mixmonitor list SIP/9002-00000177 MixMonitor ID File Receive File Transmit File ========================================================================= 0x7fda8c001020 /var/spool/asterisk/monitor/1610748564.2849 finti*CLI> mixmonitor list SIP/9002-00000179 MixMonitor ID File Receive File Transmit File ========================================================================= 0x7fda0c0070d0 /var/spool/asterisk/monitor/1610748665.2858 {code} Step 3 - *9002* hangup and complete the transfer between 9000 and 9001 *At this point the call aren't recorded anymore.* {code} [Jan 15 19:14:22] -- Channel SIP/9000-00000178 left 'simple_bridge' basic-bridge <977e4c9d-05f9-49bf-b145-2251ba7a3db0> [Jan 15 19:14:22] -- Channel SIP/9002-00000179 left 'simple_bridge' basic-bridge <ec1b1108-8f7c-439f-959e-5becd5ccb16e> [Jan 15 19:14:22] -- Channel SIP/9000-00000178 swapped with SIP/9002-00000179 into 'simple_bridge' basic-bridge <ec1b1108-8f7c-439f-959e-5becd5ccb16e> [Jan 15 19:14:22] -- Channel SIP/9002-00000177 left 'simple_bridge' basic-bridge <977e4c9d-05f9-49bf-b145-2251ba7a3db0> [Jan 15 19:14:22] == Spawn extension (jail, 9001, 4) exited non-zero on 'SIP/9002-00000179' [Jan 15 19:14:22] == Spawn extension (jail, 9000, 4) exited non-zero on 'SIP/9002-00000177' [Jan 15 19:14:22] == MixMonitor close filestream (mixed) [Jan 15 19:14:22] == End MixMonitor Recording SIP/9002-00000179 [Jan 15 19:14:22] -- Stopped music on hold on SIP/9000-00000178 [Jan 15 19:14:22] == MixMonitor close filestream (mixed) [Jan 15 19:14:22] == End MixMonitor Recording SIP/9002-00000177 {code} *`mixmonitor list`* {code} finti*CLI> mixmonitor list SIP/9000-00000178 SIP/9001-0000017a finti*CLI> mixmonitor list SIP/9000-00000178 MixMonitor ID File Receive File Transmit File ========================================================================= finti*CLI> mixmonitor list SIP/9001-0000017a MixMonitor ID File Receive File Transmit File ========================================================================= {code} Step 4 - 9001 hangup, end the call. {code} [Jan 15 19:15:42] -- Channel SIP/9001-0000017a left 'simple_bridge' basic-bridge <ec1b1108-8f7c-439f-959e-5becd5ccb16e> [Jan 15 19:15:42] -- Channel SIP/9000-00000178 left 'simple_bridge' basic-bridge <ec1b1108-8f7c-439f-959e-5becd5ccb16e> {code} I don't remember to have this problem on the Asterisk 13 when I used Set(AUDIOHOOK_INHERIT(MixMonitor)=yes). Is this a BUG? Do I have to do anything else to make the recording keep going in this scenario. Is there a way to keeping using the Transfer key on the IP Phones in the example that I gave? | ||
| Comments: | By: Asterisk Team (asteriskteam) 2021-02-24 11:32:54.399-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Joshua C. Colp (jcolp) 2021-02-24 11:39:51.529-0600 We appreciate the difficulties you are facing, however this does not appear to be a bug report and your request or comments would be better served in a different forum. The Asterisk community provides support over IRC, mailing lists, and forums as described at http://asterisk.org/community. The Asterisk issue tracker is used specifically to track issues concerning bugs and documentation errors. Please see the Asterisk Issue Guidelines [1] for instruction on the intended use of the Asterisk issue tracker. Thanks! [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines | ||