[sip-comm-dev] Configuration form for ZRTP


#1

Emil, all,

after some editing I'm nearly done with a new function that enables
a way to configure ZRTP, i.e select algorithms to use. Currently only
a few algorithms are available. Depending on interesst and time I'm
going to add some more algorithms and settings that influence the
ZRTP processing. Of course there is always a "standard" setting that
just works :slight_smile: . The ZrtpConfigure works similar to OTR or Media
configuration forms.

Currently I'm looking for a nice and cosy place (aka package) where to
put the sources. Because the ZrtpConfigure is fairly tightly coupled
to ZRTP my first guess is to put it into "...media.transform.zrtp" .
The whole stuff consists of three source files and a manifest, plus
an icon (which has to be brushed up considerably :slight_smile: ).

What do you think?

Regards,
Werner

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Werner,

we are currently working on neomedia service and I am the one that is
migrating the zrtp code into the new media service. As there are some
major changes in the media handling some parts of the zrtp
implementation has also changed (mostly the initialization code from
CallSessionImpl which is no longer present).
I have one question: its about zrtp-hash. I can see how it is
generated and put into the sdp description but I cannot see a place
where we use it if such an sdp comes in, what's the case here or am I
missing something?

Thanks
damencho

P.S. By the way with your latest commit you have broke the build,
tests are failing. You have modified felix.client.run.properties but
haven't modify the properties that are needed by the tests -
felix.unit.test.properties and the media service fails to load and so
the jabber-protocol bundle. And one more thing, you have made the
media service dependent to a plugin, I don't think this is a good idea
and that's why it doesn't start when this plugin is not enabled, what
do you think?

路路路

On Wed, Dec 2, 2009 at 2:47 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Emil, all,

after some editing I'm nearly done with a new function that enables
a way to configure ZRTP, i.e select algorithms to use. Currently only
a few algorithms are available. Depending on interesst and time I'm
going to add some more algorithms and settings that influence the
ZRTP processing. Of course there is always a "standard" setting that
just works :slight_smile: . The ZrtpConfigure works similar to OTR or Media
configuration forms.

Currently I'm looking for a nice and cosy place (aka package) where to
put the sources. Because the ZrtpConfigure is fairly tightly coupled
to ZRTP my first guess is to put it into "...media.transform.zrtp" .
The whole stuff consists of three source files and a manifest, plus
an icon (which has to be brushed up considerably :slight_smile: ).

What do you think?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Damian,

Hi Werner,

we are currently working on neomedia service and I am the one that is
migrating the zrtp code into the new media service. As there are some
major changes in the media handling some parts of the zrtp
implementation has also changed (mostly the initialization code from
CallSessionImpl which is no longer present).
I have one question: its about zrtp-hash. I can see how it is
generated and put into the sdp description but I cannot see a place
where we use it if such an sdp comes in, what's the case here or am I
missing something?

the zrtp-hash is currently not used by sip-communicator but by other ZRTP
software, for example zfone. Zfone uses this for example to check if
the client that sends the INVITE already has ZRTP enabled and zfone will
not process it an further. This is nice if a customer has both, zfone and
Sip-communicator installed.

Thanks
damencho

P.S. By the way with your latest commit you have broke the build,
tests are failing. You have modified felix.client.run.properties but
haven't modify the properties that are needed by the tests -
felix.unit.test.properties and the media service fails to load and so
the jabber-protocol bundle.

Sorry about that - I always forget to fix the test properties. I'll
update it and check it in in just a couple of minutes or so.

And one more thing, you have made the

media service dependent to a plugin, I don't think this is a good idea
and that's why it doesn't start when this plugin is not enabled, what
do you think?

That was my first thought as well. Looking at the code however I saw that
Media already has an activator to register its configuration code. Because
I'm not so familiar with this I left it as a separate plugin. Is it possible
to register several configuration panel inside one activator? If yes we can
merge the ZrtpConfigure with the media actiavtor once you did all the
modifications.

Regards,
Werner

路路路

Am 07.12.2009 17:22, schrieb Damian Minkov:

On Wed, Dec 2, 2009 at 2:47 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Emil, all,

