[SFLphone] SFLphone Digest, Vol 6, Issue 7

[Wang, Waylon]

The scenario you have described is plausible and practical. It would require some level of SIP server support. But an interesting use case can be presented to any serious enterprise voip users. 

Look forward to seeing it implemented in the near future.

Waylon

-----Original Message-----
From: sflphone-bounces at lists.savoirfairelinux.net [mailto:sflphone-bounces at lists.savoirfairelinux.net] On Behalf Of sflphone-request at lists.savoirfairelinux.net
Sent: Tuesday, June 16, 2009 9:00 AM
To: sflphone at lists.savoirfairelinux.net
Subject: SFLphone Digest, Vol 6, Issue 7

Send SFLphone mailing list submissions to
	sflphone at lists.savoirfairelinux.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.savoirfairelinux.net/mailman/listinfo/sflphone
or, via email, send a message with subject or body 'help' to
	sflphone-request at lists.savoirfairelinux.net

You can reach the person managing the list at
	sflphone-owner at lists.savoirfairelinux.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of SFLphone digest..."


Today's Topics:

   1. Re: TLS and SRTP support (pierre-luc)


----------------------------------------------------------------------

Message: 1
Date: Tue, 16 Jun 2009 10:53:30 -0400
From: pierre-luc <plbacon at savoirfairelinux.net>
Subject: Re: [SFLphone] TLS and SRTP support
To: sflphone at lists.savoirfairelinux.net
Message-ID: <1245164010.9613.21.camel at supercollider>
Content-Type: text/plain

I'm the developer at Savoir-Faire Linux who is in charge of that
project. 

I started implementing ZRTP in the last days based on the libzrtpcpp
extension. As I'm writing these lines, the implementation within the
sflphone deamon is mostly done. For the next days, I'll be working on
the gtk client to implement the needed user interactions. 

Multicast conference calls is a feature that we would like to add
in a near future. As you're pointing out, zrtp would not be suitable 
in that case. This is why the zrtp key exchange is configurable per
account. Also, when it is detected that the remote peer does not support
zrtp, the application automatically falls back to a "normal" unencrypted
symmetric rtp session.

SDES/SRTP will be the next target after ZRtp/SRTP. 

"I can imagine all multicast conference call users may want to use the
same master key for a given period of time"

I never though about ways to deal with that issue. Your suggestion makes
sense to me and should be feasible. Do you think of a scenario such as
this ?
	- A "zrtp-capable" client initiate a session with the central node then
generate a secret. Then this central node would share the key with the
other peers.

A problem that we are facing at the moment is that GNU Zrtp does not
appear to be supporting pre-shared mode. Hoping this will solve soon. 

You can follow progress here:
http://projects.savoirfairelinux.net/projects/activity/sflphone

Where all tickets are posted under the "srtp" category. Also, the "zrtp"
branch in git is a scratch pad that is then merged into the "pierre-luc"
branch which finally will end up being merged into the master when it's
stable enough. 

Thank you for giving us feedback,
Pierre-Luc Bacon
+1 (514) 276-5468 ext 118

-----Original Message-----
Emmanuel, 

Thanks for the update. Zrtp is an in-band, pair-wise key negotiation/distribution mechanism that works well for unicast calls. To support multicast conference calls, is it possible your zrtp feature be selectable? I can imagine all multicast conference call users may want to use the same master key for a given period of time, and want to disable zrtp but use only srtp. The key distribution can be handled by such thing as SDES (RFC4568).

Again, great news and thanks for the good work!

Waylon



------------------------------

_______________________________________________
SFLphone mailing list
SFLphone at lists.savoirfairelinux.net
http://lists.savoirfairelinux.net/mailman/listinfo/sflphone


End of SFLphone Digest, Vol 6, Issue 7
**************************************