[Home]

Summary:ASTERISK-28241: Call pickup fails, if dialed from subroutine, but succeeds with macro
Reporter:Hans-Peter Jansen (frispete)Labels:pjsip
Date Opened:2019-01-12 10:39:05.000-0600Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:Applications/app_directed_pickup Applications/app_stack
Versions:16.1.0 16.1.1 Frequency of
Occurrence
Constant
Related
Issues:
Environment:Attachments:
Description:if the extension is dialed from a subroutine, call pickup fails. It succeeds, if extension is dialed from a macro.

Details:

Since Asterisk 16, macros are deprecated. After rewriting my dialplan to
eliminate macros, call pickups were defective, which has gone unnoticed for
some time. Looking at my git logs (yes, I'm managing my asterisk config with
git), the only relevant change was moving from macros to subroutines.

Here are the relevant dialplan excerpts:
{noformat}
[extension]
; dial internal extension
; ${ARG1}: extension
exten = start,1,NoOp()
same = n,Dial(${ARG1},30)
same = n,Hangup()


[macro-extension]
; dial internal extension macro
; ${ARG1}: extensions to dial
exten = s,1,NoOp()
same = n,Dial(${ARG1},30)
same = n,Hangup()


[phones]
; OK:
exten = 123,1,Macro(extension,${TEL123})

[2019-01-12 16:37:12] NOTICE[5013][C-00000002]: app_directed_pickup.c:250
pickup_by_exten: SIP/00041323bbf7-00000001 pickup by SIP/00041323463e-00000002

; FAIL:
exten = 123,1,GoSub(extension,start,1(${TEL123}))

[2019-01-12 16:37:56] NOTICE[5096][C-00000002]: app_directed_pickup.c:365
pickup_exec: No target channel found for 123@internal
{noformat}

Any idea, what could affect this? It looks, like the subroutine Dial() call
disrupt the channel contexts somehow.
Comments:By: Asterisk Team (asteriskteam) 2019-01-12 10:39:06.329-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

By: Richard Mudgett (rmudgett) 2019-01-13 13:06:42.539-0600

We'd need a log to be sure of exactly what is happening.  However, based on the scant information you have provided, I do not think this is a bug.  It is how you have written your dialplan.  Gosub is not exactly the same thing as macro and cannot be treated as such.  When you do a gosub, you goto the new location in dialplan so the context, extension, and priority change to the target dialplan location.  Thus in your case the gosub changes the context to 'extension', the extension to 'start', and the priority to '1' and executes dialplan from there so of course you have no calls that are at 123@internal because they are all at start@extension.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Gosub

By: Hans-Peter Jansen (frispete) 2019-01-13 14:33:53.772-0600

Thanks Richard, for your answer.

Please note, that the call pickup got broken implicitly. Asterisk just forces users to migrate their dialplan to use GoSub without giving a warning about the things, that may break from that move (not even in documentation). GoSub just says: Jumps to the label specified, saving the return address. Comparing with Macro documentation, it's not possible to foresee these implications.

This raises the question, what other things may broke implicitly?


By: Kevin Harwell (kharwell) 2019-01-15 11:56:12.203-0600

The behavior is different between the two. However, this is because the call pickup matches against the context and extension, and also against the macro context and macro extension. In the application macro case it sets the macro context/exten accordingly and is able to match. In the application gosub case those values on the channel are not set, so it won't match.

I'm going to open this as it sounds like a bug, but at the very least could use further investigation and for sure better documentation (if that's all the comes of this issue).

In the meantime you can use the PICKUPMARK variable and functionality in call pick up as a work around. If you want it to answer the outbound ringing channel though you'll need to use a pre-dial handler to set the variable on the outbound channel. For instance, the below example works when called by both the macro or gosub application:
{noformat}
[globals]
TECH=PJSIP

[macro-extension]
exten => predial_outbound,1,NoOp()
   same => n,Set(PICKUPMARK=${ARG1})
   same => n,Return()

exten => s,1,NoOp()
   same => n,Dial(${TECH}/${ARG1},30,b(macro-extension^predial_outbound^1(${ARG1})))
   same => n,Hangup()

[default]
exten => 101,1,NoOp()
   same => n,Macro(extension,${EXTEN})
   same => n,Hangup()

exten => 102,1,NoOp()
   same => n,GoSub(macro-extension,s,1(${EXTEN}))
   same => n,Hangup()

exten => 201,1,NoOp()
   same => n,Pickup(101@PICKUPMARK)
   same => n,Hangup()

exten => 202,1,NoOp()
   same => n,Pickup(102@PICKUPMARK)
   same => n,Hangup()
{noformat}

By: Kevin Harwell (kharwell) 2019-01-15 12:51:29.041-0600

Actually here is another alternative way to also get what you want just using gosub:
{noformat}
[globals]
TECH=PJSIP

[extension]
exten => _X.,1,NoOp()
   same => n,Dial(${TECH}/${ARG1},30)
   same => n,Hangup()

[default]
exten => _1XX,1,NoOp()
   same => n,GoSub(extension,${EXTEN},1(${EXTEN}))
   same => n,Hangup()

exten => 200,1,NoOp()
   same => n,Pickup(101)
   same => n,Hangup()
{noformat}
Note here however, at least with chan_pjsip (not sure about chan_sip) the context needs to match context specified on the dialed endpoint. In this case it is "default" (i.e. pjsip endpoint configuration option on endpoint 101 has _context_=default)