Vonage---VOIP

I have four 900Mhz AP clusters seperated about 3 miles in each direction ( North, South, East, West) from the center of my service area, and about 150 SM’s.

All hardware is on 7.3.6 with HW scheduling

We just started up in April of this year and are running like mad trying to keep up with demand.

I have been taking many calls about Vonage. Are there any settings in the AP’s or SM’s that can facilitate the “High Priority” traffic for Vonage that anyone knows about?

Three tower sites are connected to my fiber network which share a full DS3 at the NOC. The fourth is on 5.2 Backhaul.

Connected bandwith is not a problem.

Currently I have set all SM’s set at:
2000 kbps down sustained
3000 kbps down burst
512 kbps up sustained
600 kbps up burst.

I have had two customers purchase the Vonage and both reported problems with intermittent service.

I modified the two customers up config to 1000 sustained and 1500 burst and the problem persisted.

Any Ideas or suggestions would be greatly appreciated.

Unfortunately Vonage requires way to many ports to be open in order to get a quality of service. Canopy doesn’t have this capability. What I have tried is have the customer purchase a netgear or similar router and follow the instructions on the link below. Good Luck!

http://www.vonage.com/help.php?article= … y=44&nav=3

If your saying that bandwidth is not an issue, then QoS probably isn’t the solution, since there would be no packet queue?

As suggested, this could be a NAT issue. NAT does bad things for our VoIP. Yes, use an external router for the natting… however, I have been testing a netgear router that does the same thing… so just give the phone a real IP?

Thanks for the replies.

NAT is disabled. I have not used it on any Canopy equip. As a newbie, I have not yet learned how to use NAT in Canopy.

I have been Natting Public IP’s all the way down to the Customer equip and routing the IP within my layer 3 Alcatel switch or routing the public to the private in my firewall.


I gave the customers a static IP for their Vonage routers.

Generally we use seperate VLANs for each SM and use DHCP to assign IP’s to cust equip.

I had both customers check bandwidth with my providers local speed test server. The same Server we use for our FTH application and DS3 Mgmt.

They would get 1.5Mb down and 460Kb up most of the time.

About every fourth sequential test, it would return a value of 30Kb up.

This led me to believe that it might be a “high priority” traffic configuration in the Canopy equip…

Let me start off by saying that Vonage has issues that are exasperated by added latency. You need to have a really clean network to be able to get acceptable Vonage performance. Many things will kill VoIP on a canopy network

- Traffic saturation
- High Jitter (<2@1X, <9@2X)
- Self Interference between clusters
- Canopy Timing issues
- Heavy P2P traffic
- Heavy broadcast traffic
- Virus at the customer LAN
- Buggered NAT or Bridge Tables

Do some link tests from the customer SM to the AP and confirm that you are getting better than 90% efficiency at 1X mode, or 60% at 2X mode. Also do some ping tests from the customer PC to your gateway - ideally you will be less than 50ms from the customer to your gateway.

Also check the latency from your gateway to various routers on the internet and make sure your ISP does not have a peering problem upstream. If you can somehow come up with the IP addresses of the Vonage VoIP switches, you could do some real testing from your network to their switches.

You might have your customers try a Linksys RTP300 with QOS enabled. I don’t think this device actually tags the WAN traffic as high priority, but rather assigns priority to the voice traffic over other LAN traffic on the LAN side.

Are you monitoring the BW on your network? How do the flows look? Can you correlate the VoIP problems with traffic patterns across the AP’s and BH’s?

I would encourage you to enable the following filters (unless needed such as BootP Client or PPPoE) on the SMs to minimize unnecessary broadcast traffic.

PPPoE
SMB (Network Neighborhood)
SNMP
Bootp Client
Bootp Server
IPv4 Multicast

We will be white labeling a VoIP solution to resell that runs on specific ports. This way way we can implement QOS.

not sure about Vonage but we have been real successful with Sipura and Innomedia ATA’s by having them tag the sip packets with Diffserv codepoint 46 and the RTP packets with 34. In the SM and AP set the 46 Diffserv codepoint to a priority of 6 and the 34 to 4. make sure all equipment between ata’s and gateway is QOS capable and have these values set. I do have Vonnage customers on the system but no complaints so I havn’t looked into it.

Reay-

The problem may be associated with the fact that you aren’t giving public IP addresses to customers.

If I remember it correctly, you’re doing VLAN-per-customer and allocating a small 10.xxx.xxx.xx subnet to each VLAN. That subnet is then NATted via your Alcatel gear.

This means most customers are double NATted (your 10.xxx NAT, then their Linksys/Netgear router on-site)

Try allocating a real public-routable subnet to a customer w/ Vonage…

Kyle

A-ha!

double NAT will definitely cause problems with any VoIP

bonage have a configuration page, where the user can select how much bandwith to use; have your customer set it to the middle or low.

My sugestion.

Our VoIP provider uses SIP and RTP. SIP to setup the call, and RTP for the voice traffic. RTP uses diff serv code point 46 in our case, so I set the priority to 5 (As my reading indicates that 7 is not actually a higher priority? can anyone verify this?)

Also, my VoIP provider told me that SIP is code point 26, however I have sniffed the traffic and it shows to me as 44. (1011|0000) < My reading also indicates that the last to bits of the diff serv byte “Don’t count”. Can someone verify this as well?

Kyle,

You are right about the network config.
We charge a little extra for Public IP’s, however I will give that a try.
I believe that both users have returnrd their Vonage modems.
Maybe I will be ready for the next one.
It is good to hear that your still out there. Thanks

Jerry,

I have been reading this forum for months, and it is clear that you have helped many many users.

Thank you, for your replies and advice.
I am in the process of implementing the filters you mentioned.