[asterisk-bugs] [Asterisk 0010479]: Registration/Un-Registration Problem with chan_skinny

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10479 
====================================================================== 
Reported By:                sbisker
Assigned To:                qwell
====================================================================== 
Project:                    Asterisk
Issue ID:                   10479
Category:                   Channels/chan_skinny
Reproducibility:            random
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:            1.4.10  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-17-2007 06:54 CDT
Last Modified:              11-15-2007 18:41 CST
====================================================================== 
Summary:                    Registration/Un-Registration Problem with
chan_skinny
Description: 
Having a problem with channels becoming partially unregistered.  This is
happening with 7920 and 7921 phones.  At some point during the day,
asterisk thinks that the  device becomes unregistered.  If you do a "skinny
show devices"  the device appears that it is registered, and the phone
screen indicates that it is registered.  However when making a call, the
following is in the log.


[Aug 16 09:46:14] VERBOSE[13870] logger.c:     -- Starting simple switch
on '5264 at 5264'
[Aug 16 09:46:15] DEBUG[12158] chan_skinny.c: Current sub
[Skinny/5264 at 5264-148] already has owner
[Aug 16 09:46:15] WARNING[13870] chan_skinny.c: Asked to transmit to a
non-existant session!
[Aug 16 09:46:15] NOTICE[13870] chan_skinny.c: Asked to indicate 'Stop
tone' condition on channel Skinny/5264 at 5264-148, but sessio
n does not exist.
[Aug 16 09:46:15] WARNING[13870] chan_skinny.c: Asked to transmit to a
non-existant session!
[Aug 16 09:46:15] NOTICE[13870] chan_skinny.c: Asked to indicate 'Stop
tone' condition on channel Skinny/5264 at 5264-148, but sessio
n does not exist.
[Aug 16 09:46:15] WARNING[13870] chan_skinny.c: Asked to transmit to a
non-existant session!
[Aug 16 09:46:15] NOTICE[13870] chan_skinny.c: Asked to indicate 'Stop
tone' condition on channel Skinny/5264 at 5264-148, but sessio
n does not exist.
[Aug 16 09:46:16] WARNING[13870] chan_skinny.c: Asked to transmit to a
non-existant session!
[Aug 16 09:46:16] VERBOSE[13870] logger.c:     -- Executing
[7848 at longdistance:1] Dial("Skinny/5264 at 5264-148",
"IAX2/isdpbx:password at isdpbx/7848||r") in new stack



If I do a "core show channels" no skinny sessions are shown, and no
channels are active for that device.  On a side note  can't do a "skinny
set debug" because asterisk crashes because the session doesn't exist, and
the debug code references session and not device.  I'll submit another bug
for this one too, if you want.
====================================================================== 

---------------------------------------------------------------------- 
 DEA - 11-15-07 18:41  
---------------------------------------------------------------------- 
And if the phone was unplugged, which results in the loss of registration?
Do we end up with Asterisk/chan_skinny spinning its wheels trying to
issue
an unregister message to a phone that no longer exists?

Sure we can code around that issue, but additional care is required.
We can also recommend tuning the keepAlive value to a smaller number
of seconds (most phones seem to honor it after the message structure
cleanup).  We could further rework the keepalive logic to request a
keepalive
message 1/2 the configured value and track the number of missed messages.
After two missed messages we then consider the phone gone.

The worst problem likely during the disruption is the phone is not
responsive.  The window is actually keepAlive time - time since last
keepAlive message.  Tuning the keepAlive value to a smaller number
of seconds will increase network traffic, albeit a trivial amount, but
does reduce recovery time. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-15-07 18:41  DEA            Note Added: 0073766                          
======================================================================