Method and system for retrieving caller information in a network

Abstract

The disclosure provides method (600) for retrieving calling party information in a network (106) The method (600) includes receiving call setup message associated with a calling party and a called party. The method (600) includes determining whether caller information of the calling party is to be retrieved for the call setup message. Further, the method (600) includes generating a query message associated with the calling party. The query message includes one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved. The method (600) further includes transmitting the query message to an external database. Further, the method (600) includes receiving in response to the query message, caller information including at least one of a display name and a spam indication associated with the calling party. The method (600) further includes forwarding the call toward the called party based on the caller information.

Description

METHOD AND SYSTEM FOR RETRIEVING CALLER INFORMATION IN A NETWORKRESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates to a field of telecommunications network. In particular, the present disclosure relates to a method and a system for retrieving caller information in a network.DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] The ‘On-net calls’, as used herein refers to calls in which both a calling party and a called party are subscribers of a same telecommunications service provider network, such that call origination and call termination are handled within the same operator network.

[0005] The ‘off-net calls’, as used herein refers to calls in which a calling party and a called party are associated with different telecommunications service provider networks, such that at least one of call origination or call termination is handled outside a network of a terminating or originating operator.

[0006] The ‘Mobile Number Portability (MNP)’, as used herein refers to a service that allows mobile subscribers to retain their mobile numbers when switching between multiple telecom service providers (TSPs).

[0007] The term MNP+, as used herein refers to an enhanced version of a Mobile Number Portability application. The MNP+ retains traditional routing functionalities and incorporates capabilities for spam detection and Calling Name Presentation (CNAP) services.

[0008] The term ‘Mobile Station International Subscriber Directory Number (MSISDN)’, as used herein refers to a unique number used to identify the mobile subscribers in a telecommunications network.

[0009] The term ‘Converged Telephony Application Server (CTAS)’, as used herein is responsible for managing multimedia telephony services in a network and interacting with the MNP+ to retrieve spam indications and display names for calling parties.

[0010] The term ‘Calling Name Presentation (CNAP)’, as used herein refers to a service that displays a calling party’s name on a called party’s device during an incoming call.

[0011] The term ‘CNAP-DB’, as used herein refers to a Calling Name Presentation Database. The CNAP-DB is a centralized database maintained by telecom service providers to store the mapping of MSISDNs to corresponding display names.

[0012] The term ‘spam indication’, as used herein refers to a flag or parameter that denotes whether a call is potentially spam. Spam indications are mapped to the MSISDNs in the MNP+ application based on patterns identified by analytics systems.

[0013] The term ‘Artificial Intelligence / Machine Learning (AI / ML) unit’ as used herein refers to an analytics unit that processes Call Detail Records (CDRs) to identify spam callers based on various behavioural patterns, such as call rejection rates, call volumes, and call durations of the users.

[0014] The term ‘new MNP functionality parameter’, as used herein refers to a Session Initiation Protocol (SIP) contact Uniform Resource Identifier (URI) parameter used in MNP+ requests. The new MNP functionality parameter is a flag that indicates a sequence of tasks to be executed by the MNP+ (referred as new MNP functionality parameter), such as spam detection, display name retrieval, or both.

[0015] The term ‘MSISDN of the Called Party parameter’ as used herein refers to a SIP contact URI parameter used in the MNP+ requests. The MSISDN of the Called Party parameter contains the MSISDN of the called party along with the country code and is used to identify specific users for spam detection or CNAP services.

[0016] The term ‘ Secured Hyper Text Transfer Protocol Application Programming Interface (HTTPS API)’ as used herein is used by the MNP+ to interact with CNAP-DBs hosted by other TSPs to retrieve display names and associated details.

[0017] The term ‘Session Initiation Protocol (SIP)’, as used herein refers to a signalling protocol used to establish, modify, and terminate communication sessions in the network that is used by the CTAS and MNP+ to exchange information about spam indications and display names during call setups.

[0018] The term ‘cache’, as used herein refers to a temporary storage mechanism used by the MNP+ to store retrieved data, such as display names or spam indications, for a configurable duration to reduce repetitive queries and optimize network performance.

[0019] The term ‘routing number (RN)’, as used herein refers to a unique identifier used in the MNP application to determine the network to which a mobile number belongs.

[0020] The term ‘operator-circle mapping’, as used herein refers to the configuration in the MNP+ that links operators and their respective circles with CNAP-DB details to facilitate efficient querying.

[0021] The term ‘blacklist’, as used herein refers to a list of MSISDNs that are flagged as spam callers. Calls from these numbers are blocked or marked as spam during incoming calls.

[0022] These definitions are in addition to those expressed in the art.BACKGROUND

[0023] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0024] In telecommunication networks, unsolicited and fraudulent calls have become a significant concern for telephone consumers. Many individuals report receiving a growing number of spam calls from unknown numbers, often leading them to avoid answering calls entirely, even when the calls are legitimate. These calls frequently originate from unregistered telemarketers or automated systems known as robocalls, designed to manipulate consumers into financial scams. Fraudulent calls exacerbate the issue by attempting to extract sensitive information such as bank account details or one-time passwords (OTPs), resulting in severe financial losses for telephone consumers.

[0025] Several third-party applications have emerged to address these issues by offering calling party name identification and spam detection. The third-party applications rely on crowdsourced data to provide information about callers, enabling users to make informed decisions about answering calls. However, the third-party applications face significant challenges such as, reliability, limited availability, and non-standardized interfaces. Further, the conventional standard interfaces fail to adequately support Calling Name Presentation (CNAP) services for both on-net (within the same operator) and off-net (across different operators) calls, creating a fragmented user experience and leaves gaps in protection for consumers.

[0026] Therefore, there is a need for an improved technique that can overcome the deficiencies of the conventional solutions to enable the telecommunication networks to provide accurate caller identification, reduce spam, and enhance the overall customer experience.SUMMARY OF THE DISCLOSURE

[0027] In an embodiment, a method for retrieving caller information in a network is described. The method includes receiving a call setup message associated with a calling party and a called party. Further, the method further include determining whether caller information of the calling party is to be retrieved for the call setup message. The method includes generating a query message associated with the calling party. The query message include one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved. Further, the method includes transmitting the query message to an externaldatabase. In response to the query message, the method include receiving caller information including at least one of a display name and a spam indication associated with the calling party. Further, the method include forwarding the call toward the called party based on the caller information.

[0028] In an embodiment, generating the query message, the method includes retrieving at least one identifier associated with the calling party from a P-Asserted-Identity header of the call setup message.

[0029] In another embodiment, the proprietary SIP parameters indicate whether the caller information to be retrieved includes at least one of a spam indication, a display name indication and both the display name and the spam indication.

[0030] In another embodiment, the method includes modifying the one or more proprietary SIP parameters based on the caller information received in response to the query message.

[0031] In another embodiment, the method includes rejecting the call when the caller information indicates that the call is to be blocked.

[0032] In another embodiment, the query message is transmitted by the CTAS at a terminating leg of the call.

[0033] In another exemplary embodiment, a system for retrieving caller information in a network is described. The system includes a Converged Telephony Application Server (CTAS) configured to receive a call setup message associated with a calling party and a called party. The STAS is configured to determine whether caller information of the calling party is to be retrieved for the call setup message. Further, the CTAS is configured to generate a query message associated with the calling party. The query message includes one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved. The CTAS is configured to transmit the query message to an external database. In response to the query message, the CTAS is configured to receive caller information including at least one of a display name and a spam indication associated with the calling party. The CTAS is configured to forward the call toward the called party based on the caller information.

[0034] In yet another embodiment, a computer program product including a non-transitory computer-readable medium including instructions that, when executed by one or more processors, cause the one or more processors to execute a method for retrieving caller information in a network is disclosed. The method includes receiving a call setup message associated with a calling party and a called party. Further, the method further include determining whether caller information of the calling party is to be retrieved for the call setup message. The method includes generating a query message associated with the calling party. The query message include one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved. Further, the method includes transmitting the query message to an external database. In response to the query message, the method include receiving caller information including at least one of a display name and a spam indication associated with the calling party. Further, themethod include forwarding the call toward the called party based on the caller information.OBJECTIVES OF THE PRESENT DISCLOSURE

