27 May
2016
27 May
'16
12:59 p.m.
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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>11111</dm:note><op:overriding-willingness><opd:basic>op
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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>22222</dm:note><op:overriding-willingness><opd:basic>op
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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>11111</dm:note><op:overriding-willingness><opd:basic>op
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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>33333</dm:note><op:overriding-willingness><opd:basic>op
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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><dm:note>22222</dm:note><op:overriding-willingness><opd:basic>op
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:willingness><opd:basic>ope
n</opd:basic></op:willingness></tuple><dm:person
id="per123"><op:overriding-willingness><opd:basic>open</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
1 Jun
1 Jun
10:14 a.m.
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
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
11:42 a.m.
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
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
12:46 p.m.
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://www.linkedin.com/in/miconda
1:20 p.m.
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://www.linkedin.com/in/miconda
1:38 p.m.
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://www.linkedin.com/in/miconda
1:58 p.m.
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://www.linkedin.com/in/miconda
2 Jun
2 Jun
9:43 a.m.
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
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
6 Jun
6 Jun
9:08 a.m.
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
--
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
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
3091
days inactive
3101
days old
8 comments
2 participants
participants (2)
-
Aleš Šturm -
Daniel-Constantin Mierla