We were never able to get Trusted MITM working, but ZRTP can work in proxy-media mode as long as your client sends the zrtp-hash attribute in its SDP. When Freeswitch sees the zrtp-hash attribute it enables logic to pass the zrtp packets through unmolested (using the same SSRC for each call leg).

As Mehroz noted in his original question, Linphone does not currently support zrtp-hash so this can't work. However, Mehroz, if you look in the Feb 2013 archives of the linphone-developers mailing list you can find a patch that adds zrtp-hash support to Linphone. It was recently rejected because it causes side-effects when video is enabled, but you can test it out and see if it fixes the your problem. 

-Eli

On Apr 9, 2013, at 12:01 PM, freeswitch-users-request@lists.freeswitch.org wrote:

From: Steven Ayre <steveayre@gmail.com>
Subject: Re: [Freeswitch-users] problems with freeswitch + zrtp in proxy-media mode
Date: April 9, 2013 12:00:21 PM EDT
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>


There is a way to do Trusted MITM I believe there is a setting for that
 
<action application="set" data="zrtp_enrollment=true"/>


On 9 April 2013 16:11, Ken Rice <krice@freeswitch.org> wrote:
Also, keep in mind that FS in a mode other then proxy or bypass media, when
you have a ZRTP call is kind of pointless, that leads to a vector for a man
in the middle attack which is also the reason the SASs don't match is you
have 2 different ZRTP legs with FS in the middle decrypting and
re-encrypting the conversation...

There is a way to do Trusted MITM I believe there is a setting for that


On 4/9/13 4:57 AM, "mehroz" <mehroz.ashraf85@gmail.com> wrote:

> Any luck with this issue?
>
> I am having the same configurations, FS acting as normal mode i.e bypass and
> proxy on default(commented)
>
> Clients are Linphone, and SAS does not match......
>
> Over jitsi ... SAS are identical ONLY IF
>
> IF linphone does not support "zrtp-hash" attribute in SIP/SDP, what is the
> next possible solution?