<div dir="ltr"><div dir="ltr">On Sat, Sep 5, 2020 at 6:18 PM Michael Maier <<a href="mailto:m1278468@mailbox.org">m1278468@mailbox.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello all,<br>
<br>
according [1], there are those options in pjsip regarding support of timers:<br>
<br>
_______________________________________________________________<br>
timers<br>
<br>
no<br>
yes<br>
required<br>
always<br>
forced - Alias of always<br>
_______________________________________________________________<br>
<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'm wondering about their meanings.<br>
<br>
- "No" seems to be clear. No timers support at all.<br>
<br>
- "Always"? I have no idea. Therefore I tested it. I couldn't find any timers support mentioned in INVITE or 200 OK at all.<br>
<br>
- "Required"? Same as "yes" - the only difference was the timer:require in asterisk's outbound Invite.<br>
<br>
<br>
Is this the expected behavior, especially regarding "always"?<br></blockquote><div><br></div><div>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 refreshes.</div><div><br></div><div>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 negotiation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
<br>
Another question:<br>
I can see here the following (with timer=yes):<br>
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<br>
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<br>
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).<br></blockquote><div><br></div><div>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:</div><div><br></div><div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"> 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.</pre></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Is this the expected behavior?<br>
I can't see this behavior on inbound calls. Here, refresher in 200 ok and following updates doesn't differ.<br></blockquote><div><br></div><div> According to things this is expected. For an inbound call without further detail I can't really say.</div><div><br></div><div>[1] <a href="https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_inv.c">https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_inv.c</a></div><div>[2] <a href="https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_timer.c">https://github.com/pjsip/pjproject/blob/master/pjsip/src/pjsip-ua/sip_timer.c</a></div><div>[3] <a href="https://tools.ietf.org/html/rfc4028">https://tools.ietf.org/html/rfc4028</a></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font><br></div></div></div></div></div></div></div></div></div></div></div>