SPA942 And Not Using 5060

Discussion in '3CX Phone System - General' started by STRB, Dec 23, 2014.

Thread Status:
Not open for further replies.
  1. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    Hi,

    I've been searching the boards here for 2 days now without success so I am going to ask for help! We've just received TalkTalks new "super" router, the HG635, which does not allow port forwarding on port 5060. So I've attempted to set up 3CX using port 5082. This has been set in the Management Console under Settings and Network, and also under the incoming and outgoing VOIP Providers. Port forwarding for 5082 has been set up to the machine running 3CX (on 192.168.0.200). The SPA942 phones have been set to register against the proxy 192.168.0.200:5082 and registers successfully.

    I can receive incoming calls successfully!

    When attempting to make outgoing calls, or internal calls, the 3CX server rejects them with "Incoming call rejected, caller is unknown". It appears to check the IP of the source of the call with the IP and Port of the registered extension and fails to match it? Here is a verbose log of an internal call, from "Phone1" on 192.168.0.100, registered as Extension 10 to "Phone2" on 192.168.0.101 registered as extension 11, please help! Many thanks.

    23-Dec-2014 12:41:58.752 Terminated from "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0 to <sip:11@192.168.0.200>;tag=a67ff26b; reason: Rejected
    23-Dec-2014 12:41:58.752 L:7.1[Unknown:] Sending: OnSendResp Send 403/INVITE from 0.0.0.0:0 tid=-fc915a49 Call-ID=f1610bc4-98818935@192.168.0.100:
    SIP/2.0 403 Forbidden
    Via: SIP/2.0/UDP 192.168.0.100:5062;branch=z9hG4bK-fc915a49
    To: <sip:11@192.168.0.200>;tag=a67ff26b
    From: "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0
    Call-ID: f1610bc4-98818935@192.168.0.100
    CSeq: 102 INVITE
    Warning: 499 3CXServe "Caller is forbidden"
    Content-Length: 0
    23-Dec-2014 12:41:58.752 SendMsg from <sip:11@192.168.0.200>;tag=a67ff26b to "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0
    23-Dec-2014 12:41:58.704 OnOffer from "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0
    23-Dec-2014 12:41:58.704 [CM502001]: Source info: From: "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0; To: <sip:11@192.168.0.200>
    23-Dec-2014 12:41:58.703 [CM503013]: Call(C:7): Incoming call rejected, caller is unknown; msg=Ivite-IN Recv Req INVITE from 192.168.0.100:5062 tid=-fc915a49 Call-ID=f1610bc4-98818935@192.168.0.100:
    INVITE sip:11@192.168.0.200:5082 SIP/2.0
    Via: SIP/2.0/UDP 192.168.0.100:5062;branch=z9hG4bK-fc915a49
    Max-Forwards: 70
    Contact: "Phone1"<sip:10@192.168.0.100:5062>
    To: <sip:11@192.168.0.200>
    From: "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0
    Call-ID: f1610bc4-98818935@192.168.0.100
    CSeq: 102 INVITE
    Expires: 240
    Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
    Content-Type: application/sdp
    Proxy-Authorization: Digest username="10",realm="3CXPhoneSystem",nonce="414d535c0aa9f41695:3d193ef4c634fbb6427e7430cf9eeb3f",uri="sip:11@192.168.0.200:5082",algorithm=MD5,response="56f8925ceb382ead1474eada1a9d424a"
    Supported: replaces
    User-Agent: Linksys/SPA942-6.1.5(a)
    Content-Length: 397

    v=0
    o=- 102314 102314 IN IP4 192.168.0.100
    s=-
    c=IN IP4 192.168.0.100
    t=0 0
    m=audio 16470 RTP/AVP 0 2 4 8 18 96 97 98 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:2 G726-32/8000
    a=rtpmap:4 G723/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:18 G729a/8000
    a=rtpmap:96 G726-40/8000
    a=rtpmap:97 G726-24/8000
    a=rtpmap:98 G726-16/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=ptime:20
    a=sendrecv
    23-Dec-2014 12:41:58.701 Call(C:7) is terminated
    23-Dec-2014 12:41:58.701 IPs do not match!
    23-Dec-2014 12:41:58.701 Compare IPs: incoming=192.168.0.200; external=92.27.112.xx
    23-Dec-2014 12:41:58.701 IPs do not match!
    23-Dec-2014 12:41:58.701 Compare IPs: incoming=192.168.0.200; external=92.27.112.xx
    23-Dec-2014 12:41:58.701 IncomingCall: C:7 from <sip:10@192.168.0.200:5060> to <sip:11@192.168.0.200:5082>
    23-Dec-2014 12:41:58.701 Added leg L:C:7.1[No endpoint yet]
    23-Dec-2014 12:41:58.700 UasSession 560 started
    23-Dec-2014 12:41:58.700 Call from "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0 to <sip:11@192.168.0.200>;tag=a67ff26b
    23-Dec-2014 12:41:58.578 [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:
    Invite-UNK Recv Req INVITE from 192.168.0.100:5062 tid=-a49ac3e9 Call-ID=f1610bc4-98818935@192.168.0.100:
    INVITE sip:11@192.168.0.200:5082 SIP/2.0
    Via: SIP/2.0/UDP 192.168.0.100:5062;branch=z9hG4bK-a49ac3e9
    Max-Forwards: 70
    Contact: "Phone1"<sip:10@192.168.0.100:5062>
    To: <sip:11@192.168.0.200>
    From: "Phone1"<sip:10@192.168.0.200>;tag=3d14278ef85a211o0
    Call-ID: f1610bc4-98818935@192.168.0.100
    CSeq: 101 INVITE
    Expires: 240
    Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
    Content-Type: application/sdp
    Supported: replaces
    User-Agent: Linksys/SPA942-6.1.5(a)
    Content-Length: 397

    v=0
    o=- 102314 102314 IN IP4 192.168.0.100
    s=-
    c=IN IP4 192.168.0.100
    t=0 0
    m=audio 16470 RTP/AVP 0 2 4 8 18 96 97 98 101
    a=rtpmap:0 PCMU/8000
    a=rtpmap:2 G726-32/8000
    a=rtpmap:4 G723/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:18 G729a/8000
    a=rtpmap:96 G726-40/8000
    a=rtpmap:97 G726-24/8000
    a=rtpmap:98 G726-16/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15
    a=ptime:20
    a=sendrecv
    23-Dec-2014 12:41:58.578 IPs do not match!
    23-Dec-2014 12:41:58.578 Compare IPs: incoming=192.168.0.200; external=92.27.112.xx
    23-Dec-2014 12:41:54.980 Currently active calls [none]
    23-Dec-2014 12:41:22.976 Currently active calls [none]
    23-Dec-2014 12:40:50.972 Currently active calls [none]
    23-Dec-2014 12:40:18.971 Currently active calls [none]
     
  2. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    First, have you performed the firewall checker?

    You should do a search for "Review INVITE and adjust source identification" as this will give you a number of solutions.

    Here is one link to one possible cause/solution:

    http://www.3cx.com/blog/docs/source-identification-issues/

    You didn't really indicate where the 92.21.112.XX is coming from. Should we assume that this is an external extension? What type of phones and if remote, did you follow the 3CX guides for its installation?

    If remote, do you have a fixed IP and is STUN being used?

    Changing the router would normally have no impact on devices on the local LAN, but you have me a little confused as you referenced not being able to make internal calls as well; hence the question of the 92.21.112.XX and what is considered as internal, external or remote.
     
  3. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    Thanks for the assistance. The firewall checker runs successfully. 92.21.112.XX is the fixed external IP of the router, which is port forwarding to 192.168.0.200, the 3CX server. The 3CX Server is not set to use STUN, but has this fixed IP entered. The 2 phones are on the local LAN (on 192.168.0.100 and 192.168.0.101) as is the 3CX Server (on 192.168.0.200).

    I agree there is an identification issue. When 3CX is set to use port 5060 internally, and the phone registers on IP address 192.168.0.100, when it attempts to make a call then 3CX identifies it successfully. However, if 3CX is set to use port 5082 internally, and the phone registers on 192.168.0.100:5082, when it attempts to make a call it does not identify it successfully, and so goes on to do a check on the IP to see if it is an external extension, hence the check against 92.21.112.xx.
     
  4. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,373
    Likes Received:
    230
    An external IP should not even be involved when placing internal calls. Are the sets making use of STUN, when they shouldn't be?
     
  5. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    No, the handsets are not using STUN. As I said in my previous reply, I think the fact the external IP appears is a bit of a red herring, but I am happy to be shown to be wrong. I think the 3CX Server is trying to authenticate the call as from a registered internal extension, failing because the IP and port does not match the registered IP and port, then trying to authenticate it as an external extension and hence the IP check with the external IP.

    Am I barking up the wrong tree?

    The critical bit, I think, is:

    Incoming call rejected, caller is unknown; msg=Ivite-IN Recv Req INVITE from 192.168.0.100:5062 tid=-fc915a49 Call-ID=f1610bc4-98818935@192.168.0.100:
    INVITE sip:11@192.168.0.200:5082 SIP/2.0
    Via: SIP/2.0/UDP 192.168.0.100:5062;branch=z9hG4bK-fc915a49

    When the 3CX Server is set up to use port 5060, and the phone registers on the IP address 192.168.0.100 alone (which in fact would use port 5060) then it accepts the call from 192.168.0.100:5062. When I change the 3CX server to use port 5082 and register the handset on 192.168.0.100:5082 it does not accept the call from 192.168.0.100:5062.

    Thanks again for any help given though.
     
  6. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,373
    Likes Received:
    230
    I still see no reason as to why the public IP is showing for an internal call unless it is being introduced by the router for some reason (perhaps sending the data out, then back in?).

    Perhaps port 5082 is used by the router for other purposes, did you try another port, such as 5070?

    You could remove the new router from the network, as a test. if all devices have been assigned static IP's then internal calls should continue without it they would have be connected through a switch , of course).

    You could replace the new router with another (just not connected to the net), and continue to use port 5082 and see if that changes things.

    You could try continuing with the new router but disconnect the WAN side, does that make a difference? If that still failed then it is definitely something in the router that needs to be changed, or, the router may be incompatible.

    The fact that the new router does not allow port 5060 to be forwarded, suggests that it may have an inbuilt ATA that uses that port, and perhaps others. If that is the case, it may have a significant bearing on whether or not this will work.
     
  7. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    Thanks again. The phones are connected to the router via a switch anyway, I'll simply remove the router and test it and come back to you. I think it is the 3CX server that is introducing the public IP, but this will be a good test.

    The reason port 5060 is disallowed from the mapping is that TalkTalk consider it a security risk. To quote TalkTalk directly (my bold):

     
  8. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,373
    Likes Received:
    230
    If you have put the public IP into 3CX, you could try removing it and see if it makes a difference. If you put in a public IP I have to assume that you have been assigned a static IP?

    While this would seem to be an effective, and easy deterrent, simply changing the port is not the "cure-all" it would appear to be. Hackers are wise to that and scan more than one port, not just for a VoIP PBX, so, simply moving it is no guarantee that the new port won't be found. It may reduce the number of hack attempts, if some hackers use programmes that limit themselves to the "easy pickings" of the majority using port 5060.
     
  9. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    Yes, the 3CX server is running on a static IP.

    I agree, but it does take out some low hanging fruit. Anyway, it is built into the TalkTalk firmware of the router so there is no way around it, aside from changing the router. I am reluctant to do this, as the router is getting the highest speeds I have seen, seriously good for an old small town in the sticks.
     
  10. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    So, let's back up a little:

    1. As the registrations do seem to occur to port 5082, this seems to imply that the 3CX system is indeed accepting 5082 from Talk Talk.
    2. What version of 3CX are you running?
    3. In the VoIP provider section used to establish the credentials and all, I assume that port 5082 is listed?
    4. In the settings tab under Network, is port 5082 listed?
    5. The phone are set to use the internal 3CX IP address for proxy, no outbound proxy is set and the SIP port is set to 5082?
    6. How were the phones provisioned? Did you allow 3CX to re-provision the phones once the setting were all changed?
    7. If your version of 3CX has FQDN settings for settings, network, do you have the internal and external IP set or the appropriate FQDNs?

    As you have indicated that items in #3 and #4 above are already set, and I assume a restart of the system has been conducted, then this leads me more to the phones being suspect at the moment. .

    You might consider doing a factory reset and then allowing the 3CX system to re-provision and then test. To be certain that the provisioning file is also up to date, make a change to the phones under test (change the codec order and save and then change back as an example) to ensure that a new, updated provisioning file is generated. I noticed that the phones were still showing ports 5060 (10@192.168.0.200:5060) & ( Req INVITE from 192.168.0.100:5062 ) on your logs. Once done, then check the phones to see if #5 above is now correct and test.

    If the above does not work, then a wireshark capture would likely prove to be of immense help as we should be able to see where/who is causing the external IP to be seen.
     
  11. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    Hi, and thanks for taking the time.

    To answer your questions:

    Incoming calls are routed via the number provider to 01446650xxx@92.27.112.xx:5082 and are accepted by the 3CX Server and routed to the correct extension. If the call is not answered, the voicemail appears to work correctly.

    I was using version 11. Today I have backed up the database, removed v11 and installed the latest v12 (as I found a fixed bug report somewhere regarding using ports other than 5060). The issue remains.

    I have 5082 specified under SIP Server Port and outbound proxy port, but I don't think the call is getting that far. I have the same issue trying to call an internal extension, and also, I have now found, if I try to access voicemail.

    Yes, as we said incoming calls are accepted and routed correctly.

    The phones are set with proxy 192.168.0.200:5082, no outbound proxy is set. Each internal extension (there are 2 on 1 phone) uses a different SIP Port. The extension I am using to test is set to 5082 (the other 2 extensions are set to 5084 and 5086). There is also a separate SIP tab on the Linksys SPA942, with the settings SIP TCP Port Min and SIP TCP Port Max, set to 5082 and 5090 respectively. The extensions appear to register correctly.

    I manually provisioned them as a. 3CX no longer supports the phone and b. One phone has 2 extensions and this seemed to cause problems with the automatic provisioning in the past. I'll try it on a second phone with a single extension and come back to you.

    All the settings are by IP, checked and double checked. Again, the fact incoming calls are accepted and routed suggests this is all ok.

    This is the crux of it I think, particularly the 5060 port (the second one is where I had the extension set to 5062, I have changed this to 5082). I have shown a normal and verbose log for dialling voicemail on extension 99 below:

    Non-verbose:
    Verbose (note 5060 still appears!!):
    Sorry for the lengthy reply. I'll try auto provisioning and come back to you.
     
  12. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    To me, the issue is that the call is not being recognized as coming from an extension. As a result, the call is thought to be from a provider and because it appears to be on a DID and said DID is not listed in the source, it is being rejected.

    The extension with 2 lines associated to it will likely need manual provisioning. 3CX provides a generic provisioning page that is used for all phones as it is not really feasible to provide a custom page for each phone when the variations can be so great. You could modify a template to accommodate the need, but this may be more trouble than it is worth as you must then be on guard for any template changes, phone attribute changes, etc. such that you always know that the manual mods to the template remain intact.

    At this point I am not as concerned with the ports as I am with the external IP showing up. You might try and put the calling extension's extension number (*10) into the DID list and create an inbound rule just to see what happens.

    I think at this point a wireshark capture is best suited to get to the bottom of this.
     
  13. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    I autoprovisioned the 1 phone with the single extension. Apart from repeating the single extension 4 times, the settings were as I expected. It set the proxy at 192.168.0.200:5082 for registration as expected, but interestingly it left the extension SIP port as 5060. Anyway, it still displayed the same problem.

    I'll post a Wireshark capture shortly. Thanks for the continuing support.
     
  14. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    I forgot to mention, I tried adding 10 to the inbound rules, but of course it requires the VOIP Provider to apply it to. I applied it to all, but the same problem remains.
     
  15. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    I'm somewhat beyond my depth now, and not sure how to present the wireshark capture here. The summary of it is, these were on sequential packets:

    Source Destination Protocol Info
    192.168.0.100 192.168.0.200 SIP/SDP Request: INVITE sip:99@192.168.0.200:5082
    192.168.0.200 192.168.0.100 SIP Status: 407 Proxy Authentication Required
    192.168.0.100 192.168.0.200 SIP Request: ACK sip:99@192.168.0.200:5082
    192.168.0.100 192.168.0.200 SIP/SDP Request: INVITE sip:99@192.168.0.200:5082
    192.168.0.200 192.168.0.100 SIP Status: 403 Forbidden
    192.168.0.100 192.168.0.200 SIP Request: ACK sip:99@192.168.0.200:5082
     
  16. lneblett

    lneblett Well-Known Member

    Joined:
    Sep 7, 2010
    Messages:
    2,061
    Likes Received:
    56
    I would like to see the capture itself. This way I can see the SDP and other details.

    Download wireshark and install onto the machine with 3CX. Also install the pcap application.
    Start wireshark and select the same interface as that used on the 3CX machine.
    Start the capture and then make a test call from extension 10 to 999 (voice mail) or another extension.
    Once the call has completed, stop the capture and then save the file with whatever name you like. The file will have a pcap extension.
    You can then upload the attachment from below or if it will not accommodate send me private PM (supported by the forum) and I will provide an email address you can send to. .
     
  17. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    Thanks for the explanation, I'm out until tomorrow but will follow your instructions then. Thanks again.
     
  18. STRB

    Joined:
    Dec 23, 2014
    Messages:
    15
    Likes Received:
    0
    After lots of help from lneblett (thanks again!) I have at least identified that the Linksys SPA942 is causing the problem somehow, as the 3CX Softphone works perfectly.

    If I compare the logs from attempting to make a call to voicemail from the Linksys and the Softphone, then the Softphone differs at the log entry "Outbound URI is used". 3CX then adds the legs to each endpoint when using the Softphone.

    So I have a Linksys SPA942 that registers on port 5082, but when attempting to make any call, internal or external fails with a forbidden message.

    Any further ideas out there?
     
Thread Status:
Not open for further replies.