load the module and set few parameters, you don't
have to track calls
with dialog module, so no runtime overload.
Cheers,
Daniel
because
the
idea was that sr will use ser tm module. if t_uac is difficult to
implement in ser tm module or if that would still not make t_uac_dlg to
work via rpc, then i guess i need to wait until mi_rpc supports
async mi
functions.
t_uac_dlg was removed long time ago from ser (that's also were
kamailio/openser inherited it from). There were 2 versions one working
with the fifo and another one with unixsocks, but both were removed when
we switched to RPC.
IIRC the idea was to make a separate module implementing it, but we
stopped when sems got its own sip stack (sems was the only known user).
t_uac exists in sr tm and is exported by the tm api. t_uac_dlg is/was
just a wrapper reading and writing to fifo/unixsock/mi and then calling
t_uac.
It should be possible to revive the t_uac_dlg implementation in a
separate module but the problem is that proper async support is easy to
implement only using the old fifo (and passing a "reply" fifo) or
datagram sockets (the async support in mi_xmlrpc is a joke: it just
waits in a loop, _polling_ a shared memory variable until someone writes
it or timeouts and then sends the xmlrpc reply).
That being said there is some work on an application server interface
using the binrpc protocol (see
ftp://ftp.iptel.org/pub/sug/sersum.pdf
and
http://tracker.iptel.org/browse/SER-347), which far exceeds
t_uac_dlg
needs. From what I know all the required tm changes are in-place, we
only have to wait for Bogdan Pintea to commit the rest of it.
otherwise things thus look pretty good to me.
thanks for your efforts.
Thanks a lot for testing.
Andrei
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev