Quality of service for web real-time communication networks

A request to establish an encrypted media stream is received, by an edge server, for a Web Real-Time Communication (WebRTC) communication session between a first browser, and a second browser or gateway. The edge server is a boundary device between a first network and a second network. The edge server retrieves a tenant identifier for the encrypted media stream. The tenant identifier can identify a specific company or enterprise. In response to receiving the tenant identifier for the encrypted media stream for the WebRTC communication session, a list of one or more Quality-of-Service (QoS) parameters associated with the tenant is retrieved. For example, the list of QoS parameters may be based on a Service Level Agreement (SLA). The edge server dynamically sends a message to configure the second network to support the list of one or more QoS parameters associated with the tenant.

TECHNICAL FIELD

The systems and methods disclosed herein relate to communication systems and in particular to Web Real-Time Communication (WebRTC) communication systems.

BACKGROUND

WebRTC is designed to prevent man-in-the-middle attacks by providing end-to-end encryption of communication sessions between browsers. However, this end-to-end encryption prevents intermediate entities to enforce Quality of Service (QoS) across network elements for the WebRTC communications coming into an enterprise or contact center. For example, a type of priority level cannot be defined for the network elements because the end-to-end encryption is directly sent between the browsers.

BRIEF SUMMARY

Systems and methods are provided that can enforce QoS across network elements for WebRTC communications.

A request to establish an encrypted media stream can be received, by an edge server, for a Web Real-Time Communication (WebRTC) communication session between a first browser, and a second browser or gateway. The edge server is a boundary device between a first network and a second network. The edge server retrieves a tenant identifier for the encrypted media stream. The tenant identifier can identify a specific company or enterprise.

In response to receiving the tenant identifier for the encrypted media stream for the WebRTC communication session, a list of one or more Quality-of-Service (QoS) parameters associated with the tenant is retrieved. For example, the list of QoS parameters may be based on a Service Level Agreement (SLA). The edge server dynamically sends a message to configure the second network to support the list of one or more QoS parameters associated with the tenant. For example, the edge server dynamically sends the message to a Software Defined Network (SDN) controller that dynamically configures network elements, such as routers, to provide the necessary QoS.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a first illustrative system100for providing QoS for WebRTC communications. The first illustrative system100comprises browsers101A-101B, networks110A-110B, an edge server120, a WebRTC application123, a Software Defined Network (SDN) controller124, and a Software Defined Network (SDN)140.

The browser101can be or may include any browser101that can be loaded on a communication device, such as Internet Explorer™, Google Chrome™, Safari™, Firefox™, Safari™, Opera™, and/or the like. The browser101can run on a variety of communication devices, such as a Personal Computer (PC), a video system, a cellular telephone, a Personal Digital Assistant (PDA), a tablet device, a notebook device, a smart phone, and the like. WhileFIG. 1only shows two browsers101A-101B, any number of browsers101may be in each of the networks110A-110B.

The networks110A-110B can be or may include any collection of communication equipment that can send and receive electronic communications, such as the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), a Voice over IP Network (VoIP), the Public Switched Telephone Network (PSTN), a packet switched network, a circuit switched network, a cellular network, a combination of these, and the like. The networks110A-110B can use a variety of electronic protocols, such as Ethernet, Internet Protocol (IP), Session Initiation Protocol (SIP), Integrated Services Digital Network (ISDN), WebRTC, Real-Time Protocol (RTP), Real-Time Control Protocol (RTCP), and/or the like. Thus, the networks110A-110B are electronic communication networks configured to carry messages via packets and/or circuit switched communications.

The network110A is typically a public network, such as the Internet, the Public Switched Telephone Network (PSTN), and/or the like. The network110B is typically a private network, such as a corporate or enterprise network. However, the networks110A-110B may be two private networks or two public networks.

The networks110A-110B also comprises one or more routers130A-130B. The routers130A-130B are used to route packets across the networks110A-110B.

The edge server120is a hardware device with a processor that executes software. The edge server120provides a boundary between the network110A and the network110B. Although not shown, the edge server120typically provides services, such as a firewall, a Network Address Translator (NAT), a Representational State Transfer (REST) server, a reverse proxy, and/or the like. The edge server120also comprises a media relay121and a policy enforcer122.