after some editing I'm nearly done with a new function that enables
a way to configure ZRTP, i.e select algorithms to use. Currently only
a few algorithms are available. Depending on interesst and time I'm
going to add some more algorithms and settings that influence the
ZRTP processing. Of course there is always a "standard" setting that
just works :slight_smile: . The ZrtpConfigure works similar to OTR or Media
configuration forms.

Currently I'm looking for a nice and cosy place (aka package) where to
put the sources. Because the ZrtpConfigure is fairly tightly coupled
to ZRTP my first guess is to put it into "...media.transform.zrtp" .
The whole stuff consists of three source files and a manifest, plus
an icon (which has to be brushed up considerably :slight_smile: ).

What do you think?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi again,

I have one more question regarding zrtp-hash I remember back in
January when we were preparing for the FOSDEM demo that the zrtp-hash
was something like bas64 string, but now I see it that is just
something like 1.10. Is this normal or what actually this string must
represent ?

Thanks
damencho

路路路

On Mon, Dec 7, 2009 at 7:25 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Hi Damian,

Am 07.12.2009 17:22, schrieb Damian Minkov:

Hi Werner,

we are currently working on neomedia service and I am the one that is
migrating the zrtp code into the new media service. As there are some
major changes in the media handling some parts of the zrtp
implementation has also changed (mostly the initialization code from
CallSessionImpl which is no longer present).
I have one question: its about zrtp-hash. I can see how it is
generated and put into the sdp description but I cannot see a place
where we use it if such an sdp comes in, what's the case here or am I
missing something?

the zrtp-hash is currently not used by sip-communicator but by other ZRTP
software, for example zfone. Zfone uses this for example to check if
the client that sends the INVITE already has ZRTP enabled and zfone will
not process it an further. This is nice if a customer has both, zfone and
Sip-communicator installed.

Thanks
damencho

P.S. By the way with your latest commit you have broke the build,
tests are failing. You have modified felix.client.run.properties but
haven't modify the properties that are needed by the tests -
felix.unit.test.properties and the media service fails to load and so
the jabber-protocol bundle.

Sorry about that - I always forget to fix the test properties. I'll
update it and check it in in just a couple of minutes or so.

And one more thing, you have made the

media service dependent to a plugin, I don't think this is a good idea
and that's why it doesn't start when this plugin is not enabled, what
do you think?

That was my first thought as well. Looking at the code however I saw that
Media already has an activator to register its configuration code. Because
I'm not so familiar with this I left it as a separate plugin. Is it possible
to register several configuration panel inside one activator? If yes we can
merge the ZrtpConfigure with the media actiavtor once you did all the
modifications.

Regards,
Werner

On Wed, Dec 2, 2009 at 2:47 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Emil, all,

after some editing I'm nearly done with a new function that enables
a way to configure ZRTP, i.e select algorithms to use. Currently only
a few algorithms are available. Depending on interesst and time I'm
going to add some more algorithms and settings that influence the
ZRTP processing. Of course there is always a "standard" setting that
just works :slight_smile: . The ZrtpConfigure works similar to OTR or Media
configuration forms.

Currently I'm looking for a nice and cosy place (aka package) where to
put the sources. Because the ZrtpConfigure is fairly tightly coupled
to ZRTP my first guess is to put it into "...media.transform.zrtp" .
The whole stuff consists of three source files and a manifest, plus
an icon (which has to be brushed up considerably :slight_smile: ).

What do you think?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi,

one more question and hope the last one :slight_smile: Cause I'm little confused
about the options - there are two configurations for the sip account -
enable support to encrypt calls and indicate support of zrtp in sip
data.
So there are three possible situations :
1. Everything is off
2. "Enable support to encrypt calls" is TURNED ON
3. "Enable support to encrypt calls" and "indicate support of zrtp in
sip data" are both TURNED ON.
What must happen in all the situation, I suppose 1 is like we don't
support zrtp at all. And the others ?

Thanks once again for answering my questions :slight_smile:
damencho

P.S. about my previous question about zrtp-hash, I was wondering as it
seems its a constant string (1.10) and is not dependent to some zrtp
engine instance, why this string is not a static field in the library
or again I'm missing something about zrtp-hash. Thanks.

路路路

On Tue, Dec 8, 2009 at 3:09 PM, Damian Minkov <damencho@sip-communicator.org> wrote:

