Hello,
Kamailio 4.3:
I am testing Presence module with more complex scenario. I have 2 SIP clients (presentity) with equal identities (3918) and one watcher (2025). All my clients are Monster 0.9.25. My Kamailio Presence module is configured with "retrieve_order=1" (presentity records are retrieve by priority order). I have situation when wrong status is send to the watcher (2025).
1. First all three clients registers and publish its own status. Below is print from my MySQL database (presentity table)
mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84481 | 3918 | 40 | 1464340695 | 1464337095 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"op:overriding-willingnessopd:basicopen</opd:basic></op:overr iding-willingness></dm:person></presence> |
| 84480 | 3918 | 40 | 1464340687 | 1464337087 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"op:overriding-willingnessopd:basicopen</opd:basic></op:overr iding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"op:overriding-willingnessopd:basicopen</opd:basic></op:overr iding-willingness></dm:person></presence> |
2. Then first 3918 client publishes his mood >11111<. The status in
Presentity< table is refreshed under the id=84480. NOTIFY is sent to 2025
with status with mood >11111<.
mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84480 | 3918 | 40 | 1464340703 | 1464337103 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"dm:note11111</dm:note>op:overriding-willingnessopd:basicop en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84481 | 3918 | 40 | 1464340695 | 1464337095 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"op:overriding-willingnessopd:basicopen</opd:basic></op:overr iding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"op:overriding-willingnessopd:basicopen</opd:basic></op:overr iding-willingness></dm:person></presence> |
3. After that the second 3918 client publishes his mood >22222<. The status in >Presentity< table is refreshed under the right id=84481. NOTIFY is sent to 2025 with status with mood >22222<.
mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84481 | 3918 | 40 | 1464340716 | 1464337116 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"dm:note22222</dm:note>op:overriding-willingnessopd:basicop en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84480 | 3918 | 40 | 1464340703 | 1464337103 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"dm:note11111</dm:note>op:overriding-willingnessopd:basicop en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"op:overriding-willingnessopd:basicopen</opd:basic></op:overr iding-willingness></dm:person></presence> |
4. Then finally, the first 3918 changes his mood to "33333". The status in >Presentity< table is refreshed under the right id=84480. BUT, to 2025 is sent NOTIFY with mood "22222". "received_time" timestamp of status with mood "33333" is higher than timestamp of status with mood "22222". BUT the "id" attribute of "presentity" table of status with mood "33333" is smaller. I think that statuses with equal "priority" are retrieved by "id" and not by "received_time"!?
mysql> select id,username,priority,expires,received_time,body from presentity ORDER BY received_time DESC;
| id | username | priority | expires | received_time | body
| 84480 | 3918 | 40 | 1464340729 | 1464337129 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"dm:note33333</dm:note>op:overriding-willingnessopd:basicop en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84481 | 3918 | 40 | 1464340716 | 1464337116 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:3918@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"dm:note22222</dm:note>op:overriding-willingnessopd:basicop en</opd:basic></op:overriding-willingness></dm:person></presence> |
| 84479 | 2025 | 40 | 1464340682 | 1464337082 | <?xml version='1.0' encoding='utf-8' ?><presence entity="sip:2025@192.168.77.43" xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpidf="urn:ietf:params:xml:ns:pidf:rpid" xmlns:op="urn:oma:xml:prs:pidf:oma-pres" xmlns:opd="urn:oma:xml:pde:pidf:ext"><tuple id="com1"><status><basic>open</basic></status>op:willingnessopd:basicope n</opd:basic></op:willingness></tuple>dm:person id="per123"op:overriding-willingnessopd:basicopen</opd:basic></op:overr iding-willingness></dm:person></presence> |
The Wireshark trace is attached.
Can anyone help. Please? We have a big installation in the Gazprom's (Rusia) network, where Kamailio is used as a Presence server only.
Thanks
Ales
Hello,
skipping the other content to fit in size limits for mailing list ...
On 27/05/16 11:59, Aleš Šturm wrote:
*I think that statuses with equal “priority” are retrieved by “id” and not by “received_time”!?*
Is the above the conclusion and the fix would be to order by received_time if the priority is the same?
At this moment I expect there is no further ordering than the priority in this case, mysql being the one returning the order within the priority as the records are found in the db. Like, if you just do a select without order by, there is no guarantee that the order of records is the one as the records were added.
Cheers, Daniel
Hello,
yes, if the priority is the same, records should be ordered by received_time. Acting in this way, when "presentity" table has more than one record of the same user with equal priority, to watcher would be send Notify message with last received status.
SQL like:
select * from presentity where username=X and priority=Y order by received_time desc;
Thanks,
Ales
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, June 01, 2016 9:15 AM To: Kamailio (SER) - Users Mailing List Cc: 'Ales Sturm' Subject: Re: [SR-Users] Wrong Publish status
Hello,
skipping the other content to fit in size limits for mailing list ...
On 27/05/16 11:59, Aleš Šturm wrote:
I think that statuses with equal "priority" are retrieved by "id" and not by "received_time"!?
Is the above the conclusion and the fix would be to order by received_time if the priority is the same?
At this moment I expect there is no further ordering than the priority in this case, mysql being the one returning the order within the priority as the records are found in the db. Like, if you just do a select without order by, there is no guarantee that the order of records is the one as the records were added.
Cheers, Daniel
On 01/06/16 10:42, Aleš Šturm wrote:
Hello,
yes, if the priority is the same, records should be ordered by received_time. Acting in this way, when “presentity” table has more than one record of the same user with equal priority, to watcher would be send Notify message with last received status.
SQL like:
select * from presentity where username=X and priority=Y order by received_time desc;
Well, the priority is not known in advance, query is like:
select ... from presentity by matching the user and event, ordering either by receive_time when retrieve_order=0 or by priority if retrieve_order=1.
Here it looks like order by has to be a combination of the two columns.
Cheers, Daniel
Hello,
yes, when retrieve_order=1, then order has to be combination of columns »priority« and »received_time«, because there can be multiple records with the same priority, but with different received_time. And we would like to publish the newest status.
My example:
mysql> select id,username,received_time,priority from presentity where username=3915 and event='presence' order by priority desc, received_time desc;
| id | username | received_time | priority |
+----+----------+---------------+----------+
| 34 | 3915 | 1464775887 | 60 |
| 33 | 3915 | 1464775876 | 60 |
| 32 | 3915 | 1464775869 | 40 |
| 30 | 3915 | 1464775844 | 40 |
| 26 | 3915 | 1464775811 | 40 |
| 35 | 3915 | 1464775894 | 20 |
+----+----------+---------------+----------+
All the best,
Ales
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, June 01, 2016 11:47 AM To: Aleš Šturm; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Wrong Publish status
On 01/06/16 10:42, Aleš Šturm wrote:
Hello,
yes, if the priority is the same, records should be ordered by received_time. Acting in this way, when “presentity” table has more than one record of the same user with equal priority, to watcher would be send Notify message with last received status.
SQL like:
select * from presentity where username=X and priority=Y order by received_time desc;
Well, the priority is not known in advance, query is like:
select ... from presentity by matching the user and event, ordering either by receive_time when retrieve_order=0 or by priority if retrieve_order=1.
Here it looks like order by has to be a combination of the two columns.
Cheers, Daniel
Hello,
to have full flexibility here I am thinking of adding a new module parameter to set the order-by string when the retrieve_order=1, as it may be different for various db connectors. The default will be 'priority', which is what is done right now.
That will practically cover also the case of retrieve_order=0, where the order by is done on received_time, but for backwards compatibility I think it should stay there.
Cheers, Daniel
On 01/06/16 12:20, Aleš Šturm wrote:
Hello,
yes, when retrieve_order=1, then order has to be combination of columns »priority« and »received_time«, because there can be multiple records with the same priority, but with different received_time. And we would like to publish the newest status.
My example:
mysql> select id,username,received_time,priority from presentity where username=3915 and event='presence' order by priority desc, received_time desc;
| id | username | received_time | priority |
+----+----------+---------------+----------+
| 34 | 3915 | 1464775887 | 60 |
| 33 | 3915 | 1464775876 | 60 |
| 32 | 3915 | 1464775869 | 40 |
| 30 | 3915 | 1464775844 | 40 |
| 26 | 3915 | 1464775811 | 40 |
| 35 | 3915 | 1464775894 | 20 |
+----+----------+---------------+----------+
All the best,
Ales
*From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Sent:* Wednesday, June 01, 2016 11:47 AM *To:* Aleš Šturm; 'Kamailio (SER) - Users Mailing List' *Subject:* Re: [SR-Users] Wrong Publish status
On 01/06/16 10:42, Aleš Šturm wrote:
Hello, yes, if the priority is the same, records should be ordered by received_time. Acting in this way, when “presentity” table has more than one record of the same user with equal priority, to watcher would be send Notify message with last received status. SQL like: select * from presentity where username=X and priority=Y order by received_time desc;Well, the priority is not known in advance, query is like:
select ... from presentity by matching the user and event, ordering either by receive_time when retrieve_order=0 or by priority if retrieve_order=1.
Here it looks like order by has to be a combination of the two columns.
Cheers, Daniel
-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda http://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda
Excellent,
I didn’t think about different db connectors. But, your proposal is the best choice. If you are willing to prepare correction I can test it. Please let me know.
All the best,
Ales
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, June 01, 2016 12:38 PM To: Aleš Šturm; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Wrong Publish status
Hello,
to have full flexibility here I am thinking of adding a new module parameter to set the order-by string when the retrieve_order=1, as it may be different for various db connectors. The default will be 'priority', which is what is done right now.
That will practically cover also the case of retrieve_order=0, where the order by is done on received_time, but for backwards compatibility I think it should stay there.
Cheers, Daniel
On 01/06/16 12:20, Aleš Šturm wrote:
Hello,
yes, when retrieve_order=1, then order has to be combination of columns »priority« and »received_time«, because there can be multiple records with the same priority, but with different received_time. And we would like to publish the newest status.
My example:
mysql> select id,username,received_time,priority from presentity where username=3915 and event='presence' order by priority desc, received_time desc;
| id | username | received_time | priority |
+----+----------+---------------+----------+
| 34 | 3915 | 1464775887 | 60 |
| 33 | 3915 | 1464775876 | 60 |
| 32 | 3915 | 1464775869 | 40 |
| 30 | 3915 | 1464775844 | 40 |
| 26 | 3915 | 1464775811 | 40 |
| 35 | 3915 | 1464775894 | 20 |
+----+----------+---------------+----------+
All the best,
Ales
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, June 01, 2016 11:47 AM To: Aleš Šturm; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Wrong Publish status
On 01/06/16 10:42, Aleš Šturm wrote:
Hello,
yes, if the priority is the same, records should be ordered by received_time. Acting in this way, when “presentity” table has more than one record of the same user with equal priority, to watcher would be send Notify message with last received status.
SQL like:
select * from presentity where username=X and priority=Y order by received_time desc;
Well, the priority is not known in advance, query is like:
select ... from presentity by matching the user and event, ordering either by receive_time when retrieve_order=0 or by priority if retrieve_order=1.
Here it looks like order by has to be a combination of the two columns.
Cheers, Daniel
I pushed the commit to add the new parameter to the master branch. Let me know if works as expected.
Cheers, Daniel
On 01/06/16 12:58, Aleš Šturm wrote:
Excellent,
I didn’t think about different db connectors. But, your proposal is the best choice. If you are willing to prepare correction I can test it. Please let me know.
All the best,
Ales
*From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Sent:* Wednesday, June 01, 2016 12:38 PM *To:* Aleš Šturm; 'Kamailio (SER) - Users Mailing List' *Subject:* Re: [SR-Users] Wrong Publish status
Hello,
to have full flexibility here I am thinking of adding a new module parameter to set the order-by string when the retrieve_order=1, as it may be different for various db connectors. The default will be 'priority', which is what is done right now.
That will practically cover also the case of retrieve_order=0, where the order by is done on received_time, but for backwards compatibility I think it should stay there.
Cheers, Daniel
On 01/06/16 12:20, Aleš Šturm wrote:
Hello, yes, when retrieve_order=1, then order has to be combination of columns »priority« and »received_time«, because there can be multiple records with the same priority, but with different received_time. And we would like to publish the newest status. My example: mysql> select id,username,received_time,priority from presentity where username=3915 and event='presence' order by priority desc, received_time desc; | id | username | received_time | priority | +----+----------+---------------+----------+ | 34 | 3915 | 1464775887 | 60 | | 33 | 3915 | 1464775876 | 60 | | 32 | 3915 | 1464775869 | 40 | | 30 | 3915 | 1464775844 | 40 | | 26 | 3915 | 1464775811 | 40 | | 35 | 3915 | 1464775894 | 20 | +----+----------+---------------+----------+ All the best, Ales *From:*Daniel-Constantin Mierla [mailto:miconda@gmail.com] *Sent:* Wednesday, June 01, 2016 11:47 AM *To:* Aleš Šturm; 'Kamailio (SER) - Users Mailing List' *Subject:* Re: [SR-Users] Wrong Publish status On 01/06/16 10:42, Aleš Šturm wrote: Hello, yes, if the priority is the same, records should be ordered by received_time. Acting in this way, when “presentity” table has more than one record of the same user with equal priority, to watcher would be send Notify message with last received status. SQL like: select * from presentity where username=X and priority=Y order by received_time desc; Well, the priority is not known in advance, query is like: select ... from presentity by matching the user and event, ordering either by receive_time when retrieve_order=0 or by priority if retrieve_order=1. Here it looks like order by has to be a combination of the two columns. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda-- Daniel-Constantin Mierla http://www.asipto.com - http://www.kamailio.org http://twitter.com/#!/miconda http://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda
Hello Daniel,
excellent. Working as expected. Now records of one user (with multiple phones) are ordered by priority and received time.
In what branch do you intend to commit those changes, 4.4 or only into development?
Thanks,
and all the best,
Ales
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Thursday, June 02, 2016 8:44 AM To: Aleš Šturm; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Wrong Publish status
I pushed the commit to add the new parameter to the master branch. Let me know if works as expected.
Cheers, Daniel
On 01/06/16 12:58, Aleš Šturm wrote:
Excellent,
I didn’t think about different db connectors. But, your proposal is the best choice. If you are willing to prepare correction I can test it. Please let me know.
All the best,
Ales
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, June 01, 2016 12:38 PM To: Aleš Šturm; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Wrong Publish status
Hello,
to have full flexibility here I am thinking of adding a new module parameter to set the order-by string when the retrieve_order=1, as it may be different for various db connectors. The default will be 'priority', which is what is done right now.
That will practically cover also the case of retrieve_order=0, where the order by is done on received_time, but for backwards compatibility I think it should stay there.
Cheers, Daniel
On 01/06/16 12:20, Aleš Šturm wrote:
Hello,
yes, when retrieve_order=1, then order has to be combination of columns »priority« and »received_time«, because there can be multiple records with the same priority, but with different received_time. And we would like to publish the newest status.
My example:
mysql> select id,username,received_time,priority from presentity where username=3915 and event='presence' order by priority desc, received_time desc;
| id | username | received_time | priority |
+----+----------+---------------+----------+
| 34 | 3915 | 1464775887 | 60 |
| 33 | 3915 | 1464775876 | 60 |
| 32 | 3915 | 1464775869 | 40 |
| 30 | 3915 | 1464775844 | 40 |
| 26 | 3915 | 1464775811 | 40 |
| 35 | 3915 | 1464775894 | 20 |
+----+----------+---------------+----------+
All the best,
Ales
From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: Wednesday, June 01, 2016 11:47 AM To: Aleš Šturm; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Wrong Publish status
On 01/06/16 10:42, Aleš Šturm wrote:
Hello,
yes, if the priority is the same, records should be ordered by received_time. Acting in this way, when “presentity” table has more than one record of the same user with equal priority, to watcher would be send Notify message with last received status.
SQL like:
select * from presentity where username=X and priority=Y order by received_time desc;
Well, the priority is not known in advance, query is like:
select ... from presentity by matching the user and event, ordering either by receive_time when retrieve_order=0 or by priority if retrieve_order=1.
Here it looks like order by has to be a combination of the two columns.
Cheers, Daniel
-
Aleš Šturm -
Daniel-Constantin Mierla