[0035] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0036] An objective of the present disclosure is to provide a method and a system that retrieves and displays the caller’s name for on-net and off-net calls without reliance on third-party applications, ensuring accuracy and user trust.

[0037] Another objective of the present disclosure is to provide a method and a system that enables dynamic management of blacklisted and grey listed numbers, catering to both circle-specific and global configurations.

[0038] Another objective of the present disclosure is to provide a method and a system that focuses on seamless integration with existing Mobile Number Portability (MNP) systems, minimizing network touchpoints, and reducing call setup delays through caching mechanisms.

[0039] Another objective of the present disclosure is to provide a method and a system that utilizes Session Initiation Protocol (SIP) headers to enable precise spam detection and Calling Name Presentation (CNAP) functionality, ensuring flexibility and scalability within network operations.

[0040] Another objective of the present disclosure is to provide a method and a system that provides accurate display names and spam indications in real-time, resulting in enhancing customer trust and reduce the inconvenience of answering unwanted calls.

[0041] Another objective of the present disclosure is to provide method and a system that ensures secure inter-Telecom Service Provider (TSP) communication through encrypted application programming interfaces (APIs) and a caching mechanism to prevent data breaches and repetitive queries.

[0042] Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.

[0044] FIG. 1 illustrates an exemplary network architecture for retrieving caller information in a network, in accordance with an embodiment of the present disclosure.

[0045] FIG. 2 illustrates an exemplary block diagram of a system configured for retrieving caller information in the network, in accordance with an embodiment of the present disclosure.

[0046] FIG. 3 illustrates an exemplary system architecture configured for retrieving caller information for an off-net call scenario in the network, in accordance with an embodiment of a prior art.

[0047] FIG. 4 illustrates an exemplary system architecture configured for retrieving caller information in the network, in accordance with an embodiment of the present disclosure.

[0048] FIG. 5 illustrates an exemplary process flow for retrieving caller information in the network, in accordance with an embodiment of the present disclosure.

[0049] FIG. 6 illustrates a flow diagram of a method for retrieving caller information in the network, in accordance with an embodiment of the present disclosure.

[0050] FIG. 7 illustrates an exemplary computer system in which or with which the embodiments of the present disclosure may be implemented.

[0051] The foregoing shall be more apparent from the following more detailed description of the disclosure.LIST OF REFERENCE NUMERALS100 - Network architecture102 -User(s)104 -User Equipments (UEs)106 - Network108 - System200 - Block diagram202 - Processor(s)204 - Memory206 -Interface(s)208 - Converged Telephony Application Server (CTAS)- Database- System Architecture- Calling Party- Originating Telecommunications Service Provider (TSP)-l- TSP-1 Calling Name Presentation (CNAP) database- Terminating TSP-2- Mobile Number Portability (MNP) database- TSP-2 CNAP database- B party (Called Party)- System Architecture- Calling Party- Internet Protocol Multimedia Subsystem (IMS) of originating super core - Home Subscriber Server (HSS)- Super core serving terminating user- Serving Call Session Control Function (SCSCF)- Converged Telephony Application Server (CTAS)- Mobile Number Portability (MNP)- Conventional MNP-MNP +- Cached Database- Calling Name Presentation (CNAP) database- Called Party- Flow Diagram- Computer system610 - External Storage Device620 - Bus630 - Main Memory640 - Read Only Memory650 - Mass Storage Device660 - Communication Port670 - ProcessorDETAILED DESCRIPTION

[0052] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0053] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0054] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0055] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structurediagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0056] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0057] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0058] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It should be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it should be understood that other equivalent terms or variationsthereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0059] As used herein, an “electronic device”, or “portable electronic device”, or “user device” or “communication device” or “user equipment” or “device” refers to any electrical, electronic, electromechanical, and computing device. The user device is capable of receiving and / or transmitting one or parameters, performing function / s, communicating with other user devices, and transmitting data to the other user devices. The user equipment may have a processor, a display, a memory, a battery, and an input-means such as a hard keypad and / or a soft keypad. The user equipment may be capable of operating on any radio access technology including but not limited to IP-enabled communication, Zig Bee, Bluetooth, Bluetooth Low Energy, Near Field Communication, Z-Wave, Wi-Fi, Wi-Fi direct, etc. For instance, the user equipment may include, but not limited to, a mobile phone, smartphone, virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general -purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other device as may be obvious to a person skilled in the art for implementation of the features of the present disclosure.

[0060] Further, the user device may also comprise a “processor” or “processing unit” includes processing unit, wherein processor refers to any logic circuitry for processing instructions. The processor may be a general -purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital Signalling Processing (DSP) core, a controller, a microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input / output processing, and / or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor is a hardware processor.

[0061] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment, as well as other embodiments of the disclosure, will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0062] In a Fifth Generation (5G) Voice over New Radio (VONR) or Fourth Generation (4G) Voice over Long-Term Evolution (VOLTE) network, the surge in spam, robocalls, and fraudulent calls has become a significant concern for telecom users, leading to a growing need for reliable caller identification and spam detection services. Current solutions, such as third-party apps rely on crowdsourced data, which is often inaccurate and only available to users who have installed these apps. Moreover, traditional telecommunication networks lack standardized systems fortransmitting caller identity across operators, limiting Calling Name Presentation (CNAP) services to internal (on-net) calls and off-net calls.

[0063] The absence of a unified and secure system for caller identification and spam detection across telecommunication networks poses significant risks to users. Legacy telecom infrastructures fail to support the transfer of caller identification (Display Name) between different telecom service providers (TSPs), resulting in incomplete CNAP services. Additionally, the lack of real-time spam detection mechanisms allows fraudulent and spam calls to reach users, increasing the risk of scams and financial fraud.

[0064] Therefore, there is a need for an enhanced Converged Telephony Application Server (CTAS) application that not only retains its traditional routing functions but also incorporates spam detection and CNAP services, enabling telecommunication networks to provide accurate caller identification, reduce spam, and enhance the overall customer experience.

[0065] To address the above-mentioned issue, the present disclosure provides a method and a system to retrieve calling party information in a network. The present disclosure integrates CNAP and Spam Detection directly into its core network infrastructure using enhanced CTAS and a newly developed enhanced Mobile Number Portability (MNP+) system. For on-net calls, the system leverages its IMS (IP Multimedia Subsystem) architecture, which natively supports CNAP via the “Display Name” field in the Home Subscriber Server (HSS). By provisioning this field for all subscribers, the present disclosure may automatically display the caller's name without additional network changes. For off-net calls, the present disclosure leverages the CTAS and an enhanced Mobile Number Portability (MNP+) architecture. The MNP+ system will establish secure, encrypted HyperText Transfer Protocol (HTTP) Application Programming Interfaces (APIs) with other TSPs for real-time CNAP data exchange. A caching mechanism in MNP+ will store frequently accessed subscriber data, reducing the need for repeated lookups and minimizing call setup delays.

[0066] The present disclosure also integrates spam detection through Artificial Intelligence (Al)-powered analytics system that analyses Call Detail Records (CDRs) to identify and classify spam callers based on calling patterns. Spam numbers are dynamically updated in real-time to the MNP+ system. When a spam call is detected, the CTAS updates Session Initiation Protocol (SIP) headers to display warnings like “Spam Call” or blocks the call entirely, depending on severity of the spam call.

[0067] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings. The various embodiments throughout the disclosure will be explained in more detail with reference to FIG. 1-FIG. 7.

[0068] FIG. 1 illustrates an exemplary network architecture 100 for retrieving caller information in a network 106, in accordance with an embodiment of the present disclosure. As illustrated in FIG. 1, the network architecture 100 may include oneor more User Equipments (UEs) 104-1, 104-2... 104-N associated with one or more users 102-1, 102-2... 102-N in an environment. A person of ordinary skill in the art will understand that one or more users 102-1, 102-2... 102-N may be collectively referred to as the users 102. Similarly, a person of ordinary skill in the art will understand that one or more UEs 104-1, 104-2... 104-N may be collectively referred to as the UE 104, the UEs 104. Although only three UE 104 are depicted in FIG. 1, however, any number of the UE 104 may be included without departing from the scope of the ongoing description.

