Remote Extension outgoing voice not heard

Discussion in 'General' started by stuart, Feb 15, 2009.

  1. stuart

    Joined:
    Dec 28, 2007
    Messages:
    32
    Likes Received:
    0
    The asterisk server at the office works without fault for local incoming and outgoing calls. We have developed a fault with remote Gtandstream GXP2000 phones connecting back to the office PBX. Previously these extensions worked for about a year with no problems at all but this has now changed.

    Currently the remote phones register with the asterisk server. The Extensions can see the BLF lights changing with use at the office. The remote phones can ring anyone but when the called party answers we can hear them clearly but they cannot hear us.

    The office can dial this extension and I can hear them perfectly but they cannot hear me responding to them.

    Things that have changed since it worked
    Smoothwall has received upgrades over time.
    We have upgraded Grandstreams firmware.
    I have replaced the modem (was a D-Link DSL-504T) for the remote extension with a Linksys AG300.

    Any help would be appreciated as I am completely out of ideas. I have checked for port forward issues on the Smoothwall Firewall and I think that it is OK, but I am not 100% sure about the Linksys AG300.

    **************************************************************************

    Smoothwall Advanced Firewall
    All outgoing ports are allowed from local network
    Incoming 5060:5089 UDP forwarded to Asterisk server on local network
    Incoming 10000:20000 UDP forwarded to Asterisk server on local network
    Incoming 5004 UDP forwarded to Asterisk server on local network

    **************************************************************************

    Remote Extension Phone Details
    Grandstream GXP2000
    Firmware 1.1.6.44

    Remote Extension Modem
    Linksys AG300 modem router
    5060 set as SIP default in "applications and gaming" under ALG
    Other Ports Forwarded Inwards
    Incoming 10000:20000 UDP
    Incoming 5004 UDP

    PBX Extension 2005
    secret xxxx
    dtmfmode rfc2833
    canreinvite no
    context from-hp
    host dynamic
    type friend
    nat yes
    port 5060
    qualify yes
    callgroup
    pickupgroup
    disallow all
    allow alaw@ulaw@gsm
    dial SIP/2005
    accountcode 2005
    mailbox 2005@device

    **************************************************************************

    Sip_Nat.conf
    nat=yes
    externip=xxx.xxx.xxx.xx (external static ip at office)
    localnet=192.168.0.0/255.255.255.0 (local network at office)
    externrefresh=10

    **************************************************************************
     
  2. stuart

    Joined:
    Dec 28, 2007
    Messages:
    32
    Likes Received:
    0
    I have set up a direct connection to our VSP from Line 2 on the Grandstream remote handset and the voice works both ways, so it is unlikely to be a Firewall issue as Line 1 which is registered to the Office server still only has one way voice.

    The office server is able to make outgoing calls and receive incoming calls with voice both ways so it is unlikely to be a Firewall issue at that end either.

    Anyone have any clues that may fix the problem?
     
  3. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    Two points. You wrote:
    What are you forwarding those ports inward to? If there's no Asterisk server there, remove those entries (a VoIP adaper doesn't need them)! I'm not even sure the reference to 5060 would not cause problems (you would think it would not, but if the problem persists it's worth temporarily removing it).

    Also, this document may or may not help:
    HOWTO: Resolving Audio Problems
    (Note: You can ignore the part about Webmin and port 10000 if you don't have it installed, or if you have it set to use a port lower than 10000).
     
  4. stuart

    Joined:
    Dec 28, 2007
    Messages:
    32
    Likes Received:
    0
    Those ports were forwarded from the AG300 directly to the remote phones local static IP address. You are right they should not be necessary, but at that time I was suspecting that it was a Firewall issue and tried forwarding everything possible in case it made a difference.

    Remote extension and the office Asterisk box are both behind static IP addresses.

    I have already read the document referred to but it made no difference, I am now suspecting that it has nothing to do with NAT or firewalls but may be a configuration issue with Asterisk but I do not know where to go from here. As I said in a previous post this remote extension happily worked for about a year, then it was not used for some time and during this time it stopped working for some reason. I would have also upgraded Elastix from 1.2 to 1.3 during this time but can not be certain when the voice problem began.
     
  5. reynolwi

    Joined:
    May 5, 2008
    Messages:
    100
    Likes Received:
    0
    I also had this problem and fixed it. I had to do several things depending on my hardware and also some additional lines had to be added to sip_nat.conf if i remember right. I will pull out my files and post what i did to see if that helps you.
     
  6. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    What's so weird is that this is typically a symptom of a NAT firewall problem but in your case that does not appear to be the problem. I will mention that when we upgraded Asterisk and FreePBX we were pulling our hair out because none of our trunks would work, and the problem turned out to be that in the past you could put disallow and allow statements (for codecs) in any order, now you have to make sure that the disallow statements come first. A change as simple as that can really mess you up. So you may want to just gaze at your sip*.conf files (NOT the ones auto-generated by FreePBX - there will be a banner at the top of those warning you about them) and see if maybe anything looks a little funny, particularly with regard to codec settings. I'm shooting in the dark again here, but maybe it's worth a look.
     
  7. stuart

    Joined:
    Dec 28, 2007
    Messages:
    32
    Likes Received:
    0
    I ran sip set debug peer 2005 and got the following output. Does this give any clues to what is causing the one way voice.

    [Feb 20 19:34:22] VERBOSE[2887] logger.c: Reliably Transmitting (NAT) to XXX.XXX.XXX.XX:5060:
    OPTIONS sip:2005@XXX.XXX.XXX.XX:5060;transport=udp SIP/2.0
    Via: SIP/2.0/UDP 192.168.0.11:5060;branch=z9hG4bK30b2d569;rport
    From: "Unknown" <sip:Unknown@192.168.0.11>;tag=as4d9ea2c2
    To: <sip:2005@XXX.XXX.XXX.XX:5060;transport=udp>
    Contact: <sip:Unknown@192.168.0.11>
    Call-ID: 618b00c047ac5753722c0da674c34e39@192.168.0.11
    CSeq: 102 OPTIONS
    User-Agent: Asterisk PBX
    Max-Forwards: 70
    Date: Fri, 20 Feb 2009 09:34:22 GMT
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
    Supported: replaces
    Content-Length: 0


    ---
    [Feb 20 19:34:22] VERBOSE[2887] logger.c:
    <--- SIP read from XXX.XXX.XXX.XX:5060 --->
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 192.168.0.11:5060;branch=z9hG4bK30b2d569;rport
    From: "Unknown" <sip:Unknown@192.168.0.11>;tag=as4d9ea2c2
    To: <sip:2005@XXX.XXX.XXX.XX:5060;transport=udp>;tag=69af1c7e108ef047
    Call-ID: 618b00c047ac5753722c0da674c34e39@192.168.0.11
    CSeq: 102 OPTIONS
    User-Agent: Grandstream GXP2000 1.1.6.44
    Warning: 399 XXX.XXX.XXX.XX "detected NAT type is restricted cone"
    Contact: <sip:2005@XXX.XXX.XXX.XX:5060;transport=udp>
    Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
    Supported: replaces, timer
    Content-Length: 0


    <------------->
    [Feb 20 19:34:22] VERBOSE[2887] logger.c: --- (12 headers 0 lines) ---
    [Feb 20 19:34:22] VERBOSE[2887] logger.c: Really destroying SIP dialog '618b00c047ac5753722c0da674c34e39@192.168.0.11' Method: OPTIONS
    [Feb 20 19:34:22] DEBUG[2887] chan_sip.c: Adding subscription for extension 2030 context from-hp for peer 2070
    [Feb 20 19:34:23] DEBUG[2887] chan_sip.c: Adding subscription for extension 2040 context from-hp for peer 2070
    [Feb 20 19:34:23] VERBOSE[2887] logger.c:
    <--- SIP read from XXX.XXX.XXX.XX:5060 --->
     
  8. stuart

    Joined:
    Dec 28, 2007
    Messages:
    32
    Likes Received:
    0
    Could this be my problem too?

    Important thing to look at if you get one way audio problem with Asterisk 1.4.10 and FreePBX 2.3.0
    We've had a weird problem where we though that there must be gremlins in the network or providers playing tricks on us. We've tried everything, reviewing our firewall rules, inserting log statements in our firewall rules, running tcpdump, analyzing STUN server traffic, everything !!

    We have lost quite a bit of time looking in the wrong place (e.g. the network). We found out that Asterisk (version 1.4.10 and below) has some problems in filtering invalid characters in CIDNAME (CallerID Name). The problem could have been caused exclusively by our custom CIDNAME lookup application but it could affect other users, we did not take the time to look into it further.

    Scenario :

    Asterisk send the CIDNUMBER and the CIDNAME to our custom CIDNAME lookup application. If our application doesn't find detailed info related to the CIDNUMBER , it just sends back the CIDNAME name that Asterisk sent to us in the first place. We had to patch our application so it trims invalid chars from the CIDNAME that Asterisk sent us in the first place before returning it to Asterisk to solve our one way audio problem.

    The one way audio problem was caused by Asterisk and/or devices sending invalid SIP packets.

    Symptom :

    Look for open double quotes without a closing one in your SIP packets by running asterisk -r and then sip debug.

    Example:

    SIP/2.0 200 OK
    Via: SIP/2.0/UDP xxx.xxx.xxx.xxx:5060;branch=z9hG4bK4a2fdbb1;rport
    From:

    "

    To: <sip: 111@xxx.xxx.xxx.xxxCette adresse email est protégée contre les robots des spammeurs, vous devez activer Javascript pour la voir. :61315>;tag=2a078efd6230ec21
    Call-ID: 6504b64851244b80647e54135c370817@xxx.xxx.xxx.xxxCette adresse email est protégée contre les robots des spammeurs, vous devez activer Javascript pour la voir.

    CSeq: 102 OPTIONS
    User-Agent: Grandstream GXP2000 1.1.1.14
    Warning: 399 xxx.xxx.xxx.xxx "detected NAT type is symmetric NAT"
    Contact: <sip: 111@xxx.xxx.xxx.xxxCette adresse email est protégée contre les robots des spammeurs, vous devez activer Javascript pour la voir. :60429>
    Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
    Supported: replaces, timer
    Content-Length: 0

    That One-Way audio problem with Asterisk 1.4.10 and FreePBX 2.3.0 that we spent so much time on had nothing to do with the network ! Just with stupid malformed headers ;-(

    **********************************************************************

    Re: where can I get the patch 2 lundi, 04 août 2008 21:53 oc9

    There is no patch available from us. This article was merely a pointer to where to look at for the source of problems.

    As stated in the article, we simply fixed our Caller ID lookup script to eliminate invalid characters. (We simply piped all called program output to the "strings" (program /usr/bin/strings).

    As mentioned in the article, we could have introduced the problem ourselves but we wanted to point out the fact that asterisk should filter out invalid characters for any fields it sends out in SIP packets. So in the best world, our problem would never have occured.

    This is a basic priciple that is applied in every robust piece of software. If a real life use case is needed as example, look at how hibernate filters out/escape invalid characters to avoid SQL injections.

    So, the point of the article was to highlight that asterisk would need more robustness at handling CALLER_ID or any other fields provided by custom programs. Asterisk should not blindly forward those fields in the SIP packets it is sending out.

    We haven't put any efforts into locating the spot in asterisk source in order to accomplished that, we apologize for that. ;-(
     
  9. wiseoldowl

    Joined:
    Aug 19, 2008
    Messages:
    251
    Likes Received:
    0
    They STILL haven't fixed that? That bug has been around practically forever!

    We first ran across it when we had a Cisco ATA-186 connected back-to-back to a Sipura SPA-3000 (so we could get calls from a provider that forces you to use their device). It worked fine most of the time but every so often Asterisk would simply ignore an incoming call. We finally figured out that the ATA-186 always sent the Caller ID name enclosed in quotes BUT if the string was over 15 characters it would simply drop the excess characters - which of course included the closing quotation mark! If a call came in from someone with a name 13 characters or shorter, it would go through just fine. 14 or more characters would, after the addition of the open and close quotes, push the total over 15 and cause the end quote to get lost, and Asterisk would simply turn up its nose at the call and refuse to acknowledge it existed!

    I really think that Asterisk is going to go the way of the Dodo bird in a few years, especially if and when FreePBX is able to work with FreeSWITCH in addition to Asterisk (of course that also assumes that the Asterisk folks don't get their act together, which I hope is not the case, but when you see a bug that's been around this long and has never been fixed, it really makes you wonder).
     

Share This Page