SRTP with Fax Calls
The SBC supports SRTP for fax calls transmitted using standard G.711 codecs (PCMU or PCMA).
- Forwarding a reINVITE from one side to the other
- Generating a reINVITE locally. For example, when establishing transcoding if one leg sends T.38 or when fax tones are detected without a reINVITE.
- Redirecting to a designated fax server or alternative endpoint after detecting a fax tone.
- Transitioning back to voice when fax-continue-session is set to faxToVoice.
For fax reINVITEs, the SBC reuses the existing outbound crypto by default and generates a new one when srtp-rekey-on-reinvite is enabled, as described in SRTP Re-keying.
For fax reINVITEs, the SBC reuses the existing outbound crypto attribute by default and generates a new one when you enable srtp-rekey-on-reinvite, as described in SRTP Rekeying. This applies in fallback cases as well.
When you set fax-continue-session to faxToVoice, any updates to the crypto attribute made in refresh reINVITE responses are not reflected. Instead, the previous outbound crypto attributes are used. This is true regardless of the srtp-rekey-on-reinvite setting. See Fax reINVITE Handling in the SIP Signaling Services chapter of this guide for more information.
- DTLS-SRTP
- Hairpin calls
- T.38 to T.38. Because SRTP is not supported for the T.38 codec, end-to-end T.38 fax calls are not transmitted over SRTP, even if an SRTP policy is applied.
- T.140
- With ringback tones; SRTP is only applicable when fax calls have been established
- Interaction with the add-sdp-invite parameter on the sip-interface
- Interaction with the simultaneous-best-effort value for the egress-offer-format parameter on sdes-profile
- When fax-conti-sess-ext and srtp-rekey-on-reinvite both are enabled, SRTP re-keying is not supported for non-refresh reINVITEs.