Patent Description:
<CIT> describes a telecommunication device for real-time communication (RTC) at a border between a global transport network and a private domain of a communication network. The telecommunication device comprises means for creating mutual trust between the telecommunication device and a communication participant and a traverser for real-time traffic to traverse a firewall or an interface for opening a path for real-time traffic through the firewall. <CIT> describes a mobile host that includes a micro-mobility management daemon that monitors the mobile host's movement between base stations. <CIT> describes a distributed application of enterprise policies to WebRTC interactive sessions. <CIT> discloses a method of providing a virtual Back-to-Back WebRTC communications agent by establishing a first interactive WebRTC connection between a first WebRTC client and a virtual WebRTC agent and by establishing a second interactive WebRTC connection between a second WebRTC client and a virtual WebRTC agent.

The current global telephone network, the PSTN (Public Switched Telephone Network), is built for voice communication of limited bandwidth (only <NUM>). Broadband networks, e.g. the Internet, can also be used for real-time person-to-person communication, e.g. voice communication, often called VoIP (Voice over Internet Protocol). The Internet transports data between endpoints, regardless of the data content or the application and is therefore called a transport network.

VoIP, or more generally Real Time Communication (RTC), is also used for multimedia communication beyond the Plain Old Telephony Service (POTS), e.g. video, presence and instant messaging. There are standards and drafts for RTC, often defined by the Internet Engineering Task Force (IETF).

Session Initiation Protocol (SIP, RFC <NUM>) is a widely used protocol for RTC. RFCs (Request For Comments) are Internet standards defined by the IETF. Web Real-Time Communication (WebRTC) is RTC built into web browsers under development and standardization by IETF and World Wide Web Consortium (W3C).

RTC protocols are used to establish media streams such as voice and video, between endpoint devices, often providing telephony-like functions and services. They often define the call setup procedure, which is how a call is initiated, done and completed.

A data communication network is typically a packet switch network like the Internet, forwarding packets of data to destinations specified by the address of the packets. The packets typically also contain the source address from which it was sent. Data packets may be messages containing requests, responses, or data representing documents, files or media like movies and voice and are exchanged between endpoints.

A data communication network may also include private segments, intranets, or Local Area Networks (LANs) that communicate with the global network through a Network Address Translator (NAT) or firewall, which often are combined and just called either NAT or firewall or sometimes access router.

In a packet switched network, traffic is data packets being sent and received.

Real-time traffic is streams of voice or other media like video. Such media streams are used by telephony-like services or calls over a network.

A media path transports such media stream over a network, which may consist of several network segments of different types.

Endpoints such as various devices, clients and servers have one or several network interfaces like Ethernet, WiFi or LTE radio interfaces, with which they connect to network access points.

An address in a network may be a number (like an IPv4 or an IPv6 address) or a symbolic address, like a Fully Qualified Domain Name (FQDN), that is further resolved into a number address, e.g. by a Domain Name System (DNS) service.

Such addresses may also be further specified by port numbers, to indicate a protocol being used or simply used as an extension to the address types exemplified above (e.g. an IPv4 address with specified port <NUM>. <NUM> :<NUM>), which in this context may be one form of a network address in general.

Endpoints such as various devices, clients and servers have one or several addresses in a network, at which they can send or receive traffic. Typically, the address to an endpoint is dependent of network interface of the endpoint and the access point of the network.

A server is a network device accessed by clients. The client can be a program on a computer or a device connected to the network.

An application server is a server offering a service or a function to users.

Network access points have different locations and can use different fixed access technologies such as Ethernet, ADSL modems, cable modems, fiber and various wireless and mobile technologies such as WiFi, <NUM>, <NUM>, LTE and more.

In addition to general network segments like the public Internet and private intranets or LANs, there are application specific network segments, e.g. telephony type of networks that carry signaling and media for voice and maybe for video, but not general data traffic. Voice over IP (VoIP) may be either over a general data network like the Internet or Over The Top (OTT) as it is called in the mobile world, or over an application specific network segment like Voice over LTE (VoLTE) that uses IP networks.

