Method, system, and computer-readable medium for establishing a communication session between a public switched telephone network (PSTN) endpoint and a web real-time communication (WEBRTC) endpoint

Abstract

A method for establishing a communication session between a public switched telephone network (PSTN) endpoint and a web real-time communications (WebRTC) endpoint includes the steps of: a PSTN microservice (MS) receiving a Session Initiation Protocol (SIP)-based signaling message from a PSTN endpoint; and a PSTN MS obtaining endpoint context attribute information from the SIP-based signaling message. The method further includes the steps of: a PSTN MS generating a WebRTC-based signaling message containing the address identifier of an associated endpoint (AE) associated with the context attribute information; and a PSTN MS sending the WebRTC-based signaling message to the AE to initiate a call session between the PSTN endpoint and the AE.

Description

[Technical field]

[0001] Claiming priority This application claims the benefit of priority to U.S. Patent Application Serial No. 16 / 453,952, filed June 26, 2019, the disclosure of which is incorporated herein by reference in its entirety.

[0002] Technical Field The subject matter described herein relates to enabling real-time communications between Public Switched Telephone Network (PSTN) users and Web Real-Time Communication (WebRTC) users. In particular, the subject matter described herein relates to methods, systems, and computer-readable media for establishing a communication session between a PSTN endpoint and a WebRTC endpoint. [Background technology]

[0003] background Currently, web-based applications and instant messaging clients are frequently used to communicate media and messages over the Internet. Similarly, PSTN telephone-based communications are commonly employed to establish voice-based call sessions. In particular, each of these different network systems typically requires that all supported endpoints establish a connection with a call center or server using a common protocol, common software client, etc. When communication between WebRTC endpoints and PSTN-based endpoints is desired, problems may arise due to incompatible signaling protocols and / or the inability of different end devices to reliably share endpoint information. In particular, it is important for a WebRTC application to know some specific details of the endpoint with which it is communicating. Furthermore, because WebRTC-based systems are primarily capable of communicating real-time media using the Secure Real-Time Protocol (SRTP), which is not used by PSTN endpoints and systems, further technical challenges may arise when a WebRTC endpoint attempts to interface with a PSTN endpoint.

[0004] Therefore, there is a need for a method, system, and computer-readable medium for establishing a communication session between a PSTN endpoint and a WebRTC endpoint. Summary of the Invention [Means for solving the problem]

[0005] overview The subject matter described herein includes a method, system, and computer-readable medium for establishing a communication session between a PSTN endpoint and a WebRTC endpoint. A method includes receiving, by a PSTN microservice (MS), a Session Initiation Protocol (SIP)-based signaling message from a PSTN endpoint, and obtaining, by the PSTN MS, endpoint context attribute information from the SIP-based signaling message. The method further includes generating, by the PSTN MS, a WebRTC-based signaling message including an address identifier of an associated endpoint (AE) associated with the context attribute information, and sending, by the PSTN MS, the WebRTC-based signaling message to the AE to initiate a call session between the PSTN endpoint and the AE.

[0006] In one example of the method, a PSTN MS initiates a WebSocket connection with a signaling engine (SE) in response to receiving a SIP-based signaling message.

[0007] In one example, the step of obtaining endpoint context attribute information in the method includes parsing a header portion of a SIP-based signaling message to obtain source and / or destination information and call type information used to generate the endpoint context attribute information.

[0008] In one example of the method, the address identifier of the AE is obtained in response to pushing endpoint context attribute information to an associate microservice associated with the AE via a Representation State Transfer (REST) ​​application programming interface (API).

[0009] In one example of the method, the PSTN MS sends a join queue request to the AE in response to the endpoint context attribute information being pushed via the REST API.

[0010] In one example of this method, the PSTN MS converts SIP signaling messages into JSON (JavaScript Object Notation) protocol signaling messages that are recognized by the AE.

[0011] In one example of the method, the JSON protocol signaling message is a conversation initiation request message that initiates a call session with the AE.

[0012] A system for establishing a communication session between a PSTN endpoint and a WebRTC endpoint includes a cloud communication environment (CCE) having at least one processor and a memory.

[0013] The system further includes a PSTN MS stored in the memory and configured, when executed by the at least one processor, to receive a SIP-based signaling message from a PSTN endpoint, retrieve endpoint context attribute information from the SIP-based signaling message, generate a WebRTC-based signaling message including an address identifier of an AE associated with the context attribute information, and send the WebRTC-based signaling message to the AE to initiate a call session between the PSTN endpoint and the AE.

[0014] In one example of the system, a PSTN MS initiates a WebSocket connection with a signaling engine (SE) in response to receiving a SIP-based signaling message.

