If you configure the
gateway for SRTP (globally or on an individual dial peer) and end-to-end TLS,
an outgoing INVITE message has cryptographic parameters in the SDP.
If you use the
fallback command and the called endpoint does not
support SRTP (offer is rejected with a 4xx class error response), the gateway or Cisco Unified
Border Element sends an RTP offer SDP in a new INVITE request. If you do not
fallback command, the call fails.
The calls established with SRTP at one end and SRTP fall back at
the other end will succeed even if the
fallback command is not configured.
When a gateway
receives an SRTP
offer, negotiation is based on the inbound dial peer if specified and, if not,
the global configuration. If multiple cryptographic attributes are offered, the
gateway selects an SRTP offer it supports (AES_CM_128_HMAC_SHA1_32). The
cryptographic attribute will include the following:
The tag and same
crypto suite from the accepted cryptographic attribute in the offer.
A unique key the
gateway generates from the SRTP library API.
session parameters and its own set of declarative parameters, if any.
If this cryptographic
suite is not in the list of offered attributes, or if none of the attributes
are valid, the SRTP negotiation fails. If the INVITE message contains an
alternative RTP offer, the gateway
the call falls back to (nonsecure) RTP mode. If there is no alternative offer
and the SRTP negotiation fails, the INVITE message is rejected with a 488 error
(Not Acceptable Media).