Signaling are typically messages in signaling channels between endpoints, proxies and servers over network segments. The signaling over a signaling channel can be interrupted, e.g. when loosing wireless coverage, changing interface of a device or changing access point of a network segment, but can thereafter be recovered to reestablish signaling connectivity.

Firewalls and NATs typically block real-time communication, an issue that either is resolved by Session Border Controllers (SBCs) at the edge of the private network or by methods or protocols such as e.g. Session Traversal Utilities for NAT (STUN, RFC <NUM>), Traversal Using Relays around NAT (TURN, RFC <NUM>) and Interactive Connectivity Establishment (ICE, RFC <NUM>).

A TURN server relays traffic between two network addresses and is an example of a relay server. A TURN server can be discovered by an RTC endpoint and in a sealed network segment it then has to be used for RTC media traffic outside the sealed network segment.

SBCs also implement security and interoperability functions for VoIP and RTC and are often used for connecting Internet Telephony Service Provider's (ITSP's) VoIP services to IP-PBXs, also called SIP trunking.

An IP-PBX is an Internet Protocol (IP) Private Branch exchange (PBX).

Call centers are most often based on IP-PBXs or Unified Communications (UC) solutions receiving calls via an ITSP's SIP Trunk. These calls are typically initiated via toll free numbers (<NUM> numbers in the US) from the telephony network.

PBX or UC functionality can be Interactive Voice Response (IVR), Queues, Voice and Video mail.

Instant Messaging (IM), presence, screen sharing and group calls are other RTC functions.

A protocol is a set of rules defining language and methods of communication.

An example is the Session Description Protocol (SDP, RFC <NUM>) that describes which media and codecs to use and where the media should be sent. Such real-time communication can be offered by one endpoint to another endpoint that can answer with its willingness and media capabilities to set up media communication session between the endpoints. That is an Offer and Answer protocol (O/A protocol).

The O/A protocol typically determines the media types, e.g. voice and video specifying which codec to use.

Such O/A protocol may also suggest methods and candidates how to set up the media path between endpoints, as e.g. defined by the ICE protocol for NAT traversal.

A media path is typically set up for the purpose of real-time communication, while the wider term communication path refers to a direct or indirect channel for transferring data that may or may not represent media.

A media endpoint is an endpoint to which a media path over a network is coupled to allow media streams to flow, typically containing real-time traffic representing voice or video.

An established media path between media endpoints that is set up again is said to be reestablished.

A media endpoint has peer-to-peer media capability if it can set up a media path directly to another media endpoint with or without going through a server, e.g. a TURN server. Mutual peer-to-peer media capability means that two endpoints are compatible and can set up a direct media path between each other.

The Session Initiation Protocol (SIP) is used to find users and set up calls between SIP clients, their real-time communication devices, e.g. hardware SIP phones or software SIP phones being a software application on a computer. SIP is a signaling protocol using registrar and proxy servers to find users and further uses the SDP O/A protocol to establish a media channel between SIP client endpoints. A SIP client typically includes the SIP user agent, interfacing users to the SIP proxy.

Web Real Time Communication (WebRTC) is a set of recommendations and protocols under standardization for extending web browsers to allow real-time communication between them. WebRTC does not specify the signaling for finding users, but allows web browsers connected to the same web server to establish a media channel for real-time communication between them, using the SDP O/A protocol. WebRTC uses the ICE protocol, including STUN and TURN, to set up a media path between the WebRTC media endpoints.

RTC devices including media endpoints may therefore be implemented in WebRTC browsers, which retrieve their program code (in HTML and Java Script) from web servers.

With WebRTC, the media streams are encrypted using the DTLS-SRTP protocol and are protected against "man in the middle" attacks. The protection involves exchange of fingerprints (digital signatures of the certificates used for the encryption key generation) between the parties over another channel or path than used for generating the encryption keys. This means that the media traffic cannot be decrypted by just intercepting the media path or the signaling path.

A web browser is a program running on computers or smartphones for accessing the World Wide Web (the web), a service on the Internet or an Intranet implemented on a web server.

