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:[EMAIL PROTECTED] Sent: Thu 4/17/2008 17:26 To: Schumann Sebastian Cc: [email protected] 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:[EMAIL PROTECTED] > Sent: Thursday, 03. April 2008 11:43 AM > To: Schumann Sebastian > Cc: [email protected] > 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="[EMAIL PROTECTED]" >> 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 > >> >> >>> 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="[EMAIL PROTECTED]" >> 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 > >> >> >>> 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:[EMAIL PROTECTED]/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:[EMAIL PROTECTED] >> Sent: Tuesday, 25. March 2008 3:05 PM >> To: Schumann Sebastian >> Cc: [email protected] >> 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 >>> [email protected] >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >> >> > > _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
