Summary: | ASTERISK-06267: Unable to monitor a call in app_queue. | ||
Reporter: | nywiley (nywiley) | Labels: | |
Date Opened: | 2006-02-07 08:41:39.000-0600 | Date Closed: | 2006-05-01 09:05:30 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_queue |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) extensions.conf | |
Description: | I am using the standard 1.2.4 distribution tarball combined with the current AMP release. Whenever I try to set a queue to record the inbound calls, the code says that it is attempting a bridge, starts to monitor, and then unbruptly ends the monitoring and leaves a 60 byte file. As you can see from the log below, it starts to monitor the call, and then drops the call all inside of a second. ****** ADDITIONAL INFORMATION ****** b 6 19:21:14 DEBUG[18256] chan_sip.c: Acked pending invite 102 Feb 6 19:21:14 DEBUG[18256] chan_sip.c: Stopping retransmission on '774a70f410fa3330423f63634c7fce96@10.1.1.221' of Request 102: Match Found Feb 6 19:21:14 DEBUG[18256] chan_sip.c: build_route: Contact hop: <sip:5302@10.1.1.200:5060> Feb 6 19:21:14 VERBOSE[18272] logger.c: -- SIP/5302-32d0 answered Local/5302@from-internal-b815,2 Feb 6 19:21:14 DEBUG[18267] app_queue.c: Dunno what to do with control type -1 Feb 6 19:21:14 VERBOSE[18267] logger.c: -- Local/5302@from-internal-b815,1 answered SIP/5300-bc09 Feb 6 19:21:14 VERBOSE[18267] logger.c: -- Stopped music on hold on SIP/5300-bc09 Feb 6 19:21:14 DEBUG[18267] channel.c: Planning to masquerade channel SIP/5300-bc09 into the structure of Local/5302@from-internal-b815,2 Feb 6 19:21:14 DEBUG[18267] channel.c: Done planning to masquerade channel SIP/5300-bc09 into the structure of Local/5302@from-internal-b815,2 Feb 6 19:21:14 DEBUG[18267] chan_local.c: Not posting to queue since already masked on 'Local/5302@from-internal-b815,1' Feb 6 19:21:14 DEBUG[18272] channel.c: Got clone lock for masquerade on 'SIP/5300-bc09' at 0x8150170 Feb 6 19:21:14 DEBUG[18272] channel.c: Putting channel SIP/5300-bc09 in 4/4 formats Feb 6 19:21:14 DEBUG[18272] channel.c: Released clone lock on 'Local/5302@from-internal-b815,2<ZOMBIE>' Feb 6 19:21:14 DEBUG[18272] channel.c: Done Masquerading SIP/5300-bc09 (6) Feb 6 19:21:14 DEBUG[18267] channel.c: Didn't get a frame from channel: Local/5302@from-internal-b815,2<ZOMBIE> Feb 6 19:21:14 DEBUG[18267] channel.c: Bridge stops bridging channels Local/5302@from-internal-b815,2<ZOMBIE> and Local/5302@from-internal-b815,1 | ||
Comments: | By: nywiley (nywiley) 2006-02-07 17:59:50.000-0600 Hi, I've done some more investigation into this issue and have learned that the monitor routine is getting associated to the callee's record before it is masq'd into the call queue answeree's process. After the call is masqueraded, the original callee's line is zombied out, and the monitor process is shutdown with it. It would appear that there may be a bug in the masquerade code in that it should transfer the monitoring process to the answerees line, but doesn't Best Regards, Bill By: nywiley (nywiley) 2006-02-08 14:01:51.000-0600 Hi, Is there any information I can provide to help resolve this issue? Best Regards, Bill By: nywiley (nywiley) 2006-02-10 09:43:55.000-0600 Good News, The entire issue of call recording can be eliminated by turning off call masquarading in chan_local. If you add a /n to any local call, the masquarading feature is turned off and call recording starts to work again! Example Local/${CALLBACKNUM}@from-internal can be converted to Local/$(CALLBACKNUM)@from-internal/n Regards, Bill By: Peng Yong (ppyy) 2006-03-10 23:12:30.000-0600 can you provide the section of your dial plan file. By: nywiley (nywiley) 2006-03-11 12:04:39.000-0600 Have uploaded the file. Pay attention to the AddQueMember line in the macro labeled macro-agent-add. Without the /n on the end of the the call will not be recorded. It has to do with the masquarading code. By: Andrey S Pankov (casper) 2006-04-10 14:39:28 chan_local will optimize (remove) itself from the media path after answer happens without /n. That's intended behavior. So your issue (if I understand it right) is not a bug. By: nywiley (nywiley) 2006-04-13 07:36:29 Hi, I think you missed the point. If you are recording a call that came in through a queue, when the optimization takes place, it drops the call recording and you get about a 100 byte file. What should be done is that if the call is going to be recorded, the recording shouldn't be started until after the optimization is done and it should be associated to the new channel. - Bill By: opsys (opsys) 2006-04-29 01:16:32 The small recorded file is from the time the Local Channel gets built, records and than gets destoryed. By: nywiley (nywiley) 2006-04-29 11:58:39 Yes, Exactly ... and what should be happening is that if you have turned on queue recording, the recording should not be attached to the local channel, but to the final channel after the local is destroyed. By: opsys (opsys) 2006-04-30 00:45:50 The /n flag was adding for this vey reason. I would concur with Casper that it is NOT bug, as when used with the /n flag, it works as expected. By: nywiley (nywiley) 2006-04-30 09:50:03 I understand that the /n was added to do this. But doesn't it strike you that this should be the default behavior? The standard AMP release doesn't use this syntax, and it took me a while to track down why the recordings would be 100 bytes in size. Why would you ever want this behavior? By: Andrey S Pankov (casper) 2006-04-30 10:29:23 That's the documented and intended behavior... Let's close this bug. |