Saturday, May 30, 2009

Vonage Voice-Bearer and Call Signaling Traffic QoS (Part 1 of 3)

This is the first of 3 posts I am making regarding my experience with Vonage on my Cisco network. Last week, I got a call from my small cable provider (Stowe Cable/Stowe VoIP) which, by the way are awesome and always provide superior customer service. Anyway, the lady called to let me know their VoIP division was bought by Momentum and that they would not be able to carry my home phone number anymore. Because it would be an inconvenience to have to update everyone with a new phone number, I decided to see if there were any other companies that offer VoIP and would be able to carry the number. I searched with Google and found several companies, some of which had already gone out of business, and some major well-known ones. Most provided the ability for me to enter my phone number on their website to see if my number could be transferred to them. I tried with,, a few others and Of those, only Vonage could carry my number. So, I signed up, and started the process. All the while, I set to try to understand how this would work. With Stowe VoIP, an EMTA device was placed directly on the coax entering the house from outside, and the phone was connected to it via a regular RJ-11 cable. In contrast, with Vonage, I learned that they would ship me a VDV21-VD which is basically an analog telephone adapter (ATA)-router combo with ethernet ports instead of coax. Now, because I already have two Cisco routers and a Cisco multilayer switch, I wasn't sure how this would connect. Realizing that my setup is not really 'mainstream', I wanted to know how the VDV21 worked and how I could best integrate it. A few days later, I received the device and promptly connected the WAN/Internet port to my internal switch. This was my preference because if I could get this to work, it would mean the VoIP system could take advantage of my dual-ISP redundancy. As expected, the adapter obtained an IP address from my DHCP server. I left the LAN port unused because I believe, in my scenario, it would not be needed since I am not using the "router" functionality of the VDV21, and simply using it as an ATA. I then connected an analog phone to the RJ-11 jack on the VDV21, and was able to immediately make an outbound call. Note- no inbound call is possible yet because my number transfer has not completed. Next order of business was to see if I could also plug the VDV21's LAN port into my network so I could manage the device via its embedded web server. Realizing it would not make sense to connect it into the same subnet, and fearing that the VDV21 was pre-configured as a DHCP server, which would potentially cause havoc by assigning IP addresses in an unwanted range to my internal hosts, I simply connected the LAN port to my laptop port. The laptop obtained and I was able to manage the VDV21 device via HTTP. The above method of management was temporary, so I configured the VDV21 to allow remote management (meaning HTTP access from the outside to the WAN/Internet port) by checking the box in "Advanced Setup, Network Options, Remote Config Management". I was then able to assign a static IP address, add the VDV21 device (I made up a hostname) to my internal DNS server, and then administer by name. Now, before discussing QoS next, one observation that impressed me about Vonage is they support many different ATA models of different brands, and allow high flexibility with different options. For example, if the default 90Kbps call (which I found means the G.711u codec) eats up too much bandwidth, they allow the user to lower this to 50Kbps or 30Kbps via their web-based dashboard, among many other features. This not only makes their service more appealing to geeks like me, but provides for potential extra sales to small businesses that may have similar networks, even if customer tech support might be a bit more complicated for them. I applaud this strategy. Finally, being somewhat familiar with the requirement for QoS in converged networks, I set to determine how exactly to configure my switches and routers for voice and call signaling. Via Netflow, I saw that the voice-bearer traffic leaving the ATA going to the Internet (Vonage's datacenter in the New York area, as determined by a traceroute), already had a DSCP of EF. However, the return traffic was set to DSCP 0. And, I was unable to determine by just looking at Netflow data, what consisted of call signaling. I therefore used Wireshark on a SPAN port on the Catalyst switch to capture all traffic to/from the ATA and made a call. Here are the results. Some kind of SIP "REGISTER" keepalives every 20 seconds: UDP/SIP source port 1030 destination port 10000 with DSCP 0 The reply: UDP/SIP source port 10000 destination port 1030 with DSCP CS1 (DSCP CS1 in this case, I assume is one of the ISP's in the path, setting this traffic as scavenger, as per the Cisco SRND) The off-hook/on-hook/invite/dial-phone-number packets: UDP/SIP/SDP source port 1030 destination port 10000 with DSCP 0 ...again with DSCP CS1 for the return traffic. During the call, every second, the following occurs: UDP/RTCP source port 10057 destination port 14697 both outbound and return have DSCP 0. I am unsure if the last one (1-second during-call keepalives) would have a dynamic, different port if I made a second call. I'll have to setup another capture later. So, based on this, configuring QoS for Vonage, will mean classifying and marking the call signaling packets both ways (outbound towards the Internet when entering the Catalyst switch, and also when coming back from the Internet, entering the router), as well as the voice-bearer coming back from the Internet, when it enters the router. Then, assign bandwidth, shape, police, etc. by following some of the suggestions in the Cisco QoS SRND document. I'll post those configs after I've figured them out and they've been tested. UPDATE- June 1 2009 A few days after, I made more captures and discovered the REGISTER/INVITE/etc. source port varies, for example, instead of UDP 1030 like the other day, now, the 20 second interval messages, as well as the off-hook messages are sourced from 1048. So, I guess the ACL will have to match the destination port only. Also, the RTCP 1-second keepalive messages do vary as well. However, they are odd numbers, and I assume from reading the Vonage forums the range is from 10000 to 20000 (same as the RTP traffic). So, to recap, the RTP voice bearer traffic is a random port (even numbered) between 10000 and 20000, and the RTCP traffic is a random port (odd numbered, one up from the RTP port).


  1. Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.
    html5 player| html5 video player

  2. Are you still using this setup Pierre and if is it working?
    I have a similar setup cisco > procurve > vonage....which I have been too lazy to attempt to setup qos on(much easier just to take the beating)!

  3. Yes, still using this setup and it works perfectly. :)