STUN Server

[DominicE]

Hi,

Before I go round in anymore circles I was hoping someone may know the answer.

I have a Gamma trunk which works absolutely fine with no STUN server. Everything is setup correctly in the LAN1 with a blank STUN server and incoming / outgoing calls function as normal.

I now need to use a STUN server which I'm currently testing with stun3.l.google.com however as soon as I put that in (nothing else on the LAN tab changes) incoming calls no longer function properly and are only one way/it may not even pick the call up (but it will drop it). Outgoing calls are fine.

As nothing further is updated on the LAN tab, why would this be? As soon as I remove the STUN server and go back to it being blank, it all works fine again.

I need to use a STUN server as our IP address changes when we failover from our primary to secondary connection.

Any help would be greatly appreciated.

Thanks,

 

[CMUK]

Try stun.counterpath.net , I use to use that a lot and never had many issues with it

Calum M
ACSS

 

[DominicE]

Sadly it's the same problem. As soon as I put the STUN server in and restart the IPO, I get one way calls on incoming. Nothing else changes on the network topology screen.

I have just upgraded to v11.0.4.0 - hopefully that hasn't got any bugs in it.

I'm not really sure what else it could be as the public IP it gets is absolutely fine.

 

[CMUK]

What type of router/firewall are you using and what ports are you forwarding?

Calum M
ACSS

 

[DominicE]

I have a Watchguard.

I've got UDP 5060, 6000-40000 forwarded.

Like I say, without STUN it works fine and has been fine for weeks. As soon as I put that STUN server in there, incoming calls are only one way. Outgoing it perfectly fine. Take the STUN server out and it's fine again.

The firewall isn't show anything odd like ports blocked etc.

 

[janni78]

Why have you forwarded UDP/6000-40000 ?

That's not the default RTP ports of IP Office.

"Trying is the first step to failure..." - Homer

 

[janni78]

IP500 V2 default = 46750. Range = 46750 to 50750.
Linux default = 40750. Range = 40750 to 50750

"Trying is the first step to failure..." - Homer

 

[DominicE]

6000 to 40000 is Gamma's default range. It has been altered in the LAN tab to reflect that and those ports forwarded.

Again with no STUN server it works fine with that setup.

 

[janni78]

What Gamma uses doesn't matter, that's the ports Gamma wants RTP on so those should be open for outgoing traffic.
The RTP ports on IP Office is the ports it want's to use and are for incoming RTP, you should not change this range to match Gamma, there's no need for it.

"Trying is the first step to failure..." - Homer

 

[DominicE]

I will test putting it back, but when I didn't do this, you used to get the odd call not working where it was using a port outside that range. Why would it mean it works fine without STUN that way? Yet STUN won't work with it?

 

[Pepp77]

You will also need 3478 UDP open to the STUN IP address if you want STUN to actually function.

| ACSS SME |

 

[DominicE]

Sadly both of those made no difference. As soon as it gets a STUN server in there, it doesn't pick an incoming call up.

18:49:35 174097mS NAT: EPNatMediaHelper f17fa41c for 0a000102000003f3 17.1011.1 2 SIPTrunk Endpoint created, parent f52def24 list size 1
18:49:35 174097mS NAT: Creating STUNClient to resolve binding for 10.0.1.2:46750, server FQDN [stun.l.google.com]:19302
18:49:35 174097mS NAT: Creating STUNUdpClient (this=0xf17f7740) local port:46750
18:49:35 174097mS DNS: stun.l.google.com DNS - refreshing: have valid (not used) result
18:49:35 174097mS NAT: Creating STUNClient to resolve binding for 10.0.1.2:46751, server FQDN [stun.l.google.com]:19302
18:49:35 174097mS NAT: Creating STUNUdpClient (this=0xf17f7570) local port:46751
18:49:35 174097mS DNS: stun.l.google.com DNS - refreshing: have valid (not used) result
18:49:35 174098mS NAT: 0a000102000003f3 17.1011.1 2 SIPTrunk Endpoint adding message CMConnect(f17f7f30) to nat message queue, size is 1


8:49:35 174108mS NAT: StunClient: ResolveIPAndPort 10.0.1.2:46750
18:49:35 174108mS NAT: STUNUdpClient TX: (this=0xf17f7740) [10.0.1.2:46750]=>[74.125.140.127:19302] ToS:136
18:49:35 174108mS NAT: StunClient: ResolveIPAndPort 10.0.1.2:46751
18:49:35 174108mS NAT: STUNUdpClient TX: (this=0xf17f7570) [10.0.1.2:46751]=>[74.125.140.127:19302] ToS:136
18:49:35 174116mS H323Evt: SESS 3 SetOperational local 10.0.1.2:0 remote 0.0.0.0:0 to 0
18:49:35 174117mS H323Evt: SESS 3 Configure: Alaw64K packet size 160
18:49:35 174117mS H323Evt: SESS 3 SetRemUDP 0 -> 6000, remote IP 0.0.0.0 -> 10.0.1.10
18:49:35 174117mS H323Evt: SESS 3 SetRfc2833: (1) rx payload 101 tx payload 101
18:49:35 174117mS CMMap: PCG::MapBChan pcp[103]b0r1 cp_b 0 other_cp_b 0 type CGTypeSimple
18:49:35 174117mS H323Evt: SESS 4 SetOperational local 10.0.1.2:0 remote 0.0.0.0:0 to 0
18:49:35 174118mS H323Evt: SESS 4 Configure: Alaw64K packet size 160
18:49:35 174118mS H323Evt: SESS 4 SetRemUDP 0 -> 31144, remote IP 0.0.0.0 -> 88.215.54.38
18:49:35 174118mS H323Evt: SESS 4 SetRfc2833: (1) rx payload 101 tx payload 101
18:49:35 174118mS H323Evt: SESS 4 SetHnt (rtp keepalives): enabled 0, send_initial_packet 1, send_periodic_packets 0
18:49:35 174118mS CMMap: PCG::MapBChan pcp[97]b0r1 cp_b 0 other_cp_b 0 type CGTypeSimple
18:49:35 174119mS CMMap: PCG::MapBChan cp RTP local 10.0.1.2:46750 remote 88.215.54.38:31144 , cp_other RTP local: 10.0.1.2:46760 remote 10.0.1.10:6000
18:49:35 174119mS CMMap: PCG::MapBChan cp oob 0 rfc_2833 1 , cp_other oob 0, rfc_2833 1, cp behind_nat 0 cp_other behind_nat 0

