[asterisk-dev] ToDo for chan_skinny

[Dan Austin]

Pavel wrote:
> when I tested keepalive patch with other phone types, 
> I discovered, that:
> ci$co 7961 (and probably all never models 7941, 7911, 7921): 
> is not supported at all by chan_skinny, phone doesn't even 
> register ci$co 7912: when call rings-in, "End call" softkey 
> button is displayed, but doesn't working (firmware 8.0(3))

The code lists the device types for the 7911, 7941 and 7961,
so providing the numbers are correct they should work.  The 
7921 is not represented yet.

If we can get a packet capture of the devices trying to register,
we might be able to see why they are failing.  I have not yet
purchase any of the new models yet, so I have no way to try to
capture their registration attempts.


PJ





Dan Austin wrote:
> Damien wrote:
>   
>> Simon Lockhart wrote:
>>     
> <Snip>
>
>   
>>> I'm fairly certain that chan_skinny already replies 
>>> to Keepalive messages from the phone (otherwise it 
>>> wouldn't work at all).
>>>
>>> Th problem is that if the phone stops sending keepalives
>>> (i.e. it goes away), then chan_skinny doesn't notice and
>>> still tries sending calls to the now non-existent phone.
>>>
>>> Simon
>>>       
>>   
>>  My bad, it does too. Funny thing, it is one of the 
>> things that calls do_housekeeping, the others being 
>> hangups. So I guess you can't reliably use 
>> do_housekeeping to check if keepalives have been 
>> received as it relies on receiving keepalives for 
>> do_housekeeping to be called.
>>     
>
> All true.  The phone sends the keep-alive.  Chan_skinny
> responds.  It looked like it should go in do_housekeeping,
> but that won't work as it is not called unless it receives
> a keep-alive.
>
> But I believe I did find the issue.  In get_input() the
> code was using poll() with timeouts disabled.  Code to check
> for a dropped connection looked for a timeout, it was also
> in a section of code that was unlikely to be reached but
> not impossible.
>
> IF the phone dropped while sending a request, the current
> code would detect it and de-register the device.
>
> My fix was to add a timeout to the poll() call based on
> the configured keep_alive value +10% to handle network
> congestion, and to move the code that tested for timeouts
> into a code path that would regularly be reached.
>
> Light testing has been positive (I have one 7940 and one
> 7920).  Both have stayed registered overnight since I
> implemented the patch, and unplugging the network from the
> 7940 has it being de-registered in less than the 30 second
> keep_alive I used for testing.
>
> Dan
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>   
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev