Dynamic Multi-Hop RSVP Negotiation for VoIP
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current RSVP protocols in VoIP systems are inefficient due to hop-by-hop negotiations and lack of end-to-end reservation support, leading to resource wastage and overhead, especially when multiple intermediary hops are involved and not all network elements support RSVP.
Innovation Solution
Negotiating RSVP reservation parameters prior to call setup by including relevant information in initial call signaling, allowing devices to determine their capabilities and adjust bandwidth accordingly, rather than during the call setup process, and using protocol-independent message elements within existing signaling models like H.323/SIP.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If hop-by-hop RSVP negotiations are performed during call setup, then RSVP reservations can be established along the data path, but multiple reservations are created before actual bandwidth negotiation, leading to resource wastage and increased overhead
Solution Approach 1:
The patent applies preliminary action by including RSVP capability information and bandwidth requirements in the initial call signaling messages (such as SIP INVITE or H.323 Setup) before the call is actually established. This allows all network elements along the path to be notified in advance about RSVP requirements, so that reservations are only created where actually needed rather than hop-by-hop during call setup. The system performs the reservation negotiation action beforehand through signaling message exchanges.
2Reliability
If RSVP reservations are established assuming maximum bandwidth, then reservations are created to ensure sufficient capacity, but the reservations frequently need to be re-established to match actual utilization, wasting resources
Solution Approach 1:
The patent applies parameter changes by dynamically adjusting RSVP reservation parameters based on actual application layer bandwidth negotiations. Instead of fixing reservations at maximum bandwidth, the system modifies reservation parameters (such as bandwidth values) according to the negotiated actual requirements from application layer protocols. This allows the network to allocate precisely the bandwidth that is actually needed rather than always reserving maximum capacity.
3Adaptability or versatility
If RSVP reservation process is performed even when end-to-end reservation is required and some network elements do not support RSVP, then the system attempts to establish reservations universally, but the reservation process wastes resources when RSVP cannot be used
Solution Approach 1:
The patent applies the intermediary principle by using application layer signaling protocols (SIP, H.323) as mediators to carry RSVP capability information and coordination data between network elements. These signaling messages act as intermediaries that allow RSVP-aware elements to communicate their capabilities and requirements without forcing RSVP onto elements that don't support it. The signaling layer mediates between RSVP requirements and actual network element capabilities, enabling selective reservation establishment only where RSVP is supported.
Data Source
AI summary
Negotiation of RSVP reservations prior to the setup of a call, rather than negotiating reservation parameters during the call. RSVP reservation parameters are negotiated prior to ringing a device, rather than after. In some embodiments, this is achieved by including information in the initial call signaling elements. This added information allows negotiation with each device in the proposed data path to determine, prior to ringing the terminating device in the data path, whether each of the devices can support the proposed data link.