Method and an apparatus to perform secure real-time transport protocol-on-the-fly

A method and an apparatus to perform Secure Real-time Transport Protocol-on-the-fly (SRTPoF) are disclosed. In one embodiment, the method includes monitoring negotiation between a first Voice-over-Internet-Protocol (VoIP) device and a second VoIP device after a call has been initiated between the first and the second VoIP devices, determining whether the first VoIP device is Secure Real-time Transport Protocol (SRTP)-capable and whether the second VoIP device is SRTP-capable, and performing SRTP-on-the-fly on a Real-time Transport Protocol (RTP) stream transmitted between the first and the second VoIP devices to make the call secure if the first VoIP device is not SRTP-capable and the second VoIP device is SRTP-capable. Other embodiments have been claimed and described.

FIELD OF INVENTION

The present invention relates to Voice-over-Internet-Protocol (VoIP) communication, and more particularly, to performing secure real-time transport protocol-on-the-fly.

BACKGROUND

Voice-over-Internet-Protocol (VoIP) is a set of protocols for the encoding, transporting, and routing of audio calls over Internet Protocol (IP) networks. According to VoIP, voice data may be converted into digital data and sent in packets using IP instead of the traditional circuit transmissions of the Public Switch Telephone Network (PSTN). In some VoIP systems, the analog audio stream is converted into a digital format, and may be compressed and encapsulated in IP for transport over the Internet or other types of network (e.g., local area network (LAN), wide area network (WAN), etc.) according to Real-time Transport Protocol (RTP). The converted stream is hereinafter referred to as a RTP stream.

Currently, VoIP software is available to be installed into personal computers to allow users to make VoIP calls over the personal computers. In addition to VoIP software, dedicated VoIP hardware are also available, such as VoIP telephones (also known as IP phones), VoIP gateways, VoIP conferencing, VoIP voicemail, etc. However, the typical processing power of VoIP telephones is significantly less than that of the personal computers.

Although VoIP calls are typically less expensive than the traditional telephone calls using PSTN, one obstacle in the popularization of VoIP is the lack of security. Currently, security protocols, such as Secure Real-time Transport Protocol (SRTP), are developed to provide encryption of the RTP stream in VoIP calls. However, SRTP requires the VoIP endpoints (e.g., personal computers loaded with VoIP software, VoIP telephones, VoIP gateway, VoIP conferencing, etc.) to perform the encryption and this is not possible in many cases because many VoIP endpoints are VoIP telephones with insufficient processing power to perform encryption and/or decryption. In some cases, the VoIP software installed on personal computers may not support SRTP.

SUMMARY

The present invention includes a method and an apparatus to perform SRTP-on-the-fly. In one embodiment, the method includes monitoring and/or modifying negotiation between a first Voice-over-Internet-Protocol (VoIP) device and a second VoIP device during call setup between the first and the second VoIP devices, determining whether the first VoIP device is Secure Real-time Transport Protocol (SRTP)-capable and whether the second VoIP device is SRTP-capable, and performing SRTP-on-the-fly on a Real-time Transport Protocol (RTP) stream transmitted between the first and the second VoIP devices to make the call secure if the first VoIP device is not SRTP-capable and the second VoIP device is SRTP-capable.

In some embodiments, substantially the same technique may be applied to Real Time Control Protocol (RTCP) as well as Real-time Transfer Protocol (RTP). When the security applies to RTP or RTCP, they change to Secure Real-time Transfer Protocol (SRTP) and Secure Real Time Control Protocol (SRTCP), respectively.

DETAILED DESCRIPTION

A method and an apparatus to perform SRTP-on-the-fly are described. In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known components, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description.

FIG. 1illustrates one embodiment of a system usable with the invention. The system100includes a first local area network (LAN)110, an Internet130, a first firewall141coupled between the first LAN110and the Internet130, and a number of VoIP devices coupled to the first LAN110. Examples of the VoIP devices include a personal computer112with VoIP software installed, a VoIP telephone114, etc. The Internet130is further coupled to other VoIP devices directly or indirectly. For example, another VoIP telephone150may be coupled to the Internet130. In one embodiment, a second LAN120is coupled to the Internet130via a second firewall142, where the second LAN120is further coupled to other VoIP devices, such as a second personal computer122, a second VoIP telephone124, etc.

