ASTERISK-07290: Parked call timeout disconnects parked caller

[Home]

Summary: ASTERISK-07290: Parked call timeout disconnects parked caller

Reporter: alanj_29672 (alanj_29672) Labels:

Date Opened: 2006-07-05 14:02:59 Date Closed: 2006-08-09 10:07:03

Priority: Major Regression? No

Status: Closed/Complete Components: Resources/res_features

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments:

Description: When a parked call times out, asterisk attempts to reconnect the parked caller to the channel that parked the user. If that channel is busy, the parked caller is disconnected. We've had several callers disconnected because of this, and from looking through forums, etc. it seems that many others have as well.

Additionally, if the channel that parked the user is not picked up, it rings until the parked caller hangs up.

This is similar to bug ASTERISK-6896953, but I propose that even if asterisk reconnects to the channel that parked the user, there be an extension that the call falls through to before it is hung up on. ASTERISK-6896953 says that either the old strategy or the new one be used, I'm proposing that the new strategy be modified to fall through to the old strategy.

Comments: By: Clod Patry (junky) 2006-08-08 22:20:14

Could you elaborate more here that part "[...] there be an extension that the call falls through to before it is hung up on.", cause i'd like to write one patch for both ticket.

what about if after a park timeout, we direct the leg to a specific CEP? In that way, ya'll be able to stream something, to recall someone or whatever you want, since its the dialplan.
By: alanj_29672 (alanj_29672) 2006-08-09 07:41:51

That was kind of what I was thinking. Have a context that the call will fall through to that can be programmed to do whatever needs to be done. Would there need to be a variable available there to determine what extension the caller had originally been connected with?
By: Serge Vecher (serge-v) 2006-08-09 10:06:49

alright, there is no reason to open another bug report just to state a different opinion on something that is a feature request. 6953 is still open, so you can post your thoughts there. I'm closing this bug report at this point. Also, please remember, that:
1) The bug-tracker is not a good discussion forum, but a tool to collect bug reports and keep track of patches, with discussion centered around "code-discussion", less so "approach-discussion".
2) Since 6953 is still in early stages of code development, I would suggest emailing the asterisk-dev mailing list to get more exposure for that report and solicit feedback from a larger development community. Thanks.