[Kamailio-Devel] [OpenSIPS-Devel] pua callback

Schumann Sebastian Sebastian.Schumann at t-com.sk
Tue Oct 7 13:50:17 CEST 2008


Hi Anca

OK, so I will put the module flag name separately also into the id, not only use it as flag. Thanks for clarification.

Best regards
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