[0069] In an embodiment, the UE 104 may include smart devices operating in a smart environment, for example, an Internet of Things (loT) system. In such an embodiment, the UE 104 may include, but are not limited to, smartphones, smart watches, smart sensors (e.g., a mechanical, a thermal, an electrical, a magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, a smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users 102 and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE 104 may include, but not limited to, intelligent, multi-sensing, network-connected devices, that may integrate seamlessly with each other and / or with a central server or a cloudcomputing system or any other device that is network-connected.

[0070] Additionally, in some embodiments, the UE 104 may include, but not limited to, a handheld wireless communication device (e.g., a mobile phone, a smartphone, a phablet device, and so on), a wearable computer device (e.g., a headmounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with wireless communication capabilities, and the like. In an embodiment, the UE 104 may include, but are not limited to, any electrical, electronic, electromechanical, or equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. Further, the UE 104 may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user 102 or an entity such as a touchpad, a touch-enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE 104 may not be restricted to the mentioned devices and various other devices may be used.

[0071] In FIG. 1, the UE 104 may communicate with a system 108 through a network 106 for sending or receiving various types of data. In an embodiment, the network 106 may include at least one of a 5G network, a Sixth Generation (6G)network, or the like. The network 106 may enable the UE 104 to communicate with other devices in the network architecture 100 and / or with the system 108. The network 106 may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network 106 may be implemented as, or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like.

[0072] In an embodiment, the network 106 may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 106 may also include, by way of example but not limitation, one or more of the RAN, a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof.

[0073] In an embodiment, the UE 104 is communicatively coupled with the network 106. The network 106 may receive a connection request from the UE 104. The network 106 may send an acknowledgment of the connection request to the UE 104. The UE 104 may transmit a plurality of signals in response to the connection request.

[0074] Although FIG. 1 shows exemplary components of the network architecture 100, in other embodiments, the network architecture 100 may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture 100 may perform functions described as being performed by one or more other components of the network architecture 100.

[0075] FIG. 2 illustrates an exemplary block diagram 200 of the system 108 configured for retrieving caller information in the network 106, in accordance with an embodiment of the disclosure.

[0076] In an embodiment, the system 108 may include one or more processor(s) 202. The one or more processor(s) 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) 202 may be configured to fetch and execute computer-readable instructions stored in a memory 204 of the system 108. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer readable storage medium, which may be fetched and executed to createor share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as a Random-Access Memory (RAM), or a non-volatile memory such as an Erasable Programmable Read Only Memory (EPROM), a flash memory, and the like.

[0077] In an embodiment, the system 108 may include an interface(s) 206. The interface(s) 206 may include a variety of interfaces, for example, interfaces for data input and output devices (VO), storage devices, and the like. The interface(s) 206 may facilitate communication through the system 108. The interface(s) 206 may also provide a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, a processing engine 208 and a database 210.

[0078] In an embodiment, the system 108 may include a Converged Telephony Application Server (CTAS) 208 that may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities. In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the CTAS 208 may be processorexecutable instructions stored on a non-transitory machine-readable storage medium and the hardware for the CTAS 208 may include a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the CTAS 208. In such examples, the system 108 may include the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system 108 and the processing resource. In other examples, the CTAS 208 may be implemented by electronic circuitry. In an aspect, the CTAS 208 may be implemented within the system 108 configured to retrieve caller information such as caller name and spam indication.

[0079] In an embodiment, the CTAS 208 is configured to receive a call setup message associated with a calling party and a called party. A call initiated by the calling party is received by the CTAS 208. The CTAS 208 is a software platform that manages and facilitates various telephony services like voice calls, video conferencing, and messaging across different networks (fixed, mobile, enterprise) simultaneously, allowing service providers to deliver unified communication services through a single system, often utilizing the SIP protocol as the foundation for call signalling. The CTAS 208 acts as a central hub for managing diverse communication needs within the network 106.

[0080] In an embodiment, the CTAS 208 may include a Calling Name Presentation (CNAP) Service to perform MNP queries for calling parties at the terminating leg. The CNAP service may be a run-time configurable service. The CNAP service may be invoked only during the INVITE phase. Once the MNP response is received, the service should be removed from the call leg. The called party is an individual whois initiating a call towards a target individual or group. The details of the calling party may include a Mobile Station International Subscriber Directory Number (MSISDN). The CTAS 208 may derive the MSISDN from a P-Asserted-Identity (PAI) header to formulate a R-URI for the MESSAGE query. Further, if the PAI is a Session Initiation Protocol (SIP), the MSISDN may be situated between and "@" symbols. If the PAI is TEL, the MSISDN may be positioned after the symbol.

[0081] In an embodiment, the CNAP service may be provisioned in the CTAS 208 as a distinct service logic module associated with retrieval of caller information for terminating-leg calls. The CTAS 208 may maintain configuration information for interfacing with an external caller-information platform through a dedicated configuration tuple in a multi -endpoint configuration file. For example, the dedicated configuration tuple may identify one or more CNAP-related endpoints, network addresses, routing preferences, and interface parameters for transmission of caller-information queries from the CTAS 208. In an embodiment, an existing endpoint configuration used for caller-related retrieval may be renamed or repurposed as a CNAP-specific configuration tuple, such as a CNAP MRF tuple, to support caller-information retrieval processing.

[0082] In an embodiment, the CTAS 208 may support endpoint management functions for the CNAP service, including at least one of health checking, alarm generation, endpoint availability monitoring, and primary / secondary pool selection. For example, when multiple CNAP-related endpoints are provisioned, the CTAS 208 may select a primary endpoint for transmitting a caller-information query and may fail over to a secondary endpoint when the primary endpoint is unavailable or does not satisfy a health condition. The CTAS 208 may provide resilient callerinformation retrieval while preserving continuity of call setup processing.

[0083] In an embodiment, the CTAS 208 may associate the CNAP service with a configurable response timer for receipt of a response to a caller-information query. The response timer may be provisioned in milliseconds and may define a maximum waiting period for receiving caller-information data from the external platform. When the response is received within the response timer, the CTAS 208 may continue caller-information enrichment processing. When the response is not received within the response timer, the CTAS 208 may continue call setup without caller-information enrichment, or may apply a predefined fallback treatment according to network policy.

[0084] Further, the CTAS 208 is configured to determine whether caller information of the calling party is to be retrieved for the call setup message from an enhanced Mobile Number Portability (MNP+). The calling party information may include a display name of the calling party, and a spam indication associated with the calling party. Further, the CTAS 208 is configured to add one or more Uniform Resource Identifier (URI) parameters associated with the call in a MESSAGE request separated by a semicolon (;) based on the determination of the calling party information. The one or more URI parameters may be a new MNP functionalityparameter corresponding a flag that may help MNP+ to identify sequence of tasks to be executed, a home circle of the serving CTAS parameter, an operator of the calling party parameter, a home circle of the calling party parameter, a MSISDN of the Called Party parameter. In an embodiment, the URI parameters " operator of the calling party parameter " and " home circle of the calling party parameter home circle of the calling party parameter" may only be included for fixed-line and unidentified numbers.

[0085] In an embodiment, if the MSISDN does not start with a "+", the CTAS 208 may set home circle of the calling party parameter to IV (invalid) and operator of the calling party parameter to IV (invalid). Further, if the MSISDN starts with a “+” and the next two digits are not "91", the CTAS 208 may Set home circle of the calling party parameter to “IV” and operator of the calling party parameter to “IV”. If the next two digits are "91” and the total length of digits is greater than 12 but not equal to 15, the CTAS 208 may set home circle of the calling party parameter to “IV” and operator of the calling party parameter to “IV”. Further, if the total length of digits is 15, the CTAS 208 may perform a circle-config check to determine if it's an M2M range. If it's an M2M range, set the M2M flag, otherwise, set home circle of the calling party parameter to “IV” and operator of the calling party parameter to “IV”. Further, if the total length is less than 12, the processing engine 208 set home circle of the calling party parameter to “IV” and operator of the calling party parameter to “IV”. Finally, if the first three characters are "+91" and the total length is 12, the CTAS 208 may perform a circle-config check to determine the operator’s name, operator type, etc., and if number is not found in circle-config, set home circle of the calling party parameter to “IV” and operator of the calling party parameter to “IV”. In an embodiment, the “IV” value in “home circle of the calling party parameter” and “operator of the calling party parameter” may help MNP+ to avoid internal MNP database query and displaying wrong “Display Name” in case of some erroneous condition (such as caller ID (CLI) spoofing cases). In an embodiment, the CTAS 208 may not invoke MNP+ service when calling party is one of Machine-To-Machine (M2M) number, number starting with +91140, and numbers starting from +91160. To cater existing CNAP service providing by originating network, the CTAS 208 may request MNP+ to perform Spam check. In an embodiment, the CTAS 208 may provide separate flag to MNP+ to control “Display Name” retrieval mechanism. The block spam lists may be circle specific. MNP+ will use the home circle identifier to check if a number is on a circle-specific block list in addition to the default list. MNP+ may not differentiate between fixed-line and mobile numbers. The " operator of the calling party parameter " and "home circle of the calling party parameter" parameters will help MNP+ to identify fixed-line numbers and query the appropriate CNAP-DB for name retrieval.

[0086] Further, to enhance the granularity of Spam Indication, the CTAS 208 may add a URI parameter, "MSISDN of the Called Party parameter" to all MNP+ requests, regardless of the "new MNP functionality parameter" value. The “MSISDN of the Called Party parameter” parameter may contain the Called PartyMSISDN with the country code. In an embodiment, the MNP+ may be configured to enable Spam functionality for all incoming requests or a specific set of called party users. If enabled for specific users, MNP+ may inspect the MSISDN of the Called Party parameter' in the contact header. A match may trigger a block or spam indication for the specified called parties. If disabled, the parameter may get ignored.

[0087] In an embodiment, the CTAS 208 is configured to generate a query message associated with the calling party. The query message includes one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved. The CTAS 208 may retrieve at least one identifier associated with the calling party from a P-Asserted-Identity header of the call setup message. The proprietary SIP parameters indicate whether the caller information to be retrieved includes at least one of a spam indication, a display name indication and both the display name and the spam indication. Further, the CTAS 208 is configured to transmit the query message to an external database. The query message is transmitted by the CTAS at a terminating leg of the call.

[0088] In an embodiment, the proprietary SIP parameters included in the query message may include a task identifier parameter configured to indicate a sequence of operations to be performed for a given call. For example, the task identifier parameter may indicate a first query mode corresponding to retrieval of spam indication, a second query mode corresponding to retrieval of display name, and a third query mode corresponding to retrieval of both display name and spam indication.

[0089] In an embodiment, when the CTAS 208 is configured to retrieve only spam indication for a call, the CTAS 208 may generate the query message with the task identifier parameter set to a first value corresponding to spam-only retrieval. In such embodiment, the CTAS 208 may include a serving-circle-related parameter in the query message to enable circle-specific spam determination. For example, the task identifier parameter may be set to a value corresponding to spam detection and the serving-circle-related parameter may be included to facilitate use of circle-specific spam lists by the external platform.

[0090] In an embodiment, when the CTAS 208 is configured to retrieve only display name for a call, the CTAS 208 may generate the query message with the task identifier parameter set to a second value corresponding to display-name retrieval. In such embodiment, the CTAS 208 may refrain from invoking callerinformation retrieval for unidentified calls, invalid calling line identification, or calls already carrying display-name information from another service. For example, where an on-net fixed-line service or another originating-network service has already provided display-name information, the CTAS 208 may request retrieval of spam indication without duplicating display-name retrieval.

[0091] In an embodiment, when the CTAS 208 is configured to retrieve both display name and spam indication, the CTAS 208 may generate the query message with the task identifier parameter set to a third value corresponding to combinedretrieval. However, for unidentified calls, invalid calling line identification, or calls already associated with display-name information, the CTAS 208 may selectively downgrade the query message to a spam-only retrieval mode, allowing the CTAS 208 to preserve the benefits of spam marking while avoiding unnecessary displayname retrieval operations.

[0092] In an embodiment, the query message may include a called-party identifier parameter irrespective of the task identifier value. The called-party identifier parameter may carry the MSISDN of the called party with country code and may enable called-party-specific spam treatment. For example, the external platform may apply spam indication or call blocking only for a predefined set of called parties for which a spam service is enabled, while ignoring the called-party identifier parameter when such service is disabled.

[0093] In an embodiment, the external platform may maintain one or more spam lists including at least one of a warning-oriented spam list and a block-spam list. The warning-oriented spam list may be used to return a spam indication while allowing the call to proceed, and the block-spam list may be used to return a block indication for preventing call delivery. In certain embodiments, such lists may be circle-specific, such that spam treatment may vary according to a circle identifier associated with the calling party, the serving CTAS, or both.

[0094] In an embodiment, when a spam indication corresponding to a warning condition is received, the CTAS 208 may update display information to present a spam -related label to the called party during call establishment. For example, the CTAS 208 may replace or augment a display -name field with a label such as “Spam Call” or another spam-indicative text and may include the updated information in one or more outgoing SIP requests toward the called party. When a block indication is received, the CTAS 208 may reject the call without forwarding the call to the called party.

[0095] To retrieve the spam indication associated with the calling party, the CTAS 208 may add home circle of the serving CTAS parameter in the message request with value of “x new MNP functionality parameter” as “1”. Further, to retrieve the display name of the calling party, the CTAS 208 add “new MNP functionality parameter” equals to “2”. In this case, the CTAS 208 may not invoke MNP+ service for unidentified calls (ISD and invalid CLI) and calls with “Display Name”. Further, to retrieve both the display name of the calling party and the spam indication associated with the calling party, the CTAS 208 may add “home circle of the serving CTAS parameter” parameter and value of “new MNP functionality parameter” as “3”, except for unidentified calls (ISD and invalid CLI) and calls with “Display Name”. For the ISD and the invalid CLI calls the value of “new MNP functionality parameter” will be “1”.

[0096] In an embodiment, a call originating from a calling party is received towards a called party. In an embodiment, a call initiated by the calling party is received by the CTAS to determine if the CNAP service is enabled or disabled for the originated call.

[0097] In response to the query message, the CTAS 208 is configured to receive caller information including at least one of a display name and a spam indication associated with the calling party. Further, the CTAS 208 is configured to forward the call toward the called party based on the caller information.

[0098] In an embodiment, the CTAS 208 is configured to determine at least one condition associated with the received call. In an embodiment, upon determining that CNAP service is disabled (CNAP=false), the received call from the calling party is forwarded to the called party without the caller information. The called party is an individual who is receiving the call from the calling party. Further, when the CNAP service is enabled (CNAP=true), the CTAS 208 may determine whether the display name of the calling party and the spam indication associated with the calling party is needed to be retrieved from the MNP+.

[0099] In an embodiment, the CTAS 208 may determine that a flag associated with the display name (DN) of the calling party is enabled and a flag associated with the spam indication (Spam) is disabled (DN= true and Spam= false). The CTAS 208 may transmit a message request to the MNP+ to retrieve the display name of the calling party. The message request may include a URI parameter “new MNP functionality parameter” equals to 2. The CTAS 208 may not invoke MNP+ service for unidentified calls International Subscriber Dialling (ISD) and invalid Calling Line Identification (CLI) and calls with “Display Name”. The CTAS 208 may forward the call to called party with only display name.

[0100] In an embodiment, the CTAS 208 may determine that the flag associated with the display name of the calling party and the flag associated with the spam indication are enabled (DN= true and Spam= true). The CTAS 208 may transmit a message request to the MNP+ to retrieve the display name and the spam indication of the calling party. The CTAS 208 may add URI parameter “home circle of the serving CTAS parameter” in the message request and may include “new MNP functionality parameter” equals to 3 except for unidentified calls (ISD and invalid CLI) and calls with “Display Name”. For these two cases value of “new MNP functionality parameter” will be “1”. The CTAS 208 may forward the call to called party with both display name and the spam indication. In an embodiment, the CTAS 208 may query a database to retrieve at least one attribute (display name and the spam indication) associated with the received call. The CTAS 208 may query the MNP+ based on the message request. Further, the MNP+ may respond with both the display name and the spam indication of the calling party based on the one or more URI parameters. In an embodiment, the at least one retrieved attribute (display name and the spam indication) is transmitted to the called party.

[0101] In an embodiment, the CTAS 208 may determine that the flag associated with the display name of the calling party is disabled and a flag associated with the spam indication is enabled (DN= false and Spam= true). The CTAS 208 may transmit a message request to the MNP+ to retrieve the spam indication of the calling party. The CTAS 208 may add “home circle of the serving CTAS” parameter and the value of “new MNP functionality parameter” equals to 1 in thetransmitted message request. The CTAS 208 may forward the call to called party with only the spam indication. Further, the MNP+ may respond with the spam indication of the calling party based on the one or more URI parameters.

[0102] In an embodiment, the CTAS 208 may modify the one or more proprietary SIP parameters based on the caller information received in response to the query message. In some embodiments, the CTAS 208 may reject the call when the caller information indicates that the call is to be blocked.

[0103] FIG. 3 illustrates an exemplary system architecture 300 configured for retrieving caller information for an off-net call scenario in the network 106, in accordance with an embodiment of a prior art. The off-net call scenario is where the calls between a calling party and a called party belong to different network operators. Further, in the on-net call scenario, the calls between a calling party and a called party belong to the same network operator.

[0104] Referring to FIG. 3, the system architecture 300 depicts a calling party A 302 initiating a call via an originating telecom service provider TSP-1 304. The TSP-1 304 maintains a CNAP database 306 containing subscriber name information for its own customers. When the call originates from a TSP-1 subscriber and is destined for a terminating telecom service provider (TSP-2) 308, the call flow involves multiple interactions for accurate CNAP data retrieval.

[0105] The terminating TSP 308 initially performs a Mobile Number Portability (MNP) database 310 dip to determine whether the calling party belongs to the originating TSP-1 304 or any other operator. If the MNP dip reveals that the originating and terminating TSPs are the same, the terminating TSP performs a CNAP lookup within its own CNAP database (e.g., TSP-2 CNAP database 312), retrieves the calling party's display name, and presents it to the called party B 314. The lookup is performed from originating TSP in case calling party is not own subscriber. The lookup is performed from own CNAP database in case calling party is own subscriber. The CNAP database may store the CNAP data and the MNP database may store the MNP data.

[0106] However, in the case of off-net calls where the originating TSP differs from the terminating TSP, the terminating TSP queries the originating TSP CNAP database (e.g., TSP-1 CNAP database 306) over a secure and encrypted channel using the HTTP API. Upon receiving the requested CNAP data, the terminating TSP 308 combines it with a Calling Line Identification CLI (CLI+CNAP) and delivers it to the called party 314.

[0107] The system architecture 300 addresses the limitations of legacy networks that prevent the transmission of “Display Names” between different TSPs. By enabling CNAP for off-net calls, the solution facilitates interworking across TSPs. Further, the system architecture 300 introduces additional latency and network load due to new transactions such as MNP query and the HTTPS-based transactions required to fetch subscriber names from external CNAP databases.

[0108] FIG. 4 illustrates an exemplary system architecture 400 configured for retrieving the caller information in the network 106, in accordance with anembodiment of the present disclosure. The present system architecture 400 overcomes the limitations of the system architecture 300.

[0109] In the on-net call scenario, Internet Protocol Multimedia Subsystem (IMS) network architecture 404 inherently supports the CNAP service, which has an option of including a ‘Display Name’ parameter in each subscriber’s profile. The customer's name, as provided in a Customer Application Form (CAF), can be utilized as the ‘Display Name’ parameter and provisioned in a Home Subscriber Server (HSS) 406 for each user.

[0110] During IMS 404 registration, the ‘Display Name’ is downloaded by the IMS 404 network and appended to Session Initiation Protocol (SIP) requests during calls. The ‘Display Name’ is then displayed on the called party’s handset.[OHl] In an embodiment, by provisioning the ‘Display Name’ for the end users in HSS 406, CNAP may be automatically displayed to each end-user on every on-net call, with no additional changes to the network configuration and zero capacity augmentation without compromising on call setup delay.

[0112] For the off-net call scenario, to minimize the challenges of capacity augmentation and call setup delays, the conventional MNP 416 is enhanced to MNP+ 418. The MNP+ 418 may be deployed in super-core locations.

[0113] Further, the CTAS 412 may retrieve the display name and a spam indication from a cached database 420 of the enhanced MNP+ 418. The MNP+ 418 establish secured HTTP connection with other TSPs, reducing number of touchpoints with other TSPs, the core network stay isolated from other operator networks.

[0114] In an embodiment, to minimize repetitive database queries and improve performance, the MNP+ 418 employs a caching mechanism that retains mappings for a predefined duration, thus significantly reducing call setup delays.

[0115] In an embodiment, the MNP+ 418 interacts with CNAP databases (CNAP-DB) 422 maintained (hosted) by TSPs, which store mappings of MSISDNs to customer display names.

[0116] In an embodiment, the TSPs collaborate to standardize, secure and encrypted HTTP API for CNAP lookups, ensuring seamless and confidential data exchange.

[0117] In an embodiment, the CTAS application 412 is enhanced to introduce an MNP query at the terminating leg of the off-net calls. The queries are directed to dedicated MNP+ endpoints, which return the corresponding display names retrieved from the CNAP-DB. The CTAS 412 may append the “Display Name” information in SIP requests during calls. The display name is then displayed on the called party’s handset.

[0118] In an embodiment, the MNP+ 418, integrated into the MNP 414 architecture, is specifically designed to retrieve customer names from the CNAP-DB 422 and provide the information (customer names) to CTAS 412 in response to incoming queries. The microservice is equipped with point-to-point Point of Interconnection (POI) connectivity to CNAP-DBs 422 hosted by other TSPs, ensuring real-time and accurate data retrieval.

[0119] Referring to FIG. 4, the system architecture 400 includes a calling party 402 originating a call from the IMS 404 of the originating super core, which interacts with the HSS 406 to authenticate and process the call. The call is directed to the super core 408 serving the terminating user (called party 424), which includes key functional modules for managing CNAP and spam detection.

[0120] In an embodiment, the super core 408 contains an enhanced MNP module 418, referred to as MNP+, which includes a cached database 420 for storing frequently accessed CNAP data from other TSPs. The enhancement over the conventional MNP 416 reduces latency and network load by minimizing the number of HTTPS transactions required for off-net CNAP lookups. When an off-net call is received, the super core 408 performs an MNP dip to identify the originating TSP and determines whether the CNAP data is available in the cached database. If the data is unavailable, the system 400 queries the CNAP database 422 hosted by the originating TSP over secure channels using the HTTP API to fetch the required CNAP data.

[0121] The CNAP data, along with the CLI, is processed by the Call Session Control Function (SCSCF) 410 and the CTAS (MMTEL telephony application servers) 412 to ensure accurate CNAP presentation to the called party 424. By utilizing the cached database 420 and optimized CNAP lookup mechanisms, the system architecture 400 significantly improves the efficiency and reliability of CNAP services for off-net call scenarios.

[0122] In an embodiment, the increasing threat of spam calls necessitates network flexibility to either block these calls or alert users to potential spam. Therefore, to protect users from spam calls, the system architecture 400 further incorporates intelligent spam detection capabilities within the MNP+ 418 and CTAS 412. Intelligent spam detection analyses call patterns, CLI data, and historical call records to detect and flag potential spam calls. Upon identifying a spam call, the system 400 may notify the called party 424 with a warning label or reject the call entirely based on predefined spam management policies.

[0123] To detect spam calls, intelligent spam detection may include an Artificial Intelligence / Machine Learning (AI / ML) unit and a network node enhancement unit. The AI / ML unit may utilize AI / ML algorithms to identify a list of spammers by analysing Call Detail Records (CDRs). The enhancements provided by the network node enhancement unit allow network nodes to act on the spammer list in real time, marking calls as spam.

[0124] In an embodiment, the AI / ML unit may be integrated with CTAS nodes to retrieve call records for all calls within the network. The AI / ML unit may analyse the CDRs to identify traffic patterns associated with each user. Using the AI / ML algorithms, the system may learn individual calling behaviours and classify users as spammers.

[0125] The analysis is based on the combination of following criteria:• Calling party numbers whose calls are repeatedly rejected by multipleunique called parties.• Calling party numbers where the volume of Mobile Originated (MO) calls significantly exceeds the number of Mobile Terminated (MT) calls.• Calling party numbers whose calls typically have very short durations. • Calling party numbers with a low call success rate.• At periodic intervals, the AI / ML intelligence will run this analysis and generate a list of identified spam users for further action.

[0126] In an embodiment, the CTAS 412 may be enhanced to query MNP+ 418 for all terminating-leg calls related to the calling party. If the calling party is listed in the spam database, MNP+ 418 may respond to the query with a spam indication. Upon receiving the spam indication, the CTAS 412 may update the "Display Name" to "Spam Calls," which may be displayed on the called party's handset when receiving the call. The enhanced CTAS 412 may be represented as in table 1.

[0127] In an embodiment, the CTAS 412 retain the flexibility to proceed with calls without furnishing the CNAP service under the following conditions:• MNP+ query times out• MNP+ provides error response• Fails to decode MNP+ response

[0128] In an embodiment, the CTAS 412 expects contact-URI parameter block and spam indication along with “Display Name” in MNP response (302 Moved Temporarily). The " blocking and spam indication parameter " parameter may contain blocking and spam indication values. Any letter from "A" to "Z" except "F," and "B" is allowed. Further, the CTAS 412 must perform following actions:• The CTAS 412 must have a configuration file mapping “blocking and spam indication parameter” values with “Additional Display Info”. • For “blocking and spam indication parameter” value “Y”, CTAS must block the calls.

[0129] In an embodiment, the CTAS 412 may store response-related information associated with a caller-information query in a Call Detail Record (CDR) for both successful and failed query outcomes, while excluding display-name content from the stored CDR information. For example, the CTAS 412 may store one or more of response status, spam indication, operator determination, circle determination, or processing outcome in a reserved field of an existing CDR structure. Where a predefined CDR field is available for caller-information logging, the CTAS 412 may use such field for recording CNAP-related response information.

[0130] In an embodiment, the CTAS 412 may maintain one or more dedicated counters for the CNAP service to provide operational visibility regarding callerinformation retrieval. The dedicated counters may include at least one of a successful-query counter, a failed-query counter, a display-name retrieval counter, a spam-indication counter, a block-indication counter, and one or more call-setup timing metrics including maximum setup time, minimum setup time, and average setup time associated with caller-information retrieval processing.

[0131] In an embodiment, when the caller-information response indicates that a call is to be blocked, the CTAS 412 may trigger a subscriber-notification action in addition to rejecting the call. For example, the CTAS 412 may leverage an existing probe, monitoring, or service-data-recording capability to cause transmission of a notification message, such as a Short Message Service (SMS) notification, to the called party indicating that a potentially fraudulent or spam call was blocked by the network.

[0132] In an embodiment, to avoid repeated insertion of additional display information when a call is forwarded across network regions or between multiple CTAS nodes, the CTAS 412 may add a control header in an outgoing SIP request after caller-information enrichment. A downstream CTAS 412 receiving the control header may determine that caller-information enrichment has already been performed and may suppress repeated addition of the same di splay -related information, while still retaining the ability to apply other call -treatment functions, including blocking treatment, according to policy.

[0133] In an embodiment, the CTAS 412 may modify display -related information in both a From header and a P-Asserted-Identity header of outgoing SIP requests after receiving caller information from the external platform. Such modification may include insertion of a retrieved display name, insertion of spam-indicative text, replacement of an existing display field, or concatenation of multiple display-related items according to a predefined formatting rule.

[0134] In an embodiment, if both "Display Name" and "Additional Display Info" are identified by CTAS 412, the outgoing "From" and "PAI" headers to the called party will be modified to "(Additional Display Info) Display Name". In an embodiment, the length of Final Display Name (Display Name along with Additional Display Info) should be limited to 80 characters. Further, the CTAS 412 modify outgoing requests’ Display Name with only “Additional Display Info”, if MNP+ 418 provides “blocking and spam indication parameter” indication with value other than “Y” but fails to return any “Display Name”. Final Display Name of outgoing requests should be - “Additional Display Info”.

[0135] In an embodiment, the CTAS 412 may employ a distinct configuration file to provide "Display Name" for calling party numbers commencing with "+91140" or "+9160". If a number aligns with a configuration within this file, the CTAS 412 bypass invoking the MNP+ query.

[0136] In an embodiment, the CTAS 412 keep the MNP+ 4128 response in both success and fail Call Detail Records (CDR) without the “Display Name” information. For fixed line numbers, the CTAS 412 determine Calling Party Operator Name and Calling Party Circle on its own before MNP+ query. If any field cannot be determined, it is left blank, and any reserved field of existing CDR structure may be used.

[0137] In an embodiment, the CTAS 412 modifies “Display Name” of both “PAI” and “From” headers of all outgoing requests. Further, the CTAS 412 may maintainseparate counter for CNAP services, to provide more visibility to Network Operation and Performance Team.

[0138] In an embodiment, the CTAS 412 have the flexibility to send SMS notification to called party to help intimate subscriber about incoming call blocked by network.

[0139] In an embodiment, to avoid repeated addition of “Additional Display Info” and cater forwarding of call from one circle to another CTAS will add a header in the outgoing request. In an embodiment, the CTAS 412 may continue to provide CLIR and CLIR-override functionality.

[0140] In an embodiment, the CTAS should not treat the CNAP / MNP+ interface as an ad hoc extension of generic signalling logic. Instead, CTAS should maintain a separate tuple in the multi-MRFC configuration file specifically for MNP+ details. Further, the existing “CRN_MRF” tuple may be renamed to “CNAP_MRF” to satisfy this requirement, meaning the CNAP query path is expected to be represented as a dedicated configurable endpoint group within CTAS, so that callerinformation retrieval toward MNP+ is handled as a separately identified interface rather than being mixed with other CTAS endpoint definitions.

[0141] Further, the CTAS provide health check, alarm, and primary / secondary pool configuration features for CNAP, like other MRFC endpoints, indicating that once the CNAP MRF tuple is defined, CTAS should operationally manage it the same way it manages other critical endpoint pools: by monitoring endpoint availability, raising alarms when the interface becomes unhealthy or unreachable, and supporting primary / secondary pool behaviour so that CNAP requests may be directed to a primary endpoint set and shifted to a secondary set when needed. The CNAP is treated as a production-grade managed interface, not merely as a logical feature invocation.

[0142] In an embodiment, the CTAS may maintain a timer parameter, provisioned in milliseconds, to control timeout handling between the CTAS and the CNAP-specific MNP+ interface. When a response is not received within the timer period, when an error response is received, or when a response cannot be decoded, the CTAS may proceed with call processing without furnishing CNAP information.

[0143] FIG. 5 illustrates an exemplary process flow 500 for retrieving caller information in the network 106, in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1, 2, and 4.

[0144] At step 502, a call initiated by the calling party 402 is received by the Converged Telephony Application Server (CTAS) 412. The CTAS 412 is a software platform that manages and facilitates various telephony services like voice calls, video conferencing, and messaging across different networks (fixed, mobile, enterprise) simultaneously, allowing service providers to deliver unified communication services through a single system, often utilizing the SIP protocol as the foundation for call signalling. The CTAS 412 acts as a central hub for managing diverse communication needs within the network 106. Further, the CTAS 412 may determine if the CNAP service is enabled or disabled for the initiated call.

[0145] At step 504, upon determining that CNAP service is disabled (CNAP=false), the received call from the calling party is forwarded to the called party without the caller information. The called party is an individual who is receiving the call from the calling party. Further, when it is determined that the CNAP service is enabled (CNAP=true), the CTAS 412 may determine whether the display name of the calling party and the spam indication associated with the calling party is needed to be retrieved from the MNP +.

[0146] At step 506, the CTAS 412 may determine that a flag associated with the display name of the calling party is enabled and a flag associated with the spam indication is disabled (DN= true and Spam= false).

[0147] At step 508, the CTAS 412 may transmit a message request to the MNP+ to retrieve the display name of the calling party. The message request may include a URI parameter “new MNP functionality parameter” equals to 2. The CTAS 412 may not invoke MNP+ service for unidentified calls International Subscriber Dialling (ISD) and invalid Calling Line Identification (CLI) and calls with “Display Name”.

[0148] At step 510, the CTAS 412 may forward the call to called party 424 with only display name.

[0149] At step 512, the CTAS 412 may determine that the flag associated with the display name of the calling party and the flag associated with the spam indication are enabled (DN= true and Spam= true).

[0150] At step 514, the CTAS 412 may transmit a message request to the MNP+ to retrieve the display name and the spam indication of the calling party 402. The CTAS 412 may add URI parameter “home circle of the serving CTAS parameter” in the message request and may include “new MNP functionality parameter” equals to 3 except for unidentified calls (ISD and invalid CLI) and calls with “Display Name”. For these two cases value of “new MNP functionality parameter” will be it ”

[0151] At step 516, the CTAS 412 may forward the call to called party 424 with both display name and the spam indication. The CTAS 412 may query the cached database 420 of the MNP+ 418 based on the message request. Further, the MNP+ 418 may respond with both the display name and the spam indication of the calling party 402 based on the one or more URI parameters.

[0152] At step 518, the CTAS 412 may determine that the flag associated with the display name of the calling party is disabled and a flag associated with the spam indication is enabled (DN= false and Spam= true).

[0153] At step 520, the CTAS 412 may transmit a message request to the MNP+ to retrieve the spam indication of the calling party 402. The CTAS will add “home circle of the serving CTAS” parameter and the value of “new MNP functionality parameter” equals to 1 in the transmitted message request.

[0154] At step 522, the CTAS 412 may forward the call to called party 424 with only the spam indication. Further, the MNP+ 418 may respond with the spam indication of the calling party 402 based on the one or more URI parameters.

[0155] In an exemplary embodiment, Alice, receives an incoming call from a number she doesn’t recognize. Alice’s mobile network is powered by the CTAS, which has been enhanced with CNAP and spam detection services. Further, if the CNAP is disabled, the CTAS checks whether CNAP is enabled for Alice’s account. If it’s not enabled, the call is forwarded to Alice without displaying Bob’s name or spam status. In this scenario, Alice sees only the number on her screen, leaving her uncertain about whether to answer the call.

[0156] Further, if the CNAP is enabled for Display Name, the CTAS retrieves Bob’s display name from the MNP+ database, using a specific URI parameter (“new MNP functionality parameter =2”). The CTAS ensures Bob’s name is displayed on Alice’s screen when the call rings. Alice may now recognize the caller and confidently decide to answer. Further, if the CNAP is enabled for Display Name and Spam Indication, when Bob calls Alice, the CTAS identifies that both the display name and spam indication flags are enabled. The CTAS then queries the MNP+ database with the parameters “home circle of the serving CTAS parameter” and the value of the parameter new MNP functionality parameter =3. The CTAS retrieves Bob’s name and spam status and forwards this information along with the call to Alice. Alice sees a warning like “(Potential Spam) Bob” on her screen and may decide to ignore the call.

[0157] Further, if the CNAP is enabled for Spam Indication only, another unknown caller, Charlie, initiates a call to Alice. Alice’s CNAP is configured only to check for spam. The CTAS queries the MNP+ database using the parameter “home circle of the serving CTAS parameter” and the value of the parameter new MNP functionality parameter =1 and retrieves spam-related information for Charlie’s number. The call is forwarded to Alice with a warning label like “Potential Spam” displayed on her phone.

[0158] Thus, the present disclosure discloses a method for retrieval of display name (i.e., Calling Name Presentation (CNAP)) and spam indication by enhanced Converged Telephony Application Server (CTAS) from a centralized Mobile Number Portability (MNP) database using the SIP protocol. The CTAS will perform MNP database query either for “Spam Detection”, or “Display Name” or both for “Display Name and Spam Detection”. When CTAS is enabled for “Spam Detection”, CTAS will add URI parameter “home circle of the serving CTAS parameter” to the contact header (e.g., Contact: <sip:abc; home circle of the serving CTAS parameter =HR; operator of the calling party parameter =AT;home circle of the calling party param eter=MH; new MNP functionality parameter =3; MSISDN of the Called Party parameter =xyz>) in the message of the MNP+ request and value of “new MNP functionality parameter” (i.e., a flag which will help MNP+ to identify sequence of tasks to be executed) will be “1”. Further, the contact URI parameters operator of the calling party parameter and home circle of the calling party parameter (denotes home circle of the calling party) will only be included for fixed-line and unidentified numbers. When CTAS is enabled for “Display Name”, CTAS will add “new MNP functionality parameter” equals to “2”. In this caseCTAS will not invoke MNP+ service for unidentified calls (ISD and invalid CLI) and calls with “Display Name”. When CTAS is enabled for both “Display Name” and “Spam Detection”, CTAS will add “home circle of the serving CTAS parameter” parameter and value of “new MNP functionality parameter” will be “3”, except for unidentified calls (ISD and invalid CLI) and calls with “Display Name”. For these two cases value of new MNP functionality parameter will be “1”. Based on the MNP+ database response, CTAS will forward the call to the called party with either of the “Display Name”, or both “Display Name and Spam Detection” or only with “spam indication”.

[0159] FIG. 6 illustrates a flow diagram of a method 600 for retrieving caller information in the network 106, in accordance with an embodiment of the present disclosure. FIG. 6 is explained in conjunction with FIGS. 1, 2, 3, 4 and 5.

[0160] At step 602, a call setup message associated with a calling party and a called party is received by the CTAS. The call setup message may include a Session Initiation Protocol (SIP) INVITE message received at a terminating side of the network for establishing a call toward the called party. The call setup message may include one or more signalling headers carrying calling party information, called party information, routing information, and service-related information. For example, the CTAS may receive the SIP INVITE message from an IP Multimedia Subsystem (IMS) entity or another network node handling call control, and may identify, from the received call setup message, that caller information retrieval processing is to be performed for the incoming call.

[0161] At step 604, whether caller information of the calling party is to be retrieved for the call setup message is determined. The determination may be based on one or more service conditions, subscription settings, call treatment rules, or signalling attributes associated with the call. For example, the CTAS may determine whether a caller information service is enabled for the called party, whether the call belongs to a category for which caller identification enrichment is permitted, and whether the call has already undergone caller information retrieval processing at an earlier stage. Based on such determination, the CTAS may decide whether to initiate a caller information query for the call setup message.

[0162] At step 606, a query message associated with the calling party is generated. The query message includes one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved. At least one identifier associated with the calling party is retrieved from a P-Asserted-Identity header of the call setup message. For example, the CTAS may extract a calling party number, such as a mobile number or another subscriber identifier, from the PAI header and may use the extracted identifier for preparing the query message. The proprietary SIP parameters indicate whether the caller information to be retrieved includes at least one of a spam indication, a display name indication and both the display name and the spam indication. In an example, the proprietary SIP parameters may specify whether the query is for retrieval of only a spam indication, only a display name, or both the display name and the spam indication. Thus, theCTAS may generate the query message in a manner that allows a downstream external database to interpret both the identity of the calling party and the type of caller information requested for the call.

[0163] At step 608, the query message is transmitted to an external database. The external database may be any centralized caller-information repository, network database, or service platform configured to store and provide caller-related information for incoming calls. For example, after generating the query message with the calling party identifier and the proprietary SIP parameters, the CTAS may send the query message over a signalling interface toward the external database so that the external database may perform a lookup corresponding to the calling party. The CTAS initiates retrieval of caller information from an external source without requiring such caller information to be locally maintained at the CTAS.

[0164] At step 610, in response to the query message, caller information including at least one of a display name and a spam indication associated with the calling party is received. For example, the external database may return a response identifying a verified or stored display name corresponding to the calling party number, a spam category or spam warning associated with the calling party, or both. The CTAS may parse the response and determine whether the caller information is available, partially available, or unavailable. In certain examples, the CTAS may receive only the display name, only the spam indication, or a combination thereof, depending on the type of retrieval requested and the information available in the external database.

[0165] At step 612, the call is forwarded toward the called party based on the caller information. For example, when the response includes caller information, the CTAS may update one or more outgoing signalling headers so that the called party device receives enriched caller presentation information during call establishment. In one example, the CTAS may insert or modify di splay -related information in a From header or a P-Asserted-Identity header so that the called party is presented with a display name and / or a spam indication corresponding to the calling party. The CTAS may continue call setup toward the called party using the modified call signalling.

[0166] In an embodiment, the one or more proprietary SIP parameters are modified based on the caller information received in response to the query message. Further, the call may be rejected when the caller information indicates that the call is to be blocked. In an exemplary embodiment, when the caller information indicates a nonblocking condition, the CTAS may allow the call to proceed toward the called party after incorporating the caller information into the outgoing call signalling. For example, if the received caller information includes a display name and a warningtype spam indication, the CTAS may forward the call with modified signalling that enables presentation of such information at the terminating side, allowing the called party to receive enhanced caller context before answering the call.

[0167] In another exemplary embodiment, when the caller information indicates that the call is to be blocked, the CTAS may reject the call instead of forwardingthe call toward the called party. For example, if the external database response identifies the calling party as belonging to a blocked spam category, the CTAS may terminate call setup and generate a rejection response. In such an embodiment, the CTAS may prevent delivery of the call to the called party while still using the retrieved caller information as the basis for call treatment.

[0168] In another exemplary embodiment, the one or more proprietary SIP parameters and / or one or more SIP headers associated with the call may be modified based on the caller information received in response to the query message. For example, the CTAS may update signalling fields to include the retrieved display name, a spam label, or another caller-information indicator prior to forwarding the call. Such modification enables dynamic enrichment of call signalling during call setup and allows caller-information presentation and spam-related call treatment to be performed in real time within the network.

[0169] FIG. 7 illustrates an exemplary computer system 700 in which or with which embodiments of the present disclosure may be implemented. As shown in FIG. 7, the computer system 700 may include an external storage device 710, a bus 720, a main memory 730, a read-only memory 740, a mass storage device 750, communication port(s) 760, and a processor 770. A person skilled in the art will appreciate that the computer system 700 may include more than one processor and communication ports. The processor 770 may include various modules associated with embodiments of the present disclosure. The communication port(s) 760 may be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 760 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 700 connects.

[0170] The main memory 730 may be a Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 740 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor 770. The mass storage device 750 may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage device 750 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.

[0171] The bus 720 communicatively couples the processor 770 with the other memory, storage, and communication blocks. The bus 720 may be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCLX) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connectingexpansion cards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 770 to the computer system 700.