The media relay121is used to relay media in a WebRTC media stream. The media stream can be for a voice communication, a video communication, a data communication, and/or the like. The media relay121, in conjunction with the WebRTC application123typically uses RTP or RTCP for a WebRTC communication. The media relay121is a bridge for a media stream sent between the browser101A and the browser101B (or possibly a gateway).

The WebRTC application123is a web server application123that is used in establishing a WebRTC communication session between the browser101A and the browser101B. For example, the WebRTC application123is used to exchange Datagram Transport Layer Security (DTLS) fingerprints between the browser101A and the browser101B so that an encrypted media stream between the browser101A, the media relay121, and the browser101B can be established. During the establishment of the communication session between the browser101A and the browser101B, the WebRTC application123receives QoS information and a tenant identifier (if there is one) for the communication session via an out-of-band link between the edge server120and the WebRTC application123. For example, a specific type of codec may be identified for a voice communication (used by the media relay121). Establishment of the media stream can be accomplished as described in U.S. patent application Ser. No. 14/282,974 filed Jun. 9, 2014 entitled “FIREWALL TRAVERSAL FOR WEB REAL-TIME COMMUNICATIONS,” which is incorporated herein in its entirety by reference.

The Software Defined Network (SDN) controller124can be or may include any hardware coupled with software that can control various elements in the network110B, such as the router(s)130, a gateway, a media server, a communication device, and/or (e.g., a network resource) the like. The SDN140is a network that is defined where the higher level functionality is abstracted from the underlying systems. In this case, the underlying systems that are used to provide QoS (e.g., such as the router(s)130B). The SDN140comprises the browser101B and the WebRTC application123.

FIG. 2is a block diagram of a second illustrative system200for providing QoS for WebRTC communications for a plurality of Software Defined Networks (SDNs)140A-140N. The second illustrative system200comprises browsers101A-101N, the networks110A-110B, the edge server120, WebRTC applications123A-123N, the SDN controller124, SDNs140A-140N, a gateway250, and a communication device251.

The gateway250can be any hardware/software that can provide a gateway between WebRTC and another protocol, such as, Session Initiation Protocol (SIP) or H.323. The communication device251can be any device that can be used to communicate with a browser101(e.g., via the gateway250), such as a Personal Computer (PC), a video system, a cellular telephone, a Personal Digital Assistant (PDA), a tablet device, a notebook device, a smart phone, and the like.

InFIG. 2, the network110B is partitioned into two SDNs140A-140N. Although only two SDNs140A-140N are shown, any number of SDNs may be portioned. The SDN140A comprises the browser101B and the WebRTC application123A. The SDN140N comprises the browser101N, the WebRTC application123N, the gateway250, and the communication device251. InFIG. 2, the SDNs140A-140N are partitioned by the SDN controller124into the two separate SDNs140A-140N. The two separate SDNs140A-140N may be partitioned based different tenants. For example, two different corporations may use the infrastructure of the network110B (e.g., routers130B) as two separate SDNs140A-140N. By having different SDNs140A-140N for different tenants, the edge server120/SDN controller124can dynamically configure the infrastructure in the network110B (e.g., the routers130A) to provide different levels of QoS for each tenant's SDN140. The edge server120/SDN controller124can dynamically configure bandwidth usage for different tenants based how much bandwidth is available. For example, the edge server120/SDN controller124can reduce the available bandwidth that one tenant can use based on another tenant that is consuming it allotted amount of bandwidth.FIG. 3is a block diagram of a third illustrative system300for providing QoS between a Virtual Local Area Network (VLAN) and a plurality of Software Defined Networks (SDNs). The third illustrative system300comprises browsers101A-101N, the networks110A-110B, the WebRTC applications123A-123N, the SDN controller124, the SDN networks140A-140N, a private cloud edge server320, WebRTC media servers360A-360N, and Virtual Local Area Networks (VLANs)370A-370N.

The private cloud edge server320is a cloud based edge server120. The private cloud edge server320is a hardware server. The private cloud edge server120comprises the media relay121and the policy enforcer122.

