[sip-comm-dev] Not existing package imports in some manifest files


#1

Dear all,

some months ago (in April) we did some cleanup to replace the
own configuration event implementation with the standard JDK
configuration event stuff. While doing some other stuff with
SC I noticed that quite some minifest file contain an import
statement for the package:

net.java.sip.communicator.service.configuration.event

This package does not exist anymore. Shall we remove this import
statement, just to avoid confuison :slight_smile: and have clean manifests?
I would volunteer for this task :wink: .

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

Hey Werner

路路路

On Sun, Oct 17, 2010 at 2:19 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Dear all,

some months ago (in April) we did some cleanup to replace the
own configuration event implementation with the standard JDK
configuration event stuff. While doing some other stuff with
SC I noticed that quite some minifest file contain an import
statement for the package:

net.java.sip.communicator.service.configuration.event

This package does not exist anymore. Shall we remove this import
statement, just to avoid confuison :slight_smile: and have clean manifests?
I would volunteer for this task :wink: .

Sure, go ahead!

Thanks,
Emil


#3

Dear All, but especially Werner D.,

we're doing some interoperability experiments between SIP Communicator
and another ZRTP implementation. From Wireshark, we found out that SIP
communicator
transmits RTP packets with audio data even during the ZRTP handshake itself.

Now the ZRTP specs say:

聽聽聽In all key agreement modes, the initiator SHOULD NOT send RTP media
聽聽聽after sending the Commit message, and MUST NOT send SRTP media before
聽聽聽receiving either the Conf2ACK or the first SRTP media (with a valid
聽聽聽SRTP auth tag) from the responder. The responder SHOULD NOT send RTP
聽聽聽media after receiving the Commit message, and MUST NOT send SRTP
聽聽聽media before receiving the Confirm2 message.

So while there is no strong prohibition on sending normal RTP traffic
while doing a ZRTP handshake, it should not be done either. Quite some
data can leak during those
several seconds.

Is there any good reason why RTP is sent during ZRTP handshake?

Yours respectfully,

Marian Kechlibar

路路路

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


#4

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

路路路

---------------------------------------------------------------------
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 Marian,

the explanation is simple:
- currently I didn't implement this "SHOULD" requirement because,
聽聽from an end-user perspective it may be disturbing if an ongoing
聽聽audio suddenly stops and then restarts.

In addition ZRTP was designed to support a "switch on" secure mode
during an ongoing audio session, thus you may talk insecure first and
then switch on ZRTP/secure mode. In this case implementation of this
"SHOULD" requirement does not make sense, doesn't it ? :slight_smile: . This
would of course require an additional GUI element to provide an
end-user with the switch-on/switch-off functions

In SC as well as in Twinkle we decided not to provide this function
and to start ZRTP (the detection phase) right after the first RTP
packets were exchanged and automatically engage ZRTP. This is more
convenient for an end-user, in particluar if the end-user is not a
computer expert - make it simple to use without much hassle. After
ZRTP is done we play a "secure" sound to signal
"now it is save to talk" and display the padlock sign. Thus the
overall behaviour is similar to a normal browser behaviour.

Best regards,
Werner

BTW, can you give some info about your ZRTP implementation?

Werner

路路路

Am 25.10.2010 13:07, schrieb Marian Kechlibar:

Dear All, but especially Werner D.,

we're doing some interoperability experiments between SIP Communicator
and another ZRTP implementation. From Wireshark, we found out that SIP
communicator
transmits RTP packets with audio data even during the ZRTP handshake itself.

Now the ZRTP specs say:

聽聽聽In all key agreement modes, the initiator SHOULD NOT send RTP media
聽聽聽after sending the Commit message, and MUST NOT send SRTP media before
聽聽聽receiving either the Conf2ACK or the first SRTP media (with a valid
聽聽聽SRTP auth tag) from the responder. The responder SHOULD NOT send RTP
聽聽聽media after receiving the Commit message, and MUST NOT send SRTP
聽聽聽media before receiving the Confirm2 message.

So while there is no strong prohibition on sending normal RTP traffic
while doing a ZRTP handshake, it should not be done either. Quite some
data can leak during those
several seconds.

Is there any good reason why RTP is sent during ZRTP handshake?

Yours respectfully,

Marian Kechlibar

---------------------------------------------------------------------
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

Hey Marian,

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

