[Kamailio-Devel] [OpenSIPS-Devel] pua callback
Schumann Sebastian
Sebastian.Schumann at t-com.sk
Wed Oct 8 12:28:36 CEST 2008
Hi Klaus
Yes, my pres_id looks different. I suspect the following happens: My module publishes the presence state with SCRIPT_PUBLISH.URI. Then, the expires of pua publishes a "renewal", using not my but an own pres_id (the one I pasted in the previous mail). Another publish from my module uses now again my pres_id. One state gets updated, the other one remains in the table.
What I basically tried to build is a module that can publish presence state from the script. Meaning: I have a function script_publish(uri, case) that provides the presentity uri and a pre-defined case (so far open active, closed and open in-call). The cases I separate from script actions (successful register open), at invite open-call-active and so on. The idea behind is a "stateful proxy" that publishes to third party presence server the state according the call-flow through it.
I saw your approach building the pres_id, but call-id is not necessary for me. I want the user to have only one state influenced by my module. The openser.cfg takes care that
- register expires>0 publishes active
- register = 0 publishes closed
- invite/200 publishes both ressources in-call
- during in-call no register can override and so on...
So, call-id is not required for me as it is for you, the pres_uri is my unique identifier.
What I get now is exactly that: If I have two states in the pua (with my and somewhere auto-generated pres_id') I have two states in the PUBLISH. This is what must be avoided. However, if my script publishes and the user himself via the client as well (sends PUBLISH), more states in the NOTIFY would not matter and be actually good.
After running the module now for several hours, the following entries accumulated in the pua table:
| 7055 | sip:snom370 at 10.96.115.129 | SCRIPT_PUBLISH.sip:snom370 at 10.96.115.129 | 1 | 1223463846 | 1223463846 | 1024 | a.1223393212.26175.3665.8 | | | | | | 0 | | | | 0 | |
| 7058 | sip:snom370 at 10.96.115.129 | SCRIPT_PUBLISH.sip:snom370 at 10.96.115.129 | 1 | 1223463846 | 1223463846 | 1024 | a.1223393212.26175.3665.8 | | | | | | 0 | | | | 0 | |
| 7060 | sip:snom370 at 10.96.115.129 | SCRIPT_PUBLISH.sip:snom370 at 10.96.115.129 | 1 | 1223463846 | 1223463846 | 1024 | a.1223393212.26175.3665.8 | | | | | | 0 | | | | 0 | |
| 7062 | sip:snom370 at 10.96.115.129 | SCRIPT_PUBLISH.sip:snom370 at 10.96.115.129 | 1 | 1223463846 | 1223463846 | 1024 | a.1223393212.26175.3665.8 | | | | | | 0 | | | | 0 | |
| 7064 | sip:snom370 at 10.96.115.129 | SCRIPT_PUBLISH.sip:snom370 at 10.96.115.129 | 1 | 1223463846 | 1223463846 | 1024 | a.1223393212.26175.3665.8 | | | | | | 0 | | | | 0 | |
| 7066 | sip:snom370 at 10.96.115.129 | SCRIPT_PUBLISH.sip:snom370 at 10.96.115.129 | 1 | 1223463846 | 1223463846 | 1024 | a.1223393212.26175.3665.8 | | | | | | 0 | | | | 0 | |
| 7068 | sip:snom370 at 10.96.115.129 | SCRIPT_PUBLISH.sip:snom370 at 10.96.115.129 | 1 | 1223463846 | 1223463846 | 1024 | a.1223393212.26175.3665.8 | | | | | | 0 | | | | 0 |
For sure there must be a bug, but where? My module was build taking pua_mi as base and using the pua api. I was my first approach to write a module, so I might have mistakes as well. What just confuses me that after restarting OpenSER, all works fine (REGISTER etag ....1.0, INVITE afterwards .....2.1, BYE ......3.2 etc.) Only after some time pua somehow does its own things. Maybe I have also forgotten a parameter like this id I introduced after your previous mails, but I cannot see it right now.
Here my building of the "pres", maybe it gives a hint:
/* Create the publ_info_t structure */
memset(&publ, 0, sizeof(publ_info_t));
publ.pres_uri= &pres_uri;
if(body.s) {
publ.body= &body;
}
publ.event= get_event_flag(&event);
if(publ.event< 0) {
LM_ERR("unkown event\n");
}
if(content_type.len!= 1) {
publ.content_type= content_type;
}
if(! (etag.len== 1 && etag.s[0]== '.')) {
publ.etag= &etag;
}
publ.expires= exp;
/* Create ID for update requests */
n = 15 + pres_uri.len;
s = (char *)pkg_malloc(n);
LM_DBG("Allocated pkg memory for id\n");
if(s==NULL) {
LM_ERR("no more pkg mem for id (%d)\n", n);
return -1;
}
p=s;
memcpy(p, "SCRIPT_PUBLISH.", 15);
p += 15;
memcpy(p, pres_uri.s, pres_uri.len);
p += pres_uri.len;
publ.id.s = s;
publ.id.len = (int)(p-s);
if(publ.id.len > n) {
LM_ERR("Buffer size overflow for id\n");
pkg_free(s);
return -1;
}
pkg_free(s);
LM_DBG("Freed pkg memory for id\n");
/* Set flags */
publ.flag|= UPDATE_TYPE;
publ.source_flag|= SCRIPT_PUBLISH;
result = pua_send_publish(&publ);
Regards
Sebastian
> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
> Sent: Wednesday, 08. October 2008 10:28
> To: Schumann Sebastian
> Cc: Anca Vamanu; devel at lists.kamailio.org; devel at lists.opensips.org
> Subject: Re: [OpenSIPS-Devel] [Kamailio-Devel] pua callback
>
> 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