summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDavid Vossel <dvossel@digium.com>2010-08-26 15:28:07 +0000
committerDavid Vossel <dvossel@digium.com>2010-08-26 15:28:07 +0000
commit522806df97095ec5aaf4c94f2e5f5d7516bdbfaa (patch)
tree913f6b0591f3b69cd9184c7b626251836bf8f537
parent405a831032f6aef8328f1bc486b78546a8ed1b23 (diff)
Merged revisions 283692 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r283692 | dvossel | 2010-08-26 10:26:37 -0500 (Thu, 26 Aug 2010) | 32 lines Merged revisions 283691 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.6.2 ................ r283691 | dvossel | 2010-08-26 10:24:40 -0500 (Thu, 26 Aug 2010) | 25 lines Merged revisions 283690 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r283690 | dvossel | 2010-08-26 10:22:28 -0500 (Thu, 26 Aug 2010) | 19 lines Fixed how Asterisk destroys a dialog on channel hangup before invite receives a response. If an ast_channel with a SIP tech pvt hangs up before the sip dialog gets a response to its outgoing INVITE, Asterisk used to pretend_ack the INVITE. This is not rfc compliant and results in confusion at the other endpoint. sip_pretend_ack will ack and remove all the packets in the retransmit queue. This means that the INVITE will stop retransmitting, and that any response to that INVITE that comes after the pretend_ack occurs will be ignored. Instead of faking any sort of acknowledgement for an outgoing INVITE during an internal hangup, we should let the protocol stack process the INVITE transaction and terminate the dialog properly. This is achieved by setting the PENDING_BYE flag. When this flag is used, once the dialog proceeds to an escapable state the transaction will either be canceled with a SIP_CANCEL or completed followed immediately by a BYE. Attempting to do this any other way is incorrect. If the endpoint is not responding to the INVITE request, the INVITE must continue to be retransmitted until it times out which will result in the dialog being destroyed. ........ ................ ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-rw-r--r--channels/chan_sip.c2
1 files changed, 0 insertions, 2 deletions
diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index 828778ba5..69de9a88e 100644
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -5837,12 +5837,10 @@ static int sip_hangup(struct ast_channel *ast)
if (!p->alreadygone && p->initreq.data && !ast_strlen_zero(p->initreq.data->str)) {
if (needcancel) { /* Outgoing call, not up */
if (ast_test_flag(&p->flags[0], SIP_OUTGOING)) {
- /* stop retransmitting an INVITE that has not received a response */
/* if we can't send right now, mark it pending */
if (p->invitestate == INV_CALLING) {
/* We can't send anything in CALLING state */
ast_set_flag(&p->flags[0], SIP_PENDINGBYE);
- __sip_pretend_ack(p);
/* Do we need a timer here if we don't hear from them at all? Yes we do or else we will get hung dialogs and those are no fun. */
sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
append_history(p, "DELAY", "Not sending cancel, waiting for timeout");