usrloc: E_UL_AOR_DELETE enhancement

[ovidiusas]

When a contact expires, the E_UL_AOR_DELETE event is handy in tracking down in the script expired records. Unfortunately, only the AOR is provided, which is ambiguous for AORs with multiple bindings.
The E_UL_AOR_DELETE event should carry the entire location record for proper identification.

[andrei-datcu]

Could you be more specific on what extra information you would like to get from the event?

[ovidiusas]

All the fields from the usrloc record.

[andrei-datcu]

Could you be a little more specific? Besides the aor, the usrloc record contains only the registered contacts. What we can do is add a different event that is raised each time a contact is inserted/deleted for a specific aor. This way, info about contact's address and the call id could be provided.

[ovidiusas]

When you run the MI command 'ul show' it displays all the details about the
existing binding. When a binding expires, I would like to have access to
all those details. Same for insert.
On Aug 1, 2014 10:22 AM, "andrei-datcu" notifications@github.com wrote:

Could you be a little more specific? Besides the aor, the usrloc record
contains only the registered contacts. What we can do is add a different
event that is raised each time a contact is inserted/deleted for a specific
aor. This way, info about contact's address and the call id could be
provided.

—
Reply to this email directly or view it on GitHub
#250 (comment).

[razvancrainea]

@ovidiusas 'ul show' displays all the contacts that are registered for that AOR. When the E_UL_AOR_DELETE is triggered, there is no other contact available. When the E_UL_AOR_INSERT only one contacts (or more if the REGISTER contains multiple contacts) is available. But we can't provide all the information shown in 'ul show'.
We think we should have a different approach: basically we can trigger a different event, like E_UL_CONTACT_INSERT that will be triggered each time a device registers and E_UL_CONTACT_DELETE when a contact is deleted. Basically the flow would be something like this:

E_UL_AOR_INSERT (user@domain)
E_UL_CONTACT_INSERT (user@domain, contact1)
E_UL_CONTACT_INSERT (user@domain, contact2)
E_UL_CONTACT_DELETE (user@domain, contact1)
E_UL_CONTACT_DELETE (user@domain, contact2)
E_UL_AOR_DELETE (user@domain)

What do you say? Does this satisfy your needs?

[ovidiusas]

@razvancrainea I see what you mean and that's fine (I was under the impression that AOR events are actually CONTACT events, hence the confusion).
We should add also a new event: E_UL_CONTACT_BINDING_UPDATE - that will be triggered when the binding is refreshed from a different IP. With this event I want to detect registrations that are made from a client behind a router that is is capable of handling multiple internet connections and a connection failover occurred.
In this case, the Cseq will be increased, the Callid will be the same but the binding address will be different.

[razvancrainea]

Indeed, the E_UL_CONTACT_BINDING_UPDATE is useful in this scenario. And what exactly would you like to get in that event? Only the new contact? Or shall we add the old contact too, to be able to match one another?

[opensips-github]

All the CONTACT events should provide (the same) all binding info, then the
admin is able to use whatever needed.

On Fri, Aug 1, 2014 at 11:20 AM, Răzvan Crainea notifications@github.com
wrote:

Indeed, the E_UL_CONTACT_BINDING_UPDATE is useful in this scenario. And
what exactly would you like to get in that event? Only the new contact? Or
shall we add the old contact too, to be able to match one another?

—

Reply to this email directly or view it on GitHub
#250 (comment).

---

Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

VoIP Embedded, Inc.
http://www.voipembedded.com

[razvancrainea]

@andrei-datcu just committed the events we were talking about in commit #286 . Let us know if that's what you need.

[ovidiusas]

All the E_UL_CONTACT_* events should carry the aor (to know which AOR was updated).
Also, The _UPDATE event should carry the previous contact and/or the previous received field (if it's not the same). This will allow detection of SIP UA that are behind routers with multiple WAN connections.

[andrei-datcu]

For the E_UL_CONTACT_UPDATE event, the previous received field is the only parameter that could be added. There is no previous contact-address since we are talking about the UPDATE event. If there is another contact-address registered for the same AOR then it will be considered as a different contact and the E_UL_CONTACT_INSERT event will be raised.
The AOR parameter for every E_UL_CONTACT* event will be added in the next patch.

[ovidiusas]

Any updates on the new "aor" param for E_UL_CONTACT* events?