You cannot really rely on RSVP to handle establishing calls on your VoIP setup. This tip explains why this is a problem, but the solution may be a bit elusive.
Got a VoIP tip of your own? Why not send it in? We'll post it on our Web site, and we'll enter you in our tips contest for some neat prizes.
One common misunderstanding regarding QoS mechanisms for VoIP is that the Resource Reservation Protocol (RSVP) is sufficient for Connection Admission Control (CAC). It is an easy mistake to make, since these QoS mechanisms are quite complex, but hopefully, this tip will help shed some light on the problem.
When a voice call is made across an IP network, several protocols work together to imitate the signaling that happens in the old-school (circuit-switched) telephony networks (POTS and the PSTN). One of the keys to establishing QoS is preventing more VoIP calls from being set up than the network can handle. This is known as admission control because the calls aren't "admitted" into the network if the network can't support the bandwidth being requested by the call. In H.323, H.225.0 handles call control and H.245 negotiates media control. During this process, the UDP ports are determined, which combine with the IP addresses to form a socket.
So the problem with using RSVP for admission control is that the RSVP mechanism uses this socket (the IP address and UDP port) to reserve bandwidth. This is necessary because there may be other conversations happening simultaneously between these two hosts and the admission control mechanism needs to guarantee that they won't also interfere with the VoIP traffic. Thus, the bandwidth cannot be reserved by RSVP until after the call has actually been connected by H.225.0 and the media control negotiation completed by H.245! This creates an unfortunate catch-22 that will hopefully be remedied by future versions of RSVP.
Until then, if you've noticed that your network is admitting calls it can't support, or if you see successful call-setups but don't hear any audio, you may be experiencing this catch-22. Check with your vendor to see what alternatives he supports.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
Did you like this tip? Why not let us know? Send an email and sound off.