[asterisk-bugs] [Asterisk 0015833]: Transfering phone left connected

Asterisk Bug Tracker noreply at bugs.digium.com
Wed Oct 21 10:26:06 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15833 
====================================================================== 
Reported By:                viraptor
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15833
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     ready for review
Asterisk Version:           1.4.26.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-09-04 12:57 CDT
Last Modified:              2009-10-21 10:26 CDT
====================================================================== 
Summary:                    Transfering phone left connected
Description: 
When doing a remote attended transfer in one of these 2 setups:

phones A,B,C --- proxy --- asterisks Z,X
when A->B call is on Z and B->C is on X, or:

phones A,B (with identity B1,B2), C --- asterisks Z,X
(A,B1 register on Z; B2,C on X)
when A->B1 call is on Z and B2->C is on X

In both scenarios Z and X are friends with no authentication needed.

The B phone doesn't get properly disconnected. asterisks invite/replace
each other properly and the audio channel is ok. B itself drops one of the
calls. But Z is not disconnecting B's call at all. You can replicate that
scenario with minimalistic dialplan - _X.,Dial(SIP/${EXTEN}) in default on
both sides.

If you do the same transfer, but on a single asterisk (local attended
transfer), then the transferring phone will drop one of the call legs
itself (like above) and asterisk will additionally drop the second one.

Tested with Snom 1XX, 3XX and GXP phones - problem always appears and the
call is never dropped if the transfer is remote.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0007784 Attended SIP Transfer Call Teardown Issue
====================================================================== 

---------------------------------------------------------------------- 
 (0112540) c0rnoTa (reporter) - 2009-10-21 10:26
 https://issues.asterisk.org/view.php?id=15833#c112540 
---------------------------------------------------------------------- 
So, I have a call drops on my production systems. I'm using E1 channel for
external calls, IAX2 for inter asterisk calls and SIP for local calls.
Asterisk ver. 1.4.26
Dahdi 2.2.0
Libpri WAS 1.4.10.1

Operators (in queue) on first asterisk receive calls from DAHDI, make
attended transfer via IAX on second asterisk, speake with another operator
(in queue) and then brige dahdi caller with second operator. So. legs are
not brige - call drops.

First of all, I found an issue https://issues.asterisk.org/view.php?id=15892. I
have updated libpri, but calls
are droping.
Then I'v found busydetect=yes option in chan_dahdi.conf for my E1 channel.
Set it to NO. Amount of call drops less then early. But still exist.

Today i'll try patch from https://issues.asterisk.org/view.php?id=7784 with
modification (set on ->owner). Is it
my situation?

I'll tell you results. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-21 10:26 c0rnoTa        Note Added: 0112540                          
======================================================================




More information about the asterisk-bugs mailing list