<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
Matt,<br>
<br>
The calls are u-Law. The format of the recordings is PCM. Is this
correct to prevent transcoding the recording? We've noloaded all other
codecs, so I don't believe that transcoding is occurring. I've only
ever seen "show translation" generate the following output:<br>
<br>
<tt>immlx15*CLI> show translation<br>
Translation times between formats (in milliseconds)<br>
Source Format (Rows) Destination Format(Columns)<br>
<br>
g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 speex
ilbc<br>
g723 - - - - - - - - - -
-<br>
gsm - - - - - - - - - -
-<br>
ulaw - - - - - - 1 - - -
-<br>
alaw - - - - - - - - - -
-<br>
g726 - - - - - - - - - -
-<br>
adpcm - - - - - - - - - -
-<br>
slin - - 1 - - - - - - -
-<br>
lpc10 - - - - - - - - - -
-<br>
g729 - - - - - - - - - -
-<br>
speex - - - - - - - - - -
-<br>
ilbc - - - - - - - - - -
- </tt><br>
<br>
Any suggestions on hardware? Are you talking the entire server or
components?<br>
<br>
I'll look into the megaraid2 drivers, but I'm interested in knowing how
they come into play when recording to a RAM disk.<br>
<br>
Matthew Roth<br>
InterMedia Marketing Solutions<br>
Software Engineer and Systems Developer<br>
<br>
Matt Florell wrote:
<blockquote
cite="mid61575c810512130917r20eb68abt2bd151b576a70082@mail.gmail.com"
type="cite">
<pre wrap="">What codec are the calls? What codec are you recording in?
I would try some non-Dell hardware, I would also try a less bloated
Linux Distro, something like Slackware, just to see if that had any
effect. And make sure you use the megaraid2 linux drivers.
MATT---
On 12/13/05, Matt Roth <a class="moz-txt-link-rfc2396E" href="mailto:mroth@imminc.com"><mroth@imminc.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Matt Florell wrote:
>Hello,
>
>Need some more information here:
>- hardware specs (including what kind of hard drives?)
The Asterisk server is a Dell PowerEdge 6850 with the following specs.
Please note that we are NOT recording to the hard drive. We are
recording to a RAM disk as detailed here
(<a class="moz-txt-link-freetext" href="http://voip-info.org/wiki/view/Asterisk+Dimensioning">http://voip-info.org/wiki/view/Asterisk+Dimensioning</a>) under the heading
"512 simultaneous SIP-to-SIP calls with Digital Recording".
Unfortunately, the scalability tests we did at that time assumed that if
call quality was good, so was the quality of the recording.
Processor: Quad Intel Xeon 3.16GHz/1MB Cache
Memory: 20 GB DDR2 400MHZ Single Ranked DIMMs (4 GB System / 16 GB RAM Disk)
Hard Drive: Two 73GB, U320, SCSI, 1IN 15K Configured in a RAID 1 (Mirrored)
Hard Drive Controller: Embedded RAID - PERC4 Integrated (Driver:
megaraid_mm, megaraid_mbox)
Everything else:
<a class="moz-txt-link-freetext" href="http://www.dell.com/downloads/global/products/pedge/en/PE6850_specs.pdf">http://www.dell.com/downloads/global/products/pedge/en/PE6850_specs.pdf</a>
>- Linux kernel version
2.6.12-1.1376_FC3smp (Fedora Core 3).
>- running Xwindows?
No.
>- Asterisk version
ABE-A.2-beta (Asterisk Business Edition A.2 beta).
>- kind of calls you are recording (Zap, SIP, IAX, Meetme, ...)
Calls originate on the PSTN and are handled by a Cisco AS5400 Universal
Gateway that is a SIP peer of Asterisk. The AS5400 converts the calls
from TDM channels to VoIP (SIP) channels before sending them to
Asterisk. The Asterisk dialplan then routes them to one of our agents,
who are using SNOM 320 VoIP (SIP) phones. Essentially all of our calls
are SIP-to-SIP, with absolutely no protocol bridging or transcoding
occurring on the Asterisk server.
The Asterisk server handles the following major tasks:
- Routing calls through the dialplan to (dynamic) agents in the
appropriate queues.
- Adding/removing agents to/from queues via AddQueueMember and
RemoveQueueMember (NO static agents!).
- Recording calls via the Monitor application directly to RAM disk.
Calls are moved to a remote machine for mixing.
- ChanSpy-based quality assurance of calls. Neither ChanSpy nor the
quality of the calls themselves is affected by the problem.
>- how many recordings at once
Anywhere from 5 to 30 concurrent recordings. This is not our planned
peak, but it's where we've experienced the problem so far. We have not
yet determined if the number of concurrent recordings is an issue, but
we are considering it. We also haven't determined if the problem gets
worse as the number of recordings increases, but it definitely exists
throughout that entire range.
>In my experience, HyperThreading does not cause recording problems,
>it's usually a disk issue. When we had issues, switching to fast SCSI
>drives on a MegaRAID 320-1 with the megaraid2 linux driver solved all
>of our problems(skips and clicks/pops)
The disk issues also directly interfere with call quality, as our
previous scalability tests showed. Digium seems to think that the issue
is scaling (some resource contention that causes a bit of audio to be
unavailable when the write occurs). I see their point, but given our
hardware and the current call volume I'm not completely sold on it.
Could it be a configuration issue (file handles, interrupts, etc...)?
>MATT---
Colin Anderson wrote:
>Matt Roth: FWIW, I am recording 1000-1500 calls a day (as of 8:52PM today,
>1482 calls!) of various length on my Netfinity with the onboard IBM RAID
>controller in RAID 5 Ultra 320 SCSI with suprisingly good quality. As the
>other Matt indicated, maybe what is needed here is an intelligent
controller
>to offload some of the chore.
>
>No definite solution here, but at least it's another data point to
compare.
I appreciate any information contributed by list users. It's by far the
most valuable resource available to me.
>On 12/12/05, Matt Roth <a class="moz-txt-link-rfc2396E" href="mailto:mroth@imminc.com"><mroth@imminc.com></a> wrote:
>
>>List users,
>>
>>I'm using the Monitor application to record calls. Most of the
>>recordings are audible, but contain skips accompanied by a popping
>>sound. Sometimes they are isolated, sometimes they appear in groups.
>>Call quality is excellent and seems unaffected by whatever is causing
>>this problem.
>>
>>If anyone has experienced this problem before, I'd appreciate if you'd
>>share what the source was and any tips on eliminating it. I contacted
>>Digium tech support and they suggested turning off hyperthreading. I
>>have done that, but I won't know if it improved things until tomorrow.
>>
>>The machine is running at a moderate call volume and is always at least
>>90% idle. I'm not seeing any "Avoided deadlock" messages in the logs.
>>If you need any more information, I'd be happy to provide it.
Thank you,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
</pre>
</blockquote>
</body>
</html>