[asterisk-users] Audio start delayed by 5-10 seconds, bizarre core show translation recalc output.

[Maciej Bonin]

Hello asterisk-users,

We're having very odd problems while testing a new server, the
configuration is exactly the same as our live cluster, save for a floating
address managed by exabgp - the remaining nodes use ucarp.
As far as I could tell the versions of asterisk ( 1.8.23.1 ), system
packages and even the hardware are the same as on all the others.

The most confusing of all is the output of core show translation recalc:

ast9a*CLI> core show translation recalc 10
         Recalculating Codec Translation (number of sample seconds: 10)

         Translation times between formats (in microseconds) for one second
of data
          Source Format (Rows) Destination Format (Columns)

           g723   gsm  ulaw  alaw g726aal2 adpcm  slin lpc10  g729 speex
 ilbc  g726  g722 siren7 siren14 slin16  g719 speex16 testlaw
     g723     -     2     2     2        2     2     1     2     2     -
  2     2     2      -       -      3     -       -       2
      gsm     2     -     2     2        2     2     1     2     2     -
  2     2     2      -       -      3     -       -       2
     ulaw     2     2     -     1        2     2     1     2     2     -
  2     2     2      -       -      3     -       -       2
     alaw     2     2     1     -        2     2     1     2     2     -
  2     2     2      -       -      3     -       -       2
 g726aal2     2     2     2     2        -     2     1     2     2     -
  2     2     2      -       -      3     -       -       2
    adpcm     2     2     2     2        2     -     1     2     2     -
  2     2     2      -       -      3     -       -       2
     slin     1     1     1     1        1     1     -     1     1     -
  1     1     1      -       -      2     -       -       1
    lpc10     2     2     2     2        2     2     1     -     2     -
  2     2     2      -       -      3     -       -       2
     g729     2     2     2     2        2     2     1     2     -     -
  2     2     2      -       -      3     -       -       2
    speex     -     -     -     -        -     -     -     -     -     -
  -     -     -      -       -      -     -       -       -
     ilbc     2     2     2     2        2     2     1     2     2     -
  -     2     2      -       -      3     -       -       2
     g726     2     2     2     2        2     2     1     2     2     -
  2     -     2      -       -      3     -       -       2
     g722     2     2     2     2        2     2     1     2     2     -
  2     2     -      -       -      1     -       -       2
   siren7     -     -     -     -        -     -     -     -     -     -
  -     -     -      -       -      -     -       -       -
  siren14     -     -     -     -        -     -     -     -     -     -
  -     -     -      -       -      -     -       -       -
   slin16     3     3     3     3        3     3     2     3     3     -
  3     3     1      -       -      -     -       -       3
     g719     -     -     -     -        -     -     -     -     -     -
  -     -     -      -       -      -     -       -       -
  speex16     -     -     -     -        -     -     -     -     -     -
  -     -     -      -       -      -     -       -       -
  testlaw     2     2     2     2        2     2     1     2     2     -
  2     2     2      -       -      3     -       -       -

The above result starts showing up about a minute or two into asterisk's
runtime, and never goes back to normal. We're not 100% it's related, but
the nodes that are functioning correctly do not exhibit this behaviour.
Could this be in-memory caching ? Why on this node and not others ?
On the end user side this seems to be a 5-10 second delay in receiving
audio, sometimes no audio is received at all. Nothing unusual in logs. We
have also done several packet captures and from the network side it seems
like asterisk is just not sending any audio after the call is picked up. We
are using UDP for transport.
Please let us know if you've come across a problem like this before, I've
had no luck tracking down any similar problems, most people seem to have
trouble just with g729, if at all.

Kind regards,
Maciej Bonin
Systems Administrator
Packnet Limited
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20150915/06b826e6/attachment.html>