Hi again,

I have one more question regarding zrtp-hash I remember back in
January when we were preparing for the FOSDEM demo that the zrtp-hash
was something like bas64 string, but now I see it that is just
something like 1.10. Is this normal or what actually this string must
represent ?

Thanks
damencho

On Mon, Dec 7, 2009 at 7:25 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Hi Damian,

Am 07.12.2009 17:22, schrieb Damian Minkov:

Hi Werner,

we are currently working on neomedia service and I am the one that is
migrating the zrtp code into the new media service. As there are some
major changes in the media handling some parts of the zrtp
implementation has also changed (mostly the initialization code from
CallSessionImpl which is no longer present).
I have one question: its about zrtp-hash. I can see how it is
generated and put into the sdp description but I cannot see a place
where we use it if such an sdp comes in, what's the case here or am I
missing something?

the zrtp-hash is currently not used by sip-communicator but by other ZRTP
software, for example zfone. Zfone uses this for example to check if
the client that sends the INVITE already has ZRTP enabled and zfone will
not process it an further. This is nice if a customer has both, zfone and
Sip-communicator installed.

Thanks
damencho

P.S. By the way with your latest commit you have broke the build,
tests are failing. You have modified felix.client.run.properties but
haven't modify the properties that are needed by the tests -
felix.unit.test.properties and the media service fails to load and so
the jabber-protocol bundle.

Sorry about that - I always forget to fix the test properties. I'll
update it and check it in in just a couple of minutes or so.

And one more thing, you have made the

media service dependent to a plugin, I don't think this is a good idea
and that's why it doesn't start when this plugin is not enabled, what
do you think?

That was my first thought as well. Looking at the code however I saw that
Media already has an activator to register its configuration code. Because
I'm not so familiar with this I left it as a separate plugin. Is it possible
to register several configuration panel inside one activator? If yes we can
merge the ZrtpConfigure with the media actiavtor once you did all the
modifications.

Regards,
Werner

On Wed, Dec 2, 2009 at 2:47 PM, Werner Dittmann >>> <Werner.Dittmann@t-online.de> wrote:

Emil, all,

after some editing I'm nearly done with a new function that enables
a way to configure ZRTP, i.e select algorithms to use. Currently only
a few algorithms are available. Depending on interesst and time I'm
going to add some more algorithms and settings that influence the
ZRTP processing. Of course there is always a "standard" setting that
just works :slight_smile: . The ZrtpConfigure works similar to OTR or Media
configuration forms.

Currently I'm looking for a nice and cosy place (aka package) where to
put the sources. Because the ZrtpConfigure is fairly tightly coupled
to ZRTP my first guess is to put it into "...media.transform.zrtp" .
The whole stuff consists of three source files and a manifest, plus
an icon (which has to be brushed up considerably :slight_smile: ).

What do you think?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Damian,

if it shows 1.10 only then something is wrong :slight_smile: .
The hash string should look like this:

zrtp-hash:1.10 fe30efd02423cb054e50efd0248742ac7a52c8f91bc2df881ae642c371ba46df

and the binary part depends on some values when initiating
ZRTP.

Thus before one call call "getHelloHash()" the ZRTP engine must
be initialized. Pls have a look to the old method initializeRtpManager()
how this works. The ZRTP initialize method does not start ZRTP
but sets the ZRTP engine in a "ready to go" state (autostart == true).
Once the first data flows on the RTP session ZRTP kicks in.

Regards,
Werner

路路路

Am 08.12.2009 14:09, schrieb Damian Minkov:

Hi again,

I have one more question regarding zrtp-hash I remember back in
January when we were preparing for the FOSDEM demo that the zrtp-hash
was something like bas64 string, but now I see it that is just
something like 1.10. Is this normal or what actually this string must
represent ?

Thanks
damencho

On Mon, Dec 7, 2009 at 7:25 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Hi Damian,

Am 07.12.2009 17:22, schrieb Damian Minkov:

Hi Werner,

we are currently working on neomedia service and I am the one that is
migrating the zrtp code into the new media service. As there are some
major changes in the media handling some parts of the zrtp
implementation has also changed (mostly the initialization code from
CallSessionImpl which is no longer present).
I have one question: its about zrtp-hash. I can see how it is
generated and put into the sdp description but I cannot see a place
where we use it if such an sdp comes in, what's the case here or am I
missing something?

