[Home]

Summary:ASTERISK-06267: Unable to monitor a call in app_queue.
Reporter:nywiley (nywiley)Labels:
Date Opened:2006-02-07 08:41:39.000-0600Date Closed:2006-05-01 09:05:30
Priority:MinorRegression?No
Status:Closed/CompleteComponents: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.