路路路

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar <marian.kechlibar@circletech.net> wrote:

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

---------------------------------------------------------------------
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


#7

Hi Werner,

I am asking because I just found out that the continual transmission of
RTP packets seems to play havoc with the ZRTP handshake on my devices.

My implementation is in C++ for Symbian OS phones. Now, the devices are
rather constrained when it comes to thread switching, memory and
processor power. The ZRTP handshake needs pretty much the entire
processor power, as it is mathematically heavy. And if 50 RTP packets
with plaintext arrive every second, they consume too much of the
scarce resources (even if the appropriate code just throws them away),
which more often than not results in resource starvation of the ZRTP
process and it usually dies around the Confirm phase. To be exact, ZRTP
runs on but the component which is responsible for sending of the ZRTP
messages out of the device is starved to death.

The main reason for this behavior is that multithreading in Symbian is
pretty lame, inherited from the old OS design from around 1993, and the
appropriate component, CActiveScheduler, is only happy to starve
subordinate objects to death if it decides that it has too many things
to do at once.

We were able to alleviate the problem temporarily by hacking into the
SIP Communicator code and turning the RTP traffic
off while the handshake runs. I am thinking whether such an expert
setting should make its way to the official release (turned off
by default, but turnable-on).

Note that the performance would be better if multiple speex frames were
sent in a single RTP packet; this would drop the amount of traffic from
50 down to 25 or 17 or 13 per second; but this, again, cannot be set in
SIP Communicator's settings.

Best regards

Marian Kechlibar

Werner Dittmann wrote:

路路路

Hi Marian,

the explanation is simple:
- currently I didn't implement this "SHOULD" requirement because,
聽聽from an end-user perspective it may be disturbing if an ongoing
聽聽audio suddenly stops and then restarts.

In addition ZRTP was designed to support a "switch on" secure mode
during an ongoing audio session, thus you may talk insecure first and
then switch on ZRTP/secure mode. In this case implementation of this
"SHOULD" requirement does not make sense, doesn't it ? :slight_smile: . This
would of course require an additional GUI element to provide an
end-user with the switch-on/switch-off functions

In SC as well as in Twinkle we decided not to provide this function
and to start ZRTP (the detection phase) right after the first RTP
packets were exchanged and automatically engage ZRTP. This is more
convenient for an end-user, in particluar if the end-user is not a
computer expert - make it simple to use without much hassle. After
ZRTP is done we play a "secure" sound to signal
"now it is save to talk" and display the padlock sign. Thus the
overall behaviour is similar to a normal browser behaviour.

Best regards,
Werner

BTW, can you give some info about your ZRTP implementation?

Werner

Am 25.10.2010 13:07, schrieb Marian Kechlibar:
聽聽

Dear All, but especially Werner D.,

we're doing some interoperability experiments between SIP Communicator
and another ZRTP implementation. From Wireshark, we found out that SIP
communicator
transmits RTP packets with audio data even during the ZRTP handshake itself.

Now the ZRTP specs say:

聽聽聽In all key agreement modes, the initiator SHOULD NOT send RTP media
聽聽聽after sending the Commit message, and MUST NOT send SRTP media before
聽聽聽receiving either the Conf2ACK or the first SRTP media (with a valid
聽聽聽SRTP auth tag) from the responder. The responder SHOULD NOT send RTP
聽聽聽media after receiving the Commit message, and MUST NOT send SRTP
聽聽聽media before receiving the Confirm2 message.

So while there is no strong prohibition on sending normal RTP traffic
while doing a ZRTP handshake, it should not be done either. Quite some
data can leak during those
several seconds.

Is there any good reason why RTP is sent during ZRTP handshake?

Yours respectfully,

Marian Kechlibar

---------------------------------------------------------------------
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


#8

Hello,

well, I do not know where to look for the initial value ... any
recommendation? (name of source file)
I would patch it otherwise.

Best regards

Marian

Dne 25.10.2010 16:05, Emil Ivov napsal(a):

路路路

Hey Marian,

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar > <marian.kechlibar@circletech.net> wrote:

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

---------------------------------------------------------------------
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

Hi Marian,

thanks for the quick answer and your detailed explanations. IMHO
we can implement such an expert switch on SC, maybe we can work
together to do it, no problem from my side here. Can you provide me
with info about your hack? I can use it and integrate it into the
main ZRTP code and try to implement a specific filed in the expert
page.

