[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-20-2008 17:35 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-20-08 17:35  
---------------------------------------------------------------------- 
Thanks kenw for identifying the internally-created context "park-dial" -
that has enabled me to fix this for our multi-company installation.  Three
notes:
1 - the dial temeout really ought to be a parameter in features.conf -
it's easy enough to add another one for those so inclined.
2 - In modifying that line in res_features.c, the arguments to the Dial
application should include 'k' so that in case the call is answered, it can
be parked again.  Without that 'k', a call can only be parked once. So ..

   snprintf(returnexten, sizeof(returnexten), "%s|45|kt", peername);

(or replace the 45 with your parameter if you make one)

3 - Exported channel variables (i.e. those originally defined with a
leading '__' are copied to the new channel - therefore they are available
in the park-dial steps.  For those of us with more than one company in the
dial plan, this means we can transfer back to the original context.  I have
a variable __COMPANY set to the original context in which the call arrived.
 All companies in my setup have a "dial 0 for operator" extension
configured.  So, this is working great for me:

[park-dial]
exten => _SIP.,2,Goto(${COMPANY}|0|1)

Thanks again!  One more red block turns green! 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-20-08 17:35  djrodman       Note Added: 0080920                          
======================================================================