Page 1 of 1
WARNING[4554]: channel.c:787 channel_find_locked
Posted:
Tue Sep 19, 2006 6:36 pm
by dev_4901
Hi,
Suddenly I see lots of these messages on my asterisk CLI
Sep 20 04:39:08 WARNING[4554]: channel.c:787 channel_find_locked: Avoided deadlock for '0x8171098', 10 retries!
Sep 20 04:39:13 WARNING[4554]: channel.c:787 channel_find_locked: Avoided deadlock for '0x81d2420', 10 retries!
These come every 5 sec and are now begining to annoy me. Dont know whether they would be causing or probably are causing any problems.
Plz advice and thanx in advance.
Dev.
Posted:
Tue Sep 19, 2006 8:39 pm
by mflorell
Asterisk version?
astGuiclient version?
loadavg of the server when this happens?
Are you recording when this happens?
What kind of channels do you use?
Posted:
Tue Sep 19, 2006 9:20 pm
by dev_4901
asterisk version - 1.2.10
astGuiclient version - 1.1.12
loadavg of the server when this happens - .84
recording - YES
channels in use - SIP
Posted:
Tue Sep 19, 2006 10:01 pm
by mflorell
do you notice any choppy sound, audio delay or other issues with your SIP channels?
What kind of internet connection are you using?
How many recordings are you doing concurrently?
Posted:
Wed Sep 20, 2006 6:53 pm
by dev_4901
Hi,
No we are not experiencing any audio related issues.
We are on a 2MBps 1:1 bandwidth.
Yes, we record all calls.
Not using any hardware.
Dev.
Posted:
Wed Sep 20, 2006 8:11 pm
by mflorell
recording is probably your issue. What kind of hard drives are you using?
How many concurrent recordings do you do when this happens?
What are the specifications on this server? (CPU/RAM/drives)
Also, you should consider upgrading to astguiclient 2.0.1 because it has a new recording_delay setting that will wait a few seconds before starting recording of calls resulting in a great reduction in very short recordings and a great reduction in CPU load as well as drive writing bottleneck which is most likely your problem.
Posted:
Thu Sep 21, 2006 7:19 pm
by dev_4901
Hi,
We have a IBM x206 series machine with PIV 3.0 GHz , 1 GB RAM and 70 GB SATA.
I just noticed one thing, probably this can help.
In the recording extensions:
exten => 8309,1,Answer
exten => 8309,2,Monitor(wav,${CALLERIDNAME})
exten => 8309,3,Wait,3600
exten => 8309,4,Hangup
we are using WAV as the recording format. But I'm using g729 as the voice codec. This may be causing some system load, that the voice is first converted to WAV and then recorded.
I'm looking up at
www.voip-info.org to get the recording done in g729 only, if it can in any way get some load off the processor.
I also found that we can use RECORD in place of MONITOR.
Plz advice on this.
Dev.
Posted:
Thu Sep 21, 2006 8:05 pm
by enjay
unfortunately SATA drives just arent good for recording. Im sure I speak for everyone else here when I say "got SCSI?"
Recording to WAV is probably not your issue. However if you do convert to MP3 after the fact make sure you are not doing it on the same system (at least not during call-times).
-enjay
Posted:
Thu Sep 21, 2006 8:21 pm
by dev_4901
Hi,
I know SATA operates at a lower speed than SCSI, but cannot help it.
How do I record files in the g729 format only?
exten => 8309,1,Answer
exten => 8309,2,Monitor(g729b,${CALLERIDNAME})
exten => 8309,3,Wait,3600
exten => 8309,4,Hangup
Wud the above solution work?
If not can I do it like this ?
exten => 8309,1,Answer
exten => 8309,2,Record(g729b,${CALLERIDNAME})
exten => 8309,3,Wait,3600
exten => 8309,4,Hangup
Plz advice.
Dev
Posted:
Thu Sep 21, 2006 9:51 pm
by dev_4901
One thing I wish to confirm :
While using Audio Code in the VoIP setup and using g729 as the Voice codec.
1) The voice goes onto the bandwidth as g729 packets
2) The voice recieved is in the g729 packets
3) The voice is sent to the Audio Code g729 or WAV?
If it is in g729 only, then I guess recording the .in and .out files would be efficient and less taxing on the processor if they are in g729 format only.
Plz advice.
Dev.
PS: Today with 4 agents logged in I saw the loadavg touch 2.54.
Posted:
Thu Sep 21, 2006 10:05 pm
by enjay
I've never heard of recording to g729 for playback.
What was your dial level when you saw that load?
-enjay
Posted:
Thu Sep 21, 2006 10:17 pm
by dev_4901
Its not for playback. Just for recording. Then we can mix the .in and .out files as we do so for .wav
The dial level was 2.0
Plz also tell me about the audio code query.
Dev.
Posted:
Thu Sep 21, 2006 10:22 pm
by enjay
Not sure what you mean by audio query. I would assume that g729 would be MORE taxing regardless since its better compression (requiring more CPU to process).
-enjay
Posted:
Sat Sep 23, 2006 4:48 pm
by dev_4901
Matt,
Plz, I think you gotta step in and go thru this thread after your last reply.
I'm still confused here about the actual format of voice transmission internally(my local LAN i.e server to agents).
Also do tell me, whether I can use g729 as the recording format in place of WAV?
Also can I use RECORD in place of MONITOR in the recording extensions?
What changes do I have to make in the AST_CRON_mix_recordings_BASIC.pl, so as to get the mixed audio file?
Plz advice.
Thanx in advance.
Dev.
Posted:
Thu Sep 28, 2006 7:58 pm
by dev_4901
Hi All,
I've been reading about the reasons about high loads, and have found one reason that is probably causing high loads :
Its TRANSCODING BETWEEN DIFFERENT VOICE CODECS.
But what I cant understand is : I use g729 to send voice to my provider, voice comes as g729 to me from the provider. Its then sent to the Audio Code as g729 and then the Audio code sends it to the agents.
Where is the TRANSCODING DONE? It's done while recording, I know this.
exten => 8309,1,Answer
exten => 8309,2,Monitor(wav,${CALLERIDNAME})
exten => 8309,3,Wait,3600
exten => 8309,4,Hangup
Except this, is the TRANSCODING done any place else that I'm probabaly skipping?
Can I use RECORD in place of MONITOR like :
exten => 8309,2,Record(${CALLERIDNAME}:g729)
as the supported sound formats are: g723, g729, gsm, h263, ulaw, alaw, vox, wav, WAV.
Plz advice and thanx in advance.
Dev Singhal.
Posted:
Thu Sep 28, 2006 8:42 pm
by mflorell
I had problems using Record a year ago. haven't tried it recently, might work fine.
As for transcoding. Meetme transcodes everything to slin, so having agents on same codec as trunks does nothing to help loadavg.