Summary:ASTERISK-14934: Asterisk cuts audio to the internal extension
Reporter:ilker Aktuna (mrmrmrmr)Labels:
Date Opened:2009-10-02 15:37:03Date Closed:2015-03-14 09:06:17
Versions:Frequency of
Environment:Attachments:( 0) agi_fail.txt
( 1) all_sip_conf.txt
( 2) audio-problem.cap
( 3) rtp_debug.txt
( 4) trace.txt

I have a problem with one call scenario on my Asterisk server.
The call is coming from an external SIP proxy to my server. Asterisk sends the call to one internal extension.
Extension rings and then answers.
The user at extension hears audio for 0.5 seconds. Then audio in that direction is cut. (no RTP is sent)
Audio in other direction continues.

I got network traces for this call scenario. Everything seems normal in SIP messaging and as RTP.
I can also see that external audio continues even after the internal extension's audio is cut.

This problem occurs with one type of CPE on the external side. With other CPEs this problem is not reproduced.

I believe Asterisk cuts the internal extension's audio because it doesn't like something in the RTP stream of external CPE.

I will add the network trace for unsuccessful call together with RTP debug on Asterisk.
On both of these files it is clearly seen that one way audio is cut in a very short time after call is established.


The Asterisk server has 2 interfaces (ppp0 to WAN, and br0 to LAN)
So internal clients reach the Asterisk on br0 interface and Asterisk reaches the external proxy through ppp0.

In the network trace IP addresses are: : Asterisk server LAN address : Extension 995 in LAN , Linksys SPA 3000 : Asterisk server WAN address : External SIP Proxy : SIP Proxy RTP address

Comments:By: Leif Madsen (lmadsen) 2009-10-05 10:41:20

You will also need to provide the SIP trace from the Asterisk console along with the sip history (per sip.conf) in order to debug this issue easier. We must see what Asterisk is doing at the console, and not just the pcap trace.

Please see the bug guidelines at http://www.asterisk.org/developers/bug-guidelines for more information. Thanks!

By: ilker Aktuna (mrmrmrmr) 2009-10-05 13:39:13

Ok; I got the sip trace along with the RTP trace on Asterisk console and attached it.
I also attached a text file which includes all of my sip configuration.

Please let me know if anything else is required.

By: Elazar Broad (ebroad) 2009-10-09 09:45:49

In the additional information you have your server at, I don't see this anywhere in the sip trace. I do see your server using as its public address, is that correct?

By: ilker Aktuna (mrmrmrmr) 2009-10-09 11:50:15

The ppp0 interface has a dynamically changing IP address. Each time the ADSL connection is established it receives a new IP.
You are correct; is the IP address of ppp0 interface at the time of that trace.

By: Elazar Broad (ebroad) 2009-10-09 11:59:07

Are you running this through a NAT firewall?

By: ilker Aktuna (mrmrmrmr) 2009-10-10 07:56:02

Asterisk is on a box with 2 interfaces (wan: ppp0 , lan: br0)
There is Shorewall firewall on the box but as the Asterisk is listening on both interfaces and acts as a sip proxy, there is no NAT for RTP.
Besides, this problem does not occur with some type of remote CPEs (on the external sip proxy)

By: ilker Aktuna (mrmrmrmr) 2009-10-14 12:25:40

I have an additional information about this issue:

I changed the configuration so that the call is forwarded to "echo test" application instead of the LAN sip client.
The call from the same external CPE is connected and for a while the echo is heard well.
But after some seconds (like 5-10 secs) echo is cut.
Then I noticed that the audio in one direction is cut when I stop talking.
It seems to be related to VAD (voice activity detection) or silence suppression.
Of course I am not sure if the issue that occured in echo test is related to the original issue.

Now, is there any way to enable/disable VAD on Asterisk configuration ?

By: Elazar Broad (ebroad) 2009-10-14 12:40:39