Software applications are other programs running on computers or smartphones.

A web server may transfer program code, typically Java Script, to a web browser for execution therein, which is a technology used with WebRTC.

A HyperText Transfer Protocol (HTTP) URL (or simply "a link") identifies a web resource and specifies the acting upon executing it. For example, a URL may refer to the web resource Zwiki/Main_Page whose related program code is obtainable via HTTP from a server whose domain name may be example. org preceding the /wiki/Main_Page.

Executing a HTTP URL in a WebRTC browser, may initiate a call to be setup from the web server being addressed, which is a useful feature of the emerging WebRTC technology. Such URL may contain a telephone number and other information of the call to setup, e.g. a limitation in time for when the URL can be used for calling.

WebRTC HTTP URLs may be long and obscure and there are services shortening links, such as Bitly, using its short domain name bit. ly after a unique string that represents a long HTTP URL that Bitly has stored, so when a URL is executed in a web browser, it goes to Bitly that redirects it to the full long web link.

Such WebRTC click-to-call link can be generated by and stored in a WebRTC server that will be called when clicked in a browser. A shortened link, e.g. consisting of a unique string followed by the domain name of the server, would be passed to the user that is intended to execute it in a WebRTC browser. Time limiting can be implemented by encrypting the last valid time or simply by only storing the link translation in the WebRTC server for as long as it is valid.

Click-to-call links, or buttons executing such links, can also be used on Web sites and are then often context-sensitive, i.e. they can carry information of whom that clicked the link, which selections that may have been made, when it was clicked and from where it was clicked.

Some browsers support WebRTC, some do not, some do it better than others. It may therefore be advantageous to define and identify a specific domain name extension, e.g. wrtc in wrtc. com, in a WebRTC HTTP URL link for invoking WebRTC functionality, that otherwise may not be available.

Gateways are used to convert between different network segments or protocols to allow a service to function between more users.

Clients access their servers when needed, but RTC clients, e.g. SIP or WebRTC clients, also need to maintain a connection to their server for incoming signaling, for an incoming call or for reestablishing a media path for an ongoing call.

A media endpoint typically knows between which addresses a media path, carrying media traffic (a media stream) is setup and can thereby determine if it is dependent on a particular address change.

Smartphones, that are mobile devices, may go to sleep when not in use to save remaining battery time, but can often be woken up to e.g. receive a message or prepare for an incoming VoIP call by so called push notifications from a centralized push notification server.

VoIP, softclients, smartphones and extended communication possibilities and functionality with RTC, are making the Graphical User Interface (GUI) of RTC clients important. One way of improving the GUI is to organize contacts (persons or users) in separate lists based on the call state (e.g. idle, active, in a group call, on hold, in queue n, in transfer, incoming unanswered calls etc.), where each contact (in a list, or single) have an expandable action menu listing currently available selections (e.g. Call, Hang-up, Transfer, Hold, Connect in conference, Mute/Un-mute Video, Mute/Un-mute Voice, Send message, Change presence and possibly also administrative tasks). Such menu can be expanded through a small symbol, e.g. the three vertical dots symbol or the menu lines symbol, commonly used by smartphones, at the line of the contact.

In a real time media channel, Dual Tone Multi Frequency (DTMF) digits can be transferred either encoded as audio or out-of-band in data packets. DTMF defined symbols are <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, #, *, A, B, C and D.

With modern networks and telecommunication devices, servers and gateways having processors coupled to memory, telephony is evolving to real-time communication, RTC, and a call is setup up via a signaling channel over the network followed by establishment of media paths over the network where the RTC media traffic, like voice or video, can flow between media endpoints.

The invention is defined by a method for establishing a media path between endpoints for intercepting and decrypting media traffic according to claim <NUM>, a method for establishing a media path between endpoints for intercepting and decrypting media traffic according to claim <NUM>, a system according to claim <NUM> and a software module according to claim <NUM>. Further embodiments mentioned in the description which are not covered by the claims are to be seen as illustrative examples for a better understanding of the invention.

The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments of the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use of the invention. In the drawings, like reference numbers indicate identical or functionally similar elements. A more complete appreciation of the invention and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:.

