[Kamailio-Devel] [OpenSIPS-Devel] pua callback
Schumann Sebastian
Sebastian.Schumann at t-com.sk
Wed Oct 8 15:26:32 CEST 2008
Hi Klaus,
yes, you are of course right. I just started writing this module as my first one so I considered a bit 'ideal world'. The module is used in proof-of-concept state currently, but later it is important for sure.
I can achieve this behaviour anyways, from the script: Just now I check if the dialog module keeps a dialog for a user and restrict the REGISTER to publish during a call:
A REGISTERs -> PUBLISH state=open
A INVITEs -> PUBLISH state= on call
A RE- REGISTERs -> PUBLISH state=open
is forbidden. I query the database from the script for this.
I can easily query the database also for BYE: If the BYE is received, the dialog is destroyed (no table entry). If there is still a dialog for the user open, nothing happens. If not, he gets published:
A REGISTERs -> PUBLISH state=open; dialog=false (publish)
A INVITEs B -> PUBLISH state= on call
A REGISTERs -> PUBLISH state=open; dialog=true (no publish)
A INVITEs C -> PUBLISH state= on call
NEW: A BYEs B -> PUBLISH state=open; dialog = true (no publish)
NEW: A BYEs C -> PUBLISH state=open; dialog = false (publish)
My next step would be then to put this logic into the module, I know, just saw this as too complex for now :-(
I will check your idea from dialog_module maybe I will implement it. The idea is good, to keep all states in the table and then decide. The thing is just that I have to care about what is sent in NOTIFY then, so far I don't. This might be easy if my pua extension publishes to OpenSER that I can influence, but if I publish to a third party presence agent he has multiple states and I do not know how to handle it.
However, I will do both functions with OpenSER, so this is not the major problem for me. Just I considered it so far as too complex as it worked fine now :-) So my lazyness put this particular issue a bit in the future... The script is quite powerful already and as I said, I really just tried to have the functions I cannot achieve with the script so far in the module.
Sebastian
> -----Original Message-----
> From: Klaus Darilion [mailto:klaus.mailinglists at pernau.at]
> Sent: Wednesday, 08. October 2008 14:49
> 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 Sebastian!
>
> Consider the following scenario:
>
> A REGISTERs -> PUBLISH state=open
> A INVITEs -> PUBLISH state= on call
> A BYEs -> PUBLISH state=open
> A deREGISTERs -> PUBLISH state=closed
>
> so far, everthing OK
>
> A REGISTERs -> PUBLISH state=open
> A INVITEs B -> PUBLISH state= on call
> A INVITEs C -> PUBLISH state= on call
> A BYEs B -> PUBLISH state=open
>
> here we have the problem - A is still in a call. Thus, unless
> you limit the calls per user = 1 then you will publish wrong data.
>
> For example in the presence_dialoginfo module, when the
> force_single_dialog parameter is set, the module retrieves
> all the states and forwards only the most important one.
>
> regards
> klaus
>
>
>
> Schumann Sebastian schrieb:
> > 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