7 Mar
2024
7 Mar
'24
6:46 p.m.
Hi kamailio community,
I have an issue with a Kamailio 5.7. It's listening both in TCP and
UDP. In my scenario requests arrive from devices on TCP, but I want to
forward to the next hops on UDP. I am avoiding using any type of DNS
resolution; since I am always forwarding to predefined next hops I am
using the dispatcher module (defined with the IP addresses and
transport=udp) or I wrote config files using t_relay_to_udp or
t_relay_to with a udp: followed by IP address. I never set up FQDNS
only IP addresses and in all of them I explicitly mention UDP.
In all of these scenarios I have tried Kamailio insists in trying to use
TCP with the next hop and failing because the next_hop is only UDP. I
guess because the message arrived using TCP Kamilio does that but I find
the behavior very confusing.
I nailed down that in my situation its the tm module function
prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the one
that missbehaves. The documentation of the function says literraly :
"* t->uac[branch].request.dst will be filled if next_hop !=0 with the result
* of the DNS resolution (next_hop, fproto and fsocket).
* If next_hop is 0 all the dst members except the send_flags are read-only
* (send_flags it's updated) and are supposed to be pre-filled."
I found out that even when next_hop is 0 the function changes the
t->uac[branch].request.dst proto, socket etc. its there that the
kamailio takes the wrong decision, until that function is called within
add_auc, the destination proto or the fproto etc is always 1 (UDP)
which is what I am trying to force from the config file or the
dispatcher definition (I tried both ways). But after calling that
function then it comes as a 2 (TCP)
The problematic function is a monster of 500 lines and I would like to
avoid having to understand it. Since I think the scenario is not so
unusual I just want to ask if maybe I am missing something that I should
do to avoid the Kamailio to select TCP and in order to have the tm
module respecting my preference for UDP (either with dispatcher module
and the transport param or with t_relay_to or t_relay_to_udp I don't
care the way).
Any hints are welcome.
Best regards
alberto
7 Mar
7 Mar
7:43 p.m.
You must be doing something essentially wrong if it came down to checking C
functions for something as trivial as transport conversion..
Are you sure you have a UDP listening socket?
kamcmd corex.list_sockets
Result of:
kamcmd dispatcher.list
Have you tried forcing the send socket?
https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_forced_s…
Cheers
On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users <
sr-users(a)lists.kamailio.org> wrote:
Hi kamailio community,
I have an issue with a Kamailio 5.7. It's listening both in TCP and
UDP. In my scenario requests arrive from devices on TCP, but I want to
forward to the next hops on UDP. I am avoiding using any type of DNS
resolution; since I am always forwarding to predefined next hops I am
using the dispatcher module (defined with the IP addresses and
transport=udp) or I wrote config files using t_relay_to_udp or
t_relay_to with a udp: followed by IP address. I never set up FQDNS
only IP addresses and in all of them I explicitly mention UDP.
In all of these scenarios I have tried Kamailio insists in trying to use
TCP with the next hop and failing because the next_hop is only UDP. I
guess because the message arrived using TCP Kamilio does that but I find
the behavior very confusing.
I nailed down that in my situation its the tm module function
prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the one
that missbehaves. The documentation of the function says literraly :
"* t->uac[branch].request.dst will be filled if next_hop !=0 with the
result
* of the DNS resolution (next_hop, fproto and fsocket).
* If next_hop is 0 all the dst members except the send_flags are
read-only
* (send_flags it's updated) and are supposed to be pre-filled."
I found out that even when next_hop is 0 the function changes the
t->uac[branch].request.dst proto, socket etc. its there that the
kamailio takes the wrong decision, until that function is called within
add_auc, the destination proto or the fproto etc is always 1 (UDP)
which is what I am trying to force from the config file or the
dispatcher definition (I tried both ways). But after calling that
function then it comes as a 2 (TCP)
The problematic function is a monster of 500 lines and I would like to
avoid having to understand it. Since I think the scenario is not so
unusual I just want to ask if maybe I am missing something that I should
do to avoid the Kamailio to select TCP and in order to have the tm
module respecting my preference for UDP (either with dispatcher module
and the transport param or with t_relay_to or t_relay_to_udp I don't
care the way).
Any hints are welcome.
Best regards
alberto
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe:
8:48 p.m.
Hi Sergiu,
yes I am pretty sure something is going wrong.
I do have kamailio listening udp sockets and also the dispatcher is on
UDP doing SIP OPTIONS over UDP all the time without any problem.
I have not tried forcing the socket I tried to find out why kamailio is
trying to use TCP with the targets even when I use t_relay_to_udp and
that's how I ended up finding that function which claims not to do
something if next_hop is 0 but doing it nevertheless (which I guess is
something going wrong in general in Kamailio not in particular in my setup).
I will try forcing the socket, but that crazy tm module function
rewrites the socket was already given as a destination (yes I already
checked that in the C code before!)
Best regards
alberto
El 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
You must be doing something essentially wrong if it
came down to
checking C functions for something as trivial as transport conversion..
Are you sure you have a UDP listening socket?
kamcmd corex.list_sockets
Result of:
kamcmd dispatcher.list
Have you tried forcing the send socket?
https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_forced_s…
Cheers
On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hi kamailio community,
I have an issue with a Kamailio 5.7. It's listening both in TCP and
UDP. In my scenario requests arrive from devices on TCP, but I
want to
forward to the next hops on UDP. I am avoiding using any type of DNS
resolution; since I am always forwarding to predefined next hops I am
using the dispatcher module (defined with the IP addresses and
transport=udp) or I wrote config files using t_relay_to_udp or
t_relay_to with a udp: followed by IP address. I never set up FQDNS
only IP addresses and in all of them I explicitly mention UDP.
In all of these scenarios I have tried Kamailio insists in trying
to use
TCP with the next hop and failing because the next_hop is only
UDP. I
guess because the message arrived using TCP Kamilio does that but
I find
the behavior very confusing.
I nailed down that in my situation its the tm module function
prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being
the one
that missbehaves. The documentation of the function says literraly :
"* t->uac[branch].request.dst will be filled if next_hop !=0 with
the result
* of the DNS resolution (next_hop, fproto and fsocket).
* If next_hop is 0 all the dst members except the send_flags are
read-only
* (send_flags it's updated) and are supposed to be pre-filled."
I found out that even when next_hop is 0 the function changes the
t->uac[branch].request.dst proto, socket etc. its there that the
kamailio takes the wrong decision, until that function is called
within
add_auc, the destination proto or the fproto etc is always 1 (UDP)
which is what I am trying to force from the config file or the
dispatcher definition (I tried both ways). But after calling that
function then it comes as a 2 (TCP)
The problematic function is a monster of 500 lines and I would
like to
avoid having to understand it. Since I think the scenario is not so
unusual I just want to ask if maybe I am missing something that I
should
do to avoid the Kamailio to select TCP and in order to have the tm
module respecting my preference for UDP (either with dispatcher
module
and the transport param or with t_relay_to or t_relay_to_udp I don't
care the way).
Any hints are welcome.
Best regards
alberto
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender!
Edit mailing list options or unsubscribe:
11:44 p.m.
If you just strip the incoming ;transport=tcp attribute, I think all should be well when
t_relay() consumes the modified RURI.
On 7 Mar 2024, at 12:48, Alberto Diez via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hi Sergiu,
yes I am pretty sure something is going wrong.
I do have kamailio listening udp sockets and also the dispatcher is on UDP doing SIP
OPTIONS over UDP all the time without any problem.
I have not tried forcing the socket I tried to find out why kamailio is trying to use TCP
with the targets even when I use t_relay_to_udp and that's how I ended up finding that
function which claims not to do something if next_hop is 0 but doing it nevertheless
(which I guess is something going wrong in general in Kamailio not in particular in my
setup).
I will try forcing the socket, but that crazy tm module function rewrites the socket was
already given as a destination (yes I already checked that in the C code before!)
Best regards
alberto
El 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
You must be doing something essentially wrong if
it came down to checking C functions for something as trivial as transport conversion..
Are you sure you have a UDP listening socket?
kamcmd corex.list_sockets
Result of:
kamcmd dispatcher.list
Have you tried forcing the send socket?
https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_forced_s…
Cheers
On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hi kamailio community,
I have an issue with a Kamailio 5.7. It's listening both in TCP and
UDP. In my scenario requests arrive from devices on TCP, but I want to
forward to the next hops on UDP. I am avoiding using any type of DNS
resolution; since I am always forwarding to predefined next hops I am
using the dispatcher module (defined with the IP addresses and
transport=udp) or I wrote config files using t_relay_to_udp or
t_relay_to with a udp: followed by IP address. I never set up FQDNS
only IP addresses and in all of them I explicitly mention UDP.
In all of these scenarios I have tried Kamailio insists in trying to use
TCP with the next hop and failing because the next_hop is only UDP. I
guess because the message arrived using TCP Kamilio does that but I find
the behavior very confusing.
I nailed down that in my situation its the tm module function
prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the one
that missbehaves. The documentation of the function says literraly :
"* t->uac[branch].request.dst will be filled if next_hop !=0 with the result
* of the DNS resolution (next_hop, fproto and fsocket).
* If next_hop is 0 all the dst members except the send_flags are read-only
* (send_flags it's updated) and are supposed to be pre-filled."
I found out that even when next_hop is 0 the function changes the
t->uac[branch].request.dst proto, socket etc. its there that the
kamailio takes the wrong decision, until that function is called within
add_auc, the destination proto or the fproto etc is always 1 (UDP)
which is what I am trying to force from the config file or the
dispatcher definition (I tried both ways). But after calling that
function then it comes as a 2 (TCP)
The problematic function is a monster of 500 lines and I would like to
avoid having to understand it. Since I think the scenario is not so
unusual I just want to ask if maybe I am missing something that I should
do to avoid the Kamailio to select TCP and in order to have the tm
module respecting my preference for UDP (either with dispatcher module
and the transport param or with t_relay_to or t_relay_to_udp I don't
care the way).
Any hints are welcome.
Best regards
alberto
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
8 Mar
8 Mar
12:27 p.m.
thanks Alex. Sadly in my case the Request-URI does not contain a
transport parameter.
So the call to prepare_new_uac() function is deciding based on another
parameter (don't know which, was trying to avoid investigating that
because the function is a pain and not commented). I think its quite
counter-intuitive, and for me a bug, that you call t_relay_to_udp and
Kamailio tries to connect over TCP.... Same if its dispatcher module
asking to dispatch to UDP and t_relay decides TCP (because it calls this
same function at the end) etc.
By the way I also tried forcing the socket from the config file to be
the UDP one, and nothing. Prior to calling prepare_new_uac the socket is
the UDP one, but after calling that function it has changed the socket
to a TCP one.
Would be great if anyone has a hint what could be going on and why
prepare_new_uac changes the socket and based on what param
Best regards
alberto
El 07/03/2024 a las 21:44, Alex Balashov via sr-users escribió:
If you just strip the incoming ;transport=tcp
attribute, I think all should be well when t_relay() consumes the modified RURI.
> On 7 Mar 2024, at 12:48, Alberto Diez via sr-users
<sr-users(a)lists.kamailio.org> wrote:
>
> Hi Sergiu,
> yes I am pretty sure something is going wrong.
> I do have kamailio listening udp sockets and also the dispatcher is on UDP doing SIP
OPTIONS over UDP all the time without any problem.
> I have not tried forcing the socket I tried to find out why kamailio is trying to use
TCP with the targets even when I use t_relay_to_udp and that's how I ended up finding
that function which claims not to do something if next_hop is 0 but doing it nevertheless
(which I guess is something going wrong in general in Kamailio not in particular in my
setup).
> I will try forcing the socket, but that crazy tm module function rewrites the socket
was already given as a destination (yes I already checked that in the C code before!)
> Best regards
> alberto
> El 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
>> You must be doing something essentially wrong if it came down to checking C
functions for something as trivial as transport conversion..
>>
>> Are you sure you have a UDP listening socket?
>> kamcmd corex.list_sockets
>>
>> Result of:
>> kamcmd dispatcher.list
>>
>> Have you tried forcing the send socket?
>>
https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_forced_s…
>>
>> Cheers
>>
>> On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users
<sr-users(a)lists.kamailio.org> wrote:
>> Hi kamailio community,
>>
>> I have an issue with a Kamailio 5.7. It's listening both in TCP and
>> UDP. In my scenario requests arrive from devices on TCP, but I want to
>> forward to the next hops on UDP. I am avoiding using any type of DNS
>> resolution; since I am always forwarding to predefined next hops I am
>> using the dispatcher module (defined with the IP addresses and
>> transport=udp) or I wrote config files using t_relay_to_udp or
>> t_relay_to with a udp: followed by IP address. I never set up FQDNS
>> only IP addresses and in all of them I explicitly mention UDP.
>>
>> In all of these scenarios I have tried Kamailio insists in trying to use
>> TCP with the next hop and failing because the next_hop is only UDP. I
>> guess because the message arrived using TCP Kamilio does that but I find
>> the behavior very confusing.
>>
>> I nailed down that in my situation its the tm module function
>> prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the one
>> that missbehaves. The documentation of the function says literraly :
>>
>> "* t->uac[branch].request.dst will be filled if next_hop !=0 with the
result
>> * of the DNS resolution (next_hop, fproto and fsocket).
>> * If next_hop is 0 all the dst members except the send_flags are read-only
>> * (send_flags it's updated) and are supposed to be pre-filled."
>>
>> I found out that even when next_hop is 0 the function changes the
>> t->uac[branch].request.dst proto, socket etc. its there that the
>> kamailio takes the wrong decision, until that function is called within
>> add_auc, the destination proto or the fproto etc is always 1 (UDP)
>> which is what I am trying to force from the config file or the
>> dispatcher definition (I tried both ways). But after calling that
>> function then it comes as a 2 (TCP)
>>
>> The problematic function is a monster of 500 lines and I would like to
>> avoid having to understand it. Since I think the scenario is not so
>> unusual I just want to ask if maybe I am missing something that I should
>> do to avoid the Kamailio to select TCP and in order to have the tm
>> module respecting my preference for UDP (either with dispatcher module
>> and the transport param or with t_relay_to or t_relay_to_udp I don't
>> care the way).
>>
>> Any hints are welcome.
>>
>> Best regards
>>
>> alberto
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the
sender!
>> Edit mailing list options or unsubscribe:
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
sender!
> Edit mailing list options or unsubscribe:
1:38 p.m.
Hello,
this sound indeed strange, as this is used from many people without any problems. Its not
expected to use C programming to alter the message transport for relaying.
If you can reproduce and minimize the problem towards a small test cfg and a test message,
it would be great if you could open an issue in our tracker.
Cheers,
Henning
-----Original Message-----
From: Alberto Diez via sr-users <sr-users(a)lists.kamailio.org>
Sent: Freitag, 8. März 2024 10:28
To: sr-users(a)lists.kamailio.org
Cc: Alberto Diez <alberto-lists(a)mobileplots.com>
Subject: [SR-Users] Re: from TCP to UDP and Kamailio doing it wrong
thanks Alex. Sadly in my case the Request-URI does not contain a transport
parameter.
So the call to prepare_new_uac() function is deciding based on another
parameter (don't know which, was trying to avoid investigating that because
the function is a pain and not commented). I think its quite counter-intuitive,
and for me a bug, that you call t_relay_to_udp and Kamailio tries to connect
over TCP.... Same if its dispatcher module asking to dispatch to UDP and
t_relay decides TCP (because it calls this same function at the end) etc.
By the way I also tried forcing the socket from the config file to be the UDP
one, and nothing. Prior to calling prepare_new_uac the socket is the UDP one,
but after calling that function it has changed the socket to a TCP one.
Would be great if anyone has a hint what could be going on and why
prepare_new_uac changes the socket and based on what param
Best regards
alberto
El 07/03/2024 a las 21:44, Alex Balashov via sr-users escribió:
sender!
If you just strip the incoming ;transport=tcp
attribute, I think all should be
well when t_relay() consumes the modified RURI.
> On 7 Mar 2024, at 12:48, Alberto Diez via sr-users <sr-
users(a)lists.kamailio.org> wrote:
>
> Hi Sergiu,
> yes I am pretty sure something is going wrong.
> I do have kamailio listening udp sockets and also the dispatcher is on UDP
doing SIP OPTIONS over UDP all the time without any problem.
> I have not tried forcing the socket I tried
to find out why kamailio is trying to
use TCP with the targets even when I use t_relay_to_udp and that's how I
ended up finding that function which claims not to do something if next_hop
is 0 but doing it nevertheless (which I guess is something going wrong in
general in Kamailio not in particular in my setup).
> I will try forcing the socket, but that crazy
tm module function
> rewrites the socket was already given as a destination (yes I already
> checked that in the C code before!) Best regards alberto El
> 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
>> You must be doing something essentially wrong if it came down to
checking C functions for something as trivial as transport conversion..
>>
>> Are you sure you have a UDP listening socket?
>> kamcmd corex.list_sockets
>>
>> Result of:
>> kamcmd dispatcher.list
>>
>> Have you tried forcing the send socket?
>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_f
>> orced_send_socket
>>
>> Cheers
>>
>> On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users <sr-
users(a)lists.kamailio.org> wrote:
>> Hi kamailio community,
>>
>> I have an issue with a Kamailio 5.7. It's listening both in TCP and
>> UDP. In my scenario requests arrive from devices on TCP, but I want
>> to forward to the next hops on UDP. I am avoiding using any type of
>> DNS resolution; since I am always forwarding to predefined next hops
>> I am using the dispatcher module (defined with the IP addresses and
>> transport=udp) or I wrote config files using t_relay_to_udp or
>> t_relay_to with a udp: followed by IP address. I never set up FQDNS
>> only IP addresses and in all of them I explicitly mention UDP.
>>
>> In all of these scenarios I have tried Kamailio insists in trying to
>> use TCP with the next hop and failing because the next_hop is only
>> UDP. I guess because the message arrived using TCP Kamilio does that
>> but I find the behavior very confusing.
>>
>> I nailed down that in my situation its the tm module function
>> prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the
>> one that missbehaves. The documentation of the function says literraly :
>>
>> "* t->uac[branch].request.dst will be filled if next_hop !=0 with the
result
>> * of the DNS resolution (next_hop, fproto and fsocket).
>> * If next_hop is 0 all the dst members except the send_flags are read-
only
>> * (send_flags it's updated) and
are supposed to be pre-filled."
>>
>> I found out that even when next_hop is 0 the function changes the
>> t->uac[branch].request.dst proto, socket etc. its there that the
>> kamailio takes the wrong decision, until that function is called
>> within add_auc, the destination proto or the fproto etc is always 1
>> (UDP) which is what I am trying to force from the config file or the
>> dispatcher definition (I tried both ways). But after calling that
>> function then it comes as a 2 (TCP)
>>
>> The problematic function is a monster of 500 lines and I would like
>> to avoid having to understand it. Since I think the scenario is not
>> so unusual I just want to ask if maybe I am missing something that I
>> should do to avoid the Kamailio to select TCP and in order to have
>> the tm module respecting my preference for UDP (either with
>> dispatcher module and the transport param or with t_relay_to or
>> t_relay_to_udp I don't care the way).
>>
>> Any hints are welcome.
>>
>> Best regards
>>
>> alberto
>>
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions To
>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the
sender!
> Edit
mailing list options or unsubscribe:
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions To
> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
2:01 p.m.
Hi Henning,
yes as soon as I solve it I will try to give you a config and a sipp
script that shows you the issue. It seems its in the function
build_req_buf_from_sip_req (modules/tm/msg_translator.c) that if you
have a flag in the message that says FL_TCP_MTU_FB and your message is
larger than a given MTU for UDP that you can define in the core config
it will change you to TCP even if you have used t_relay_to_udp so I am
trying to find out why my message has that flag and what's the value of
that MTU parameter etc.
I just explain it here so that in the future someone else has the
problem kamilio all of a sudden deciding TCP when it should have been
UDP, maybe its because of this flag, config parameter and crazy behavior
(if I would have used t_relay maybe not so crazy but I used
t_relay_to_udp explicitly... so quite crazy that instead of returning an
error or something it tries TCP).
Best regards
alberto
El 08/03/2024 a las 11:38, Henning Westerholt escribió:
Hello,
this sound indeed strange, as this is used from many people without any problems. Its not
expected to use C programming to alter the message transport for relaying.
If you can reproduce and minimize the problem towards a small test cfg and a test
message, it would be great if you could open an issue in our tracker.
Cheers,
Henning
> -----Original Message-----
> From: Alberto Diez via sr-users <sr-users(a)lists.kamailio.org>
> Sent: Freitag, 8. März 2024 10:28
> To: sr-users(a)lists.kamailio.org
> Cc: Alberto Diez <alberto-lists(a)mobileplots.com>
> Subject: [SR-Users] Re: from TCP to UDP and Kamailio doing it wrong
>
> thanks Alex. Sadly in my case the Request-URI does not contain a transport
> parameter.
>
> So the call to prepare_new_uac() function is deciding based on another
> parameter (don't know which, was trying to avoid investigating that because
> the function is a pain and not commented). I think its quite counter-intuitive,
> and for me a bug, that you call t_relay_to_udp and Kamailio tries to connect
> over TCP.... Same if its dispatcher module asking to dispatch to UDP and
> t_relay decides TCP (because it calls this same function at the end) etc.
>
> By the way I also tried forcing the socket from the config file to be the UDP
> one, and nothing. Prior to calling prepare_new_uac the socket is the UDP one,
> but after calling that function it has changed the socket to a TCP one.
>
> Would be great if anyone has a hint what could be going on and why
> prepare_new_uac changes the socket and based on what param
>
> Best regards
>
> alberto
>
> El 07/03/2024 a las 21:44, Alex Balashov via sr-users escribió:
>> If you just strip the incoming ;transport=tcp attribute, I think all should be
> well when t_relay() consumes the modified RURI.
>>> On 7 Mar 2024, at 12:48, Alberto Diez via sr-users <sr-
> users(a)lists.kamailio.org> wrote:
>>> Hi Sergiu,
>>> yes I am pretty sure something is going wrong.
>>> I do have kamailio listening udp sockets and also the dispatcher is on UDP
> doing SIP OPTIONS over UDP all the time without any problem.
>>> I have not tried forcing the socket I tried to find out why kamailio is
trying to
> use TCP with the targets even when I use t_relay_to_udp and that's how I
> ended up finding that function which claims not to do something if next_hop
> is 0 but doing it nevertheless (which I guess is something going wrong in
> general in Kamailio not in particular in my setup).
>>> I will try forcing the socket, but that crazy tm module function
>>> rewrites the socket was already given as a destination (yes I already
>>> checked that in the C code before!) Best regards alberto El
>>> 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
>>>> You must be doing something essentially wrong if it came down to
> checking C functions for something as trivial as transport conversion..
>>>> Are you sure you have a UDP listening socket?
>>>> kamcmd corex.list_sockets
>>>>
>>>> Result of:
>>>> kamcmd dispatcher.list
>>>>
>>>> Have you tried forcing the send socket?
>>>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_f
>>>> orced_send_socket
>>>>
>>>> Cheers
>>>>
>>>> On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users <sr-
> users(a)lists.kamailio.org> wrote:
>>>> Hi kamailio community,
>>>>
>>>> I have an issue with a Kamailio 5.7. It's listening both in TCP and
>>>> UDP. In my scenario requests arrive from devices on TCP, but I want
>>>> to forward to the next hops on UDP. I am avoiding using any type of
>>>> DNS resolution; since I am always forwarding to predefined next hops
>>>> I am using the dispatcher module (defined with the IP addresses and
>>>> transport=udp) or I wrote config files using t_relay_to_udp or
>>>> t_relay_to with a udp: followed by IP address. I never set up FQDNS
>>>> only IP addresses and in all of them I explicitly mention UDP.
>>>>
>>>> In all of these scenarios I have tried Kamailio insists in trying to
>>>> use TCP with the next hop and failing because the next_hop is only
>>>> UDP. I guess because the message arrived using TCP Kamilio does that
>>>> but I find the behavior very confusing.
>>>>
>>>> I nailed down that in my situation its the tm module function
>>>> prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the
>>>> one that missbehaves. The documentation of the function says literraly
:
>>>>
>>>> "* t->uac[branch].request.dst will be filled if next_hop !=0 with
the result
>>>> * of the DNS resolution (next_hop, fproto and fsocket).
>>>> * If next_hop is 0 all the dst members except the send_flags are
read-
> only
>>>> * (send_flags it's updated) and are supposed to be
pre-filled."
>>>>
>>>> I found out that even when next_hop is 0 the function changes the
>>>> t->uac[branch].request.dst proto, socket etc. its there that the
>>>> kamailio takes the wrong decision, until that function is called
>>>> within add_auc, the destination proto or the fproto etc is always 1
>>>> (UDP) which is what I am trying to force from the config file or the
>>>> dispatcher definition (I tried both ways). But after calling that
>>>> function then it comes as a 2 (TCP)
>>>>
>>>> The problematic function is a monster of 500 lines and I would like
>>>> to avoid having to understand it. Since I think the scenario is not
>>>> so unusual I just want to ask if maybe I am missing something that I
>>>> should do to avoid the Kamailio to select TCP and in order to have
>>>> the tm module respecting my preference for UDP (either with
>>>> dispatcher module and the transport param or with t_relay_to or
>>>> t_relay_to_udp I don't care the way).
>>>>
>>>> Any hints are welcome.
>>>>
>>>> Best regards
>>>>
>>>> alberto
>>>>
>>>> __________________________________________________________
>>>> Kamailio - Users Mailing List - Non Commercial Discussions To
>>>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply only to
the
> sender!
>>>> Edit mailing list options or unsubscribe:
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions To
>>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to
the
> sender!
>>> Edit mailing list options or unsubscribe:
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
> send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the
> sender!
> Edit mailing list options or unsubscribe:
2:24 p.m.
Hello,
check your config if the mtu-related parameters are set:
- https://www.kamailio.org/wikidocs/cookbooks/5.7.x/core/#udp_mtu
Be sure you grep all the files if the config is split in many.
There is also a function that could result in switching protocols:
-
https://www.kamailio.org/wikidocs/cookbooks/5.7.x/core/#udp_mtu_try_protopr…
Cheers,
Daniel
On 08.03.24 12:01, Alberto Diez via sr-users wrote:
Hi Henning,
yes as soon as I solve it I will try to give you a config and a sipp
script that shows you the issue. It seems its in the function
build_req_buf_from_sip_req (modules/tm/msg_translator.c) that if you
have a flag in the message that says FL_TCP_MTU_FB and your message is
larger than a given MTU for UDP that you can define in the core config
it will change you to TCP even if you have used t_relay_to_udp so I
am trying to find out why my message has that flag and what's the
value of that MTU parameter etc.
I just explain it here so that in the future someone else has the
problem kamilio all of a sudden deciding TCP when it should have been
UDP, maybe its because of this flag, config parameter and crazy
behavior (if I would have used t_relay maybe not so crazy but I used
t_relay_to_udp explicitly... so quite crazy that instead of returning
an error or something it tries TCP).
Best regards
alberto
El 08/03/2024 a las 11:38, Henning Westerholt escribió:
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com
Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com
Hello,
this sound indeed strange, as this is used from many people without
any problems. Its not expected to use C programming to alter the
message transport for relaying.
If you can reproduce and minimize the problem towards a small test
cfg and a test message, it would be great if you could open an issue
in our tracker.
Cheers,
Henning
> -----Original Message-----
> From: Alberto Diez via sr-users <sr-users(a)lists.kamailio.org>
> Sent: Freitag, 8. März 2024 10:28
> To: sr-users(a)lists.kamailio.org
> Cc: Alberto Diez <alberto-lists(a)mobileplots.com>
> Subject: [SR-Users] Re: from TCP to UDP and Kamailio doing it wrong
>
> thanks Alex. Sadly in my case the Request-URI does not contain a
> transport
> parameter.
>
> So the call to prepare_new_uac() function is deciding based on another
> parameter (don't know which, was trying to avoid investigating that
> because
> the function is a pain and not commented). I think its quite
> counter-intuitive,
> and for me a bug, that you call t_relay_to_udp and Kamailio tries to
> connect
> over TCP.... Same if its dispatcher module asking to dispatch to
> UDP and
> t_relay decides TCP (because it calls this same function at the end)
> etc.
>
> By the way I also tried forcing the socket from the config file to
> be the UDP
> one, and nothing. Prior to calling prepare_new_uac the socket is the
> UDP one,
> but after calling that function it has changed the socket to a TCP one.
>
> Would be great if anyone has a hint what could be going on and why
> prepare_new_uac changes the socket and based on what param
>
> Best regards
>
> alberto
>
> El 07/03/2024 a las 21:44, Alex Balashov via sr-users escribió:
>> If you just strip the incoming ;transport=tcp attribute, I think
>> all should be
> well when t_relay() consumes the modified RURI.
>>> On 7 Mar 2024, at 12:48, Alberto Diez via sr-users <sr-
> users(a)lists.kamailio.org> wrote:
>>> Hi Sergiu,
>>> yes I am pretty sure something is going wrong.
>>> I do have kamailio listening udp sockets and also the dispatcher
>>> is on UDP
> doing SIP OPTIONS over UDP all the time without any problem.
>>> I have not tried forcing the socket I tried to find out why
>>> kamailio is trying to
> use TCP with the targets even when I use t_relay_to_udp and that's
> how I
> ended up finding that function which claims not to do something if
> next_hop
> is 0 but doing it nevertheless (which I guess is something going
> wrong in
> general in Kamailio not in particular in my setup).
>>> I will try forcing the socket, but that crazy tm module function
>>> rewrites the socket was already given as a destination (yes I already
>>> checked that in the C code before!) Best regards alberto El
>>> 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
>>>> You must be doing something essentially wrong if it came down to
> checking C functions for something as trivial as transport conversion..
>>>> Are you sure you have a UDP listening socket?
>>>> kamcmd corex.list_sockets
>>>>
>>>> Result of:
>>>> kamcmd dispatcher.list
>>>>
>>>> Have you tried forcing the send socket?
>>>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_f
>>>> orced_send_socket
>>>>
>>>> Cheers
>>>>
>>>> On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users <sr-
> users(a)lists.kamailio.org> wrote:
>>>> Hi kamailio community,
>>>>
>>>> I have an issue with a Kamailio 5.7. It's listening both in TCP and
>>>> UDP. In my scenario requests arrive from devices on TCP, but I want
>>>> to forward to the next hops on UDP. I am avoiding using any type of
>>>> DNS resolution; since I am always forwarding to predefined next hops
>>>> I am using the dispatcher module (defined with the IP addresses and
>>>> transport=udp) or I wrote config files using t_relay_to_udp or
>>>> t_relay_to with a udp: followed by IP address. I never set up FQDNS
>>>> only IP addresses and in all of them I explicitly mention UDP.
>>>>
>>>> In all of these scenarios I have tried Kamailio insists in trying to
>>>> use TCP with the next hop and failing because the next_hop is only
>>>> UDP. I guess because the message arrived using TCP Kamilio does that
>>>> but I find the behavior very confusing.
>>>>
>>>> I nailed down that in my situation its the tm module function
>>>> prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the
>>>> one that missbehaves. The documentation of the function says
>>>> literraly :
>>>>
>>>> "* t->uac[branch].request.dst will be filled if next_hop !=0
with
>>>> the result
>>>> * of the DNS resolution (next_hop, fproto and fsocket).
>>>> * If next_hop is 0 all the dst members except the send_flags
>>>> are read-
> only
>>>> * (send_flags it's updated) and are supposed to be
pre-filled."
>>>>
>>>> I found out that even when next_hop is 0 the function changes the
>>>> t->uac[branch].request.dst proto, socket etc. its there that the
>>>> kamailio takes the wrong decision, until that function is called
>>>> within add_auc, the destination proto or the fproto etc is always 1
>>>> (UDP) which is what I am trying to force from the config file or the
>>>> dispatcher definition (I tried both ways). But after calling that
>>>> function then it comes as a 2 (TCP)
>>>>
>>>> The problematic function is a monster of 500 lines and I would like
>>>> to avoid having to understand it. Since I think the scenario is not
>>>> so unusual I just want to ask if maybe I am missing something that I
>>>> should do to avoid the Kamailio to select TCP and in order to have
>>>> the tm module respecting my preference for UDP (either with
>>>> dispatcher module and the transport param or with t_relay_to or
>>>> t_relay_to_udp I don't care the way).
>>>>
>>>> Any hints are welcome.
>>>>
>>>> Best regards
>>>>
>>>> alberto
>>>>
>>>> __________________________________________________________
>>>> Kamailio - Users Mailing List - Non Commercial Discussions To
>>>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply
>>>> only to the
> sender!
>>>> Edit mailing list options or unsubscribe:
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions To
>>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply
>>> only to the
> sender!
>>> Edit mailing list options or unsubscribe:
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions To
> unsubscribe
> send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply
> only to the
> sender!
> Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only
to the sender!
Edit mailing list options or unsubscribe:
3:23 p.m.
Yes, the problem was I had udp_mtu_try_proto set to TCP as a global
parameter, I have removed that and now it behaves.
I have, on the side, also disabled use_dns_failover because that
triggers also a special behavior in those tm functions I mentioned and
gave problems when using the dispatcher version of the solution (not
with the t_relay_to_udp though)...
I am still wondering because my udp_mtu was configured to 1300 and the
message is not larger than that, but I don't want to use more time
understanding the tm module, although it would be helpful if someone did
understand it eventually :D
Best regards
alberto
El 08/03/2024 a las 12:24, Daniel-Constantin Mierla escribió:
Hello,
check your config if the mtu-related parameters are set:
- https://www.kamailio.org/wikidocs/cookbooks/5.7.x/core/#udp_mtu
Be sure you grep all the files if the config is split in many.
There is also a function that could result in switching protocols:
-
https://www.kamailio.org/wikidocs/cookbooks/5.7.x/core/#udp_mtu_try_protopr…
Cheers,
Daniel
On 08.03.24 12:01, Alberto Diez via sr-users wrote:
Hi Henning,
yes as soon as I solve it I will try to give you a config and a sipp
script that shows you the issue. It seems its in the function
build_req_buf_from_sip_req (modules/tm/msg_translator.c) that if you
have a flag in the message that says FL_TCP_MTU_FB and your message is
larger than a given MTU for UDP that you can define in the core config
it will change you to TCP even if you have used t_relay_to_udp so I
am trying to find out why my message has that flag and what's the
value of that MTU parameter etc.
I just explain it here so that in the future someone else has the
problem kamilio all of a sudden deciding TCP when it should have been
UDP, maybe its because of this flag, config parameter and crazy
behavior (if I would have used t_relay maybe not so crazy but I used
t_relay_to_udp explicitly... so quite crazy that instead of returning
an error or something it tries TCP).
Best regards
alberto
El 08/03/2024 a las 11:38, Henning Westerholt escribió:
Hello,
this sound indeed strange, as this is used from many people without
any problems. Its not expected to use C programming to alter the
message transport for relaying.
If you can reproduce and minimize the problem towards a small test
cfg and a test message, it would be great if you could open an issue
in our tracker.
Cheers,
Henning
> -----Original Message-----
> From: Alberto Diez via sr-users <sr-users(a)lists.kamailio.org>
> Sent: Freitag, 8. März 2024 10:28
> To: sr-users(a)lists.kamailio.org
> Cc: Alberto Diez <alberto-lists(a)mobileplots.com>
> Subject: [SR-Users] Re: from TCP to UDP and Kamailio doing it wrong
>
> thanks Alex. Sadly in my case the Request-URI does not contain a
> transport
> parameter.
>
> So the call to prepare_new_uac() function is deciding based on another
> parameter (don't know which, was trying to avoid investigating that
> because
> the function is a pain and not commented). I think its quite
> counter-intuitive,
> and for me a bug, that you call t_relay_to_udp and Kamailio tries to
> connect
> over TCP.... Same if its dispatcher module asking to dispatch to
> UDP and
> t_relay decides TCP (because it calls this same function at the end)
> etc.
>
> By the way I also tried forcing the socket from the config file to
> be the UDP
> one, and nothing. Prior to calling prepare_new_uac the socket is the
> UDP one,
> but after calling that function it has changed the socket to a TCP one.
>
> Would be great if anyone has a hint what could be going on and why
> prepare_new_uac changes the socket and based on what param
>
> Best regards
>
> alberto
>
> El 07/03/2024 a las 21:44, Alex Balashov via sr-users escribió:
>> If you just strip the incoming ;transport=tcp attribute, I think
>> all should be
> well when t_relay() consumes the modified RURI.
>>> On 7 Mar 2024, at 12:48, Alberto Diez via sr-users <sr-
> users(a)lists.kamailio.org> wrote:
>>> Hi Sergiu,
>>> yes I am pretty sure something is going wrong.
>>> I do have kamailio listening udp sockets and also the dispatcher
>>> is on UDP
> doing SIP OPTIONS over UDP all the time without any problem.
>>> I have not tried forcing the socket I tried to find out why
>>> kamailio is trying to
> use TCP with the targets even when I use t_relay_to_udp and that's
> how I
> ended up finding that function which claims not to do something if
> next_hop
> is 0 but doing it nevertheless (which I guess is something going
> wrong in
> general in Kamailio not in particular in my setup).
>>> I will try forcing the socket, but that crazy tm module function
>>> rewrites the socket was already given as a destination (yes I already
>>> checked that in the C code before!) Best regards alberto El
>>> 07/03/2024 a las 17:43, Sergiu Pojoga escribió:
>>>> You must be doing something essentially wrong if it came down to
> checking C functions for something as trivial as transport conversion..
>>>> Are you sure you have a UDP listening socket?
>>>> kamcmd corex.list_sockets
>>>>
>>>> Result of:
>>>> kamcmd dispatcher.list
>>>>
>>>> Have you tried forcing the send socket?
>>>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#fs_-_f
>>>> orced_send_socket
>>>>
>>>> Cheers
>>>>
>>>> On Thu, Mar 7, 2024 at 11:27 AM Alberto Diez via sr-users <sr-
> users(a)lists.kamailio.org> wrote:
>>>> Hi kamailio community,
>>>>
>>>> I have an issue with a Kamailio 5.7. It's listening both in TCP and
>>>> UDP. In my scenario requests arrive from devices on TCP, but I want
>>>> to forward to the next hops on UDP. I am avoiding using any type of
>>>> DNS resolution; since I am always forwarding to predefined next hops
>>>> I am using the dispatcher module (defined with the IP addresses and
>>>> transport=udp) or I wrote config files using t_relay_to_udp or
>>>> t_relay_to with a udp: followed by IP address. I never set up FQDNS
>>>> only IP addresses and in all of them I explicitly mention UDP.
>>>>
>>>> In all of these scenarios I have tried Kamailio insists in trying to
>>>> use TCP with the next hop and failing because the next_hop is only
>>>> UDP. I guess because the message arrived using TCP Kamilio does that
>>>> but I find the behavior very confusing.
>>>>
>>>> I nailed down that in my situation its the tm module function
>>>> prepare_new_uac (in file src/modules/tm/t_fwd.c line 119) being the
>>>> one that missbehaves. The documentation of the function says
>>>> literraly :
>>>>
>>>> "* t->uac[branch].request.dst will be filled if next_hop !=0
with
>>>> the result
>>>> * of the DNS resolution (next_hop, fproto and fsocket).
>>>> * If next_hop is 0 all the dst members except the send_flags
>>>> are read-
> only
>>>> * (send_flags it's updated) and are supposed to be
pre-filled."
>>>>
>>>> I found out that even when next_hop is 0 the function changes the
>>>> t->uac[branch].request.dst proto, socket etc. its there that the
>>>> kamailio takes the wrong decision, until that function is called
>>>> within add_auc, the destination proto or the fproto etc is always 1
>>>> (UDP) which is what I am trying to force from the config file or the
>>>> dispatcher definition (I tried both ways). But after calling that
>>>> function then it comes as a 2 (TCP)
>>>>
>>>> The problematic function is a monster of 500 lines and I would like
>>>> to avoid having to understand it. Since I think the scenario is not
>>>> so unusual I just want to ask if maybe I am missing something that I
>>>> should do to avoid the Kamailio to select TCP and in order to have
>>>> the tm module respecting my preference for UDP (either with
>>>> dispatcher module and the transport param or with t_relay_to or
>>>> t_relay_to_udp I don't care the way).
>>>>
>>>> Any hints are welcome.
>>>>
>>>> Best regards
>>>>
>>>> alberto
>>>>
>>>> __________________________________________________________
>>>> Kamailio - Users Mailing List - Non Commercial Discussions To
>>>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>>>> Important: keep the mailing list in the recipients, do not reply
>>>> only to the
> sender!
>>>> Edit mailing list options or unsubscribe:
>>> __________________________________________________________
>>> Kamailio - Users Mailing List - Non Commercial Discussions To
>>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply
>>> only to the
> sender!
>>> Edit mailing list options or unsubscribe:
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions To
> unsubscribe
> send an email to sr-users-leave(a)lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply
> only to the
> sender!
> Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only
to the sender!
Edit mailing list options or unsubscribe:
12:25 a.m.
if(proto == TCP)
$ru = $(ru{s.replace,transport=TCP,}{s.replace,transport=tcp,});
...
t_relay();
-- Alex
On 7 Mar 2024, at 10:46, Alberto Diez via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Hi kamailio community,
I have an issue with a Kamailio 5.7. It's listening both in TCP and UDP. In my
scenario requests arrive from devices on TCP, but I want to forward to the next hops on
UDP. I am avoiding using any type of DNS resolution; since I am always forwarding to
predefined next hops I am using the dispatcher module (defined with the IP addresses and
transport=udp) or I wrote config files using t_relay_to_udp or t_relay_to with a udp:
followed by IP address. I never set up FQDNS only IP addresses and in all of them I
explicitly mention UDP.
In all of these scenarios I have tried Kamailio insists in trying to use TCP with the
next hop and failing because the next_hop is only UDP. I guess because the message arrived
using TCP Kamilio does that but I find the behavior very confusing.
I nailed down that in my situation its the tm module function prepare_new_uac (in file
src/modules/tm/t_fwd.c line 119) being the one that missbehaves. The documentation of the
function says literraly :
"* t->uac[branch].request.dst will be filled if next_hop !=0 with the result
* of the DNS resolution (next_hop, fproto and fsocket).
* If next_hop is 0 all the dst members except the send_flags are read-only
* (send_flags it's updated) and are supposed to be pre-filled."
I found out that even when next_hop is 0 the function changes the
t->uac[branch].request.dst proto, socket etc. its there that the kamailio takes the
wrong decision, until that function is called within add_auc, the destination proto or
the fproto etc is always 1 (UDP) which is what I am trying to force from the config file
or the dispatcher definition (I tried both ways). But after calling that function then it
comes as a 2 (TCP)
The problematic function is a monster of 500 lines and I would like to avoid having to
understand it. Since I think the scenario is not so unusual I just want to ask if maybe I
am missing something that I should do to avoid the Kamailio to select TCP and in order to
have the tm module respecting my preference for UDP (either with dispatcher module and the
transport param or with t_relay_to or t_relay_to_udp I don't care the way).
Any hints are welcome.
Best regards
alberto
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800
262
days inactive
263
days old
9 comments
5 participants
participants (5)
-
Alberto Diez -
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt -
Sergiu Pojoga