[0015] In one example of the system, the PSTN MS is further configured to parse a header portion of the SIP-based signaling message to obtain source and / or destination information and call type information, which are used to generate endpoint context attribute information.

[0016] In one example of the system, the address identifier of the AE is obtained in response to pushing endpoint context attribute information to an associate microservice associated with the AE via a REST API.

[0017] In one example system, the PSTN MS sends a join queue request to the AE in response to endpoint context attribute information being pushed via the REST API.

[0018] In one example of the system, the PSTN MS converts SIP signaling messages into JavaScript Object Notation (JSON) protocol signaling messages that are recognized by the AE.

[0019] In one example of the system, the JSON protocol signaling message is a conversation initiation request message that initiates a call session with the AE.

[0020] The subject matter described herein may be implemented in hardware, software, firmware, or any combination thereof. Thus, the terms "function," "node," or "engine" as used herein refer to hardware that may also include software and / or firmware components for implementing the described functionality. In one exemplary implementation, the subject matter described herein may be implemented using a non-transitory computer-readable medium having stored thereon computer-executable instructions that, when executed by a processor of a computer, control a computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. Furthermore, computer-readable media implementing the subject matter described herein may be located on a single device or computing platform or distributed across multiple devices or computing platforms. [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 is a block diagram illustrating an example network for establishing a communication session between a PSTN endpoint and a WebRTC endpoint according to one embodiment of the subject matter described herein. [Diagram 2] FIG. 2 is a signaling diagram illustrating an example call flow for establishing a communication session between a PSTN endpoint and a WebRTC endpoint according to one embodiment of the subject matter described herein. [Diagram 3] 1 is a flowchart illustrating an example process for establishing a communication session between a PSTN endpoint and a WebRTC endpoint according to one embodiment of the subject matter described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] Detailed Description A method, system, and computer-readable medium for establishing a communication session between a public switched telephone network (PSTN) endpoint and a web real-time communication (WebRTC) endpoint are disclosed. In some embodiments, the disclosed subject matter includes an external PSTN endpoint that is authorized to communicate with a web-based associated endpoint (AE). In such an example, protocol translation is required to initiate and establish a call or communication session. A host system, such as a cloud communication environment (CCE), utilizes multiple microservices (e.g., virtual machines and / or software applications). These multiple microservices are collectively configured to receive an inbound Session Initiation Protocol (SIP) INVITE message from outside the CCE and then convert the SIP INVITE message into a signaling message based on a JavaScript Object Notation (JSON) RTC protocol. In this manner, the receiving AE can immediately accept the incoming call (e.g., function as if the incoming call was from another AE). The CCE system is also configured to push context attribute information related to the sending PSTN endpoint (e.g., "callType:PSTN") to inform the destination AE that the call signaling message originates from an endpoint supported by the PSTN system.

[0023] 1 is a block diagram illustrating an example network for establishing a communication session between a PSTN endpoint and a WebRTC endpoint, according to one embodiment of the subject matter described herein. For example, FIG. 1 illustrates a network 100 including a PSTN endpoint 102, a PSTN SIP trunk 104, a firewall 106, a load balancer 108, and a CCE system with at least one external hosted domain 110 and at least one internal hosted domain 112.

[0024] In some embodiments, the PSTN endpoint 102 comprises a mobile device, user equipment, Voice over IP (VoIP) phone, etc. capable of communicating over a PSTN network (e.g., PSTN SIP trunk 104). In particular, the endpoint 102 is configured to communicate and establish a session using SIP and Session Description Protocol (SDP) signaling messages. In particular, the PSTN endpoint 102 may attempt to establish a call session with a WebRTC endpoint, such as the AE 114, by directing a SIP INVITE message towards the external host domain 110. In some embodiments, the AE 114 may comprise any WebRTC endpoint, such as a desktop device, a laptop device, a mobile device (e.g., iOS, Android, etc.), etc.

[0025] A SIP INVITE message sent by the PSTN endpoint 102 is initially received by the firewall 106 via the PSTN SIP trunk 104. In particular, the firewall 106 can provide network address translation (NAT) services for a public-facing Internet Protocol (IP) network (e.g., 129.146.xx) to a private network (e.g., 10.0.xx) to which devices and / or microservices of the external host domain 110 are connected. In some embodiments, the firewall 106 is a bare metal as a service (BMaas) firewall.