[0172] Optionally, operator and administrative interfaces, e.g. a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus 720 to support direct operator interaction with the computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 760. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 700 limit the scope of the present disclosure.

[0173] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

[0174] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0175] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.ADVANTAGES OF THE PRESENT DISCLOSURE

[0176] Enhanced Spam Detection and Mitigation: The present disclosure integrates Artificial Intelligence (Al) capabilities to analyse call records and detect spam patterns based on factors like rejected call rates, call duration, and Mobile Originated (MO) vs. Mobile Terminated (MT) call volumes. The present disclosure enables real-time marking of spam calls to protect users from unwanted or fraudulent communication.

[0177] Efficient Calling Name Presentation (CNAP): The present disclosure introduces a CNAP service that displays the calling party’s name for both on-net and off-net calls without requiring third-party apps, improving customer trust and user experience by reducing reliance on external applications.

[0178] Secure and Isolated Network Integration: The present disclosure ensures that the CNAP and spam detection services remain isolated from the core telecommunication network, enhancing security and reducing vulnerabilities associated with external Telecom Service Provider (TSP) interaction.

[0179] Improved Data Accuracy and Efficiency: The present disclosure isolate telecommunications (Telco) nodes from external TSP databases, ensuring the accuracy of display names and spam indicators while minimizing unnecessary data exchange.

