Clipping issue with SIP over satellite

Home » Asterisk Users » Clipping issue with SIP over satellite
Asterisk Users 5 Comments

I’m having a wierd clipping issue with one employee who’s using a phone
over a satellite Internet. He was sold that system specifically for use
with VoIP. Ping times show average round-trip time as around 700 ms with a
range of 560 to 841, so considerable jitter.

Things work fine when he’s talking to another Asterisk phone or to a SIP
trunk provider, but when connecting to a T1, there’s clipping where about
1/3 of his voice (in intervals of maybe 200ms) are removed. This sounds
like an echo canceller conflict, but I’ve set echocancel=no in
chan_dahdi.conf (I have hardware echo cancelling) and it didn’t do
anything. I’m forcing his codec to G729 for bandwidth reasons. The
phone is an Aastra 6757iCT.

Does anybody have any suggestions here?

5 thoughts on - Clipping issue with SIP over satellite

  • You have hardware echo canceling *outside* of your T1 card? If it’s an
    echo canceler on the card, then setting ‘echocancel=no’ disables it. You
    probably don’t want to do that.

    The DAHDI layer has some buffering that can help with jitter, but the
    default buffers can only handle 80ms of jitter. You can increase this by
    setting the ‘buffers’ option in chan_dahdi.conf; each buffer is 20ms by
    default.

    As long as what are dealing with is ‘simple’ jitter (just delayed
    packets), as opposed to packet reordering, then this should help quite a
    bit. If you have packet reordering occurring as well, then you’ll need a
    full-fledged adaptive jitter buffer on the channel to compensate for it.
    In recent releases of Asterisk, this can be done by using the
    JITTERBUFFER() dialplan function on the SIP channel in question, but
    since you didn’t mention your version of Asterisk, I can’t speculate
    whether that is available to you or not.

    It sounds like the lack of a proper jitter buffer (of adequate size) is
    the issue here, since when the audio is directed at endpoints outside of
    Asterisk that have them, the audio is as you’d expect it to be.

  • No, on the card.

    I’m running 1.6.2 and it appears that this is called jitterbuffers there.
    Is that right?

    I’ve set it to 20 and it did indeed help quite a bit, so I tried 30.

    Interestingly, that isn’t completely true. If it goes out a SIP trunk
    to PSTN, it works fine, but when it goes out a SIP trunk to the SV8300
    (where the T1 goes), it has the same problem. This was leading me to
    believe that the problem was on the 8300.

  • Then you definitely don’t want ‘echocancel=no’ set, or you’ll disable it.

    Yes.

    Excellent!

    Well, that doesn’t disprove my statement 🙂 Note that I said that when
    the audio is directed at endpoints that have a proper jitter buffer,
    there is no issue. If you send the call over SIP to this ‘SV8300’ device
    and still have audio issues, that would imply that this device does not
    have a jitter buffer capable of handling this level of jitter.

  • You can try and improve audio quality and “compensate” on the problems with the ‘SV8300’ device by using quality improvement software like PBXMate. It should be able and take care of server-side echo cancellation.

  • When I thought that it was echo cancellers fighting each other, that’s
    exactly what I wanted to do.