18:49:35 174158mS NAT: STUNUdpClient RX: (this=0xf17f7570) [74.125.140.127:19302]=>[10.0.1.2:46751] ToS:0
18:49:35 174158mS NAT: Response To Enquiry is: IP:46751

18:49:38 177628mS TFTP Download: Upgrader: Upgrade is not in Progress
18:49:39 178108mS NAT: StunClient: ResponseTimeout in Resolve RTP, attempt 2
18:49:39 178108mS NAT: STUNUdpClient TX: (this=0xf17f7740) [10.0.1.2:46750]=>[74.125.140.127:19302] ToS:136
18:49:41 180129mS RES: Thu 21/3/2019 18:49:41 FreeMem=58971300 Heap=58781904(3) Cache=189396 MemObjs=12924(Max 13308) CMMsg=3(6) ASN=0 Buff=5200 1364 1000 7440 5 Links=52765(52973) BTree=700(1045) CB=6054 MCT=0 CPU=06.47% CPUStats=02.79%/1/4/2074/179
01/459307/00.18%/0/02.70% MCR
18:49:41 180129mS RES2: IP 500 V2 11.0.4.0.0 build 74 Tasks=54 RTEngine=0 CMRTEngine=0 ExRTEngine=0 Timer=12+119 Poll=0 Ready=0 CMReady=0 CMQueue=0 VPNNQueue=0 Monitor=1 SSA=0 TCP=48(TLS=5 OFF=0) TAPI=0 Partner=0 ASC=1 SYS=MNTD OPT=UMNT SDSPD=2034
18:49:41 180129mS RES4: XML MemObjs=8 PoolMem=4748404(2) FreeMem=4736284(0) HeapUsed=0
18:49:41 180129mS RES5: CLog MemObjs=711 FreePoolMem(Objs)=4984(89) TotalMem=44800 StringsTotalMem=136500
18:49:43 182108mS NAT: StunClient: ResponseTimeout in Resolve RTP, attempt 3
18:49:43 182108mS NAT: STUNUdpClient TX: (this=0xf17f7740) [10.0.1.2:46750]=>[74.125.140.127:19302] ToS:136

 

[DominicE]

I take it Gamma wouldn't need to enable anything to get it working with a STUN server would they?

 

[CMUK]

Might be a dumb question but have you set a DNS server on the IP Office?

Calum M
ACSS

 

[DominicE]

I have. It seems to resolve fine:

server FQDN [stun.l.google.com]:19302

[74.125.140.127:19302]

Outgoing calls work fine. Incoming calls, it rings fine, it just won't pick it up for some reason. So there must be something different although it's ringing in fine as to why it won't pick the call up.

 

[DominicE]

Gamma have said:

As per the attached trace all of your inbound calls are failing due to no response, as you can see we [Gamma] are offering the calls to the correct IP address but are receiving no response back.
Please review the site setup as to why we are receiving no traffic back from you on the back of our INVITE's.

So I'm not sure what part of the STUN setup would be causing that to happen.

 

[mforrence]

Gamma have said:

As per the attached trace all of your inbound calls are failing due to no response, as you can see we [Gamma] are offering the calls to the correct IP address but are receiving no response back.
Please review the site setup as to why we are receiving no traffic back from you on the back of our INVITE's.

So I'm not sure what part of the STUN setup would be causing that to happen.

I've actually had a wonky STUN do EXACTLY this! Find another STUN server or (even better) install your own SBC, and trouble will go away.

Mike Forrence

http://www.goteamvox.com

 

[DominicE]

Thanks. I was using Google's so I would have thought that would work. I have tried a few others as well and no joy. There could be a problem with a few, but I can't really see it. I'll try a couple more and double check or if anyone has one they know works I'd appreciate giving it a go just to prove it one way or another.

Failing that it looks like SBC is going to be the way forward.

Thanks

 

[mforrence]

Indeed, if you've had multiple. Check the UDP port and firewall type that each STUN assigns - this may have a bearing. Check Monitor on a failed call, looking at UDP port in particular.

Mike Forrence

http://www.goteamvox.com

 

[amriddle01]

I have a Gamma trunk which works absolutely fine with no STUN server"

There's your clue right there.... something is rewriting the packets already, turn that off to use STUN