the zrtp-hash is currently not used by sip-communicator but by other ZRTP
software, for example zfone. Zfone uses this for example to check if
the client that sends the INVITE already has ZRTP enabled and zfone will
not process it an further. This is nice if a customer has both, zfone and
Sip-communicator installed.

Thanks
damencho

P.S. By the way with your latest commit you have broke the build,
tests are failing. You have modified felix.client.run.properties but
haven't modify the properties that are needed by the tests -
felix.unit.test.properties and the media service fails to load and so
the jabber-protocol bundle.

Sorry about that - I always forget to fix the test properties. I'll
update it and check it in in just a couple of minutes or so.

And one more thing, you have made the

media service dependent to a plugin, I don't think this is a good idea
and that's why it doesn't start when this plugin is not enabled, what
do you think?

That was my first thought as well. Looking at the code however I saw that
Media already has an activator to register its configuration code. Because
I'm not so familiar with this I left it as a separate plugin. Is it possible
to register several configuration panel inside one activator? If yes we can
merge the ZrtpConfigure with the media actiavtor once you did all the
modifications.

Regards,
Werner

On Wed, Dec 2, 2009 at 2:47 PM, Werner Dittmann >>> <Werner.Dittmann@t-online.de> wrote:

Emil, all,

after some editing I'm nearly done with a new function that enables
a way to configure ZRTP, i.e select algorithms to use. Currently only
a few algorithms are available. Depending on interesst and time I'm
going to add some more algorithms and settings that influence the
ZRTP processing. Of course there is always a "standard" setting that
just works :slight_smile: . The ZrtpConfigure works similar to OTR or Media
configuration forms.

Currently I'm looking for a nice and cosy place (aka package) where to
put the sources. Because the ZrtpConfigure is fairly tightly coupled
to ZRTP my first guess is to put it into "...media.transform.zrtp" .
The whole stuff consists of three source files and a manifest, plus
an icon (which has to be brushed up considerably :slight_smile: ).

What do you think?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Damian,

see inline pls

Regards,
Werner

Hi,

one more question and hope the last one :slight_smile: Cause I'm little confused
about the options - there are two configurations for the sip account -
enable support to encrypt calls and indicate support of zrtp in sip
data.
So there are three possible situations :
1. Everything is off

This is "no ZRTP support at all". In the old code the ZRTP engine is
used as the connector but is not initialized to start ZRTP

2. "Enable support to encrypt calls" is TURNED ON

ZRTP support is enabled, this is the usual cause. The check is done with:
聽聽if (this.getCall().isDefaultEncrypted())

in the old code in method initializeRtpManager(...) .

3. "Enable support to encrypt calls" and "indicate support of zrtp in
sip data" are both TURNED ON.

This option controls if the SDP data shall contain the zrtp-hash. We had
reports that some border gateways discard SIP packets if they contain unknown
SDP parameters. In this case the user may switch off this indication.

What must happen in all the situation, I suppose 1 is like we don't
support zrtp at all. And the others ?

Thanks once again for answering my questions :slight_smile:
damencho

P.S. about my previous question about zrtp-hash, I was wondering as it
seems its a constant string (1.10) and is not dependent to some zrtp
engine instance, why this string is not a static field in the library
or again I'm missing something about zrtp-hash. Thanks.

If ZRTP was not initialized it returns just 1.10, right. The code in
the old implementation (CallSessionImpl) is a bit weak here. The code
does not check the variable "usingZRTP".

This is the current code:
if (engine instanceof ZRTPTransformEngine && call.isSipZrtpAttribute())
{
聽聽聽聽ZRTPTransformEngine ze = (ZRTPTransformEngine) engine;
聽聽聽聽String helloHash = ze.getHelloHash();
聽聽聽聽if( helloHash != null && helloHash.length() > 0)
聽聽聽聽聽聽聽am.setAttribute("zrtp-hash", helloHash);
聽聽}

The first line of the code shall read:
聽聽if (engine instanceof ZRTPTransformEngine && usingZRTP && call.isSipZrtpAttribute())

