The same rule in the RFC covers the case where Session-Expires is sent, but no
refresher is sent as covers the case where no Session-Expires is sent at all,
as long as session timers are supported:
UAC supports? refresher parameter refresher parameter
in request in response
-------------------------------------------------------
Y none uas or uac
The definition of the refresher parameter in the request being none is: "there
was no refresher parameter in the request". There is no mention of
Session-Expires headers, and the table also uses "none" in this column for the
timers unsupported case, in which case Session-Expires would be invalid.
Asterisk does not allow uac (SESSION_TIMER_REFRESHER_THEM) to be set unless the
peer included a Session-Expires header. Whilst it is a local policy choice
which is sent, to me, this breaches the least surprise principle, and prevents
the use of a legal combination. Note, I don't actually have a production
environment use for this; I was using it to test a back port of the fix to the
bug that resulted in refresher being interpreted relative to the direction of
the original INVITE.
This is the relevant code in today's branch 13:
} else {
/* The UAC did not request session-timers. Asterisk (UAS),
will now decide
(based on session-timer-mode in sip.conf) whether to run
session-timers for
this session or not. */
switch (st_get_mode(p, 1)) {
case SESSION_TIMER_MODE_ORIGINATE:
st_active = TRUE;
st_interval = st_get_se(p, TRUE);
tmp_st_ref = SESSION_TIMER_REFRESHER_US;
p->stimer->st_active_peer_ua = (p->sipoptions &
SIP_OPT_TIMER) ? TRUE : FALSE;
break;
BTS Holdings PLC - Registered office: BTS House, Manor Road, Wallington, SM6
0DD - Registered in England: 1517630
--
_____________________________________________________________________
-- 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
