Lotus Sametime Unified Telephony supports securing of RTP (Real Time Transport Protocol) calls via SRTP (Secure Real-Time Transport Protocol) using MIKEY (Multimedia Internet Keying) Option 0. The mechanism defined, follows a standards based approach and allows for backward compatibility. There are defined provisions for a SIP end point to reject the SRTP offer if it does not support this mechanism. But certain 3rd party end points fail in the SDP (Session Description Protocol) negotiation and as a result the call setup fails. This feature provides a solution to identify such cases and support a mechanism that will allow for the call setup to succeed between an end point that originates an SRTP offer and an end point that does not comply with the provisions for rejecting such an offer.
The MIKEY keys for payload encryption are negotiated during the SDP offer- answer exchange. The procedure for exchanging the MIKEY keys is followed in accordance with the best effort SRTP mechanism defined in the OSCAR Signaling and Payload Encryption Specification. This mechanism is supported by certain Lotus Sametime Unified Telephony Enterprise Communications SIP EPs (Endpoints).
The administrator controls the determination of the best effort SRTP capabilities of devices via a RTP parameter displayed and modifiable via the Lotus Sametime Unified Telephony Assistant.
The administrator is able to switch ON, OFF and AUTO function this feature. If the feature is turned OFF, SIPSM (SIP Signaling Manager) will not check B-side's capabilities to determine to send SRTP. At the same time SIP Registrar functionality will not be changed even if the feature is turned OFF. This allows for fast toggling of the feature in case a administrator needs to quickly turn off the feature because of problems with it.
The administrator is able to add other devices that may not support the mechanism and if they are now part of the solution spectrum of the Lotus Sametime Unified Telephony. This allows for fast solutions of problems in the field when a device is discovered to cause problems when it gets offered best effort SRTP.
If the terminating SIP device does not support OSCAR Best Effort SRTP approach, the Telephony Control Server will remove the SRTP related attributes from the SDP offer before send it to the terminating side. Such a mechanism will ensure that the terminating side need not deal with the SRTP negotiation mechanism and instead can negotiate the call to an unsecured mode.
The secure keys are exchanged within the SDP offer/answer exchange facilitated via the SIP signaling the key exchange to only those devices that do support the mechanism or which behave in a standards conformant manner.
The Lotus Sametime Unified Telephony will be pre-configured during installation with a list of devices that are known to have problems with OSCAR SRTP mechanism. This list is used in case of AUTO feature.
These devices would be displayed on the Lotus Sametime Unified Telephony Assistant on the configuration for the SIP Signaling Manager.
System Specific Information
Lotus Sametime Unified Telephony Enterprise Communications SIP devices, that support establishing secure calls via SRTP, do so by exchanging secure keys between the originating and the terminating side end points.
The mechanism for SDP negotiation provided in this feature allows Lotus Sametime Unified Telephonyend points enabled for SRTP to successfully negotiate a call with a 3rd party SIP end point that does not support the Lotus Sametime Unified Telephony Enterprise Communications best effort SRTP mechanism. Such a call would be setup as an unsecured call.
The list of device types can change during run time, it is upgraded automatically. The SIP Registrar has to request update notifications from RTP to be informed about these changes and act upon it.
Parent topic: SIP Privacy Mechanism