[sip-comm-dev] ZRTP transformer doesn't deliver packets with seq number >65535


#1

Werner,

While we - damencho and I - were preparing the video demo for the
FOSDEM demo, we noticed that the video would stop after some time. So
we started backtracing it up the stack and determined the RTP packets
with seq number >65535 weren't delivered to us. Since seq numbers are
expressed in two bytes, it means the packets stop coming to us when
the seq number rolls over. We commented the ZRTP transformer out of
CallSessionImpl (i.e. disabled it) and then the RTP packets with seq
number >65535 started coming to us.

We'd be delighted to have it fixed for the FOSDEM demo.

Best regards,
Lubo

···

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


#2

Lubo,

was ist just the ZRTPTransformer or was SRTP engaged. In case of SRTP
it could be that same rollover counter does not work - otherwise something
could be wrong in Transformer packet handling. Do you have any further
indications? Also the packet counter usually does not start at one but at
a random number.

Regards,
Werner

Lubomir Marinov schrieb:

···

Werner,

While we - damencho and I - were preparing the video demo for the
FOSDEM demo, we noticed that the video would stop after some time. So
we started backtracing it up the stack and determined the RTP packets
with seq number >65535 weren't delivered to us. Since seq numbers are
expressed in two bytes, it means the packets stop coming to us when
the seq number rolls over. We commented the ZRTP transformer out of
CallSessionImpl (i.e. disabled it) and then the RTP packets with seq
number >65535 started coming to us.

We'd be delighted to have it fixed for the FOSDEM demo.

Best regards,
Lubo

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

I had a quiuck look into the transform stuff but couldn't see any place
where the outgoing part deals with RTP packet counters, only if SRTP
is switched on the counter is used to compute authentication.

Same on the input side. Do you have any logs available?

Regards,
Werner

Werner Dittmann schrieb:

···

Lubo,

was ist just the ZRTPTransformer or was SRTP engaged. In case of SRTP
it could be that same rollover counter does not work - otherwise something
could be wrong in Transformer packet handling. Do you have any further
indications? Also the packet counter usually does not start at one but at
a random number.

Regards,
Werner

Lubomir Marinov schrieb:

Werner,

While we - damencho and I - were preparing the video demo for the
FOSDEM demo, we noticed that the video would stop after some time. So
we started backtracing it up the stack and determined the RTP packets
with seq number >65535 weren't delivered to us. Since seq numbers are
expressed in two bytes, it means the packets stop coming to us when
the seq number rolls over. We commented the ZRTP transformer out of
CallSessionImpl (i.e. disabled it) and then the RTP packets with seq
number >65535 started coming to us.

We'd be delighted to have it fixed for the FOSDEM demo.

Best regards,
Lubo

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

we don't have logs cause testing sometimes takes about ten minutes and there was nothing interesting :slight_smile: we put a print in the decoder to watch the sequence number that comes to the video decoder and thats it :slight_smile:
What we have done is removing all the imports related to zrtp from CallSessionImpl (and comment all errors :)) and made a SC 2 SC video call in p2p mode. Yes it was a dirty try but helped.
Without commenting those code when the sequence number reaches the max value the video stops.
Yes it starts at random sometimes its from 50k sometimes from 13k or 2k.
With those lines commented everything is working fine.
The call we made is just enter number and hit dial without pushing any of the buttons that appear later ( from Secure Call UI) -
so I don't know if SRTP is turned on in this situation.

Cheers
damencho

Werner Dittmann wrote:

···

I had a quiuck look into the transform stuff but couldn't see any place
where the outgoing part deals with RTP packet counters, only if SRTP
is switched on the counter is used to compute authentication.

Same on the input side. Do you have any logs available?

Regards,
Werner

Werner Dittmann schrieb:
  

Lubo,

was ist just the ZRTPTransformer or was SRTP engaged. In case of SRTP
it could be that same rollover counter does not work - otherwise something
could be wrong in Transformer packet handling. Do you have any further
indications? Also the packet counter usually does not start at one but at
a random number.

Regards,
Werner

Lubomir Marinov schrieb:
    

Werner,