[0026] After successfully passing through the firewall 106 (e.g., via a specific port), the SIP INVITE message is received by the load balancer 108. In some embodiments, the load balancer 108 is configured to distribute one or more PSTN calls to host devices and / or microservices of the external host domain 110, which may be configured as a set of back-end servers and / or virtual machines. For example, the load balancer 108 is adapted to select one of multiple Enterprise Session Border Controller (ESBC) microservices (e.g., ESBC MS 116) hosted in the external host domain 110 of the CCE system to process any incoming SIP INVITE message. In some embodiments, the IP address of the load balancer 108 is provisioned to the PSTN SIP trunk 104. For example, existing 10.0.xx private network addresses may be used to carry PSTN signaling and media traffic. Because the ESBC MS 116 is located behind the firewall 106, the ESBC MS 116 is configured for NAT traversal so that SIP and media negotiations reflect the public-side IP address of the firewall 106. More specifically, during SIP and media negotiations, the PSTN endpoint 102 is presented with the public-side IP address of the BMaas to reach the ESBC MS 116 in the external host domain 110.

[0027] In some embodiments, the external host domain 110 comprises one or more hardware devices configured to support and execute the ESBC MS 116, the TURN MS 128, and the OHS MS 124. For example, the external host domain 110 may be implementable in software in combination with hardware and / or firmware. In particular, the subject matter described herein may be implementable in software executed by a processor. In one exemplary implementation, the external host domain 110 may include one or more processors, such as a central processing unit (e.g., a single core or multiple processing cores), a microprocessor, a microcontroller, a network processor, an application specific integrated circuit (ASIC), etc. The external host domain 110 may also include memory. The memory may be comprised of random access memory (RAM), flash memory, a magnetic disk storage drive, etc. In some embodiments, the memory may be configured to store one or more microservices. In some embodiments, the processor(s) and memory may be managed by a hypervisor to act as the underlying hardware to support virtual machine(s) (VMs) that support the aforementioned microservices 116, 124, 128 supported in the external host domain 110.

[0028] As shown in FIG. 1, the ESBC MS 116 is configured to receive signaling communications from the PSTN SIP trunk 104 via the firewall 106 and the load balancer 108. For example, port “5061” of the ESBC MS may be exposed and adapted to accept SIP over a TLS connection. The ESBC MS 116 is configured to terminate the PSTN side of the call session and then load balance the SIP INVITE messages to multiple back-end PSTN micro-services (e.g., the PSTN MS 118). In some embodiments, the ESBC MS 116 is configured to utilize a round-robin load balancing scheme. In other embodiments, the ESBC MS 116 may support other types of algorithms or methods for load balancing signaling messages directed to the AEs as needed. After selecting the appropriate PSTN micro-service, the ESBC MS 116 may establish a secure connection with the PSTN MS 118 using Transport Layer Security (TLS), Secure Sockets Layer (SSL), Transmission Control Protocol (TCP) / IP, etc.

[0029] In some embodiments, the ESBC MS 116 is configured to provide the necessary security for PSTN traffic received by the CCE. For example, the ESBC MS 116 may protect the SIP signaling plane by requiring SIP over TLS communication when communicating with the PSTN service provider (e.g., via the PSTN SIP trunk 104). Similarly, the ESBC MS 116 may be configured to protect the media plane by requiring encryption of all media traffic using Secure Real-time Transport Protocol (SRTP). In addition to utilizing SRTP, the ESBC MS 116 may provide protection of exposed media ports against denial of service (DoS), distributed denial of service (DDoS), and man-in-the-middle attacks. In some embodiments, the ESBC MS 116, unlike the OHS MS 124 and the TURN MS 128, may run as a kernel-based virtual machine (KVM) instance in the external host domain of the CCE.

[0030] In some embodiments, the ESBC MS 116 may be used as a public-facing service configured to negotiate the SIP and media signaling required to establish a PSTN call via CCE. As mentioned above, the ESBC MS 116 may be provisioned as a KVM instance on one or more devices / servers in the external host domain 110. The external host domain(s) are located behind the BMaas firewall 106 and the load balancer 108. The firewall 106 provides network address translation (NAT) services to a public-facing IP network (129.146.xx) to a private network (10.0.xx) to which external hosts are connected in the external host domain 110. In some embodiments, the external host domain 110 is provisioned with at least one firewall rule that allows incoming packet traffic originating from the PSTN service provider's SIP port (and a set of media ports) and forwards the traffic to the 10.0.xx private interface of the ESBC MS 116. Additionally, the PSTN service provider may be configured with the IP address of the BMaas load balancer to direct communications to the CCE. For example, the BMaas load balancer 108 may distribute incoming calls to one or more backend servers (and / or microservices) of the external host domain 110. The existing IP address of the BMaas load balancer 108 may be provisioned to the PSTN SIP trunk 104 to reach the CCE service. The existing 10.0.xx private network is used to carry the PSTN signaling and media traffic.