This is at two places: audio and video part of the SDP.

Hi again,

I have one more question regarding zrtp-hash I remember back in
January when we were preparing for the FOSDEM demo that the zrtp-hash
was something like bas64 string, but now I see it that is just
something like 1.10. Is this normal or what actually this string must
represent ?

Thanks
damencho

<SNIP --- SNAP>

路路路

Am 08.12.2009 18:28, schrieb Damian Minkov:

On Tue, Dec 8, 2009 at 3:09 PM, Damian Minkov > <damencho@sip-communicator.org> wrote:

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hi,

I think I got it all.
But about the zrtp-hash I think there is something wrong and in the
media service.
I'm testing with revision 6236 which is the latest one in which the
sip protocol is using the media service. I use this revision on both
my test machines and I make a p2p call and in the wireshark dump I can
see that in the sdp from both sides I get : "a=zrtp-hash:1.10 ". Can
it be a problem in the lib ?

Thanks
damencho

路路路

On Tue, Dec 8, 2009 at 10:05 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Damian,

see inline pls

Regards,
Werner

Am 08.12.2009 18:28, schrieb Damian Minkov:

Hi,

one more question and hope the last one :slight_smile: Cause I'm little confused
about the options - there are two configurations for the sip account -
enable support to encrypt calls and indicate support of zrtp in sip
data.
So there are three possible situations :
1. Everything is off

This is "no ZRTP support at all". In the old code the ZRTP engine is
used as the connector but is not initialized to start ZRTP

2. "Enable support to encrypt calls" is TURNED ON

ZRTP support is enabled, this is the usual cause. The check is done with:
if (this.getCall().isDefaultEncrypted())

in the old code in method initializeRtpManager(...) .

3. "Enable support to encrypt calls" and "indicate support of zrtp in
sip data" are both TURNED ON.

This option controls if the SDP data shall contain the zrtp-hash. We had
reports that some border gateways discard SIP packets if they contain unknown
SDP parameters. In this case the user may switch off this indication.

What must happen in all the situation, I suppose 1 is like we don't
support zrtp at all. And the others ?

Thanks once again for answering my questions :slight_smile:
damencho

P.S. about my previous question about zrtp-hash, I was wondering as it
seems its a constant string (1.10) and is not dependent to some zrtp
engine instance, why this string is not a static field in the library
or again I'm missing something about zrtp-hash. Thanks.

If ZRTP was not initialized it returns just 1.10, right. The code in
the old implementation (CallSessionImpl) is a bit weak here. The code
does not check the variable "usingZRTP".

This is the current code:
if (engine instanceof ZRTPTransformEngine && call.isSipZrtpAttribute())
{
ZRTPTransformEngine ze = (ZRTPTransformEngine) engine;
String helloHash = ze.getHelloHash();
if( helloHash != null && helloHash.length() > 0)
am.setAttribute("zrtp-hash", helloHash);
}

The first line of the code shall read:
if (engine instanceof ZRTPTransformEngine && usingZRTP && call.isSipZrtpAttribute())

This is at two places: audio and video part of the SDP.

On Tue, Dec 8, 2009 at 3:09 PM, Damian Minkov >> <damencho@sip-communicator.org> wrote:

Hi again,

I have one more question regarding zrtp-hash I remember back in
January when we were preparing for the FOSDEM demo that the zrtp-hash
was something like bas64 string, but now I see it that is just
something like 1.10. Is this normal or what actually this string must
represent ?

Thanks
damencho

<SNIP --- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Damian,

just check ind a new zrtp4j jat file that fixes the problem
with hello hash. The problem was introduce because ZRTP now supports
several hash algorithms and the hello hash was using the wrong
one :slight_smile:

Regards,
Werner

路路路

Am 08.12.2009 21:41, schrieb Damian Minkov:

Hi,

I think I got it all.
But about the zrtp-hash I think there is something wrong and in the
media service.
I'm testing with revision 6236 which is the latest one in which the
sip protocol is using the media service. I use this revision on both
my test machines and I make a p2p call and in the wireshark dump I can
see that in the sdp from both sides I get : "a=zrtp-hash:1.10 ". Can
it be a problem in the lib ?

Thanks
damencho