The WebRTC media servers360A-360N can be any hardware server that can stream media, such as a video server, a conference bridge, an audio server, and/or the like. The media servers360A-360N stream a media stream to the browsers101A-101N.

The SDN140A comprises the WebRTC application123A and the WebRTC media server360A. The SDN140N comprises the WebRTC application123N and the WebRTC media server360N. The SDN controller124is used to partition the SDNs140A-140N for different tenants. For example, the SDN controller124identifies devices, applications, WebRTC media servers360, associated with different tenants to create the SDNs140A-140N.

The VLANs370A-370N are sub-divided networks that are portioned at the data link layer (of the Open Source Interconnect (OSI) model). The VLANs370A-370N are similar to the SDNs140A-140N except that the partitioning is done at a lower layer than the SDNs140A-140N.

The private cloud edge server320maintains a mapping of VLAN tags for communication devices251(devices running the browsers101A-101B) in VLAN370A. The private cloud edge server320uses a corresponding identifier defined by the SDN controller124to send a communication session to an individual SDN140. For example, when browser101A wants to stream a video from the WebRTC media server360A, the initial WebRTC request will include the VLAN tag for VLAN370A. The private cloud edge server320uses the corresponding SDN identifier provided by the SDN controller124to establish the WebRTC communication session between the browser101A and the WebRTC media server360A. A similar process is used for the VLAN370N and the SDN140N.

InFIG. 3, the parameters, such as QoS parameters, can be enforced in either direction. For example, if a call is made from the SDN140A (via a browser101, not shown), the parameters/QoS parameters of the SDN140A may be enforced in the VLAN370A. This can be done by sending the QoS parameters to configure network elements in the VLAN. For example, by the private cloud edge server320sending a QoS parameter to configure a codec in a communication device251with the browser101A.

The SDN140A comprises the edge server120A, the WebRTC application123A, and the WebRTC media server360A. The SDN140B comprises the edge server120B, the WebRTC application123B, and the WebRTC media server360B. The SDN140N comprises the edge server120N, the WebRTC application123N, and the WebRTC media server360N. The SDNs140A-140N may be in different physical locations. For example, the SDN140A may be located in the United States, the SDN140B may be located in Europe, and the SDN140N may be located in Asia.

The SDN controller124controls requests from the browser101to access the WebRTC media servers360A-360N. In addition, the SDN controller124receives QoS information from each of the edge servers120A-120N. The QoS information can include information, such as, capacity, bit rate, throughput, present traffic, jitter information, supported codecs, and/or the like. The QoS information may be gathered by the edge servers120A-120N from various network elements, such as the routers130, the gateway250, the WebRTC media servers360, the communication device251, and/or the like. The SDN controller124uses the received QoS information to determine a specific edge server120to send the request to. For example, under normal conditions, if the browser101makes a request from the United States to access the WebRTC media server360, the request will be directed to the WebRTC media server360that is closest (e.g., in the United States). If the edge server120in the United States is heavily loaded (e.g., where taking the request would violate a Service Level Agreement (SLA)), the SDN controller124can send the request to a different edge server120(and a different WebRTC media server360) that will be in compliance with the SLA. Different customers may have different SLA agreements that require different QoS. For example, if the United States edge server120was heavily loaded, one customer may be redirected to a different edge server120while another customer would not be redirected to the different edge server120under the same conditions.

Alternatively, the edge servers120A-120N can send the information to one another. The edge server120receives the request to initiate a WebRTC communication session. If the edge server120is heavily loaded and cannot support the request, the edge serve120can redirect the request to a different edge server120that is not as heavily loaded. The redirection can be based on a SLA.

InFIG. 4, each SDN140A-140N comprises a WebRTC application123A-123N. However, in some embodiments, there may be only a single WebRTC application123used to establish the communication sessions for each of the SDNs140A-140N.

