ZRTP is a key agreement protocol. It sets the key for SRTP, which is ultimately responsible for securing the RTP payload. SRTP keys can also be set by the signaling server, but then the encryption is not end to end. There's another protocol called SDP to handle this

Signal does use ZRTP. It just doesn't use SIP. ZRTP is currently the best choice for voice.

> ZRTP is currently the best choice for voice.

I beg to differ. ZRTP is currently the best choice for voice when the caller and callee share no key material to begin with. In the context of Signal-the-app, the caller and callee often do share key material, but the protocol (to the best of my knowledge) doesn't bother to use that key material to authenticate the voice channel. This means that two users with the ability to securely text-message each other can still have their voice calls tapped if they fail to validate the short code each time.

The same omission also means that you cannot confirm that you have real end-to-end encryption by making a voice call and comparing the short authentication string on the screen.

I don't know whether Signal-the-protocol in WhatsApp is better designed, but calling ZRTP a good choice is ignoring the fact that current uses are not well thought out.

Actually, ZRTP supports SAS signing. This allows applications that use Axolotl to provide additional signatures to ZRTP, enabling sessions to be confirmed without human intervention. See section 7.2 of RFC 6189 for details. Support for Axolotl integration was added to the very popular ZRTPCPP library on August 1, 2015.

I think it's still a good idea for clients to display the SAS even when signed with another key. Especially when that session was established with a protocol which uses the TOFU model.