<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body dir="auto">The opensip register module states the following:<div dir="auto"><br></div><div dir="auto"><span class="titlepage"><div><div><h3 class="title">1.3.23. <code class="varname">pn_providers</code> (string)</h3></div></div></span><p>
A list of supported Push Notification providers. While only three
possible values are defined by RFC 8599 ("apns", "fcm" and "webpush"),
non-standard values may be specified as well.
</p><p>
<span class="emphasis"><em>
Default value is <span class="bold"><strong>NULL</strong></span>
(not set). </em></span></p><div dir="auto"><br></div><div dir="auto"><span class="titlepage"><div><div><h3 class="title">1.3.24. <code class="varname">pn_ct_match_params</code> (string)</h3></div></div></span><p>
The minimally required list of RFC 8599 parameters (custom ones are
accepted as well) which must be present in a Contact URI and
identically match an existing binding in order for the binding
to be refreshed during a SIP re-REGISTER. If at least one such
parameter is missing from a Contact header field URI, the module
will fall back to performing regular contact matching.
</p><p>
Note that if all above PN Contact URI parameters match an existing
binding, the match is considered to be successful regardless if
other parts of the SIP URI do not match (e.g. hostname, port,
other URI parameters, etc.).
</p><p>
After calling <span class="emphasis"><em><acronym class="acronym">lookup()</acronym></em></span> or
<a title="1.5.1. pn_process_purr(domain)" href="https://opensips.org/docs/modules/devel/registrar.html#afunc_pn_process_purr" class="xref">pn_process_purr()</a>, the above PN-related
parameters will be automatically stripped from the resulting
Request and Contact URI event parameter, respectively.
</p><p>
<span class="emphasis"><em>
Default value is <span class="bold"><strong>
"pn-provider, pn-prid, pn-param"</strong></span>. </em></span></p><p><span class="emphasis"><em><br></em></span></p><p><span class="emphasis">https://opensips.org/docs/modules/3.3.x/registrar.html</span></p><p><span class="emphasis"><em>Linphone, depending how far back you go, is not rfc 8599 compliant. It uses a nonstandard way of supporting push notifications using their own proxy flexisip.</em></span></p><p><span class="emphasis"><em><br></em></span></p><p><span class="emphasis"><em>The 4.56 version does support the rfc 8599 but it does not do the re-register event that is required in order to be fully compliant with the rfc and opensips. You will actually have to compile linphone changing three lines of code to make it do the REGISTER request. I found that on Google about a year ago (will look for and send later if you need it). Linphone doesn't support +sip.pnsreg feature so you will rely on the </em></span>pn_trigger_interval in opensips (read module link I sent above regarding it).</p></div></div><div><br></div><div align="left" dir="auto" style="font-size:100%;color:#000000"><div>-------- Original message --------</div><div>From: HS <bullehs@gmail.com> </div><div>Date: 2/22/23 1:56 AM (GMT-06:00) </div><div>To: OpenSIPS users mailling list <users@lists.opensips.org> </div><div>Subject: [OpenSIPS-Users] Push Notification - Location table has flag 0 v3.3 </div><div><br></div></div><div dir="ltr"><div>Hi all.</div><div><br></div><div>I am starting to implement push notifications on Opensips v3.3, using an old Linphone version that sends out parameters in the following format:</div><div><br></div><div>pn-type instead of pn-provider</div><div>firebase instead of fcm<br></div><div>app-id
instead of
pn-param<br>pn-tok
instead of
pn-prid</div><div><br></div><div>Location table has flag 0 (I think it should be 4). I tried adding pn-type, app-id in pn_ct_match_params, but didn't seem to work (flag is still 0).</div><div><br></div><div>modparam("registrar", "pn_providers", "apns, fcm, firebase")<br>modparam("registrar", "pn_ct_match_params", "pn-provider, pn-prid, pn-param, pn-type, pn-tok, app-id")<br></div><div></div><div><br></div><div>Is v3.3 incompatible with the old nomenclature or am I missing something?</div><div><br></div><div>Thanks.</div></div>
</body></html>