[asterisk-bugs] [Asterisk 0018185]: Blind transfer failure, A calls B, B transfers to C
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Oct 22 20:35:00 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18185
======================================================================
Reported By: kwemheuer
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18185
Category: Channels/chan_sip/Transfers
Reproducibility: always
Severity: major
Priority: normal
Status: feedback
Asterisk Version: 1.8.0
JIRA:
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-10-22 04:43 CDT
Last Modified: 2010-10-22 20:35 CDT
======================================================================
Summary: Blind transfer failure, A calls B, B transfers to C
Description:
The summary says it: Transfers are not working in one direction. In
detail:
I set up an asterisk system (version 1.8.0). While using a SIP only
environment I discovered a problem using blind transfer. The phones are
SNOM or Aastra and are using the SIP REFER Method.
For debugging purposes I stripped down the environment to a simple
dialplan with only three extensions. There are three phones (Snom)
registered to asterisk. I use release 1.8.0 from yesterday.
There are three extensions: 100, 150, and 180. There are three
SIP-Devices: phone1, phone2, and phone3. (See extensions.conf, sip.conf)
User on phone1 dials 150 (phone2). User on phone2 transfers the call to
phone3 (using blind transfer, SIP REFER Method). The calls fails (See debug
output in file failed.log)
The following scenario is working: User on phone1 dials 150 (phone2). User
on phone1 transfers the call to phone3 (using blind transfer, SIP REFER
Method). See debug output in file working.log.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0018192 Call dropped on SIP REFER in 1.8.0
======================================================================
----------------------------------------------------------------------
(0128348) rsw686 (reporter) - 2010-10-22 20:35
https://issues.asterisk.org/view.php?id=18185#c128348
----------------------------------------------------------------------
I'm seeing the same issue with SIP REFER transfers where the call is hung
up. After switching back to 1.6.2.11 from 1.8 with the same config the
problem goes away.
On both 1.6.2.11 and 1.8 with FreePBX the log shows
[Oct 22 18:42:53] VERBOSE[20889] pbx.c: -- Executing
[s at macro-hangupcall:9] Hangup("SIP/1050-0000000c", "") in new stack
[Oct 22 18:42:53] VERBOSE[20889] app_macro.c: == Spawn extension
(macro-hangupcall, s, 9) exited non-zero on 'SIP/1050-0000000c' in macro
'hangupcall'
[Oct 22 18:42:53] VERBOSE[20889] app_macro.c: == Spawn extension
(from-internal-xfer, 2001, 1) exited non-zero on 'SIP/1050-0000000c' in
macro 'dialout-trunk'
[Oct 22 18:42:53] VERBOSE[20889] pbx.c: == Spawn extension
(from-internal-xfer, 2001, 1) exited non-zero on 'SIP/1050-0000000c'
At this point 1.8 drops the call and nothing more is shown in the log.
1.6.2.11 continues with
[Oct 22 19:01:35] VERBOSE[24071] pbx.c: -- Executing
[2001 at from-internal-xfer:1] Macro("SIP/1050-00000000",
"exten-vm,2001,2001") in new stack
[Oct 22 19:01:35] VERBOSE[24071] pbx.c: -- Executing
[s at macro-exten-vm:1] Macro("SIP/1050-00000000", "user-callerid,") in new
stack
[Oct 22 19:01:35] VERBOSE[24071] pbx.c: -- Executing
[s at macro-user-callerid:1] Set("SIP/1050-00000000", "AMPUSER=2000") in new
stack
Issue History
Date Modified Username Field Change
======================================================================
2010-10-22 20:35 rsw686 Note Added: 0128348
======================================================================
More information about the asterisk-bugs
mailing list