diff options
| author | David Vossel <dvossel@digium.com> | 2009-04-01 19:03:32 +0000 |
|---|---|---|
| committer | David Vossel <dvossel@digium.com> | 2009-04-01 19:03:32 +0000 |
| commit | 729f22522558310b9a01413a1be8a35b4f3cb7f5 (patch) | |
| tree | 8b993273b345cd43094cda29a77df5a4d54e245a /include/asterisk/res_odbc.h | |
| parent | f1707e95e5188f9788a6a9461c3640b01e381989 (diff) | |
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
Diffstat (limited to 'include/asterisk/res_odbc.h')
0 files changed, 0 insertions, 0 deletions