Calling Party Name Provisioning via LIDB Query Bridge
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In the Public Switched Telephone Network (PSTN) and Session Initiation Protocol (SIP) domain, incoming calls often lack calling party name information, which is not provided for calls originating in the PSTN and destined for the SIP domain, leading to incomplete caller identification.
Innovation Solution
A system and method that utilize an application server, open services platform, integrated service control point, and line information database to query and provide calling party name information by sending SIP SUBSCRIBE messages, converting them into Generic Data Interface (GDI) Invoke Application messages, and performing GR-1188 CNAM queries to retrieve and present the calling party's name to the called party's device.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If calling party name information is not queried for PSTN-originating calls, then the system maintains simplicity and compatibility with existing PSTN infrastructure, but caller identification becomes incomplete and the calling name feature cannot be provided
Solution Approach 1:
The patent introduces an intermediary mechanism (the application server querying the LIDB through the Open Services Platform) that bridges the gap between PSTN calls and SIP domain requirements. This intermediary layer retrieves calling name information from the Line Information Database and makes it available to SIP terminals without requiring fundamental changes to PSTN infrastructure, thus resolving the contradiction between obtaining complete caller identification and maintaining system simplicity.
Solution Approach 2:
The system performs preliminary action by querying the Line Information Database before the call is fully processed in the SIP domain. The application server proactively retrieves calling party name information associated with the calling number and makes it available for display to the called party, ensuring that name information is obtained in advance rather than attempting to extract it from the PSTN call itself.
2Loss of information
If calling name queries are performed for all incoming calls, then complete caller identification is achieved, but additional processing time and network resources are consumed
Solution Approach 1:
The system performs the name query as a preliminary action triggered by the incoming call, but the query is executed in parallel with other call setup operations. The application server initiates the LIDB query simultaneously with message routing operations, so that the name retrieval does not sequentially delay the call setup process. This preliminary parallel execution minimizes the time impact while ensuring complete caller identification.
3Ease of operation
If PSTN calls are routed directly to SIP terminals without name lookup, then call routing remains simple and fast, but the calling name feature cannot be provided to subscribers
Solution Approach 1:
The patent introduces an intermediary layer (the application server acting as a bridge between PSTN and SIP domains) that handles the name lookup functionality. This intermediary does not complicate the core call routing path but adds name retrieval capability through separate queries to the LIDB. The intermediary retrieves names and makes them available to SIP terminals without requiring changes to the fundamental PSTN-to-SIP routing mechanism, thus resolving the contradiction between feature availability and routing simplicity.
Data Source
AI summary
A system may receive a telephone call request for a Voice over Internet Protocol (VoIP) user. The telephone call request omits a name of a calling party. The system may further determine if the VoIP user has a calling party name feature enabled and obtaining, when the VoIP user has a calling party name feature enabled, the name of the calling party from a Public Switched Telephone Network (PSTN) based repository of calling party names.