[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 17:51 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 17:51  
---------------------------------------------------------------------- 
Well, yes we will hear about it and the phone will become
unregistered in Asterisk.  But for some reason the phone
itself still thinks that it is registered.

We could send the unregister, and then the phone SHOULD do
the right thing and re-register.  On the other hand if we
are getting keepAlive packets from a phone that we do not
see is registered, why not just register it?  The phone
clearly thinks it is registered to us, and we have a valid
session (otherwise we would not be getting the keepAlive
messages), so the least amount of work would seem to be
to re-register.

If the opinions are strong in favor of forcing an
unregister/register cycle, I'll rework the patch to do it
that way. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-15-07 17:51  DEA            Note Added: 0073760                          
======================================================================