Wifi Works, 3G doesn't

[tsteffens]

uhoh this doesn't sound good. is it a problem?

 

[eagle2]

No, still I don't see a problem except port 8082 (firewall checker exit code 2).
What is the model of your router, how you implement NAT and destination NAT to 3CX PBX ?

Regards
Orlin.

 

[Vali_3CX]

what you mean by this - what is strange?

I see

SIP/2.0 200 Ok
v: SIP/2.0/UDP 192.168.254.69:5060;branch=z9hG4bK-d8754z-92287d0ca4165814-1---d8754z-;rport=5060
f: "2189277019" <sip:[email protected]:5060>;tag=da50ee79
t: "2189277019" <sip:[email protected]:5060>
i: NmI1N2M5ZmY5ZmE1MjIxNjgzNmY4OWIxNWI1MDY4ZjE.
CSeq: 4 REGISTER
m: <sip:[email protected]:5060;rinstance=95c0caf40f1255c9>;expires=62
l: 0

while I expected this

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.254.69:5060;branch=z9hG4bK-d8754z-92287d0ca4165814-1---d8754z-;rport=5060
From: "2189277019" <sip:[email protected]:5060>;tag=da50ee79
To: "2189277019" <sip:[email protected]:5060>
Call-ID: NmI1N2M5ZmY5ZmE1MjIxNjgzNmY4OWIxNWI1MDY4ZjE.
CSeq: 4 REGISTER
Contact: <sip:[email protected]:5060;rinstance=95c0caf40f1255c9>;expires=62
Content-Length: 0

 

[tsteffens]

we use this device as our NAT device.

http://www.untangle.com/

Also, I am still confused as to how this points to that device when I can connect to wifi outside of the office and it works just fine.

 

[Vali_3CX]

Also, I am still confused as to how this points to that device when I can connect to wifi outside of the office and it works just fine.

All I can tell you, for sure, is that 3CXPhone will not recognize a "v: f: t: i: m: l:" answer or response from remote side.
http://tools.ietf.org/html/rfc3261

 

[tsteffens]

Also, I am still confused as to how this points to that device when I can connect to wifi outside of the office and it works just fine.

All I can tell you, for sure, is that 3CXPhone will not recognize a "v: f: t: i: m: l:" answer or response from remote side.
http://tools.ietf.org/html/rfc3261

So what could be stripping that? the NAT device? ATT network? 3cx server?

 

[eagle2]

what you mean by this - what is strange?

I see

SIP/2.0 200 Ok
v: SIP/2.0/UDP 192.168.254.69:5060;branch=z9hG4bK-d8754z-92287d0ca4165814-1---d8754z-;rport=5060
f: "2189277019" <sip:[email protected]:5060>;tag=da50ee79
t: "2189277019" <sip:[email protected]:5060>
i: NmI1N2M5ZmY5ZmE1MjIxNjgzNmY4OWIxNWI1MDY4ZjE.
CSeq: 4 REGISTER
m: <sip:[email protected]:5060;rinstance=95c0caf40f1255c9>;expires=62
l: 0

while I expected this

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.254.69:5060;branch=z9hG4bK-d8754z-92287d0ca4165814-1---d8754z-;rport=5060
From: "2189277019" <sip:[email protected]:5060>;tag=da50ee79
To: "2189277019" <sip:[email protected]:5060>
Call-ID: NmI1N2M5ZmY5ZmE1MjIxNjgzNmY4OWIxNWI1MDY4ZjE.
CSeq: 4 REGISTER
Contact: <sip:[email protected]:5060;rinstance=95c0caf40f1255c9>;expires=62
Content-Length: 0

I thought this is a normal abbreviation of fields name, this happened to me also before. Could this be a wireshark peculiarity? I will investigate it. Really, this is strange.

However it seems there is a successful registration to Callcentric. Could Tsteffens prove it? Is Callcentric working fine (making and receiving calls, etc.)?

That wireshark capture contains infact declined request from remote phone (twice) and successful request to Callcentric.

Regards

 

[tsteffens]

oh yes callcentric is making and receiving calls just fine from in office phones and windows 3cxphone.

 

[Vali_3CX]

I thought this is a normal abbreviation of fields name, this happened to me also before. Could this be a wireshark peculiarity?

I don't think it's Wireshark here. To be convinced, select record 75 then choose "Follow UDP Stream". Do the same thing for the tunnel - record 2, "Follow TCP stream" (LAPK, sip0 blablabla are tunnel-appended). In first is "v:", in second is "Via:", and so on.

I'm not suspecting this stripping/abbreviation is coming from router or from callcentric, I'm suspecting is coming from 3G provider - as far as I understood, using WiFI is working but using 3G no.

I will ask tomorrow my teammates who are more skilled in such things than me.

 

[eagle2]

we use this device as our NAT device.

http://www.untangle.com/

Also, I am still confused as to how this points to that device when I can connect to wifi outside of the office and it works just fine.

