I know that the audio and video streams, which are transmitted in the logical channels setup in H.245, are transported over dynamic port using UDP protocol. Despite of this, anyone could tell me if there is a range of ports used by endpoints to transmit audio and video stream? Thus way the application could classified using mechanism of QoS.
The Cisco MCM could be used to mark the packet of the videoconference, but there is a range of ports?
Video conferencing endpoints use the RTP range of ports between 1024 and 32757. They are dynamically picked on a per call basis one each for voice and video
11000 - 11999; for H.245 port numbers
16384 - 32757; for RTP port numbers
5060; - For SIP
1718 - 1719 ; for H.225 RAS 18 for GRQ and 19 for the rest
1720; for H.225 Q.931
Charles - Ebone
Is there a range of ports? Yes, but too many to give QoS.
Alternatives (apologies if you have already thought of these):
1. Use the Cisco MCM at each end of the WAN link with its H.323 proxy. Use the H.323 proxy for WAN link calls. Using the commands available on the proxy, you can implement either IP Precedence or RSVP to mark the packets. - The "By the Book" answer.
2. Use the Cisco MCM at each end of the WAN link with its H.323 proxy. Use the H.323 proxy for WAN link calls. Implement QoS for all traffic between the two proxies. - An altered "By the Book" answer.
3. Set up an H.323 environment, endpoints, gatekeepers, MCUs and gateways using whoever's products. Identify all the H.323 endpoints via IP address and provide QoS for these IP addresses. - It should work, but if you have either, loads of endpoints, DHCP, or just a busy network, this is no good/messy/un-manageable.
4. A halfway solution. Set up an H.323 environment, endpoints, gatekeepers, MCUs and gateways using whoever's products. Provide QoS for all connections to/from the MCUs and gateways only. These IP addresses should be static and you get QoS for calls using these devices, but one-to-one connections have to struggle through the network.
Hope these help.
i am very grateful for your reply. At the moment, the challenge is identify the videoconference in the network to apply properly QoS mechanism.
At the moment we are using the followings endpoints:
- Cisco MCU 3510
- Gateway Cisco 3520
- Terminals VCON, Polycom and PictureTel
Leave QoS to endpoints. I am a VCON engineer. VCON terminals themselves provide pretty good QoS, such as ip precedence, auto bandwidth adjust ... if not applicable for mcu, the use policy routing.
Leaving QoS to endpoints is not a feasible strategy. Without a mechanism in the network to verify the integrity of the settings in the enspoints, VC users can set any IP Prec settings they wish effectively destroying any order and by definition QoS. The best place to set QoS at this point is in a central point such as the QoS Proxy in the Cisco MCM or from a switch port.
I agree with you about the strategy of classification and marking in a central point such as QoS proxy.
With regarding use of switch to marking and considering that the terminals are not dedicated to videoconference, Do not you think that using switch port to marking could make that all application originated from the terminal would use the same service QoS created to videoconference? Or Is there a mechanism in a switch to differentiate H323?
If you just specify that the IP address of the video clients are to have a certain QoS, then all packets from that device with have QoS, not just the video ones. This is not good, see my comments in point 3 above.
If you configure the Cisco MCM to make the clients use the H.323 proxy for calls across WAN links, then you could specify that QoS applies to the proxies IP address, see my comments on point 2. This gives you QoS on the WAN, but NOT the LAN. If the LAN can't handle video without QoS, then you have other problems to worry about.
As for QoS at the endpoints, I am not sure whether that the VCON clients mark ONLY the VIDEO packets from the device, leaving all other traffic without QoS. However, it is probably best to leave QoS management/implementation to a central proxy device.
I agree with the points you make here and recommend using the MCM as well for those devices that are multifunctional - i.e., not only VC systems. Using IP precendence marking at the switch port is workable when you have a small number of VC-only video appliances
I have some doubts about proxy existing in the MCM.
1. Can I have 2 proxies configured in the same zone or I shall configure one proxy per zone?
2. Does the marking precedence occurs in all signaling H323 and audio/video stream?
UDP packets for Audio are normally 480bytes and a max of 1469 (UDP packet size).
UDP packets for video are a max also of 1469bytes but can be as little a 40bytes. Video packet size varies dependent on video motion. TCP packet sizes depend on the message but are normally a few bytes to a few hundred bytes.
The normal well known call signaling listen port is 1720 for endpoints and 1719 for GateKeepers (per H.323)
The media ports can be configured for a range. The current PT970 default settings are;
TCP traffic (port range: 1700 to 1750)
Call signalling for call establishment: 1720
UDP audio traffics use port range 17000 to 17050
UDP video traffics use port range 17100 to 17150
Other UDP traffics, such as RAS, use port range: 1700 to 1750
IF THE FIREWALL IS H.323 COMPLIANT, it leaves only port 1720 open for call setup. Then as the RAS messaging goes back and forth and the endpoints/gatekeepers agree on which IP ports to use for UDP etc, the firewall listens to these messages and opens only the ports needed for the session. The ports are closed when the session ends.