[asterisk-bugs] [Asterisk 0009724]: SIP Transfers To Parking Lot From Grandstream GXP-2000 Locks Up SIP Channel

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9724 
====================================================================== 
Reported By:                kenw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   9724
Category:                   Channels/chan_sip/Transfers
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.4 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 63519 
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             05-14-2007 14:49 CDT
Last Modified:              07-30-2007 10:48 CDT
====================================================================== 
Summary:                    SIP Transfers To Parking Lot From Grandstream
GXP-2000 Locks Up SIP Channel
Description: 
Starting a couple of months ago about once a week Asterisk would stop
responding to our SIP phones.  This has increased slowly to 3-5 times a
day.  It's taken me a long time to (hopefully) narrow the problem down to
something I could report.  I've looked everywhere online for help and I
hope I didn't miss this being reported already.

I've been able to reproduce the problem with 1.4.1, 1.4.2, 1.4.4 & the
latest SVN as of last week (63519), the version doesn't seem to affect the
timing of the problem one way or another.

I've attached logs below including SIP Debug enabled, verbose & debug set
to 4.  I've also included a console log of the state of things when it
happens.  

We are using the TRNF button on the GXP-2000 phones to transfer to a
parking lot.  It seems to be a transfer to the parking lot that causes SIP
to stop responding, though I may be mistaken.  Asterisk appears fine but
all phones get 'no response from server' when the lock up occurs.

We've got 3 boxes at 3 locations, the other 2 are working fine, this one
is having fits, however, this box is also used 10x more then the other 2. 
Last week I removed all asterisk folders and reinstalled 1.4.4 but the
problem still occurs.

When the lockup occurs if I try to reload chan_sip I get no errors, if I
try to unload it I get the following:
[May 14 11:40:47] WARNING[6314]: loader.c:458 ast_unload_resource: Soft
unload failed, 'chan_sip.so' has use count 32

The server is running CentOS 4.4, has two TDM-400p cards with 6 FXS & 2
FXO cards.


====================================================================== 

---------------------------------------------------------------------- 
 kenw - 07-30-07 10:48  
---------------------------------------------------------------------- 
Well, the problem was a modification I was making to the parking lot
transfers (go figure).  Why or how I never thought of this before last week
is beyond me (thus the embarassed & ashamed part).

When we put someone on hold, the way I have the phones setup we don't care
which parking lot extension they get transferred to, not to mention the way
the Grandstream phones do the TRNF you don't get to here the parking lot
extension play back anyway.  All it does on Grandstream phones is take 2-3
seconds to put a call on hold, which is a bit annoying.  So, I had found
the source for SAY_DIGITS and remarked it out.  Specifically line 426 in
the 1.4.6 version of res_features.c.  

        if (peer && pu->parkingnum != -1) /* Only say number if it's a
number */
                ast_say_digits(peer, pu->parkingnum, "", peer->language);

Apparently taking this delay to say the digits out randomly causes a
channel lockup.  I'd like to remark this out so our transfers are instant,
but for now we're living with the longer transfer for the sake of a phone
system that doesn't randomly lock.

So, any thoughts?  Should I open a new request ticket?

(BTW, server up time 5 days on 1.4.6, never happen in the 1.4.x before.) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-30-07 10:48  kenw           Note Added: 0068060                          
======================================================================