SPA942 And Not Using 5060

[STRB]

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:[email protected]>;tag=3d14278ef85a211o0 to <sip:[email protected]>;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 [email protected]:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.0.100:5062;branch=z9hG4bK-fc915a49
To: <sip:[email protected]>;tag=a67ff26b
From: "Phone1"<sip:[email protected]>;tag=3d14278ef85a211o0
Call-ID: [email protected]
CSeq: 102 INVITE
Warning: 499 3CXServe "Caller is forbidden"
Content-Length: 0
23-Dec-2014 12:41:58.752 SendMsg from <sip:[email protected]>;tag=a67ff26b to "Phone1"<sip:[email protected]>;tag=3d14278ef85a211o0
23-Dec-2014 12:41:58.704 OnOffer from "Phone1"<sip:[email protected]>;tag=3d14278ef85a211o0
23-Dec-2014 12:41:58.704 [CM502001]: Source info: From: "Phone1"<sip:[email protected]>;tag=3d14278ef85a211o0; To: <sip:[email protected]>
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 [email protected]:
INVITE sip:[email protected]:5082 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.100:5062;branch=z9hG4bK-fc915a49
Max-Forwards: 70
Contact: "Phone1"<sip:[email protected]:5062>
To: <sip:[email protected]>
From: "Phone1"<sip:[email protected]>;tag=3d14278ef85a211o0
Call-ID: [email protected]
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:[email protected]: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:[email protected]:5060> to <sip:[email protected]: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:[email protected]>;tag=3d14278ef85a211o0 to <sip:[email protected]>;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 [email protected]:
INVITE sip:[email protected]:5082 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.100:5062;branch=z9hG4bK-a49ac3e9
Max-Forwards: 70
Contact: "Phone1"<sip:[email protected]:5062>
To: <sip:[email protected]>
From: "Phone1"<sip:[email protected]>;tag=3d14278ef85a211o0
Call-ID: [email protected]
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]

 

[lneblett]

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.

 

[STRB]

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.

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.

 

[leejor]

92.21.112.XX is the fixed external IP of the router, which is port forwarding to 192.168.0.200, the 3CX server.

An external IP should not even be involved when placing internal calls. Are the sets making use of STUN, when they shouldn't be?

 

[STRB]

92.21.112.XX is the fixed external IP of the router, which is port forwarding to 192.168.0.200, the 3CX server.

An external IP should not even be involved when placing internal calls. Are the sets making use of STUN, when they shouldn't be?

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 [email protected]:
INVITE sip:[email protected]: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.

 

[leejor]

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.

 

[STRB]

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.

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

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

If port 5060 is open it is an instant confirmation that there is a SIP device behind that IP, attackers scan subnets of the Internet to find open 5060 ports. Some attackers use the open ports themselves other may sell them on to other criminals to use. I think of leaving port 5060 open like wearing a hi-viz jacket with flashing light on your helmet at a paintball game, you might not get shot but it’s just not a good idea to make yourself a target.

 

[leejor]

I think it is the 3CX server that is introducing the public IP, but this will be a good test.

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?

The reason port 5060 is disallowed from the mapping is that TalkTalk consider it a security risk.

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.

 

[STRB]

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?

Yes, the 3CX server is running on 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.

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.

 

