skip to content

For SRTP protection profiles on a calling platform with WebRTC clients and a narrow SIP trunk, do you set a policy or take each library's default, and what goes in it?

level: principalimportance: nice to knowfreq 6%

answer

  1. a default is someone else's choice
  2. what WebRTC already mandates
  3. different legs, different budgets
  4. offer order versus who picks
  5. record what was negotiated

basics

~20 s

Set a policy, because a default is just one stack's choice. Support SRTP_AES128_CM_HMAC_SHA1_80 as WebRTC's mandatory baseline, offer the AES-GCM profiles first where every hop can meet their rules, forbid NULL encryption, and allow the 32-bit tag only on the bandwidth-bound trunk.

solid answer

~40 s

I would write a policy per leg, because each endpoint's default reflects its authors' trade-offs, not yours. The specifications fix some lines: RFC 8827 makes `SRTP_AES128_CM_HMAC_SHA1_80` mandatory for WebRTC and forbids NULL encryption, SDES and MKI; RFC 3711 keeps SRTCP at an 80-bit tag; RFC 7714 forbids truncating the GCM tag. Inside those lines the lead decides. On WebRTC legs, offer `SRTP_AEAD_AES_128_GCM` ahead of `_80` if every media server can meet GCM's uniqueness rules. On the SIP trunk, compute the overhead: `_32` saves 6 bytes per packet, which matters on a G.729 trunk and hardly on G.711. Choose AES-256 for long-term confidentiality needs, not by reflex: RFC 6188 calls AES-128 more than sufficient and puts AES-256's extra compute near 40%. Then verify by logging the negotiated profile per call.

go deeper

for a junior

Recall that WebRTC requires SRTP_AES128_CM_HMAC_SHA1_80 support and forbids NULL encryption, so those two lines are fixed in any policy.

for a middle

Explain how offer order works in SDES and DTLS-SRTP, and why an offerer's preference does not guarantee the outcome.

for a senior

Compute per-leg overhead for the codecs in use and identify which media servers can meet GCM's uniqueness rules before offering it.

for a principal

Own the trade-off between bandwidth, integrity strength, CPU and interoperability per leg, and make the negotiated profile observable so the policy can be audited.

## Why the default is not a policy Every SRTP stack ships with an offer order and an acceptance rule. Those defaults encode its authors' guesses about interoperability, CPU and bandwidth, and they differ between stacks. A platform that accepts them has no single answer to "what protects our calls?", only whatever each pair of endpoints happened to agree. There is no single correct policy, but there should be one written down, and the trade-offs below are the lead's to own. ## Constraints the specifications already impose Some decisions are made for you: - **WebRTC (RFC 8827 §6.5):** `SRTP_AES128_CM_HMAC_SHA1_80` MUST be supported; NULL encryption MUST NOT be negotiated; DTLS-SRTP MUST be offered, SDES MUST NOT be offered or accepted; an MKI MUST NOT be used. - **SRTCP (RFC 3711 §5.2):** never a tag shorter than 80 bits, so even the `_32` profiles keep an 80-bit RTCP tag. - **AES-GCM (RFC 7714):** the tag is always 16 octets; implementations MUST support both 128- and 256-bit keys; SRTP packets are always encrypted. - **SDES (RFC 4568):** one crypto-suite for both directions of a stream; the answerer takes the first offered line it supports. - **DTLS-SRTP (RFC 5764):** the server picks one profile from the client's list and is not bound to the client's first choice. ## A policy by leg | Leg | Keying | Offer order | Allowed | Refused | |---|---|---|---|---| | Browser to media server | DTLS-SRTP | `SRTP_AEAD_AES_128_GCM`, then `SRTP_AES128_CM_HMAC_SHA1_80` | GCM-128, GCM-256, `_80` | any NULL-cipher profile, `_32` | | Media server to SIP trunk | as the trunk supports | `AES_CM_128_HMAC_SHA1_80`, then `_32` if the budget needs it | `_80`, `_32` | NULL encryption | | Long-retention or high-sensitivity tenants | DTLS-SRTP | `SRTP_AEAD_AES_256_GCM` first | GCM-256, GCM-128 | `_32` | The table is an illustration of a defensible starting point, not a standard. ## The trade-offs a lead owns 1. **Bandwidth.** The tag costs 4, 10 or 16 bytes per packet for `_32`, `_80` and GCM. At 50 packets per second that is 1.6, 4.0 or 6.4 kbit/s per stream per direction; it matters on a G.729 trunk and hardly on G.711. 2. **Integrity strength.** A 32-bit tag gives 2^-32 forgery odds per packet; RFC 3711 accepts that only for bandwidth-bound voice with a limited per-packet impact. 3. **CPU and hardware.** RFC 7714 describes GCM as well suited to efficient hardware; RFC 6188 puts AES-256's extra cost over AES-128 near 40%. 4. **Uniqueness discipline.** GCM requires that (SSRC, ROC, SEQ) never repeat under a key and that SSRC collisions be prevented when keys are shared; a media server that cannot guarantee that should not be offered GCM. 5. **Interoperability.** The trunk peer's supported list may be short; RFC 6188 gives its AES-256 counter-mode suites only SDES names, so a 256-bit requirement on DTLS-SRTP means GCM. ## Where media servers change the answer A media server that terminates SRTP on each leg negotiates **separate profiles per leg**, so the weakest leg sets the call's real protection. RFC 8723 defines double profiles such as `DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM` for an end-to-end inner layer under a hop-by-hop outer layer; they add 32 octets of tags plus 1-4 octets of original-header block, and a distributor that re-encrypts MUST use independent master keys for each context. ## Questions to settle before writing it 1. Which legs use DTLS-SRTP and which use SDES? On an SDES leg the master key travels in the signalling, so the strongest profile is only as safe as the signalling path that carries its key. 2. Which media servers decrypt, and can each one guarantee unique SSRCs and indices under a key? 3. Which codecs and packet rates run on each leg, and what does each tag length cost there? 4. Who may grant an exception, such as `_32` on a new trunk, and where is it recorded? ## Verifying the policy holds - Log the negotiated profile for every call leg, in a consistent spelling. - Alert on any NULL-cipher profile anywhere, and on `_32` outside the trunk. - Re-run the bandwidth and CPU arithmetic when the codec mix or call volume changes. - Review the policy when a new profile or keying change is published.

  • A media server sits between the browser and the trunk; how does that change the profile policy?
    It terminates SRTP on each side, so each leg negotiates its own profile and the call is only as strong as its weakest leg. If end-to-end protection through the server is required, RFC 8723's double AES-GCM profiles add an inner end-to-end layer, at 32 octets of tags plus 1-4 octets of header block, and a distributor that re-encrypts must use independent keys.
  • Would you mandate AES-256 profiles everywhere?
    Not by reflex. RFC 6188 regards AES-128 as more than sufficient and AES-256 as worth its roughly 40% extra compute for long-term confidentiality needs. On DTLS-SRTP a 256-bit requirement means `SRTP_AEAD_AES_256_GCM`, since RFC 6188's counter-mode 256-bit suites have only SDES names. I would reserve it for tenants that need it.

saying these in an interview costs you the question

  • Whatever a library negotiates by default is by definition the secure choice.
  • WebRTC may fall back to SDES keys when DTLS-SRTP negotiation fails.
  • A NULL-cipher profile still keeps voice confidential because HMAC-SHA1 covers it.
  • Offering AES-GCM first guarantees a DTLS-SRTP peer will select it.
  • Choosing AES-256 counter mode also lengthens the HMAC-SHA1 authentication key.