7 thoughts on - Delay On Speak With Asterisk

• I would firstly look at whether your Asterisk box is doing transcoding –
  converting from oe codec (supported by your phones) and another codec
  (supported by the provider) because no codec can be found in common between the two.

  Secondly I would put a full packet sniffer (by which I mean collect all the RTP
  data as well as SIP) on each of your interfaces (internal and external) to see whether the delay really is happening inside your Asterisk server – if you see RTP data on your internal interface, then appearing 1-1.5 seconds later on the external interface, and vice versa, then you know the delay is inside your system.

  No point in making such an assumption only to find out it’s someone else doing the transcoding and introducing the delay there 🙂

  Hope that helps,

  Antony.

  —
  Tinned food was developed for the British Navy in 1813.

  The tin opener was not invented until 1858.

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

  —

• Am 03.12.2019 um 19:57 schrieb Antony Stone:

  Hi Antony,

  thank you for your answer.

  I’m really not an expert on Asterisk… Could you please say me HOW can I check the codecs?

  I tried to get the information of the channel:

  bpi*CLI> sip show channel p65551t1575398506m6025c4749452s2

  * SIP Call
  Curr. trans. direction: Incoming
  Call-ID: p65551t1575398506m6025c4749452s2
  Owner channel ID: SIP/pbxanika-0000021e
  Our Codec Capability: (alaw)
  Non-Codec Capability (DTMF): 1
  Their Codec Capability: (ulaw|gsm|alaw|amr)
  Joint Codec Capability: (alaw)
  Format: (alaw)
  T.38 support No
  Video support No
  MaxCallBR: 384 kbps
  Theoretical Address: 217.x.x.x:5060
  Received Address: 217.x.x.x:5060
  SIP Transfer mode: open
  Force rport: Auto (No)
  Audio IP: 217.y.y.y (local)
  Our Tag: as45e11359
  Their Tag:
  h7g4Esbg_p65551t1575398506m6025c4749452s1_206873930-910452977
  SIP User agent:
  Username: 550293777072-0001
  Peername: pbxanika
  Original uri: sip:sgc_c@217.x.y.z
  Caller-ID: +4917711111111
  Need Destroy: No
  Last Message: Rx: ACK
  Promiscuous Redir: No
  Route:
  DTMF Mode: rfc2833
  SIP Options: timer
  Session-Timer: Inactive
  Transport: UDP
  Media: RTP

  Maybe it helps to find the problem?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• Am 03.12.2019 um 19:28 schrieb Luca Bertoncello:

  Hi again

  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?

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• 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!

  gsm seems to be unsupported from Deutsche Telekom… Already tried, it does not work… 🙁

  Down 50Mbps Up 10Mbps

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

  Thanks Luca Bertoncello
  (lucabert@lucabert.de)

  —

• 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.

  Well, that should certainly be plenty for a single VoIP channel (which I
  usually estimate as 100kpbs each way for ulaw or alaw).

  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.

  —

• Am 04.12.2019 um 11:14 schrieb Antony Stone:

  I tried again right now:

  disallow=all allow=alaw allow=gsm

  If I call my phone I can see, alaw is used. If I allow just gsm I get the error:

  [Dec 4 11:23:17] NOTICE[14060][C-0000012e]: chan_sip.c:10798
  process_sdp: No compatible codecs, not accepting this offer!

  So, back to alaw… 🙁

  OK, I forgot it… I privilege RTP, too… 😉

  Regards Luca Bertoncello
  (lucabert@lucabert.de)

  —