presence: Always check if a record exists for this dialog before inserting

[phil-lavin]

The presence implementation is a little dubious, to say the least.
It probably wants re-writing at some stage. However, this fixes a
race condition that could have a number of causes in which the PUA
is unaware of the eTag at the point it sends the PUBLISH.

The mechanism is such that the PUA passes the eTag that should be updated in the database into a main Kamailio process via a header in the PUBLISH. It is made aware of the new eTag by the main Kamailio process in the 200 OK.

In the scenario when the PUA has not received the 200 OK for the Trying PUBLISH before it sends the early PUBLISH, it will send the early PUBLISH with no eTag. This results in both Trying and early being inserted into the database. Only the early is updated, as it is the most recent, meaning the Trying will stick around in the table until it expires.

[phil-lavin]

This may have a memory leak... Going to investigate more so hold off on merging for now. If anyone can spot it, free beer may be on offer.

[phil-lavin]

Found the leak with valgrind. Added as a second commit. Going to run in production for a few days and see if memory stays stable.

[miconda]

Thanks! I will review and merge asap -- just that these days I am traveling with limited available time and the pull request is consistent.

[phil-lavin]

Hi Daniel, no problem at all. Whenever you can.

It's been running in production for a few days now, along with #726. We use BLF extremely heavily and no further problems have been seen by customers.

That said, give it another week or so such that we can be sure the memory footprint is unaffected.

[miconda]

I guess all went ok so far, without issues, given you haven't reported back. I hope to have the time to do the merge these days.

[phil-lavin]

Yes, all good here. #726 has been running good too.