On the other hand: at wich part or which step consumes the most
CPU resources? IMHO this could only be the generation of the DH values.
Maybe (as a later optimization and if symbian provides the mechanisms)
you may implement a small thread the runs on low priority and generates
some DH value pair in the background so they are ready during ZRTP.

Best regards,
Werner

路路路

Am 25.10.2010 19:42, schrieb Marian Kechlibar:

Hi Werner,

I am asking because I just found out that the continual transmission of
RTP packets seems to play havoc with the ZRTP handshake on my devices.

My implementation is in C++ for Symbian OS phones. Now, the devices are
rather constrained when it comes to thread switching, memory and
processor power. The ZRTP handshake needs pretty much the entire
processor power, as it is mathematically heavy. And if 50 RTP packets
with plaintext arrive every second, they consume too much of the
scarce resources (even if the appropriate code just throws them away),
which more often than not results in resource starvation of the ZRTP
process and it usually dies around the Confirm phase. To be exact, ZRTP
runs on but the component which is responsible for sending of the ZRTP
messages out of the device is starved to death.

The main reason for this behavior is that multithreading in Symbian is
pretty lame, inherited from the old OS design from around 1993, and the
appropriate component, CActiveScheduler, is only happy to starve
subordinate objects to death if it decides that it has too many things
to do at once.

We were able to alleviate the problem temporarily by hacking into the
SIP Communicator code and turning the RTP traffic
off while the handshake runs. I am thinking whether such an expert
setting should make its way to the official release (turned off
by default, but turnable-on).

Note that the performance would be better if multiple speex frames were
sent in a single RTP packet; this would drop the amount of traffic from
50 down to 25 or 17 or 13 per second; but this, again, cannot be set in
SIP Communicator's settings.

Best regards

Marian Kechlibar

Werner Dittmann wrote:

Hi Marian,

the explanation is simple:
- currently I didn't implement this "SHOULD" requirement because,
聽聽from an end-user perspective it may be disturbing if an ongoing
聽聽audio suddenly stops and then restarts.

In addition ZRTP was designed to support a "switch on" secure mode
during an ongoing audio session, thus you may talk insecure first and
then switch on ZRTP/secure mode. In this case implementation of this
"SHOULD" requirement does not make sense, doesn't it ? :slight_smile: . This
would of course require an additional GUI element to provide an
end-user with the switch-on/switch-off functions

In SC as well as in Twinkle we decided not to provide this function
and to start ZRTP (the detection phase) right after the first RTP
packets were exchanged and automatically engage ZRTP. This is more
convenient for an end-user, in particluar if the end-user is not a
computer expert - make it simple to use without much hassle. After
ZRTP is done we play a "secure" sound to signal
"now it is save to talk" and display the padlock sign. Thus the
overall behaviour is similar to a normal browser behaviour.

Best regards,
Werner

BTW, can you give some info about your ZRTP implementation?

Werner

Am 25.10.2010 13:07, schrieb Marian Kechlibar:
聽聽

Dear All, but especially Werner D.,

we're doing some interoperability experiments between SIP Communicator
and another ZRTP implementation. From Wireshark, we found out that SIP
communicator
transmits RTP packets with audio data even during the ZRTP handshake itself.

Now the ZRTP specs say:

聽聽聽In all key agreement modes, the initiator SHOULD NOT send RTP media
聽聽聽after sending the Commit message, and MUST NOT send SRTP media before
聽聽聽receiving either the Conf2ACK or the first SRTP media (with a valid
聽聽聽SRTP auth tag) from the responder. The responder SHOULD NOT send RTP
聽聽聽media after receiving the Commit message, and MUST NOT send SRTP
聽聽聽media before receiving the Confirm2 message.

So while there is no strong prohibition on sending normal RTP traffic
while doing a ZRTP handshake, it should not be done either. Quite some
data can leak during those
several seconds.

Is there any good reason why RTP is sent during ZRTP handshake?

Yours respectfully,

Marian Kechlibar

---------------------------------------------------------------------
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


#10

Hello Emil,

I just did open the issue, as I am leaving for a few days and it could
easily be forgotten.
The problem is not fatal, but annoying, yes.

Best regards

Marian

Dne 25.10.2010 16:05, Emil Ivov napsal(a):

路路路