A method for establishing or reestablishing a media path between endpoints according to an embodiment is shown in <FIG>, where endpoints have one or more network interfaces <NUM> of different types and are connected to network access points <NUM> at different types of network segments <NUM>, <NUM>, <NUM>, to implement handover of calls.

Mobile phones typically allow a call to be maintained and continue when accessing the telephony network through different cell towers. Similarly, this embodiment of establishing and reestablishing of media streams allows Real Time Communication devices (RTC devices) <NUM> (e.g. software clients or applications on smart phones), to maintain an ongoing call when network access points are changed, when using different network interfaces (e.g. fixed Ethernet, Wi-Fi, mobile <NUM> data and LTE) and via various network access service providers.

To achieve this capability to handover calls, a Real Time Communication device (RTC device) <NUM> including a media endpoint <NUM> and the other media endpoint <NUM> to communicate with, have peer-to-peer media capability by using an Offer and Answer protocol (O/A protocol) <NUM> to establish and reestablish a media path <NUM> between them. Such media path may pass a firewall or NATs shown in <FIG> and a TURN server shown in <FIG>.

Both endpoints can be connected to a server <NUM> reachable at some address <NUM> from access points <NUM> at the network segments <NUM>, <NUM> and <NUM>, where the endpoints will be used;.

The RTC device (<NUM>) is via at least one network interface (<NUM>) connected to some network access point <NUM> establishing a signaling channel to or through the server <NUM> by sending and receiving messages <NUM>.

The RTC device <NUM> may reach the server <NUM> via a FQDN looked up in DNS even if the numeric address of the server <NUM> may have changed, due to access via another network segment <NUM>, <NUM>, <NUM>. The server <NUM> may be connected to several network segments with a separate address <NUM> on each segment. An RTC device <NUM> changing its access to another network segment <NUM>, <NUM>, <NUM>, can then have received the addresses <NUM> of the server <NUM> on the various network segments <NUM>, <NUM>, <NUM> it is connected to, from the server <NUM> in advance of the change of access point <NUM> and can then reconnect via the new network segment.

After establishing a connection between the RTC device <NUM> and the server <NUM>, a unique connection identity is created and shared between the RTC device <NUM> and the server <NUM> to allow a non responding connection to be identified and recovered.

When the network access point <NUM> or the network interface <NUM> used by the RTC device <NUM> for connecting to the server <NUM> may change or the access point <NUM> or the network interface <NUM> used for a media path <NUM>, may change during a call, the following steps can establish or reestablish the media path <NUM>:.

The media channel is typically monitored separately and tried to be reestablished only when having been interrupted or showing bad quality.

In a further embodiment to do handover of calls, also referring to <FIG>, the RTC device <NUM> may detect a need for media path reestablishment by the occurrence of one of the following changed addresses or media path conditions:.

In a further embodiment to do handover of calls, also referring in <FIG>, the RTC device <NUM> is adapting a frequency of sending messages repeatedly to the server <NUM> depending on whether a call is ongoing, or whether there are NAT or firewall openings that need to be kept alive.

A further embodiment is shown in <FIG>, where a gateway <NUM> integrates the second media endpoint <NUM> with the server <NUM> for connecting calls to endpoints that are incompatible with the RTC device <NUM> regarding signaling or media, or for connecting calls over network segments <NUM>, <NUM>, <NUM> that are incompatible regarding signaling or media, when a protocol used by the RTC device <NUM> requires media encryption and encryption keys are negotiated over the media path <NUM> by the media endpoints <NUM>, <NUM> and has protection against man in the middle attacks by checking a fingerprint only available to the server <NUM> through a signaling channel.

A method for establishing or reestablishing a media path between endpoints for intercepting and decrypting Real Time Communication (RTC) media traffic between an RTC device <NUM> and an RTC service <NUM> using a communication protocol, where the media traffic is protected against man in the middle attacks using a fingerprint, for monitoring, analyzing and recording purposes, according to an embodiment is shown in <FIG>.

