[Kamailio-Devel] [Serdev] CVS:commitlog: sip_router/modules/tm t_cancel.c t_fwd.c t_reply.c t_reply.h t_suspend.c t_suspend.h tm.c tm_load.c tm_load.h

[Andrei Pelinescu-Onciul]

[crossposting since this is of general interest]

On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> Hi Miklos!
> 
> This sounds great. Can you make a sample function which uses the new 
> feature?

We are thinking of doing a dns_prefetch module using this.
The sip-router.cfg will look like:

route{
    ...
    dns_prefetch("uri", ROUTE_DNS_OK);
    # end of script
}

route[ROUTE_DNS_OK]{
    if (dns_error){
        ...
    }
    # continue normal processing
    # the uri was resolved and is in the dns cache
    ...
    t_relay()
    ...
}


However don't expect something quickly as everybody is quite busy and we
would still need to write a dns resolver process pool (time consuming).

Note that this is not the "final" async. solution since it's not
transparent for the script writer (scripts would have to be written in a
special way), works only with tm and it's also a little inefficient for 
dns usage.
In the long term we will have completely transparent async. support for dns
and maybe db lookups (though it's controversial if we really need it for
normal db lookups). This will take much longer and will require among
other things reviewing all the global variable use (most of the global
variables will either need to be registered or allocated in some known
special place).
If Miklos doesn't beat me to it, I'll probably start working on it only 
after the core merging is complete.

> 
> Can this also be used for DNS lookups and TCP/TLS connection setup?

Yes for DNS (see above) and in general for any route-level async processing
involving tm (e.g. lookup some part of the message in a slow DB and 
execute automatically another route when the DB responds).

It cannot be used for TCP/TLS, but it's not needed anyway. In ser TCP
connection setup and TCP send is already asynchronous, at least if
you have tcp_buf_write=yes in ser.cfg (I agree it's not a very well
chosen name :-)). TLS does not support it yet, so if you use TLS
 you should not set this option (that's why it's not yet the default).
TLS support for it requires non-trivial changes in the tcp core and it 
will probably come after the merge (it's started already but far from
 finished).
(BTW: most of the core new options documentation in ser can be found
 in NEWS)

Andrei

> 
> Further, also for Kamailio cooperation better documentation would be 
> needed. Thus, instead of writing long CVS commit messages I think it 
> would be better to write the text into the module documentation, and 
> then copy/paste it into the CVS commit.

> 
> regards
> Klaus
> 
> Miklos Tirpak wrote:
> > tirpi       2008/11/10 13:47:03 CET
> > 
> >   SER CVS Repository
> > 
> >   Modified files:
> >     modules/tm           t_cancel.c t_fwd.c t_reply.c t_reply.h 
> >                          tm.c tm_load.c tm_load.h 
> >   Added files:
> >     modules/tm           t_suspend.c t_suspend.h 
> >   Log:
> >   t_suspend() and t_continue() functions are introduced.
> >   
> >   These fuctions can be used by other modules to implement
> >   asynchronous actions: t_suspend() saves the transaction, returns its
> >   identifiers, and t_continue() continues the SIP request processing.
> >   (The transaction processing does not continue from the same point
> >   in the script, a separate route block defined by the parameter of
> >   t_continue() is executed instead. The reply lock is held during the
> >   route block execution.) FR timer is ticking while the
> >   transaction is suspended, and the transaction's failure route is
> >   executed if t_continue() is not called in time.
> >   
> >   Missing: msg lumps are saved by t_suspend() and are not updated by
> >   the subsequent t_relay(). This means that the modifications made
> >   between them are lost.
> >   
> >   Revision  Changes    Path
> >   1.32      +7 -2      sip_router/modules/tm/t_cancel.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_cancel.c.diff?r1=1.31&r2=1.32
> >   1.107     +8 -2      sip_router/modules/tm/t_fwd.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_fwd.c.diff?r1=1.106&r2=1.107
> >   1.162     +4 -4      sip_router/modules/tm/t_reply.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply.c.diff?r1=1.161&r2=1.162
> >   1.31      +7 -1      sip_router/modules/tm/t_reply.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_reply.h.diff?r1=1.30&r2=1.31
> >   1.1       +154 -0    sip_router/modules/tm/t_suspend.c (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspend.c?rev=1.1&content-type=text/plain
> >   1.1       +42 -0     sip_router/modules/tm/t_suspend.h (new)
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/t_suspend.h?rev=1.1&content-type=text/plain
> >   1.177     +3 -1      sip_router/modules/tm/tm.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm.c.diff?r1=1.176&r2=1.177
> >   1.31      +11 -1     sip_router/modules/tm/tm_load.c
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load.c.diff?r1=1.30&r2=1.31
> >   1.31      +4 -1      sip_router/modules/tm/tm_load.h
> > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/tm/tm_load.h.diff?r1=1.30&r2=1.31
> > _______________________________________________
> > Serdev mailing list
> > Serdev at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serdev
> 
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev