[Home]

Summary:ASTERISK-14014: Monitor in Asterisk does not record all calls and also recordings are not complete according to the complete actual duration
Reporter:destiny6628 (destiny6628)Labels:
Date Opened:2009-04-25 05:29:00Date Closed:2011-06-07 14:00:22
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Resources/res_monitor
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 9119899500233-66220300-20090424-164209.wav
( 1) 9119999100816-66220300-20090520-112805-all.wav
( 2) 9119999777037-66220300-20090622-121734-all.wav
( 3) 9119999979713-66220300-20090625-121625-all.wav
( 4) monitor_started_but_recording_didnt.txt
( 5) voice_log_half_recorded.txt
Description:e are using Monitor command for recording calls.

Issue which we are facing is are

1)Recording does not even start happening even when Monitor command issued.
2)Even if recording is started then also calls are half recorded.

Logs are attached both of same.

This is a bit critical issue as complete recordings are required for all the Calls is mandatory

****** ADDITIONAL INFORMATION ******

Asterisk version is 1.4.19
Libpri version is 1.4.3
Zaptel version is 1.4.8
Comments:By: destiny6628 (destiny6628) 2009-04-25 05:39:31

i have also attached the recording on which voice recording is not complete.
Call started at 16:42:30 and ended at 16:59:00.

The another record for which Monitor didnt started calls were made 2wice on that number out of which 1 call was recorded and another was not.

I have attached the logs for the call on which monitor command went but recording didnt started at all.
By: destiny6628 (destiny6628) 2009-04-25 05:43:21

Just for the information we are using ALAW codec and ZAP.
By: Joshua C. Colp (jcolp) 2009-04-27 08:13:54

1. Please upgrade and use the latest Asterisk version.
2. Please provide a description of the complete call flow for these calls.
3. Since it looks like you are using chan_local please add /n to the end of your Local dial line. It is possible that Monitor is being started on it but not surviving being optimized away, which is what chan_local does by default.
By: destiny6628 (destiny6628) 2009-05-20 06:33:11

I am extremely sorry for the delay in giving feedback.
Yes, correct we are using Local Channel for dialing but after going through your feedback we stopped using Local Channel and instead have started dialing directly on ZAP.

After dialing directly on ZAP as well,we are facing recording issue.

ACTUAL Call was for longer duration but recording we had for only 6 sec.

I am attaching the logs below which will clearly shows same and also please fine the attached recording.

[May 20 11:28:16] VERBOSE[994] logger.c:     -- Executing [143@default:1] NoOp("Zap/7-1", "9119999100816-66220300-20090520-112805") in new stack
[May 20 11:28:16] VERBOSE[994] logger.c:     -- Executing [143@default:2] Monitor("Zap/7-1", "wav|/var/spool/asterisk/monitor/ORIG/20090520/9119999100816-66220300-20090520-112805") in new stack
[May 20 11:28:16] VERBOSE[994] logger.c:     -- Executing [143@default:3] Dial("Zap/7-1", "SIP/143") in new stack
[May 20 11:28:16] VERBOSE[994] logger.c:     -- Called 143
[May 20 11:28:16] VERBOSE[994] logger.c:     -- SIP/143-0927c5b0 is ringing
[May 20 11:28:19] VERBOSE[994] logger.c:     -- SIP/143-0927c5b0 answered Zap/7-1
[May 20 11:48:13] VERBOSE[994] logger.c:   == Spawn extension (default, 143, 3) exited non-zero on 'Zap/7-1'
By: destiny6628 (destiny6628) 2009-05-20 06:41:58

Looking forward to positive response.
By: destiny6628 (destiny6628) 2009-05-23 01:45:41

Still waiting for any feedback,
Any success or feedback??
Does any one facing the same problem??
By: destiny6628 (destiny6628) 2009-05-26 03:21:42

Can i expect any response on same please ??
This is bothering a lot now.
By: Ronald Chan (loloski) 2009-05-26 06:14:47

destiny6628

would you be able to reproduce this to more recent branch of asterisk 1.4? and i just notice, how about changing your codec from alaw to ulaw/g711u ?

let's hope for a developer to pick this up.
By: Leif Madsen (lmadsen) 2009-05-26 08:32:58

destiny6628: this is an issue tracker where a 'best effort' is given, but there are several other pressing issues including this one. When a developer has the chance to request more information, they will, and will then follow up as time permits. Thanks for your patience!
By: Leif Madsen (lmadsen) 2009-05-26 08:36:53

Additionally, we are missing two answers from the questions file had asked you:

1. Please confirm you have reproduced on latest 1.4 from SVN, although 1.4.25 was just released so that version is probably fine to test with.

2. Please provide the complete call flow of how to reproduce this issue, along with related dialplan for the call flow. Ability to reproduce the issue may be very important to move this issue forward.
By: motto (motto) 2009-05-27 10:33:46

I have the same issue when monitoring Zap channels.

==== manually enabled via Manager API ======
Action: monitor
Channel: Zap/62-1
File: check
Mix: 0

Response: Success
Message: Started monitoring channel
=========== cut ==========

Connected to Asterisk 1.4.25 currently running on stream (pid = 10142)
Verbosity was 3 and is now 6
stream*CLI>
stream*CLI> core show channels
Channel              Location             State   Application(Data)
Zap/1-1              (None)               Up      AppDial((Outgoing Line))
Zap/62-1             s@macro-dial:2    Up      Dial(Zap/g1/80194884361)
2 active channels
1 active call

# ls -la /var/spool/asterisk/monitor/
-rw-r--r-- 1 root root 1056364 2009-05-26 20:12 check-in.wav
-rw-r--r-- 1 root root      44 2009-05-26 20:11 check-out.wav


But audio dumping only one way.
By: destiny6628 (destiny6628) 2009-06-06 05:42:29

I am extremely sorry for late reply.

I have upgraded to Asterisk-1.4.25 but still problem remains same with me.

I am using Dial Application for Dialing on Zap Channels, once call gets matured we use an AGI application to transfer call to the Agents, and once call gets answered at the Agents extensions then we issue a Monitor Command and start monitoring channel.

exten => _91.,1,Set(_CALLFILENAME=${EXTEN}-${CALLERID(num)}-${STRFTIME(${EPOCH},,%Y%m%d-%H%M%S)})
exten => _91.,2,NoOp(${CALLFILENAME})
exten => _91.,3,Dial(Zap/g1/${EXTEN:3},55,o)
exten => _91.,4,Hangup

Once call gets answered we set it to extension which is 8365 which transfers call to Extensions

exten => 8365,1,AGI(call_log,10.0.0.8|10.0.0.190)
exten => 8365,2,Answer
exten => 8365,3,playback(silence)
exten => 8365,4,AGI(transfer_agi,10.0.0.8|10.0.0.190|n)
exten => 8365,5,AGI(transfer_agi,10.0.0.8|10.0.0.190|n)
exten => 8365,6,AGI(transfer_agi,10.0.0.8|10.0.0.190|n)
exten => 8365,7,Hangup

exten => _1.,1,NoOp(${CALLFILENAME})
exten => _1.,2,monitor(wav,/var/spool/asterisk/monitor/ORIG/${STRFTIME(${EPOCH},Asia/Calcutta,%Y%m%d)}/${CALLFILENAME})
exten => _1.,3,Dial(SIP/${EXTEN})

Just to mention i have tried all options by starting monitoring on customer channel as well and had same problem then started at the extensions side.

This is a simple call flow of a call and monitoring.

Will wait for reply.
By: Leif Madsen (lmadsen) 2009-06-09 08:48:59

I'm seeing the two reporters mentioning Zaptel, and I'm curious if upgrading to DAHDI would cause these issues to go away? Does this *only* happen on hardware channels? (chan_zap?)

If that is the case, it could very well be the problem exists in chan_zap, and upgrading to chan_dahdi may cause the problem to be resolved. Since chan_zap is no longer maintained, but chan_dahdi is, I'd suggest you give that a shot to see if resolves the issue.

Thanks!
Leif.
By: destiny6628 (destiny6628) 2009-06-11 23:35:48

