Hello,
after never really having to use sip-router's tm callbacks but
Kamailio's only, I did some tests today and found a few issues I'd like
to discuss followingly:
1) In Kamailio, certain callbacks (namely TMCB_RESPONSE_PRE_OUT,
TMCB_RESPONSE_OUT, and TMCB_REQUEST_BUILT) provided the entire processed
message (i.e., after headers were modified) in tmcb_params->extra1 as
*str. AFAICS, sr's equivalent to that parameter is send_buf in the
tmcb_params structure. However, the only sr callbacks that do provide
the processed messages are TMCB_REQUEST_SENT and TMCB_RESPONSE_SENT
which, had no perfect correspondency in Kamailio (*_OUT callbacks would
not be called for retransmissions).
Technically, this makes complete sense because the two *_SENT callbacks
and the send_buf variable are available only when WITH_ONSEND is
defined. Also, I noticed that these callbacks are handled through
run_onsend_callbacks[2]() instead of run_trans_callbacks(). Only the
former fill send_buf and hence pass processed messages as part of the
callback.
Why do these TMCB_ONSEND callbacks need such special care? Would it be
feasible to pass processed messages for other callbacks somehow too?
Ideally, I'd like to see that happen for every callback where a
processed message is supposed to be available, i.e., all *_OUT and
*_READY callbacks.
2) Is there a special reason why TMCB_REQUEST_OUT is missing? Kamailio
used to have it although it's name TMCB_REQUEST_BUILT was a little
misleading.
3) Similarly, how hard would it be to implement TMCB_REQUEST_READY?
Kamailio lacked that but I'd truly love to see it exist in sr.
Sorry for the abundance of questions and lack of solutions -- when I had
just started to get a rough idea of how Kamailio's tm module works
internally, here comes sr and forces me to start over again. :)
TIA and
cheers,
--Timo
Show replies by date