Note that any or all of the components and the associated hardware illustrated inFIG. 1may be used in various embodiments of the system100. However, it should be appreciated that other configurations of the system100may include more or less devices than those shown inFIG. 1.

In one embodiment, the first firewall141is capable of performing SRTP-on-the-fly (SRTPoF) to allow one of the VoIP devices coupled to the first LAN110to have a secure VoIP call over the Internet130with another VoIP device (e.g., the VoIP telephone150, the VoIP telephone120via the firewall142, etc.). Details of some embodiments of the process to perform SRTPoF are described below with reference toFIGS. 3 and 4. Before discussing the process to perform SRTPoF, one embodiment of the first firewall141is discussed in details now.

FIG. 2shows one embodiment of a firewall capable of performing SRTPoF. The firewall200includes a first interface210, a second interface220, monitoring logic230, an encoder-decoder device240, a storage device250, processing logic260, and a bus270. The first interface210, the second interface220, the monitoring logic230, the encoder-decoder device240(also referred to as encryption-decryption device), the storage device250, and the processing logic260are coupled to each other via the bus270.

In one embodiment, the firewall200is directly or indirectly coupled to a first and a second VoIP devices via the first and the second interfaces210and220, respectively. For example, the first interface210may be directly coupled to a VoIP device (such as a VoIP telephone, a VoIP-capable personal computer) or indirectly coupled to a VoIP device via a local area network (e.g., the first LAN110inFIG. 1). Likewise, the second interface220may be directly coupled to a VoIP device (such as a VoIP telephone, a VoIP-capable personal computer) or indirectly coupled to a VoIP device via an Internet and/or another firewall (e.g., the second firewall142inFIG. 1). When a VoIP call is established between the first and the second VoIP devices, a RTP stream containing voice and/or video data may pass through the firewall200via the first and the second interfaces210and220.

In one embodiment, the storage device250stores routing and/or transformation data, which may include various information, such as the Internet Protocol (IP) address and/or port number of each of the first and the second VoIP devices, etc. The routing information may be stored in a VoIP transformation table. To establish a VoIP call between the first and the second VoIP devices, the first and the second VoIP devices negotiate with each other by exchanging signaling messages through the firewall200. The monitoring logic230in the firewall200monitors the negotiation. In some embodiments, the monitoring logic230identifies one or more predetermined parameters in the signaling messages exchanged, where the predetermined parameters are relevant to whether the first and the second VoIP devices are SRTP-capable. Using the routing data and the identified parameters, the processing logic260may determine whether each of the first and the second VoIP devices is SRTP-capable.

The firewall200further includes an encoder-decoder device240(also referred to as encryption-decryption device) to perform SRTPoF on a RTP stream transmitted between the first and the second VoIP devices during the call established under certain predetermined circumstances. Details of these predetermined circumstances and SRTPoF are described below with reference toFIGS. 3 and 4.

FIG. 3shows a flow diagram of one embodiment of a process to perform SRTP-on-the-fly in a VoIP call generated from behind a SRTP-on-the-fly capable firewall (such as the firewall200inFIG. 2and the firewall141inFIG. 1). The process is performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system, a server, or a dedicated machine), or a combination of both. The VoIP device initiating the call is referred to as the calling party or the initiator, while the VoIP device receiving the call is referred to as the called party or the receiver in the following discussion. Examples of the receiver may include a VoIP device (e.g., VoIP telephone) and a firewall coupled to a VoIP device, where the firewall may or may not be SRTPoF-capable.

Referring toFIG. 3, the process begins when a VoIP call is initiated by the calling party behind a SRTPoF-capable firewall (processing block301). Processing logic finds the appropriate routing data from a VoIP transformation table stored in the SRTPoF-capable firewall (processing block310). The routing data may include the source IP address and/or port number, the destination IP address and/or port number for the VoIP devices, etc. Then processing logic checks to determine whether the initiator is SRTP-capable (processing block315). In some embodiments, processing logic uses one or more parameters identified in the messages exchanged between the initiator and the receiver during their negotiation and the routing data to determine whether the initiator is SRTP-capable.

