ok, now I can see the server_id in the usrloc dump.
``` { "Info": { "AoR": "example_user@example.com", "HashID": -1389656423, "Contacts": [{ "Contact": { "Address": "sip:example_user@212.2.172.228:43356;rinstance=4dc262b9af47682f;transport=UDP", "Expires": 111, "Q": -1, "Call-ID": "4HEiFls2hkky2XR6hL8Nrg..", "CSeq": 86, "User-Agent": "Z 3.15.40006 rv2.8.20", "Received": "sip:212.2.172.228:43356", "Path": "sip:10.7.0.186:5062;lr;received=sip:212.2.172.228:43356", "State": "CS_NEW", "Flags": 2, "CFlags": 64, "Socket": "[not set]", "Methods": -1, "Ruid": "uloc-2-5a04296d-4ed0-e1", "Instance": "[not set]", "Reg-Id": 0, "Server-Id": 2, "Tcpconn-Id": -1, "Keepalive": 1, "Last-Keepalive": 1510231303, "Last-Modified": 1510231303 } }] } } ```
Let me run this for a while longer and see if I can see any options messages being sent on the "wrong" registrar(s). After the update and restart, I currently don't see any "incorrect" options messages being sent, which indicates, for now, that nathelpers filtering is working as expected.
On a side note, is the aor server_id attribute exposed to $ulc pseudo variable? So if I wanted to see which server_id an aor was loaded on I could do a reg_fetch_contacts and check the server_id attribute, and if an aor expired, I should be able to see the server_id in the "usrloc:contact-expired" event route when calling, for example "aor: $ulc(exp=>aor), server_id: $ulc(exp=>server_id)"