Parallel Forking with AOR Chaining for SIP Call Routing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current Session Initiation Protocol (SIP) communication systems lack the ability to define and manage advanced call resolution preferences, particularly in scenarios involving multiple users and media types, limiting the flexibility and sophistication of alerting and application sequencing during call establishment.
Innovation Solution
Implementing a contact resolution preference table that allows users to define preferences for alerting multiple communication devices and backup users, enabling parallel forking and application sequencing based on user-defined preferences, including addresses of record (AoR) for extended alerting and feature integration.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If traditional parallel forking is used to alert multiple communication devices, then basic alerting functionality is provided, but the system lacks the ability to define advanced call resolution preferences for multiple users and media types
Solution Approach 1:
The contact resolution system is segmented into multiple independent preference tables, each dedicated to a specific user. Each table contains structured preference records that can be independently configured for different media types (voice, video, messaging) and priority levels, allowing granular control without increasing overall system complexity
Solution Approach 2:
The system adds new dimensions to call resolution by introducing media type classification (voice, video, messaging) and priority levels as additional organizational dimensions. This allows preferences to be defined not just for single contacts but for multiple contacts across different media types and priorities, transforming the flat contact list into a multi-dimensional preference structure
2Productivity
If application sequencing is implemented during session establishment, then applications can be inserted into the communication session, but the applications are sequentially invoked rather than allowing parallel processing
Solution Approach 1:
The application invocation mechanism is made dynamic by allowing the system to automatically select between sequential and parallel execution modes based on the configured preferences and application requirements. The system can dynamically adjust the invocation strategy without requiring complex manual configuration for each scenario
Solution Approach 2:
The system performs self-service by automatically determining the optimal application invocation sequence or parallel execution plan based on pre-configured preferences stored in the contact resolution tables. The system autonomously manages application coordination without requiring external intervention or complex orchestration logic
3Adaptability or versatility
If users can only define preferences for their own communication devices, then simple alerting is achieved, but the system cannot support alerting backup users or assistant supervisors
Solution Approach 1:
The preference table structure is designed to be universal and can store preferences for any type of contact, not just the user's own devices. The system can handle preferences for primary devices, backup devices, assistant supervisors, and other contacts through the same unified table structure, eliminating the need for separate configuration mechanisms
Solution Approach 2:
The contact resolution preference table acts as an intermediary that bridges the gap between user intent and system action. It stores and manages preferences for multiple users and contacts, allowing the system to automatically route calls to appropriate backup users or assistants based on the stored preferences without requiring direct user input for each scenario
Data Source
Figure 1
Figure 2
Figure 3
AI summary
The concept of chained parallel forking is introduced. Addresses of record are included in a cantactee's cantact resolution preferences to enable an incoming INVITE message to be routed to one or more users as well as other devices, per the contactee's contact resolution preferences. A communication system configured to execute the chained parallel forking contact resolution process is also described.