Thanks Leif for the reply.
I will upgrade to Dahdi and keep you posted on same.

Thanks for your prompt reply.
By: motto (motto) 2009-06-12 01:28:33

Hi, there.
I did update to the latest: libpri-1.4.9, dahdi-linux-2.1.0.4, dahdi-tools-2.1.0.2, asterisk-1.4.25.1, asterisk-addons-1.4.8.
Now:
Calls being recorded fine (i.e. both channels) when initiated in dialplan with command monitor.
exten => _XXXX.,1,Set(CALLFILENAME=${STRFTIME(${EPOCH},,%C%y%m%d-%H%M%S)}-${CALLERID(num)}-${EXTEN})
exten => _XXXX.,n,Monitor(wav,${CALLFILENAME})
exten => _XXXX.,n,Dial(Dahdi/g1/${EXTEN})

But when initiated via Manager API, it still writing/recording only single channel.
=== cut ===
Action: Monitor
Channel: DAHDI/123-1
=== cut ===
-rw-r--r-- 1 root root 224044 2009-06-11 19:17 DAHDI-123-1-in.wav                                                                          
-rw-r--r-- 1 root root     44 2009-06-11 19:17 DAHDI-123-1-out.wav
By: motto (motto) 2009-06-12 10:16:45

I have also tried that on Asterisk 1.6.0.10.
situation is the same:
when starting recording via Manager API it does record only single channel.
By: Miguel Molina (coolmig) 2009-06-18 23:45:34

Does this happen too if you use MixMonitor instead?
By: motto (motto) 2009-06-19 04:31:28

See, MixMonitor available only via dialplan and not available via Manager API.
I need to have recording work properly via Manager API.
By: Sebastian Gutierrez (sum) 2009-06-19 11:27:22

you can always use the ami action to send a cli command and use mixmonitor
By: destiny6628 (destiny6628) 2009-06-22 05:22:16

Hi Leif,

i had upgraded my system from Zaptel to Dahdi few days back as per the feedback, and was monitoring the recordings for some time, but still facing same problem as earlier.

Calls are actual for long duration but recording is of very short duration.

I have attached a latest recording which shows both prospect and agent were speaking with each other and recording stops in the initial stages.

Plz suggests.
By: destiny6628 (destiny6628) 2009-06-22 05:23:16

Version upgraded

DAHDI Linux 2.1.0.4
DAHDI Tools 2.1.0.2
Asterisk 1.4.25
By: destiny6628 (destiny6628) 2009-06-22 05:23:51

[Jun 22 12:17:53] VERBOSE[23583] logger.c:     -- Executing [108@default:1] NoOp("DAHDI/8-1", "9119999777037-66220300-20090622-121734") in new stack
[Jun 22 12:17:53] VERBOSE[23583] logger.c:     -- Executing [108@default:2] Monitor("DAHDI/8-1", "wav|/var/spool/asterisk/monitor/ORIG/20090622/9119999777037-66220300-20090622-121734") in new stack
[Jun 22 12:17:53] VERBOSE[23583] logger.c:     -- Executing [108@default:3] Dial("DAHDI/8-1", "SIP/108") in new stack
[Jun 22 12:17:53] VERBOSE[23583] logger.c:     -- Called 108
[Jun 22 12:17:53] VERBOSE[23583] logger.c:     -- SIP/108-09ee4d88 is ringing
[Jun 22 12:17:54] VERBOSE[23587] logger.c:     -- Requested transfer capability: 0x00 - SPEECH
[Jun 22 12:17:55] DEBUG[2886] chan_dahdi.c: Queuing frame from PRI_EVENT_PROCEEDING on channel 0/1 span 1
[Jun 22 12:17:55] VERBOSE[23583] logger.c:     -- SIP/108-09ee4d88 answered DAHDI/8-1



Monitor command issued at 12:17:53 and filename generated was 9119999777037-66220300-20090622-121734.

--------------------------------------------



[Jun 22 12:28:07] VERBOSE[23583] logger.c:     -- Executing [h@default:1] DeadAGI("DAHDI/8-1", "call_log|10.0.0.8|10.0.0.190") in new stack

