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
_______________________________________________
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