FIG. 5is a flow diagram of a process for providing QoS for WebRTC communications. Illustratively, the browsers101A-101N, the edge servers120A-120N, the media relay121, the policy enforcer122, the WebRTC applications123A-123N, the SDN controller124, the routers130A-130B, the gateway250, the communication device251, and the WebRTC media servers360A-360N are stored-program-controlled entities, such as a computer or processor, which performs the methods ofFIGS. 5-6and the processes described herein by executing program instructions stored in a computer readable storage medium, such as a memory or disk. Although the methods described inFIGS. 5-6are shown in a specific order, one of skill in the art would recognize that the steps inFIGS. 5-6may be implemented in different orders and/or be implemented in a multi-threaded environment. Moreover, various steps may be omitted or added based on implementation.

The process starts in step500. The edge server120/320determines in step502if a request to establish and encrypted WebRTC media stream has been received. If a request to establish an encrypted WebRTC media stream has not been received in step502, the process repeats step502.

Otherwise, if a request to establish an encrypted WebRTC media stream has been received in step502, the QoS policy enforcer122retrieves the parameters/QoS parameters and/or the tenant identifier (if there is one) associated with the media stream in step504. Retrieving the parameter(s)/QoS parameter(s)/tenant identifier can occur in different ways. For example, when a request to establish an encrypted WebRTC media stream is received, the edge server120/320may see the request. For example, the edge server120/320may include a reverse proxy server (not shown) that proxies the request to the WebRTC media application123.

In another embodiment, the tenant identifier/parameter(s) of step504may be retrieved via an out-of-band communication with the WebRTC application123. For example, the QoS policy enforcer122may retrieve the tenant identifier by sending a message to the WebRTC application123. Alternatively, the WebRTC application123may automatically send the tenant identifier to the edge server120when the request to establish the encrypted media stream is received in step502. The tenant identifier may be based on an IP address and/or port. The QoS policy enforcer122may receive the parameter(s)/tenant identifier via RTP or RTCP.

The QoS policy enforcer122determines if there is a tenant identifier associated with the media stream in step506. If there is a tenant identifier associated with the media stream in step506, the QoS policy enforcer122retrieves parameter/QoS parameter(s) associated with the tenant in step508. For example, the QoS policy enforcer122may retrieve a list of parameters/QoS parameters that are associated with a Service Level Agreement (SLA) from a database. The parameters/QoS parameters in the SLA may define a particular codec, a jitter level, a packet priority, a routing path, and/or the like. A SLA may be different for each tenant. For instance, one tenant may have a higher priority for jitter and packet priority than another tenant. A tenant may be an individual person, a group of persons, an organization, a company, and/or the like. The process then goes to step512.

Otherwise, if there is not a tenant identifier in step506, the QoS policy enforcer122uses the retrieved parameters/QoS parameters received in step504(or a default list of parameters/QoS parameters). The QoS policy enforcer122sends a message, to the SDN controller124to configure the network110B to support the one or more parameters/QoS parameters in step512. The message of step512can be defined in various ways, such as defining a priority level based on a source/destination port and/or IP address. The message is used to access Application Programming Interfaces (APIs) exposed by the SDN controller124for controlling network elements (e.g., the routers130B).

The SDN controller124controls QoS for network elements in the network110B. For example, the SDN controller124can control the routers130, the gateway250, the communication device251, the WebRTC media servers360, network interface cards, and/or the like to support the one or more parameters/QoS parameters. The parameters/QoS parameters can control other network resources, such as a CPU(s) in a server, virtual machines, network interface cards, disk space, memory usage, and/or the like. The parameters/QoS parameters can be based on a specific tenant or SLA. For example, the SDN controller124can define (based on the message of step512) a particular route (or routes) for packets in the media stream, a level of jitter for the media stream, a packet priority for the media stream, and/or the like. The SDN controller124can control the parameters/QoS parameters differently for different network elements based on different tenants.

After sending the message to the SDN controller124, in step512, the edge server120determines if the process is complete in step514. If the process is complete in step514, the process ends in step516. Otherwise, the process goes back to step502.

In one embodiment, the WebRTC application123can control the SDN controller124instead of the QoS policy enforcer122. In this embodiment, the WebRTC application123sends the message to the SDN controller124to set the parameters/QoS parameters.

The process ofFIG. 5can be used for the system defined inFIG. 1where there is only a single SDN140. In this case, there would not be a tenant identifier.

