Merged revisions 194484 via svnmerge from
authorMark Michelson <mmichelson@digium.com>
Thu, 14 May 2009 22:20:51 +0000 (22:20 +0000)
committerMark Michelson <mmichelson@digium.com>
Thu, 14 May 2009 22:20:51 +0000 (22:20 +0000)
commit64c6397bd08b4b1b9f825a43e5b9197feb267acb
treed5077020bde072da672819284553c23e06c9f024
parent7872538b83cbb2cc94df0140c5686cbcc8f66c32
Merged revisions 194484 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines

  Fix a race condition where a reinvite could trigger a 482 response.

  The loop detection/spiral detection code in chan_sip used the owner
  channel's state as a criterion for determining if the incoming INVITE
  is a looped request. The problem with this is that the INVITE-handling
  code happens in a different thread than the thread that marks the owner
  channel as being up. As a result, if a reinvite were to come in very quickly,
  say from another Asterisk on the same LAN, it was possible for the reinvite
  to arrive before the owner channel had been set to the up state.

  This patch corrects the problem by using the invitestate of the sip_pvt
  instead, since that can be guaranteed to be set correctly by the time
  the reinvite arrives. Since there is a switch statement further in the
  INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
  of the sip_pvt in case we should actually be treating the channel as if it were
  up already.

  (closes issue #12215)
  Reported by: jpyle
  Patches:
        12215_confirmed.patch uploaded by mmichelson (license 60)
  Tested by: lmadsen
........

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/chan_sip.c