Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

Classic one-way audio issue

Discussion in '3CX Phone System - General' started by Vic D'Elfant, Nov 3, 2010.

Thread Status:
Not open for further replies.
  1. Vic D'Elfant

    Joined:
    Oct 11, 2009
    Messages:
    24
    Likes Received:
    0
    After two full days of fiddling with the settings I figured it was time to post my problem here... hopefully someone can shed some light on this.

    The situation is as follows: we've always had 3CX version 8 running happily at the office, but for several reasons we decided to move it out of the office and install version 9 on a remote server in a data center. So far, so good... but the two Aastra 6731i devices we have are now "external" extensions because of this change, which - as I found out the hard way - makes life a whole lot more difficult in VoIP-land.

    I found out that registering wasn't working as expected (that, and phones weren't ringing for some reason) so enabled STUN along with Rport. The STUN server is stun.3cx.com:3478, for the record. Registering and ringing in both ways is working just fine, but we're still having one-way audio. The calling party hears us, but we do not hear the calling party... so the upload RTP stream isn't getting to the phone. Thinking it was a firewall issue I took one of the phones to my home, plugged it in and voila, it registered just fine with our old, version 8 install, and it had two-way audio out of the box. Perfectly, but very unexpected. Switch the server details to our new version 9 install... one-way audio. [ edit: this no longer applies ]

    The remote server is on a static IP (obviously), and routers at both the office and home location are completely locked-down devices... quite common here in the Netherlands, sadly enough. It wouldn't mind giving up if I could say it was just another unsolvable firewall issue, but it strikes me that audio worked both ways when going remotely to the version 8 install. There seems to be a difference between the two installs, somehow.

    I've taken a few random entries from the log (called from Aastra to mobile device, 0-ed in the logs); please let me know if you need specific entries and I'd be happy to share them.

    Code:
    INVITE sip:0000000000@[server-public]:5060 SIP/2.0
    Via: SIP/2.0/UDP [home-public]:49514;branch=z9hG4bK69c814492f5e655d1;rport=49514
    Max-Forwards: 70
    Contact: <sip:101@[home-public]:49514;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-1000-8000-00085D1364DE>";isfocus
    To: "0000000000"<sip:0000000000@[server-public]:5060>
    From: <sip:101@[server-public]:5060>;tag=27cae1a3a3
    Call-ID: dc55d861953fbf7f
    CSeq: 25754 INVITE
    Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
    Proxy-Authorization: Digest username="101",realm="3CXPhoneSystem",nonce="414d535c02e23e9734:f3b70a2ffcc566d1df4da854afe58958",uri="sip:0000000000@[server-public]:5060",response="551a731d7a44ffa7983dad38086195a8",algorithm=MD5
    Supported: gruu, path, timer, 100rel, replaces
    User-Agent: Aastra 6731i/2.6.0.1008
    Allow-Events: talk, hold, conference, LocalModeStatus
    Content-Length: 0
    
    SIP/2.0 183 Session Progress
    Via: SIP/2.0/UDP [home-public]:49514;branch=z9hG4bK69c814492f5e655d1;rport=49514
    Contact: <sip:0000000000@[server-public]:5060>
    To: "0000000000"<sip:0000000000@[server-public]:5060>;tag=f90a3a2d
    From: <sip:101@[server-public]:5060>;tag=27cae1a3a3
    Call-ID: dc55d861953fbf7f
    CSeq: 25754 INVITE
    Content-Type: application/sdp
    User-Agent: 3CXPhoneSystem 9.0.14474.0
    Content-Length: 272
    
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP [home-public]:49514;branch=z9hG4bK69c814492f5e655d1;rport=49514
    Contact: <sip:0000000000@95.211.12.97:5060>
    To: "0000000000"<sip:0000000000@[server-public]:5060>;tag=f90a3a2d
    From: <sip:101@[server-public]:5060>;tag=27cae1a3a3
    Call-ID: dc55d861953fbf7f
    CSeq: 25754 INVITE
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
    Content-Type: application/sdp
    Supported: replaces
    User-Agent: 3CXPhoneSystem 9.0.14474.0
    Content-Length: 272
     
  2. KerryG

    KerryG Active Member

    Joined:
    Jun 19, 2009
    Messages:
    960
    Likes Received:
    0
    My question would be what is different between the two systems? Different firewalls? Different firewall settings?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. Vic D'Elfant

    Joined:
    Oct 11, 2009
    Messages:
    24
    Likes Received:
    0
    Thanks for the quick reply. There are no real differences... same ports are opened on both ends (I temporarily disabled the firewalls for testing, actually) and both systems have a fixed external IP.

    I have a feeling this is some sort of routing issue since traffic from the v9 system isn't getting to the phone, whilst the phone configuration is exactly the same for both systems (apart from the actual SIP server hostname, of course). I'd love to see what STUN is actually doing and whether traffic is getting at its destination.
     
  4. RichardCrabb1

    RichardCrabb1 New Member

    Joined:
    Mar 7, 2009
    Messages:
    196
    Likes Received:
    0
    I would like to ask whether the hosted 3CX is behind a NAT router with static public IP address. If it is, does the firewall test complete correctly on the 3CX? In other words if it is a NAT router, and are the ports properly forwarded?

    If it is purely on a public IP address and therefore is using a firewall, are the ports open that need to be used?

    It sounds to me that the RTP is not reaching 3CX.

    Richard Crabb
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. Vic D'Elfant

    Joined:
    Oct 11, 2009
    Messages:
    24
    Likes Received:
    0
    Right - after two more test runs I found out that there's no difference between the systems when it comes to audio... both of them have one-way audio. I have no idea how it's even possible that it was working both ways on the first try. I'm starting to doubt myself, heh.

    Firewall check from the v9 system:

    Code:
    3CX Firewall Checker, v1.0. Copyright (C) 3CX Ltd. All rights reserved.
    
    <19:14:52>: Phase 1, checking servers connection, please wait...
    <19:14:52>: Stun Checker service is reachable. Phase 1 check passed.
    <19:14:52>: Phase 2a,  Check Port Forwarding to UDP SIP port, please wait...
    <19:14:53>: UDP SIP Port is set to 5060. Response received correctly with no translation. Phase 2a check passed.
    
    <19:14:53>: Phase 2b. Check Port Forwarding to TCP SIP port, please wait...
    <19:14:53>: TCP SIP Port is set to 5060. Response received correctly with no translation. Phase 2b check passed.
    
    <19:14:53>: Phase 3. Check Port Forwarding to TCP Tunnel port, please wait...
    <19:14:53>: TCP TUNNEL Port is set to 5090. Response received correctly with no translation. Phase 3 check passed.
    
    <19:14:53>: Phase 4. Check Port Forwarding to RTP external port range, please wait...
    
    Application exit code is 0
     
  6. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    Could you please make a wireshark capture of the problematic call?
    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. Vic D'Elfant

    Joined:
    Oct 11, 2009
    Messages:
    24
    Likes Received:
    0
    Stepan, would you mind if I'd PM you the wireshark capture? We'd rather not have sensitive data such as private telephone numbers popping up at fora :)
     
  8. RichardCrabb1

    RichardCrabb1 New Member

    Joined:
    Mar 7, 2009
    Messages:
    196
    Likes Received:
    0
    Just one point. I noticed that the firewall check did not appear to complete the RTP ports, and exited with exit code 0. Is this true, or was the data just "snipped" to save space?

    Richard
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. Vic D'Elfant

    Joined:
    Oct 11, 2009
    Messages:
    24
    Likes Received:
    0
    I noticed that too, it just seemed to "die" halfway apart from the "exit 0" on the end. So no, there are no listings of RTP ports.
     
  10. yozh

    Joined:
    Dec 12, 2010
    Messages:
    8
    Likes Received:
    0
    Having exactly same issue. My Server is on a public IP no NAT, there is windows firewall but its disabled when testing. One way audio, always I cant hear. Any suggestions would be appreciated. Thanks
     
  11. Vic D'Elfant

    Joined:
    Oct 11, 2009
    Messages:
    24
    Likes Received:
    0
    My problem was fixed by applying a custom setting, which was suggested by Stepan from 3CX. I can't remember the setting off the top of my hat, but it had something to do with using the source RTP port for incoming traffic as well. The problem was the NAT on the client's end (that was confirmed with Wireshark), but since this is controlled by some locked down, VoIP-unfriendly piece of firmware as provided by the ISP, I couldn't do much about this.

    This custom setting worked for a while, but after a few days we decided to revert things back and place the 3CX server within our office network. We had issues with phones not ringing from time to time, phones losing registration, etc. We couldn't rely on this setup so we went for the usual setup after all.
     
  12. yozh

    Joined:
    Dec 12, 2010
    Messages:
    8
    Likes Received:
    0
    Yeah I`m assuming my issue is NAT on the client side., but not sure what to change to make it work atleast to test. I changed all the settings multiple times and still cant find what works. IF you have few minutes can you look thru your msg and see what I have to modify ?

    Thanks
     
  13. yozh

    Joined:
    Dec 12, 2010
    Messages:
    8
    Likes Received:
    0
    So no luck ? I cant get it working. Guess I`ll post a new topic to see what I can get help with,
     
  14. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    There is a "luck".
    It is http://www.3cx.com/forums/forum-rules-read-to-get-answers-93.html

    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  15. yozh

    Joined:
    Dec 12, 2010
    Messages:
    8
    Likes Received:
    0
    OK I`ll make a new thread with the info, I was referring to "luck" finding the info that the other user indicated.
     
  16. Vic D'Elfant

    Joined:
    Oct 11, 2009
    Messages:
    24
    Likes Received:
    0
    I honestly had no idea whether you were talking about the experimental setting for the PBX or the NAT... for the PBX, I can imagine that Stepan provided this setting for testing purposes only, I'm sure they wouldn't want a setting that basically breaks SIP protocol to be listed as a solution in this topic, and have dozens of users use it... and have to handle support for this.

    If it's about the NAT: I can't recall the exact setting plus we're using a SpeedTouch router as provided by our ISP. Configuration is different for all those things plus it came down to simply testing the few types of NAT there are. It also depends on which NAT type you are comfortable with in your company network.

    Testing itself can be done very easily with Wireshark in the server side.
     
Thread Status:
Not open for further replies.