Patent classifications
H04L69/40
DATA PAYMENT AND AUTHENTICATION VIA A SHARED DATA STRUCTURE
The disclosed embodiments relate generally to complex data stream control and entitlement. Specifically, the disclosed embodiments provide systems and methods for ensuring that only authenticated/verified participants receive data streams. A third party, e.g., a party other than the data provider or the data recipient, who is nevertheless associated with both the data provider and the data recipient, may be involved in controlling whether data streams from the data provider can reach the data recipient. Thus, a third party may logically sit between the data provider and the data recipient, and may decide whether the data recipient should receive data streams. The disclosed embodiments implement data generation, flow, control and permissioning between multiple entities via digital assets accessed and manipulated on a shared data structure.
RECOVERY FROM A POTENTIAL PROXY CALL SESSION CONTROL FUNCTION (P-CSCF) FAILURE DURING CALL ORIGINATION
A user device registers with a proxy-call session control function device (P-CSCF) associated with an Internet protocol (IP) multimedia subsystem (IMS). The user device forwards a request to the P-CSCF requesting a session via the IMS for an IMS call. If a response to the request is not received from the P-CSCF during a time period after forwarding the request, the user device attempts to newly register with the P-CSCF. If the new registration is successful, the user device re-forwards the request to the P-CSCF. Otherwise, if the new registration with the P-CSCF is unsuccessful, the user device registers with a different P-CSCF and forwards the request to the second P-CSCF.
SUPPORTING HITLESS UPGRADE OF CALL PROCESSING NODES IN CLOUD-HOSTED TELEPHONY SYSTEM
A method is provided in which a call agent process that supports one or more Internet Protocol (IP) calls, stores to persistent memory a set of data associated with the one or more IP calls. An outage is detected affecting the one or more IP calls. Using the data retrieved from the persistent memory, the one or more IP calls are resynthesized using a device simulator process to simulate connectivity with endpoints that were participating in the one or more IP calls prior to the outage. After resynthesizing, depending on activity detected from devices associated with the one or more IP calls, the one or more IP calls are internally re-stitched/re-establishing (without signaling to endpoints) with the endpoints involved in the one or more IP calls, or the one or more calls are fully re-stitched/re-established by signaling an endpoint that was participating in the one or more IP calls.
RETURN AND REPLACEMENT PROTOCOL (RRP)
Systems and methods provide for managing faulting network devices. A first network device can receive an error. The first network device can generate one or more frames including data indicative of the error. The first network device can broadcast the one or more frames to one or more neighboring network devices. It may be determined that the first network device is inaccessible. The first data can be retrieved and presented from a second network device among the one or more neighboring network devices. In some embodiments, a network management system can utilize the first data to generate a machine learning model that classifies whether network devices are instances of network devices designated for a Return Merchandise Authorization (RMA) process. In some embodiments, the network management system can apply the first data to a machine learning classifier to determine whether to initiate the RMA process for the first network device.
AUTOMATED MULTI-NETWORK FAILOVER FOR DATA CENTERS
A device may monitor a status of a first data center of a group of data centers. The device may determine, based on the status of the first data center, to cause a failover from the first data center to a second data center. The device may cause a domain name server (DNS) configuration, associated with an external DNS, to be and a set of DNS entries, associated with an internal DNS, to be altered to cause a portion of the network traffic, respectively associated with a first network and a second network of the plurality of networks, to be routed the second data center. The device may cause a load balancer configuration to be altered to cause a portion of the network traffic associated with a third network of the plurality of networks to be redirected from the first data center to the second data center.
APPLICATION PROGRAM INTERFACE ENDPOINT MONITORING
A computer-implemented method to monitor application program interface (API) endpoints may include sending, over a network from a computing system, a test structure to an API endpoint. In some embodiments, the test structure may be configured based on the API endpoint. The method may further include receiving a first response over the network at the computing system from the API endpoint in response to sending the test structure and resending, over the network from the computing system, the test structure to the API endpoint. The method may further include receiving a second response at the computing system from the API endpoint in response to resending the test structure and comparing, at the computing system, the first response and the second response. The method may further include determining, at the computing system, a status of the API endpoint based on the comparison of the first response and the second response.
DETERMINING MANIFEST FILE DATA USED IN ADAPTIVE STREAMING VIDEO DELIVERY
Techniques for serving a manifest file of an adaptive streaming video include receiving a request for the manifest file from a user device. The video is encoded at different reference bitrates and each encoded reference bitrate is divided into segments to generate video segment files. The manifest file includes an ordered list of universal resource locators (URLs) that reference a set of video segment files encoded at a particular reference bitrate. A source manifest file that indicates the set of video segment files is identified based on the request. An issued manifest file that includes a first URL and a second URL is generated based on the source manifest file. The first URL references a first domain and the second URL references a second domain that is different from the first domain. The issued manifest file is transmitted to the user device as a response to the request.
Content delivery network architecture with edge proxy
Aspects of the present disclosure involve systems, methods, computer program products, and the like, for a content delivery network (CDN) architecture utilizing one or more proxy cache devices between a requesting device and an edge cluster of the CDN. The proxy cache device is a relatively high speed device compared to various possible devices making up one or more edge clusters. Thus, if the proxy has cached the requested content, it is capable of directly servicing the client content request at a faster rate than providing the content from the edge cluster. Otherwise, the proxy cache may request the content from an edge cluster and store the content for quick retrieval in response to additional requests for the content. In one embodiment, the proxy cache may perform an analysis of the request or a series of requests to determine if the content is cached at the proxy cache device.
Connectivity analysis and a mass storage system capable of connectivity analysis
A mass storage system obtains an hierarchical cluster mapping information; Host port state information, which is indicative of a state of at least one host port, is received from an intermediate device of a network that couples hosts to the mass storage system; The mass storage system estimates a state of an entity, which may be one or more host computers or a cluster of host computers. The estimating is based on the hierarchical cluster mapping information and the host port state information. The mass storage system determines whether to generate an alert, in response to the estimated state of the at least one entity. If it is determined to generate an alert then an alert is generated.
Semi-automatic failover
Semi-automatic failover includes automatic failover by a service provider as well as self-serviced failover by a service consumer. A signal can be afforded by a service provider based on analysis of an incident that affects the service provider. Initiation of self-serviced failover by a service consumer can be predicated on the signal. In one instance, the signal provides information that aids a decision of whether or not to failover. In another instance, the signal can grant or deny permission to perform a self-serviced failover.