[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] patch to enable ZRTP on Freeswitch in proxy me

From: Eli Burke
Subject: Re: [Linphone-developers] patch to enable ZRTP on Freeswitch in proxy media mode
Date: Wed, 7 Jan 2015 16:49:05 -0500


Rfc5939 sounds like a good solution, but after 4 years it does not seem to have 
been implemented in any client or switch that I can find. SRTP DTLS (rfc5763) 
seems to require rfc5939, so perhaps you guys have plans to implement that you 
would like to share?

To your point of not wanting to offer 6 profiles, I disagree with your logic. 
When you finish your implementations for AVPF and DTLS, I imagine that you 
would expose them as toggles:
1) Offering AVP or AVPF (when using ZRTP or No Crypto, depending on the 
Feedback setting)
2) Offering SAVP or SAVPF or DTLS SAVP or DTLS SAVPF (when using SRTP, 
depending on the Feedback setting and the DTLS setting)

In such a situation, my patch would only ever increase the number of m lines 
from 1 to 2. Feedback off? Linphone offers AVP and SAVP. Feedback on? Linphone 
offers AVPF and SAVPF. DTLS on? Linphone offers AVP and DTLS SAVP. Etc.

I understand that you are not inclined to accept this patch, but there is an 
opportunity to make Linphone behave much more securely. This patch does more 
than just improve Freeswitch interoperability; it allows Linphone to be 
configured to use both SRTP and ZRTP without requiring that the users change 
their crypto settings. This is essential in a mixed device environment that 
includes SRTP-only hardware devices, or calls out through a PSTN gateway.

Others have worked around this problem and there are only a few ways to do it:
0) rfc5939
1) offer two profiles, as in my patch
2) rfc6189 - always offer AVP, add zrtp-hash for ZRTP, add crypto lines for 
SRTP (see rfc6189 or draft-kaplan-mmusic-best-effort-srtp-01)
3) always offer SAVP, always attempt to negotiate ZRTP

If you don’t like the multiple profile solution, are you likely to accept a 
patch that implements one of the other two “hacks” ?


> Date: Tue, 6 Jan 2015 18:54:55 +0100
> From: jehan monnier <address@hidden>
> Hi Eli,
> I was just reviewing your patch.  For offering both AVP and SAVP, it seems 
> rfc5939 propose a smart alternative to having multiple m lines.
> If we add SRTP DTLS, possible m lines would become RTP/AVP, RTP/SAVP, 
> offer 6 m lines.
> Best regards
> Jehan
> Le 23 d?c. 2014 ? 20:23, Eli Burke <address@hidden> a ?crit :
>> Attached is an updated version of the zrtp hash patch I submitted last year. 
>> This allows liblinphone to negotiate ZRTP when registered to Freeswitch 
>> running in proxy media mode by adding a fake zrtp-hash attribute to the 
>> initial SDP. Freeswitch detects this attribute in order to correctly 
>> configure the two call legs. This is the exact same technique Groundwire 
>> uses.
>> If you are curious about why the switch would be configured like that, this 
>> pretty much covers it:
>> The patch does a number of things:
>> 1) adds ?zrtp_available" to the SalMediaDescription structure, and 
>> sal_stream_description_has_zrtp() to return it
>> 2) modifies sal_media_description_find_best_stream to prefer any stream with 
>> ZRTP, then SRTP, then AVP
>> 3) modifies linphone_call_make_local_media_description to set zrtp_available 
>> based on the settings returned by linphone_core_get_media_encryption() and 
>> linphone_core_is_media_encryption_mandatory()
>> 4) modifies stream_description_to_sdp to add a fake zrtp-hash attribute to 
>> outbound streams if zrtp_available is set
>> 5) modifies sdp_to_stream_description to detect a zrtp-hash attribute and 
>> set zrtp_available on inbound streams
>> 6) modifies initiate_outgoing() and initiate_incoming() to set 
>> zrtp_available on the result stream if it is present in both the local and 
>> remote streams
>> My version of liblinphone is able to advertise both SRTP and ZRTP at the 
>> same time, so my changes to sal_media_description_find_best_stream() and 
>> linphone_call_make_local_media_description() are designed with this in mind. 
>> (in ?both? mode, the first two streams are audio? one SAVP and one AVP). If 
>> there is interest, I?d be willing to make a patch for that feature too, but 
>> it?s fairly complex and anyone who integrates it would have to make their 
>> own UI changes.
>> <add_zrtp_hash.patch>
>> -Eli

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

reply via email to

[Prev in Thread] Current Thread [Next in Thread]