[asterisk-dev] SIP session-timers: concept, discussion
John Todd
jtodd at loligo.com
Mon Sep 10 13:06:49 CDT 2007
As a follow-up to this thread:
Via funding generously donated by ntegratedsolutions.com (JR
Richardson) and TalkPlus (me) we have contracted to have the
Session-Timer features added to Asterisk. It is a limited method,
and uses only the re-INVITE method of timer activation, but that
should be sufficient and Asterisk doesn't support NOTICE methods at
this point.
I would appreciate it if others who need this feature could test the
implementation so that it can be included in TRUNK soon, before the
patches get stale. There have already been extensive tests by the
developer and by myself, so it should be ready to go into TRUNK right
now, but additional testing by others wouldn't hurt.
http://bugs.digium.com/view.php?id=10665
JT
At 4:20 PM -0700 2007/7/17, John Todd wrote:
>
>The issue of SIP session-timers has been raised before, and I'd like
>to start a discussion here if there is any interest in implementing
>this in Asterisk, and to solicit anyone who might think that they
>would be up to the task of coding such a useful extension to the code.
>
>In short: session-timers are described in RFC4028
>(http://www.ietf.org/rfc/rfc4028.txt) and provide a method by which
>two SIP entities can periodically verify with each other that
>sessions are still valid. This avoids "zombie" calls that are costly
>from both a real sense (price paid to carriers or by customers) and
>from a customer service sense ("My bill shows a three hour call that
>I know was only 10 minutes long!")
>
>In my experiences, Asterisk has a nasty (and frequent) habit of
>hanging SIP sessions due to internal inconsistencies which are
>difficult to track down. A worse condition arises when a network
>becomes disconnected, and particularly stupid equipment doesn't
>notice that RTP stops in one direction(1). (This brings up an
>interesting side note: I haven't tested it, but does Asterisk
>interpret a certain volume of ICMP unreachables on a particular RTP
>destination as evidence of a failed call?) When a software or
>network failure causes one end of a SIP session to terminate without
>a BYE, it often is the case that a call will be "stuck" and never
>will be hung up. In every large-scale instance of Asterisk that I've
>run, this has been a constant problem. I've tried solving it with a
>large number of external "reapers" that use the manager interface,
>I've used RTP timeouts to try to detect failed calls (this doesn't
>work where there is no media), and I've used absolute timers to limit
>risk exposure. None of these are particularly good solutions.
>
>The best solution I've seen suggested (but not implemented in
>Asterisk) is the use of the Session-Expires: header and related
>configuration options. This allows SIP devices to agree on an
>interval in which they will re-confirm the existence of a session.
>This can be done with a RE-INVITE to the same parameters, or it can
>be done with an UPDATE. Either way, it sends a "I'm here - I'm
>alive!" message that is expected between the two end "devices" in the
>communication. If, after the timer expires, there has been no update
>or re-INVITE, then each side knows that the other has somehow
>died/gone away, and the call is hopefully terminated. Even in the
>cases where this is only supported by one side (the Asterisk side) it
>will still make it possible to determine that a particular session
>has failed, which would hopefully start to cut down on the number of
>calls that get zombied due to network or other problems.
>
>I would be thrilled to see that for each SIP peer (or better yet,
>specifiable from within the Dialplan, but I won't get too greedy) the
>ability to specify how Asterisk can originate calls with Session
>Timers, or could accept calls with Session Timer requests. I've
>outlined what my ideal configuration options would be in the sip.conf
>snippet below. My company would be willing to pay some reasonable
>amount of dollars towards getting this implemented as an "assist" to
>a developer (but probably not a full funding.)
>
>Note that this would also introduce a new error handling routine (to
>manage "422 Session Interval Too Small") in response to remote
>systems that didn't like the timer indicated in the INVITE when calls
>were originated from Asterisk.
>
>(1) So why not just use the RTP detection routines in Asterisk? Two
>reasons come to mind immediately, but there may be more. Firstly:
>often, RTP is not travelling through the Asterisk server that is
>responsible for the call setup, and forcing RTP through that server
>may be impractical or impossible. Secondly, Session-Timers (can)
>work on the equipment at both ends of a call so any disconnection
>[can|will] cause both ends to hang up. The RTP timers in Asterisk
>are great for closing out the call on the Asterisk system, but in the
>case of a network failure (without Session-Timers) it may be the case
>that the non-Asterisk side may continue the call "forever", which is
>typically a big problem when there are charges for call minutes.
>
>JT
>
>
>
>imaginary sip.conf snippet for session-Timers:
>
>;
>; Session-Expires (aka: Session Timers)
>;
>; Session-Expires headers may be used to create RE-INVITE or UPDATE sessions
>; periodically so that SIP calls do not get 'hung' infinitely in the case
>; of a network outage, device crash, NAT timeout, or other problem which
>; would prevent a correct BYE from being sent. Care should be taken not to
>; set these values too low, as the additional SIP traffic may utilize
>; additional system and/or network resources. This method may work even if
>; only one side of the call implements Session Timers, though of course any
>; side which does not support the Session-Expires headers may become 'hung'
>; in an open call state. To activate Session Timers, set the
>; 'session-expires' value to "originate" and you can probably leave the rest
>; of the values alone.
>;
>; session-expires=["accept", "originate", "refuse"] - The default is "accept".
>;
>; This describes what this Asterisk server will do in relation to
>; Session-Expires headers.
>; accept = accept Session-Expires requests from remote UAs, and apply
>; the values described below in accepting the timer request.
>; originate = originate Session-Expires on any INVITEs to this peer,
>; using the values below. If "originate" is selected, it is
>; implied that this Asterisk instance will also accept
>; Session-Expires headers.
>; refuse = Do not respond to Session-Expires headers, but continue the
>; INVITE processing. In other words: act dumb.
>;
>;
>; session-time=[integer] - This is the time that will be presented in the
>; Session-Expires: header on a call that is originated by this
>Asterisk system.
>; The default if unspecified is 1800, and cannot be lower than 90.
>;
>; session-minse=[integer] - This is the lower bound for a received
>; Session-Expires header. The default if unspecified is 1800, and cannot be
>; lower than 90. If a Session-Expires header is received that is below this
>; time, it will be refused with a 422 error ("Session Interval Too
>Small") and
>; this value will be handed back as the "Min-SE:" header.
>;
>; session-type=["uas", "uac", "auto"] - Forces sending the
>refresher parameter to
>; "uac" or "uas". Expert use only; forcing this setting may cause
>all calls to
>; time out incorrectly. Default is "auto".
>;
>; session-method=["update","reinvite", "auto"] - Use either a re-INVITE or an
>; UPDATE at the end of the timer cycle. Default is "auto". Some
>equipment may
>; not understand "UPDATE" methods, and may only respond correctly
>to re-INVITEs
>; with the same Call-ID value. If set to "auto", then the system
>will function
>; as follows: during the initial INVITE, the presence of "UPDATE"
>in the Allow:
>; field should dictate the use of "update" for that session, otherwise
>; "reinvite" is used.
>;
>
>_______________________________________________
>--Bandwidth and Colocation Provided by http://www.api-digital.com--
>
>asterisk-dev mailing list
>To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-dev
mailing list