< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [recon-devel] Thread safe of recon for srtp


I know it, but for the RTP data, it's base on the UDP, allows packet lost or delay etc...
So consider this:

1: A thread now processing send data.
2: B thread change the mSTPSessionOut.
3: A thread process data faild, because the SRTP context changed - then this RTP packet send failed.
4: B thread change the mSRTPSession succeeded
5: A thread process next send data(next RTP packet)

In this case just lost one RTP packet(sometime maybe 2-3 RTP packets), but consider change mSRTPSessionOut is not frequent,
So I think can move this lock.

Thanks


On Tue, Jan 20, 2009 at 2:08 AM, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:

The SRTP sessions (ie. mSRTPSessionOut)  can change (via createXXboundSRTPSession) in another thread while sending/receiving is active – ie. when the SRTP session parameters are re-negotiated via SDP.  So this optimization is not possible.

 

Scott

 

From: recon-devel-bounces@xxxxxxxxxxxxxxx [mailto:recon-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Karlsson
Sent: Monday, January 19, 2009 1:03 PM
To: Scott Godin
Cc: recon-devel@xxxxxxxxxxxxxxx
Subject: Re: [recon-devel] Thread safe of recon for srtp

 

So I think maybe there can do optimization, likes:

err_status_t
MediaStream::srtpProtect(void* data, int* size, bool rtcp)
{
   {
       err_status_t status = err_status_no_ctx;

       Lock lock(mMutex);
       if (mSRTPSessionOutCreated == false)
       {
           return err_status_no_ctx;
       }
   }

       if(rtcp)
       {
           status = srtp_protect_rtcp(mSRTPSessionOut, data, size); 
       }
       else
       {
           status = srtp_protect(mSRTPSessionOut, data, size); 
       }
  
   return status;
}

Because the srtp functions will take long time ?


On Tue, Jan 20, 2009 at 1:28 AM, Scott Godin <sgodin@xxxxxxxxxxxxxxx> wrote:

That is correct.

2009/1/19 Karlsson <boost.regex@xxxxxxxxx>:

> Hi, I  think the libSRTP is thread safe and does not requires mutex, why in
> the mediastream.cxx of recon there has a lock ?
> Likes MediaStream::srtpProtect and  MediaStream::srtpUnprotect,
> MediaStream::createOutboundSRTPSession etc...
>
> I think this lock is used for mSRTPSessionOutCreated, mSRTPSessionInCreated
> and independent the srtp, right ?
>
> Thanks
>

> _______________________________________________
> recon-devel mailing list
> recon-devel@xxxxxxxxxxxxxxx
> List Archive: http://list.resiprocate.org/archive/recon-devel/
>