[Home]

Summary:ASTERISK-13562: Blind transfer uses the wrong context when blind transffering, combined with 'h' extension.
Reporter:Isaac Aaron (e-tsik)Labels:
Date Opened:2009-02-11 09:51:57.000-0600Date Closed:2011-06-07 14:02:55
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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.

****** ADDITIONAL INFORMATION ******

Dialing the Extension from Macro

  -- Goto (macro-dial_ext_int,s,230)
   -- Executing [s@macro-dial_ext_int:230] Ringing("SIP/10.0.0.5-08345748", "") in new stack
   -- Executing [s@macro-dial_ext_int:231] Set("SIP/10.0.0.5-08345748", "__DYNAMIC_FEATURES=monitor_callee") in new stack
   -- Executing [s@macro-dial_ext_int:232] Dial("SIP/10.0.0.5-08345748", "SIP/11106|30|mt") in new stack
   -- Called 11106
   -- Started music on hold, class 'moh_1', on SIP/10.0.0.5-08345748
   -- SIP/11106-08390ad8 is ringing
   -- SIP/11106-08390ad8 answered SIP/10.0.0.5-08345748
   -- Stopped music on hold on SIP/10.0.0.5-08345748


Transfer Button Pushed
   -- Started music on hold, class 'moh_1', on SIP/10.0.0.5-08345748

After transferring

   -- Stopped music on hold on SIP/10.0.0.5-08345748
   -- Executing [h@internal_p1:1] Goto("SIP/10.0.0.5-08345748", "21") in new stack
   -- Goto (internal_p1,h,21)
   -- Executing [h@internal_p1:21] GotoIf("SIP/10.0.0.5-08345748", "1?features_p1|hangup|1") in new stack
   -- Goto (features_p1,hangup,1)
 == 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
Comments:By: Isaac Aaron (e-tsik) 2009-02-11 10:44:26.000-0600

I have found a workaround for this issue -
Since the new channel's context starts where the 'h' ended, I have moved the 'hangup' target that was on 'features_p1' to 'internal_p1' - where I want the transferred call to originate.
I guess this workaround is suitable for everyone who is impacted from this issue since the Goto out of the context actually causes the problem.


By: Joshua C. Colp (jcolp) 2009-02-12 12:53:17.000-0600

I'm rather confused over this bug report. Can you provide the actual dialplan being used and what you expect to happen?
By: Isaac Aaron (e-tsik) 2009-02-12 16:58:22.000-0600

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@internal_p1:1] Goto("SIP/10.0.0.5-08345748", "21") in new stack
   -- Goto (internal_p1,h,21)
   -- Executing [h@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"
By: Isaac Aaron (e-tsik) 2009-03-03 04:14:36.000-0600

I have discovered something else that may shed light on the issue.
It seems that blind transfer always begins the new call from the same context of the transferred call. The user would expect the transferred call to begin from the transferring user's context, because users dial extension codes relative to their extension.

Example:
An incoming call to the DID context hits a target that calls Dial() to an extension. The call is now in a did context.
A user bind-transfers the call to another extension using an extension number, but the did context only contains full inbound numbers, so the call either reaches the 'i' extension or drops.
By: Joshua C. Colp (jcolp) 2009-03-04 09:08:51.000-0600

This is the way the code is written to work. Channels have no concept of what the context that should be used for transfers should be EXCEPT for the TRANSFER_CONTEXT dialplan variable. It was put there for this reason and can be used in your situation to control what context to use.