Hi Joel,<div><br></div><div>We have a meetme on which we are landing two G.711 alaw calls, one coming from TDM another from SIP. Once we those parties are in the conference we are adding one more leg using Local channel and starting to record it.</div>
<div><br></div><div>Surely it would be logical if it would be less overhead recording alaw wav since we are using alaw on both parties, but its not.</div><div><br></div><div>Thanks,</div><div>Vilius.</div><div><br><div class="gmail_quote">
On 22 November 2010 14:19, Joel Maslak <span dir="ltr"><<a href="mailto:jmaslak@antelope.net">jmaslak@antelope.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
What format are the actual calls in? Are they in G.711u/a format or<br>
are they in something else (perhaps gsm?) format? I'm asking to find<br>
out if Asterisk would need to transcode them.<br>
<div><div></div><div class="h5"><br>
On Mon, Nov 22, 2010 at 6:47 AM, Vilius Adamkavicius<br>
<<a href="mailto:vilius.adamkavicius@invade.net">vilius.adamkavicius@invade.net</a>> wrote:<br>
> Hi All,<br>
> We have a requirement to record over 60 simultaneous calls. Our recording<br>
> facilities are implemented using Monitor() over AMI. The thing we have<br>
> noticed that making 60 simultaneous call recordings using wav CPU load is<br>
> significantly higher (around 2 times more) than using gsm. Even writing call<br>
> recordings to /dev/null makes a big difference in CPU load.<br>
> What could be the reason for this? Is Asterisk updating wav headers every<br>
> time it writes?<br>
> What would be recommended hardware setup for over 60 simultaneous call<br>
> records?<br>
> Regards,<br>
> Vilius.<br>
><br>
><br>
><br>
</div></div>> --<br>
> _____________________________________________________________________<br>
> -- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
> New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
> <a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
><br>
> asterisk-users mailing list<br>
> To UNSUBSCRIBE or update options visit:<br>
> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
<a href="http://www.asterisk.org/hello" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Vilius Adamkavicius<br>InVADE Technical Support<br><br><br>3 Berkeley Crescent, Bristol United Kingdom BS8 1HA<br><br>Company Registration Number: 3660482<br>Registered in England and Wales<br>
this email, and any attachment, is intended only for the attention of the addressee. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not the intended recipient, please destroy all copies and inform the sender by return email. If you have received this email in error, please return it to the sender and highlight the error. We accept no legal liability for the content of the message. Any opinions or views presented are solely the responsibility of the author and do not necessarily represent those of InVADE. We cannot guarantee that this message has not been modified in transit, and this message should not be viewed as contractually binding. Although we have taken reasonable steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.<br>
<br>international phone number +44(0) 117 33 555 00 <br>
</div>