Look at this article: http://wiki.untangle.com/index.php/Untangle_Bypass_Rules
This is related to the problem with firewall checker -- exit code 2 (port 8082).

By the way this could also the source of SIP field name manipulation (as noted by Vali).

Regards

 

[tsteffens]

we use this device as our NAT device.

http://www.untangle.com/

Also, I am still confused as to how this points to that device when I can connect to wifi outside of the office and it works just fine.

Look at this article: http://wiki.untangle.com/index.php/Untangle_Bypass_Rules
This is related to the problem with firewall checker -- exit code 2 (port 8082).

By the way this could also the source of SIP field name manipulation (as noted by Vali).

Regards

ok added the following ports for bypass:

5060:sip
8082:tunnel
9000-9049 rtp.

still doesn't work, and here is new firewall checker log:

3CX Firewall Checker, v1.0. Copyright (C) 3CX Ltd. All rights reserved.

<15:46:47>: Phase 1, checking servers connection, please wait...
<15:46:47>: Stun Checker service is reachable. Phase 1 check passed.
<15:46:47>: Phase 2a, Check Port Forwarding to UDP SIP port, please wait...
<15:46:51>: UDP SIP Port is set to 5060. Response received correctly with no translation. Phase 2a check passed.

<15:46:51>: Phase 2b. Check Port Forwarding to TCP SIP port, please wait...
<15:46:51>: TCP SIP Port is set to 5060. Response received correctly with no translation. Phase 2b check passed.

<15:46:51>: Phase 3. Check Port Forwarding to TCP Tunnel port, please wait...
<15:46:51>: TCP TUNNEL Port is set to 8082. Response received correctly with no translation. Phase 3 check passed.

<15:46:51>: Phase 4. Check Port Forwarding to RTP external port range, please wait...
<15:46:56>: UDP RTP Port 9000. Response received correctly with no translation. Phase 4-01 check passed.
<15:46:56>: UDP RTP Port 9001. Response received correctly with no translation. Phase 4-02 check passed.
<15:46:56>: UDP RTP Port 9002. Response received correctly with no translation. Phase 4-03 check passed.
<15:46:56>: UDP RTP Port 9003. Response received correctly with no translation. Phase 4-04 check passed.
<15:46:56>: UDP RTP Port 9004. Response received correctly with no translation. Phase 4-05 check passed.
<15:46:56>: UDP RTP Port 9005. Response received correctly with no translation. Phase 4-06 check passed.
<15:46:56>: UDP RTP Port 9006. Response received correctly with no translation. Phase 4-07 check passed.
<15:46:56>: UDP RTP Port 9007. Response received correctly with no translation. Phase 4-08 check passed.
<15:46:56>: UDP RTP Port 9008. Response received correctly with no translation. Phase 4-09 check passed.
<15:46:56>: UDP RTP Port 9009. Response received correctly with no translation. Phase 4-10 check passed.
<15:46:56>: UDP RTP Port 9010. Response received correctly with no translation. Phase 4-11 check passed.
<15:46:56>: UDP RTP Port 9011. Response received correctly with no translation. Phase 4-12 check passed.
<15:46:56>: UDP RTP Port 9012. Response received correctly with no translation. Phase 4-13 check passed.
<15:46:56>: UDP RTP Port 9013. Response received correctly with no translation. Phase 4-14 check passed.
<15:46:56>: UDP RTP Port 9014. Response received correctly with no translation. Phase 4-15 check passed.
<15:46:56>: UDP RTP Port 9015. Response received correctly with no translation. Phase 4-16 check passed.
<15:46:56>: UDP RTP Port 9016. Response received correctly with no translation. Phase 4-17 check passed.
<15:46:56>: UDP RTP Port 9017. Response received correctly with no translation. Phase 4-18 check passed.
<15:46:56>: UDP RTP Port 9018. Response received correctly with no translation. Phase 4-19 check passed.
<15:46:56>: UDP RTP Port 9019. Response received correctly with no translation. Phase 4-20 check passed.
<15:46:56>: UDP RTP Port 9020. Response received correctly with no translation. Phase 4-21 check passed.
<15:46:56>: UDP RTP Port 9021. Response received correctly with no translation. Phase 4-22 check passed.
<15:46:56>: UDP RTP Port 9022. Response received correctly with no translation. Phase 4-23 check passed.
<15:46:56>: UDP RTP Port 9023. Response received correctly with no translation. Phase 4-24 check passed.
<15:46:56>: UDP RTP Port 9024. Response received correctly with no translation. Phase 4-25 check passed.
<15:46:56>: UDP RTP Port 9025. Response received correctly with no translation. Phase 4-26 check passed.
<15:46:56>: UDP RTP Port 9026. Response received correctly with no translation. Phase 4-27 check passed.
<15:46:56>: UDP RTP Port 9027. Response received correctly with no translation. Phase 4-28 check passed.
<15:46:56>: UDP RTP Port 9028. Response received correctly with no translation. Phase 4-29 check passed.
<15:46:56>: UDP RTP Port 9029. Response received correctly with no translation. Phase 4-30 check passed.
<15:46:56>: UDP RTP Port 9030. Response received correctly with no translation. Phase 4-31 check passed.
<15:46:56>: UDP RTP Port 9031. Response received correctly with no translation. Phase 4-32 check passed.
<15:46:56>: UDP RTP Port 9032. Response received correctly with no translation. Phase 4-33 check passed.
<15:46:56>: UDP RTP Port 9033. Response received correctly with no translation. Phase 4-34 check passed.
<15:46:56>: UDP RTP Port 9034. Response received correctly with no translation. Phase 4-35 check passed.
<15:46:56>: UDP RTP Port 9035. Response received correctly with no translation. Phase 4-36 check passed.
<15:46:56>: UDP RTP Port 9036. Response received correctly with no translation. Phase 4-37 check passed.
<15:46:56>: UDP RTP Port 9037. Response received correctly with no translation. Phase 4-38 check passed.
<15:46:56>: UDP RTP Port 9038. Response received correctly with no translation. Phase 4-39 check passed.
<15:46:56>: UDP RTP Port 9039. Response received correctly with no translation. Phase 4-40 check passed.
<15:46:56>: UDP RTP Port 9040. Response received correctly with no translation. Phase 4-41 check passed.
<15:46:56>: UDP RTP Port 9041. Response received correctly with no translation. Phase 4-42 check passed.
<15:46:56>: UDP RTP Port 9042. Response received correctly with no translation. Phase 4-43 check passed.
<15:46:56>: UDP RTP Port 9043. Response received correctly with no translation. Phase 4-44 check passed.
<15:46:56>: UDP RTP Port 9044. Response received correctly with no translation. Phase 4-45 check passed.
<15:46:56>: UDP RTP Port 9045. Response received correctly with no translation. Phase 4-46 check passed.
<15:46:56>: UDP RTP Port 9046. Response received correctly with no translation. Phase 4-47 check passed.
<15:46:56>: UDP RTP Port 9047. Response received correctly with no translation. Phase 4-48 check passed.
<15:46:56>: UDP RTP Port 9048. Response received correctly with no translation. Phase 4-49 check passed.
<15:46:56>: UDP RTP Port 9049. Response received correctly with no translation. Phase 4-50 check passed.