Modern protocols, e.g. WebRTC, not only allows encrypted media traffic, but even mandates encrypted media traffic between endpoints and includes protection against man in the middle attacks, making it difficult for call centers and others to monitor, analyze and record RTC communication. In this embodiment a proxy <NUM> is used to get control over the signaling and a media server <NUM> is intercepting, decrypting and relaying the media traffic.

The Real Time Communication device (RTC device) <NUM> comprises a first media endpoint <NUM>, a second media endpoint <NUM>, an RTC server <NUM> and an intercepting gateway <NUM>, each of the RTC device <NUM>, the second media endpoint <NUM>, the RTC server <NUM> and the intercepting gateway <NUM> having a memory <NUM> and a processor <NUM> coupled to the memory <NUM>.

The intercepting gateway <NUM>, integrates a proxy <NUM> for the communication protocol used by the RTC service <NUM> and a media server <NUM>, each of the proxy <NUM> and the media server <NUM> having a memory <NUM> and a processor <NUM> coupled to the memory <NUM>.

The RTC media path is established between the RTC device <NUM> and the media server <NUM> and between the media server <NUM> and the second media endpoint <NUM>, by the proxy <NUM> rewriting messages <NUM>, 164b.

The fingerprint is arranged by the proxy <NUM> rewriting messages <NUM>, 164b for the interception, decryption and transferring of the RTC media traffic by the media server <NUM>.

The RTC device <NUM>)is configured to use said proxy <NUM> for the communication protocol used by the RTC service <NUM>.

A method for establishing or reestablishing a media path between endpoints for intercepting and decrypting Real Time Communication (RTC) media traffic between an RTC device <NUM> and an RTC service <NUM> using a TURN protocol, where the media traffic is protected against man in the middle attacks using a fingerprint, for monitoring, analyzing and recording purposes, according to another embodiment is shown in <FIG>.

Modern protocols, e.g. WebRTC, not only allows encrypted media traffic, but even mandates encrypted media traffic between endpoints and includes protection against man in the middle attacks, making it difficult for call centers and others to monitor, analyze and record RTC communication. In this embodiment a TURN server <NUM> is relaying the media traffic.

Media streams will flow through a TURN server if it is considered "sealed" as outlined in IETF draft-schwartz-rtcweb-return-<NUM>, or if the TURN server is auto discovered or assigned by a software application and enforced to be used.

The intercepting gateway may also be built into an IP default gateway or a firewall/NAT between the media endpoints.

Another location of the intercepting server may be in the device handling real-time traffic between a local or private network and a global transport network, to handle use cases where the RTC is on a private domain and external traffic is to be monitored. A remote user to such private domain, sending its media to said intercepting server, can also be analyzed using the proposed method.

Further, a client, e.g. a WebRTC browser configured to do so, can establish the media through an intercepting server by modifying the ICE procedure or by other means.

For clients, not implementing to convey keys or to establish media through an intercepting server, e.g. the current browsers, such things can be added by a plug-in or extension to the browser.

The intercepting gateway <NUM>, integrates a TURN server <NUM> having a memory <NUM> and a processor <NUM> coupled to the memory <NUM> with the intercepting gateway <NUM>.

The RTC media path is established between the RTC device <NUM> and the TURN server <NUM> and between the TURN server <NUM> and the second media endpoint <NUM>, by configuring the RTC device <NUM> or the RTC service <NUM> to use the TURN server <NUM>, or by one of the media endpoints <NUM> or <NUM> discovering the TURN server <NUM> in a sealed network segment.

The decryption key for the RTC media traffic is conveyed to the intercepting gateway <NUM>, by the first media endpoint <NUM> or by the second media endpoint <NUM>, for decrypting the RTC media traffic passing the intercepting gateway <NUM>.

The intercepting server can also be built into an SBC (Session Border Controller) that typically handles media flows to traverse NAT and firewalls.

A method for establishing or reestablishing a media path between endpoints <NUM>, <NUM> with peer-to-peer media capability, connected over a network with gateways <NUM> between network segments of different types <NUM>, <NUM>, <NUM>, to achieve a direct media path for richer media, improved media quality, lower network load or lower cost calls according to an embodiment is shown in <FIG>.