On Tue, Dec 8, 2009 at 10:05 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Damian,

see inline pls

Regards,
Werner

Am 08.12.2009 18:28, schrieb Damian Minkov:

Hi,

one more question and hope the last one :slight_smile: Cause I'm little confused
about the options - there are two configurations for the sip account -
enable support to encrypt calls and indicate support of zrtp in sip
data.
So there are three possible situations :
1. Everything is off

This is "no ZRTP support at all". In the old code the ZRTP engine is
used as the connector but is not initialized to start ZRTP

2. "Enable support to encrypt calls" is TURNED ON

ZRTP support is enabled, this is the usual cause. The check is done with:
if (this.getCall().isDefaultEncrypted())

in the old code in method initializeRtpManager(...) .

3. "Enable support to encrypt calls" and "indicate support of zrtp in
sip data" are both TURNED ON.

This option controls if the SDP data shall contain the zrtp-hash. We had
reports that some border gateways discard SIP packets if they contain unknown
SDP parameters. In this case the user may switch off this indication.

What must happen in all the situation, I suppose 1 is like we don't
support zrtp at all. And the others ?

Thanks once again for answering my questions :slight_smile:
damencho

P.S. about my previous question about zrtp-hash, I was wondering as it
seems its a constant string (1.10) and is not dependent to some zrtp
engine instance, why this string is not a static field in the library
or again I'm missing something about zrtp-hash. Thanks.

If ZRTP was not initialized it returns just 1.10, right. The code in
the old implementation (CallSessionImpl) is a bit weak here. The code
does not check the variable "usingZRTP".

This is the current code:
if (engine instanceof ZRTPTransformEngine && call.isSipZrtpAttribute())
{
聽聽聽ZRTPTransformEngine ze = (ZRTPTransformEngine) engine;
聽聽聽String helloHash = ze.getHelloHash();
聽聽聽if( helloHash != null && helloHash.length() > 0)
聽聽聽聽聽聽am.setAttribute("zrtp-hash", helloHash);
}

The first line of the code shall read:
if (engine instanceof ZRTPTransformEngine && usingZRTP && call.isSipZrtpAttribute())

This is at two places: audio and video part of the SDP.

On Tue, Dec 8, 2009 at 3:09 PM, Damian Minkov >>> <damencho@sip-communicator.org> wrote:

Hi again,

I have one more question regarding zrtp-hash I remember back in
January when we were preparing for the FOSDEM demo that the zrtp-hash
was something like bas64 string, but now I see it that is just
something like 1.10. Is this normal or what actually this string must
represent ?

Thanks
damencho

<SNIP --- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

All:

As my updating the last version, I found a problem which prevented me from
using the client. I have only one sip account, but it keeping adding more
accounts as showing in the following picture:

Has anyone fixed this?

Thanks.

Jiannan

-----閭欢鍘熶欢-----

路路路

鍙戜欢浜: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
鍙戦佹椂闂: Thursday, December 10, 2009 1:51 AM
鏀朵欢浜: dev@sip-communicator.dev.java.net
涓婚: Re: [sip-comm-dev] Configuration form for ZRTP

Damian,

just check ind a new zrtp4j jat file that fixes the problem

with hello hash. The problem was introduce because ZRTP now supports

several hash algorithms and the hello hash was using the wrong

one :slight_smile:

Regards,

Werner

Am 08.12.2009 21:41, schrieb Damian Minkov:

Hi,

I think I got it all.

But about the zrtp-hash I think there is something wrong and in the

media service.

I'm testing with revision 6236 which is the latest one in which the

sip protocol is using the media service. I use this revision on both

my test machines and I make a p2p call and in the wireshark dump I can

see that in the sdp from both sides I get : "a=zrtp-hash:1.10 ". Can

it be a problem in the lib ?

Thanks

damencho

On Tue, Dec 8, 2009 at 10:05 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Damian,

see inline pls

Regards,

Werner

Am 08.12.2009 18:28, schrieb Damian Minkov:

Hi,

one more question and hope the last one :slight_smile: Cause I'm little confused

about the options - there are two configurations for the sip account -

enable support to encrypt calls and indicate support of zrtp in sip

data.

So there are three possible situations :

1. Everything is off