Application exit code is 0

 

[tsteffens]

would using dynamicDNS for outside ip have any affect on this?

 

[tsteffens]

I thought this is a normal abbreviation of fields name, this happened to me also before. Could this be a wireshark peculiarity?

I don't think it's Wireshark here. To be convinced, select record 75 then choose "Follow UDP Stream". Do the same thing for the tunnel - record 2, "Follow TCP stream" (LAPK, sip0 blablabla are tunnel-appended). In first is "v:", in second is "Via:", and so on.

I'm not suspecting this stripping/abbreviation is coming from router or from callcentric, I'm suspecting is coming from 3G provider - as far as I understood, using WiFI is working but using 3G no.

I will ask tomorrow my teammates who are more skilled in such things than me.

I thought the tunnel was supposed to bypass provider issues?

 

[Vali_3CX]

I thought the tunnel was supposed to bypass provider issues?

What is passed through the tunnel is the traffic between 3CXPhone and 3CX PBX - 3CXPhone's tunnel "is talking" with PBX's tunnel. And is everything OK in the SIP "dialog", I checked.

 

[eagle2]

The tunnel port is 5090, not 8082 -- please correct your configuration (port 8082 was an erratic result of SIP ALG for port 5060). You need to forward ports 5060, 5090, 9000-9049 (UDP) and port 5090 (TCP) to 3CX server by default.
If your firewall checker result code is 0, than everything should be fine.

Hope this solves your issues.

Regards,
Orlin.

 

[Vali_3CX]

The tunnel port is 5090, not 8082

Orlin, 5090 is the default port, PBX admin can change it to any convenient value.
According to wireshark capture, tunnel traffic through 8082 is ok:
->Sip0REGISTER sip:192.168.254.69:5060 SIP/2.0
<-Sip0SIP/2.0 407 Proxy Authentication Required
->Sip0REGISTER sip:192.168.254.69:5060 SIP/2.0
<-Sip0SIP/2.0 200 OK

 

[tsteffens]

Still confused at what is going on. but wifi does work correctly.....

 

[Vali_3CX]

OK, I checked and I guess I found it:
the "f:, t:, v: ..." are called "SIP compact form" and they may be used for UDP transport, to reduce the size of the packet.
I will check about this tomorrow at work.
From my point of view, we can end our discussion for this evening/night and leave it for tomorrow 8)
Regards
vali

 

[tsteffens]

thank you for your time today!

 

[Vali_3CX]

thank you for your time today!

Don't worry, I guess we are on the right track.
Thank you and Orlin for your feedback, very useful discussion 8)