[Asterisk-Dev] SIP channels not cleared

[John Todd]

At 11:33 AM +0200 on 8/21/05, Olle E. Johansson wrote:
>John Todd wrote:
>>  At 7:06 AM +0200 on 8/19/05, Olle E. Johansson wrote:
>>
>>>  Chee Foong wrote:
>>>
>>>>   OK, I under stand.
>>>>   So, can this be considered a bug in asterisk?
>>>>   Since it knows how to response to a BYE, it should also know it's
>>>>  time to
>>>>   clear the channel.
>>>
>>>
>>>  The real fault here is that the other end issues a BYE when we have no
>>>  session set up by
>>>  INVITE/200 OK/ACK - to cancel a pending INVITE you use CANCEL, not BYE.
>>>  That is a bug, please ask your vendor to look up CANCEL in the SIP rfc.
>>>
>>>  And yes, we should be able to handle faulty devices better, but will
>>>  concentrate our energy on being able to improve the way we handle
>>>  devices that actually support basic SIP according to the standard. ;-)
>>>
>>>  /Olle
>>
>>
>>
>>  This problem could perhaps could be resolved by implementation of
>>  session-timers on the Asterisk side, assuming that the UAC also
>>  supported (or at least did not crash on) such timers.
>>
>>  http://www.faqs.org/rfcs/rfc4028.html
>>
>>  If Asterisk sent re-INVITEs after the Session-Expires: duration, then it
>>  (Asterisk) could close channels which did not respond.  I would think
>>  that this would be something that could be set on a per-peer basis or
>>  globally.
>>
>>  I believe my previous tests with Asterisk showed that Asterisk supported
>>  Session-Expires: in a non-harmful way (i.e.: did not crash) but Asterisk
>>  did not seem to have any "hooks" for generating a Session-Expires:
>>  header or creation of timers.  Does anyone have any alternate
>>  information?  It's been a year or so since I experimented with equipment
>>  using session-timers.
>>
>...and you haven't seen my bug report with a patch for SIP timers
>either? Not session timers, but as a starting point an implementation of
>the standard T1 timer for retransmits. When that is done, SIP timers
>would not be a bad thing to add.
>
>/O

Actually, I've been running your patch for about a week, and I've 
just re-patched with CVS-HEAD.  (One chunk fails, but it's an easy 
fix.)

Session-timers would be an excellent thing to add, as they will 
eliminate many of the "phantom channel" problems people have.  At the 
same time, it should be noted that not all equipment handles 
session-timers correctly, so an optional per-peer flag should be 
available as well as the global value.

Perhaps something like:

session-timer=[<seconds>,[yes/no/always]]
min-session-timer=<seconds>
max-session-timer=<seconds>

If session-timer=yes, then accept whatever the other end puts as the 
session-timer as long as it meets min-session-timer and 
max-session-timer.  If "no", then don't accept a session-timer.  (Is 
this worth having?)   If session-timer=always then the session should 
be refused unless a session-timer agreement can be made.

Sound like a reasonable set of values?  Then, it's just a simple 
matter of giving coffee to a programmer and having them do it!  ;-)

JT