[asterisk-users] Odd one-way audio problem (Mike Diehl

[Stefan Viljoen]

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.