[0031] Because the ESBC MS 116 is behind the BMaas firewall 106, the ESBC MS 116 is configured for NAT traversal so that SIP and media negotiations reflect the public-side IP address of the BMaas firewall 106. Specifically, during SIP and media negotiations, PSTN endpoints (e.g., endpoint 102) are presented with a BMaas public-side IP address that can be used to establish contact with the ESBC MS 116.

[0032] For SIP signaling traffic, the ESBC MS 116 may be configured to load balance among multiple PSTN microservices (e.g., PSTN MS 118) within the internal host domain 112. For media traffic, the ESBC MS 116 may forward packet traffic to a back-end media engine (ME) server (e.g., ME microservice 120). The ME server directs the media traffic to the next destination (e.g., TURN server and / or microservice 128) for delivery to an associated endpoint (e.g., AE 114). It is understood that existing ME microservices may support a mix of MCU and SFU sessions.

[0033] In some embodiments, the ESBC MS 116 is configured to perform SIP trunking termination, TLS and SRTP support, advanced DOS and overload protection, NAT support (e.g., when the ESBC MS is located behind a firewall), KVM support, and routing of SIP messages to back-end servers. The ESBC MS 116 is further configured for 1:1 optional High Availability (HA) support, supports all relevant PSTN and ME related codecs, and is capable of supporting 12000 signaling sessions, 6000 SRTP sessions, and 2500 transcoding sessions (G.721<->G.729).

[0034] In some embodiments, the ESBC MS forwards the load balanced SIP INVITE message to a selected / designated PSTN MS 118 located in the CCE's internal hosted domain 112. In some embodiments, the internal hosted domain 112 may comprise one or more hardware devices configured to support and execute the tenant MS 105, the associate MS 107, the PSTN MS 118, the ME MS 120, and the SE MS 122. For example, the internal hosted domain 112 may be implemented in software in combination with hardware and / or firmware. In particular, the subject matter described herein may be implemented in software executed by a processor. In an example implementation, the internal hosted domain 112 may include one or more processors, such as a central processing unit (e.g., a single core or multiple processing cores), a microprocessor, a microcontroller, a network processor, an application specific integrated circuit (ASIC), etc. The internal hosted domain 112 may also include memory. The memory may consist of random access memory (RAM), flash memory, magnetic disk storage drives, etc. In some embodiments, the memory may be configured to store one or more microservices. In some embodiments, the processor(s) and memory may be managed by a hypervisor to act as the underlying hardware to support virtual machine(s) (VMs) that support the aforementioned microservices 105-107 and 118-122.

[0035] In some embodiments, the PSTN MS 118 is configured to process SIP requests received from outside the CCE (via the ESBC MS 116). As an example, the PSTN MS 118 may support SIP related call setup methods and signaling messages such as SIP INVITE, UPDATE, ACK, BYE, and CANCEL messages. In some embodiments, the PSTN MS 118 may also be configured to implement a SipServlet to process SIP INVITE requests.

[0036] After receiving the initial SIP INVITE message, the PSTN MS 118 is configured to: i) obtain a tenant key and / or client identifier based on the target phone number (i.e., the phone number of the called party); ii) generate a JWT token; iii) establish a connection to the SE MS 122 via WebSocket; iii) parse the “from” and “to” headers of the received SIP INVITE and generate endpoint context attribute information; and iv) push the endpoint context attribute data to the Associate MS 107 via a REST API. In some embodiments, the Associate MS 107 includes multiple routing rules that can be used to establish a connection between a PSTN endpoint and a target AE via the PSTN MS 118. In particular, to route a PSTN call to the correct associate or the correct team (e.g., AE 114), the routing rules need to be first configured by a tenant administrator on the TOB UI 103. The provisioned routing rules can be based on the target PSTN number, e.g., a call directed to “+01234” is routed to “mceAgent@example.com”. Alternatively, the routing rule may be based on the originating number of the PSTN endpoint 102 (e.g., a call from "+64xxx" may be routed to "NZ Support Team"). Based on the associate name returned by the associate MS 107 to the PSTN MS 118, the PSTN MS 118 may forward or translate the SIP INVITE message to initiate a communication session with a target (e.g., an AE) associated with the associate name. So, the request is sent to the correct associate or AE. For example, the PSTN MS 118 may be further configured to v) send a join queue REST request message after the context attribute information is successfully pushed to the associate MS 107, and vi) generate a conversation query request and send the message to the SE MS 122. After getting the query / response, generate a conversation initiation / request message including the relevant AE information.After obtaining the initiation / response message, the PSTN MS 118 generates a SIP 200 response message to the initial SIP INVITE request sent by the PSTN endpoint 102. More specifically, once the AE responds with an answer SDP, the PSTN MS 118 may generate a SIP 200 message that includes the answer SDP to the original / initial SIP INVITE request sent by the PSTN endpoint 102.

