[reSIProcate] transaction id collisions
Fischl jason
jason.fischl at gmail.com
Thu Jun 2 13:54:13 CDT 2005
This behavior is windows specific.
On 6/2/05, david Butcher <david at purplecomm.com> wrote:
> Quoting Scott Godin <slgodin at icescape.com>:
>
> > By tid collisions, do you mean that resip is generating duplicate tids for
> > different requests?
>
> Apparently. I have to instrument to prove it.
>
> > I've seen this behavior if you forget to call srand on every thread in your
> > application that is creating requests. Even if you only use 1 thread, when
> > you restart your app and you haven't called srand, it will use the same
> > tid's it used the last time you started.
>
> random()'s state is in thread data? if that is the case then resip::Random's
> initialize strategy is broken -- it initializes as a singleton.
>
> thanks,
> david
>
> >
> >
> > -----Original Message-----
> > From: david Butcher [mailto:david at purplecomm.com]
> > Sent: Wednesday, June 01, 2005 7:03 PM
> > To: resiprocate-devel at list.sipfoundry.org
> > Subject: [reSIProcate] transaction id collisions
> >
> > We're seeing transaction id collisions in a proxy built on a slightly out of
> > date version of resiprocate.
> >
> > It seems that straight ahead random collision is extremely unlikely.
> >
> > Under what conditions can a transaction id collision occur? Some sort of
> > replay
> > attack? Can this cause an assert?
> >
> > david
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel at list.sipfoundry.org
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
> >
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
More information about the resiprocate-devel
mailing list