[0180] Regulatory Compliance and Scalability: By adhering to standardized and secure protocols for data exchange, the present disclosure is compliant with regulatory requirements. Further, the present disclosure scalable design supports nationwide deployments without additional hardware for Converged Telephony Application Server (CTAS).

[0181] Efficient Information Retrieval with SIP Protocol: The present disclosure utilizes the Session Initiation Protocol (SIP) instead of Hyper Text Transfer Protocol (HTTP) for information retrieval, benefiting from lower latency, simplified transport layer requirements, and suitability for real-time communications.

[0182] Reduced Call Setup Delays: The present disclosure achieves faster call setup times by minimizing the number of network touchpoints involved in the retrieval of the calling party information.

Claims

CLAIMSWe Claim:

1. A method (600) for retrieving caller information in a network (106), the method (600) comprising:receiving (602), by a Converged Telephony Application Server (CTAS) (208), a call setup message associated with a calling party and a called party; determining (604), by the CTAS (208), whether caller information of the calling party is to be retrieved for the call setup message;generating (606), by the CTAS (208), a query message associated with the calling party, wherein the query message comprises one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved;transmitting (608), by the CTAS (208), the query message to an external database;receiving (610), by the CTAS (208), in response to the query message, caller information comprising at least one of a display name and a spam indication associated with the calling party; andforwarding (612), by the CTAS (208), the call toward the called party based on the caller information.

2. The method (600) as claimed in claim 1, wherein generating the query message, further comprising:retrieving, by the CTAS (208), at least one identifier associated with the calling party from a P-Asserted-Identity header of the call setup message.

3. The method (600) as claimed in claim 1, wherein the proprietary SIP parameters indicate whether the caller information to be retrieved comprises at least one of a spam indication, a display name indication and both the display name and the spam indication.

4. The method (600) as claimed in claim 1, further comprising:modifying, by the CTAS (208), the one or more proprietary SIP parameters based on the caller information received in response to the query message.

5. The method (600) as claimed in claim 1 further comprising:rejecting, by the CTAS (208), the call when the caller information indicates that the call is to be blocked.

6. The method (600) as claimed in claim 1, wherein the query message is transmitted by the CTAS at a terminating leg of the call.

7. A system (108) for retrieving caller information in a network (106), the system (108) comprising:a Converged Telephony Application Server (CTAS) (212) configured to:receive a call setup message associated with a calling party and a called party;determine whether caller information of the calling party is to be retrieved for the call setup message;generate a query message associated with the calling party, wherein the query message comprises one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved;transmit the query message to an external database;receive, in response to the query message, caller information comprising at least one of a display name and a spam indication associated with the calling party; andforward the call toward the called party based on the caller information.

