[asterisk-bugs] [JIRA] (ASTERISK-21410) Park() application never returns in some cases
Jonathan Rose (JIRA)
noreply at issues.asterisk.org
Thu Apr 11 13:08:01 CDT 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-21410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=205224#comment-205224 ]
Jonathan Rose edited comment on ASTERISK-21410 at 4/11/13 1:07 PM:
-------------------------------------------------------------------
This doesn't show that Park isn't returning. This only demonstrates that the call that was parked isn't proceeding in the dial plan, and this is expected behavior. If you hangup while an application is running, then on returning from the application when the your call will get sent to to h extension if it exists. It doesn't go on to the next priority. That's standard behavior for most things. From there you can perform your various NoOp messages (or maybe something less trivial, I don't know, whatever floats your boat). If you want a little more control than that, you should consider looking into a new feature for Asterisk 11 called hangup handlers which you can read more about here: https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers
Generally speaking, you should look at Park as a terminal extension. Under normal circumstances, the parkee will either stay in the parking space until it times out and then does the usual comeback stuff (which will always involve going to a different extension) or else the parkedcall application will be used to retrieve it and from there you basically (not quite, just basically. The internals of this are weird in current implementations of parking) have a Dial from the retriever to the parkee (ex-parkee at this point, but you get the idea). If I'm not mistaken about how it works, the parkee will no longer actually be in the PBX at this point and the retriever will essentially own the call, even if the original dial that resulted in the park in the first place belonged to the parkee.
was (Author: jrose):
This doesn't show that Park isn't returning. This only demonstrates that the call that was parked isn't proceeding in the dial plan, and this is expected behavior. If you hangup, you get sent to to h extension if it exists. That's standard behavior for most things. From there you can peform your various NoOp messages (or maybe something less trivial, I don't know, whatever floats your boat). If you want a little more control than that, you should consider looking into a new feature for Asterisk 11 called hangup handlers which you can read more about here: https://wiki.asterisk.org/wiki/display/AST/Hangup+Handlers
Generally speaking, you should look at Park as a terminal extension. Under normal circumstances, the parkee will either stay in the parking space until it times out and then does the usual comeback stuff (which will always involve going to a different extension) or else the parkedcall application will be used to retrieve it and from there you basically (not quite, just basically. The internals of this are weird in current implementations of parking) have a Dial from the retriever to the parkee (ex-parkee at this point, but you get the idea). If I'm not mistaken about how it works, the parkee will no longer actually be in the PBX at this point and the retriever will essentially own the call, even if the original dial that resulted in the park in the first place belonged to the parkee.
> Park() application never returns in some cases
> ----------------------------------------------
>
> Key: ASTERISK-21410
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-21410
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Affects Versions: 1.8.15.0
> Environment: CentOS 5.5 2.6.18-308.13.1.e15 x86_64
> Reporter: Red
>
> In my setup, I manually manage call parking and unparking. This requires bookkeeping to be done in the priorities that immediately _follow_ the actual call to the Park() application. However, under no circumstances are those priorities ever executed.
> If the parking spot times out, Park correctly routes to the timeout context. However, if a timeout is neither reached nor is the call unparked the Park NEVER returns. An example of this is A calls B, B parks A, A hangs up before timeout.
> The following dialplan code is an example:
> {noformat}
> [call-park]
> ;***
> ; NOTES
> ; This context manages parking of calls and
> ; access to the parking lot.
> ;***
> include => parkedcalls ;none of the features.conf stuff seems to work so this isn't really necessary
> exten => _700, 1, NoOp(=-=-=- ${EXTEN}@${CONTEXT} -=-=-=)
> ;Check out a free parking spot and associate it
> ; with a given account, then park it:
> exten => _700, n, Set(PARKINGEXTEN=${VOIP_GetAvailableParkingSpot()})
> exten => _700, n, Set(VOIP_DeleteAvailableParkingSpot(${PARKINGEXTEN})=)
> exten => _700, n, Set(VOIP_AddParkedCall(${PARKINGEXTEN},${HASH(account,id)})=)
> ; Here is where the problem is:
> exten => _700, n, Park(45000,call-park-timeout,${PARKINGEXTEN},1,,)
> exten => _700, n, NoOp(Nothing after the above park ever gets run.)
> exten => _700, n, NoOp(Either the timeout context is routed to)
> exten => _700, n, NoOp(or Park() flakes out and never returns. Bug?!)
> exten => _700, n, Hangup()
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list