This is "no ZRTP support at all". In the old code the ZRTP engine is

used as the connector but is not initialized to start ZRTP

2. "Enable support to encrypt calls" is TURNED ON

ZRTP support is enabled, this is the usual cause. The check is done with:

if (this.getCall().isDefaultEncrypted())

in the old code in method initializeRtpManager(...) .

3. "Enable support to encrypt calls" and "indicate support of zrtp in

sip data" are both TURNED ON.

This option controls if the SDP data shall contain the zrtp-hash. We had

reports that some border gateways discard SIP packets if they contain

unknown

SDP parameters. In this case the user may switch off this indication.

What must happen in all the situation, I suppose 1 is like we don't

support zrtp at all. And the others ?

Thanks once again for answering my questions :slight_smile:

damencho

P.S. about my previous question about zrtp-hash, I was wondering as it

seems its a constant string (1.10) and is not dependent to some zrtp

engine instance, why this string is not a static field in the library

or again I'm missing something about zrtp-hash. Thanks.

If ZRTP was not initialized it returns just 1.10, right. The code in

the old implementation (CallSessionImpl) is a bit weak here. The code

does not check the variable "usingZRTP".

This is the current code:

if (engine instanceof ZRTPTransformEngine && call.isSipZrtpAttribute())

{

聽聽聽ZRTPTransformEngine ze = (ZRTPTransformEngine) engine;

聽聽聽String helloHash = ze.getHelloHash();

聽聽聽if( helloHash != null && helloHash.length() > 0)

聽聽聽聽聽聽am.setAttribute("zrtp-hash", helloHash);

}

The first line of the code shall read:

if (engine instanceof ZRTPTransformEngine && usingZRTP &&

call.isSipZrtpAttribute())

This is at two places: audio and video part of the SDP.

On Tue, Dec 8, 2009 at 3:09 PM, Damian Minkov >>> <damencho@sip-communicator.org> wrote:

Hi again,

I have one more question regarding zrtp-hash I remember back in

January when we were preparing for the FOSDEM demo that the zrtp-hash

was something like bas64 string, but now I see it that is just

something like 1.10. Is this normal or what actually this string must

represent ?

Thanks

damencho

<SNIP --- SNAP>

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

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net

For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net

For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

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

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net

For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Thanks, I've just implemented it in neomedia and committed it.
damencho

路路路

On Wed, Dec 9, 2009 at 7:51 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Damian,

just check ind a new zrtp4j jat file that fixes the problem
with hello hash. The problem was introduce because ZRTP now supports
several hash algorithms and the hello hash was using the wrong
one :slight_smile:

Regards,
Werner

Am 08.12.2009 21:41, schrieb Damian Minkov:

Hi,

I think I got it all.
But about the zrtp-hash I think there is something wrong and in the
media service.
I'm testing with revision 6236 which is the latest one in which the
sip protocol is using the media service. I use this revision on both
my test machines and I make a p2p call and in the wireshark dump I can
see that in the sdp from both sides I get : "a=zrtp-hash:1.10 ". Can
it be a problem in the lib ?

Thanks
damencho

On Tue, Dec 8, 2009 at 10:05 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Damian,

see inline pls

Regards,
Werner

Am 08.12.2009 18:28, schrieb Damian Minkov:

Hi,

one more question and hope the last one :slight_smile: Cause I'm little confused
about the options - there are two configurations for the sip account -
enable support to encrypt calls and indicate support of zrtp in sip
data.
So there are three possible situations :
1. Everything is off

This is "no ZRTP support at all". In the old code the ZRTP engine is
used as the connector but is not initialized to start ZRTP

2. "Enable support to encrypt calls" is TURNED ON

ZRTP support is enabled, this is the usual cause. The check is done with:
if (this.getCall().isDefaultEncrypted())

in the old code in method initializeRtpManager(...) .

3. "Enable support to encrypt calls" and "indicate support of zrtp in
sip data" are both TURNED ON.

This option controls if the SDP data shall contain the zrtp-hash. We had
reports that some border gateways discard SIP packets if they contain unknown
SDP parameters. In this case the user may switch off this indication.

What must happen in all the situation, I suppose 1 is like we don't
support zrtp at all. And the others ?