[0037] In some embodiments, the PSTN MS 118 may receive a SIP CANCEL message before the call is answered and be configured to send a cancel "joinQueue request" to the associate MS 107 and close the WebSocket with the SE MS 122. The PSTN MS 118 then receives the SIP CANCEL message after the AE 114 answers. However, the SIP 200 message is not delivered to the PSTN client (e.g., PSTN endpoint 102). In such a case, the PSTN MS 118 sends a shutdown message to the SE MS 122 and closes the WebSocket.

[0038] In some embodiments, the AE 114 is configured to communicate over the PSTN MS 118 using WebRTC (defined in IETF and W3C standards), a protocol that enables real-time communication on a hosted browser. As described above, endpoints configured to communicate with WebRTC encounter several technical challenges when communication with PSTN endpoints is desired. For example, WebRTC allows for secure communication of real-time media using SRTP. However, this protocol is not widely recognized and / or utilized by PSTN networks. To address this technical challenge, the disclosed subject matter describes a methodology that provides a Push Context API, a JavaScript Conversation SDK, and a JSON RTC protocol. In this way, the disclosed subject matter enables developers to easily build applications that provide interworking services for both PSTN and WebRTC users.

[0039] In some embodiments, the ESBC MS 116 is configured to negotiate a media session with a PSTN service over the PSTN SIP trunk 104 (after the signaling session is initiated). In particular, a set of ESBC media ports may be exposed by the ESBC MS 116. As such, media traffic arriving at the exposed ESBC media ports is network address translated (NAT) by the firewall 106 to a private IP address of the external host domain 110. In some embodiments, the external host domain 110 has firewall rules provisioned to port forward a range of media ports to the ESBC MS 116. When the ESBC MS 116 receives the PSTN media traffic, the ESBC MS 116 forwards the media traffic to the ME MS 120 for delivery to the AE 114. The media path existing between the PSTN SIP trunk 104 and the ESBC MS 116 may use SRTP to provide confidentiality, message authentication, and replay protection for the communicated media traffic. In addition to SRTP, the ESBC MS 116 may provide security and protection against DOS, DDOS, and man-in-the-middle attacks for exposed ESBC media ports. However, the ESBC MS 116 does not provide any transcoding functionality. Rather, the ME MS 120 is responsible for any transcoding that may be required for media traffic associated with a call established between the PSTN endpoint 102 and the AE 114.

[0040] In some embodiments, the disclosed subject matter may be configured to implement a number of security measures. In some embodiments, the PSTN MS 118 requires a set or multiple media ports to be exposed to the public side of the CCE system. In particular, the ME MS does not provide any DOS / DDOS or man-in-the-middle protection for the exposed media ports. Therefore, it is important for the CCE service to protect these media ports from external attacks. For this reason, the aforementioned ESBC MS 116 is configured to terminate the SIP trunk in the PSTN when the SIP message enters the CCE. The ESBC MS 116 acts as a back-to-back user agent (b2bua) that provides security on the public PSTN side and as an interface to the PSTN MS 118 located in the CCE's internal host domain 112. In some embodiments, the security of the ESBC is achieved by supporting TLS for SIP signaling and SRTP for the media path, as well as protecting against DOS / DDOS and man-in-the-middle attacks. For example, the ESBC MS 116 provides protection from possible TCP / TLS message flooding by limiting the number of connections from the endpoints and by limiting the number of simultaneous TCP / TLS connections to the SIP interface. For example, the ESBC MS 116 can use a "Static TLS" connection to the PSTN SIP trunk 104, which means that a single TLS connection is established from the PSTN service provider to the CCE system. Specifically, all call signaling is designated to utilize that single TLS connection. Once the call is established, if a SIP signaling event is initiated from the CCE side (e.g., AE), the CCE system may need to initiate a new TLS connection back to a PSTN endpoint supported by the PSTN service provider. For example, it can connect to the IP:port sent by the PSTN service provider in the Contact header of the initial SIP INVITE message.Therefore, a policy may be implemented by the ESBC MS 116 that enforces a soft limit on TLS connections over the access side SIP interface.

