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