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)"

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.