summaryrefslogtreecommitdiffstats
path: root/chan_lcr.h
diff options
context:
space:
mode:
authorPeter Schlaile2008-09-27 22:03:44 +0200
committerroot2008-09-27 22:03:44 +0200
commit08f7138ac0d13805e61ff3303a50bdb5ed9a7bb7 (patch)
tree9966ca370e77ee156a65b49419e19489c8256fea /chan_lcr.h
parentadded options.c to automake, so that chan_lcr gets built correctly (diff)
downloadlcr-08f7138ac0d13805e61ff3303a50bdb5ed9a7bb7.tar.gz
lcr-08f7138ac0d13805e61ff3303a50bdb5ed9a7bb7.tar.xz
lcr-08f7138ac0d13805e61ff3303a50bdb5ed9a7bb7.zip
chan_lcr: fixed race condition in new ref assignment
LCR assumes, that any call in the list, that has ref set to 0 is waiting for a ref to be assigned. That can cause trouble, if we have one call waiting for a ref to be assigned and another call hanging in the list, that was just released in the same moment. Both have ref == 0 and in some circumstances, the new ref message picks the wrong one for assignment... This patch makes chan_lcr distinguish between calls waiting for a new ref and those, that only have their ref removed due to release. (It is not enough, to check for state, since new calls can change into release state immediately! That is also one of the race conditions, when this can get you into trouble: asterisk receives call1 by LCR, makes a SETUP call2 immediately through LCR and then receives a release for call1 by LCR before call2 got it's ref assigned!) This patch also removes some dead code, that was #ifdef'd out. End user notice: if you ever got into the situation, that _all_ calls from asterisk to LCR got released immediately and only a restart of asterisk got you out of the situation, then you might need this fix :)
Diffstat (limited to 'chan_lcr.h')
0 files changed, 0 insertions, 0 deletions