summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorMark Michelson <mmichelson@digium.com>2009-06-22 14:58:24 +0000
committerMark Michelson <mmichelson@digium.com>2009-06-22 14:58:24 +0000
commitf142cbe10ca1781b3712cecc26d552c8a97809b6 (patch)
treec31251393ff35bd2b85eb338b5718e6a4e883316 /include
parente68e6f9d75b0ca2751c92a0988248168530c59fe (diff)
Merged revisions 202341-202342 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r202341 | mmichelson | 2009-06-22 09:42:55 -0500 (Mon, 22 Jun 2009) | 26 lines Fix a situation in which Asterisk would not stop retransmitting 487s. If a CANCEL were received by Asterisk, we would send a 487 in response to the original INVITE and a 200 OK for the CANCEL. If there were a network hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used to be to try sending another 487 to the canceled INVITE and another 200 OK to the CANCEL. The problem here is that the originally-sent 487 was sent "reliably" meaning that it will be retransmitted until it is received properly. So when we receive the second CANCEL it is likely that the first batch of 487s we sent is still going strong and reaches the UA. The result was that the second set of 487s would be retransmitted constantly until the maximum number of retries had been reached. The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel the retransmission of the first set of 487s and start a second set. This causes the dialog to be terminated reasonably. (closes issue #14584) Reported by: klaus3000 Patches: 14584_v2.patch uploaded by mmichelson (license 60) Tested by: klaus3000 ........ r202342 | mmichelson | 2009-06-22 09:44:58 -0500 (Mon, 22 Jun 2009) | 3 lines Remove an extra debug line left from previous commit. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions