Details

    • Type: Bug Bug
    • Status: Open
    • Severity: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Target Release Version/s: None
    • Labels:
      None
    • Mantis ID:
      16014
    • Regression:
      No

      Description

      Hi,

      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.

                • ADDITIONAL INFORMATION ******

      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:

      192.168.254.254 : Asterisk server LAN address
      192.168.254.5 : Extension 995 in LAN , Linksys SPA 3000
      95.65.180.146 : Asterisk server WAN address
      193.243.202.97 : External SIP Proxy
      193.243.202.124 : SIP Proxy RTP address

      1. agi_fail.txt
        19 kB
      2. all_sip_conf.txt
        5 kB
      3. audio-problem.cap
        137 kB
      4. rtp_debug.txt
        13 kB
      5. trace.txt
        154 kB

        Activity

        Hide
        Leif Madsen added a comment -

        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!

        Show
        Leif Madsen added a comment - 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!
        Hide
        ilker Aktuna added a comment -

        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.

        Show
        ilker Aktuna added a comment - 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.
        Hide
        Elazar Broad added a comment -

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

        Show
        Elazar Broad added a comment - In the additional information you have your server at 95.65.180.146, I don't see this anywhere in the sip trace. I do see your server using 213.248.146.120 as its public address, is that correct?
        Hide
        ilker Aktuna added a comment -

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

        Show
        ilker Aktuna added a comment - The ppp0 interface has a dynamically changing IP address. Each time the ADSL connection is established it receives a new IP. You are correct; 213.248.146.120 is the IP address of ppp0 interface at the time of that trace.
        Hide
        Elazar Broad added a comment -

        Are you running this through a NAT firewall?

        Show
        Elazar Broad added a comment - Are you running this through a NAT firewall?
        Hide
        ilker Aktuna added a comment -

        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)

        Show
        ilker Aktuna added a comment - 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)
        Hide
        ilker Aktuna added a comment -

        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 ?

        Show
        ilker Aktuna added a comment - 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 ?
        Hide
        Elazar Broad added a comment -

        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.

        Show
        Elazar Broad added a comment - 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.
        Hide
        ilker Aktuna added a comment -

        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 ?

        Show
        ilker Aktuna added a comment - 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 ?
        Hide
        Elazar Broad added a comment -

        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?

        Show
        Elazar Broad added a comment - 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?
        Hide
        ilker Aktuna added a comment -

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

        Show
        ilker Aktuna added a comment - no; when I make the call from internal client the audio is fine. both with echo test and the external client.
        Hide
        Elazar Broad added a comment -

        Does your local extension support G729(not G729a)?

        Show
        Elazar Broad added a comment - Does your local extension support G729(not G729a)?
        Hide
        ilker Aktuna added a comment -

        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.

        Show
        ilker Aktuna added a comment - 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.
        Hide
        Elazar Broad added a comment -

        Can you disable G729a on the SPA3000?

        Show
        Elazar Broad added a comment - Can you disable G729a on the SPA3000?
        Hide
        ilker Aktuna added a comment -

        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.

        Show
        ilker Aktuna added a comment - 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.
        Hide
        Elazar Broad added a comment -

        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?

        Show
        Elazar Broad added a comment - 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?
        Hide
        ilker Aktuna added a comment -

        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 ?

        Show
        ilker Aktuna added a comment - 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 ?
        Hide
        Elazar Broad added a comment -

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

        Show
        Elazar Broad added a comment - I believe that is correct. What happens when you disable G729 on the SPA?
        Hide
        ilker Aktuna added a comment -

        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.

        Show
        ilker Aktuna added a comment - 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.
        Hide
        Elazar Broad added a comment -

        Good point. Can your remote peer change their codec?

        Show
        Elazar Broad added a comment - Good point. Can your remote peer change their codec?
        Hide
        ilker Aktuna added a comment -

        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 ?

        Show
        ilker Aktuna added a comment - 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 ?
        Hide
        Elazar Broad added a comment -

        Try enabling silence support on the SPA...

        Show
        Elazar Broad added a comment - Try enabling silence support on the SPA...
        Hide
        ilker Aktuna added a comment -

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

        Show
        ilker Aktuna added a comment - enabled silence support on SPA ; it does not change anything. because Asterisk is cutting the RTP to SPA...
        Hide
        Elazar Broad added a comment -

        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.

        Show
        Elazar Broad added a comment - 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.
        Hide
        ilker Aktuna added a comment -

        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 ?

        Show
        ilker Aktuna added a comment - 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 ?
        Hide
        ilker Aktuna added a comment -

        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 ?

        Show
        ilker Aktuna added a comment - 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 ?
        Hide
        ilker Aktuna added a comment -

        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.

        Thanks.

        Show
        ilker Aktuna added a comment - 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. Thanks.
        Hide
        Leif Madsen added a comment -

        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.

        Show
        Leif Madsen added a comment - 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.
        Hide
        ilker Aktuna added a comment -

        I have the following line in my shorewall config to disable sip modules:
        DONT_LOAD=nf_nat_sip,nf_conntrack_sip

        Is there any other modules that I should disable ?

        Show
        ilker Aktuna added a comment - I have the following line in my shorewall config to disable sip modules: DONT_LOAD=nf_nat_sip,nf_conntrack_sip Is there any other modules that I should disable ?
        Hide
        Leif Madsen added a comment -

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

        Show
        Leif Madsen added a comment - Not sure, I've never used a shorewall device. I just use iptables.
        Hide
        Elazar Broad added a comment -

        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

        Show
        Elazar Broad added a comment - 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
        Hide
        ilker Aktuna added a comment -

        Hi,

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

        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:

        1. 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 ?

        Thanks.

        Show
        ilker Aktuna added a comment - Hi, Thanks for pointing that out but I already have sip modules (nat and conntrack) disabled as I've written in my previous comment: DONT_LOAD=nf_nat_sip,nf_conntrack_sip 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 ? Thanks.
        Hide
        ilker Aktuna added a comment -

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

        Show
        ilker Aktuna added a comment - I'd appreciate any reply, comments etc. why do you think it's a lost packet and/or nat issue ?
        Hide
        ilker Aktuna added a comment -

        Hi,

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

        Show
        ilker Aktuna added a comment - Hi, This is very important for me please help. Do you believe I have lost packets in my network ?
        Hide
        Leif Madsen added a comment -

        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.

        Show
        Leif Madsen added a comment - 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.
        Hide
        ilker Aktuna added a comment -

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

        Show
        ilker Aktuna added a comment - But I don't think it's a network issue. How do you come to such result ?
        Hide
        Denes Dolhay added a comment -

        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.

        Show
        Denes Dolhay added a comment - 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.
        Hide
        Leif Madsen added a comment -

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

        Show
        Leif Madsen added a comment - The issue is still marked as Acknowledged and will be looked into by a developer when time permits.
        Hide
        ilker Aktuna added a comment -

        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 ?

        Show
        ilker Aktuna added a comment - 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 ?
        Hide
        Denes Dolhay added a comment -

        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.

        Show
        Denes Dolhay added a comment - 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.
        Hide
        Leif Madsen added a comment -

        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.

        Show
        Leif Madsen added a comment - 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.
        Hide
        ilker Aktuna added a comment -

        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.

        Show
        ilker Aktuna added a comment - 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.

          People

          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development