While we - damencho and I - were preparing the video demo for the
FOSDEM demo, we noticed that the video would stop after some time. So
we started backtracing it up the stack and determined the RTP packets
with seq number >65535 weren't delivered to us. Since seq numbers are
expressed in two bytes, it means the packets stop coming to us when
the seq number rolls over. We commented the ZRTP transformer out of
CallSessionImpl (i.e. disabled it) and then the RTP packets with seq
number >65535 started coming to us.

We'd be delighted to have it fixed for the FOSDEM demo.

Best regards,
Lubo

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

Damian,

if the secure UI is shownd _and_ the padlock is in "closed" state
then it's quite sure that SRTP is _on_ . As said if SRTP is on there
might be a problem with SRTP authentication because this authentication
involves a roll-over-counter (ROC).

Do you have security enabled for the SIP account? Its in the extended
account page and it is enabled by default. Maybe this is the problem??

Does transmission stop if the counter goes over 2^32 or after the
number of sent packet is 2^32 ?

Regards,
Werner

Damian Minkov schrieb:

···

Hi,

we don't have logs cause testing sometimes takes about ten minutes and
there was nothing interesting :slight_smile: we put a print in the decoder to watch
the sequence number that comes to the video decoder and thats it :slight_smile:
What we have done is removing all the imports related to zrtp from
CallSessionImpl (and comment all errors :)) and made a SC 2 SC video
call in p2p mode. Yes it was a dirty try but helped.
Without commenting those code when the sequence number reaches the max
value the video stops.
Yes it starts at random sometimes its from 50k sometimes from 13k or 2k.
With those lines commented everything is working fine.
The call we made is just enter number and hit dial without pushing any
of the buttons that appear later ( from Secure Call UI) -
so I don't know if SRTP is turned on in this situation.

Cheers
damencho

Werner Dittmann wrote:

I had a quiuck look into the transform stuff but couldn't see any place
where the outgoing part deals with RTP packet counters, only if SRTP
is switched on the counter is used to compute authentication.

Same on the input side. Do you have any logs available?

Regards,
Werner

Werner Dittmann schrieb:

Lubo,

was ist just the ZRTPTransformer or was SRTP engaged. In case of SRTP
it could be that same rollover counter does not work - otherwise
something
could be wrong in Transformer packet handling. Do you have any further
indications? Also the packet counter usually does not start at one
but at
a random number.

Regards,
Werner

Lubomir Marinov schrieb:
   

Werner,

While we - damencho and I - were preparing the video demo for the
FOSDEM demo, we noticed that the video would stop after some time. So
we started backtracing it up the stack and determined the RTP packets
with seq number >65535 weren't delivered to us. Since seq numbers are
expressed in two bytes, it means the packets stop coming to us when
the seq number rolls over. We commented the ZRTP transformer out of
CallSessionImpl (i.e. disabled it) and then the RTP packets with seq
number >65535 started coming to us.

We'd be delighted to have it fixed for the FOSDEM demo.

Best regards,
Lubo

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


#6

After your posts I did a more thourough check on the SRTP code
and it seems that there is a problem with the replay check inside
SRTP - some code parts are missing. Probably these code parts
were missed when porting SRTP from C++ to Java during GSoC 2007.

Thus - disable security for long running transmissions until we
fixed this possible problem. The fix it I need to have a closer look
to fully understand the code and the effects it has.

Regards,
Werner

Werner Dittmann schrieb:

···

Damian,

if the secure UI is shownd _and_ the padlock is in "closed" state
then it's quite sure that SRTP is _on_ . As said if SRTP is on there
might be a problem with SRTP authentication because this authentication
involves a roll-over-counter (ROC).

Do you have security enabled for the SIP account? Its in the extended
account page and it is enabled by default. Maybe this is the problem??

Does transmission stop if the counter goes over 2^32 or after the
number of sent packet is 2^32 ?

Regards,
Werner

Damian Minkov schrieb:

Hi,

