Hi,
Sorry I know not quite the correct forum. We're having an issue with our IP Office when using it on a fall back connection.
We're told Gamma will not take a secondary IP to authenticate in case of a connection failure, does anyone know if this is the case / they've had this scenario...
Thanks for the replies.
On a Watchguard SIP ALG is turned off by default. You have to have a separate policy to turn it on, which I don't - so I know that's not the problem.
The reason I'm trying to use STUN is because we're attempting to get it working with a failover connection which is on a...
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...
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...
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...
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...
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?
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.
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...
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...
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...
Just a note to say I do have calling waiting on per extension, but this was more for internal calls so you could see who was calling you internally if you were using the phone.
Thanks,
Hi,
Is there an option to allow a single incoming call per DID, otherwise give a busy tone?
At the moment a single number will allow multiple inbound calls to the hunt group. Our external IVR system doesn't function well allowing multiple calls per number and if it receive a busy tone when it...
Thanks, I think that's the general consensus. I just can't see if everyone is saying that, then why they don't fix it.
It's also odd how it's not on every call as well, but almost every call, so there must be something different which triggers it.
Hi,
I'm hoping someone can shed some light on why I'm seeing 100% packet loss on the SIP trunk and round trip delay of 65,000ms in the Status, Call Quality of Service monitor.
Having spoken to Avaya they suggest like on many forum posts on here, don't use the QoS, but I fail to see why it...
Following a test last night:
DHCP worked getting the phone onto the correct VLAN
IP Office was fine communicating with the phones that then appeared on the VLAN and the new IP range/gateway.
So for all intents and purpose it was segreted correctly with voice on a seperate VLAN and a route to...
Because people in offices make mistakes. New system, don't know new extension etc. It's a perfectly feesible problem, but obviously one that doesn't exist if the passwords are all different.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.