RSVP problems

RSVP problems
Tom Lancaster

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?

    Requires Free Membership to View

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.

This was first published in October 2001

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.