Thanks once again for answering my questions :slight_smile:
damencho

P.S. about my previous question about zrtp-hash, I was wondering as it
seems its a constant string (1.10) and is not dependent to some zrtp
engine instance, why this string is not a static field in the library
or again I'm missing something about zrtp-hash. Thanks.

If ZRTP was not initialized it returns just 1.10, right. The code in
the old implementation (CallSessionImpl) is a bit weak here. The code
does not check the variable "usingZRTP".

This is the current code:
if (engine instanceof ZRTPTransformEngine && call.isSipZrtpAttribute())
{
ZRTPTransformEngine ze = (ZRTPTransformEngine) engine;
String helloHash = ze.getHelloHash();
if( helloHash != null && helloHash.length() > 0)
am.setAttribute("zrtp-hash", helloHash);
}

The first line of the code shall read:
if (engine instanceof ZRTPTransformEngine && usingZRTP && call.isSipZrtpAttribute())

This is at two places: audio and video part of the SDP.

On Tue, Dec 8, 2009 at 3:09 PM, Damian Minkov >>>> <damencho@sip-communicator.org> wrote:

Hi again,

I have one more question regarding zrtp-hash I remember back in
January when we were preparing for the FOSDEM demo that the zrtp-hash
was something like bas64 string, but now I see it that is just
something like 1.10. Is this normal or what actually this string must
represent ?

Thanks
damencho

<SNIP --- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Damian,

thanks for commiting the stuff. Testing with Zfone and others
follows this weekend.

Damian, Emil, regading the zrtpconfigure plugin. What would be the
best place to put the classes? The registration woul go into
the neomedia activatore class, thus the zrtpconfigure activator
is not needed anymore. Would it make sense to put the remaining
classes (the configure panel, the table model, and the utils)
into the neomedia package alongside the ZrtpControlImpl? IMHO
this would make sense because ZrtpControlImpl would reference
the zrtpconfigure classes when enabling the ZRTP configuration
functions.

Regards,
Werner

路路路

Am 10.12.2009 12:20, schrieb Damian Minkov:

Thanks, I've just implemented it in neomedia and committed it.
damencho

On Wed, Dec 9, 2009 at 7:51 PM, Werner Dittmann > <Werner.Dittmann@t-online.de> wrote:

Damian,

just check ind a new zrtp4j jat file that fixes the problem
with hello hash. The problem was introduce because ZRTP now supports
several hash algorithms and the hello hash was using the wrong
one :slight_smile:

Regards,
Werner

Am 08.12.2009 21:41, schrieb Damian Minkov:

Hi,

<SNIP -- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#13

Hey Werner,

Damian, Emil, regading the zrtpconfigure plugin. What would be the
best place to put the classes? The registration woul go into
the neomedia activatore class, thus the zrtpconfigure activator
is not needed anymore. Would it make sense to put the remaining
classes (the configure panel, the table model, and the utils)
into the neomedia package alongside the ZrtpControlImpl? IMHO
this would make sense because ZrtpControlImpl would reference
the zrtpconfigure classes when enabling the ZRTP configuration
functions.

Our media configuration form also lives there so yes I guess it would
make sense. For the longer term, we have gathered a sufficient number
of configuration GUI components to move them to a package of their
own.

We could do this later though. For the time being, I'd prefer to have
a somewhat stable version of neomedia so that we could resume the
builds (and possibly prepare a 1.1 release). We'll think about
refactoring after that. So again, moving them to impl.neomedia is
fine.

Cheers,
Emil

路路路

On Thu, Dec 10, 2009 at 6:30 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Regards,
Werner

Am 10.12.2009 12:20, schrieb Damian Minkov:

Thanks, I've just implemented it in neomedia and committed it.
damencho

On Wed, Dec 9, 2009 at 7:51 PM, Werner Dittmann >> <Werner.Dittmann@t-online.de> wrote:

Damian,

just check ind a new zrtp4j jat file that fixes the problem
with hello hash. The problem was introduce because ZRTP now supports
several hash algorithms and the hello hash was using the wrong
one :slight_smile:

Regards,
Werner

Am 08.12.2009 21:41, schrieb Damian Minkov:

Hi,

<SNIP -- SNAP>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31