kenmirrors/asterisk
1
0
Fork 0
mirror of https://github.com/asterisk/asterisk.git synced 2026-06-15 20:27:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merged revisions 283692 via svnmerge from

Browse Source 
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
This commit is contained in:
David Vossel
2010-08-26 15:28:07 +00:00
parent 405a831032
commit 522806df97
1 changed files with 0 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
channels/chan_sip.c
-2
View File
@@ -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");