[0041] Additionally, the ESBC MS 116 may be configured to provide security measures for signaling messages. For example, a single port may be opened in the firewall 106 and the ESBC MS 116 to accommodate receipt of SIP signaling messages. For example, a new port (e.g., 5061) may be opened for SIP over TLS communication. Similarly, multiple ports may be opened in the firewall 106 and the ESBC MS 116 to facilitate accommodating media traffic. For example, the ESBC MS 116 may be located in an external host domain 110, and a set of ports (e.g., UDP ports 49152-60152) may be opened in the external host domain 110 (in both the firewall 106 and the ESBC MS 116) for media traffic so that an external PSTN phone (e.g., the endpoint 102) can communicate with the AE 114. In some embodiments, the media connection established between the PSTN SIP trunk 104 and the ESBC MS 116 is required to use SRTP to provide confidentiality, message authentication, and replay protection for the communicated media traffic.

[0042] In some embodiments, the ESBC MS 116 is configured to provide encryption of signaling and media. For example, the ESBC access side interface to the PSTN service provider (e.g., PSTN SIP trunk 104) uses TLS to ensure confidentiality of the SIP signaling layer. Similarly, the ESBC access side media layer uses SRTP to provide confidentiality, message authentication, and replay protection for the media path. In addition to TLS and SRTP, the PSTN service provider is provisioned to only accept calls from the BMaas public IPs corresponding to the CCE system. Any attempts to connect to the PSTN's SIP trunk 104 from other non-CCE IPs are rejected by the PSTN service provider. Similarly, the CCE has provisioned security lists that only allow external access to signaling and media ports from specific PSTN service provider public IPs that are provisioned only for CCE services. Access to signaling / media ports from sources other than the PSTN service provider's IP addresses is rejected by the ESBC MS 116.

[0043] In some embodiments, the ESBC MS 116 provides further protection internally within the CCE network by only allowing connections from configured "session agents." A "session agent" in ESBC terminology is a SIP hop with which the ESBC MS 116 communicates, so the CCE has one session agent on the access side (i.e., external host domain IP address) and one for each supported PSTN MS. The ESBC MS 116 only allows SIP dialogs from these configured session agents and rejects attempts from all other IPs.

[0044] As shown in FIG. 1, the network 100 further includes a tenant on-boarding (TOB) administrator user interface (UI) 103. Using this interface, a tenant administrator user may provision and configure PSTN rules for each of a number of tenants and / or associate entities (i.e., system subscribers). For example, a tenant administrator may utilize the TOB UI 103 (which may be realized as a browser application hosted and executed by a user computing device) to add context attribute data to a tenant configuration table. The tenant administrator may then configure PSTN rules with the newly defined context attributes for one or more tenants or associates on the TOB UI 103. In particular, the context attribute data provisioned using the TOB UI 103 may be used to configure a PSTN provider / vendor to be able to route PSTN calls to an AE supported by the CCE system. For example, the TOB UI 103 may be used to specify an originating PSTN number in a condition table of a routing rule and to specify an AE as a predefined call destination (e.g., a target telephone number). In this way, all call signaling messages originating from a particular PSTN endpoint or PSTN vendor can be specifically routed to a particular AE (eg, a "team").

[0045] In some embodiments, the security information configured by the tenant administrator is encrypted before being stored in the management database. In some embodiments, a DKKey is used to encrypt private data. Additionally, the PSTN vendor credentials are considered private information, while the tenant contracted phone number may be designated as public information. Additionally, for cross-microservice access, the private key of the Auth MS is replicated to the PSTN MS domain (e.g., the internal host domain 112), and the private key is used to generate a JWT token for a specific TenantKey / ClientId. In particular, the JWT token is used by the PSTN MS 118 to access the Associate MS 107 and the SE MS 122. The use of the JWT token is designated for internal access, and the public API is not exported.

[0046] In some embodiments, routing rules may be provisioned to one or more tenants by onboarding the rules as RESTful configuration data to one or more corresponding tenant microservices (TMS) 105. After receiving the configuration data, the TMS 105 may send a synchronization message to one or more related associate microservices (AMS) 107. The AMS 107 may then use the configuration data to specify specific routing rules for PSTN endpoints associated with subscribed associate or tenant MSs.

[0047] 2 is a signaling diagram illustrating an example call flow for establishing a communication session between a PSTN endpoint and a WebRTC endpoint, according to one embodiment of the subject matter described herein. As shown in FIG. 2, a tenant administrator (TA) 222 utilizes a tenant on-boarding (TOB) user interface 216 to assign PSTN configurations for each of one or more tenant entities (see, e.g., message 1). In some embodiments, the tenant administrator 222 is a system user or operator responsible for managing tenants that subscribe to and support the CCE system. In particular, the tenant administrator 222 may update configuration data for tenant entities serviced by the CCE system.