we don't have logs cause testing sometimes takes about ten minutes and
there was nothing interesting :slight_smile: we put a print in the decoder to watch
the sequence number that comes to the video decoder and thats it :slight_smile:
What we have done is removing all the imports related to zrtp from
CallSessionImpl (and comment all errors :)) and made a SC 2 SC video
call in p2p mode. Yes it was a dirty try but helped.
Without commenting those code when the sequence number reaches the max
value the video stops.
Yes it starts at random sometimes its from 50k sometimes from 13k or 2k.
With those lines commented everything is working fine.
The call we made is just enter number and hit dial without pushing any
of the buttons that appear later ( from Secure Call UI) -
so I don't know if SRTP is turned on in this situation.

Cheers
damencho

Werner Dittmann wrote:

I had a quiuck look into the transform stuff but couldn't see any place
where the outgoing part deals with RTP packet counters, only if SRTP
is switched on the counter is used to compute authentication.

Same on the input side. Do you have any logs available?

Regards,
Werner

Werner Dittmann schrieb:

Lubo,

was ist just the ZRTPTransformer or was SRTP engaged. In case of SRTP
it could be that same rollover counter does not work - otherwise
something
could be wrong in Transformer packet handling. Do you have any further
indications? Also the packet counter usually does not start at one
but at
a random number.

Regards,
Werner

Lubomir Marinov schrieb:
   

Werner,

While we - damencho and I - were preparing the video demo for the
FOSDEM demo, we noticed that the video would stop after some time. So
we started backtracing it up the stack and determined the RTP packets
with seq number >65535 weren't delivered to us. Since seq numbers are
expressed in two bytes, it means the packets stop coming to us when
the seq number rolls over. We commented the ZRTP transformer out of
CallSessionImpl (i.e. disabled it) and then the RTP packets with seq
number >65535 started coming to us.

We'd be delighted to have it fixed for the FOSDEM demo.

Best regards,
Lubo

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

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


#7

Hi again,

we have made some tests today after you have commit the new changes, unfortunately they do not fix the problem.
We also test when "enable support for secure calls" is switched off then as you suggested everything is fine.
We also put some prints to see what happens after the sequence number reaches max value and start to increment from 0. In reverseTransform of SRTPTransformer every packet goes in here :
                       boolean validPacket = context.reverseTransformPacket(pkt);
                   if (!validPacket)
            {
                return null;
            }
Further investigation shows that packets are not authenticated - the comparsion of the first four bytes
fails. This happens in reverseTransformPacket in SRTPCryptoContext in the first for cycle where it returns false, we made some prints to see is this right and we confirm that the bytes are different.
This is what we have found today. I think that we cannot say whether send or receive is the problem.

damencho

Werner Dittmann wrote:

···

After your posts I did a more thourough check on the SRTP code
and it seems that there is a problem with the replay check inside
SRTP - some code parts are missing. Probably these code parts
were missed when porting SRTP from C++ to Java during GSoC 2007.

Thus - disable security for long running transmissions until we
fixed this possible problem. The fix it I need to have a closer look
to fully understand the code and the effects it has.

Regards,
Werner

Werner Dittmann schrieb:
  

Damian,

if the secure UI is shownd _and_ the padlock is in "closed" state
then it's quite sure that SRTP is _on_ . As said if SRTP is on there
might be a problem with SRTP authentication because this authentication
involves a roll-over-counter (ROC).

Do you have security enabled for the SIP account? Its in the extended
account page and it is enabled by default. Maybe this is the problem??

Does transmission stop if the counter goes over 2^32 or after the
number of sent packet is 2^32 ?

Regards,
Werner

Damian Minkov schrieb:
    

Hi,

we don't have logs cause testing sometimes takes about ten minutes and
there was nothing interesting :slight_smile: we put a print in the decoder to watch
the sequence number that comes to the video decoder and thats it :slight_smile:
What we have done is removing all the imports related to zrtp from
CallSessionImpl (and comment all errors :)) and made a SC 2 SC video
call in p2p mode. Yes it was a dirty try but helped.
Without commenting those code when the sequence number reaches the max
value the video stops.
Yes it starts at random sometimes its from 50k sometimes from 13k or 2k.
With those lines commented everything is working fine.
The call we made is just enter number and hit dial without pushing any
of the buttons that appear later ( from Secure Call UI) -
so I don't know if SRTP is turned on in this situation.