[lneblett]

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 ([email protected]: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.

 

[STRB]

Hi, and thanks for taking the time.

To answer your questions:

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.

Incoming calls are routed via the number provider to [email protected]: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.

2. What version of 3CX are you running?

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.

3. In the VoIP provider section used to establish the credentials and all, I assume that port 5082 is listed?

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.

4. In the settings tab under Network, is port 5082 listed?

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

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?

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.

6. How were the phones provisioned? Did you allow 3CX to re-provision the phones once the setting were all changed?

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.

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?

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

I noticed that the phones were still showing ports 5060 ([email protected]:5060) & ( Req INVITE from 192.168.0.100:5062 ) on your logs.

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:

30-Dec-2014 11:47:39.498 Leg L:1.1[Unknown:] is terminated: Cause: BYE from PBX
30-Dec-2014 11:47:39.450 [CM502001]: Source info: From: "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0; To: "Voice Mail"<sip:[email protected]>
30-Dec-2014 11:47:39.450 [CM503013]: Call(C:1): Incoming call rejected, caller is unknown; msg=Ivite-IN Recv Req INVITE from 192.168.0.100:5082 tid=-a7185917 [email protected]:
INVITE sip:[email protected]:5082 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.100:5082;branch=z9hG4bK-a7185917
Max-Forwards: 70
Contact: "Phone1"<sip:[email protected]:5082>
To: "Voice Mail"<sip:[email protected]>
From: "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0
Call-ID: [email protected]
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="414d535c0ab321db12:b5d284cbfd9a386956053687a993a0c9",uri="sip:[email protected]:5082",algorithm=MD5,response="b1cd7723571ab3925f026ff8b77e46e6"
Supported: replaces
User-Agent: Linksys/SPA942-6.1.5(a)
Content-Length: 399

v=0
o=- 8849525 8849525 IN IP4 192.168.0.100
s=-
c=IN IP4 192.168.0.100
t=0 0
m=audio 16434 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
30-Dec-2014 11:47:39.328 [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:
Invite-UNK Recv Req INVITE from 192.168.0.100:5082 tid=-7f092aeb [email protected]:
INVITE sip:[email protected]:5082 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.100:5082;branch=z9hG4bK-7f092aeb
Max-Forwards: 70
Contact: "Phone1"<sip:[email protected]:5082>
To: "Voice Mail"<sip:[email protected]>
From: "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0
Call-ID: [email protected]
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: 399

v=0
o=- 8849525 8849525 IN IP4 192.168.0.100
s=-
c=IN IP4 192.168.0.100
t=0 0
m=audio 16434 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

Verbose (note 5060 still appears!!):

30-Dec-2014 11:47:39.498 L:1.1[Unknown:]: Terminating targets, reason:
30-Dec-2014 11:47:39.498 Leg L:1.1[Unknown:] is terminated: Cause: BYE from PBX
30-Dec-2014 11:47:39.498 Terminated from "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0 to "Voice Mail"<sip:[email protected]>;tag=65559c1d; reason: Rejected
30-Dec-2014 11:47:39.497 L:1.1[Unknown:] Sending: OnSendResp Send 403/INVITE from 0.0.0.0:0 tid=-a7185917 [email protected]:
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.0.100:5082;branch=z9hG4bK-a7185917
To: "Voice Mail"<sip:[email protected]>;tag=65559c1d
From: "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0
Call-ID: [email protected]
CSeq: 102 INVITE
Warning: 499 3CXServer "Caller is forbidden"
Content-Length: 0
30-Dec-2014 11:47:39.497 SendMsg from "Voice Mail"<sip:[email protected]>;tag=65559c1d to "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0
30-Dec-2014 11:47:39.450 OnOffer from "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0
30-Dec-2014 11:47:39.450 [CM502001]: Source info: From: "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0; To: "Voice Mail"<sip:[email protected]>
30-Dec-2014 11:47:39.450 [CM503013]: Call(C:1): Incoming call rejected, caller is unknown; msg=Ivite-IN Recv Req INVITE from 192.168.0.100:5082 tid=-a7185917 [email protected]:
INVITE sip:[email protected]:5082 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.100:5082;branch=z9hG4bK-a7185917
Max-Forwards: 70
Contact: "Phone1"<sip:[email protected]:5082>
To: "Voice Mail"<sip:[email protected]>
From: "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0
Call-ID: [email protected]
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="414d535c0ab321db12:b5d284cbfd9a386956053687a993a0c9",uri="sip:[email protected]:5082",algorithm=MD5,response="b1cd7723571ab3925f026ff8b77e46e6"
Supported: replaces
User-Agent: Linksys/SPA942-6.1.5(a)
Content-Length: 399

v=0
o=- 8849525 8849525 IN IP4 192.168.0.100
s=-
c=IN IP4 192.168.0.100
t=0 0
m=audio 16434 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
30-Dec-2014 11:47:39.448 Call(C:1) is terminated
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=92.27.112.xx
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.447 IPs do not match!
30-Dec-2014 11:47:39.447 Compare IPs: incoming=192.168.0.200; external=92.27.112.xx
30-Dec-2014 11:47:39.446 IncomingCall: C:1 from <sip:[email protected]:5060> to <sip:[email protected]:5082>
30-Dec-2014 11:47:39.446 Added leg L:C:1.1[No endpoint yet]
30-Dec-2014 11:47:39.445 UasSession 597 started
30-Dec-2014 11:47:39.445 Call from "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0 to "Voice Mail"<sip:[email protected]>;tag=65559c1d
30-Dec-2014 11:47:39.328 [CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:
Invite-UNK Recv Req INVITE from 192.168.0.100:5082 tid=-7f092aeb [email protected]:
INVITE sip:[email protected]:5082 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.100:5082;branch=z9hG4bK-7f092aeb
Max-Forwards: 70
Contact: "Phone1"<sip:[email protected]:5082>
To: "Voice Mail"<sip:[email protected]>
From: "Phone1"<sip:[email protected]>;tag=749e23fd8e619f1bo0
Call-ID: [email protected]
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: 399

v=0
o=- 8849525 8849525 IN IP4 192.168.0.100
s=-
c=IN IP4 192.168.0.100
t=0 0
m=audio 16434 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
30-Dec-2014 11:47:39.327 IPs do not match!
30-Dec-2014 11:47:39.327 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=0.0.0.0
30-Dec-2014 11:47:39.326 IPs do not match!
30-Dec-2014 11:47:39.326 Compare IPs: incoming=192.168.0.200; external=92.27.112.xx

Sorry for the lengthy reply. I'll try auto provisioning and come back to you.

 

[lneblett]

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.

 

[STRB]

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.

 

[STRB]

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.

 

[STRB]

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:[email protected]: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:[email protected]:5082
192.168.0.100 192.168.0.200 SIP/SDP Request: INVITE sip:[email protected]: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:[email protected]:5082

 

[lneblett]

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

 

[STRB]

Thanks for the explanation, I'm out until tomorrow but will follow your instructions then. Thanks again.

 

[STRB]

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?