[OpenSER-Users] PUA/PUA_MI: More than one Publish sent
Schumann Sebastian
Sebastian.Schumann at t-com.sk
Thu Apr 17 20:20:32 CEST 2008
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 at voice-system.ro]
Sent: Thu 4/17/2008 17:26
To: Schumann Sebastian
Cc: users at 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 at voice-system.ro]
> Sent: Thursday, 03. April 2008 11:43 AM
> To: Schumann Sebastian
> Cc: users at 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 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