When testing SDES key exchange mechanism to add information to the CallInfoFrame, I have seen the following behavior (corresponding to Jisti svn revision #9424):
[Configuration with SIP protocol using SDES and with TCP for the control transport protocol (no TLS)].
[JITSI point of view]
The call info frame display that the SDES mechanism is successful (information based on the CallPeerMediaHandler.srtpControls), but the CallPanel shows an open padlock.
[WIRESHARK point of view]
Wireshark displays the following SDES key exchange (which seems to work correctly), but display media packets only as RTP one (no SRTP):
PCA -> PCB SIP/SDP INVITE with:
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_80 inline: ABC...
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_32 inline: 123...
PCB -> PCA SIP/SDP 200 OK with:
- Media Attribute (a): crypto: 1 AES_CM_128_HMAC_SHA1_80 inline: XYZ...
PCA -> PCB SIP ACK.
Does someone knows:
- Why for wireshark, the key exchange seems to work correctly and nevertheless it sees only RTP media packets? In contrary for ZRTP, wireshark displays correctly SRTP media packets once the key exchange is done).
- Why for Jitsi, the padlock on the CallPanel does not correspond to the information available in the CallPeerMediaHandler.srtpControls?