I have softphone users on VPN and when they call each other they are losing audio path. I know this is because after the call is setup the medpro drops out and it tries to go client to client. If you hit a touchtone it bring the medpro back in the link and the audio works.
I know there is a setting on the VPN that allows the clients to go direct but I do not remember what it is called… I had this on a Cisco VPN and network guys were able to fix it… I have a BIG IP F5 now that is having the same problem and they have not been able to fix it and F5 wants $ to diag the problem (different network guys).
You are already aware of direct ip to ip so I won’t rehash that.
From a traffic point of view there is a network restriction, most of the time at least 1 leg of the traffic is being block somewhere but without WireShark traces to dig into you’d be hard pressed to find where the restriction is.
Unless you can change the VPN concentrator settings (which i wouldn’t recommend changing), the key here is to turn off shuffling when the endpoints are VPN based, because your VPN concentrator isn’t allowing clients to talk directly to each other. So, typically you will make sure to set up a network region to represent the IP addresses that the VPN concentrator is handing out to clients. Then, for that network region, set Intra-network region (ie intra meaning both endpoints are in the same network region) shuffling to off.
I had the exact issue myself. There is a setting for “direct media path” somewhere in the VOIP settings in IPOffice. I’ll take a look when I’m in tomorrow for it its somewhere in my documentation
Yea… that or on the network region i think is a workaround…i was hoping to not have to travel the full distance back to the CM just to go back out if it can just loop thru the concentrator back to the client… it works to clients that come in on different concentrators, just not on the same one.
if you have statistics open when you are on the call you will see the IP address change from the medpro IP to the local IP and the audio stops, then you hit a DTMF key and it will switch back to the medpro IP change codecs also. the network guys called F5 and could not figure it out… i suspect they are looking at this a a pure VOIP issue but it could be more of a general setting on the concentrator. I do not have have great confidence in the network guys to diag this… they hear VOIP and get blinders on.
yes there are a few ways to get around it… either by the station form or network region form and force the hairpin thru the medpro… i was hoping to avoid that since that could add 3-6 hops inside the LAN…we have nectar running and seeing some of the reports of what network devices are getting hit just inside the LAN is just crazy… as in the LAN may not quite be optimized as is should be… we found a problem with CMS dropping the link and it turned out they had the path from the vmware cluster on floor 1(where the CM is) to the basement (in the same building to the CMS) was being routed thru a site 30 miles away and back. so my confidence is not high…
I had the same issues with my remote users…I just went to the extension level of each user and disabled direct media per user if I knew they were VPN remote. I eventually moved all remote workers to SIP TLS via ASBCE and all soft and hard clients came in through there no more need for VPN.
If you’re asking an Avaya forum, you’re going to get the answer from people that know Avaya. If there’s a big IP F5 forum then that might be a better question about changing your big IP F5. I’m not trying to be smart, I’m literally just saying that this group is going to know how to make it work from the Avaya side but if you don’t want to go all the way back to the Avaya side and back with the IP traffic and taking up extra DSPs while at it, then you need to ask in a group that handles the VPN set up. I suspect there is something that prevents VPN clients from talking to other VPN clients or that the VPN clients are sharing and added address rather than getting their own private IP address from the VPN.
They just get overwhelmed and nervous. Are you in a situation where you can physically duplicate the issue from your office and then compare the traffic with vs without the VPN and get a better idea of the variable(s) that could be causing the issue?
It sounds like there is something obviously going on with your VPN but you’ve got the hassle of trying to find a way to whittle down through the layers to determine which leg of travel is at fault. It’s really tough unless you’ve got a good network guy.
Comparing WireShark traces of traffic from the corporate LAN vs VPN would probably show something being blocked/dropped.
It’s fairly simple. For the network guys perspective, the endpoint/client is trying to send UDP to the other client and something is stopping that. No need to worry about VOIP or PSTN or other weird telephony things.
UDP is being sent but not received, they need to troubleshoot that.
I imagine other protocols are blocked too, eg you probably can’t ping the other VPN client either.