[asterisk-bugs] [Asterisk 0014457]: Blind transfer uses the wrong context when blind transffering, combined with 'h' extension.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14457 
====================================================================== 
Reported By:                e-tsik
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14457
Category:                   Channels/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 174644 
Request Review:              
====================================================================== 
Date Submitted:             2009-02-11 09:51 CST
Last Modified:              2009-02-12 16:58 CST
====================================================================== 
Summary:                    Blind transfer uses the wrong context when blind
transffering, combined with 'h' extension.
Description: 
Hello

As with 0013978, I blind-transferring results in invalid contexts, and I
also use the Macro command in conjunction with the 'h' extension.
The 'h' extension is used in the calling context - in my instance
'internal_p1'. What the 'h' extension does is
- Check for a variable's presence
- On a false condition - makes a goto to a certain function (calls a URL,
actually irrelevant to this bug because it never gets called) and hangs up
- On a true condition - Makes a goto to hangup|features_p1|1 . I use a
goto because it makes it easier to call from a GotoIf (there isn't a
HangUpIf).

Example how I reproduce it is under "Additional Information".
Also note that this is reproducible both by using the phone's (tecom
IP2008) transfer button or by using the "##" sequence.
====================================================================== 

---------------------------------------------------------------------- 
 (0100071) e-tsik (reporter) - 2009-02-12 16:58
 http://bugs.digium.com/view.php?id=14457#c100071 
---------------------------------------------------------------------- 
exten => h,1,Goto(21)
exten => h,21,GotoIf($["${APITAG}"=""]?features_p1|func-hangup|1)
exten => h,22,Goto(hangup|${APITAG}|1)

In my example, I took a call from trunk SIP/10.0.0.5 to 11106 and
transferred it to 107

This log looks OK
    -- Stopped music on hold on SIP/10.0.0.5-08345748
    -- Executing [h at internal_p1:1] Goto("SIP/10.0.0.5-08345748", "21") in
new stack
    -- Goto (internal_p1,h,21)
    -- Executing [h at internal_p1:21] GotoIf("SIP/10.0.0.5-08345748",
"1?features_p1|hangup|1") in new stack
    -- Goto (features_p1,hangup,1)

I understand this is the call between the phone behind 10.0.0.5 and 106
that got disconnected while 106 is reinveted to 107
Here is where the problem starts:

  == Spawn extension (features_p1, 107, 0) exited non-zero on
'SIP/10.0.0.5-08345748' in macro 'dial_ext_int'
  == Spawn extension (features_p1, 107, 0) exited non-zero on
'SIP/10.0.0.5-08345748'
[Feb 11 17:45:15] WARNING[26238]: pbx.c:2473 __ast_pbx_run: Channel
'SIP/10.0.0.5-08345748' sent into invalid extension '107' in context
'features_p1', but no invalid handler

The new call is not supposed to originate from "features_p1" - but from
internal_p1. When I changed to goto command in h,21 to jump to
internal_p1|func-hangup|1 - the problem was resolved because the new call
from 10.0.0.5 to 107 was originated from internal_p1. 

If we refer to the terminated call to 106 as call A and the new call to
107 as call B, then I would expect call B to originate from internal_p1
(the same place where the macro was called, and the sip.conf context of the
transferring extension) regardless of where call A was terminated. Call A
was terminated at a context I used to write a special handler integrating
the PBX with the customer service system.

Hope that clarifies it. The actual dial script is rather complex but I
really think (and the logs might say so also) that everything happens
outside the dial script, in the calling context "internal_p1" 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-12 16:58 e-tsik         Note Added: 0100071                          
======================================================================