If the initiator is SRTP-capable, the initiator may encrypt the RTP stream, depending on whether the receiver is SRTP-capable, and processing logic does not have to perform SRTPoF. Thus, processing logic allows the encrypted or unencrypted RTP stream to pass through the firewall (processing block340). In other words, the firewall does not perform SRTPoF in this situation. After passing the RTP stream, processing logic checks whether the call is terminated (processing block342). If the call is not terminated, processing logic returns to processing block340to let additional RTP stream to pass through the firewall. Otherwise, processing logic transitions to processing block390and the process ends with the call being terminated.

If the initiator is not SRTP-capable, processing logic adds SRTP capability by modifying the signaling message (processing block312) before sending the signaling message out. Processing logic checks whether the receiver is SRTP-capable (processing block320). In some embodiments, processing logic uses one or more parameters identified in the signaling messages exchanged between the initiator and the receiver during their negotiation as well as the routing data to determine whether the receiver is SRTP-capable. The technique to determine the SRTP capabilities varies among different VoIP protocols, such as Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP), H.248 Megaco, etc. For instance, in H.323 protocol, SRTP capability may be determined using the existing terminal capabilities exchange that uses h235SecurityCapability entries in the capabilityTable of the H.245 TerminalCapabilitySet message. The encryptionAuthenticationAndIntegrity field in the h235SecurityCapability entry contains the SrtpCryptoCapability field which will specify the SRTP crypto-suites. Alternatively, in SIP, the Session Description Protocol (SDP) parameters are used to determine the SRTP capability for either the initiator or the receiver. Below is an example of a SDP message indicating the lack of SRTP capability.

i=A discussion on the session description protocol

m=audio 49170 RTP/AVP 0→This indicates that there is no SRTP capability

m=video 51372 RTP/AVP 31→This indicates that there is no SRTP capability

If the receiver is also not SRTP-capable, then a secure VoIP call cannot be established between the initiator and the receiver because the receiver cannot decrypt an encrypted RTP stream. Thus, processing logic allows the unencrypted RTP stream from the initiator to pass through the firewall (processing block331). Processing logic then checks whether the call is terminated (processing block335). If the call is not terminated, processing logic returns to processing block331to let additional RTP stream to pass through the firewall. Otherwise, processing logic transitions to processing block390and the process ends with the call being terminated.

However, if the receiver is SRTP-capable, processing logic performs SRTPoF to allow a secure VoIP call between the initiator and the receiver, albeit the initiator behind the firewall is not SRTP-capable. In one embodiment, processing logic modifies the VoIP signaling messages exchanged between the initiator and the receiver to indicate that the initiator is SRTP-capable (processing block312). For instance, processing logic may set or reset a parameter indicative of the SRTP-capability of the initiator in one or more of the signaling messages in order to represent to the receiver that the initiator is SRTP-capable. Below is an example of SDP parameters in SIP that have been set by the firewall to indicate SRTP capability.

i=A discussion of Secure RTP

m=audio 49170 RTP/SAVP 0→This indicates that there is SRTP capability

Then the receiver may be tricked into accepting a secure VoIP call with the initiator.

Once the secure VoIP call is established between the initiator and the receiver, processing logic performs SRTPoF on the RTP stream transmitted from the initiator to the receiver (processing block323). In one embodiment, processing logic may encrypt or encode the RTP stream from the initiator and then send the encrypted RTP stream to the receiver because the initiator cannot encrypt the RTP stream. Then processing logic sends the RTP stream to either the initiator or the receiver (processing block325). In some embodiments, the encryption is SRTP-compliant, which is also referred to as RFC 3711 compliant.

Processing logic then checks whether the VoIP call is terminated (processing block327). If the call is not terminated, processing logic returns to processing block323to perform SRTPoF on additional RTP stream. Otherwise, processing logic tears down the encrypted RTP stream in response to the termination of the VoIP call (processing block329). Finally, the process ends at processing block390with the VoIP call being terminated.