[0048] In response to the input by the tenant administrator 222, the TOB UI 216 is configured to send a signaling message including RESTful configuration data (for the tenant entities) to the tenant microservices (TMS) 210 (see, e.g., message 2). The tenant MS 210 then provides the received configuration information to the associate MS (AMS) 208 for synchronization purposes (see, e.g., message 3). Thus, the associate MS 208 is thus provisioned with the PSTN configuration information originally specified by the tenant administrator 222 using the TOB UI 216.

[0049] As shown in FIG. 2, the PSTN endpoint 202 is utilized to dial (e.g., by a user) an access number that corresponds to and / or can be mapped to the AE 218 (see, e.g., message 4). The dialed number information is received (e.g., via a PSTN SIP trunk) by the PSTN vendor 204, which then generates a SIP INVITE message (see, e.g., message 5) directed to the external host domain and / or the AE 218. After passing through firewalls, load balancers, and a designated EBSC ​​MS (see above and FIG. 1), the SIP INVITE message (see, e.g., message 6) is received by a PSTN MS (e.g., PSTN MS 206) selected by the external host network and / or the EBSC ​​MS. In particular, the PSTN MS 206 extracts endpoint context attribute information from the received SIP INVITE message and provides this data to the associated MS 208 via a push context message.

[0050] In some embodiments, the associate MS 208 is an agent application initially created by the tenant administrator 222 and responsible for answering calls from PSTN endpoints. In some embodiments, the PSTN MS 206 provides endpoint context attribute information to the associate MS 208 using push context messages (e.g., pushContext / getAgentUri messages) sent via a REST API (see, e.g., message 6). In particular, the endpoint context attribute information may be generated by the PSTN MS 206 using information extracted from headers of received SIP INVITE messages. For example, the endpoint context attribute information may include "From" or "To" information included in the headers of the SIP INVITE messages.

[0051] In some embodiments, the associate MS 208 is responsible for determining which AE should be selected to answer the call request from the PSTN endpoint 202. Upon receiving a push context message (see, e.g., message 6), the associate MS 208 may be configured to access local routing rules that indicate the AE that should be designated as the target. As described above, the routing rules may designate the target AE based on data included in the endpoint context attribute information provided by the PSTN MS 206. In some embodiments, the associate MS 208 may cross-reference the endpoint context attribute information with entries in a local routing rule database that has entries that include mappings between AE address identifiers and data corresponding to various context attributes.

[0052] The associate MS 208 then routes the call to the selected destination AE, such as AE 218 (see, e.g., message 7). After receiving the call, the AE 218 may be configured to display an incoming call alert (see, e.g., message 8). Such an incoming call alert may be a visual display and / or an audible signal prompting the associated user 220 (e.g., a user of the AE 218) to select an answer button (see, e.g., message 9) to receive the call and ultimately establish a media session connection. After the answer button is interfaced / activated by the associated user 220, the AE 218 sends a response message to the associate MS 208, such as an “associateUser URI” message (see, e.g., message 10), that includes an address identifier of the associated user 220. In some embodiments, the address identifier may be a uniform resource identifier (URI) address corresponding to the AE 218 and / or the associated user 220.

[0053] Therefore, the associate MS 208 forwards the message including the associate user URI information to the PSTN MS 206, and the PSTN MS 206 initiates the establishment of a WebSocket connection with the signaling engine (SE) MS 212. For example, the PSTN MS 206 generates and sends a Web RTC message, such as a JSON RTC connection request message, to the SE 212 to establish the WebSocket connection. After receiving a response from the SE 212, the PSTN MS 206 sends a JSON RTC start request message to the SE 212.

[0054] After receiving the initiation request message, the SE 212 sends an SDP request message (for the AE 218) to the ME MS 214. The ME MS 214 responds with an SDP message that is used by the endpoints to negotiate parameters of the media channel, e.g., the codec for transmitting the media. The SDP message also prompts the SE 212 to send a JSON RTC initiation request message to the AE 218. The AE 218 responds with a JSON RTC response message. In response, the SE MS 212 then sends an SDP message to the ME MS 214. After receiving the SDP message from the ME MS 214, the SE 212 sends a JSON RTC initiation response message back to the PSTN MS 206 as a response to the initial JSON initiation request message. In response, the PSTN MS 206 triggers a 200 SIP INVITE acknowledge message to be conveyed (via the PSTN SIP trunk) to the PSTN vendor 204. The PSTN vendor 204 then sends an acknowledge message to the PSTN MS 206 to complete the media connection between the endpoint 202 and the AE 218 .

[0055] 3 is a flow chart illustrating an example process or method 300 for establishing a communication session between a PSTN endpoint and a WebRTC endpoint according to one embodiment of the subject matter described herein. In some embodiments, the method 300 illustrated in FIG. 3 is an algorithm stored in memory that, when executed by a hardware processor, performs one or more of blocks 302-308.

