[OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Anca Vamanu
anca at voice-system.ro
Thu Apr 3 11:43:16 CEST 2008
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 at 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: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="alice at 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: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: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 at voice-system.ro]
> Sent: Tuesday, 25. March 2008 3:05 PM
> To: Schumann Sebastian
> Cc: users at 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 at lists.openser.org
>> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
More information about the Users
mailing list