FIG. 4shows a flow diagram of one embodiment of a process to perform SRTPoF in a VoIP call received by a SRTPoF capable firewall (such as the firewall200inFIG. 2and the firewall141inFIG. 1). The process is performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system, a server, or a dedicated machine), or a combination of both. The VoIP device initiating the call is referred to as the calling party or the initiator, while the VoIP device receiving the call is referred to as the called party or the receiver in the following discussion.

Referring toFIG. 4, the process begins when a VoIP call is received from the calling party by the SRTPoF-capable firewall at processing block401. Processing logic finds the appropriate routing data from a VoIP transformation table stored in the SRTPoF-capable firewall (processing block410). The routing data may include an IP address and/or port number of the source, an IP address and/or port number of the destination, etc. Processing logic then checks if the initiator is SRTP-capable (processing block415). In one embodiment, processing logic monitors signaling messages between the initiator and the receiver to identify parameters relevant to the SRTP capability of the initiator. Using these parameters and the appropriate routing data from the VoIP transformation table, processing logic may determine whether the initiator is SRTP-capable. For example, in SIP protocol, the SDP specific parameters are used to indicate SRTP capabilities, the following SDP message indicates the lack of SRTP capability.

i=A discussion on the session description protocol

m=audio 49170 RTP/AVP 0→This indicates that there is no SRTP capability

m=video 51372 RTP/AVP 31→This indicates that there is no SRTP capability

If the initiator is not SRTP-capable, then the RTP stream from the initiator is not touched. Therefore, the firewall may allow the RTP stream to pass through to the receiver (processing block440). Processing logic checks whether the VoIP call is terminated (processing block442). If the call is not terminated, processing logic returns to processing block440to let additional RTP stream from the initiator to pass through the firewall. Otherwise, processing logic transitions to processing block490and the process ends with the call being terminated.

If the initiator is SRTP-capable, then the RTP stream sent from the initiator may be decrypted or decoded. In some embodiments, the encrypted RTP stream is a SRTP stream. Processing logic checks if the receiver is SRTP-capable (processing block420). In one embodiment, processing logic checks the VoIP signaling messages between the initiator and the receiver. Based on one or more parameters identified in the signaling messages and the appropriate routing data from the VoIP transformation table, processing logic may determine whether the receiver is SRTP-capable. Below is an example of SDP parameters that indicate SRTP capability.

i=A discussion of Secure RTP

m=audio 49170 RTP/SAVP 0→This indicates that there is SRTP capability

If the receiver is SRTP-capable, then the receiver is able to decrypt or decode the encrypted RTP stream from the initiator. Thus, processing logic allows the encrypted RTP stream to pass through the firewall to the receiver without performing SRTPoF on the encrypted RTP stream (processing block431). Processing logic checks whether the VoIP call is terminated (processing block435). If the call is not terminated, processing logic returns to processing block431to let additional encrypted RTP stream from the initiator to pass through the firewall to the receiver. Otherwise, processing logic transitions to processing block490and the process ends with the call being terminated.

However, if the receiver is not SRTP-capable, then the receiver is unable to decrypt or decode the encrypted RTP stream from the initiator. In order to allow the VoIP call to be secure, processing logic first modifies the VoIP signaling messages to indicate to the initiator that the receiver is SRTP-capable (processing block421). Processing logic may set or reset one or more parameters indicative of the SRTP-capability of the receiver in the signaling messages to trick the initiator to send encrypted RTP stream to the firewall. Below is an example for SIP protocol, where SDP parameters that are added and/or modified to indicate SRTP capability:

i=A discussion of Secure RTP

m=audio 49170 RTP/SAVP 0→This line has been modified to indicate that there is SRTP capability

Then processing logic performs SRTPoF on the RTP stream from the receiver (processing block423). In some embodiments, processing logic decrypts or decodes the encrypted RTP stream from the initiator. Then processing logic sends the decrypted RTP stream to the receiver (processing block425).

Processing logic checks whether the VoIP call is terminated (processing block427). If the call is not terminated, processing logic returns to processing block423to perform SRTPoF for the receiver stream and send the encrypted data to the initiator (i.e., the calling party). Otherwise, processing logic tears down the encrypted RTP stream in response to the termination of the VoIP call (processing block429). Then processing logic transitions to processing block490and the process ends with the call being terminated.