Merged revisions 185845 via svnmerge from
authorDavid Vossel <dvossel@digium.com>
Wed, 1 Apr 2009 19:03:32 +0000 (19:03 +0000)
committerDavid Vossel <dvossel@digium.com>
Wed, 1 Apr 2009 19:03:32 +0000 (19:03 +0000)
commit729f22522558310b9a01413a1be8a35b4f3cb7f5
tree8b993273b345cd43094cda29a77df5a4d54e245a
parentf1707e95e5188f9788a6a9461c3640b01e381989
Merged revisions 185845 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r185845 | dvossel | 2009-04-01 14:02:00 -0500 (Wed, 01 Apr 2009) | 10 lines

  Fixes issue with dropped calles due to re-Invite glare and re-Invites never executing after a 491

  Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno.  Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries.  Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct.  When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite.  In this case, it is in response to the glare invite and must be dealt with or the call is dropped.  I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261.  Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well.

  (closes issue #12013)
  Reported by: alx

  Review: http://reviewboard.digium.com/r/213/
........

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