cannot hear the other party

Discussion in 'General' started by addame, Sep 17, 2009.

  1. addame

    Joined:
    Aug 23, 2009
    Messages:
    8
    Likes Received:
    0
    hi everyone,

    In my new installed elastix I cannot hear when someone call me.
    At first I though it's a nat/firewall problem ...
    I checked my ports and they seem to be open ... also I configured my router to allow traffic on some ports such as :
    5060, 5061, 4520, 2727, 5038.

    To be 100% sure it's not the rooter : I put my server as DMZ... but even so the problem persists : I cannot hear the other party.

    Any idea where it can come from ?

    thanks in advance
     
  2. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    Welcome to Elastix addame:

    The audio path in a sip connection rides on ports 10000-20000 UDP by default in Asterisk, these ports need to be opened on your firewall.

    "Elastix Without Tears" (IMHO an essential read, without it you are flying blind) will explain how to setup your SIP NAT traversal settings to allow bidirectional audio.
     
  3. addame

    Joined:
    Aug 23, 2009
    Messages:
    8
    Likes Received:
    0
    Thanks dicko !

    To get ride of port forwarding I put my asterisk server in DMZ ... so all incoming net traffic is going directly to the asterisk server.

    when runing : asterisk -vvvvvr and try to use one of my sip phones to call another one ... using an outoging trunk I got this :
    -- Executing [s@macro-record-enable:1] GotoIf("SIP/81.85.224.41-b6c07618", "1?check") in new stack
    -- Goto (macro-record-enable,s,4)
    -- Executing [s@macro-record-enable:4] AGI("SIP/81.85.224.41-b6c07618", "recordingcheck|20090916-183447|1253151287.28") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/recordingcheck
    recordingcheck|20090916-183447|1253151287.28: Inbound recording enabled.
    recordingcheck|20090916-183447|1253151287.28: CALLFILENAME=20090916-183447-1253151287.28
    -- AGI Script recordingcheck completed, returning 0
    -- Executing [s@macro-record-enable:999] MixMonitor("SIP/81.85.224.41-b6c07618", "20090916-183447-1253151287.28.wav||") in new stack
    -- Executing [s@macro-exten-vm:9] Macro("SIP/81.85.224.41-b6c07618", "dial|15|tr|3000") in new stack
    -- Executing [s@macro-dial:1] GotoIf("SIP/81.85.224.41-b6c07618", "1?dial") in new stack
    -- Goto (macro-dial,s,3)
    -- Executing [s@macro-dial:3] AGI("SIP/81.85.224.41-b6c07618", "dialparties.agi") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/dialparties.agi
    == Begin MixMonitor Recording SIP/81.85.224.41-b6c07618
    dialparties.agi: Starting New Dialparties.agi
    == Parsing '/etc/asterisk/manager.conf': Found
    == Parsing '/etc/asterisk/manager_additional.conf': Found
    == Parsing '/etc/asterisk/manager_custom.conf': Found
    == Manager 'admin' logged on from 127.0.0.1
    dialparties.agi: Caller ID name is '418' number is '418'
    dialparties.agi: USE_CONFIRMATION: 'FALSE'
    dialparties.agi: RINGGROUP_INDEX: ''
    dialparties.agi: Methodology of ring is 'none'
    -- dialparties.agi: Added extension 3000 to extension map
    > dialparties.agi: Extension 3000 has call screening off
    -- dialparties.agi: Extension 3000 cf is disabled
    -- dialparties.agi: Extension 3000 do not disturb is disabled
    > dialparties.agi: extnum 3000 has: cw: 0; hascfb: 0 [] hascfu: 0 []
    > dialparties.agi: ExtensionState: 0
    dialparties.agi: Extension 3000 has ExtensionState: 0
    -- dialparties.agi: Checking CW and CFB status for extension 3000
    -- dialparties.agi: dbset CALLTRACE/3000 to 418
    -- dialparties.agi: Filtered ARG3: 3000
    == Manager 'admin' logged off from 127.0.0.1
    -- AGI Script dialparties.agi completed, returning 0
    -- Executing [s@macro-dial:7] Dial("SIP/81.85.224.41-b6c07618", "SIP/3000|15|tr") in new stack
    -- Called 3000CLI>
    -- SIP/3000-085068f0 is ringing
    -- SIP/3000-085068f0 answered SIP/81.85.224.41-b6c07618
    -- SIP/SmartVoip-08539880 answered SIP/3002-b6c035f8
    -- Remote UNIX connection
    -- Remote UNIX connection disconnected

    But when I call a sip phone internally it's working fine.

    Any help ? :)
     
  4. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    So I guess you decided to pass on the "Elastix Without Tears" thing then ? :) (I find Dutch people do that a lot, are you Dutch by any chance ?)

    Unless you have the right VIA's in your SIP headers the far end will try and send the audio to your local address (LAN),if your box has a "real" network address, then that's fine if your LAN is not "public" (192. blah blah) then that won't work, you might well get "one way" or "no way" audio. It's very easy to arrange for that to not happen, just read the FM :) You need to very explicitly define what your external IP or name is , and what your LAN network looks like, this is conventionally defined in sip_nat.conf, you need to define those parameters to get the RTP traffic through to the right place.

    I will also add that the DMZ is a VERY bad place for an Elastix box, my guess is you will be compromised within a week, just use (P)NAT rules appropriately and it works.
     
  5. addame

    Joined:
    Aug 23, 2009
    Messages:
    8
    Likes Received:
    0
    Thanks for the advice !!
    I went through "elastix without tears" an added the following lines to my sip_general_custom.conf

    bindport=5060
    bindaddr=0.0.0.0
    nat=yes
    externhost=<here I put my server domain name>
    localnet=192.168.0.0/255.255.255.0
    externrefresh=10
    allowguest=yes
    context=from-trunk
    rtptimeout=60
    rtpholdtimeout=120
    useragent=Elastix


    And then restarted elastix :
    asterisk -r
    reload

    Now ingoing calls work as well as outgoing calls ... great !!


    By the way, I'm from Canada :)
     
  6. dicko

    Joined:
    Oct 24, 2008
    Messages:
    4,099
    Likes Received:
    0
    My apologies, (I noticed your SIP proxy has an address in Holland).

    from Asterisk CLI:

    sip debug ip <IP of service provider>

    will reveal the SIP headers, (anything noticeably wrong with the via's or ip addresses in these traces needs to be fixed)

    further. . .

    rtp debug

    will show the packets (in and out) of the media payload, when a SIP session is connected, (as your previous post shows it successfully is), if you see the outbound traffic, but not the inbound, then your firewall/router/NAT setup is at fault. (you can check the expected behavior with a local call, just use the appropriate IP in the debug session)
     

Share This Page