[0056] In block 302, a SIP-based signaling message is received by a public switched telephone network (PSTN) microservice (MS) from a PSTN endpoint. In some embodiments, the PSTN receives a SIP INVITE message from a PSTN endpoint device. In particular, the SIP INVITE message may pass through firewalls, load balancers, and an ESBC MS (located in the CCE's external host domain) before reaching the PSTN MS (located in the CCE's internal host domain).

[0057] At block 304, the endpoint context attribute information is obtained by the PSTN MS from the SIP-based signaling message. In some embodiments, the PSTN MS parses the header of the received SIP INVITE message to extract the "to" and "from" data from the signaling message. The PSTN MS pushes the endpoint context attribute information to an associated MS that is provisioned with a routing rule. In response to receiving the endpoint context attribute information, the associated MS accesses a local routing rule database to determine an address identifier corresponding to the target AE and provides the identifier to the PSTN MS. The address identifier may be a URI corresponding to the target AE.

[0058] In block 306, a Web Real-Time Communications (WebRTC) based signaling message is generated by the PSTN MS that includes an address identifier of an associated endpoint (AE) associated with the endpoint context attribute information. In some embodiments, the PSTN MS generates a Web RTC message, such as a JSON RTC message, to request a communication session with a target AE that corresponds to the address identifier.

[0059] At block 308, a WebRTC-based signaling message is sent by the PSTN MS to the AE to initiate the call session between the PSTN endpoint and the AE. In some embodiments, the PSTN MS directs a JSON RTC message to a destination in the AE to establish a call session between the AE and the sending PSTN endpoint.

[0060] It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Further, the above description is intended to be illustrative only and not limiting.

Claims

1. 1. A method comprising: receiving, by a public switched telephone network (PSTN) microservice (MS), a session initiation protocol (SIP) based signaling message from a PSTN endpoint; and obtaining, by the PSTN MS, endpoint context attribute information from the SIP-based signaling message; the endpoint context attribute information includes access number information corresponding to an associated endpoint (AE) that is an intended recipient of the SIP-based signaling message; The step of obtaining the endpoint context attribute information includes parsing a header portion of the SIP-based signaling message to obtain source and / or destination information used to generate the endpoint context attribute information, the method further comprising: providing the endpoint context attribute information to an associate microservice (MS) by the PSTN MS, the associate MS, in response to receiving the endpoint context attribute information, identifying an address identifier corresponding to the AE based on a routing rule, and providing the address identifier to the PSTN MS, the method further comprising: generating, by the PSTN MS, a Web Real-Time Communication (WebRTC) based signaling message including the address identifier of the AE associated with the endpoint context attribute information; sending, by the PSTN MS, the WebRTC-based signaling message to the AE to initiate a call session between the PSTN endpoint and the AE.

2. 2. The method of claim 1, wherein the address identifier of the AE is obtained in response to pushing the endpoint context attribute information to the associated MS associated with the AE via a Representation State Transfer (REST) ​​application programming interface (API).

3. The method of claim 2 , wherein the PSTN MS sends a join queue request to the AE in response to the endpoint context attribute information being pushed via the REST API.

4. The method according to any one of claims 1 to 3, wherein the PSTN MS converts the SIP-based signaling messages into JSON (Javascript Object Notation) protocol signaling messages that are recognized by the AE.

5. The method of claim 4 , wherein the JSON protocol signaling message is a conversation initiation request message that initiates the call session with the AE.

6. A cloud communications environment (CCE) comprising at least one processor and a memory; a public switched telephone network (PSTN) microservice (MS); The PSTN MS, when stored in the memory and executed by the at least one processor, receiving a Session Initiation Protocol (SIP) based signaling message from a PSTN endpoint; Obtaining endpoint context attribute information from the SIP-based signaling message; the endpoint context attribute information includes access number information corresponding to an associated endpoint (AE) that is an intended recipient of the SIP-based signaling message; The PSTN MS, obtaining the endpoint context attribute information by parsing a header portion of the SIP-based signaling message to obtain source and / or destination information used to generate the endpoint context attribute information; Providing the endpoint context attribute information to an associate microservice (MS); the associated MS, in response to receiving the endpoint context attribute information, identifies an address identifier corresponding to the AE based on a routing rule, and provides the address identifier to the PSTN MS; The PSTN MS, generating a Web Real-Time Communication (WebRTC) based signaling message including the address identifier of the AE associated with the endpoint context attribute information; The system is configured to send the WebRTC-based signaling message to the AE to initiate a call session between the PSTN endpoint and the AE.

7. A computer readable program for causing a processor to carry out the method according to any one of claims 1 to 5.

Images