On Mon, Jan 13, 2003 at 02:38:37PM +0100, Jan Janak wrote:
On 13-01 14:46, Maxim Sobolev wrote:
I see, but IMO this would be not a generic
solution, as I'll have to adjust
the code for my particular needs. What I am looking for is some way to
allow it to be modified by properly constructing config file. Perhaps something
like t_on_negative() could be added, i.e. t_on_positive(): the specified
routing block will be called when the transaction is completed with positive
result but before sending final reply. What do you think?
Why is the callback not generic solution ?
Because as far as I understand then it will be called on each transaction,
or I am missing something? What if I need to apply my function only if the
reply match some pre-defined conditions (i.e. "Server: ATA.*")?
-Maxim
regards, Jan.
> > First, you need to include t_hooks.h and tm_load.h from the tm module.
> >
> > Then, you need to register a callback function. The following code snippet
> > shows how to do it:
> >
> > static int mod_init( void )
> > {
> >
> > load_tm_f load_tm;
> >
> > /* import the TM auto-loading function */
> > if ( !(load_tm=(load_tm_f)find_export("load_tm", NO_SCRIPT)))
{
> > LOG(L_ERR, "radius_acc: mod_init: can't import
load_tm\n");
> > return -1;
> > }
> > /* let the auto-loading function load all TM stuff */
> > if (load_tm( &tmb )==-1) return -1;
> >
> > /* register callback */
> > if (tmb.rngister_tmcb( TMCB_REPLY, rad_acc_onreply, 0) <= 0)
> > return -1;
> > }
> >
> > return 0;
> > }
> >
> > The mod_init function registers rad_acc_onreply function, the function will
> > be called when the tm module receives a response.
> >
> > The callback follows. Note that radius_acc module (from which the code
> > snippets were taken) registers TMCB_REPLY callback. This type of callback
> > will be called _AFTER_ the response was sent out - that means there is no way
> > how to modify it. Because of that, your module will have to register another
> > type of callback - TMCB_REPLY_IN. Such callback will be called before the
> > reply gets forwarded which means that you can modify it before it will be
> > sent out.
> >
> > See modules/tm/t_hooks.h file for more details ! There is a description of
> > the callbacks.
> >
> > /*
> > * Function that gets called on reply
> > * params: struct cell* t The callback structure
> > * struct sip_msg *msg The sip message.
> > * int code The status code
> > * void* param Passed parameter
> > * returns: nothing
> > */
> > static void rad_acc_onreply( struct cell* t, struct sip_msg *reply, int code,
> > void *param )
> > {
> >
> > struct sip_msg *rq;
> >
> > rq = t->uas.request;
> >
> > if (t->is_invite && missed_flag && isflagset( rq,
missed_flag)==1
> > && ((code>=400 && code<500) ||
code>=600))
> > rad_acc_missed_report( t, reply, code);
> >
> >
> > /* if acc enabled for flagged transaction, check if flag matches */
> > if (acc_flag && isflagset( rq, acc_flag )==-1) return;
> > /* early media is reported only if explicitely demanded,
> > other provisional responses are always dropped */
> > if (code < 200 && ! (early_media && code==183))
> > return;
> > /* negative transactions reported only if explicitely demanded */
> > if (!failed_transactions && code >=300) return;
> >
> > /* anything else, i.e., 2xx, always reported */
> > radius_log_reply(t, reply);
> >
> > }
> >
> > regards, Jan.
>
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
>
http://lists.iptel.org/mailman/listinfo/serusers
>