Hey Marian,

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar > <marian.kechlibar@circletech.net> wrote:

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

---------------------------------------------------------------------
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

Hi Werner,

the current hack is crude and ugly, but I believe that tomorrow we will
have something
more elegant.

The part that takes most of the time is, of course, the Diffie-Hellman
power computation.
But the problem seems to really kick in with the multiple arriving
packets. Standalone
DH is survivable, DH + 50 incoming packets is not, even though the time
of processing
per every incoming packet is around 1 ms. The price of the context
switching is probably
too high.

I was already thinking about creation of a separate thread for all the
big integer operations,
but I am not sure whether it is going to help. The synchronization work
in Symbian is pretty
ugly. It could easily happen that the thread would stay in background
too long and only
return the computed value long after the ZRTP transmission timed out
(and after the user
lost his patience).

Best regards

Marian

Werner Dittmann wrote:

路路路

Hi Marian,

thanks for the quick answer and your detailed explanations. IMHO
we can implement such an expert switch on SC, maybe we can work
together to do it, no problem from my side here. Can you provide me
with info about your hack? I can use it and integrate it into the
main ZRTP code and try to implement a specific filed in the expert
page.

On the other hand: at wich part or which step consumes the most
CPU resources? IMHO this could only be the generation of the DH values.
Maybe (as a later optimization and if symbian provides the mechanisms)
you may implement a small thread the runs on low priority and generates
some DH value pair in the background so they are ready during ZRTP.

Best regards,
Werner

Am 25.10.2010 19:42, schrieb Marian Kechlibar:
聽聽

Hi Werner,

I am asking because I just found out that the continual transmission of
RTP packets seems to play havoc with the ZRTP handshake on my devices.

My implementation is in C++ for Symbian OS phones. Now, the devices are
rather constrained when it comes to thread switching, memory and
processor power. The ZRTP handshake needs pretty much the entire
processor power, as it is mathematically heavy. And if 50 RTP packets
with plaintext arrive every second, they consume too much of the
scarce resources (even if the appropriate code just throws them away),
which more often than not results in resource starvation of the ZRTP
process and it usually dies around the Confirm phase. To be exact, ZRTP
runs on but the component which is responsible for sending of the ZRTP
messages out of the device is starved to death.

The main reason for this behavior is that multithreading in Symbian is
pretty lame, inherited from the old OS design from around 1993, and the
appropriate component, CActiveScheduler, is only happy to starve
subordinate objects to death if it decides that it has too many things
to do at once.

We were able to alleviate the problem temporarily by hacking into the
SIP Communicator code and turning the RTP traffic
off while the handshake runs. I am thinking whether such an expert
setting should make its way to the official release (turned off
by default, but turnable-on).

Note that the performance would be better if multiple speex frames were
sent in a single RTP packet; this would drop the amount of traffic from
50 down to 25 or 17 or 13 per second; but this, again, cannot be set in
SIP Communicator's settings.

Best regards

Marian Kechlibar

Werner Dittmann wrote:
聽聽聽聽

Hi Marian,

the explanation is simple:
- currently I didn't implement this "SHOULD" requirement because,
聽聽from an end-user perspective it may be disturbing if an ongoing
聽聽audio suddenly stops and then restarts.

In addition ZRTP was designed to support a "switch on" secure mode
during an ongoing audio session, thus you may talk insecure first and
then switch on ZRTP/secure mode. In this case implementation of this
"SHOULD" requirement does not make sense, doesn't it ? :slight_smile: . This
would of course require an additional GUI element to provide an
end-user with the switch-on/switch-off functions

In SC as well as in Twinkle we decided not to provide this function
and to start ZRTP (the detection phase) right after the first RTP
packets were exchanged and automatically engage ZRTP. This is more
convenient for an end-user, in particluar if the end-user is not a
computer expert - make it simple to use without much hassle. After
ZRTP is done we play a "secure" sound to signal
"now it is save to talk" and display the padlock sign. Thus the
overall behaviour is similar to a normal browser behaviour.

Best regards,
Werner

BTW, can you give some info about your ZRTP implementation?

Werner

Am 25.10.2010 13:07, schrieb Marian Kechlibar:
聽聽

Dear All, but especially Werner D.,

we're doing some interoperability experiments between SIP Communicator
and another ZRTP implementation. From Wireshark, we found out that SIP
communicator
transmits RTP packets with audio data even during the ZRTP handshake itself.

