[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:                     feedback
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:              10-30-2007 15:08 CDT
====================================================================== 
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).
====================================================================== 

---------------------------------------------------------------------- 
 jharragi - 10-30-07 15:08  
---------------------------------------------------------------------- 
I've been getting a related error. I am merely reporting my observations.
If I get an opportunity to collect better cli output I will. Unfortunatly,
this would not be a good machine to compile debug & get a core dump.

[Oct 30 13:14:50] WARNING[3917] chan_sip.c: Remote host can't match
request BYE to call '1ca86cc074fbe2ba2fee44ee7f736bb6 at 10.0.9.7'. Giving
up.

...the condition that generated this repeated message had an interesting
sideffect. A user reported that her cisco 7912 couldn't make calls. I was
testing it by calling my cell phone from the 7912. Before during and after
ringing, choppy audio (but recognisable as a menu recording from a
different asterisk box at another of my buildings) was playing on the 7912.
My connection was crap but did pass some additional audio. After a few of
these calls - which I teminated by hanging up the cell I noticed that
occationally the 7912 stayed off the hook - so I left it that way. I went
to the CLI and saw that the 7912 was now bridged to a ZAP channel. I tried
a soft hangup on the zap channel and it was now working properly with no
WARNING being generated. So it appears that some unholy union between
channels can occur when this message is present.

Note 10.0.9.7 is the server hosting the 7912. On other occations, the
channel listed in the WARNING message may relate to an ip-phone. If that is
the case, rebooting the assosiated phone also causes the repeated WARNING
to cease. I suppose the re-registration process clears the wierd channel on
the asterisk server.

This was observed on a production box running 1.4.11 - recently upgraded
from 1.2.? (with 1.2 the warning was not occuring). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
10-30-07 15:08  jharragi       Note Added: 0072764                          
======================================================================