Sorry, one short mistake: Of course, after last expire, the expires only removed the a.1207041424.4027.8.0, which was the last one published. The a.1207041424.4027.7.0 from the same publication remains in the table. It has nothing to do with odd and even numbers. Regards Sebastian -----Original Message----- From: Schumann Sebastian Sent: Tuesday, 01. April 2008 10:32 AM To: 'Anca Vamanu' Cc: users(a)lists.openser.org Subject: RE: [OpenSER-Users] PUA/PUA_MI: More than one Publish sent 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=&quot;alice(a)10.96.115.129&quot; 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:activities><rpid:unknown/></rpid:activities><dm:note EOF And my expires script: #!/bin/bash # FIFO command to PUBLISH hard-presence state of user via PUA # #config values OP_SYSUSER=&quot;alice(a)10.96.115.129&quot; 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:activities><rpid:unknown/></rpid:activities><dm:note 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(a)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: match. online. ------------------------------------------------------------------------