Now the ZRTP specs say:

聽聽聽In all key agreement modes, the initiator SHOULD NOT send RTP media
聽聽聽after sending the Commit message, and MUST NOT send SRTP media before
聽聽聽receiving either the Conf2ACK or the first SRTP media (with a valid
聽聽聽SRTP auth tag) from the responder. The responder SHOULD NOT send RTP
聽聽聽media after receiving the Commit message, and MUST NOT send SRTP
聽聽聽media before receiving the Confirm2 message.

So while there is no strong prohibition on sending normal RTP traffic
while doing a ZRTP handshake, it should not be done either. Quite some
data can leak during those
several seconds.

Is there any good reason why RTP is sent during ZRTP handshake?

Yours respectfully,

Marian Kechlibar

---------------------------------------------------------------------
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


#12

Hey folks,

Hi Marian,

thanks for the quick answer and your detailed explanations. IMHO
we can implement such an expert switch on SC, maybe we can work
together to do it, no problem from my side here. Can you provide me
with info about your hack? I can use it and integrate it into the
main ZRTP code and try to implement a specific filed in the expert
page.

On the other hand: at wich part or which step consumes the most
CPU resources? IMHO this could only be the generation of the DH values.
Maybe (as a later optimization and if symbian provides the mechanisms)
you may implement a small thread the runs on low priority and generates
some DH value pair in the background so they are ready during ZRTP.

Is this really the best way to go? I am not really sure I understand
exactly who such a property benefit. Do we really expect users to to
turn it on even if it existed? On the other hand knowing that it would
only be used by certain developers is probably not enough to justify
the increased complexity in the SRTP code (that people are already
finding hard to grasp).

Marian, what about other clients that do this, aren't you still going
to have the problem with them? The same goes for SC instances running
with default settings. Wouldn't it make more sense to drop RTP packets
and somehow avoid the context switching instead?

Emil

路路路

On Mon, Oct 25, 2010 at 7:59 PM, Werner Dittmann <Werner.Dittmann@t-online.de> wrote:

Best regards,
Werner

Am 25.10.2010 19:42, schrieb Marian Kechlibar:

Hi Werner,

I am asking because I just found out that the continual transmission of
RTP packets seems to play havoc with the ZRTP handshake on my devices.

My implementation is in C++ for Symbian OS phones. Now, the devices are
rather constrained when it comes to thread switching, memory and
processor power. The ZRTP handshake needs pretty much the entire
processor power, as it is mathematically heavy. And if 50 RTP packets
with plaintext arrive every second, they consume too much of the
scarce resources (even if the appropriate code just throws them away),
which more often than not results in resource starvation of the ZRTP
process and it usually dies around the Confirm phase. To be exact, ZRTP
runs on but the component which is responsible for sending of the ZRTP
messages out of the device is starved to death.

The main reason for this behavior is that multithreading in Symbian is
pretty lame, inherited from the old OS design from around 1993, and the
appropriate component, CActiveScheduler, is only happy to starve
subordinate objects to death if it decides that it has too many things
to do at once.

We were able to alleviate the problem temporarily by hacking into the
SIP Communicator code and turning the RTP traffic
off while the handshake runs. I am thinking whether such an expert
setting should make its way to the official release (turned off
by default, but turnable-on).

Note that the performance would be better if multiple speex frames were
sent in a single RTP packet; this would drop the amount of traffic from
50 down to 25 or 17 or 13 per second; but this, again, cannot be set in
SIP Communicator's settings.

Best regards

Marian Kechlibar

Werner Dittmann wrote:

Hi Marian,

the explanation is simple:
- currently I didn't implement this "SHOULD" requirement because,
from an end-user perspective it may be disturbing if an ongoing
audio suddenly stops and then restarts.

In addition ZRTP was designed to support a "switch on" secure mode
during an ongoing audio session, thus you may talk insecure first and
then switch on ZRTP/secure mode. In this case implementation of this
"SHOULD" requirement does not make sense, doesn't it ? :slight_smile: . This
would of course require an additional GUI element to provide an
end-user with the switch-on/switch-off functions