8. The system (108) as claimed in claim 7, wherein to generate the query message, the CTAS (208) is configured to retrieve at least one identifier associated with the calling party from a P-Asserted-Identity header of the call setup message.

9. The system (108) as claimed in claim 7, wherein the proprietary SIP parameters indicate whether the caller information to be retrieved comprises at least one of a spam indication, a display name indication and both the display name and the spam indication.

10. The system (108) as claimed in claim 7, wherein the CTAS (208) is configured to modify the one or more proprietary SIP parameters based on the caller information received in response to the query message.

11. The system (108) as claimed in claim 7, wherein the CTAS (208) is configured to reject the call when the caller information indicates that the call is to be blocked.

12. The system (108) as claimed in claim 7, wherein the query message is transmitted by the CTAS (208) at a terminating leg of the call.

13. A computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to execute a method (600) for retrieving caller information in a network (106), the method (600) comprising:receiving (602), by a Converged Telephony Application Server (CTAS) (208), a call setup message associated with a calling party and a called party; determining (604), by the CTAS (208), whether caller information of the calling party is to be retrieved for the call setup message;generating (606), by the CTAS (208), a query message associated with the calling party, wherein the query message comprises one or more proprietary Session Initiation Protocol (SIP) parameters indicating a type of caller information to be retrieved;transmitting (608), by the CTAS (208), the query message to an external database;receiving (610), by the CTAS (208), in response to the query message, caller information comprising at least one of a display name and a spam indication associated with the calling party; andforwarding (612), by the CTAS (208), the call toward the called party based on the caller information.

Images