asterisk users - Dec 2019 - Delay on speak with Asterisk

On Wednesday 04 December 2019 at 07:37:51, Luca Bertoncello wrote:
> Am 03.12.2019 um 19:28 schrieb Luca Bertoncello:
> 
> Hi again
> 
> > This delay happens on every peer, Deutsche Telekom and Messagenet, so
I
> > think the problem is NOT by the Provider, but in my configuration...
> 
> Maybe I got the solution...
> I see, that I had the jitter buffer active. As I deactivated it, I have
> no delay anymore.
> Unfortunately is the audio quality now a little bad than with the jitter
> buffer...
> 
> Any suggestion how can I improve the audio quality without add the delay?
1. Try using codec GSM (which is pretty good quality but lower bandwidth than 
alaw, which is currently the only one you are offering).

2. What is the bandwidth (upstream is more important than downstream) of your 
Internet connection?


Antony.

-- 
Why is "dylexia" so difficult to spell, and why can I never remember
"aphasia"
when I want to?

                                                   Please reply to the list;
                                                         please *don't* CC
me.

Am 04.12.2019 um 10:53 schrieb Antony Stone:

Hi Antony!
> 1. Try using codec GSM (which is pretty good quality but lower bandwidth
than
> alaw, which is currently the only one you are offering).
gsm seems to be unsupported from Deutsche Telekom...
Already tried, it does not work... :(
> 2. What is the bandwidth (upstream is more important than downstream) of
your
> Internet connection?
Down 50Mbps
Up   10Mbps

On my Router (Debian 9) I configured a traffic shaper that privileges
the SIP-Packets.

Thanks
Luca Bertoncello
(lucabert at lucabert.de)

On Wednesday 04 December 2019 at 11:00:23, Luca Bertoncello wrote:
> Am 04.12.2019 um 10:53 schrieb Antony Stone:
> 
> Hi Antony!
> 
> > 1. Try using codec GSM (which is pretty good quality but lower
bandwidth
> > than alaw, which is currently the only one you are offering).
> 
> gsm seems to be unsupported from Deutsche Telekom...
> Already tried, it does not work... :(
Hm, I was judging based on what you posted previously:

  Our Codec Capability:   (alaw)
  Their Codec Capability:   (ulaw|gsm|alaw|amr)
  Joint Codec Capability:   (alaw)

which suggested to me that if you offered GSM, that could be agreed with the 
other side.
> > 2. What is the bandwidth (upstream is more important than downstream)
of
> > your Internet connection?
> 
> Down 50Mbps
> Up   10Mbps
Well, that should certainly be plenty for a single VoIP channel (which I 
usually estimate as 100kpbs each way for ulaw or alaw).
> On my Router (Debian 9) I configured a traffic shaper that privileges
> the SIP-Packets.
Ah, but SIP is not RTP :)

SIP is used to set up the call, tell the other end what number you want to 
dial, tell you that the phone needs to ring, etc.  It's not the audio part
of
the call once it's set up.

RTP is the audio part of the call, and that's what you're saying is not
so
good now you've disabled the jitter buffer.

RTP is UDP packets normally sent on any port between 10,000 and 20,000, so you 
need to ensure that your router allows that through with as low latency (and 
very importantly, consistent latency, since inconsistent latency = jitter) as 
possible.

Prioritising SIP is hardly ever needed - who cares about a few tenths of a 
second setting up or responding to a call?  What needs prioritising, and QoS 
if you can do it, is RTP.


Antony.

-- 
Police have found a cartoonist dead in his house.  They say that details are 
currently sketchy.

                                                   Please reply to the list;
                                                         please *don't* CC
me.