In SC as well as in Twinkle we decided not to provide this function
and to start ZRTP (the detection phase) right after the first RTP
packets were exchanged and automatically engage ZRTP. This is more
convenient for an end-user, in particluar if the end-user is not a
computer expert - make it simple to use without much hassle. After
ZRTP is done we play a "secure" sound to signal
"now it is save to talk" and display the padlock sign. Thus the
overall behaviour is similar to a normal browser behaviour.

Best regards,
Werner

BTW, can you give some info about your ZRTP implementation?

Werner

Am 25.10.2010 13:07, schrieb Marian Kechlibar:

Dear All, but especially Werner D.,

we're doing some interoperability experiments between SIP Communicator
and another ZRTP implementation. From Wireshark, we found out that SIP
communicator
transmits RTP packets with audio data even during the ZRTP handshake itself.

Now the ZRTP specs say:

In all key agreement modes, the initiator SHOULD NOT send RTP media
after sending the Commit message, and MUST NOT send SRTP media before
receiving either the Conf2ACK or the first SRTP media (with a valid
SRTP auth tag) from the responder. The responder SHOULD NOT send RTP
media after receiving the Commit message, and MUST NOT send SRTP
media before receiving the Confirm2 message.

So while there is no strong prohibition on sending normal RTP traffic
while doing a ZRTP handshake, it should not be done either. Quite some
data can leak during those
several seconds.

Is there any good reason why RTP is sent during ZRTP handshake?

Yours respectfully,

Marian Kechlibar

---------------------------------------------------------------------
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

--
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


#13

Hey Marian,

袧邪 26.10.10 20:06, Marian Kechlibar 薪邪锌懈褋邪:

Hello Emil,

I just did open the issue, as I am leaving for a few days and it could
easily be forgotten.
The problem is not fatal, but annoying, yes.

Did have a look yesterday but it seems like the issue is coming from the
native speex implementation so it's probably not going to be a 2 minute
fix.

We'll have a look next week (or the one after). Thanks for opening the
issue.

Cheers,
Emil

路路路

Best regards

Marian

Dne 25.10.2010 16:05, Emil Ivov napsal(a):

Hey Marian,

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar >> <marian.kechlibar@circletech.net> wrote:

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

---------------------------------------------------------------------
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

--
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

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


#14

Marian, what about other clients that do this, aren't you still going
to have the problem with them?

Well, from the myriad of SIP clients running around the Internet, we chose
only SIP communicator to be surely compatible with... and this is because
it is multi-platform, has a dedicated team of developers and it also seems
to be easily modifiable if the need arises. I certainly do not intend to
flatter
you idly, but this is how it is. Most other SIP clients either do not
run on multiple
platforms, or are developed by a single overworked man, or aren't open
source
enough... etc.

Wouldn't it make more sense to drop RTP packets
and somehow avoid the context switching instead?
聽聽

As the song goes: ... if I could, if I only could, I surely would!

The trouble is: ZRTP and RTP are multiplexed on the same port. Therefore you
need a single socket to listen to incoming packets for both ZRTP and
RTP. This
socket reports you every incoming UDP packet, and you need to look at
it, even
briefly, to determine whether it is a common RTP packet, or a ZRTP
packet. But
even before that, the socket has already consumed some resources - in
this case,
too much of them.

And you can't turn the socket off for the second of Diffie-Hellman,
because the
underlying system implementation of networking is so deficient that,
more often than
not, you wouldn't be able to start it up in reasonable time again when
needed (say,
for sending of the resulting DHPart or Confirm message).

Best regards

Marian

路路路

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


#15

Hello Emil,

Did have a look yesterday but it seems like the issue is coming from the
native speex implementation so it's probably not going to be a 2 minute
fix.
聽聽

Hmm.... We've had some issue with speex timestamps this year:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=821
It was then fixed fully and the timestamps looked right since revision 7102.
I believe speex hasn't evolved since then, it is still the same 1.1.2
beta release.

Best regards

Marian

路路路

We'll have a look next week (or the one after). Thanks for opening the
issue.

Cheers,
Emil
聽聽

Best regards

Marian

Dne 25.10.2010 16:05, Emil Ivov napsal(a):
聽聽聽聽

Hey Marian,

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar >>> <marian.kechlibar@circletech.net> wrote:
聽聽聽聽聽聽

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.
聽聽聽聽聽聽聽聽

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

---------------------------------------------------------------------
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


#16

Hey Marian,

袧邪 27.10.10 22:45, Marian Kechlibar 薪邪锌懈褋邪:

