Link to home
Start Free TrialLog in
Avatar of TechGuy_007
TechGuy_007Flag for United States of America

asked on

Avaya Remote Phones & QoS

I have an Avaya IP Office Solution at the main office.  The ISP & SIP Provider are providing a dual handoff to our network with 0/0 going to the data network and 0/1 going to the WAN of the Avaya IP Office.  The remote handsets connect to the IP office through VPN which is terminating through the ISP's router 0/0 and finally at a Cisco ASA.  

Our network is unique as we also have a Watchguard Firebox running side by side with the Cisco ASA.  Normal data traffic is routing through the Watchguard.  Currently the only thing that the ASA is doing is performing VPN termination and once the VPN's are termianted forwarding the traffic to the phone server.  Obviously remote handset to remote handset RTP traffic is being routed through the ASA, and signaling forwards to the phone server.

1.)  Our remote handsets are experiencing QoS issues (low audio, choppy calls, disconnected calls).  
2.) Our local handsets are not have any problems whatsover (as the QoS is being performed by the ISP's router)
3.)  Remote sites have 20Mbit connections to the internet, and the main site has a T1x3 connections.  

Theory:  I believe that the Voice packets encapsulated in the IPSec VPN are being treated as raw data and not prioritized as being Voice traffic.  

Also because we are not using one firewall to manage the LAN QoS this could actually be causing more problems as their is no prioritization of the VPN traffic over standard data.

The question is:   Is this what is actually happening and if so what are the recommended solutions for this repair.
ASKER CERTIFIED SOLUTION
Avatar of BWaring
BWaring

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of TechGuy_007

ASKER

The phones are indeed traveling over open internet, and no they are not using MPLS.  And this may be the cause, however there are countless of Avaya remote users that use their handsets remotely in this manner and do not have the problems we are experiencing.

At this point I need to know how the ISP router would see the VPN traffic.  Since it's encrypted in VPN tunnel, does it see it as voice packets or data packets.  

And is there a way to assign priority over this traffic over the regular data traffic that's flowing in and out of the main site.  

Avatar of BWaring
BWaring

Not an 'expert' on the Cisco ASA, but generally, the VPN is only a tunnel that is created from one interface on a device to another. In your case, this would be from a WAN port on the Cisco to the WAN port at the remote side. Traffic is then directed through this tunnel from interface to interface. The VPN doesn't go THROUGH the device... Generally speaking, after the traffic enters (ingress) or before is leaves (egress) the interface, it is processed according to any applicable firewall/bandwidth/routing/prioritization rules that are in place on the device, then directed (or not) accordingly...

So for example, you can set an egress rule saying "give priority to voice traffic through the VPN on this interface" or "reserve x amount of bandwidth for voice traffic through the VPN on this interface", with corresponding ingress rules on the other side.... so now you are controlling how data enters the VPN tunnel and how it leaves on both sides... the other devices through the network on each side would also need similar QoS rules set up (I believe you are saying that is already in place)... you need to make sure those rules are set up on the interfaces of the ASA and the routers at the other sides...

Now, as the VPN tunnel gets 'routed' through the Internet, of course all those devices see is the VPN tunnel and not the data within, but since you cannot control those anyway, so it doesn't matter... when you have MPLS/VPN services, for example, the whole 'middle' betwen your sites that make up the VPN over the MPLS services DO see the data in all that traffic, so the provider can prioritize the voice over the normal data (that's a simplified explanation, but I think it gets the point across)...