[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Linphone-developers] [PATCH] [PING..] zrtp: use session's seq_numbe
From: |
Dmitry Monakhov |
Subject: |
Re: [Linphone-developers] [PATCH] [PING..] zrtp: use session's seq_number for zrtp pack |
Date: |
Thu, 08 Nov 2012 13:32:54 +0400 |
User-agent: |
Notmuch/0.6.1 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-redhat-linux-gnu) |
On Tue, 06 Nov 2012 20:55:57 +0400, Dmitry Monakhov <address@hidden> wrote:
> On Tue, 06 Nov 2012 15:02:42 +0100, Werner Dittmann <address@hidden> wrote:
> > Am 05.11.2012 21:53, schrieb Dmitry Monakhov:
> > >
> > > Currently seq_number for zrtp initiated to random value so
> > > seq_numbers for rtp and zrtp packets will have different base
> > > which is incorrect because other parts expect to receive packets
> > > with monolithic seq_numbers.
> >
> > It's abosultely ok that ZRTP packet have different seq numbers, acutally
> > the ZRTP spec (RFC 6189) requires a random number, see chap 5.
> Ohh i've missed that part in rfc6189, But you also use same predefined number
> in
> https://github.com/wernerd/ZRTPCPP/blob/master/clients/ccrtp/ZrtpQueue.cpp
>
> Currently i try to add zrtp to
> libjingle(https://github.com/dmonakhov/libjingle).
> By default it use SDES/SRTP encryption, and i have to pick SDES or ZRTP
> during negotiation stage, and if ZRTP was chosen it still may fail later so
> call will be completely unprotected.
> At the same time Libjingle allow to separate different layer
> see
> https://github.com/dmonakhov/libjingle/blob/master/talk/session/media/channel.cc:
> OUT:ortp-->mediastream2--->srtp_filter.ProtectRtp()-->NET
> IN: NET-->srtp_filter.UnprotectRtp(pkt)--->mediatream2--->ortp
> So it is possible to use both negotiation strategies independently:
> Let's signalling layer setup encryption via SDES,
> later we can try to negotiate zrtp key over existing SDES/SRTP trunc.
> Later if zrtp negotiations succeed we may disable SDES, or continue
> in double encryption mode (crazy people will love that)
> I test this approach and it works quite well with one exception,
> established SDES/SRTP session expect to see monolithic seq_numbers
> according to rfc3711:3.3.2
>
> With my patch zrtp negotiation works fine over SRTP trunc.
> What do you think about that approach?
Werner, you are known as a zrtp guru. Can you please give an advice
Is it possible to avoid strict implementation RFC6189:ch5
in order to provide an ability of zrtp negotiation over SRTP trunc?
As soon as i understand Phill Zimmermann does not consider that
use-case(or i've just missed that).
>
> >
> > ZRTP just uses the same port numbers to send/receive its packets. ZRTP
> > is an own protocol and ZRTP packets shall be filtered by the receiving
> > software
> > and handed over to the ZRTP software and then discarded after ZRTP
> > processing.
> > ZRTP packets are _not_ RTP packets and should never be treated as such.
> >
> > Werner
> >
> >
> > > Let's use common session.rtp.snd_seq counter. ASAIU it is safe to
> > > modify counter w/o locking from zrtp callback because it is called
> > > from sender context.
> > >
> > > Signed-off-by: Dmitry Monakhov <address@hidden>
> > > ---
> > > src/zrtp.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/src/zrtp.c b/src/zrtp.c
> > > index bb653cd..3a35876 100644
> > > --- a/src/zrtp.c
> > > +++ b/src/zrtp.c
> > > @@ -50,7 +50,6 @@ struct _OrtpZrtpContext{
> > > RtpSession *session;
> > > uint32_t timerWillTriggerAt;
> > > uint16_t last_recv_zrtp_seq_number;
> > > - uint16_t last_sent_zrtp_seq_number;
> > > srtp_t srtpSend;
> > > srtp_t srtpRecv;
> > > zrtp_Callbacks zrtp_cb;
> > > @@ -197,7 +196,7 @@ static int32_t ozrtp_sendDataZRTP (ZrtpContext* ctx,
> > > const uint8_t* data, const
> > > uint8_t *buffer8=(uint8_t*)buffer32;
> > > uint16_t *buffer16=(uint16_t*)buffer32;
> > >
> > > - uint16_t seqNumber=userData->last_sent_zrtp_seq_number++;
> > > + uint16_t seqNumber=session->rtp.snd_seq++;
> > >
> > > *buffer8 = 0x10;
> > > buffer8[1]=0;
> > > @@ -769,7 +768,6 @@ static OrtpZrtpContext* createUserData(ZrtpContext
> > > *context) {
> > > userData->zrtpContext=context;
> > > userData->timerWillTriggerAt=0;
> > > userData->last_recv_zrtp_seq_number=0;
> > > - userData->last_sent_zrtp_seq_number=rand()+1; // INT_MAX+1 (signed)
> > >
> > > userData->srtpRecv=NULL;
> > > userData->srtpSend=NULL;
> > >
> >
> >
> > --
> > ----------------------------------------------
> > Werner Dittmann address@hidden
> > Tel +49 176 993 462 95
> > PGP key: 82EF5E8B
> >
> > _______________________________________________
> > Linphone-developers mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/linphone-developers
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/linphone-developers