As far as I know, Asterisk itself does not do any voice detection, the only thing that I could think of that possibly comes close is RTP timers, which will terminate a call after a certain period of RTP inactivity. With that said, your last note got me thinking, and a little Googling confirms that G729 has a VAD capability built into the codec, however, Asterisk explicitly requests peers to disable it via 'a=fmtp:18 annexb=no' which signals the peer to disable annexb(see http://en.wikipedia.org/wiki/G.729#G.729_Annex_B). Chances are the peer on the far end is ignoring this and since Asterisk is not inserting 'hiss frames', the far end assumes that the link is dead.

By: ilker Aktuna (mrmrmrmr) 2009-10-14 14:06:35

thanks for the information. however, the far end does not th?nk the link is closed. it keeps sending RTP. And even, Asterisk is sending RTP to the far end.
It's just that Asterisk does not forward the received RTP to the internal client.
Can you comment on that ?

By: Elazar Broad (ebroad) 2009-10-14 14:27:55

Hmm, I was going based on your previous note that the audio cut out when the external peer called your echo extension, leaving your internal extension out of the mix. Does audio cut out when you dial your echo extension from your internal phone?

By: ilker Aktuna (mrmrmrmr) 2009-10-14 14:57:02

no; when I make the call from internal client the audio is fine. both with echo test and the external client.

By: Elazar Broad (ebroad) 2009-10-14 15:08:51

Does your local extension support G729(not G729a)?

By: ilker Aktuna (mrmrmrmr) 2009-10-14 15:35:34

local extension is on a linksys spa3000.
on the linksys gui , I have g729a codec not g729.
but there is "silence supp enable" option which is not selected.

By: Elazar Broad (ebroad) 2009-10-14 15:49:52

Can you disable G729a on the SPA3000?

By: ilker Aktuna (mrmrmrmr) 2009-10-14 16:00:01

if I disable g729a then I won't be able to use g729; it will fall back to g711.
This is something I don't want, but if you want it for just testing purpose, I can try.

By: Elazar Broad (ebroad) 2009-10-14 16:13:25

Hmm, both G729a and G729 are essentially the same(they share the same RTP map). Do you have a G729 license installed on your Asterisk instance?

By: ilker Aktuna (mrmrmrmr) 2009-10-14 16:35:29

on the spa3000 there is only g729a , no plain g729.
So if I disable g729a , it will fall back to g711.

on Asterisk , I don't have g729 license.
But as there will be no transcoding, I don't need a license, right ?

By: Elazar Broad (ebroad) 2009-10-14 16:39:57

I believe that is correct. What happens when you disable G729 on the SPA?

By: ilker Aktuna (mrmrmrmr) 2009-10-14 16:52:03

I will try that tomorrow (as it is night time now, everybody at home is sleeping and I don't want to disturb)

aart from that test, I wonder why it is not possible to analyze this issue with Asterisk traces/logs ?
The RTP on one side is suddenly cut by Asterisk and I get nothing on the debugs. isn't that weird ?

as a side note, we know that the problem also occurs when there is no internal client and the external call is answered by echo application.
so, changing the internal client's codec won't make any difference, I'm afraid.

By: Elazar Broad (ebroad) 2009-10-14 16:54:06

Good point. Can your remote peer change their codec?

By: ilker Aktuna (mrmrmrmr) 2009-10-15 13:45:51

I made the test (both the echo test and the original call issue) with a softphone. (Softphone connected as the external CPE instead of the CPE which is making the call)

When I enable VAD on softphone the problems occur. If I disable VAD, then the problem is gone.

So, now we know that both problems (echo test and the original problem described) is related to VAD being enabled on the external CPE behind external SIP proxy.

How can we solve this on Asterisk ?
Why does Asterisk stop sending the received RTP to the inside client ?
Is there a configuration to disable this kind of behaviour ?

By: Elazar Broad (ebroad) 2009-10-15 15:16:50

Try enabling silence support on the SPA...

By: ilker Aktuna (mrmrmrmr) 2009-10-15 15:29:36

enabled silence support on SPA ; it does not change anything.
because Asterisk is cutting the RTP to SPA...

By: Elazar Broad (ebroad) 2009-10-15 16:07:34

A little research shows that Asterisk currently does not support VAD(see the related issues and http://www.asteriskguru.com/tutorials/comfort_noise_support_incomplete.html ), however, I will wait for an Asterisk developer to chime in before coming to a conclusion.

By: ilker Aktuna (mrmrmrmr) 2009-10-15 17:18:34

ok; I understand Asterisk does not support VAD, but it shouldn't cut the audio when the RTP frame is "null/empty audio"
This is something different than supporting or not supporting VAD.
Am I wrong ?

By: ilker Aktuna (mrmrmrmr) 2009-10-16 01:57:00

I found a workaround for the problem:
if I disable g729 on internal clients and use g711 inside, while using g729 on the external leg of the call, the VAD problem does not occur.
Of course to achieve this, I had to use the g729 codec.

But then I have another issue. Sometimes, the internal clients do not ring.
(not in every call; occurs randomly)

When I check the console logs I see the following line which I don't know the meaning of:
"<SIP/200004908502121277-b5705c18>AGI Script dialparties.agi completed, returning -1"

Why does it return "-1" ?

I am adding the complete console log with agi debug as attachment in case you want to have a look.

Btw, if it will solve my problem, I am willing to purchase a g729 license.
Is there an alternative to the Digium codec ?

By: ilker Aktuna (mrmrmrmr) 2009-10-19 12:14:02

The original problem is solved by using g711 on the internal clients but the new problem is even more disturbing. Some of the calls (not a low percentage) are not even being delivered to the internal client.
How can we troubleshoot this issue ?
Is there any clue in the console output that I've attached ?

As far as I see Asterisk doesn't even send an INVITE to the internal client. Sometimes I see an OPTIONS message but I guess that's not relevant.


By: Leif Madsen (lmadsen) 2009-10-20 09:26:45

You don't have any SIP helper modules loaded and running on the Shorewall do you? These "helper" apps almost always mangle the headers in such a way that issues appear where you would not expect them.

By: ilker Aktuna (mrmrmrmr) 2009-10-20 15:00:09

I have the following line in my shorewall config to disable sip modules:

Is there any other modules that I should disable ?

By: Leif Madsen (lmadsen) 2009-10-21 11:02:56

Not sure, I've never used a shorewall device. I just use iptables.

By: Elazar Broad (ebroad) 2009-10-21 11:48:15

I am a Cisco man myself, however, isn't there a conntrack kernel module for SIP, you might want to try disabling it...

Edit: I did find this: http://forum.soft32.com/linux2/Bug-415654-shorewall-linux-ip_nat_sip-module-breaks-SIP-ftopict77049.html

By: ilker Aktuna (mrmrmrmr) 2009-10-21 16:00:29


Thanks for pointing that out but I already have sip modules (nat and conntrack) disabled as I've written in my previous comment:

ip_nat_sip is the format used in kernel versions 2.6.20 or earlier. Higher kernel versions use nf_nat_sip

So it's all disabled together with conntrack_sip module:

# lsmod | grep sip

Btw, what makes you think it's a lost packet and/or nat issue ?
Do you see evidence for that in the logs I've attached ?


By: ilker Aktuna (mrmrmrmr) 2009-10-28 13:37:51

I'd appreciate any reply, comments etc.
why do you think it's a lost packet and/or nat issue ?

By: ilker Aktuna (mrmrmrmr) 2009-10-31 13:22:36


This is very important for me please help. Do you believe I have lost packets in my network ?

By: Leif Madsen (lmadsen) 2009-11-02 10:53:20.000-0600

If it is a network issue, there is very little to do here. I'd suggest you take this to the asterisk-users mailing list.

By: ilker Aktuna (mrmrmrmr) 2009-11-02 14:46:29.000-0600

But I don't think it's a network issue. How do you come to such result ?

By: Denes Dolhay (denke) 2009-11-02 15:17:06.000-0600

There is no way, that it is a network issue.
I Confirm the issue, an the issue has been confirmed by File as well.
He log no to my server while I was reproduced the bug.
Look at the related issues too!

But if it would be a network issue, hen ALL outgoing packets should be on the console debug trace which are supposed to go out, but they are not.
They was not there even if I used an original digium zaptel card as timing source.

So I recommand to drop the netwok from the list of suspected causes.

By: Leif Madsen (lmadsen) 2009-11-02 15:28:38.000-0600

The issue is still marked as Acknowledged and will be looked into by a developer when time permits.

By: ilker Aktuna (mrmrmrmr) 2009-11-03 16:17:40.000-0600

denke and lmadsen,

thanks for your answers. I understand that the issue will be checked by a developer when they have time. however, I am having problems because of the issue and now that I solved the VAD issue by using g711 on internal clients, the issue is totally different. (some calls are not reaching the internal clients)
So, should I open a new bug file or will this be enough to follow up ?

And, meanwhile what can I do to solve my problem ?
How can I not understand why it is occuring ? There must be a log to see why the call is not reaching the extensions. Am I wrong ?

By: Denes Dolhay (denke) 2009-11-08 09:28:39.000-0600

You should probably open another bug report, unless you suspect, that this problem is originated from the same bug.

You can find out what asterisk is doing by settig the information level on the console to debug (I think you can do this in asterisk.conf) and increasing the debug level (ex.: core set debug 100), and if you stil don't have what your searching for, then you should enable sip debug as well.

By: Leif Madsen (lmadsen) 2009-11-09 08:15:16.000-0600

I agree with denke, if the issue originally associated with this issue is resolved, then I'm going to close this issue, and any further issues should be followed up by another report.

The issue tracker is not a support system, and thus your questions are most appropriate for the asterisk-users list, or #asterisk-users IRC channel on irc.freenode.net.

By: ilker Aktuna (mrmrmrmr) 2009-11-10 13:45:46.000-0600

I didn't say that the original issue is solved.
Original issue is solved by selecting different codec in the internal clients.
But I prefer not using any transcoding (and common sense says so). That's why original issue remains.

By: Joshua C. Colp (jcolp) 2015-03-14 09:06:06.663-0500

Per the Asterisk versions page [1], the maintenance (bug fix) support for the Asterisk branch you are using has ended. For continued maintenance support please move to a supported branch of Asterisk. After testing with a supported branch, if you find this problem has not been resolved, please open a new issue against the latest version of that Asterisk branch.


[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions