| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
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/
>