US20170187678A1 - Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers - Google Patents

Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers Download PDF

Info

Publication number
US20170187678A1
US20170187678A1 US15/458,465 US201715458465A US2017187678A1 US 20170187678 A1 US20170187678 A1 US 20170187678A1 US 201715458465 A US201715458465 A US 201715458465A US 2017187678 A1 US2017187678 A1 US 2017187678A1
Authority
US
United States
Prior art keywords
turn
signaling
credential
signaling gateway
ed
Prior art date
Legal status (The legal status 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 status listed.)
Abandoned
Application number
US15/458,465
Inventor
Xiaobo Wang
Ren Huipeng
Xuwu Zhang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FutureWei Technologies Inc
Original Assignee
FutureWei Technologies 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
Priority to US14/142,465 priority Critical patent/US9515995B2/en
Priority to US14/461,162 priority patent/US9621518B2/en
Application filed by FutureWei Technologies Inc filed Critical FutureWei Technologies Inc
Priority to US15/458,465 priority patent/US20170187678A1/en
Assigned to FUTUREWEI TECHNOLOGIES, INC. reassignment FUTUREWEI TECHNOLOGIES, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: REN, HUIPENG, ZHANG, XUWU, WANG, XIAOBO
Publication of US20170187678A1 publication Critical patent/US20170187678A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/15Directories; Name-to-address mapping
    • H04L61/1505Directories; Name-to-address mapping involving standard directories or standard directory access protocols
    • H04L61/1529Directories; Name-to-address mapping involving standard directories or standard directory access protocols using voice over internet protocol [VoIP] directories, e.g. session initiation protocol [SIP] registrar or H.323 gatekeeper
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/25Network arrangements or network protocols for addressing or naming mapping of addresses of the same type; address translation
    • H04L61/2503Internet protocol [IP] address translation
    • H04L61/256Network address translation [NAT] traversal
    • H04L61/2575Network address translation [NAT] traversal using address mapping retrieval, e.g. simple traversal of user datagram protocol through NAT [STUN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/25Network arrangements or network protocols for addressing or naming mapping of addresses of the same type; address translation
    • H04L61/2503Internet protocol [IP] address translation
    • H04L61/256Network address translation [NAT] traversal
    • H04L61/2589Network address translation [NAT] traversal over a relay server, e.g. traversal using relay NAT [TURN]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029Firewall traversal, e.g. tunnelling or, creating pinholes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1013Network architectures, gateways, control or user entities
    • H04L65/102Gateways
    • H04L65/1033Signalling gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1013Network architectures, gateways, control or user entities
    • H04L65/1046Call controllers; Call servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • H04L65/1069Setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • H04L65/1073Registration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/25Network arrangements or network protocols for addressing or naming mapping of addresses of the same type; address translation
    • H04L61/2503Internet protocol [IP] address translation
    • H04L61/2507Internet protocol [IP] address translation translating between special types of IP addresses
    • H04L61/2514Internet protocol [IP] address translation translating between special types of IP addresses between local and global IP addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/25Network arrangements or network protocols for addressing or naming mapping of addresses of the same type; address translation
    • H04L61/2503Internet protocol [IP] address translation
    • H04L61/256Network address translation [NAT] traversal
    • H04L61/2564Network address translation [NAT] traversal for a higher-layer protocol, e.g. for session initiation protocol [SIP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements or network protocols for addressing or naming
    • H04L61/60Details
    • H04L61/6004Structures or formats of addresses

Abstract

Various disclosed embodiments include methods and systems for provisioning traversal using relays around network address translation (TURN) credentials and servers for network address translation/firewall (NAT/FW) traversal via a Voice-over-Internet-protocol/Web Real-Time Communication (VoIP/WebRTC) signaling channel. The method comprises receiving, at a signaling gateway, a signaling message from a first electronic device (ED) when the first electronic device registers with the signaling gateway or sends other signaling messages for requesting a TURN credential. The signaling message comprises one or more signaling message parameters. The signaling message further comprises a request that the signaling gateway generate a TURN credential for the first electronic device, the TURN credential associated with the one or more signaling message parameters. The method comprises sending, from the signaling gateway, the TURN credential to the first electronic device.

Description

    PRIORITY CLAIM
  • This application is a continuation of and claims benefit of U.S. non-provisional patent application Ser. No. 14/461,162, filed on Aug. 15, 2014, and entitled “Method and Apparatus for Provisioning Traversal Using Relays Around network Address Translation (TURN) Credential and Servers,” the content of which is hereby incorporated by reference in its entirety.
  • TECHNICAL FIELD
  • The present disclosure relates generally to provisioning TURN credentials.
  • BACKGROUND
  • A Network Address Translation (NAT) device modifies an internet protocol (IP) header when a packet transits across the NAT device. NAT devices are widely deployed at home/enterprise networks and the internet. NAT devices, however, break Voice over Internet Protocol (VoIP) calls.
  • Some firewalls are configured to block User Datagram Protocol (UDP) and only allow Hypertext Transfer Protocol (HTTP) (TCP 80) or HTTP Secure (HTTPS) (TCP 443) to pass, usually for security reasons. Because voice packets are sent on UDP, firewalls that block UDP also block voice traffic. To summarize, both NAT and firewalls that block UDP can block media communication in VoIP and result in one-way voice or no voice.
  • It would therefore be desirable to provide improved NAT/Firewall traversal.
  • SUMMARY
  • According to one embodiment, there is provided a method for traversal using relays around network address translation (TURN) credential and server provisioning in a communication system, where the communication system comprises a signaling gateway, a TURN server, and an electronic device. The method comprises receiving, at the signaling gateway, a signaling message from a first electronic device (ED) when the first electronic device registers with the signaling gateway or sends other signaling messages for requesting TURN credential. The signaling message comprises one or more signaling message parameters. The signaling message further comprises a request that the signaling gateway generate a TURN credential for the first ED. The TURN credential is associated with the one or more authentication message parameters. The method comprises sending, from the signaling gateway, the TURN credential to the first ED.
  • In another embodiment, there is provided an electronic device for traversal using relays around network address translation (TURN) credential and server provisioning in a communication system, where the communication system comprises a signaling gateway and a TURN server. The electronic device comprises a processor and memory coupled to the processor. The electronic device is configured to send, to a signaling gateway, a signaling message. The signaling message comprises one or more signaling message parameters. The signaling message further comprises a request that the signaling gateway generate a TURN credential for the first ED. The TURN credential is associated with the one or more signaling message parameters. The electronic device is configured to receive, from the signaling gateway, the TURN credential.
  • In another embodiment, there is provided a signaling gateway. The signaling gateway comprises a processor and memory coupled to the processor. The signaling gateway is configured to receive a signaling message from a first electronic device (ED). The signaling message comprises one or more signaling message parameters. The signaling message further comprises a request that the signaling gateway generate a TURN credential for the first ED. The TURN credential is associated with the one or more authentication message parameters. The signaling gateway is configured to send the TURN credential to the first ED.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a more complete understanding of the present disclosure, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:
  • FIG. 1 illustrates a NAT device that translates a source IP/port of a packet to a new value;
  • FIGS. 2A-2C illustrate diagrams of ICE/STUN/TURN NAT/Firewall traversal solutions for P2P communication;
  • FIG. 3 illustrates an example VoIP call flow diagram using ICE/STUN/TURN;
  • FIG. 4 illustrates a call flow diagram of a system for provisioning TURN credentials and servers for NAT/FW traversal via a VoIP/WebRTC signaling channel according to one embodiment;
  • FIG. 5 illustrates a call flow diagram of a system for dynamic TURN server provisioning or dynamic TURN credential provisioning according to one embodiment;
  • FIG. 6 illustrates a block diagram of a signaling gateway according to one embodiment;
  • FIG. 7 illustrates a block diagram of an electronic device (ED) according to one embodiment; and
  • FIG. 8 illustrates a flow diagram illustrating a method of NAT traversal according to one embodiment.
  • DETAILED DESCRIPTION
  • An example NAT device 102 is shown in FIG. 1 where the NAT device 102 translates the source IP/port of a packet 104 to a new value 106 (e.g., 10.0.1.1:6554->1.2.3.4:8877) as the packet transits across it. NAT devices can solve an Internet Protocol version 4 (IPv4) address shortage problem by reusing private IP addresses. NAT devices also hide internal network topologies from outside for security protection. NAT devices, however, break Voice over Internet Protocol (VoIP) calls. The NAT breaks VoIP calls because the originating UE sends its private address (un-NATted) as a media address in the signaling message when the call is being set up. Because private addresses are not routable in public networks, media packets sent to a private address will be discarded by routers or switches on the path and do not reach the peer UE.
  • One solution to solve the above NAT/firewall issue is by using ICE/STUN/TURN. FIGS. 2A-2C illustrate simplified steps for ICE/STUN/TURN. As illustrated in FIG. 2A, during a first step, a first UE 202 collects its public and relay addresses by sending a request to a STUN or TURN server (shown as a TURN server 210 in FIG. 2A). As illustrated in FIG. 2B, during a second step, the first UE 202 sends collected media candidates to the peer or a second UE 204. The peer or second UE 204 collects its public and relay addresses by sending a request to the TURN server 210 and sends collected media candidates to the first UE 202. As illustrated in FIG. 2C, during a third step, the first and second UEs 202, 204 check media paths 208 by sending connectivity check messages for each possible path and select a path that works.
  • FIG. 3 illustrates an example VoIP call flow 300 using ICE/STUN/TURN. In the illustrated example, two UEs 302, 304 collect candidate addresses (public and relay address), exchange media candidates through signaling messages (steps 306, 308), perform a connectivity check (steps 310, 312), and exchange media over a selected media path (step 314). Because UEs 302, 304 are behind a symmetric NAT 303, their connectivity check for public addresses fails (step 310). The UEs 302, 304 switch to use a TURN relay server 316 for media communication (step 312). The UE registration process is not shown in FIG. 3 for simplification.
  • ICE/STUN/TURN are among the most common NAT/Firewall traversal solutions for P2P communication and have recently been adopted by the World Wide Web Consortium (W3C) and the IETF for Web Real-Time Communication (WebRTC) as the required NAT traversal mechanism. WebRTC enables users to make voice or video calls with a web browser. Because browsers are readily available on most types of electronic devices (desktop, smart phone, tablet/pad, etc.), WebRTC is regarded as a disruptive technology because of its potential for large user bases and its ability to integrate voice/video with web applications. Therefore a scalable, secure, and efficient ICE/TURN/STUN solution is desirable.
  • There are several drawbacks with existing ICE/STUN/TURN solutions. One drawback is TURN credential provisioning. For example, the TURN standard defines a mechanism for user authentication using TURN long-term credentials. When a UE sends a request to the TURN server, the TURN server challenges the UE with a random value and the UE must send an authentication code computed with the shared credential to authenticate itself. This is critical for security. Otherwise, hackers can send a flood of requests to exhaust resources on the TURN server, e.g., relay addresses or table entries.
  • However, current standards do not specify how to provision the long-term credential to UEs. Common practices include:
      • a. Manual configuration: this approach is not scalable to a large number of users, e.g., for WebRTC where credentials need to be configured for millions of users.
      • b. Using device management channel: this approach only works for devices that support a device management function, e.g., smart phones. It does not work for WebRTC because browsers do not use device management functions.
      • c. Shared user name/password: this approach only works when the number of users is small and is not secure when the number of users is large or for users that frequently join/leave a group, so it is not acceptable for service providers.
      • d. Re-using other service credentials like WebRTC user name/password: this approach has several drawbacks:
        • i. The TURN server may not know the service credentials (e.g., the TURN server belongs to a 3rd party), so it is difficult to use this approach if the TURN server and the service credential belong to different parties or organizations;
        • ii. Because the TURN user name and authentication code may be sent in clear text, using service credentials increases the risk of user name leakage and off-line password cracking attacks.
  • Several approaches have been proposed recently to IETF and other standard bodies regarding TURN credential management.
      • a. RFC 7065 “Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers” by M. Petit-Huguenin et al. This RFC defines the format to encode the TURN server address and protocols in a message, e.g., an HTTP response. But it does not define a mechanism to provision TURN credentials.
      • b. Retrieve TURN credential by REST API calls to a web server. In this approach, a UE sends an HTTP request to a URL (API) on a web server to retrieve TURN parameters, including user name and password (credentials). However, this mechanism does not specify how the UE can be authenticated by the web server. For example, if the TURN server belongs to a 3rd party, or if the web server does not have a user authentication function (e.g., users use IMS identity, not web identity, to access WebRTC services). Therefore, this approach only moves the authentication problem from the TURN server to the web server. Because there is no guarantee that the web server always authenticates a user, its applicability is limited and depends on the web server functions.
      • c. OAuth Token Approach. In this approach, a TURN server redirects a user to authenticate to a WebRTC server first. The WebRTC server then returns an OAuth token, which is used by the UE to authenticate to a TURN server. Some of the drawbacks of this approach are that:
        • I. The TURN protocol needs to be changed to send/process the OAuth token.
        • II. The OAuth token may not be available in existing service architecture. For example, for WebRTC service, when a user uses IMS ID to authenticate, there is no OAuth token used according to the service architecture proposed by 3GPP. Therefore the existing architecture needs to be changed.
        • III. Token leakage. Because TURN messages usually are sent without encryption, if the UE sends a token in the TURN message, it is possible for an attacker to eavesdrop or hack TURN messages and capture the OAuth token. This is a serious security issue that may be used by attackers to steal a user's identity or hijack sessions, etc.
      • d. Provisioning TURN credential using VoIP signaling channel. In this approach, a user first authenticates to a VoIP/WebRTC server, and then the server returns a user name and password to the user. This approach has the advantage that it is secure because the user is authenticated by the WebRTC or the VoIP server during registration. This approach is also simple and scalable because it uses the scalability of the signaling channel. One drawback is that it does not explain how to send the generated credential to the TURN server (from the WebRTC or the VoIP server), and it does not support dynamic change of user credentials, e.g., for anonymous calls discussed below.
  • Because TURN messages are often sent in clear text, it is possible for an attacker or 3rd party to find user call information by tracking the user name in TURN messages. This may reveal the user's call time, call destination (IP), call duration, etc. It is possible to reveal user call ID if attackers use active attack techniques, e.g., call a user first and analyze the TURN message from the user to find his TURN user name, etc. Therefore, it may be desirable to change the TURN user name regularly. For example, it is desirable to change the TURN user name to a different user name for anonymous calls. Current approaches do not allow the user to retrieve a new TURN user name for anonymous calls or change user names regularly to avoid privacy issues.
  • According to the present disclosure, a method to provision TURN credentials (e.g., user name/password) using a VoIP/WebRTC signaling channel is provided. The method provides a mechanism to manage credentials between the signaling gateway (e.g., the VoIP/WebRTC signaling gateway) and the TURN server. The method provides a mechanism to handle users for different realms. The method provides a mechanism to control credential expiration time and credential revocation. The method provides a mechanism to renew a credential anytime by the ED, e.g., before anonymous calls, to protect user privacy. The method provides a mechanism to retrieve TURN servers dynamically, e.g., based on network condition or security issues.
  • An embodiment of a system 400 for provisioning TURN credentials and servers for NAT/FW traversal via a VoIP/WebRTC signaling channel in accordance with the present disclosure is described with reference to the call flow diagram of FIG. 4. The system 400 includes a first electronic device (ED) 402, a first NAT/Firewall 404, a signaling gateway 406 such as a VoIP/WebRTC signaling gateway, a second NAT/Firewall 409, a TURN server 408, and a second ED 412. The signaling gateway 406 may integrate signaling, media, and TURN functions together. The first and second EDs 402, 412 are configured to operate and/or communicate in the system 400. For example, the EDs 402, 412 are configured to transmit and/or receive wireless signals or wired signals. Each ED 402, 412 represents any suitable end user device and may include such devices (or may be referred to) as a user equipment/device (UE), wireless transmit/receive unit (WTRU), mobile station, fixed or mobile subscriber unit, pager, cellular telephone, personal digital assistant (PDA), smartphone, laptop, computer, touchpad, wireless sensor, or consumer electronics device. An example signaling protocol used in the system is Session Initiation Protocol over WebSocket (SIP over WS).
  • The signaling gateway 406 may include an operating system that provides executable program instructions for the general administration and operation of that gateway, and typically will include a computer-readable medium storing instructions that, when executed by a processor of the signaling gateway 406, allow the signaling gateway 406 to perform its intended functions. Suitable implementations for the operating system and general functionality of the signaling gateway is known or commercially available, and are readily implemented by persons having ordinary skill in the art.
  • When the first ED 402 registers with the signaling gateway 406, such as a VoIp signaling server (e.g., Proxy Call Session Control Function (P-CSCF)) or a WebRTC signaling server (e.g., eP-CSCF), it sends a REGISTER (e.g., REGISTER for SIP SIP over WS) or other registration or authentication message that comprises a TURN credential provision request and one or more parameters, such as a “tun-cred” parameter, to request the signaling gateway 406 to provide TURN credentials to the first ED 402 (step 405). The format of the “tun-cred” parameter is:
      • “tun-cred: [realm=value;] [exp=value;] [revoke;]” where:
        (a) a “realm” parameter is optional and if present, requests a credential for the specific realm; (b) an “exp” parameter is optional and if present, requests a credential for the specified expiration time; and (c) a “revoke” parameter is optional and if present, requests the signaling gateway 406 to revoke previously generated credentials.
  • When the signaling gateway 406 receives the registration message with the “tun-cred” parameter, it validates the “tun-cred” parameter and selects the realm and TURN server for the realm. For example, the signaling gateway 406 may determine that the format of the realm is recognized, that the realm is recognized, that a value of the expiration time is not negative or infinite, etc. The realm may be a string used to describe the server or a context within the server and may tell a client device which username and password combination to use to authenticate requests. The signaling gateway 406 then generates a user portion of the TURN credential (TURN-USR) (step 410). The user portion of the TURN credential (TURN-USR) may be in the following format:
      • “Turn-USR=user-name[@realm-value;][exp=value;][revoke;],” where:
      • (a) “user-name” is the user name portion of the TURN credential;
      • (b) “realm-value” is optional and specifies the realm of the user;
      • (c) the “exp” value is optional and specifies the expiration time for the credential; and
      • (d) the “revoke” keyword is optional and indicates to the TURN server to revoke all TURN credentials generated before this credential.
  • The signaling gateway 406 identifies a pre-shared key (km) for the selected TURN server and generates a password portion of the TURN credential (TURN-PWD) by hashing the user portion of the credential using the pre-shared key (step 410). The password portion of the TURN credential (TURN-PWD) may be in the following format:
      • “TURN-PWD=hmac (TURN-USR, pre-shared-key)”
  • The signaling gateway 406 sends the generated TURN credential (TURN-USR and TURN-PWD) to the first ED 402 in a response to the registration message (e.g., “200 OK” for SIP) (step 415). The result may be encoded as: “tur-cred=usr-name@realm;exp=val;revoke;tur-pwd=turn-password.” Those of skill in the art will recognize that other formats may also be used.
  • The first ED 402 receives the response for registration with TURN credential from the signaling gateway 406 and uses the TURN credential to request a TURN relay address. The first ED 402 uses the entire string of TURN-USR as the TURN user name (that is, it includes the user-name@realm;exp-value;revoke) in its allocation (Alloc) request and uses the TURN-PWD to generate the message authentication code (MAC) for the Alloc request (step 420).
  • The TURN server 408 receives the Alloc request from the first ED 402, parses the user string (e.g., user-name@realm;exp-value;revoke), and extracts the TURN user name, the realm, the expiration time, and the revoke keyword (step 425). The TURN server 408 validates the extracted values and discards the request if the parameters are invalid (e.g., unknown or unrecognized format of the realm, unknown or unrecognized realm, negative expiration time, etc.). The TURN server 408 identifies the pre-shared key from the realm and calculates the TURN-PWD by hashing the received TURN user string in the Alloc request with the pre-shared key (step 425). The TURN server 408 uses the TURN-PWD generated by hashing the received TURN user string in the Alloc request with the pre-shared key to validate the received message. If the user string in the Alloc request includes the revoke keyword, the TURN server 408 revokes previously received unexpired credentials (e.g., using a local cache to record unexpired credentials for a user and the status of the credential). If a credential is revoked, it is rejected by the TURN server 408. After the received message is validated, the TURN server 408 sends an Alloc response including a relay address to the first ED 402 (step 430).
  • If the first ED receives a relay address from TURN server, it proceeds to make calls using existing protocols or procedures, e.g., the first ED 402 sends an INVITE request (step 435) to the signaling gateway 406 to initiate a call. The signaling gateway 406 receives the INVITE request from the first ED 402 and checks whether the call can proceed. If the call cannot proceed, e.g., the called party (e.g., the second ED 412) is not registered or not online, the signaling gateway 406 returns an error code to the first ED 402 (not shown) and terminates the call.
  • If the call can proceed, the signaling gateway 406 forwards the INVITE message to the called party (e.g., the second ED 412) (step 435). The called party (e.g., the second ED 412) receives the INVITE message, processes the INVITE message, and sends a response message (e.g., a “200 OK” message) to the signaling gateway 406. The signaling gateway 406 forwards the response message to the first ED 402 (step 440). Each of the EDs 402, 412 is behind a respective symmetric NAT/Firewall 404, 409.
  • The first ED 402 receives the response message and sends a ChannelBind request to the TURN server 408 to reserve a channel (step 445). The TURN server 408 receives the ChannelBind request and sends a ChannelBind response to the first ED 402 (step 450). After the channel is set up, the first and second EDs 402, 412 can exchange messages for a connectivity check (e.g., using STUN binding requests). For example, the TURN server 408 receives data from the first ED 402 via a connectivity check request message and relays the data to the second ED 412 (step 455). The second ED 412 receives the data and responds via a connectivity check response message. The TURN server 408 receives the connectivity check response message and relays the data therein to the first ED 402 (step 460). Thereafter, the first and second EDs 402, 412 find a media path and start sending media packets to each other, such as via Real-time Transport Protocol (RTP) (step 465).
  • FIG. 5 is a call flow diagram illustrating a system 500 for dynamic TURN server provisioning or dynamic TURN credential provisioning. As illustrated in the call flow diagram of FIG. 5, the first ED 402 requests TURN credentials in its initial registration message (e.g., REGISTER). The registration message may include the “tun-creel” parameter as described above with respect to FIG. 4. The signaling gateway 406 identifies the realm of the user, selects one or a list of TURN servers, and sends the selected TURN credential to the first ED 402 in its response (e.g., “200 OK” for SIP). If the first ED receives a relay address from the TURN server 408, it proceeds to make calls using existing protocols or procedures, e.g., the first ED 402 sends an INVITE request to the signaling gateway 406 to initiate a call as explained above with respect to FIG. 4.
  • The signaling gateway 406 may be configured to dynamically renew a credential, e.g., before anonymous calls or to avoid using one credential for too long, to protect user privacy. To receive a new TURN user name and password before the next registration cycle, (e.g., before making an anonymous call), the first ED 402 sends an update request such as an OPTION or INFORM request to the signaling gateway 406 that includes a parameter such as the “tur-cred” parameter as described above with respect to FIG. 4 (step 505). The format of the “tur-cred” parameter is the same as explained above with respect to FIG. 4. The signaling gateway 406 validates the user request and generates a new TURN credential (e.g., TURN-USR and TURN-PWD) as explained above with respect to FIG. 4. The signaling server 406 sends the new credential back to the first ED 402 in the response to the OPTION or INFORM request (e.g., “200 OK” in SIP) (step 510). The first ED 402 receives the new TURN credential from the signaling gateway 406 and uses the new TURN credential to make anonymous calls.
  • Alternatively, or in addition, the signaling gateway 406 may be configured to support re-selection of a TURN server based on a network condition (e.g., quality of service (QoS)) or a security condition. For example, if the first ED 402 detects a TURN server issue (e.g., QoS or security) such as the previously received TURN server not responding to its requests, the first ED 402 may send an update request such as the OPTION or INFORM request to the signaling gateway 406 that includes a parameter such as the “tur-serv” parameter in step 505. The update request may contain a reason code that indicates why the first ED needs a new TURN server. The signaling gateway 406 validates the user request, selects a new TURN server or TURN servers based on its knowledge of the operational status of other TURN servers in the communication system and the feedback from the first ED 402, and sends a new TURN server list back to the first ED 402 in the response to the OPTION or INFORM request (e.g., “200 OK” in SIP) (step 510). The first ED 402 receives the new TURN server list from the signaling gateway 406 and selects a new TURN server.
  • FIG. 6 illustrates a block diagram of the signaling gateway 406. In a particular embodiment, the signaling gateway 406 is composed of a server computer such as an SIP server, H.323 server, or the like. As shown in FIG. 6, in its hardware configuration, the signaling gateway 406 includes, for example, a communication interface 602 coupled to an IP network 604, an operating system (not shown), a storage device 608 for storing programs to serve as a server such as a VoIP server, and a control device 610 (e.g., a processor or CPU) which executes a program in the storage device 608 to control the entire operations.
  • The storage device 608 may include, for example, an OS, a communication protocol stack which controls data communication based on IP packets, a database, control programs, for example, call control protocols such as H.323, SIP, or the like which defines voice communication procedures (e.g., making and receiving calls), and a server program which defines processing procedures for the NAT and firewall traversal method.
  • The control device 610 may be a general purpose, special purpose or digital signal processor, and may be a plurality of processors or combination of such processors. The control device 610 includes functionality to perform signal coding, data processing, input/output processing, and/or any other functionality enabling the signaling gateway 406 to operate in the system 400 or the system 500. In addition, the control device 610 is coupled to the storage device 608 operable for storing and retrieving data. Any suitable type of memory storage device may be included, such as random-access memory (RAM), read-only memory (ROM), hard disk, subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • FIG. 7 illustrates a block diagram of an example electronic device (ED) or User Equipment (UE). The electronic device 710 may be, for example, a portable wireless electronic device. For example, the electronic device 710 may be a cellular telephone, a media player with wireless communications capabilities, a handheld computer (also sometimes called a personal digital assistant), a remote controller, a global positioning system (GPS) device, a tablet computer, and a handheld gaming device. The electronic device 710 includes a processor 700, a transceiver 702, an antenna element 704, one or more input/output devices 706 (e.g., speaker/microphone, keypad, display/touchpad) and memory 708. The electronic device 710 may be wirelessly coupled to a base station (not shown) via a wireless link 790.
  • The electronic device 710 may include one or more other components, devices, or functionalities (not shown). It will be understood that the electronic device 710 may include fewer or more of the foregoing described elements.
  • The processor 700 may be a general purpose, special purpose or digital signal processor, and may be a plurality of processors or combination of such processors. The processor 700 includes functionality to perform signal coding, data processing, power control, input/output processing, and/or any other functionality enabling the electronic device 710 to operate in the system 400 or the system 500. The processor 700 is coupled to the transceiver 702 which is coupled to the antenna element 704. It will be understood that the processor 700 and the transceiver 702 may be separate components or integrated together. Similarly, the antenna element 704 may be a single element or a number of elements (multiple antennas or elements).
  • The transceiver 702 is configured to modulate the data or signals for transmission by the antenna 704 and demodulate the data or signals received by the antenna 704.
  • The processor 700 is coupled to the one or more input/output devices 706 (including ports or busses) operable for inputting/outputting user data. In addition, the processor 700 is coupled to memory 708 operable for storing and retrieving data. Any suitable type of memory storage device may be included, such as random-access memory (RAM), read-only memory (ROM), hard disk, subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like.
  • Other elements or devices that might be included within the electronic device 710 will not be described herein, unless necessary or relevant to an understanding of the present disclosure.
  • FIG. 8 illustrates a flow diagram illustrating a method 800 for traversal using relays around network address translation (TURN) credential and server provisioning in a communication system according to one embodiment. The method comprises receiving, at a signaling gateway, a signaling message from a first electronic device when the first electronic device registers or authenticates with the signaling gateway, at step 802. The signaling message comprises one or more signaling message parameters. The signaling message further comprises a request that the signaling gateway generate a TURN credential for the first electronic device. The TURN credential is associated with the one or more signaling message parameters. For example, the registration message from the first electronic device 402 is received at the signaling gateway 406 (step 405). The registration message includes a TURN credential provision request parameter, and may include parameters such as the realm parameter, the expiration parameter, and the revoke parameter.
  • The signaling message parameters are validated at the signaling gateway, at step 804. For example, the registration message is validated by the signaling gateway 406 (step 410). To illustrate, the signaling gateway 406 validates the realm parameter “realm” (if present) against its security policies and discards requests with an invalid realm value. If the realm parameter is not present, the signaling gateway chooses a default realm. The signaling gateway 406 validates the expiration parameter “exp” (if present) and discards requests with an invalid value. If the expiration parameter is not present, the signaling gateway chooses an expiration value, such as an expiration value of the authentication message (e.g., the REGISTER message).
  • The TURN credential is sent to the first electronic device by the signaling gateway, at step 806. For example, the signaling gateway 406 sends the TURN credential in its response message “200 OK” to the first electronic device 402 (step 415).
  • One of the advantages of the present disclosure is that the signaling gateway authenticates users during the registration process, ensuring that only authenticated users can receive TURN credentials. Other approaches like OAuth Token or REST API use web servers to distribute TURN credentials. Web servers may or may not authenticate users. For example, in a 3GPP defined WebRTC architecture, the web server only hosts WebRTC JS code but will not authenticate users when an IMS identity is used to access the WebRTC service. In such case, the signaling gateway based approach is more secure than the web server based approach.
  • Another advantage of the present disclosure is that the signaling gateway based approach reuses existing ICE/TURN protocols with little to no change or addition of new interfaces. This approach does not need extra steps to verify TURN credentials (e.g., steps to verify token in the OAuth solution), thereby needing less overhead to implement and operate.
  • Another advantage of the present disclosure is that the signaling gateway based approach allows the ED to retrieve new credentials for anonymous calls to avoid call information leakage via analysis of the TURN user name, thereby providing more protection on user privacy than other approaches.
  • In some embodiments, some or all of the functions or processes of the one or more of the devices are implemented or supported by a computer program that is formed from computer readable program code and that is embodied in a computer readable medium. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory.
  • It may be advantageous to set forth definitions of certain words and phrases used throughout this patent document. The terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation. The term “or” is inclusive, meaning and/or. The phrases “associated with” and “associated therewith,” as well as derivatives thereof, mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like.
  • While this disclosure has described certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure, as defined by the following claims.

Claims (1)

What is claimed is:
1. A method for traversal using relays around network address translation (TURN) credential and server provisioning in a communication system, the communication system comprising a signaling gateway, a TURN server, and an electronic device, the method comprising:
receiving, at the signaling gateway, a signaling message from a first electronic device (ED) when the first ED registers with the signaling gateway or sends other signaling messages for requesting a TURN credential, the signaling message comprising one or more signaling message parameters, the signaling message further comprising:
a request that the signaling gateway generate a TURN credential for the first ED, the TURN credential associated with the one or more signaling message parameters; and
sending, from the signaling gateway, the TURN credential to the first ED.
US15/458,465 2013-12-27 2017-03-14 Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers Abandoned US20170187678A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US14/142,465 US9515995B2 (en) 2013-12-27 2013-12-27 Method and apparatus for network address translation and firewall traversal
US14/461,162 US9621518B2 (en) 2013-12-27 2014-08-15 Method and apparatus for provisioning traversal using relays around network address translation (TURN) credential and servers
US15/458,465 US20170187678A1 (en) 2013-12-27 2017-03-14 Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US15/458,465 US20170187678A1 (en) 2013-12-27 2017-03-14 Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US14/461,162 Continuation US9621518B2 (en) 2013-12-27 2014-08-15 Method and apparatus for provisioning traversal using relays around network address translation (TURN) credential and servers

Publications (1)

Publication Number Publication Date
US20170187678A1 true US20170187678A1 (en) 2017-06-29

Family

ID=53483216

Family Applications (3)

Application Number Title Priority Date Filing Date
US14/142,465 Active 2034-05-07 US9515995B2 (en) 2013-12-27 2013-12-27 Method and apparatus for network address translation and firewall traversal
US14/461,162 Active 2034-09-17 US9621518B2 (en) 2013-12-27 2014-08-15 Method and apparatus for provisioning traversal using relays around network address translation (TURN) credential and servers
US15/458,465 Abandoned US20170187678A1 (en) 2013-12-27 2017-03-14 Method and apparatus for provisioning traversal using relays around network address translation (turn) credential and servers

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US14/142,465 Active 2034-05-07 US9515995B2 (en) 2013-12-27 2013-12-27 Method and apparatus for network address translation and firewall traversal
US14/461,162 Active 2034-09-17 US9621518B2 (en) 2013-12-27 2014-08-15 Method and apparatus for provisioning traversal using relays around network address translation (TURN) credential and servers

Country Status (7)

Country Link
US (3) US9515995B2 (en)
EP (1) EP3167599B1 (en)
JP (1) JP6414630B2 (en)
KR (1) KR101794787B1 (en)
CN (1) CN106233704B (en)
BR (1) BR112017002343B1 (en)
WO (1) WO2016023507A1 (en)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9515995B2 (en) * 2013-12-27 2016-12-06 Futurewei Technologies, Inc. Method and apparatus for network address translation and firewall traversal
US10129412B1 (en) * 2014-09-08 2018-11-13 Whatsapp Inc. Establishing and maintaining a VOIP call
US10171511B2 (en) 2014-09-25 2019-01-01 Microsoft Technology Licensing, Llc Media session between network endpoints
US9596272B2 (en) 2014-09-25 2017-03-14 Microsoft Technology Licensing, Llc Media session between network endpoints
US10244003B2 (en) 2014-09-25 2019-03-26 Microsoft Technology Licensing, Llc Media session between network endpoints
US9762508B2 (en) * 2014-10-02 2017-09-12 Microsoft Technology Licensing, Llc Relay optimization using software defined networking
CA2963976C (en) * 2014-10-29 2019-11-19 Kodiak Networks, Inc. System and method to leverage web real-time communication for implementing push-to-talk solutions
US9942129B2 (en) * 2014-10-31 2018-04-10 Szegedi Tudományegyetem Communication method
US10542082B2 (en) * 2015-01-29 2020-01-21 Ntt Communications Corporation Communication control apparatus, communication control method and communication control program
US10594746B1 (en) * 2015-09-30 2020-03-17 Amazon Technologies, Inc. Connection service with network routing
US9961014B2 (en) 2015-11-13 2018-05-01 Nanning Fugui Precision Industrial Co., Ltd. Network communication method based on software-defined networking and server using the method
US10462101B2 (en) * 2015-11-13 2019-10-29 Nanning Fugui Precision Industrial Co., Ltd. Network communication method based on software-defined networking and server using the method
US10079863B2 (en) 2015-11-18 2018-09-18 Microsoft Technology Licensing, Llc Media session between network endpoints
US10158679B2 (en) 2015-11-18 2018-12-18 Microsoft Technology Licensing, Llc Media session between network endpoints
US9614973B1 (en) * 2016-06-16 2017-04-04 Sorenson Ip Holdings, Llc Voice over internet protocol credentials
CN108234398A (en) * 2016-12-15 2018-06-29 中国电信股份有限公司 Multimedia communication method and system and relevant device
CN109246589A (en) * 2017-06-14 2019-01-18 普天信息技术有限公司 A kind of method and apparatus for realizing distant dizzy terminal positioning business
US20190068684A1 (en) * 2017-08-31 2019-02-28 Microsoft Technology Licensing, Llc Bidirectional data exchange
US20190068652A1 (en) * 2017-08-31 2019-02-28 Microsoft Technology Licensing, Llc Bidirectional data exchange between computing devices
US20190141009A1 (en) * 2017-11-07 2019-05-09 General Electric Company Session moderator for turn-pattern tcp-packet relay with websocket instantiation
US10432583B1 (en) * 2018-03-14 2019-10-01 Syniverse Technologies, Llc Routing agent platform with a 3-tier architecture for diameter communication protocol in IP networks

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080098228A1 (en) * 2006-10-19 2008-04-24 Anderson Thomas W Method and apparatus for authentication of session packets for resource and admission control functions (RACF)
US20120197962A1 (en) * 2009-10-21 2012-08-02 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for locating services in a peer-to-peer network
US20140115037A1 (en) * 2011-01-25 2014-04-24 Hang Liu Method and apparatus for automatically discovering and retrieving content based on content identity
US20140150075A1 (en) * 2012-11-27 2014-05-29 Sansay, Inc. Securely establishing ice relay connections
US20140153710A1 (en) * 2012-12-04 2014-06-05 Genesys Telecommunications Laboratories, Inc. Distributed event delivery
US20140222894A1 (en) * 2013-02-04 2014-08-07 Oracle International Corporation Javascript api for webrtc
US20140223452A1 (en) * 2013-02-04 2014-08-07 Oracle International Corporation Generic model for customizing protocol behavior through javascript
US20150074259A1 (en) * 2006-12-29 2015-03-12 Prodea Systems, Inc. Multi-services application gateway and system employing the same
US20150180748A1 (en) * 2013-12-20 2015-06-25 Futurewei Technologies Inc. METHOD AND APPARATUS OF WebRTC MEDIA CONTROL
US20150188902A1 (en) * 2013-12-27 2015-07-02 Avaya Inc. Controlling access to traversal using relays around network address translation (turn) servers using trusted single-use credentials
US20150281344A1 (en) * 2014-03-31 2015-10-01 Yaana Technologies, Inc. Peer-to-Peer Rendezvous System for Minimizing Third Party Visibility and Method Thereof
US20150373059A1 (en) * 2013-02-07 2015-12-24 Openvacs Co., Ltd. Communication System Using Heterogeneous Networks

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8065418B1 (en) * 2004-02-02 2011-11-22 Apple Inc. NAT traversal for media conferencing
US7620033B2 (en) 2004-05-21 2009-11-17 Alcatel-Lucent Usa Inc. Method for optimal path selection in traversal of packets through network address translators
US8571011B2 (en) * 2004-08-13 2013-10-29 Verizon Business Global Llc Method and system for providing voice over IP managed services utilizing a centralized data store
US20070022289A1 (en) * 2005-07-20 2007-01-25 Mci, Inc. Method and system for providing secure credential storage to support interdomain traversal
US7920549B2 (en) * 2005-07-20 2011-04-05 Verizon Business Global Llc Method and system for providing secure media gateways to support interdomain traversal
EP2087698B1 (en) * 2006-11-08 2015-02-25 Orange Method for establishing a secured connection, corresponding MFC equipment and computer software program
US8578459B2 (en) * 2007-01-31 2013-11-05 At&T Intellectual Property I, L.P. Methods and apparatus to control network access from a user device
US8656017B2 (en) * 2007-05-16 2014-02-18 Microsoft Corporation Peer-to-peer collaboration system with edge routing
US20090094684A1 (en) * 2007-10-05 2009-04-09 Microsoft Corporation Relay server authentication service
US20100257276A1 (en) * 2007-11-22 2010-10-07 Nokia Corporation Virtual network interface for relayed nat traversal
US8893248B2 (en) * 2008-12-12 2014-11-18 Tekelec, Inc. Methods, systems, and computer readable media for media session policy compliance auditing and enforcement using a media relay and session initiation protocol (SIP) signaling
US8752161B1 (en) * 2009-07-22 2014-06-10 Cisco Technology, Inc. Securing and authenticating multiple devices behind a NAT device
GB2485148B (en) * 2010-11-01 2016-12-21 Media Network Services Network routing
CN102185827B (en) * 2011-01-30 2014-05-14 广东佳和通信技术有限公司 Firewall-penetrating method of voice in VOIP (Voice Over Internet Protocol) system
US9154426B2 (en) 2011-10-31 2015-10-06 Apple Inc. Low-latency hole punching
US20130308628A1 (en) * 2012-05-15 2013-11-21 Viber Media, Inc. Nat traversal for voip
US9712515B2 (en) * 2012-12-21 2017-07-18 Cellco Partnership Verifying an identity of a message sender
US9294458B2 (en) * 2013-03-14 2016-03-22 Avaya Inc. Managing identity provider (IdP) identifiers for web real-time communications (WebRTC) interactive flows, and related methods, systems, and computer-readable media
US9300633B2 (en) * 2013-03-25 2016-03-29 International Business Machines Corporation Network-level access control management for the cloud
US10263952B2 (en) * 2013-10-31 2019-04-16 Avaya Inc. Providing origin insight for web applications via session traversal utilities for network address translation (STUN) messages, and related methods, systems, and computer-readable media
US9515995B2 (en) 2013-12-27 2016-12-06 Futurewei Technologies, Inc. Method and apparatus for network address translation and firewall traversal

Patent Citations (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080098228A1 (en) * 2006-10-19 2008-04-24 Anderson Thomas W Method and apparatus for authentication of session packets for resource and admission control functions (RACF)
US20150074259A1 (en) * 2006-12-29 2015-03-12 Prodea Systems, Inc. Multi-services application gateway and system employing the same
US20120197962A1 (en) * 2009-10-21 2012-08-02 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for locating services in a peer-to-peer network
US20140115037A1 (en) * 2011-01-25 2014-04-24 Hang Liu Method and apparatus for automatically discovering and retrieving content based on content identity
US20140150075A1 (en) * 2012-11-27 2014-05-29 Sansay, Inc. Securely establishing ice relay connections
US20140153710A1 (en) * 2012-12-04 2014-06-05 Genesys Telecommunications Laboratories, Inc. Distributed event delivery
US20140153707A1 (en) * 2012-12-04 2014-06-05 Genesys Telecommunications Laboratories, Inc. Dialed string matching and call cost minimization in dial plan
US20140222894A1 (en) * 2013-02-04 2014-08-07 Oracle International Corporation Javascript api for webrtc
US20140223452A1 (en) * 2013-02-04 2014-08-07 Oracle International Corporation Generic model for customizing protocol behavior through javascript
US20150373059A1 (en) * 2013-02-07 2015-12-24 Openvacs Co., Ltd. Communication System Using Heterogeneous Networks
US20150180748A1 (en) * 2013-12-20 2015-06-25 Futurewei Technologies Inc. METHOD AND APPARATUS OF WebRTC MEDIA CONTROL
US20150188902A1 (en) * 2013-12-27 2015-07-02 Avaya Inc. Controlling access to traversal using relays around network address translation (turn) servers using trusted single-use credentials
US20150281344A1 (en) * 2014-03-31 2015-10-01 Yaana Technologies, Inc. Peer-to-Peer Rendezvous System for Minimizing Third Party Visibility and Method Thereof

Also Published As

Publication number Publication date
WO2016023507A1 (en) 2016-02-18
US20150188882A1 (en) 2015-07-02
EP3167599B1 (en) 2019-12-04
EP3167599A4 (en) 2017-07-12
BR112017002343A2 (en) 2017-11-28
CN106233704B (en) 2019-08-20
US20160050179A1 (en) 2016-02-18
US9515995B2 (en) 2016-12-06
BR112017002343B1 (en) 2020-01-21
KR20170041880A (en) 2017-04-17
US9621518B2 (en) 2017-04-11
JP2017527210A (en) 2017-09-14
KR101794787B1 (en) 2017-11-07
EP3167599A1 (en) 2017-05-17
JP6414630B2 (en) 2018-10-31
CN106233704A (en) 2016-12-14

Similar Documents

Publication Publication Date Title
US10165015B2 (en) System and method for real-time communication by using a client application communication protocol
US10560485B2 (en) System and method for connecting a communication to a client
WO2016192396A1 (en) Exchanging application metadata for application context aware service insertion in service function chain
US9967348B2 (en) Methods and apparatus for providing session policy during a registration of a device
US9473581B2 (en) Integrated web-enabled session border controller
EP2509280B1 (en) System and method to preserve dialogs in clustered environments in case of node failure
JP5763267B2 (en) Lawful intercept based on policy routing in a communication system with end-to-end encryption
US9882939B2 (en) System and method for providing multimedia services
EP2550787B1 (en) System and method for session sweeping between devices
US8190739B2 (en) Method for lawfully intercepting communication IP packets exchanged between terminals
US8503657B2 (en) System, method and apparatus for authenticating and protecting an IP user-end device
US9392437B2 (en) Method and system for IP multimedia bearer path optimization through a succession of border gateways
Rosenberg Interactive connectivity establishment (ICE): A protocol for network address translator (NAT) traversal for offer/answer protocols
KR100788083B1 (en) System, devices, and method for distributing load control information in a network
US8689301B2 (en) SIP signaling without constant re-authentication
US9307039B2 (en) Method, system, push client, and user equipment for service communication
JP4405360B2 (en) Firewall system and firewall control method
JP4938674B2 (en) Method and apparatus for accessing an IP multimedia subsystem
CN105933279B (en) system, method, apparatus, and machine-readable medium for enterprise wireless calling
US8108677B2 (en) Method and apparatus for authentication of session packets for resource and admission control functions (RACF)
Geneiatakis et al. Survey of security vulnerabilities in session initiation protocol
EP2095224B1 (en) Systems, methods, media, and means for hiding network topology
US8265069B2 (en) System, terminal, method, and computer program product for establishing a transport-level connection with a server located behind a network address translator and/or firewall
US7792065B2 (en) Securely establishing sessions over secure paths
US8725885B1 (en) Securely establishing ice relay connections

Legal Events

Date Code Title Description
AS Assignment

Owner name: FUTUREWEI TECHNOLOGIES, INC., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:WANG, XIAOBO;REN, HUIPENG;ZHANG, XUWU;SIGNING DATES FROM 20140815 TO 20141015;REEL/FRAME:041571/0616

STCB Information on status: application discontinuation

Free format text: FINAL REJECTION MAILED

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION