WO2021003209A1 - Systèmes et procédés d'utilisation de http pour une jonction de téléphonie entre un fournisseur et un consommateur - Google Patents

Systèmes et procédés d'utilisation de http pour une jonction de téléphonie entre un fournisseur et un consommateur Download PDF

Info

Publication number
WO2021003209A1
WO2021003209A1 PCT/US2020/040406 US2020040406W WO2021003209A1 WO 2021003209 A1 WO2021003209 A1 WO 2021003209A1 US 2020040406 W US2020040406 W US 2020040406W WO 2021003209 A1 WO2021003209 A1 WO 2021003209A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
call
resource information
http
ript
Prior art date
Application number
PCT/US2020/040406
Other languages
English (en)
Inventor
Jonathan Rosenberg
Original Assignee
Five9, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Five9, Inc. filed Critical Five9, Inc.
Publication of WO2021003209A1 publication Critical patent/WO2021003209A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1046—Call controllers; Call servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer

Definitions

  • the technology described herein relates generally to systems and methods for providing a protocol for communicating over a packet network such as the Internet.
  • Cloud computing platforms have become mainstream for the development of software applications. These platforms are often targeted at enabling web applications, and as such many of their features are based on the usage of HTTP.
  • HTTP load balancers Cloud computing platforms provide highly scalable, geographically distributed, redundant load balancers. These load balancers can monitor the state of downstream servers and can uniformly distribute load amongst them. The load balancers can compensate for failure of individual nodes and send new traffic to other nodes.
  • a typical cloud computing platform can automatically add new instances of a server backend, or remove them, and automatically configure the load balancers to include them in the pool of available servers.
  • API gateways which provide authentication and authorization, provisioning of applications, rate limiting, analytics, sandboxing for testing, embedded documentation, and so on.
  • denial-of-service prevention techniques typically done using BGP peering and re-routing. Though in principle these techniques can work for voice- over-IP (VoIP), they are typically deployed in conjunction with the load balancers which represent the entry point into these cloud provider networks. Consequently, the protections these cloud providers offer do not extend to applications which merely use these platforms for virtual machines.
  • VoIP voice- over-IP
  • a more recent technology is service meshes, which utilize sidecar HTTP proxies to facilitate inter-service communications. These systems come with robust control planes which enable additional routing features, such as canary deploys, percentage based routing, and so on.
  • SIP Session Initiation Protocol
  • SIP based servers In order for these applications to connect to the PSTN, they typically deploy Session Initiation Protocol (SIP) based servers - SBCs, SIP proxies, and softswitches, to provide this interconnection.
  • SIP Session Initiation Protocol
  • SIP based applications cannot make use of the many capabilities these cloud platforms afford to HTTP based applications.
  • SIP servers are usually deployed on bare metal or VMs at best.
  • Application developers typically must build their own load balancing, HA, failover, clustering, security, and scaling technologies, rather than using the capabilities of these platforms.
  • a load balancing processor receives a Hypertext Transfer Protocol (HTTP) request to create a call from a client processor over an Internet Protocol (IP) network; the load balancing processor directs the HTTP request to a first server in a cluster of servers; the first server generates call resource information identifying the first server as a server resource for the call, and sends the call resource information to the client processor over the IP network; the first server receives HTTP requests over the IP network from the client processor for sending and receiving signaling and media data for the call, where the HTTP requests are sent from the client processor using the call resource information; the load balancing processor receives a re-initiated HTTP request from the client processor that includes the call resource information, where the re-initiated HTTP request is sent by the client processor upon detection that the first server is no longer active; the load balancing processor sends the re initiated HTTP request to a second server in the cluster of
  • HTTP Hypertext Transfer Protocol
  • IP Internet Protocol
  • FIG. 1 is a diagram illustrating an example client-server architecture for providing telephony trunking between a provider and a consumer utilizing HTTP.
  • FIG. 2. is a diagram illustrating an example client-server architecture utilizing an HTTP load balancer.
  • FIG. 3 is a flow diagram illustrating an example of a configuration phase for telephony trunking between a provider and a consumer utilizing HTTP
  • FIG. 4 is a flow diagram illustrating an example operation for provisioning telephony tmnking between a provider and a consumer utilizing HTTP.
  • FIG. 5 is a flow diagram illustrating an example of a call initiated by a tmnking customer telephony utilizing HTTP.
  • FIG. 6 is a flow diagram illustrating an example of a call initiated by a tmnking provider utilizing HTTP.
  • FIG. 7 is a diagram of an example media frame for use in telephony tmnking between a provider and a consumer utilizing HTTP.
  • FIG. 8 is a flow diagram of an example method for providing a VoIP call.
  • RIPT Realtime Internet Peering for Telephony
  • RIPT may be used to provide telephony peering between a trunking provider (such as a telco), and a trunking consumer (such as an enterprise, cloud PBX provider, cloud contact center provider, and so on).
  • RIPT is an alternative to SIP, SDP and RTP for this use case, and is designed to run on top of a Hypertext Transfer Protocol (HTTP), such as HTTP/3.
  • HTTP Hypertext Transfer Protocol
  • Using HTTP allows trunking consumers to more easily build their applications on top of cloud platforms, such as AWS, Azure and Google Cloud, all of which are heavily focused on HTTP based services.
  • RIPT also addresses many of the challenges of traditional SIP -based trunking.
  • RIPT may provide for secure caller ID via the Secure Telephone Identity Revised (STIR) standard, and may provide automated trunk provisioning as a protocol component.
  • RIPT may also support both direct and "BYO" (Bring Your Own Broadband) trunk configurations. Because RIPT runs over HTTP, it can work through Network Address Translation devices (NATs ) and firewalls with the same ease as HTTP does, and easily supports load balancing with elastic cluster expansion and contraction, including auto-scaling - all because RIPT is an HTTP application.
  • RIPT may also provide built in mechanisms for migrations of calls between RIPT client and server instances, enabling failover with call preservation
  • FIG. 1 is a diagram illustrating an example client-server architecture 100 for providing telephony trunking between a trunking provider 102 and a trunking consumer 104 utilizing the RIPT protocol.
  • RIPT enables one administrative domain to send and receive voice calls with another domain.
  • RIPT may, for example, function as the minimum protocol required to interconnect voice between a trunking provider 102 and a trunking consumer 104 (/ ' .£., a domain wishing to access trunking services).
  • Fig. 1 is a diagram illustrating an example client-server architecture 100 for providing telephony trunking between a trunking provider 102 and a trunking consumer 104 utilizing the RIPT protocol.
  • RIPT enables one administrative domain to send and receive voice calls with another domain.
  • RIPT may, for example, function as the minimum protocol required to interconnect voice between a trunking provider 102 and a trunking consumer 104 (/ ' .£., a domain wishing to access trunking services).
  • the RIPT protocol enables the trunking provider 102 and the trunking consumer 104 to implement both RIPT client and RIPT server roles, where a RIPT server receives calls and a RIPT client sends calls.
  • a trunking provider 102 operates as a RIPT client 106 to initiate a call to a trunking consumer 104 operating as a RIPT server 108.
  • the trunking consumer 104 is also shown operating as a RIPT client 110 to initiate a call to the trunking provider 102 operating as a RIPT server 112.
  • RIPT clients and RIPT servers are HTTP (e.g, HTTP/3) applications, running on top of HTTP. That is, RIPT utilizes HTTP, but is not an extension of the HTTP protocols. In this way, RIPT is able to take advantage of advancements in the HTTP protocols (such as advancements in HTTP/3) without requiring the HTTP protocols to include any special features for the benefit of VoIP.
  • the RIPT procedures for sending and receiving calls are therefore compatible with the core HTTP primitives available to applications, such as opening connections, closing connections, sending request and responses, receiving requests and responses, and setting header fields and bodies.
  • HTTP is strictly a hop-by-hop (HBH) technology. Though it does support the notion of proxies (e.g., the CONNECT method for reverse proxies), the protocol is fundamentally designed to be between a client and an authoritative server. What happens beyond that authoritative server is beyond the scope of HTTP, and can (and often does) include additional HTTP transactions. Consequently, in order to reside within HTTP, RIPT follows the same pattern and only concerns itself with HBH behaviors. Like HTTP, a RIPT server can also act as a RIPT client and further connect calls to downstream elements. However, such behavior requires no additional functionality.
  • HBH hop-by-hop
  • HTTP requires that one entity is a client and the other is a server.
  • RIPT operates under HTTP requirements, meaning distinct roles for clients and servers. Clients must always initiate connections and send requests, not servers. To handle this, RIPT specifies that the domain associated with the caller implements the RIPT client, and the domain receiving the calls is the RIPT server. For any particular call, the roles of client and server do not change. To facilitate calls in either direction, a domain can implement both RIPT client and RIPT server roles, as shown in Fig. 1. However, there is no relationship between the two directions.
  • HTTP load balancing is effective because it treats each request/response pair as an independent action which can be routed to any number of backends.
  • the request/response transaction is atomic, and consequentially RIPT operates this way as well.
  • Inter-domain interconnect - used primarily for interconnection with the PSTN - is done traditionally with Session Border Controllers (SBCs) which terminate and re-originate media.
  • SBCs Session Border Controllers
  • RIPT combines signaling and media together on the same connection. To ensure low latency, RIPT uses multiple independent request/response transactions - each running in parallel over unique streams (e.g, HTTP/3 streams) - to transmit media.
  • RIPT also provides for separation between calls and connections.
  • SIP there is a fuzzy relationship between calls and connections.
  • connection failures cause call terminations, and vice a versa.
  • HTTP on the other hand, very clearly separates the state of the resource being manipulated, with the state of the HTTP connection used to manipulate it. This design principle utilized by RIPT. Consequently, call state on both client and server exist independently from the connections which manipulate them. This allows for greater availability by enabling connections for the same call to move between machines in the case of failures.
  • HTTP also makes voice communications under the SIPT protocol compatible with cloud-based platforms.
  • Cloud platforms are typically based on the behavior of HTTP, which has been based on TCP connections and therefore does most of its routing at the connection layer, and not the IP layer.
  • modern cloud platforms are full of NATs and private IP space, making them inhospitable to SIP based applications which still struggle with NAT traversal.
  • RIPT does not suffer from this.
  • "addressing" to the degree it exists at all, is done with HTTP URIs.
  • RIPT as an application on top of HTTP, does not use or convey any IP addresses or ports. Furthermore, the client never provides addressing to the server - all traffic is sent in the reverse direction over the connection.
  • RIPT may also include a built-in mechanism for provisioning, an example of which is described in more detail below with reference to Fig. 3. This enables RIPT trunks to be self- provisioned through web portals, and instantly turned on in production. This capability may, for example, help accelerate the adoption of telecommunications services across the web.
  • RIPT is also compatible with modern cloud-based authentication protocols, as described in more detail below with reference to Fig. 4.
  • HTTP due to its client-server nature, uses asymmetric techniques for authentication. Most notably, certificate based authentication is done by the client to verify that it is speaking to the server it thinks it should be speaking to.
  • modem platforms make use of OAuth2.0.
  • OAuth is not actually an authentication protocol, the use of OAuth has allowed authentication to be done out of band via separate identity servers which produce OAuth tokens which can then be used for authentication of the client.
  • RIPT follows this same approach. For each call, one domain acts as the client, and the other, as the server.
  • the domain When acting as a server, the domain authenticates itself with TLS and verifies the client with OAuth tokens. For calls in the reverse direction, the roles are reversed.
  • RIPT allows one domain to act as the customer of another, the trunking provider. The customer domain authenticates with the provider and obtains an OAuth token using traditional techniques. RIPT then allows the customer domain to automatically create a bearer token for inbound calls and pass it to the provider.
  • RIPT also provides enhanced security features that are compatible with modern cloud-based platforms. Because of the HBH nature of RIPT, security is done fundamentally at the connection level. Since media is also carrier over the HTTP connection, both signaling and media are covered by the connection security provided by HTTP (e.g, HTTP/3). For example, because of the mandatory usage of TLS1.3 with HTTP/3, and the expected widespread deployment of HTTP/3, running VoIP on top of HTTP/3 will bring built-in encryption of media and signaling between peering domains, which is a notable improvement over the current deployment situation.
  • HTTP e.g, HTTP/3
  • RIPT may also provide authenticated caller ID functionality. Robocalling is seeing a dramatic rise in volume, and efforts to combat it continue. One of the causes of this problem is the ease of which SIP enables one domain to initiate calls to another domain without authenticated caller ID.
  • RIPT provides a remedy to this problem by enabling the client and servers to implement STIR. Because RIPT is configured for peering between providers (and not client-to-server connections), STIR is applicable. RIPT clients may therefore be requires to insert a signed passport, or pass one through if it exists. Similarly, RIPT servers may act as verifying parties and reject any calls that omit a passport. [0036] RIPT may also provide enhanced path validation capabilities.
  • HTTP/3 is designed to work through NAT as a client-server protocol. It has built in techniques for dealing with NAT re-bindings, IP address changes due to a client moving between networks (e.g., wifi to cellular data). HTTP/3 has built in path validation that ensures that HTTP cannot be used for amplification attacks. To work with HTTP, RIPT utilizes the HTTP approaches for these problems.
  • RIPT is also designed such that all communications between a RIPT client and a RIPT server can sit behind a load balancer, as illustrated in Fig. 2.
  • Fig. 2 is a diagram illustrating an example RIPT client-server architecture 200 utilizing an load balancer 202, such as an HTTP load balancer. Because both the trunk provider and the trunk consumer implement the client and server roles in a RIPT system, both entities will typically have a load balancer used to receive incoming calls.
  • RIPT may, for example, operate with both L4 and L7 HTTP load balancers.
  • RIPT may hide the number of servers behind the load balancer, allow the addition or removal of servers from the cluster at will, and not expose any of this information to the peer.
  • RIPT may enable the usage of autoscaling technologies used in cloud platforms, without any special consideration for RIPT. By utilizing one or more of these features, RIPT provides for call preservation in the face of failures of the server or client.
  • RIPT may also support built-in migration, allowing a server to quickly shed load in order to be restarted or upgraded, without any impact to calls in progress.
  • a client 204 - which can be a VoIP client (e.g., softphone, hardphone, or a server like an IP PBX or SBC) - that wishes to send a call, comprising media and signaling, to a server for processing.
  • That server may be implemented as a cluster of servers 206, 208 with a load balancer 202, as shown in Fig. 2.
  • Those servers 206, 208 in turn send the call, after processing, to a downstream server 210.
  • the downstream server 210 may also be a cluster, but is shown in Fig. 2 as a single instance for simplicity.
  • a RIPT system provides for call preservation in the face of failures of the server or client.
  • call signaling and media both utilize HTTP.
  • a call may be established using the following steps:
  • the above process for establishing a call may, for example, be performed identically from the client 204 to either server 1 (206) or server 2 (208), and then from server 1/2 (206, 208) to the downstream server 210.
  • a call may be initially established by the client 204 by performing a POST operation to /calls to create the call. This HTTP request arrives at the load balancer 202.
  • the load balancer 202 may, for example be a load balancer to one of the servers in the cluster, for example server 1 (206).
  • server 1 (206) when the HTTP request arrives to server 1 (206) via the load balancer 202, server 1 (206) returns the call URI. Subsequent requests made to that call URI or any of its sub-resources will then preferably be routed to server 1. This can be accomplished, for example, using traditional HTTP techniques, such as HTTP session cookies, embedding routing information in the call URI in the path or URI attributes, or using an authority component which preferentially routes to server 1 (206) based on DNS or other configuration information.
  • server 1 (206) After returning the call URI, server 1 (206) creates a call to the downstream server 210. In this way, server 1 (206) will also have a URI for the call as seen by the downstream server 210. Call this the“downstream call URI”.
  • Server 1 (206) stores in a database, shared by all the servers in the cluster, the call URI that was created, the downstream call URI, and other properties of the call needed for processing the call (for example, whether the call needs transcoding).
  • the HTTP load balancer 202 can quickly detect the failure (e.g ., within a second or less.) This is because, there will typically be extremely high volumes of HTTP transactions towards server 1 (206) - each media packet is a request. Aggregated across many calls, the request/response latency will typically be extremely small, but when a failure happens the request/response latency immediately increases. For example, HTTP error (e.g., 5xx) responses and timeouts will follow.
  • the load balancer 202 may also detect failure through HTTP probes, which may look identical to media since they can go to the same resources and sub-resources, making it more likely that a server failure is detected.
  • the load balancer 202 Upon detecting a failure of server 1 (206), the load balancer 202 sends subsequent requests to server 2 (208).
  • the client 204 will also quickly detect (e.g., within a second or so) the timeout due to a lack of response to media requests. When those requests timeout, the client 204 may retry the request, which is normal http behavior. Typically the client 204 will retry the request with a media request to send or receive a media packet.
  • the load balancer 202 redirects the request to server 2 (208). In this way, server 2 (208) receives a request for a sub-resource of the call URI, which is a call that server 2 (208) is not currently handling.
  • server 2 (208) may access the database, look up the call URI, and retrieve the information needed to process the call along with the next- hop call URI, i.e., the“downstream call URI”. This information provides server 2 (208) the information needed to continue processing the call.
  • server 2 (208) uses the retrieved call information to create a signaling channel with a long-lived GET and PUT towards the downstream server 210, and similarly starts sending and receiving media packets with GET and PUT requests. This will cause the downstream server 210 to now direct signaling events and media packets to server 2 (208) in responses to those requests, which server 2 (208) can now forward to the client 204 in responses.
  • Server 2 (208) may also return a cookie, if needed, to ensure that subsequent requests for this call now route to server 2 (208), in the event that server 1 (206) comes back up during the call.
  • server 2 (208) may return an updated call URI which now preferentially routes to server 2 (208), which will be used by the client 204. At this point, the call has in effect moved to server 2 (208). No packets were lost - anything which could not be delivered was resent to server 2 (208).
  • the RIPT system 200 illustrated in Fig. 2 may be used to gracefully shutdown a server, rather than having an unexpected failure. This may, for example, occur in the event of software upgrades, or for migration of virtual machines or pods to different compute nodes.
  • the RIPT system 200 may be used to perform the upgrade without any interruption in calls. For example, if an admin of the RIPT system wishes to shut down or upgrade a server, they perform the following steps:
  • the server being shut down or upgraded sends a‘migrate event’ on the call signaling channel for one or more of the calls currently in progress.
  • a‘migrate event’ on the call signaling channel for one or more of the calls currently in progress.
  • the client 204 behaves in the same way that it would upon detecting a failure by ending its signaling and media requests, and resending them.
  • the resent requests get sent without session cookies, which means they get routed to another available server in the cluster.
  • the new server may then establish a new cookie and the call can continue on the second server.
  • the server may send, in a migration request, a new call URI to replace the current one.
  • This allows for URI-based routing in the load balancer 202 in the event that session cookie routing cannot be supported. This is also more robust in cases where the client cannot easily control the session cookie at the application layer in order to expire it.
  • FIGs. 3-6 are flow diagrams that illustrate example operations of a packet-based communications system that employs the RIPT protocol for voice communications.
  • this figure illustrates an example of a configuration phase for RIPT communications.
  • RIPT configuration happens when a trunking consumer wishes to be able to provision, on demand, new RIPT trunks with a trunking provider.
  • This configuration phase may occur, for example, when an OAuth2.0 client application (such as a softswitch, cloud PBX, cloud contact center, etc.) wishes to enable trunking customers to provision RIPT trunks against a trunking provider.
  • the trunking provider acts as the resource provider in OAuth2.0 parlance.
  • a trunking consumer 102 may, for example, initiate the RIPT configuration phase by registering with a configuration web page 302 maintained by a trunking provider 104.
  • the trunking provider 104 may generate and return configuration information 304, such as a client identification (ID), client-secret encryption information, and an authorization endpoint URL.
  • the trunking consumer 104 may then use the configuration information 304 to configure a trunking service 306.
  • One example use case is that of an enterprise, which has deployed an IP PBX of some sort within its data centers. Once deployed, the enterprise needs to enable the PBX to place and receive calls towards the PSTN.
  • the enterprise contracts with a RIPT trunking provider. All of this happens as a precursor to configuration.
  • the enterprise administrator will visit the configuration web page, and be able to register their enterprise PBX. This process will typically return a client-ID, client-secret, and authorization endpoint URL, as illustrated in Fig. 3. The administrator manually enters these into the configuration of their PBX.
  • a cloud contact center, cloud PBX provider, or any other saas application which wishes to obtain trunking services can contract with a RIPT trunking provider.
  • the administrator obtains a clientID, client-secret, and authorization endpoint URL which are configured into their service.
  • an enterprise administrator has purchased trunking services from a RIPT trunking provider.
  • the enterprise administrator have separately purchased cloud PBX, cloud contact center, or another saas service which requires connectivity to a RIPT trunk.
  • the cloud PBX, cloud contact center, or other saas service acts as the RIPT trunk consumer.
  • the RIPT trunk consumer would configure itself as a client with a variety of RIPT trunking providers, and for each, obtain the clientID, client-secret and authorization URL. This will allow the customers of the RIPT trunking consumer to provision RIPT trunks automatically, and point them to the RIPT trunking consumer.
  • this figure illustrates an example operation 400 for provisioning RIPT communications.
  • the trunking customer can perform provisioning. More specifically, once a RIPT consumer has been configured as an OAuth client application with a RIPT provider, the RIPT customer can provision a RIPT trunk, for example using an on-demand a web form.
  • Provisioning is the process by which a trunking customer connects a RIPT trunk from a trunking provider to trunking consumer. Provisioning may, for example, be accomplished using OAuth2.0 code authorization techniques.
  • the OAuth resource owner is the trunking customer.
  • the OAuth client is the RIPT implementation within the trunking consumer.
  • the resource server is the RIPT implementation in the trunking provider. RIPT consumers may, for example, provide a self-service web form for such provisioning.
  • the trunking customer 102 may, for example, initiate an authentication procedure by accessing a web page 406 hosted by the trunking consumer, for example by clicking on a user interface icon labeled with an identification of the trunking provider 104.
  • This will begin an authentication (e.g., OAuth 2) authorization flow 404, where the trunking customer 102 provides necessary information to authenticate with the trunking provider 104.
  • the authorization flow 404 may, for example, utilize the clientID, client-secret and authorization endpoint URL configured during the configuration phase shown in Fig. 3.
  • the RIPT customer will authenticate to the RIPT provider and authorize creation of a new RIPT trunk.
  • the trunking provider 104 authorizes the access 406, generates an authorization code 408, and generates a RIPT trunk provider URI 410.
  • the provider URI 410 contains a path component, but preferably does not contain any URI parameters.
  • the URI may, for example, be an HTTPS URI and may preferably support HTTP/3.
  • the path component may be a globally unique identifier for the trunk, and preferably should not depend on the authority component as part of the namespace for purposes of uniqueness.
  • the provider URI 410 may, for example, be included in a new OAuth parameter and returned as a parameter in the authorization response.
  • the URI may be returned in the OAuth2.0 parameter“ript-trunk” and may be base64 encoded.
  • the trunking consumer trades the authorization code 412 for a refresh and access token 414 and stores the provider URI 416.
  • the refresh and access token 414 is issued by the RIPT provider, and preferably will last a long time in order to avoid the resource owner needing to manually re-authorize.
  • the trunk consumer should, however, be prepared for its access and refresh tokens to be invalidated at any time.
  • the RIPT consumer extracts the authentication parameter (e.g., the“ript-trunk” OAuth parameter) from the authorization response, and decodes and persists the parameter.
  • the trunking consumer mints a bearer token 418 associated with the new RIPT trunk, and also mints a RIPT trunk consumer URI 420 for receiving calls from the provider on this trunk. Both of these are passed to the trunking provider via a POST operation 422 (e.g., an HTTPS PUT request to /consumerTrunk) on the RIPT trunk provider URI.
  • the request may preferably contain an Authorization header field utilizing the access token 414 and a RIPT provisioning object in the body.
  • the RIPT provisioning object contains a RIPT consumer URI and a RIPT bearer token, as illustrated in Fig. 4.
  • the RIPT trunk consumer URI 420 minted by the RIPT consumer may, for example, be an HTTPS URI with a path component and a globally unique path segment, and preferably should not contain any URI parameters.
  • the bearer token 418 minted by the trunking consumer is used by the RIPT provider when performing operations against the RIPT trunk client URI.
  • the bearer token may be constructed in a way desired by the RIPT consumer, and should remain valid for at least one day, however, may be invalidated in the event of a security problem.
  • the RIPT consumer should refresh the provisioning against the RIPT trunk at least on hour in advance of the expiration in order to ensure no calls are delayed.
  • the trunking consumer and the trunking customer 102 are the same for simplicity of illustration. It should be understood, however, that the usage of the authentication (e.g., OAuth2.0) flow enables the trunking consumer and trunking customer 102 to be the same (e.g ., a cloud PBX provider purchases services from a telco), or different (e.g.., an enterprise customer has purchased trunking services from a telco, and wishes to provision them into a cloud contact center that acts as the trunking consumer).
  • the latter is often referred to informally as "BYOSIP" in traditional SIP trunking and may, for example, be supported by RIPT using OAuth2.0.
  • both sides obtain capability declarations 424, 426 for the RIPT trunk.
  • each client may perform a GET to /capAdv of its peer’s trunk URI, and the response body may include a RIPT capabilities object.
  • the capabilities declaration 424, 426 may be a simple document that conveys the receive capabilities of the entity sending it, and includes parameters, such as maximum bitrate for audio. This process is optional, and each parameter may have a default.
  • either side may be able to update its capabilities for the RIPT trunk at any time, and trigger a fresh GET via an HTTP push.
  • Capability declarations 424, 426 occur outside of a call and convey static receive capabilities which are a fixed property of the RIPT trunk. Consequently, capability declaration is significantly different from SDP offer/answer.
  • either side may update the capabilities declarations 424, 426, for example by sending an HTTP push to trigger its peer to fetch a fresh capabilities document. Due to race conditions, it is possible that the client may receive calls compliant to the old capabilities document for a brief interval.
  • the RIPT capabilities document may, for example, be is a list of name-value pairs, which specify a capability. Every capability may have a default, so that if no document is posted, or it is posted but a specific capability is not included, the capability for the peer is understood. Capabilities may be receive only, and specify what the entity is willing to receive. Capabilities may be bound to the RIPT trunk and be destroyed when the RIPT trunk is destroyed.
  • codecs can be listed as capabilities. This may be done by using the media type and subtype, separated by a 7", as the capability name. Media type and subtype values may be taken from the IANA registry for RTP payload format media types. The value of the capability is “true” if the codec is supported, “false” if it is not. The default is “false” for all codecs except for "audio/PCMU", “audio/opus”, “audio/telephone-event” and “audio/CN”, for which the default is “true”. Because codec capabilities are receive-only, it is possible, and totally acceptable, for there to be different audio codecs used in each direction.
  • an entity may preferably declare a capability for any characteristic of a call which may result in the call being rejected. This facilitates prevention of call failures, along with clear indications of why calls have failed when they do. For example, if a RIPT trunk provider provisions a trunk without support for G.729, but the consumer configures to utilize this codec, this will be known as a misconfiguration immediately. This enables validation of trunk configurations in an automated fashion, without placing test calls or calling customer support.
  • Figs. 5 and 6 illustrate calls may be initiated by either the trunking customer 102 or trunking provider 104, as illustrated in Figs. 5 and 6.
  • Fig. 5 illustrates an example 500 of a call initiated by the trunking customer 102
  • Fig. 6 illustrates an example 600 of a call initiated by the trunking provider 104.
  • Either the trunking consumer 102 or trunking provider 104 can initiate calls, for example by posting 502, 602 to the /calls on RIPT trunk URI of its peer.
  • this is the RIPT trunk RUI provisioned during the authentication (e.g ., OAuth2.0) flow.
  • the trunking provider it is the RIPT trunk consumer URI learned through the provisioning POST operation.
  • the request may be an HTTP/3 transaction, and the client may validate that the TLS certificate that this returned matched the authority component of the RIPT trunk URI.
  • the request 502, 602 may contain the target phone number in the request URI and an Identity header field in the HTTP Request, as shown in Figs. 5 and 6.
  • the Identity header field may, for example, be identical in syntax and semantics to a SIP Identity header field, just carried in HTTP instead of SIP.
  • the Identity header field is a valid HTTP header field to ensure that all calls utilize secure caller ID.
  • a RIPT client should preferably not place the caller ID any place except for the Identity header field in the request 502, 602, and a“From,”“Contact,” or“P-Asserted-ID” should preferably not be included in the Identify header field.
  • the request 502, 602 may contain the token that the client has obtained out-of-band.
  • this may be the authorization (e.g, OAuth) token
  • the RIPT trunk provider 104 this may be the bearer token learned through the provisioning POST operation.
  • the client may also add the“target” URI parameter, which may for example be of the form user@domain. If the target is a phone number on the PSTN, the URI parameter may take the form ⁇ el64>@el64.arpa, where ⁇ el64> is a valid E.163 number.
  • RIPT may also support private trunks, in which case the URI parameter may take the form ⁇ number>@ ⁇ domain>, where the number is a non-El 64 number scoped to be valid within the domain.
  • RIPT may also be used to place a call to application services, such as a recorder, in which case the URI parameter may take the form of an RFC822 email address.
  • the receiving server Upon receipt of the request 502, 602, the receiving server should preferably validate the authentication (e.g., OAuth) token and act as the verifying party to verify the Identity header field, and then either accept or reject the request 504, 604 to authorize or decline the creation of a new call. If the call is accepted, indicating that the server is willing to accept the call, the server generates a response 504, 604.
  • the generated response 504, 604 includes a location header field, for example containing an HTTPS URI that identifies the call that has been created.
  • the URI identifying the call may, for example, include a path segment that contains a type 4 UUID, ensuring that call identifiers are globally unique.
  • the response 504, 604 may also include a session cookie, bound to the call, to facilitate sticky session routing in HTTP proxies. This allows all further signaling and media to reach the same RIPT server that handled the initial request, while facilitating failover should that server go down.
  • the client should preferably support receipt of cookies, and should be prepared to receive up to 10 cookies per call. In embodiments, the client may destroy all cookies associated with a call when the call has ended. Cookies may also be restricted in size.
  • the root URI can use a domain whose A record maps to this IP. Once a call has landed on a particular SBC, the call URI can indicate the specific IP of the SBC.
  • the RIPT trunk URI for such a telco operator might be:
  • the HTTP URI for the call should not contain an IP address; it should instead utilize a valid host or domain name. This is to ensure that TLS certificate validation functions properly without manual configuration of certificates (a practice which is required still for SIP based peering). Neither the request, nor the response, contain bodies.
  • a pair of long-lived HTTP transactions is initiated from the client to the server for purposes of signaling.
  • One is a GET transaction 506, 606, retrieving call events from its peer.
  • the other is a PUT transaction 508, 608, sending call events to its peer.
  • Each of these transactions produces a unidirectional data stream, one data stream 510, 610 in the forward direction, and another data stream 512, 612 in the reverse direction 612. These data streams are called byways.
  • HTTP/3 ensures zero RTT for setup of these byways.
  • the long-lived HTTP transactions may utilized a stream of lavaScript Object Notation (ISON) in the PUT request and a stream of JSON in the GET response.
  • ISON lavaScript Object Notation
  • the body may begin with an open curly bracket, and after that a series of JSON object, each starting with a curly bracket and ending with a curly bracket, and each side should immediately send their respective open brackets after the HTTP header fields.
  • Streaming JSON may, for example, be utilized in order to facilitate usage of tools like cURL for signaling operations.
  • Signaling commands may be encoded into the signaling byway using streaming JSON in both directions.
  • Each JSON object encodes an event and its parameters. Events may, for example, be defined for alerting, connected, ended, migrate, keepalive, and transfer-and- takeback.
  • the media byways may carry a simple binary encoding in both directions. Even though data can flow in both directions, a media byway is unidirectional in terms of media transmission.
  • a forward media byway carries media from the client to the server, and a reverse byway carries media from the server to the client.
  • HOL Head-of-Line
  • a media packet is sent on a media byway when it is first established. After the first packet, the client cannot be sure a subsequent packet will be delayed due to the ordering guarantees provided by HTTP/3 within a stream. To combat this, both sides may acknowledge the receipt of each packet using an ACK message sent over the media byways, in the opposite direction of the media.
  • ACK messages are carried from server to client, and in a reverse media byway, they are carried from client to server.
  • the media byway can be used once again without fear of HOL blocking. Because each media packet is acknowledged independently, each side can compute statistics on packet losses and delays. Consequently, the equivalent of Real-Time Transport Control Protocol (RTCP) sender and receiver reports may not be needed.
  • RTCP Real-Time Transport Control Protocol
  • RIPT may also provide for congestion control at the client side. Specifically, the RIPT protocol may cause clients to drop media packets if there are too many media byways in the blocked state.
  • RIPT provides a simple technique for allowing a call to seamlessly migrate from one client instance to another on a different host, or from one server instance to another on a different host.
  • RIPT need only end the byways in use for the call and re-initiate from a different instance.
  • a server can request migration, and this triggers the client to perform this same action.
  • the call state persists independently of the state of the HTTP connection or the byways embedded in HTTP transactions, so that a reconnect can continue where things left off.
  • RIPT trunks can be destroyed by a trunking consumer, for example by issuing a DELETE against the RIPT trunk provider URI.
  • RIPT media is represented as a continuous sequence of RIPT media frames embedded in a media byway.
  • Each RIPT media frame encodes a variable length sequence number offset, followed by a variable length field, followed by a codec frame equal to that length.
  • the media byway itself when created, includes properties that are shared across all media frames within that byway. These parameters include the sequence number base, the timestamp base, the codec type, and the frame size in milliseconds for the codec.
  • each RIPT media frame 700 has the following properties, as shown in Fig. 7:
  • a sequence number 702 which may be equal to the sequence number base associated with the media byway plus the value of the sequence number offset
  • • a timestamp 704 which may be equal to the timestamp base from the byway plus the sequence number offset times the frame size in milliseconds (note that this requires that frame size remain fixed for all media frames in a byway);
  • RIPT will not support gaps in the media sequence due to silence. In this case, something must be transmitted for each time interval. If a RIPT implementation wishes to change codecs, it may utilize a different byway for that codec.
  • the RIPT client bears the responsibility for opening media byways - both forward and reverse. Consequently, the server is strongly dependent on the client opening reverse byways; it cannot send media unless a reverse byway has opened.
  • a RIPT client may open a new forward byway whenever it has a media frame to send, all existing forward byways (if any) are in the blocked state, and the client has not yet opened 20 byways.
  • the client may be required to keep a minimum number (e.g., 10) of reverse byways open at all times to ensures that the server can send media.
  • the client may be required to open these byways immediately, in parallel.
  • the requests to create these transactions may include cookie headers for any applicable session cookies.
  • a client may open a forward media byway, as shown in Figs. 5 and 6, by initiating a POST request to the /media-forward endpoint on the call URI, which includes a RIPT-Media header field in the request headers.
  • the client may initiate a POST request to the /media-reverse endpoint of the call URI.
  • the POST request for opening a reverse media byway does not include a RIPT-Media header field in the request headers.
  • the server includes the RIPT-Media header in the response headers.
  • the RIPT-Media header contains the properties for the byway, such as the sequence number base, the timestamp base, and the name of the codec.
  • RIPT may supports multiple audio channels for active recording sessions, such as Session Recording Protocol (SIPREC) use cases.
  • SIPREC Session Recording Protocol
  • each channel is on a separate byway.
  • the client may include the multichannel parameter and the channel number, starting at 1.
  • the sequence number space is unique for each direction, channel, and call (as identified by the call URI). For example, each side may be required to start the sequence number at zero, and increment the sequence number by one for each subsequent media frame.
  • the sequence number base is represented as a string corresponding to a 32 bit unsigned integer
  • the sequence number offset in the media frame is variable length, representing an unsigned integer. Consequently, the sequence number space for a media stream within a call may have a total space of 32 bits. In this case, with a minimum frame size of 10ms, RIPT can support call durations as long as 11,930 hours.
  • rollover of the sequence number is not permitted, and the client or server must end the call before rollover. This means that the combination of call URI, direction (client to server, or server to client), channel number, and sequence number represent a unique identifier for media packets.
  • the client or server when either the client or server sends a media frame on a byway, it immediately marks the byway as blocked. At that point, the client or server should not send another media frame on that byway. The client or server may note the sequence number and channel number for that media frame. Then, once an acknowledgement is received for that corresponding media frame, the client or server may mark the byway as unblocked. A client or server may send a media frame on any unblocked byway.
  • the client may open additional byways once the number of blocked byways goes above a threshold. For example, if the number of blocked byways in either direction hits 75% of the total for that direction, this may be a signal that congestion has occurred. In such a case, the client or server may either drop packets at the application layer, or buffer them for later transmission.
  • a client or server When a client or server receives a media frame, it sends an acknowledge message.
  • This acknowledge message may be sent on the same byway that the media was received.
  • the acknowledgement message may, for example, contain the full sequence number and channel number for the media packet that was received.
  • the acknowledgment message may also contain the timestamp, represented as wallclock time, at which the media packet was received.
  • the server may send a signaling event instructing the client to open another reverse media byway. Once this command is received, the client may open a new reverse byway, unless the total number of byways has reached a maximum number (e.g., 20).
  • a maximum number e.g. 20
  • a client may terminate media byways gracefully if they have not sent or received packets on that byway for a set amount of time (e.g., 5 or more seconds). This is to clean up unused byways.
  • the state of the connection, the media (e.g, QUIC) streams, and byways, is separate from the state of the call.
  • the client may therefore terminate an HTTP connection or byway at any time, and re-establish it.
  • the server or client may end a byway at any time.
  • both client and server may buffer their signaling and media streams for a set period (e.g., at least 5 seconds), and then once the connections and byways are re-established, send all buffered data immediately.
  • a set period e.g., at least 5 seconds
  • each event may be a JSON object embedded in the signaling stream, which conveys the event as perceived by the client or server.
  • Each event may have a sequence number, for example which starts at zero for a call, and increases by one for each event. The sequence number space may be unique in each direction.
  • the event may also contain a direction field, which indicates whether the event was sent from client to server, or server to client.
  • the event may also contain a timestamp field, which indicates the time of the event as perceived by the sender. In embodiments, the timestamp is not updated when retransmissions happen because the timestamp exists at the RIPT application layer and RIPT cannot directly observe HTTP retransmits.
  • the event may also contains a call field, which contains the URI of the call in question.
  • the event may also include an event type field, which conveys the type of event.
  • the event type field is followed by additional fields that are specific to the event type.
  • This structure means that each event carried in the signaling is totally self-describing, regardless of the enclosing connection and stream. This greatly facilitates logging, debugging, retransmissions, retries, and other race conditions which may deliver the same event multiple times, or deliver an event to a server which is not aware of the call.
  • Events may also be defined so that the resulting state is uniquely defined by the event itself. This ensures that knowing the most recent event is sufficient to determine the state of the call.
  • alerting passed from server to client, indicating that the recipient is alerting
  • rejected passed from server to client, indicating that the call was rejected by the user failed: passed from server to client, indicating that the call was rejected by the server or downstream servers, not by the user, but due to some kind of error condition.
  • This event may contain a response code and reason phrase.
  • noanswer passed from server to client, indicating that the call was delivered to the receiving user but was not answered, and the server or a downstream server timed out the call.
  • a call cannot be ended with a DELETE against the call URI; DELETE is not permitted and is rejected by the server.
  • the call end event may contain a reason, for example using predefined Reason codes.
  • migrate sent from server to client, instructing the client to terminate the connections and re-establish the connections to a new URI which replaces the URI for the call.
  • the event contains the new URI to use, which may utilize the same path components, and may have a different authority component.
  • open-reverse sent from server to client, instructing the client to open an additional set of reverse media byways.
  • tnt send from consumer to provider, invoking a takeback-and-transfer operation.
  • This event may include the phone number to which the call should be transferred. The provide will then transfer the call to the target number. This event is meant to invoke the feature as it has been implemented by the provider.
  • Signaling may allow an application layer call end to be sent. This may also cause each side to terminate the outstanding transactions, for example using end flags per HTTP/3 specs. However, the opposite is not true - ending of the transactions or connection does not impact the call state.
  • the server maintains a timer with a predetermined time limit (e.g ., one second) for which it will hold the call in its current state without any active signaling byway. If the server does not receive a signaling byway before the expiration of this timer, it may consider the call as ended.
  • a predetermined time limit e.g ., one second
  • a server if a server receives a signaling or media byway for a call that is in a terminated state, the server rejects the transaction with an XX response code.
  • the call resource may be destroyed.
  • a client may initiate a GET request against the call URI at any time. This returns the current state of the resource.
  • the GET request may return the most recent event, either sent by the server or received by the server.
  • RIPT may provide built in support for allowing a server instance to drain all active calls to another server instance.
  • the server can issue a migrate event over the signaling byway, which includes a new call URI that the peer should use.
  • the client closes all transactions to the current call URI.
  • the client then establishes new signaling, media and media control byways to the URI it just received. All media that the client wishes to transmit, but was unable to do so during the migration, may be buffered and then sent in a burst once the media byways are re-established. This ensures there is no packet loss (though there will be jitter) during the migration period.
  • RIPT clients are able to easily move a call from one client instance to another. No commands are required. The client simply ends the in-progress transactions for signaling and media, and then reinitiates them to the existing call URI from whatever server is to take over. In embodiments, the client may be required to do this within a set time limit (e.g, Is) or the server will end the call.
  • a set time limit e.g, Is
  • the RIPT client is responsible for failure detection.
  • the client if the client detects such a failure, it aborts all ongoing transactions to the server, terminates the QUIC connection, and then establishes a new connection using 0- RTT, and re-establishes signaling and media transactions. If this retry fails, the client may consider the call terminated, and should not further attempt to re-establish the call.
  • SIP Gateway if the client detects such a failure, it aborts all ongoing transactions to the server, terminates the QUIC connection, and then establishes a new connection using 0- RTT, and re-establishes signaling and media transactions. If this retry fails, the client may consider the call terminated, and should not further attempt to re-establish the call.
  • RIPT may, for example, be implemented in Session Border Controllers (SBCs) and softswitches.
  • SBCs Session Border Controllers
  • a SIP to RIPT gateway should be call-stateful, acting as a back-to-back user agent (B2BUA), in order to gateway to RIPT.
  • B2BUA back-to-back user agent
  • a SIP to RIPT gateway should act as a media termination point in SIP, should perform any SRTP decryption and encryption, and it should de-packetize RTP packets to extract their timestamps, sequence numbers, and codec types.
  • SIP to RIPT gateways may not be transparent. SIP header fields which are unknown or do not map to RIPT functionality may be discarded.
  • systems employing the RIPT protocol enable telcos, having existing SBC deployments, to allow those SBCs to originate and receive calls over RIPT without requiring any change in deployment architecture.
  • Case 2 There is a cluster of SBCs, deployed behind a SIP proxy pair.
  • the SIP proxy pair share a VIP, acting in an active/passive configuration.
  • the SIP proxy load balances the calls across the SBC farm. Media flows directly to the SBC, and signaling through the (stateful) proxy.
  • INVITE goes to the proxies, but once the call is routed to an SBC, all subsequent signaling is routed directly to the SBC (along with media).
  • Case 4 As Case #2 or #3, except the proxies don’t share a VIP. Rather, they each have a separate IP address. DNS is used to round robin across the proxy farm. This means there can be more than 2 SIP proxies, and they are all active.
  • embodiments of RIPT may provide one or more enhanced features, as follows.
  • a call is created via a POST operation to the trunk URI, two unique URI are returned.
  • One URI represents the call endpoint for the signaling channel, and the other URI represents the endpoint for media.
  • the RIPT client may then establish a byway to the signaling URI for signaling, and establish a byway to the media URI for the media byways.
  • Case 1 The SBC implements RIPT also, for example running an HTTPS server on port 443.
  • the RIPT provider trunk URI is a hostname which is configured in the DNS to resolve to this VIP (e.g ., sbc-vip.provider.com). This means that the incoming HTTP requests will arrive at the active SBC.
  • This SBC will create a call URI, and the call URI also uses the same hostname - sbc-vip.provider.com. This means that all mid-call signaling will continue to arrive to this VIP and be routed to the active SBC.
  • the provider does not need to add any kind of HTTP load balancer - it just needs the SBC vendor to add support for RIPT.
  • Case 2 The SBC adds RIPT support. Beyond that, there are two example solutions. First, an HTTP proxy is added. This can be done, for example, by adding HTTP proxy support to the SIP proxy or adding an off the shelf http proxy. Alternatively, the provider can deploy a separate web server, not a proxy. Let us consider the proxy case separately from the web server case:
  • the RIPT trunk provider URI may be proxy-vip.provider.com, pointing to the VIP which is associated with the HTTP proxy, whether this is implemented as a feature of the sip proxy or a standalone http proxy. HTTP/rip requests arrive there. These are proxied to the SBCs, which implement RIPT.
  • the SBCs generate a call URI with a domain of proxy-vip.provider.com and include in the path segment, an indicator of which SBC is handling the call. For example, https://proxy- vip.provider.com/calls/call24/sbcl2 would indicate that call 24 is present on SBC 12.
  • the media URI would have a host part that routes directly to SBC 12: e.g., https ://sbc- 12.provider.com/calls/call24.
  • the RIPT client may open a signaling byway which goes to the proxies, which can then route to the SBC.
  • the media byways may be opened directly to the SBCs.
  • Case 2 - Second Example Solution In the web server case, a separate, standalone web server may be implemented and deployed.
  • the RIPT trunk provider URI may be https://webserver.provider.com. There may or may not be a VIP; this Webserver is likely part of the normal web infrastructure for the provider, and not part of its telecom infrastructure. This web application will monitor the up/down status of the SBCs through an out of bands means.
  • the web server selects an SBC that is active, and then encodes its hostname into the domain part of both the signaling and media URIs - e.g ., https://sbc-12.provider.com.
  • This approach may, for example, be beneficial for telcos who have a highly separated web and sip/telecom infrastructure. It enables them to use their existing web infra for the creation of calls, implementing the load balancing amongst the SBCs, and then direct the actual calls to the telecom infra of the SBCs. Note that, in this case, subsequent signaling does not pass through the web server, rather it goes to the SBC.
  • Case 3 This topology is easy to implement in RIPT. As with Case 2, there is either a web server, or a proxy. If it is a web server, as in the Second Example Solution for Case 2 (above), the flow is identical. In the case of a proxy, it is similar to the First Example Solution for Case 2 (above), except that the call URI minted by the SBC points to itself - e.g., https://sbc- 12.provider.com/calls/call24 would be used for BOTH the signaling and media call URI.
  • RIPT also allows for another topology for telcos.
  • the RIPT trunk provider URI points to either a VIP, or a farm of entry proxies (e.g., proxy-farm.provider.com).
  • proxy-farm.provider.com e.g., proxy-farm.provider.com
  • the SBC encodes its identity, and the calllD, into the URL as well.
  • the call and media URL may both be https://proxy-farm.provider.com/calls/calll2/sbc-23.
  • call 12 is actually on SBC 23.
  • these are just HTTP requests, which route once again to the proxy farm.
  • the proxy farm can see that these requests are for an established call, and the identity of the SBC is embedded in the URI - SBC 23.
  • the proxies route these requests there. Should SBC 23 fail, the proxies may select an alternative.
  • This cookie can either be inserted by the RIPT server behind the proxy, or by the proxy itself.
  • the call and media URIs are also directed to the proxy-farm.provider.com.
  • the HTTP load balancer inspects the cookies and will continue to route the transactions to the same backend server which created the cookie. This is common HTTP server behavior.
  • Fig. 8 is a flow diagram showing an example method for providing a Voice over Internet Protocol (VoIP) call.
  • a load balancing processor receives a Hypertext Transfer Protocol (HTTP) request to create a call from a client processor over an Internet Protocol (IP) network.
  • IP Internet Protocol
  • the load balancing processor directs the HTTP request to a first server in a cluster of servers.
  • the first server generates call resource information identifying the first server as a server resource for the call, and sends the call resource information to the client processor over the IP network.
  • the call resource information may include an HTTP Uniform Resource Identifier (URI) for the first server and/or a session cookie identifying the first server.
  • the first server receives HTTP requests over the IP network from the client processor for sending and receiving signaling and media data for the call, where the HTTP requests are sent from the client processor using the call resource information.
  • URI Uniform Resource Identifier
  • the load balancing processor receives a re-initiated HTTP request from the client processor that includes the call resource information, where the re-initiated HTTP request is sent by the client processor upon detection that the first server is no longer active.
  • the client processor detects that the first sever is no longer active and, in response, generates the re-initiated HTTP request.
  • the load balancing processor sends the re initiated HTTP request to a second server in the cluster of servers.
  • the load balancing processor detects that the first server is no longer active and, in response, causes subsequent HTTP requests for the call to be redirected to the second server.
  • the second server generates updated call resource information that identifies the second server as the server resource for the call, and sends the updated call resource information over the IP network to the client processor.
  • the updated call resource information may include an HTTP URI for the second server and/or an updated session cookie identifying the second server.
  • the second server receives subsequent HTTP requests over the IP network from the client processor for sending and receiving signaling and media data for the call, where the subsequent HTTP requests are sent from the client processor using the updated call resource information.
  • the method 800 of Fig. 8 may include the additional steps of: establishing the call between the first server and a downstream server and receiving, at the first server, downstream call resource information for the downstream server; storing the downstream call resource information in a database accessible by the cluster of servers; retrieving, at the second processor, the downstream call resource information from the database; and re establishing the call between the second sever and the downstream server using the downstream call resource information.
  • the downstream call resource information may include an HTTP URI for the downstream server.
  • the first and second servers may use the downstream call resource information to generate HTTP requests for sending and receiving signaling and media packets for the call to and from the downstream media server.
  • the methods and systems described herein may be implemented on many different types of processing devices by program code comprising program instructions that are executable by the device processing subsystem.
  • the software program instructions may include source code, object code, machine code, or any other stored data that is operable to cause a processing system to perform the methods and operations described herein and may be provided in any suitable language.
  • Other implementations may also be used, however, such as firmware or even appropriately designed hardware configured to carry out the methods and systems described herein.
  • data e.g., associations, mappings, data input, data output, intermediate data results, final data results, etc.
  • data may be stored and implemented in one or more different types of computer-implemented data stores, such as different types of storage devices and programming constructs (e.g, RAM, ROM, Flash memory, flat files, databases, programming data structures, programming variables, IF-THEN (or similar type) statement constructs, etc.).
  • storage devices and programming constructs e.g, RAM, ROM, Flash memory, flat files, databases, programming data structures, programming variables, IF-THEN (or similar type) statement constructs, etc.
  • data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.
  • a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code.
  • the software components and/or functionality may be located on a single computer or distributed across multiple computers depending upon the situation at hand.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne des systèmes et des procédés pour fournir un appel voix par protocole Internet (VoIP). Selon un mode de réalisation, un processeur d'équilibrage de charge reçoit une demande HTTP relancée provenant d'un processeur client lors de la détection qu'un serveur d'appel initial n'est plus actif, et envoie la demande HTTP relancée à un second serveur d'appels. Le second serveur génère des informations de ressource d'appel mises à jour qui identifient le second serveur en tant que nouvelle ressource de serveur pour l'appel, et envoie les informations de ressource d'appel mises à jour sur le réseau IP au processeur client. Des demandes HTTP ultérieures provenant du processeur client pour envoyer et recevoir la signalisation et des données média pour l'appel sont reçues au niveau du second serveur à l'aide des informations de ressource d'appel mises à jour.
PCT/US2020/040406 2019-07-04 2020-07-01 Systèmes et procédés d'utilisation de http pour une jonction de téléphonie entre un fournisseur et un consommateur WO2021003209A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962870710P 2019-07-04 2019-07-04
US62/870,710 2019-07-04

Publications (1)

Publication Number Publication Date
WO2021003209A1 true WO2021003209A1 (fr) 2021-01-07

Family

ID=74065918

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/040406 WO2021003209A1 (fr) 2019-07-04 2020-07-01 Systèmes et procédés d'utilisation de http pour une jonction de téléphonie entre un fournisseur et un consommateur

Country Status (2)

Country Link
US (1) US11172069B2 (fr)
WO (1) WO2021003209A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11647072B2 (en) * 2021-01-11 2023-05-09 Ribbon Communications Operating Company, Inc. Methods and apparatus for efficient failure recovery and scaling of a communications system
CN114710445A (zh) * 2022-05-24 2022-07-05 阿里巴巴（中国）有限公司 语音软交换服务方法、装置、系统、电子设备及存储介质

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020046279A1 (en) * 2000-05-09 2002-04-18 David Chung Methods and systems for call processing utilizing a uniform resource locator
US20080063159A1 (en) * 2004-07-02 2008-03-13 Greg Pounds Method and Apparatus for Using the Web to Select a VoIP Provider and for Attaching the Provider to a Generic VoIP Resource
US20100142516A1 (en) * 2008-04-02 2010-06-10 Jeffrey Lawson System and method for processing media requests during a telephony sessions
US20110112901A1 (en) * 2009-05-08 2011-05-12 Lance Fried Trust-based personalized offer portal
US20130054806A1 (en) * 2011-08-31 2013-02-28 Metaswitch Networks Ltd Load Balancing for SIP Services
US20130339781A1 (en) * 2012-06-14 2013-12-19 Vivek WAMORKAR High Availability Conferencing Architecture
US20140269446A1 (en) * 2013-03-15 2014-09-18 Genesys Telecommunications Laboratories, Inc. System and method for geo-location based media recording for a contact center

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020046279A1 (en) * 2000-05-09 2002-04-18 David Chung Methods and systems for call processing utilizing a uniform resource locator
US20080063159A1 (en) * 2004-07-02 2008-03-13 Greg Pounds Method and Apparatus for Using the Web to Select a VoIP Provider and for Attaching the Provider to a Generic VoIP Resource
US20100142516A1 (en) * 2008-04-02 2010-06-10 Jeffrey Lawson System and method for processing media requests during a telephony sessions
US20110112901A1 (en) * 2009-05-08 2011-05-12 Lance Fried Trust-based personalized offer portal
US20130054806A1 (en) * 2011-08-31 2013-02-28 Metaswitch Networks Ltd Load Balancing for SIP Services
US20130339781A1 (en) * 2012-06-14 2013-12-19 Vivek WAMORKAR High Availability Conferencing Architecture
US20140269446A1 (en) * 2013-03-15 2014-09-18 Genesys Telecommunications Laboratories, Inc. System and method for geo-location based media recording for a contact center

Also Published As

Publication number Publication date
US20210006662A1 (en) 2021-01-07
US11172069B2 (en) 2021-11-09

Similar Documents

Publication Publication Date Title
US9473581B2 (en) Integrated web-enabled session border controller
US9509745B2 (en) Java API for programming web real-time communication applications
US9871829B2 (en) Voice over IP (VoIP) network infrastructure components and method
US7660297B2 (en) Voice over IP forwarding
US7936746B2 (en) Multimedia communication session coordination across heterogeneous transport networks
US9692710B2 (en) Media stream management
US7639668B2 (en) Method for securing RTS communications across middleboxes
CN114866521A (zh) 会议服务器
US20070291734A1 (en) Methods and Apparatus for Multistage Routing of Packets Using Call Templates
KR20180015627A (ko) 실시간 통신의 미디어 경로 설정
Wang Skype VoIP service-architecture and comparison
CN113632443B (zh) 用于在公共交换电话网络（pstn）端点和web实时通信（webrtc）端点之间建立通信会话的方法、系统和计算机可读介质
WO2009070646A1 (fr) Interface d'interconnexion réseau-réseau à commutation par paquets
CA2751605A1 (fr) Traversee nat extensible
US11172069B2 (en) Systems and methods for utilizing HTTP for telephony trunking between a provider and a consumer
JP5926164B2 (ja) セッションボーダーコントローラに対する高速振り分け方法及び接続システム
Cumming Sip Market Overview
Lajtha et al. Connection establishment in time critical scenarios
Pang Stream Control Transmission Protocol Support in Session Initiation Protocol Proxy Server
Shen On scalable, robust and secure signaling for next generation internet multimedia services
Segec et al. Research Article A Survey of Open Source Products for Building a SIP Communication Platform

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20834913

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20834913

Country of ref document: EP

Kind code of ref document: A1