[Kamailio-Devel] [OpenSIPS-Devel] pua callback
Klaus Darilion
klaus.mailinglists at pernau.at
Wed Oct 8 10:28:08 CEST 2008
Hi never had such issues. as the pres_id looks completely different I
suspect a bug (maybe in your module? - btw: what are you trying to build?)
In the pua_dialoginfo module I use the callid as pres_id. Thus, in my
case, if a user has multiple dialogs concurrently, I have multiple
states of the same user in the presence table.
The presence module supports different methods for NOTIFY generation. In
the simplest mode it just forwards the PUBLISH-body as NOTIFY-body.
If you register the agg_nbody callback in the presence module, you can
aggregate the body of all PUBLISHs in a single NOTIFY-body (of course
this depends on the definition of the Event: type)
regards
klaus
Schumann Sebastian schrieb:
> Hi again
>
> It works so far so good. I just found out, monitoring pua and presentity table, that there are still situations when one user has more presence states in the presentity table. When the pua table updates my presence state, it seems it creates another entry with a different pres_id.
>
> Example from pua table:
> +------+---------------------------+------------------------------------------+-------+------------+-----------------+------+--------------------
> | id | pres_uri | pres_id | event | expires | desired_expires | flag | etag
> +------+---------------------------+------------------------------------------+-------+------------+-----------------+------+--------------------
> | 6967 | sip:alice at 10.96.115.129 | SCRIPT_PUBLISH.sip:alice at 10.96.115.129 | 1 | 1223390177 | 1223390177 | 1024 | a.1223388369.19558.66.10
> | 6971 | sip:alice at 10.96.115.129 | a.1223388369.19558.66.1060 at 10.96.115.129 | 1 | 1223390270 | 1223390270 | 1024 | a.1223388369.19558.69.11
> +------+---------------------------+------------------------------------------+-------+------------+-----------------+------+--------------------
>
> Is this the correct behavior?
>
> How is the presence state for NOTIFY created in this situation? The actual state for the last publish from script (id 6967) should be actually the same as the one the pua module created (id 6971). I still think he should use the pres_id that I created and not create its own.
>
> Sebastian
>
>> -----Original Message-----
>> From: Anca Vamanu [mailto:anca at voice-system.ro]
>> Sent: Tuesday, 07. October 2008 13:49
>> To: Schumann Sebastian
>> Cc: Klaus Darilion; devel at lists.kamailio.org; devel at lists.opensips.org
>> Subject: Re: [OpenSIPS-Devel] [Kamailio-Devel] pua callback
>>
>> Hi Sebastian,
>>
>> The id is used to differentiate between sources using the pua
>> module to send Publish messages for the same event. If for
>> example you were to use the same id as pua_mi uses ( it is
>> not the case now) of some other future module that used 'pua'
>> module, both will update the same record.
>> I suggest using an id that identifies the module also,
>> starting with the module flag is a good idea.
>>
>> regards,
>> Anca
>>
>> Schumann Sebastian wrote:
>>> OK, seems to work, thanks a lot.
>>>
>>> For clarification: I publish the presence state from the
>> script and pass as parameter the URI. For each user, I
>> publish from the script should always be _only one_ presence
>> state. This does not mean that I will not have another state
>> of the same user, if he published differently (XCAP, SIP
>> PUBLISH directly from client) but all info from the script
>> should only be the latest available.
>>> I assinged this:
>>> /* Create ID for update requests */
>>> publ.id.s = pres_uri.s;
>>> publ.id.len = pres_uri.len;
>>>
>>> publ.flag|= UPDATE_TYPE;
>>> publ.source_flag|= SCRIPT_PUBLISH;
>>>
>>> I understand it that I can use presence URI as ID, as there
>> should be only one state from the user. The publ.flag means
>> that he should update the state if he find any previous (Etag
>> changes already successfully from .......1.0 to ......2.1
>> what I didn't have before) and the source_flag separates the
>> "presence source". So if e.g. Klaus would use the same ID
>> from his module, it would be threated separately. I do not
>> need this information in the id. Example from Klaus' module
>> (memcpy(publ->id.s, "DIALOG_PUBLISH.", 15);
>> memcpy(publ->id.s+15, callid->s, callid->len);) The
>> DIALOG_PUBLISH would in fact be not required mandatory for
>> separation because the souce_flag is set.
>>> Did I understand it correctly? I hope so, because I achieved what I
>>> want and hope not to have just "a lucky hack" caused by any
>>> misunderstanding :-)
>>>
>>> Thanks.
>>>
>>> Sebastian
>>>
>>>
>>>> -----Original Message-----
>>>> From: Anca Vamanu [mailto:anca at voice-system.ro]
>>>> Sent: Monday, 06. October 2008 19:00
>>>> To: Klaus Darilion
>>>> Cc: Schumann Sebastian; devel at lists.kamailio.org;
>>>> devel at lists.opensips.org
>>>> Subject: Re: [OpenSIPS-Devel] [Kamailio-Devel] pua callback
>>>>
>>>> Hi Sebastian,
>>>>
>>>> As Klaus said, you should not keep the etag to ensure that
>> the state
>>>> is updated, but provide the same id and pua module will
>> take care of
>>>> that.
>>>> If you however, do want get the etag or the expires from
>> the answer
>>>> in your module, you have to register a callback in pua
>> module to be
>>>> called when the reply for the message you triggered is received.
>>>>
>>>> For this, you have to register the callback in mod_init, as it is
>>>> done in modules/pua_mi/pua_mi.c file:
>>>>
>>>> if(pua.register_puacb(SCRIPT_PUBLISH,
>> scr_publ_rpl_cback, NULL)<
>>>> 0)
>>>> {
>>>> LM_ERR("Could not register callback\n");
>>>> return -1;
>>>> }
>>>> where SCRIPT_PUBLISH should be a new type of source generating
>>>> messages, that has to be defined in pua module.
>>>> And then define the scr_publ_rpl_callback which has the prototype:
>>>> int scr_publ_rpl_cback( ua_pres_t* hentity, struct
>> sip_msg* reply);
>>>> The first parameter is a structure with infos about the presentity
>>>> and the second is the reply message.
>>>>
>>>> regards,
>>>> Anca Vamanu
>>>>
>>>>
>>>> Klaus Darilion wrote:
>>>>
>>>>> Hi Sebastian!
>>>>>
>>>>> In the presence_dialoginfo module I do not care about the
>> etag. The
>>>>> pua module stores the etag itself and reuses it for further
>>>>>
>>>> presence requests.
>>>>
>>>>> (I think it is based on the publ->id which should be constant for
>>>>> "in-dialog" requests. Further, the type must be set to the
>>>>>
>>>> update type:
>>>>
>>>>> publ->flag|= UPDATE_TYPE;)
>>>>>
>>>>> regards
>>>>> klaus
>>>>>
>>>>> Schumann Sebastian schrieb:
>>>>>
>>>>>
>>>>>> Dear all
>>>>>>
>>>>>> I wrote a module using the pua module api to send presence
>>>>>>
>>>> messages
>>>>
>>>>>> directly from the script and it all works fine. I have
>>>>>>
>>>> only problems
>>>>
>>>>>> to use the ETag from the answer, I can somehow not process
>>>>>>
>>>> the answer
>>>>
>>>>>> at all. I tried to look at pua_mi and other pua modules
>> but cannot
>>>>>> see any light there how to process the answer. I know
>> pua callback
>>>>>> does it but do not know how, I am lost within the structures.
>>>>>>
>>>>>> It is important though because otherwise if a publish is
>>>>>>
>>>> sent and the
>>>>
>>>>>> state is updated, there is no acutal update but two
>>>>>>
>>>> presence states
>>>>
>>>>>> from one client.
>>>>>>
>>>>>> Can someone (Anca?) help me and provide some more info about the
>>>>>> proper use of PUA to process the answer and E-Tag
>>>>>>
>>>> respectively properly?
>>>>
>>>>>>
>>>>>> Thanks a lot!
>>>>>>
>>>>>> Sebastian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>
>>>>>> ---
>>>>>>
>>>>>> _______________________________________________
>>>>>> Devel mailing list
>>>>>> Devel at lists.kamailio.org
>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>>>
>>>>>
>>>>>
>>>>
>>
More information about the Devel
mailing list