<div dir="ltr">Hi Liviu,<div>Enabling log_level 4 helped me to identify the problem. I saw this message in logs:</div><div>DBG:core:pn_inspect_request: skip PN processing, matching mode already enforced</div><div><br></div><div>Indeed I use mid_registrar_save with matching-mode=1 flag. I've removed it and now AOR is saved with Flags: 4</div><div>I think this should be documented somehow or there should be one more matching-mode which enables PN params processing.</div><div>Anyway, thank you very much for the hint.</div><div><br></div><div>Best regards, Andrew.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">чт, 29 янв. 2026 г. в 17:14, Liviu Chircu <<a href="mailto:liviu@opensips.org">liviu@opensips.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Andrew,<br>
<br>
Indeed, the expected result is Flags: 4 here.  Your Contact looks OK at <br>
a first glance.<br>
<br>
Especially since you're on a test lab and generating RFC 8599 compliant <br>
traffic using hand-made sipp scenarios, please put OpenSIPS in debug <br>
mode (4), do a "grep -C5 mid_registrar" on the entire logs generated <br>
during the REGISTER and post the results here (or mail me privately is <br>
privacy is a concern).  The DEBUG logs should give us strong clues on <br>
what PN detection steps your OpenSIPS takes before giving up on that RFC <br>
8599 Contact.<br>
<br>
Best regards,<br>
<br>
Liviu Chircu<br>
<a href="http://www.opensips-solutions.com" rel="noreferrer" target="_blank">www.opensips-solutions.com</a> | <a href="http://www.siphub.com" rel="noreferrer" target="_blank">www.siphub.com</a><br>
<br>
On 27/01/2026 17:35, Andrew wrote:<br>
> As we can see Flags: 0 but should be 4.<br>
> mid_registrar_lookup returns 1 (should be 2).<br>
> OpenSIPS doesn't generate E_UL_CONTACT_REFRESH event.<br>
> Is there anything wrong with the REGISTER request?<br>
</blockquote></div>