[asterisk-bugs] [Asterisk 0014692]: [patch] ISDN-Transfer causes backcall attempt of attendent phone

Asterisk Bug Tracker noreply at bugs.digium.com
Tue Jul 14 14:49:49 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14692 
====================================================================== 
Reported By:                sodom
Assigned To:                rmudgett
====================================================================== 
Project:                    Asterisk
Issue ID:                   14692
Category:                   Channels/chan_misdn
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.24 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-03-18 07:57 CDT
Last Modified:              2009-07-14 14:49 CDT
====================================================================== 
Summary:                    [patch] ISDN-Transfer causes backcall attempt of
attendent phone
Description: 
If you successfuly transfer a call via ISDN-Transfer the attendant phone
will generate a "ghost" back call for the first phone you spoke to.

e.g.

You got three phones with the number 11 (port 4),15 (port 8) and 13 (port
6).

15 calls 11 -> connection success.
15 presses R-Key -> Hold success, 11 got moh
15 calls 13 -> connection success.
15 simply hook on -> transfer 13->11 success
15 starts ringing again, indicating still established call to 11

as there is nothing left from the connection 15->11 you can run into real
problems. Some phones ring forether as they don't reaslise that the
connection was disconnected. (Most of Siemens DECT-ISDN phones e.g., on
some you can't get rid of the ghost call other the switching the phone
off.)

I analised the problem down and i think it's simply the problem that
asterisk didn't send a ISDN-Relase message for the first connection. It
only send a ISDN-Release message for the second connection, so the
attendant phone simply didn't know that the initial connection was also
released.

I attached a asterisk CLI of the misdn debug lv. 1.

I guess the problem is that asterisk masquerades the second connection
with the first connection. Logicaly only three connection are handling in
asterisk but in real you would need to handle four connections.
====================================================================== 

---------------------------------------------------------------------- 
 (0107744) svnbot (reporter) - 2009-07-14 14:49
 https://issues.asterisk.org/view.php?id=14692#c107744 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 206565

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_misdn.c
U   branches/1.6.2/channels/misdn/isdn_lib.c
U   branches/1.6.2/channels/misdn/isdn_lib.h

------------------------------------------------------------------------
r206565 | rmudgett | 2009-07-14 14:49:47 -0500 (Tue, 14 Jul 2009) | 42
lines

Merged revisions 206489 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r206489 | rmudgett | 2009-07-14 12:01:48 -0500 (Tue, 14 Jul 2009) | 35
lines
  
  Merged revisions 206487 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r206487 | rmudgett | 2009-07-14 11:44:47 -0500 (Tue, 14 Jul 2009) | 28
lines
    
    Fixes several call transfer issues with chan_misdn.
    
    *  issue https://issues.asterisk.org/view.php?id=14355 - Crash if attempt to
transfer a call to an
application.
    Masquerade the other pair of the four asterisk channels involved in
the
    two calls.  The held call already must be a bridged call (not an
    applicaton) or it would have been rejected.
    
    *  issue https://issues.asterisk.org/view.php?id=14692 - Held calls are not
automatically cleared after
transfer.
    Allow the core to initate disconnect of held calls to the ISDN port. 
This
    also fixes a similar case where the party on hold hangs up before
being
    transferred or taken off hold.
    
    *  JIRA ABE-1903 - Orphaned held calls left in music-on-hold.
    Do not simply block passing the hangup event on held calls to asterisk
    core.
    
    *  Fixed to allow held calls to be transferred to ringing calls.
    Previously, held calls could only be transferred to connected calls.
    *  Eliminated unused call states to simplify hangup code.
    *  Eliminated most uses of "holded" because it is not a word.
    
    (closes issue https://issues.asterisk.org/view.php?id=14355)
    (closes issue https://issues.asterisk.org/view.php?id=14692)
    Reported by: sodom
    Patches:
          misdn_xfer_v14_r205839.patch uploaded by rmudgett (license 664)
    Tested by: rmudgett
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=206565 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-07-14 14:49 svnbot         Checkin                                      
2009-07-14 14:49 svnbot         Note Added: 0107744                          
======================================================================




More information about the asterisk-bugs mailing list