VoIP services, even when a call starts from a computer client or an IP phone on a LAN (an intranet type of network segment) or on the Internet, almost always include gateway functionality into a telephony type of network segment and even when the other endpoint is a compatible VoIP phone, the media traffic is restricted or costly, because it involves the telephony type of network segment. With modern protocols, e.g. WebRTC and SIP or a combination thereof, also capable of video, it would be advantageous to establish a direct media path between compatible endpoints, rather than setting up a media path over a telephony type of network segment.

Real time communion calls, today also most telephone calls, connects endpoints in a two step process with messages over a signaling channel, which may be over several network segments and interconnecting servers <NUM>, <NUM>, followed by media channel establishment, which also may be over several network segments and servers. Any of these connections may be used for sending and receiving at least limited amounts of data between the endpoints and it should be noticed that a media path for conventional voice telephony, still is able to transfer data content, e.g. in the form of DTMF digits.

When two endpoints have established a signaling channel or a media path between each other that is not a direct media path between the endpoints, it may be advantageous to continue the setup process to establish or reestablish a direct media path between the endpoints, also called a peer-to-peer media path, that otherwise may be a media path over several network segments with gateways in between. Either of the endpoints can indicate to the other endpoint that it has peer-to-peer media path capability and either of the endpoints can initiate such establishment or reestablishment. Such direct media path may in this context include TURN servers and still be considered a direct media connection.

Initiating establishment or reestablishment of a media path may be signaled over a signaling channel or a media path, by using a O/A protocol. However, if the media path only is for voice, an O/A protocol may be too long to e.g. encode into DTMF digits and to transfer over that voice channel. In such cases a compressed version of the O/A protocol can be used. Alternatively (and often better) one endpoint can request that the other endpoint connects to the same server that it is self connected to, through which the O/A protocol can be executed and a direct media connection between the endpoints can be established.

This mechanism could be implemented in a WebRTC browser, that is in contact with a server (a web server) over which its signaling is transferred. The request could then be implemented as a transfer of a HTTP URL to the other endpoint over the signaling channel or media path, where after the full O/A protocol could be signaled via the then common server <NUM>.

The Real Time Communication device (RTC device) <NUM> comprises a first media endpoint <NUM>, a second media endpoint <NUM> and interconnecting servers <NUM>, 212b, each of the RTC device <NUM>, the second media endpoint <NUM> and the interconnecting servers <NUM>, 212b has a memory <NUM> and a processor <NUM> coupled to the memory <NUM>.

The RTC device <NUM> and the second media endpoint <NUM> are configured to have peer-to-peer media capability by using an Offer and Answer protocol (O/A protocol) to establish and reestablish a media path for media traffic of different types.

When attempting to set up a call between the RTC device <NUM> and the second media endpoint <NUM>, not knowing whether they have mutual per-to-per media compatibility or whether the interconnecting servers <NUM>, 212b convey the O/A protocol between the RTC device <NUM> and the second media endpoint <NUM> to establish a direct media path <NUM> between the RTC device <NUM> and the second media endpoint <NUM>, the following steps can establish a direct media path <NUM>:.

The RTC device <NUM> requests establishment of a direct media path <NUM> for the call, using the O/A protocol, which may be compressed, through an end-to-end signaling channel <NUM> between the RTC device <NUM> and the second media endpoint <NUM>, or.

The second media endpoint <NUM> requests establishment of a direct media path <NUM> for the call, using the O/A protocol, which may be compressed, through an end-to-end signaling channel <NUM> between the RTC device <NUM> and the second media endpoint <NUM>, or.

Another embodiment, referring to <FIG>, <FIG>, <FIG> and <FIG> the second endpoint <NUM> may be another RTC device <NUM> or gateway <NUM>, <NUM>.

A further embodiment may be a system for communication over a network using the method for establishing or reestablishing a media path, further comprising two or more endpoints <NUM>, <NUM>, 203b.

