[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 sr-users mailing list