Stefan Viljoen
2019-Mar-27 06:36 UTC
[asterisk-users] Odd one-way audio problem (Mike Diehl
Hi Mike
No rtp.conf in /etc/asterisk?!
This might be part of your problem, AFAIK rtp.conf is part of any standard
installation.... might it be that you have a corrupted Asterisk install and / or
-other- missing conf files as well?
Might this not also be part of your problem?
I installed Asterisk 13 by downloading the 13.22.0 version from Digium as a
source .tar.gz and compiling and installig it myself, by hand. Not sure if yours
comes from a distro repo or something similar which has been modified or is not
a standard install.
That might also be something to try, e. g. see if you can compile a
"clean" instance, from canon community version source, from Digium
itself directly, and see if that changes anything.
Note that the 10000 and 20000 ranges I show below was mandated by my voice
service provider, yours may differ! For example, I run 17 instances of Asterisk
in South Africa with Centracom (my voice service provider) and in South Africa I
have to use 10000 - 20000.
However, we also run a branch in Colorado in the United States with Twilio LLC
as voice service provider in the USA, and they -require- 10000 - 65535 to be
used in rtp.conf... or you get exactly what you describe, e. g. random calls
have no audio in either of the two directions.
For reference, your /etc/asterisk/rtp.conf file has a set format, e. g. it has
to look like this (to parse, and work, I assume):
/etc/asterisk/rtp.conf
---
;
; RTP Configuration
;
[general]
;
; RTP start and RTP end configure start and end addresses
;
; Defaults are rtpstart=5000 and rtpend=31000
;
rtpstart=10000
rtpend=20000
;
; Whether to enable or disable UDP checksums on RTP traffic
;
;rtpchecksums=no
;
; The amount of time a DTMF digit with no 'end' marker should be
; allowed to continue (in 'samples', 1/8000 of a second)
;
;dtmftimeout=3000
; rtcpinterval = 5000 ; Milliseconds between rtcp reports
;(min 500, max 60000, default 5000)
---
As you can see, defaults (if no rtp.conf specified) is 5000 and 31000 which is
probably what you have been using up to this point, since you state that there
was no rtp.conf on your system.
Also, you might need to do a "core reload" to make any changes to
rtp.conf effective. A sip reload only re-parses sip.conf and reloads the SIP
substructure and channel drivers, AFAIK it a sip reload doesn't affect RTP
and doesn't parse and apply rtp.conf.
As regards the problems, are you sure that (for example) the audio codecs used
are fully specified on, for example, the phones on either side?
With Yealink T-21 phones for example (and older ATCOM 820's and some older
Polycoms) it is possible to turn off some codecs, and turn others on - I once
had this kind of intermittent voice issue but only on a certain extension, and
it turned out that the particular Yealink's codec mix was set too narrow (it
would only accept ulaw and alaw, not G729) and this was precluding that phone
from receiving incoming calls from our service provider (which only offer G729)
while in-office calls to and from it worked fine as the other phones in the
office were allowing running ulaw and alaw, -and- G729 so that any phone could
take an incoming call (in G729) and have audio. Not sure of the dynamics (as
Asterisk AFAIK should handle this situation transparently, transcoding as needed
AFAIK) but it was definitively fixed by allowing G729 on the particular Yealink
phone's web interface.
The only remaining issue may be NATing, e. g. for a particular network path to /
from a particular client, the intervening firewalls and / or routers might not
allow the required UDP ports to be opened to allow RTP flow. You can set what
you like in rtp.conf, but all the intervening network segments you use to get to
the phone (and your VOIP trunk provider / service provider) -also- need to allow
all the necessary UDP ports to be opened so RTP can flow back and forth. This
might again be why it sometimes works, e. g. sometimes RTP ports are negotiated
on port numbers that are too low / too high for a particular network segment or
network edge device like a router or hardware / software firewall, and then
there's no audio. The RTP port number is too low or too high for the
intervening routers / firewalls, even though Asterisk is perfectly fine with
that RTP port number, the intervening network(s) is incapable of carrying the
RTP flow as the port number is invalid according to a router / firewall
configuration on a device between you and the phone.
If a customer is in a state of no audio, what does
sip show channelstats
in the Asterisk CLI, show?
E. g. the "sip show channelstats" display shows RTCP (RTP control
protocol) statistics, e. g. how bad the jitter and packet loss for a particular
call is on a certain extension for the incoming and outgoing legs of the call.
In a situation with no audio, can you check on this to see if (for example)
-any- RTP packets flow at all? E. g. a particular readout of "sip show
channelstats" on one of my servers:
asterisk*CLI> sip show channelstats
Peer Call ID Duration Recv: Pack Lost (
%) Jitter Send: Pack Lost ( %) Jitter
xxx.xxx.xxx.xxx 2faf8f31239 00:05:09 0000014686 0000000000 ( 0.00%)
0.0000 0000014653 0000000000 ( 0.00%) 0.0001
You will see IP addresses in the left column, translate to an extension number
by looking that IP up in
sip show peers
What you -might- see is that a call pops up in the sip show channelstats list,
but its lost packet count for both of the two count columns (received, or sent)
spikes very very quickly and then the call might end (e. g. the time column
clears) as a user hangs up the call gets cut off. This can indicate that the
call was successfully setup via SIP, but actual RTP transmission failed. You may
also see that one column (received, or sent) only spikes, indicating that that
channel's RTP port for the particular type of flow - in or out - wasn't
open.
Then maybe you can use the Call ID to identify the call to your SIP service
provider so they can check on their side if they can trace the call flow?
(Centracom SA for example can provide a full graphical SIP negotiation trace
which includes RTP port numbers negotiated, if you can identify the call and
send them the key.)
Note that the call ID is much longer than in the column display, e. g. a visual
call ID in the sip show channelstats display may be
31f867c50ce
but the full call ID is then
32d867a55cfb563b7f59da01de84dc6f at xxx.xxx.xxx.xxx:5060
The full ID can be obtained by typing the partial ID as displayed in the list in
the Asterisk CLI and then hitting TAB on the keyboard.
Maybe this helps a bit...
Kind regards,
---
Hi, and thank you for your suggestion!
As it turns out, my server didn't even HAVE an rtp.conf file... (No, I
don't know how that happened...)
So I created one with:
rtpstart=10000
rtpend=20000
and reloaded chan_sip.
I hope that is sufficient. Or do I need to restart asterisk completely?
Anyway, my user tested later that day and they are still having problems....
Any other ideas?
Mike.