ZRTP errors in logs - are they significant?
After ZRTP negotiation is complete (the ZRTP state machine has entered the "secure" state), I get a number of lines in the log as follows (FreeSWITCH rev. 13501): 2009-05-29 16:43:19 [DEBUG] switch_rtp.c:538 zrtp_logger() [zrtp protoco]: ERROR! Decrypt failed. ID=14:DH s=SRTP authentication failure (RTP size=172 ssrc=2760088424 seq=53043/53043 pt=9) They all have a time stamp of shortly after the end of the protocol negotiation. Is this normal, or a sign of trouble? The call itself is fine, and ZRTP does not leave the secure state until the end of the call: 2009-05-29 16:43:30 [DEBUG] switch_rtp.c:538 zrtp_logger() [ zrtp engine]: STOP STREAM ID=14 mode=DH state=SECURE. Are others seeing similar behaviour?
This is normal because the switch from clear to secure can happen quickly on one end or the other and you'll have a few packets that get thru before one end is ready... nothing to be worried about. /b On May 29, 2009, at 5:02 AM, Jason White wrote:
After ZRTP negotiation is complete (the ZRTP state machine has entered the "secure" state), I get a number of lines in the log as follows (FreeSWITCH rev. 13501):
2009-05-29 16:43:19 [DEBUG] switch_rtp.c:538 zrtp_logger() [zrtp protoco]: ERROR! Decrypt failed. ID=14:DH s=SRTP authentication failure (RTP size=172 ssrc=2760088424 seq=53043/53043 pt=9)
They all have a time stamp of shortly after the end of the protocol negotiation.
Is this normal, or a sign of trouble?
The call itself is fine, and ZRTP does not leave the secure state until the end of the call: 2009-05-29 16:43:30 [DEBUG] switch_rtp.c:538 zrtp_logger() [ zrtp engine]: STOP STREAM ID=14 mode=DH state=SECURE.
Are others seeing similar behaviour?
Brian West brian@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com
Brian West <brian@freeswitch.org> wrote:
This is normal because the switch from clear to secure can happen quickly on one end or the other and you'll have a few packets that get thru before one end is ready... nothing to be worried about.
I thought that might be the scenario. In a typical FreeSWITCH to FreeSWITCH call, the entire ZRTP key negotiation takes place during early media, hence not even the first few seconds of conversation are transmitted in the clear.
If you happen to have a polycom or snom and you use the new sched_api extension I added to trunk (commented out) it will sched_api and snag the zrtp sas1 and sas2 strings and 4 seconds after the call is up update the display of the polycom with those two strings... kinda handy eh? For those not wanting to go hunting for it. <action application="set" data="exec_after_bridge_app=${sched_api(+4 zrtp expand uuid_display ${uuid} \${uuid_getvar(\${uuid_getvar(${uuid} signal_bond)} zrtp_sas1_string )} \${uuid_getvar(\${uuid_getvar($ {uuid} signal_bond)} zrtp_sas2_string )} )}"/> :P Try that out! /b On May 29, 2009, at 10:31 PM, Jason White wrote:
I thought that might be the scenario.
In a typical FreeSWITCH to FreeSWITCH call, the entire ZRTP key negotiation takes place during early media, hence not even the first few seconds of conversation are transmitted in the clear.
Brian West brian@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com
participants (2)
-
Brian West
-
Jason White