[asterisk-dev] pjsip and timers configuration

Joshua C. Colp jcolp at sangoma.com
Tue Sep 8 04:41:58 CDT 2020

On Sat, Sep 5, 2020 at 6:18 PM Michael Maier <m1278468 at mailbox.org> wrote:

> Hello all,
> according [1], there are those options in pjsip regarding support of
> timers:
> _______________________________________________________________
> timers
>     no
>     yes
>     required
>     always
>     forced - Alias of always
> _______________________________________________________________
Timers support is 100% PJSIP[1][2], so my own experience with it and the
implementation is extremely limited - as will likely be the rest of people.

> I'm wondering about their meanings.
> - "No" seems to be clear. No timers support at all.
> - "Always"? I have no idea. Therefore I tested it. I couldn't find any
> timers support mentioned in INVITE or 200 OK at all.
> - "Required"? Same as "yes" - the only difference was the timer:require in
> asterisk's outbound Invite.
> Is this the expected behavior, especially regarding "always"?

Looking at the code the use of "always" means that even if the remote side
has not accepted it or negotiated it, it is still enabled on the session
from the perspective of PJSIP so it is supposed to generate session

The use of "required" means that if the remote side does not support the
timer extension it is supposed to reject the call as a result of extension

> Another question:
> I can see here the following (with timer=yes):
> On *outbound* calls, the provider says in 200 ok: refresher is uas (means:
> provider). The first refresh coming in as update, the provider says:
> refresher is uac (that would be
> asterisk) and asterisk acks it in the 200 ok. But the provider does send
> all following updates (always with uac as refresher). Asterisk itself
> doesn't send any update (I would expect
> it - or is asterisk just not fast enough and provider is always faster?
> Min-SE is 900 and Session-Expires is 1800 - updates from provider are
> coming exactly each 900 s).

Looking at the RFC[3] it appears as though this is fine. Within the scope
of a session refresh initiated by the provider it is the UAC and Asterisk
is the UAS:

   The UAC MAY include the refresher parameter with value 'uac' if it
   wants to perform the refreshes.  However, it is RECOMMENDED that the
   parameter be omitted so that it can be selected by the negotiation
   mechanisms described below.

> Is this the expected behavior?
> I can't see this behavior on inbound calls. Here, refresher in 200 ok and
> following updates doesn't differ.

 According to things this is expected. For an inbound call without further
detail I can't really say.

[3] https://tools.ietf.org/html/rfc4028

Joshua C. Colp
Asterisk Technical Lead
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20200908/e2f07e86/attachment.html>

More information about the asterisk-dev mailing list