Hello Ivan,

good point, I have clarified the description on 
www.kamailio.org<http://www.kamailio.org>.

About your question, there is one user of this function in the pua module. Have 
a look to line 1069 and following in pua/send_subscribe.c.

So you need to take care of the memory management of the dlg_t struct, with the 
free_dlg() function as you already guessed.

Cheers,

Henning

Am 09.05.19 um 09:38 schrieb Ivan Ribakov:
Thanks for your feedback Henning.

Regarding dev mailing list, I’ve considered posting here but the description of 
the mailing list pretty clearly states it’s purpose (“the list is dedicated for 
discussions related to development version and next steps of Kamailio”) and I 
didn’t feel like my question belonged here. If that’s not the case, it would be 
nice if the list’s purpose description could be amended to include all 
code-related queries, including those coming from users, not just Kamailio 
developers.

Regarding my question - since my last email I have found the cause of the 
problem which was unrelated to the code I was using (incorrect SIPp scenario 
was generating response with a different Via header branch, hence it was 
discarded). But in the process of debugging, I realised that using 
tmb.t_request_outside() has some shared memory implications, in particular that 
it allocates memory for the dlg_t dialog struct. I can see that tm_load.h 
interface exposes free_dlg() function but what I’m not sure about is whether I 
have to call it myself, or does tm module takes care of that?

Regarding dlg_transfer.c - thanks for pointing it out, I’ll consider using it 
as a reference in the future. But I’m still feeling a bit at a loss as there 
seems to be no other code that uses tmb.t_request_outside() / 
tmb.t_request_within() specifically, hence my doubts about memory management 
etc.

Regards,
Ivan


On 9 May 2019, at 07:58, Henning Westerholt 
<[email protected]<mailto:[email protected]>> wrote:


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 
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services




_______________________________________________
Kamailio (SER) - Development Mailing List
[email protected]<mailto:[email protected]>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev


--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
_______________________________________________
Kamailio (SER) - Development Mailing List
[email protected]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to