[sr-dev] [SR-Users] Sending in-dialog requests from custom module's C code

Henning Westerholt hw at skalatan.de
Thu May 9 07:58:03 CEST 2019


Hello Ivan,

this type of questions are better suited to our developer list, not the users list - adding it to CC.

I haven't looked yet that deep into your previous e-mail, but have you already looked e.g. to the dialog module? This does something similar, e.g. bridging an existing dialog. It uses uac_req_t and a TM callback. You find the implementation in dlg_transfer.c, e.g. function dlg_bridge(str *from, str *to, str *op, str *bd).

Cheers,

Henning

Am 08.05.19 um 09:26 schrieb Ivan Ribakov:
Anyone with module dev experience here who had to do something similar or used tm_load.h interface for other purposes?

On 7 May 2019, at 16:39, Ivan Ribakov <i.ribakov at zaleos.net<mailto:i.ribakov at zaleos.net>> wrote:

I’m working on a custom Kamailio module where I need to send new-dialog and in-dialog requests on timer (hence I’m being forced to generate new messages from C code).

So far I’ve been using modules/tm/tm_load.h defined interface to generate messages and handle callbacks. New dialog messages are sent and processed normally. To do that I’m:

1. Calling set_uac_request() to define request parameters
2. Calling tmb.t_request_outside() to send it outside any existing dialog


I was able to send in-dialog requests (or so I thought) in a similar fashion, but I soon realised that responses to those requests were dropped because they couldn’t be matched against any known existing transaction. I’m attaching log messages that I believe support this theory and I’ve also observed UDP retransmissions.

tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 50576 label 0 branch 0
tm [t_lookup.c:990]: t_reply_matching(): no matching transaction exists
tm [t_lookup.c:993]: t_reply_matching(): failure to match a transaction
tm [t_lookup.c:1088]: t_check_msg(): msg (0x5abcb50) id=1 global id=1 T end=(nil)
tm [t_reply.c:2195]: reply_received(): transaction not found - (branch -1)


The way I’m currently generating in-dialog requests is very similar to what tmb.t_request_outside() does, the main difference being that I do the dialog setup manually, based on the call-ID, cseq and from/to tags (I’m tracking transaction identifiers separately) and then pass resulting uac_req_t to tmb.t_request_within() - https://gist.github.com/IvanRibakov/3302cb286b1f4b786d109b406f2435a2


Now, the question part - does anyone know what I’m doing wrong/missing? As I mentioned, when looking at the generated message bodies, they look ok to me (left - initial request that started the dialog, right - first in-dialog request), so I’m guessing I’m missing some Kamailio internal steps needed to register new transaction.
<kamailio_indialog_req.png>

SIP flow (up to the point when first UDP retransmission happens)
<PastedGraphic-1.png>

I apologise in advance for the bulky question and will be extremely thankful for any guidance.

Regards,
Ivan




_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20190509/1aa948d4/attachment-0001.html>


More information about the sr-dev mailing list