Hello Emil,

Did have a look yesterday but it seems like the issue is coming from the
native speex implementation so it's probably not going to be a 2 minute
fix.
聽聽

Hmm.... We've had some issue with speex timestamps this year:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=821
It was then fixed fully and the timestamps looked right since revision 7102.
I believe speex hasn't evolved since then, it is still the same 1.1.2
beta release.

Back in r7102 we were still using the jspeex implementation (i.e.
jspeex.jar). We switched to the native lib between r7245 and r7253.

Emil

路路路

Best regards

Marian

We'll have a look next week (or the one after). Thanks for opening the
issue.

Cheers,
Emil
聽聽

Best regards

Marian

Dne 25.10.2010 16:05, Emil Ivov napsal(a):
聽聽聽聽

Hey Marian,

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar >>>> <marian.kechlibar@circletech.net> wrote:
聽聽聽聽聽聽

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.
聽聽聽聽聽聽聽聽

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

---------------------------------------------------------------------
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

--
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

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


#17

Hi Emil, Marian,

my proposal is: let's give it a try and see how it works out.
To stop sending RTP packets is a change in ZRTP code (not SRTP).
Without having a deeper look ZRTP is already prepared to implement
this "stop of RTP packets", we "just" need to activate or deactivate
it somehow. I'll check this with Marian and we can do some tests at
our playground and come back to you once we have some results.

Maybe (if it does not do any harm and the audio distortion is not
too bad) we can leave this option activated to meet the "SHOULD"
requirement. But we will see how it works out. WDYT?

Best regards,
Werner

路路路

Am 25.10.2010 20:36, schrieb Marian Kechlibar:

Marian, what about other clients that do this, aren't you still going
to have the problem with them?

Well, from the myriad of SIP clients running around the Internet, we chose
only SIP communicator to be surely compatible with... and this is because
it is multi-platform, has a dedicated team of developers and it also seems
to be easily modifiable if the need arises. I certainly do not intend to
flatter
you idly, but this is how it is. Most other SIP clients either do not
run on multiple
platforms, or are developed by a single overworked man, or aren't open
source
enough... etc.

Wouldn't it make more sense to drop RTP packets
and somehow avoid the context switching instead?
聽聽

As the song goes: ... if I could, if I only could, I surely would!

The trouble is: ZRTP and RTP are multiplexed on the same port. Therefore you
need a single socket to listen to incoming packets for both ZRTP and
RTP. This
socket reports you every incoming UDP packet, and you need to look at
it, even
briefly, to determine whether it is a common RTP packet, or a ZRTP
packet. But
even before that, the socket has already consumed some resources - in
this case,
too much of them.

And you can't turn the socket off for the second of Diffie-Hellman,
because the
underlying system implementation of networking is so deficient that,
more often than
not, you wouldn't be able to start it up in reasonable time again when
needed (say,
for sending of the resulting DHPart or Confirm message).

Best regards

Marian

---------------------------------------------------------------------
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


#18

Hi Marian,

I commit a fix in revision 7875 to address the RTP problem. Can you try it and tell us if it works for you ?

Regards,

路路路

--
Seb

Le 27/10/2010 23:41, Emil Ivov a 茅crit :

Hey Marian,

袧邪 27.10.10 22:45, Marian Kechlibar 薪邪锌懈褋邪:
聽聽聽

Hello Emil,

Did have a look yesterday but it seems like the issue is coming from the
native speex implementation so it's probably not going to be a 2 minute
fix.

Hmm.... We've had some issue with speex timestamps this year:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=821
It was then fixed fully and the timestamps looked right since revision 7102.
I believe speex hasn't evolved since then, it is still the same 1.1.2
beta release.
聽聽聽聽聽

Back in r7102 we were still using the jspeex implementation (i.e.
jspeex.jar). We switched to the native lib between r7245 and r7253.

Emil

Best regards

Marian
聽聽聽聽聽

We'll have a look next week (or the one after). Thanks for opening the
issue.

Cheers,
Emil

Best regards

Marian

Dne 25.10.2010 16:05, Emil Ivov napsal(a):

Hey Marian,

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar >>>>> <marian.kechlibar@circletech.net> wrote:

Hello,

it seems that outgoing Speex packets have incorrect RTP timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

I can send a Wireshark dump, if necessary. It is rather largish, though.

