Expand description
SDES: keying SRTP through SDP (RFC 4568).
The mechanism is blunt. a=crypto carries the master key in the SDP body, base64-encoded
and otherwise in the clear, and whoever can read the signalling can decrypt the media. RFC
4568 §7.1 is explicit that it therefore requires a secure signalling path, and treats that as
a condition of use rather than as advice.
sipx enforces it rather than documenting it. Crypto::offer takes a flag saying whether the
signalling is secure and returns nothing when it is not, so an offer over cleartext SIP cannot
carry a key by forgetting a check somewhere. That is the difference between a stack that has
a rule and one that has a comment.
What SDES cannot do is protect a key from an intermediary that terminates the TLS — a proxy, a session border controller. For that the keying has to happen on the media path, which is what DTLS-SRTP (RFC 5764) is for.
Structs§
- Crypto
- One
a=cryptoline.
Enums§
- Suite
- The crypto suite. Only the default SRTP transform is offered.