[asterisk-users] Call recording format

Vilius Adamkavicius vilius.adamkavicius at invade.net
Mon Nov 22 11:27:55 CST 2010


We are using wav, not WAV. I believe WAV is the one with GSM. Its a very
good idea to compare WAV against wav, will run some tests and come back with
outcome, will try Tzafrir's suggestion as well.

Thanks guys
Vilius.

On 22 November 2010 16:31, Joel Maslak <jmaslak at antelope.net> wrote:

> WAV or wav?  One of these has GSM-encoding inside a WAV formatted
> envelope.  That said, I wouldn't expect that to have any noticeable
> CPU utilization above that of GSM.  If you are using the non-GSM
> version of WAV, then I am as baffled as you - hopefully someone who
> knows more about this can help.
>
> On Mon, Nov 22, 2010 at 7:58 AM, Vilius Adamkavicius
> <vilius.adamkavicius at invade.net> wrote:
> > Hi Joel,
> > 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.
> > 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.
> > Thanks,
> > Vilius.
> > On 22 November 2010 14:19, Joel Maslak <jmaslak at antelope.net> wrote:
> >>
> >> What format are the actual calls in?  Are they in G.711u/a format or
> >> are they in something else (perhaps gsm?) format?  I'm asking to find
> >> out if Asterisk would need to transcode them.
> >>
> >> On Mon, Nov 22, 2010 at 6:47 AM, Vilius Adamkavicius
> >> <vilius.adamkavicius at invade.net> wrote:
> >> > Hi All,
> >> > We have a requirement to record over 60 simultaneous calls. Our
> >> > recording
> >> > facilities are implemented using Monitor() over AMI. The thing we have
> >> > noticed that making 60 simultaneous call recordings using wav CPU load
> >> > is
> >> > significantly higher (around 2 times more) than using gsm. Even
> writing
> >> > call
> >> > recordings to /dev/null makes a big difference in CPU load.
> >> > What could be the reason for this? Is Asterisk updating wav headers
> >> > every
> >> > time it writes?
> >> > What would be recommended hardware setup for over 60 simultaneous call
> >> > records?
> >> > Regards,
> >> > Vilius.
> >> >
> >> >
> >> >
> >> > --
> >> > _____________________________________________________________________
> >> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >> > New to Asterisk? Join us for a live introductory webinar every Thurs:
> >> >               http://www.asterisk.org/hello
> >> >
> >> > asterisk-users mailing list
> >> > To UNSUBSCRIBE or update options visit:
> >> >   http://lists.digium.com/mailman/listinfo/asterisk-users
> >> >
> >>
> >> --
> >> _____________________________________________________________________
> >> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >> New to Asterisk? Join us for a live introductory webinar every Thurs:
> >>               http://www.asterisk.org/hello
> >>
> >> asterisk-users mailing list
> >> To UNSUBSCRIBE or update options visit:
> >>   http://lists.digium.com/mailman/listinfo/asterisk-users
> >
> >
> >
> > --
> > Vilius Adamkavicius
> > InVADE Technical Support
> >
> >
> > 3 Berkeley Crescent, Bristol United Kingdom BS8 1HA
> >
> > Company Registration Number: 3660482
> > Registered in England and Wales
> > 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.
> >
> > international  phone number +44(0) 117 33 555 00
> >
> > --
> > _____________________________________________________________________
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> > New to Asterisk? Join us for a live introductory webinar every Thurs:
> >               http://www.asterisk.org/hello
> >
> > asterisk-users mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-users
> >
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> New to Asterisk? Join us for a live introductory webinar every Thurs:
>               http://www.asterisk.org/hello
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20101122/527271d4/attachment.htm 


More information about the asterisk-users mailing list