Cheers
damencho

Werner Dittmann wrote:
      

I had a quiuck look into the transform stuff but couldn't see any place
where the outgoing part deals with RTP packet counters, only if SRTP
is switched on the counter is used to compute authentication.

Same on the input side. Do you have any logs available?

Regards,
Werner

Werner Dittmann schrieb:

Lubo,

was ist just the ZRTPTransformer or was SRTP engaged. In case of SRTP
it could be that same rollover counter does not work - otherwise
something
could be wrong in Transformer packet handling. Do you have any further
indications? Also the packet counter usually does not start at one
but at
a random number.

Regards,
Werner

Lubomir Marinov schrieb:
   

Werner,

While we - damencho and I - were preparing the video demo for the
FOSDEM demo, we noticed that the video would stop after some time. So
we started backtracing it up the stack and determined the RTP packets
with seq number >65535 weren't delivered to us. Since seq numbers are
expressed in two bytes, it means the packets stop coming to us when
the seq number rolls over. We commented the ZRTP transformer out of
CallSessionImpl (i.e. disabled it) and then the RTP packets with seq
number >65535 started coming to us.

We'd be delighted to have it fixed for the FOSDEM demo.

Best regards,
Lubo

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

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

Hi there,

thanks for the info. Todays fix was to make sure to deal with short
integeres in case of sign extension and to fix the problem of
replay check (missing code).

Thanks for the additiona info - I'll try to perform some more tests
and checks. But it is a good info that it is definitely part of SRTP
handling, not the generic Transformer.

I'll keep you updated :slight_smile:

Regards,
Werner

Damian Minkov schrieb:

Hi again,

we have made some tests today after you have commit the new changes,
unfortunately they do not fix the problem.
We also test when "enable support for secure calls" is switched off then
as you suggested everything is fine.
We also put some prints to see what happens after the sequence number
reaches max value and start to increment from 0. In reverseTransform of
SRTPTransformer every packet goes in here :
                     boolean validPacket =
context.reverseTransformPacket(pkt);
                 if (!validPacket)
           {
               return null;
           }
Further investigation shows that packets are not authenticated - the
comparsion of the first four bytes
fails. This happens in reverseTransformPacket in SRTPCryptoContext in
the first for cycle where it returns false, we made some prints to see
is this right and we confirm that the bytes are different.
This is what we have found today. I think that we cannot say whether
send or receive is the problem.

damencho

Werner Dittmann wrote:

After your posts I did a more thourough check on the SRTP code
and it seems that there is a problem with the replay check inside
SRTP - some code parts are missing. Probably these code parts
were missed when porting SRTP from C++ to Java during GSoC 2007.

Thus - disable security for long running transmissions until we
fixed this possible problem. The fix it I need to have a closer look
to fully understand the code and the effects it has.

Regards,
Werner

<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


#9

Damian, Lubo,

thanks to your excellent decsription I was able to reproduce the error
with my test programs. I fixed the problem and the tests are ok.

Just a few second ago I checked-in a new srtp crypto context that
contais the fix. Can you give it a try?

Regards,
Werner

Werner Dittmann schrieb:

···

Hi there,

thanks for the info. Todays fix was to make sure to deal with short
integeres in case of sign extension and to fix the problem of
replay check (missing code).

Thanks for the additiona info - I'll try to perform some more tests
and checks. But it is a good info that it is definitely part of SRTP
handling, not the generic Transformer.

I'll keep you updated :slight_smile:

Regards,
Werner

Damian Minkov schrieb:

Hi again,

we have made some tests today after you have commit the new changes,
unfortunately they do not fix the problem.
We also test when "enable support for secure calls" is switched off then
as you suggested everything is fine.
We also put some prints to see what happens after the sequence number
reaches max value and start to increment from 0. In reverseTransform of
SRTPTransformer every packet goes in here :
                     boolean validPacket =
context.reverseTransformPacket(pkt);
                 if (!validPacket)
           {
               return null;
           }
