Less Good Call Quality Using Asterisk

Report
Question
Hello,

I am currently using the following setup: Snom 300 - Asterisk 1.8.13.0 running on Raspberry Pi - Sipgate SIP Provider When I am using this setup, the call quality isn't as good as when using a direct connection like Snom 300 - Sipgate SIP Provider to my SIP Provider (Sipgate).

Sipgate supports

0x08 (G.711), so the best one possible. Still the quality isn't as good as on a direct connection between my Snom phone and Asterisk. Using Asterisk it feels a little bit like there is some more background noise or so. Any hints why the quality using Asterisk is less good than on a direct connection? Does Asterisk by default change anything on the signal or is it just passed through? Thanks :-)

Best regards Stefan
Asterisk Users 3 years ago 8 Answers

Answers ( 8 )

  1. Doug Lytle
    +1
    July 21, 2012 at 14:13 pm
    Reply

    Stefan at WPF wrote:

    Not that I can help, but I'm sorta shocked that you have Asterisk running on a Raspberry Pi!

    Very cool!

    Doug

  2. Mike
    +1
    July 21, 2012 at 14:19 pm
    Reply

    I've had it running on a Guruplug without any problems - http://www.globalscaletechnologies.com/p-49-guruplug-server-standard.aspx#summary - handly little device if you need something small.

  3. Stefan at
    +1
    July 23, 2012 at 10:57 am
    Reply

    --14dae9340afb9964e204c5814ace Content-Type: text/plain; charset=ISO-8859-1

    For private use the RPI is really cool for that, though I am not yet sure if it works 100% without problems - at least it did in my latest tests. Anyone has any hint on the call quality or if Asterisk does any kind of transcoding of the audio?

    2012/7/21 Mike

    --14dae9340afb9964e204c5814ace Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

    For private use the RPI is really cool for that, though I am not yet sure i= f it works 100% without problems - at least it did in my latest tests.

    = Anyone has any hint on the call quality or if Asterisk does any kind of tra= nscoding of the audio?

    2012/7/21 Mike <ispbuilder@gmail.com= >
    On 12-07-21 04:13 PM, Doug Lytle wrote:
    Stefan at WPF wrote:
    Snom 300 - Asterisk 1.8.13.0 running on Raspberry Pi

    Not that I can help, but I'm sorta shocked that you have Asterisk runni= ng on a Raspberry Pi!

    I've had it running on a Guruplug without any problems - http://www.globalscaletechnologies.com/p-<= /u>49-guruplug-server-standard.aspx#summary - handly little devi= ce if you need something small.





    --
    Looking for (employment|contract) work in the
    Internet industry, preferrably working remotely.
    Building / Supporting the net since 2400 baud was
    the hot thing. Ask for a resume! ispbuilder@gmail.com

    --
    _____________________________________________________________= ________
    -- Bandwidth and Colocation Provided by http://www.api-digital.com --
    New to Asterisk? Join us for a live introductory webinar every Thurs:
    =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://www.asterisk.org/hello

    asterisk-users mailing list
    To UNSUBSCRIBE or update options visit:
    =A0 http://lists.digium.com/mailman/listinfo/asterisk-= users



    --14dae9340afb9964e204c5814ace

  • Kevin P.
    +1
    July 23, 2012 at 11:07 am
    Reply

    If both legs of the call are using the same codec, then normally Asterisk would not modify the audio in any way at all.

  • Bakko
    +1
    July 23, 2012 at 11:11 am
    Reply

    Hello,

    I tried Asterisk Confbridge with raspberry pi without audio issue.

    Asterisk was compiled from sources.

    http://www.voztovoice.org/?q=node/553

    Regards

  • Stefan at
    +1
    July 25, 2012 at 06:42 am
    Reply

    Hmm is it possible, that the monitor command changes the quality? If not I guess I also once have to try compiling it from source, though I wanted to avoid that.

    2012/7/23 Bakko

  • Kevin P.
    +1
    July 25, 2012 at 09:39 am
    Reply

    It certainly can, since recording the call causes disk I/O as the audio is written out. In addition, Monitor is more prone to this problem than MixMonitor is, because Monitor's call recording is done in the same thread that handles the call's audio normally. If you switch to MixMonitor, you'll probably have better results, unless your system just can't handle recording the call without overloading its CPU.

  • Stefan at
    +1
    August 1, 2012 at 07:21 am
    Reply

    Thank you Kevin, I have the impression it got better, but I yet didn't have the chance to test it much. If there are I/O problems, are there any logs for this / are there logs in general for monitor and MixMonitor? Thanks :-)

    2012/7/25 Kevin P. Fleming

  •  Prev question

    Next question