[Jun 22 12:28:07] VERBOSE[23583] logger.c:     -- Executing [h@default:2] DeadAGI("DAHDI/8-1", "hangup|10.0.0.8|10.0.0.190|16|ANSWER|n") in new stack


-------------------------------------------------

Call actually was hang up at 12:28:07, its a complete call but monitor command issued recording started and then call kept went on and recording stopped after 28 sec.
By: destiny6628 (destiny6628) 2009-06-24 00:43:12

Still struggling to get the calls recorded complete.
If any trace is required please let me know i will get that ASAP
By: destiny6628 (destiny6628) 2009-06-25 14:23:03

i have found the problem, might be i am wrong but i would like to share what i have done to get rid of the problem which seems so but however still under observation.

1) I have already explained my call flow that i am doing recording on a DAHDI CHANNEL and also have shown many times above, actual call length has always been more then the call recorded.

2) Today i tried also issued monitor command on the agent channel with the help of macro and what i noticed was recording which started on DAHDI channel stopped after 30 sec and recording which started on Agent Channel was of 8 min and has the complete conversation of complete call.

This might be a problem with DAHDI or ZAP where some channel changes and recording stops but calls remain on.

Let me know please if any other logs are required to get this problem fixed.

Please find the attached recording which states the above example.
By: destiny6628 (destiny6628) 2009-06-25 14:33:05

8MB recording i am unable to attach because of the uploading limitation, but it seems what i have faced above.

i will monitor some more calls tomorrow and update accordingly.
By: motto (motto) 2009-06-26 01:58:08

I also noticed after moving from Zap to DAHDI my server started crushing almost each day.

kernel: Uhhuh. NMI received for unknown reason 25 on CPU 0.
kernel: Do you have a strange power saving mode enabled?
kernel: Dazed and confused, but trying to continue
kernel: Clocksource tsc unstable (delta = 2729277052 ns)
kernel: Time: jiffies clocksource has been installed.
syslogd 1.4.2: restart.
By: Leif Madsen (lmadsen) 2009-06-29 11:08:42

motto: please do not hijack an existing issue -- if you have an issue different from this, please open a new bug report. Thanks!
By: destiny6628 (destiny6628) 2009-07-01 03:02:00

Hi

It seems problem of half recorded calls have been resolved, because since then did not got any problem of such type.

So it seems was related to Dahdi / ZAP or might be SIP channel as well.

Is there something which we can do about this problem.

Any response would be of great help.
By: motto (motto) 2009-07-01 03:14:00

well, I have resolved issue by rolling back to Zaptel.
and now I have installed Asterisk-1.4.10 and recording working fine on this version.
By: Leif Madsen (lmadsen) 2009-07-01 08:15:38

destiny6628: I'm a bit confused... what problem needs to be resolved if the issue is resolved.... ?
By: destiny6628 (destiny6628) 2009-07-02 11:34:14

why does recordings are not completed when we start monitor on DAHDI or ZAP or SIP channel which is a customer channel.

But when we start monitor command on the agent channel then calls gets completly recorded.

Is everything ok with this stuff.

Earlier when i was using local channel was for dialing, then i was being told local channel gets spawn so might calls gets half recorded.

Then i started monitoring on DAHDI channel but still faced problem.

So does dahdi / zap / sip channel also gets changed??
By: destiny6628 (destiny6628) 2009-07-11 14:13:39

Still waiting for the inputs??
By: Leif Madsen (lmadsen) 2009-07-22 09:18:25

This issue is marked as blocking for 1.4.27, so it will get looked at by a developer when the resources are available, and it has become a high enough priority.
By: destiny6628 (destiny6628) 2009-07-30 02:19:36

Thank you for the reply.
Appreciate your response.

For the time being i had my problem under control with no calls half recorded.

Will post something, if get something to contribute.
By: Leif Madsen (lmadsen) 2009-09-21 10:45:41

I'm closing this for now per the reporter stating they have it under control with no half-recordings. If this issue crops back up, then please reopen. Thanks!