In a further embodiment the user agents coupled to the RTC devices <NUM> are implemented in the server <NUM> or interconnecting servers <NUM>, 212b.

A further embodiment, referring to <FIG>, is a system where the interconnecting servers <NUM>, 212b use the SIP protocol between each other and the SIP user agents coupled to the RTC devices <NUM> are implemented in the interconnecting servers <NUM>, 212b.

Another embodiment, referring to <FIG> is to offload the gateway <NUM> to enable communication when (i) the defined O/A protocol for the media endpoints <NUM>, <NUM>, 203b is incompatible with an endpoint <NUM> or <NUM> or a network segments <NUM>, <NUM> or <NUM>, implementing in the media endpoints <NUM>, <NUM>, 203b, by deviating from the defined O/A protocol, an O/A protocol that is compatible with the endpoints and the network segment to communicate with, and when (ii) the defined media path capabilities for the media endpoints <NUM>, <NUM>, 203b are incompatible with an endpoint <NUM> or <NUM> or a network segments <NUM>, <NUM> or <NUM>, implementing in the media endpoints <NUM>, <NUM>, 203b, by deviating from the defined media path capabilities, media path capabilities that are compatible with the endpoints and the network segment to communicate with, to offload the gateway <NUM> to enable communication.

In another embodiment, the system for communication over a network includes two or more RTC endpoints.

In another embodiment, a client side of the system is implemented by a telecommunication device.

In another embodiment, a server side of the system, which may be part of a Session Border Controller is implemented by a telecommunication device.

In another embodiment, the device for telecommunication incorporates and can send a program to a client.

In another embodiment, the device for telecommunication is a web server.

In another embodiment, the client or server side of the system is implemented by a software module in a web browser or as an application for smartphones, tablets, laptop or personal computers or computer servers, or in a telecommunication device comprising a processor for executing a program.

In another embodiment, user agents coupled to the RTC devices of the system are implemented in the server, interconnecting servers or RTC server.

In another embodiment, the interconnecting servers use the SIP protocol between each other and SIP user agents coupled to the RTC devices are implemented in the interconnecting servers.

In another embodiment, the server or interconnecting server is combined with a gateway or intercepting gateway.

In <FIG> and <FIG> is shown a process for establishing or reestablishing a media path between endpoints for handover of calls according to an embodiment. In a first operation <NUM>, shown in <FIG>, a Real Time Communication device (RTC device) comprising a first media endpoint, a second media endpoint and a server is provided. In a second operation <NUM>, the server is made reachable at addresses from access points at network segments. In a third operation <NUM>, at least one network interface of the RTC device that is connected to some network access point is arranged to send and receive messages between the RTC device and the server. In a fourth operation <NUM>, the RTC device and the second media endpoint are configured to have peer-to-peer media capability by using an Offer and Answer protocol (O/A protocol) to establish and reestablish a media path between the RTC device and the second media endpoint. In a fifth operation <NUM>, a unique connection identity is created that is shared between the RTC device and the server to allow a non responding connection to be identified and recovered, In a sixth operation <NUM>, addresses to the server from the access points at the network segments are collected by the RTC device. In a seventh operation <NUM>, shown in <FIG>, messages are sent repeatedly by the RTC device to an address of the server and, if no response is received, then other collected addresses to the server are tried until a response is received and signaling connectivity is recovered by continuing sending messages to the address from which the response was received. In an eighth operation <NUM>, the connection identity is presented by the RTC device to the server for recovering the specific connection, to be able to receive calls or to use the O/A protocol to establish or reestablish a media path between the RTC device and the second media endpoint. In a ninth operation <NUM>, the need for reestablishing the media path is determined by the RTC device and, if the media path needs to be reestablished, reestablishment of the media path is initiated.

