3.1.5.5 Audio/Video Encryption

  • Article

For audio/video sessions, the initiating and receiving parties MUST negotiate support for encryption by using a new SDP attribute.

To implement the new SDP encryption attribute,<5> two pieces of information are required for audio/video encryption. The first is to determine whether encryption is required, and the second is to determine what the encryption key will be. This can be implemented in any of the following ways:

  • If encryption is required, SDP signaling MUST carry a media-level attribute as shown in the following. 

     m=audio 49170 RTP/AVP 0
 a=encryption:required

  • If encryption is supported but not required, SDP signaling MUST carry a media-level attribute as shown in the following: 

     m=audio 49170 RTP/AVP 0
 a=encryption:optional

  • If encryption is not allowed, SDP signaling MUST carry a media-level attribute as shown in the following.

     m=audio 49170 RTP/AVP 0
 a=encryption:rejected

The encryption key to use MUST be carried in a media-level key parameter, as shown in the following example.

 m=audio 49170 RTP/AVP 0
 a=encryption:required
 k=base64:bhdsfsd78f7dssdfssfsd7sdfssa

The encryption key is not encrypted. The only transformation of the key is the base64 encoding for transport in the textual session description (SDP). Clients MUST send the key in base64 encoded form and MUST decode the key that is received from the other endpoint before using it to decrypt audio/video. Protection of the encryption key is provided by the TLS transport over which SIP signaling is carried. The encryption key is used to encrypt traffic that is sent by the supplier of the key and also to decrypt traffic at the recipient. The keys used in each direction are independent and are typically different.

If SDP indicates that encryption is required or optional, an encryption key MUST also be supplied. In the case of optional encryption, the encryption key can go unused. It is highly recommended that a new encryption key be generated and used for every new INVITE request. However, when an INVITE is reused, it typically uses the same encryption key.

For information about SIP, see [RFC3261].