From: "address@hidden" <address@hidden>
To: address@hidden
Sent: Saturday, February 2, 2013 8:33 AM
Subject: Linphone-developers Digest, Vol 120, Issue 3
Send Linphone-developers mailing list submissions to
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
https://lists.nongnu.org/mailman/listinfo/linphone-developersor, via email, send a message with subject or body 'help' to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Linphone-developers digest..."
Today's Topics:
1. Question About Security Feature (Mohamad Mansouri)
2. Re: Failure to establish ZRTP sessions using linphone-iphone
built from source (Eli Burke)
3. Re: Failure to establish ZRTP sessions using linphone-iphone
built from source (Werner Dittmann)
4. Re: Question About Security Feature (Werner Dittmann)
5. Join my network on LinkedIn (Eric des Courtis via LinkedIn)
----------------------------------------------------------------------
Message: 1
Date: Fri, 1 Feb 2013 12:39:21 -0800 (PST)
From: Mohamad Mansouri <
address@hidden>
To: "
address@hidden" <
address@hidden>
Subject: [Linphone-developers] Question About Security Feature
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
hello dears
i confused about security feature in?linphone?APP:
ZRTP is key?management and?agreement protocol and SRTP is security profile for RTP protocol. SRTP get it's needed security
parameters form another protocol such as ZRTP or MIKEYor SDES, ok?
now when we?choice SRTP in encryption menu not ZRTP, where SRTP found it's needed security parameters such as key for AES algorithm? or in another situation, using ZRTP alone how could secure my call?While the SRTP not actived?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.nongnu.org/archive/html/linphone-developers/attachments/20130201/4b6a59b6/attachment.html>
------------------------------
Message: 2
Date: Fri, 1 Feb 2013 16:19:53 -0500
From: Eli Burke <
address@hidden>
To:
address@hiddenSubject: Re: [Linphone-developers] Failure to establish ZRTP sessions
using linphone-iphone built from source
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="us-ascii"
Peter,
I'm glad to know I'm not alone in this! The silence here and on the Freeswitch mailing list has been somewhat discouraging.
Like you, I had also tried disabling the CRC check and observed the garbled audio.. I think it's due to the progressive nature of the hash on the ZRTP packets.. once it goes wrong, it stays wrong.
Today I observed something interesting while examining ZRTP hello packets with Wireshark. When I establish a connection
between two Groundwire clients, the ZRTP Hello packet is passed through Freeswitch unaltered. When I use two Linphones, or one of each as either the caller or callee, that's when I see the SSRC change as it passes through Freeswitch.
My new speculation is that some detail setting in the ZRTP hello packet is responsible. I'll be looking at it more next week, but FWIW, here are the respective bits of packet, starting immediately after the ZID:
http://tools.ietf.org/html/rfc6189#section-5.2Here is Linphone:
00050 00 01 12 21 53 32 35 36 ...!S256
00060 41 45 53 31 48 53 33 32 48 53 38 30 44 48 33 6b AES1HS32HS80DH3k
00070 4d 75 6c 74 42 33 32 20 7b a2 28 be dd b5 b1 70
MultB32 {.(....p
00080 0d 69 39 db .i9.
And here is Groundwire:
00050 00 02 32 12 53 32 35 36 ..2.S256
00060 53 33 38 34 41 45 53 33 41 45 53 32 41 45 53 31 S384AES3AES2AES1
00070 48 53 33 32 48 53 38 30 44 48 33 6b 42 32 35 36 HS32HS80DH3kB256
00080 42 33 32 20 5a 9d dc 01 57 32 72 72 08 51 18 b4 B32 Z...W2rr.Q..
Off the top of my head I see variations in the hash, and the passive flag, among others.
-Eli
On Jan 31, 2013, at 12:00 PM,
address@hidden wrote:
> Date: Thu, 31 Jan 2013 01:37:00 +0000
> From: Peter Kosztolanyi <
address@hidden>
> To:
address@hidden> Subject: Re: [Linphone-developers] Failure to establish ZRTP sessions
> using linphone-iphone built from source
> Message-ID: <
address@hidden>
> Content-Type: text/plain; charset=us-ascii
>
> I have exactly the same problem with the same scenario. I made some
additional investigations, maybe it can help to find the what's going wrong.
>
> 1) Enabling proxy-media in freeswitch, disabling the ZRTP CRC check in oRTP and recompiling linphone onto two devices (android & iPhone):
> Result: Connection is encrypted, same SAS on both legs but serious problem with the voice. It's scratching and beeping.
>
> 2) Enabling bypass-media in freeswitch and using the original oRTP for linphone:
> Result: Connection is encrypted, same SAS on both legs, clear voice. Btw it works only if the two devices on the same network but this is normal.
>
> So I think linphone works correctly and we have to look around what proxy-media is really doing in freeswitch and why it is modifying the packets.. but any other idea welcomed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.nongnu.org/archive/html/linphone-developers/attachments/20130201/b6162dbe/attachment.html>
------------------------------
Message: 3
Date: Sat, 02 Feb 2013 08:02:39 +0100
From: Werner Dittmann <
address@hidden>
To:
address@hiddenSubject: Re: [Linphone-developers] Failure to establish ZRTP sessions
using linphone-iphone built from source
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Am
01.02.2013 22:19, schrieb Eli Burke:
> Peter,
>
> I'm glad to know I'm not alone in this! The silence here and on the Freeswitch mailing list has been somewhat discouraging.
>
> Like you, I had also tried disabling the CRC check and observed the garbled audio.. I think it's due to the progressive nature of the hash on the ZRTP packets..
> once it goes wrong, it stays wrong.
>
> Today I observed something interesting while examining ZRTP hello packets with Wireshark. When I establish a connection between two Groundwire clients, the ZRTP
> Hello packet is passed through Freeswitch unaltered. When I use two Linphones, or one of each as either the caller or callee, that's when I see the SSRC change
> as it passes through Freeswitch.
>
> My new speculation is that some detail setting in the ZRTP hello packet is responsible. I'll be looking at it more next week, but FWIW, here are the
respective
> bits of packet, starting immediately after the ZID:
It's not a problem in ZRTP packets, it's the way FreeSwitch (FS) works if I'm not completely mistaken.
FS terminates the RTP session from the SIP client and opens a new RTP session to the other client, thus
FS it's not "transparent" with regard to RTP. Obviously both RTP sessions have different SSRCs which is
correct according to the RTP spec (RFC 3550).
I'm not sure about the current implementation of FS (you may ask on the FS mailing list), however since some
time FS permits transparent RTP handling if both clients add the "zrtp-hash" attribute to the SIP/SDP
data. If FS detects this attribute it knows that both clients support ZRTP and that it shall just passthru
the RTP packets. Groundwire adds this SIP/SDP attribute. You may have a look at the SIP data that
Groundwire sends and compare it with Linphone's data.
Or you configure FS to
bypass media (as noted in the email below) if your network configuration
permits it.
A short time ago someone on this list stated that Linphone does not support the "zrtp-hash" attribute
in SIP/SDP. That's an optional attribute but some switches (FS, maybe Astrisk) use it the change their
internal handling of RTP dynamically.
Werner
>
http://tools.ietf.org/html/rfc6189#section-5.2>
> Here is Linphone:
> 00050 00 01 12 21 53 32 35 36 ...!S256
> 00060 41 45 53 31 48 53 33 32 48 53 38 30 44 48 33 6b AES1HS32HS80DH3k
> 00070 4d 75 6c 74 42 33 32 20 7b a2 28 be dd b5 b1 70 MultB32 {.(....p
> 00080 0d 69 39
db .i9.
>
> And here is Groundwire:
> 00050 00 02 32 12 53 32 35 36 ..2.S256
> 00060 53 33 38 34 41 45 53 33 41 45 53 32 41 45 53 31 S384AES3AES2AES1
> 00070 48 53 33 32 48 53 38 30 44 48 33 6b 42 32 35 36 HS32HS80DH3kB256
> 00080 42 33 32 20 5a 9d dc 01 57 32 72 72 08 51 18 b4 B32 Z...W2rr.Q..
>
> Off the top of my head I see variations in the hash, and the passive flag, among others.
>
> -Eli
>
> On Jan 31, 2013, at 12:00 PM,
address@hidden <mailto:
address@hidden> wrote:
>
>> Date: Thu, 31 Jan 2013 01:37:00 +0000
>> From: Peter Kosztolanyi <
address@hidden <mailto:
address@hidden>>
>> To:
address@hidden <mailto:
address@hidden>
>> Subject: Re:
[Linphone-developers] Failure to establish ZRTP sessions
>> usinglinphone-iphone built from source
>> Message-ID: <
address@hidden <mailto:
address@hidden>>
>> Content-Type: text/plain; charset=us-ascii
>>
>> I have exactly the same problem with the same scenario. I made some additional investigations, maybe it can help to find the what's going wrong.
>>
>> 1) Enabling proxy-media in freeswitch, disabling the ZRTP CRC check in oRTP and recompiling linphone onto two devices (android & iPhone):
>> Result: Connection is encrypted, same SAS on both legs but serious problem with
the voice. It's scratching and beeping.
>>
>> 2) Enabling bypass-media in freeswitch and using the original oRTP for linphone:
>> Result: Connection is encrypted, same SAS on both legs, clear voice. Btw it works only if the two devices on the same network but this is normal.
>>
>> So I think linphone works correctly and we have to look around what proxy-media is really doing in freeswitch and why it is modifying the packets.. but any
>> other idea welcomed.
>
>
>
> _______________________________________________
> Linphone-developers mailing list
>
address@hidden>
https://lists.nongnu.org/mailman/listinfo/linphone-developers>
--
----------------------------------------------
Werner Dittmann
address@hiddenTel +49 173 44 37 659
PGP key: 82EF5E8B
------------------------------
Message: 4
Date: Sat, 02 Feb 2013 08:11:35 +0100
From: Werner Dittmann <
address@hidden>
To:
address@hiddenSubject: Re: [Linphone-developers] Question About Security Feature
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Am 01.02.2013 21:39, schrieb Mohamad
Mansouri:
> hello dears
> i confused about security feature in linphone APP:
> ZRTP is key management and agreement protocol and SRTP is security profile for RTP protocol. SRTP get it's needed security parameters form another protocol such
> as ZRTP or MIKEYor SDES, ok?
Yes, correct.
> now when we choice SRTP in encryption menu not ZRTP, where SRTP found it's needed security parameters such as key for AES algorithm? or in another situation,
> using ZRTP alone how could secure my call While the SRTP not actived?
ZRTP activates and uses SRTP implicitly if you enable ZRTP
Without knowing the Linphone implementation in detail my guess is that if just only enable
SRTP then Linphone uses SDES to exchange the crypto information. In this case it is mandatory
that you use an ecrypted SIP connection (SIPS) and a trustworthy SIP server/SIP proxy. SDES
exhanges the crypto data (keys for example)
in clear text in the SIP/SDP data. Therefore
not using encryptd SIP moots security. Also keep in mind: the encrypted SIP (SIPS) only
encrypts the data between the client and the SIP server/proxy, thus the SIP server/proxy
knows about all the keys!
ZRTP uses the media channel, end-to-end, directly between clients to negotiate the keys etc
and it's much more secure in that regard.
Werner
>
>
> _______________________________________________
> Linphone-developers mailing list
>
address@hidden>
https://lists.nongnu.org/mailman/listinfo/linphone-developers>
--
----------------------------------------------
Werner Dittmann
address@hiddenTel +49 173 44 37 659
PGP key: 82EF5E8B
------------------------------
Message: 5
Date: Sat, 2 Feb 2013 16:32:56 +0000 (UTC)
From: Eric des Courtis via LinkedIn <
address@hidden>
To: Subhash Kumar G V V <
address@hidden>
Subject: [Linphone-developers] Join my network on LinkedIn
Message-ID:
<
address@hidden>
Content-Type: text/plain;
charset="utf-8"
LinkedIn
------------
Eric des Courtis requested to add you as a connection on LinkedIn:
------------------------------------------
Subhash Kumar,
I'd like to add you to my professional network on LinkedIn.
- Eric
Accept invitation from Eric des Courtis
http://www.linkedin.com/e/-eny74y-hcozddd7-62/uYFEuWLlC02mozDbre8hS0Gf4ea_5Ii-llrtSWAlFRwotI/blk/I375135564_65/3wOtCVFbmdxnSVFbm8JrnpKqlZJrmZzbmNJpjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfPkSnPgSdjkPcjkTcQALgChLomxBtQgLe38Sd3sUdjkUc34LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=2hIbqGWeYwQBA1View profile of Eric des Courtis
http://www.linkedin.com/e/-eny74y-hcozddd7-62/rso/27174404/PXOM/name/66762757_I375135564_65/?hs=false&tok=38kB1skuMwQBA1------------------------------------------
You are receiving Invitation emails.
This email was intended for Subhash Kumar G V V.
Learn why this is included:
http://www.linkedin.com/e/-eny74y-hcozddd7-62/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=36tWRqNwIwQBA1(c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.nongnu.org/archive/html/linphone-developers/attachments/20130202/5905cc06/attachment.html>
------------------------------
_______________________________________________
Linphone-developers mailing list
address@hiddenhttps://lists.nongnu.org/mailman/listinfo/linphone-developersEnd of Linphone-developers Digest, Vol 120, Issue 3
***************************************************