The process ofFIG. 5can be used for the system defined inFIG. 2where there are two or more Software Defined Networks (SDN)140A-140N. For example, a user of the browser101A can make a voice call to the browser101B via the SDN140A. Similarly the user of the browser101C can make a video call to the browser101N via the SDN140N. In this example, each of the SDNs140A-140N would use a different tenant identifier.

The process ofFIG. 5can also be used for the system defined inFIG. 3. In this example, a user of the VLAN370A at one of the browsers101A-101B can communicate via the VLAN370A to the WebRTC media server360A. Likewise, a user of the browsers101C-101N can communicate via the VLAN370N to the WebRTC media server360N. The private cloud edge server320maintains a VLAN tag for each VLAN370A-370N and an identifier for the SDNs140A-140N to map between the two VLANs370A-370N and the two SDNs140A-140N. The QoS may be accomplished based on different tenants and their respective SLAs.

The process ofFIG. 5can also be used for the system defined inFIG. 4. For example, after the edge server120A-120N has been selected based on a parameter/QoS parameter, the process ofFIG. 5can be implemented for communications to and from the respective SDNs140A-140N.

In one embodiment, the edge server120/320can configure the parameters/QoS parameters based on a WebRTC call volume at the edge server120/320. For example, if the first tenant has a higher priority than a second tenant, the edge server120/320can dynamically reduce the priority or bandwidth in one or more network resources for the second tenant based on a call volume at the edge server120/320.

In another example, if the SDN140A for tenant 1 is configured with 4 virtual CPUs, X bandwidth, Y network interface card and the SDN140N for tenant 2 is configured with 2 virtual CPUs, Z bandwidth and K network interface card. If a SLA for tenant 2 states that tenant 2 has more preference than tenant 1 and volume/usage for tenant 2 increases (as seen by increase in traffic on corresponding vlan tag), the SDN controller124can dynamically allocate resources from tenant 1 to tenant 2.

FIG. 6is a flow diagram of a process for determining an edge server120/320. The process starts in step600. The SDN controller124, WebRTC application123, and/or edge server120/320determines in step602if a request to establish an encrypted media stream is received in step602. If a request to establish an encrypted media stream is not received in step602, the process of step602repeats.

Otherwise, if a request to establish an encrypted media stream is received in step602, the SDN controller124, WebRTC application123, and/or edge server120/320determines if the closest edge server120/320meets the QoS of the tenant in step604. The SDN controller124, WebRTC application123, and/or edge server120/320, each, or in combination can determine the closest edge server120/320to meet the QoS. For example, the edge servers120A-120may communicate their QoS information to each other. Alternatively, the SDN controller124or the WebRTC application123(where there is a single or master WebRTC application123) may query/receive messages from the edge servers120A-120N. If the closest edge server120/320meets the necessary QoS, the request is sent to the closest edge server120/320in step606and the process goes back to step602.

Otherwise, if the closest edge server120/320does not meet the QoS of the tenant, the SDN controller124, WebRTC application123, and/or edge server120/320determines the best edge server120/320in step608. The SDN controller124, WebRTC application123, and/or edge server120/320sends the request to the best edge server120/320in step610and the process goes to step602. For example, the SDN controller124may determine that an edge server120/320in the United States is overloaded and redirect the request to the edge server120/320in Asia.

In one embodiment, the process may not identify the closest edge server120/320. For example, step604may be to determine the best edge server120/320regardless of location.

Of course, various changes and modifications to the illustrative embodiment described above will be apparent to those skilled in the art. These changes and modifications can be made without departing from the spirit and the scope of the system and method and without diminishing its attendant advantages. The following claims specify the scope of the disclosure. Those skilled in the art will appreciate that the features described above can be combined in various ways to form multiple variations of the disclosure. As a result, the disclosure is not limited to the specific embodiments described above, but only by the following claims and their equivalents.

The term “module” as used herein refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software that is capable of performing the functionality associated with that element. Also, while the disclosure is described in terms of exemplary embodiments, it should be appreciated that individual aspects of the disclosure can be separately claimed. As will be appreciated by one skilled in the art, aspects of the present disclosure may be embodied as a system, method or computer program product. Accordingly, aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.