[asterisk-bugs] [Asterisk 0010890]: When parking lot ring back times out, error is generated, line is hung up and timeout extension isn't reached.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10890 
====================================================================== 
Reported By:                kenw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10890
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.11  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             10-04-2007 18:28 CDT
Last Modified:              01-22-2008 15:29 CST
====================================================================== 
Summary:                    When parking lot ring back times out, error is
generated, line is hung up and timeout extension isn't reached.
Description: 
The situation is repeated as follows:

1. Call is placed into parking lot
2. Call timesout from parking lot and rings back extension that put it
there to begin with
3. After http://bugs.digium.com/view.php?id=8#50 seconds of ringing back to
extension that placed the call in
the parking lot, the [park-dial] 't' extension should be invoked, instead
the following errors show up in the Asterisk-CLI:

[Oct  4 17:22:47] WARNING[7986]: chan_sip.c:12037 handle_response_invite:
Re-invite to non-existing call leg on other UA. SIP dialog
'224fe567089888351edffad76cdf16d9 at 10.200.26.202'. Giving up.
[Oct  4 17:38:18] WARNING[7986]: chan_sip.c:12536 handle_response: Remote
host can't match request CANCEL to call
'4c93b03d7f87f05950d21bd971edd97b at 10.200.26.202'. Giving up.

I'm not sure if this is a parking lot or SIP issue, but beings the errors
are from chan_sip.c I chose SIP Transfers.

I've attached CLI with debug & verbose set to 4 as well as sip debug
enabled.  I've also attached the parts of features.conf, extensions.conf &
sip.conf that apply.  Problem was noticed in 1.4.10.1, upgrade to 1.4.12
made no difference.

(1.4.12 not an option on Asterisk version btw).
====================================================================== 

---------------------------------------------------------------------- 
 djrodman - 01-22-08 15:29  
---------------------------------------------------------------------- 
Aragon is correct on all points but this:
 - the suggested work-around does NOT require any source code changes,
does NOT result in the caller being disconnected, and makes it possible to
provide full functionality to Park(), including the ability to transfer the
call anywhere you want to send it.  All that is required is to add steps
(priorities) to the dialplan in the context to which these calls are being
sent by the existing code.

The suggested source code changes are not required in order to implement
this workaround.  They (a) reduce the timeout on recalled calls; and (b)
correct a different bug that prevents recalled calls from being parked
again.

You bet it would be better to follow the busy/no-answer logic on the
called-back extension, and it would be better to have an official fix.  No
question.

On the other hand, this workaround makes it possible to treat calls that
were abandoned on park differently from calls that are ringing the
extension for the first time.  In a customer service environment this might
be seen to be an improvement.  You can say "We're sorry you have been on
hold for so long" and offer options like leaving a message or ringing
trying a different extension, and so forth- options that only make sense
when the call has been stuck in park for a while.  Whatever the "official"
fix winds up being ought to take that flexibility into acocunt.  Perhaps
something as simple as setting a channel variable would do the trick.

In any case, the value of the current suggestion is that anyone who is
suffering from the problem at hand and who does not wish to modify the
source code can still work around the problem in a satisfactory way.  I
hope I have not suggested that this is anything more than a successful
workaround and if so I apologize. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-22-08 15:29  djrodman       Note Added: 0081046                          
======================================================================