Further investigation shows that packets are not authenticated - the
comparsion of the first four bytes
fails. This happens in reverseTransformPacket in SRTPCryptoContext in
the first for cycle where it returns false, we made some prints to see
is this right and we confirm that the bytes are different.
This is what we have found today. I think that we cannot say whether
send or receive is the problem.

damencho

Werner Dittmann wrote:

After your posts I did a more thourough check on the SRTP code
and it seems that there is a problem with the replay check inside
SRTP - some code parts are missing. Probably these code parts
were missed when porting SRTP from C++ to Java during GSoC 2007.

Thus - disable security for long running transmissions until we
fixed this possible problem. The fix it I need to have a closer look
to fully understand the code and the effects it has.

Regards,
Werner

<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


#10

Hi,

I just test it and I can confirm that its ok :slight_smile:

damencho

Werner Dittmann wrote:

···

Damian, Lubo,

thanks to your excellent decsription I was able to reproduce the error
with my test programs. I fixed the problem and the tests are ok.

Just a few second ago I checked-in a new srtp crypto context that
contais the fix. Can you give it a try?

Regards,
Werner

Werner Dittmann schrieb:
  

Hi there,

thanks for the info. Todays fix was to make sure to deal with short
integeres in case of sign extension and to fix the problem of
replay check (missing code).

Thanks for the additiona info - I'll try to perform some more tests
and checks. But it is a good info that it is definitely part of SRTP
handling, not the generic Transformer.

I'll keep you updated :slight_smile:

Regards,
Werner

Damian Minkov schrieb:
    

Hi again,

we have made some tests today after you have commit the new changes,
unfortunately they do not fix the problem.
We also test when "enable support for secure calls" is switched off then
as you suggested everything is fine.
We also put some prints to see what happens after the sequence number
reaches max value and start to increment from 0. In reverseTransform of
SRTPTransformer every packet goes in here :
                     boolean validPacket =
context.reverseTransformPacket(pkt);
                 if (!validPacket)
           {
               return null;
           }
Further investigation shows that packets are not authenticated - the
comparsion of the first four bytes
fails. This happens in reverseTransformPacket in SRTPCryptoContext in
the first for cycle where it returns false, we made some prints to see
is this right and we confirm that the bytes are different.
This is what we have found today. I think that we cannot say whether
send or receive is the problem.

damencho

Werner Dittmann wrote:
      

After your posts I did a more thourough check on the SRTP code
and it seems that there is a problem with the replay check inside
SRTP - some code parts are missing. Probably these code parts
were missed when porting SRTP from C++ to Java during GSoC 2007.

Thus - disable security for long running transmissions until we
fixed this possible problem. The fix it I need to have a closer look
to fully understand the code and the effects it has.

Regards,
Werner

<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

Hi,

great to here. Just a question: do your tests use two SRTP sessions,
one for audi and one for video? When implementing multi-stream mode
I couldn't test it inside SC. Would it be possible to take a screen
shot and send it - that way I could see the security GUI and which
info it displays if multi-stream is active.

Thanks.

Regards,
Werner

PS: because Java does not support unsigned data types there is a
small problem in the current implementation:

Per RFC 3711 it is possible to send maximal 2^48 SRTP packets before
the keys must be re-negotiated. Due to the signed integer in Java
this number is reduced to 2^47-1 packets. Assuming 50 packets per
second a SRTP session should not exceed a mere 89255 years (approx.).
IMHO we need to tackle that problem in a relative near future :wink:

Werner

Damian Minkov schrieb:

Hi,

I just test it and I can confirm that its ok :slight_smile:

damencho

Werner Dittmann wrote:

Damian, Lubo,

thanks to your excellent decsription I was able to reproduce the error
with my test programs. I fixed the problem and the tests are ok.

Just a few second ago I checked-in a new srtp crypto context that
contais the fix. Can you give it a try?

Regards,
Werner

Werner Dittmann schrieb:

Hi there,

thanks for the info. Todays fix was to make sure to deal with short
integeres in case of sign extension and to fix the problem of
replay check (missing code).

Thanks for the additiona info - I'll try to perform some more tests
and checks. But it is a good info that it is definitely part of SRTP
handling, not the generic Transformer.

I'll keep you updated :slight_smile:

Regards,
Werner

<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