9 May
2019
9 May
'19
1:58 a.m.
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@zaleos.net<mailto:i.ribakov@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@lists.kamailio.org<mailto:sr-users@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
9 May
9 May
3:38 a.m.
New subject: [SR-Users] Sending in-dialog requests from custom module's C code
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
<hw(a)skalatan.de> 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?
--
Henning Westerholt - https://skalatan.de/blog/ <https://skalatan.de/blog/>
Kamailio services - https://skalatan.de/services <https://skalatan.de/services>
On 7 May 2019, at 16:39, Ivan Ribakov
<i.ribakov(a)zaleos.net <mailto:i.ribakov@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
<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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
6:14 a.m.
New subject: [SR-Users] Sending in-dialog requests from custom module's C code
Not sure if my previous email was posted due to me being not subscribed to the mailing
list so just writing this now (after subscribing) to make sure it gets posted.
On 9 May 2019, at 09:38, Ivan Ribakov
<i.ribakov(a)zaleos.net> wrote:
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 <hw(a)skalatan.de
<mailto:hw@skalatan.de>> 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 <i.ribakov(a)zaleos.net
<mailto:i.ribakov@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
<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(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> --
> Henning Westerholt - https://skalatan.de/blog/ <https://skalatan.de/blog/>
> Kamailio services - https://skalatan.de/services <https://skalatan.de/services>
10 May
10 May
2:03 p.m.
New subject: [SR-Users] Sending in-dialog requests from custom module's C code
Hello Ivan,
good point, I have clarified the description on
www.kamailio.org<http://www.kamailio.org>rg>.
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
<hw@skalatan.de<mailto:hw@skalatan.de>> 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
<i.ribakov@zaleos.net<mailto:i.ribakov@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@lists.kamailio.org<mailto:sr-users@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
_______________________________________________
Kamailio (SER) - Development Mailing List
sr-dev@lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
--
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
2030
days inactive
2031
days old
3 comments
2 participants
participants (2)
-
Henning Westerholt -
Ivan Ribakov