Best regards

Marian Kechlibar

---------------------------------------------------------------------
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


#19

Hello,

I agree. Let us try tomorrow. I will be ready from about 8.40 central
euro time till, I expect,
at least 19.30.

Best regards

Marian

Werner Dittmann wrote:

路路路

Hi Emil, Marian,

my proposal is: let's give it a try and see how it works out.
To stop sending RTP packets is a change in ZRTP code (not SRTP).
Without having a deeper look ZRTP is already prepared to implement
this "stop of RTP packets", we "just" need to activate or deactivate
it somehow. I'll check this with Marian and we can do some tests at
our playground and come back to you once we have some results.

Maybe (if it does not do any harm and the audio distortion is not
too bad) we can leave this option activated to meet the "SHOULD"
requirement. But we will see how it works out. WDYT?

Best regards,
Werner

Am 25.10.2010 20:36, schrieb Marian Kechlibar:
聽聽

Marian, what about other clients that do this, aren't you still going
to have the problem with them?
聽聽聽聽聽聽

Well, from the myriad of SIP clients running around the Internet, we chose
only SIP communicator to be surely compatible with... and this is because
it is multi-platform, has a dedicated team of developers and it also seems
to be easily modifiable if the need arises. I certainly do not intend to
flatter
you idly, but this is how it is. Most other SIP clients either do not
run on multiple
platforms, or are developed by a single overworked man, or aren't open
source
enough... etc.

Wouldn't it make more sense to drop RTP packets
and somehow avoid the context switching instead?
聽聽

As the song goes: ... if I could, if I only could, I surely would!

The trouble is: ZRTP and RTP are multiplexed on the same port. Therefore you
need a single socket to listen to incoming packets for both ZRTP and
RTP. This
socket reports you every incoming UDP packet, and you need to look at
it, even
briefly, to determine whether it is a common RTP packet, or a ZRTP
packet. But
even before that, the socket has already consumed some resources - in
this case,
too much of them.

And you can't turn the socket off for the second of Diffie-Hellman,
because the
underlying system implementation of networking is so deficient that,
more often than
not, you wouldn't be able to start it up in reasonable time again when
needed (say,
for sending of the resulting DHPart or Confirm message).

Best regards

Marian

---------------------------------------------------------------------
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


#20

Hello,

I will be able to try it either on Monday or on Tuesday.

Best regards

Marian

Dne 29.10.2010 20:27, Sebastien Vincent napsal(a):

路路路

Hi Marian,

I commit a fix in revision 7875 to address the RTP problem. Can you try
it and tell us if it works for you ?

Regards,
--
Seb

Le 27/10/2010 23:41, Emil Ivov a 茅crit :

Hey Marian,

袧邪 27.10.10 22:45, Marian Kechlibar 薪邪锌懈褋邪:
聽聽

Hello Emil,

Did have a look yesterday but it seems like the issue is coming from
the
native speex implementation so it's probably not going to be a 2 minute
fix.

Hmm.... We've had some issue with speex timestamps this year:
https://sip-communicator.dev.java.net/issues/show_bug.cgi?id=821
It was then fixed fully and the timestamps looked right since
revision 7102.
I believe speex hasn't evolved since then, it is still the same 1.1.2
beta release.
聽聽聽聽聽

Back in r7102 we were still using the jspeex implementation (i.e.
jspeex.jar). We switched to the native lib between r7245 and r7253.

Emil

Best regards

Marian
聽聽聽聽

We'll have a look next week (or the one after). Thanks for opening the
issue.

Cheers,
Emil

Best regards

Marian

Dne 25.10.2010 16:05, Emil Ivov napsal(a):

Hey Marian,

On Mon, Oct 25, 2010 at 3:38 PM, Marian Kechlibar >>>>>> <marian.kechlibar@circletech.net> wrote:

Hello,

it seems that outgoing Speex packets have incorrect RTP
timestamp. It
starts with 4294967295, then goes to 159, 319, 479 etc.
Probably the code initializes a counter to be -1, not 0, then adds
correct values of 160.

Right, this looks weird indeed. Care to provide a patch? If not then
we'll probably look at this next week or the week after so in that
case could you please open an issue so that we don't forget about it?

Thanks!
Emil

I can send a Wireshark dump, if necessary. It is rather largish,
though.

Best regards

Marian Kechlibar

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

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