In <FIG> is shown a process for establishing a media path for intercepting RTC traffic between endpoints according to an embodiment using a proxy. In a first operation <NUM>, a Real Time Communication (RTC) device comprising a first media endpoint, a second media endpoint, an RTC server, and an intercepting gateway is provided. In a second operation <NUM>, a proxy for the communication protocol used by the RTC service and a media server is integrated with the intercepting gateway. In a third operation <NUM>, the RTC media path is established between the RTC device and the media server and between the media server and the second media endpoint. In a fourth operation <NUM>, the fingerprint for the interception is arranged by the proxy rewriting the messages, for the decryption and transferring of the RTC media traffic by the media server. In a fifth operation <NUM>, the RTC device is configured to use the proxy for the communication protocol used by the RTC service.

In <FIG> is shown a process for establishing a media path for intercepting RTC traffic between endpoints according to an embodiment using a TURN server. In a first operation <NUM>, a Real Time Communication device (RTC device) comprising a first media endpoint, a second media endpoint, an RTC server and an intercepting gateway is provided. In a second operation <NUM>, a TURN server is integrated with the intercepting gateway. In a third operation <NUM>, the RTC media path is established between the RTC device and the TURN server and between the TURN server and the second media endpoint. In a fourth operation <NUM>, the decryption key for the RTC media traffic is conveyed to the intercepting gateway (<NUM>), by the first media endpoint (<NUM>) or by the second media endpoint.

In <FIG> is shown a process for establishing or reestablishing a direct media path between endpoints according to an embodiment. In operation <NUM>, a Real Time Communication device (RTC device) comprising a first media endpoint, a second media endpoint and interconnecting servers is provided, each of the RTC device, the second media endpoint and the interconnecting servers having a memory and a processor coupled to the memory. In operation <NUM>, the RTC device and the second media endpoint are configured to have peer-to-peer media capability by using an Offer and Answer protocol (O/A protocol) to establish and reestablish a media path for media traffic of different types. In operation <NUM>, an attempt is made to set up a call between the RTC device and the second media endpoint, not knowing whether they have mutual per-to-per media compatibility or whether the interconnecting servers convey the O/A protocol between the RTC device and the second media endpoint to establish a direct media path between the RTC device and the second media endpoint. In operation <NUM>, the RTC device receives an indication of mutual peer-to-peer media compatibility, then invoking a process for direct media path establishment or reestablishment. In operation <NUM>, the second media endpoint receives an indication of mutual peer-to-peer media compatibility, and then invokes a process for direct media path establishment or reestablishment.

Claim 1:
A method for establishing a media path between endpoints for intercepting and decrypting media traffic between an Real Time Communication, RTC, device (<NUM>) and an RTC service (<NUM>) using a communication protocol, where the media traffic is protected by encryption against man in the middle attacks using a fingerprint, for monitoring, analyzing and recording purposes, comprising:
providing the RTC device (<NUM>) comprising a first media endpoint (<NUM>) and a second media endpoint (<NUM>) and an RTC server (<NUM>) and an intercepting gateway (<NUM>), each of the RTC device (<NUM>), the second media endpoint (<NUM>), the RTC server (<NUM>) and the intercepting gateway (<NUM>) storing software implementing the method in a memory (<NUM>) and a processor (<NUM>) coupled to the memory (<NUM>);
further comprising:
integrating, with the intercepting gateway (<NUM>), a proxy (<NUM>) for the communication protocol used by the RTC service (<NUM>) and a media server (<NUM>), each of the proxy (<NUM>) and the media server (<NUM>) storing software implementing the method in a memory (<NUM>) and a processor (<NUM>) coupled to the memory (<NUM>);
characterized by:
establishing the RTC media path, by the RTC device (<NUM>), between the RTC device (<NUM>) and the media server (<NUM>) and, by the RTC device (<NUM>), between the media server (<NUM>) and the second media endpoint (<NUM>), and by the proxy (<NUM>) rewriting messages (<NUM>, 164b);
arranging the fingerprint, by the proxy (<NUM>) rewriting the messages (<NUM>, 164b), for the interception, decryption and transferring of the RTC media traffic via the media server (<NUM>); and
configuring the RTC device (<NUM>) to use said proxy (<NUM>) for the communication protocol used by the RTC service (<NUM>);
whereby media traffic is intercepted and decrypted by establishing a media path through an intercepting gateway in a telecommunication service using fingerprint to protect against man in the middle attacks.