Dear all
I am using OpenSER 1.3.1 branch release R3936. I face some bad behaviour using pua and pua_mi modules.
I publish presence states via the management interface. Sometimes, it happens that multiple PUBLISH message are sent by one request. Unfortunately, there is no "system" or oder when this occurs. It just happens after some publications.
In case of an expiration (Expires=0, E-Tag .) it is not that bad, I receive the log message: ERROR:presence:update_presentity: No E_Tag match.
In case of publication (Expires=-1, E-Tag .) it is very bad: After publication, he receives also two similar messages, and threats both PUBLISH messages as two different ones. Thus, creates two different presentity entries with different E-Tags. If the state is expired now via MI (Expires: -1, E-Tag .) only one of the E-Tags is removed. The second stays in the presentity table and the user still appears online.
Any ideas what can be the reason and how to solve it?
Best regards Sebastian
Hello Sebastian,
Indeed sometimes more that one Publish messages are sent. I will explain when and why. It is possible for someone to request through the MI command to publish a state that should be active for 5000 seconds (you probably know that -1 in expires filed means infinite time). But the max expires in presence server is lets say 3600 sec. If no other publish request is received before the first one expires, the record is deleted. So, to respect the requested time, the pua module generates itself another publish when the first one is close to expire just to update the validity time. Now, if for a subsequent mi command you do not sent the etag parameter ( set it to '.' value), the most recent etag will be found in pua module, and a correct Publish message will be sent. I have just now tried the scenario you described and it works perfectly for me. So, I want to ask you to say exactly what you are doing because there must be something you have missed out. Is the presentity uri exactly the same for the first and the subsequent mi requests? After how much time have you sent the mi request that fails?
Regards, Anca Vamanu
Schumann Sebastian wrote:
Dear all
I am using OpenSER 1.3.1 branch release R3936. I face some bad behaviour using pua and pua_mi modules.
I publish presence states via the management interface. Sometimes, it happens that multiple PUBLISH message are sent by one request. Unfortunately, there is no "system" or oder when this occurs. It just happens after some publications.
In case of an expiration (Expires=0, E-Tag .) it is not that bad, I receive the log message: ERROR:presence:update_presentity: No E_Tag match.
In case of publication (Expires=-1, E-Tag .) it is very bad: After publication, he receives also two similar messages, and threats both PUBLISH messages as two different ones. Thus, creates two different presentity entries with different E-Tags. If the state is expired now via MI (Expires: -1, E-Tag .) only one of the E-Tags is removed. The second stays in the presentity table and the user still appears online.
Any ideas what can be the reason and how to solve it?
Best regards Sebastian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Dear Anca
Thank you for the response.
The publication of more than one message in your described scenario I understand. In my case, immediately after the first PUBLISH is sent, a second one is sent afterwards. OpenSER does not use the most recent etag for an update, but creates a new one, that is never been removed automatically. If I send an expires=0 message after the publication, only the first published etag is removed.
Here my publication script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="open" OP_EXPIRES="-1"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml . <?xml version='1.0' encoding='UTF-8'?><presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple id='gigpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input Har d-State</rpid:user-input></tuple>dm:person id='0jfqoiet'rpid:activitiesrpid:unknown/</rpid:activities><dm:note
Hard-State</dm:note></dm:person></presence>
EOF
And my expires script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="closed" OP_EXPIRES="0"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml . <?xml version='1.0' encoding='UTF-8'?><presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple id='giqpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input Har d-State</rpid:user-input></tuple>dm:person id='0jfqoiet'rpid:activitiesrpid:unknown/</rpid:activities><dm:note
ard-State</dm:note></dm:person></presence>
EOF
I start first publish, then expire, then publish again and so on.
The following etags are created normally: e.g. a.1207041424.4027.1.0 a.1207041424.4027.3.0 a.1207041424.4027.5.0
At some point, another one is created together with the "normal" one, e.g. a.1207041424.4027.7.0 and a.1207041424.4027.8.0
The expires only removed the a.1207041424.4027.7.0 (all odd numbers). The published one with the even number stays forever.
I don't know what can be the reason. Here my OpenSER configuration file extract from pua module: modparam("pua", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("pua", "db_table", "pua") modparam("pua", "update_period", 10) modparam("pua", "default_expires", 600)
Thanks for help.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Tuesday, 25. March 2008 3:05 PM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hello Sebastian,
Indeed sometimes more that one Publish messages are sent. I will explain
when and why. It is possible for someone to request through the MI command to publish a state that should be active for 5000 seconds (you probably know that -1 in expires filed means infinite time). But the max expires in presence server is lets say 3600 sec. If no other publish request is received before the first one expires, the record is deleted. So, to respect the requested time, the pua module generates itself another publish when the first one is close to expire just to update the validity time. Now, if for a subsequent mi command you do not sent the etag parameter (
set it to '.' value), the most recent etag will be found in pua module, and a correct Publish message will be sent. I have just now tried the scenario you described and it works perfectly for me. So, I want to ask you to say exactly what you are doing because there must be something you have missed out. Is the presentity uri exactly the
same for the first and the subsequent mi requests? After how much time have you sent the mi request that fails?
Regards, Anca Vamanu
Schumann Sebastian wrote:
Dear all
I am using OpenSER 1.3.1 branch release R3936. I face some bad behaviour using pua and pua_mi modules.
I publish presence states via the management interface. Sometimes, it happens that multiple PUBLISH message are sent by one request. Unfortunately, there is no "system" or oder when this occurs. It just happens after some publications.
In case of an expiration (Expires=0, E-Tag .) it is not that bad, I receive the log message: ERROR:presence:update_presentity: No E_Tag
match.
In case of publication (Expires=-1, E-Tag .) it is very bad: After publication, he receives also two similar messages, and threats both PUBLISH messages as two different ones. Thus, creates two different presentity entries with different E-Tags. If the state is expired now via MI (Expires: -1, E-Tag .) only one of the E-Tags is removed. The second stays in the presentity table and the user still appears
online.
Any ideas what can be the reason and how to solve it?
Best regards Sebastian
------------------------------------------------------------------------
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Sebastian,
I find no reason why two Publish messages might be sent when an MI command is received. Please send me a message trace together with the openser log ( debug= 7) from where the MI command is being handled (search for the line containing "mi_pua_publish: start").
regards, Anca
Schumann Sebastian wrote:
Dear Anca
Thank you for the response.
The publication of more than one message in your described scenario I understand. In my case, immediately after the first PUBLISH is sent, a second one is sent afterwards. OpenSER does not use the most recent etag for an update, but creates a new one, that is never been removed automatically. If I send an expires=0 message after the publication, only the first published etag is removed.
Here my publication script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="open" OP_EXPIRES="-1"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple id='gigpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input Har d-State</rpid:user-input></tuple>dm:person id='0jfqoiet'rpid:activitiesrpid:unknown/</rpid:activities><dm:note
Hard-State</dm:note></dm:person></presence>
EOF
And my expires script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="closed" OP_EXPIRES="0"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple id='giqpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input Har d-State</rpid:user-input></tuple>dm:person id='0jfqoiet'rpid:activitiesrpid:unknown/</rpid:activities><dm:note
ard-State</dm:note></dm:person></presence>
EOF
I start first publish, then expire, then publish again and so on.
The following etags are created normally: e.g. a.1207041424.4027.1.0 a.1207041424.4027.3.0 a.1207041424.4027.5.0
At some point, another one is created together with the "normal" one, e.g. a.1207041424.4027.7.0 and a.1207041424.4027.8.0
The expires only removed the a.1207041424.4027.7.0 (all odd numbers). The published one with the even number stays forever.
I don't know what can be the reason. Here my OpenSER configuration file extract from pua module: modparam("pua", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("pua", "db_table", "pua") modparam("pua", "update_period", 10) modparam("pua", "default_expires", 600)
Thanks for help.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Tuesday, 25. March 2008 3:05 PM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hello Sebastian,
Indeed sometimes more that one Publish messages are sent. I will explain
when and why. It is possible for someone to request through the MI command to publish a state that should be active for 5000 seconds (you probably know that -1 in expires filed means infinite time). But the max expires in presence server is lets say 3600 sec. If no other publish request is received before the first one expires, the record is deleted. So, to respect the requested time, the pua module generates itself another publish when the first one is close to expire just to update the validity time. Now, if for a subsequent mi command you do not sent the etag parameter (
set it to '.' value), the most recent etag will be found in pua module, and a correct Publish message will be sent. I have just now tried the scenario you described and it works perfectly for me. So, I want to ask you to say exactly what you are doing because there must be something you have missed out. Is the presentity uri exactly the
same for the first and the subsequent mi requests? After how much time have you sent the mi request that fails?
Regards, Anca Vamanu
Schumann Sebastian wrote:
Dear all
I am using OpenSER 1.3.1 branch release R3936. I face some bad behaviour using pua and pua_mi modules.
I publish presence states via the management interface. Sometimes, it happens that multiple PUBLISH message are sent by one request. Unfortunately, there is no "system" or oder when this occurs. It just happens after some publications.
In case of an expiration (Expires=0, E-Tag .) it is not that bad, I receive the log message: ERROR:presence:update_presentity: No E_Tag
match.
In case of publication (Expires=-1, E-Tag .) it is very bad: After publication, he receives also two similar messages, and threats both PUBLISH messages as two different ones. Thus, creates two different presentity entries with different E-Tags. If the state is expired now via MI (Expires: -1, E-Tag .) only one of the E-Tags is removed. The second stays in the presentity table and the user still appears
online.
Any ideas what can be the reason and how to solve it?
Best regards Sebastian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Anca
Sorry for late reply, was busy at work. Attached pls. find the Wireshark trace and also log file from mentioned point on.
I did execute one publish. There everything was fine.
Already at the execution of the expire file, 2x Publish was sent. This has no bas influence, becaus ethe second expires is ignored (see trace).
The next publish for some reason published again 2x a presence state. After one expires would be sent, only one state would be deleted, the other would remain.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Thursday, 03. April 2008 11:43 AM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hi Sebastian,
I find no reason why two Publish messages might be sent when an MI command is received. Please send me a message trace together with the openser log ( debug= 7) from where the MI command is being handled (search for the line containing "mi_pua_publish: start").
regards, Anca
Schumann Sebastian wrote:
Dear Anca
Thank you for the response.
The publication of more than one message in your described scenario I understand. In my case, immediately after the first PUBLISH is sent, a second one is sent afterwards. OpenSER does not use the most recent
etag
for an update, but creates a new one, that is never been removed automatically. If I send an expires=0 message after the publication, only the first published etag is removed.
Here my publication script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="open" OP_EXPIRES="-1"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple
id='gigpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input
Har d-State</rpid:user-input></tuple><dm:person
id='0jfqoiet'>rpid:activitiesrpid:unknown/</rpid:activities><dm:note
Hard-State</dm:note></dm:person></presence>
EOF
And my expires script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="closed" OP_EXPIRES="0"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple
id='giqpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input
Har d-State</rpid:user-input></tuple><dm:person
id='0jfqoiet'>rpid:activitiesrpid:unknown/</rpid:activities><dm:note
ard-State</dm:note></dm:person></presence>
EOF
I start first publish, then expire, then publish again and so on.
The following etags are created normally: e.g. a.1207041424.4027.1.0 a.1207041424.4027.3.0 a.1207041424.4027.5.0
At some point, another one is created together with the "normal" one, e.g. a.1207041424.4027.7.0 and a.1207041424.4027.8.0
The expires only removed the a.1207041424.4027.7.0 (all odd numbers). The published one with the even number stays forever.
I don't know what can be the reason. Here my OpenSER configuration
file
extract from pua module: modparam("pua", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("pua", "db_table", "pua") modparam("pua", "update_period", 10) modparam("pua", "default_expires", 600)
Thanks for help.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Tuesday, 25. March 2008 3:05 PM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hello Sebastian,
Indeed sometimes more that one Publish messages are sent. I will
explain
when and why. It is possible for someone to request through the MI command to
publish
a state that should be active for 5000 seconds (you probably know that
-1 in expires filed means infinite time). But the max expires in presence server is lets say 3600 sec. If no other publish request is received before the first one expires, the record is deleted. So, to respect the requested time, the pua module generates itself another publish when the first one is close to expire just to update the validity time. Now, if for a subsequent mi command you do not sent the etag parameter
(
set it to '.' value), the most recent etag will be found in pua
module,
and a correct Publish message will be sent. I have just now tried the scenario you described and it works
perfectly
for me. So, I want to ask you to say exactly what you are doing because there must be something you have missed out. Is the presentity uri exactly
the
same for the first and the subsequent mi requests? After how much time
have you sent the mi request that fails?
Regards, Anca Vamanu
Schumann Sebastian wrote:
Dear all
I am using OpenSER 1.3.1 branch release R3936. I face some bad behaviour using pua and pua_mi modules.
I publish presence states via the management interface. Sometimes, it
happens that multiple PUBLISH message are sent by one request. Unfortunately, there is no "system" or oder when this occurs. It just
happens after some publications.
In case of an expiration (Expires=0, E-Tag .) it is not that bad, I receive the log message: ERROR:presence:update_presentity: No E_Tag
match.
In case of publication (Expires=-1, E-Tag .) it is very bad: After publication, he receives also two similar messages, and threats both PUBLISH messages as two different ones. Thus, creates two different presentity entries with different E-Tags. If the state is expired now
via MI (Expires: -1, E-Tag .) only one of the E-Tags is removed. The second stays in the presentity table and the user still appears
online.
Any ideas what can be the reason and how to solve it?
Best regards Sebastian
------------------------------------------------------------------------
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Sebastian,
The second Publish seems to be a retransmission. Make sure to create a new transaction before calling the handling functions in your configuration file, so that retransmission are caught. You should put something like : if (!t_newtran()) { sl_reply_error(); exit; }; before handle_publish.
regards, Anca Vamanu
Schumann Sebastian wrote:
Hi Anca
Sorry for late reply, was busy at work. Attached pls. find the Wireshark trace and also log file from mentioned point on.
I did execute one publish. There everything was fine.
Already at the execution of the expire file, 2x Publish was sent. This has no bas influence, becaus ethe second expires is ignored (see trace).
The next publish for some reason published again 2x a presence state. After one expires would be sent, only one state would be deleted, the other would remain.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Thursday, 03. April 2008 11:43 AM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hi Sebastian,
I find no reason why two Publish messages might be sent when an MI command is received. Please send me a message trace together with the openser log ( debug= 7) from where the MI command is being handled (search for the line containing "mi_pua_publish: start").
regards, Anca
Schumann Sebastian wrote:
Dear Anca
Thank you for the response.
The publication of more than one message in your described scenario I understand. In my case, immediately after the first PUBLISH is sent, a second one is sent afterwards. OpenSER does not use the most recent
etag
for an update, but creates a new one, that is never been removed automatically. If I send an expires=0 message after the publication, only the first published etag is removed.
Here my publication script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="open" OP_EXPIRES="-1"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple
id='gigpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input
Har d-State</rpid:user-input></tuple><dm:person
id='0jfqoiet'>rpid:activitiesrpid:unknown/</rpid:activities><dm:note
Hard-State</dm:note></dm:person></presence>
EOF
And my expires script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="closed" OP_EXPIRES="0"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple
id='giqpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input
Har d-State</rpid:user-input></tuple><dm:person
id='0jfqoiet'>rpid:activitiesrpid:unknown/</rpid:activities><dm:note
ard-State</dm:note></dm:person></presence>
EOF
I start first publish, then expire, then publish again and so on.
The following etags are created normally: e.g. a.1207041424.4027.1.0 a.1207041424.4027.3.0 a.1207041424.4027.5.0
At some point, another one is created together with the "normal" one, e.g. a.1207041424.4027.7.0 and a.1207041424.4027.8.0
The expires only removed the a.1207041424.4027.7.0 (all odd numbers). The published one with the even number stays forever.
I don't know what can be the reason. Here my OpenSER configuration
file
extract from pua module: modparam("pua", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("pua", "db_table", "pua") modparam("pua", "update_period", 10) modparam("pua", "default_expires", 600)
Thanks for help.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Tuesday, 25. March 2008 3:05 PM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hello Sebastian,
Indeed sometimes more that one Publish messages are sent. I will
explain
when and why. It is possible for someone to request through the MI command to
publish
a state that should be active for 5000 seconds (you probably know that
-1 in expires filed means infinite time). But the max expires in presence server is lets say 3600 sec. If no other publish request is received before the first one expires, the record is deleted. So, to respect the requested time, the pua module generates itself another publish when the first one is close to expire just to update the validity time. Now, if for a subsequent mi command you do not sent the etag parameter
(
set it to '.' value), the most recent etag will be found in pua
module,
and a correct Publish message will be sent. I have just now tried the scenario you described and it works
perfectly
for me. So, I want to ask you to say exactly what you are doing because there must be something you have missed out. Is the presentity uri exactly
the
same for the first and the subsequent mi requests? After how much time
have you sent the mi request that fails?
Regards, Anca Vamanu
Schumann Sebastian wrote:
Dear all
I am using OpenSER 1.3.1 branch release R3936. I face some bad behaviour using pua and pua_mi modules.
I publish presence states via the management interface. Sometimes, it
happens that multiple PUBLISH message are sent by one request. Unfortunately, there is no "system" or oder when this occurs. It just
happens after some publications.
In case of an expiration (Expires=0, E-Tag .) it is not that bad, I receive the log message: ERROR:presence:update_presentity: No E_Tag
match.
In case of publication (Expires=-1, E-Tag .) it is very bad: After publication, he receives also two similar messages, and threats both PUBLISH messages as two different ones. Thus, creates two different presentity entries with different E-Tags. If the state is expired now
via MI (Expires: -1, E-Tag .) only one of the E-Tags is removed. The second stays in the presentity table and the user still appears
online.
Any ideas what can be the reason and how to solve it?
Best regards Sebastian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Hi Anca
Indeed, this was the problem. I did not check the configuration carefully enough, sorry for that :)
Thank you very much for the right hint!
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Thu 4/17/2008 17:26 To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hi Sebastian,
The second Publish seems to be a retransmission. Make sure to create a new transaction before calling the handling functions in your configuration file, so that retransmission are caught. You should put something like : if (!t_newtran()) { sl_reply_error(); exit; }; before handle_publish.
regards, Anca Vamanu
Schumann Sebastian wrote:
Hi Anca
Sorry for late reply, was busy at work. Attached pls. find the Wireshark trace and also log file from mentioned point on.
I did execute one publish. There everything was fine.
Already at the execution of the expire file, 2x Publish was sent. This has no bas influence, becaus ethe second expires is ignored (see trace).
The next publish for some reason published again 2x a presence state. After one expires would be sent, only one state would be deleted, the other would remain.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Thursday, 03. April 2008 11:43 AM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hi Sebastian,
I find no reason why two Publish messages might be sent when an MI command is received. Please send me a message trace together with the openser log ( debug= 7) from where the MI command is being handled (search for the line containing "mi_pua_publish: start").
regards, Anca
Schumann Sebastian wrote:
Dear Anca
Thank you for the response.
The publication of more than one message in your described scenario I understand. In my case, immediately after the first PUBLISH is sent, a second one is sent afterwards. OpenSER does not use the most recent
etag
for an update, but creates a new one, that is never been removed automatically. If I send an expires=0 message after the publication, only the first published etag is removed.
Here my publication script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="open" OP_EXPIRES="-1"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple
id='gigpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input
Har d-State</rpid:user-input></tuple><dm:person
id='0jfqoiet'>rpid:activitiesrpid:unknown/</rpid:activities><dm:note
Hard-State</dm:note></dm:person></presence>
EOF
And my expires script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA #
#config values OP_SYSUSER="alice@10.96.115.129" OP_SIPURI="sip:$OP_SYSUSER" OP_STATE="closed" OP_EXPIRES="0"
#build reply fifo file rm -f /tmp/openser_fifo_reply mkfifo /tmp/openser_fifo_reply cat /tmp/openser_fifo_reply&
cat >/tmp/openser_fifo <<EOF :pua_publish:openser_fifo_reply $OP_SIPURI $OP_EXPIRES presence application/pidf+xml .
<?xml version='1.0' encoding='UTF-8'?><presence
xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:x ml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' ntity='$OP_SIPURI'><tuple
id='giqpoej8'><status><basic>$OP_STATE</basic></status>rpid:user-input
Har d-State</rpid:user-input></tuple><dm:person
id='0jfqoiet'>rpid:activitiesrpid:unknown/</rpid:activities><dm:note
ard-State</dm:note></dm:person></presence>
EOF
I start first publish, then expire, then publish again and so on.
The following etags are created normally: e.g. a.1207041424.4027.1.0 a.1207041424.4027.3.0 a.1207041424.4027.5.0
At some point, another one is created together with the "normal" one, e.g. a.1207041424.4027.7.0 and a.1207041424.4027.8.0
The expires only removed the a.1207041424.4027.7.0 (all odd numbers). The published one with the even number stays forever.
I don't know what can be the reason. Here my OpenSER configuration
file
extract from pua module: modparam("pua", "db_url", "mysql://openser:openserrw@localhost/openser") modparam("pua", "db_table", "pua") modparam("pua", "update_period", 10) modparam("pua", "default_expires", 600)
Thanks for help.
Best regards Sebastian
-----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Tuesday, 25. March 2008 3:05 PM To: Schumann Sebastian Cc: users@lists.openser.org Subject: Re: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Hello Sebastian,
Indeed sometimes more that one Publish messages are sent. I will
explain
when and why. It is possible for someone to request through the MI command to
publish
a state that should be active for 5000 seconds (you probably know that
-1 in expires filed means infinite time). But the max expires in presence server is lets say 3600 sec. If no other publish request is received before the first one expires, the record is deleted. So, to respect the requested time, the pua module generates itself another publish when the first one is close to expire just to update the validity time. Now, if for a subsequent mi command you do not sent the etag parameter
(
set it to '.' value), the most recent etag will be found in pua
module,
and a correct Publish message will be sent. I have just now tried the scenario you described and it works
perfectly
for me. So, I want to ask you to say exactly what you are doing because there must be something you have missed out. Is the presentity uri exactly
the
same for the first and the subsequent mi requests? After how much time
have you sent the mi request that fails?
Regards, Anca Vamanu
Schumann Sebastian wrote:
Dear all
I am using OpenSER 1.3.1 branch release R3936. I face some bad behaviour using pua and pua_mi modules.
I publish presence states via the management interface. Sometimes, it
happens that multiple PUBLISH message are sent by one request. Unfortunately, there is no "system" or oder when this occurs. It just
happens after some publications.
In case of an expiration (Expires=0, E-Tag .) it is not that bad, I receive the log message: ERROR:presence:update_presentity: No E_Tag
match.
In case of publication (Expires=-1, E-Tag .) it is very bad: After publication, he receives also two similar messages, and threats both PUBLISH messages as two different ones. Thus, creates two different presentity entries with different E-Tags. If the state is expired now
via MI (Expires: -1, E-Tag .) only one of the E-Tags is removed. The second stays in the presentity table and the user still appears
online.
Any ideas what can be the reason and how to solve it?
Best regards Sebastian
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
-
Anca Vamanu -
Schumann Sebastian