subject:"Re\: \[SR\-Users\] Confusion about TCP worker ports"

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Alex Balashov

Internally generated requests are a little quirky in that they’re generated by 
outside timer processes or tasks in core timers — activity that takes place 
outside the SIP worker pool. However, the expectation is that any replies will 
be processed (in this case, absorbed) by the SIP workers. 

Asymmetric signalling is permitted in SIP, so sending from source port X while 
specifying a return port of Y in the top Via hop is perfectly acceptable.

— Alex

—
Sent from mobile, with due apologies for brevity and errors.

> On Oct 29, 2020, at 3:21 PM, Noah Mehl  wrote:
> 
> Hey all,
> 
> I’m a little stuck on an implementation of a set of dispatchers via TCP.  
> There are some oddities about the behavior of the TCP source port of the 
> Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem valid. 
>  For instance, I have a dispatcher:
> 
>   "RECORDS":  [{
>   "SET":  {
>   "ID":   1,
>   "TARGETS":  [{
>   "DEST": {
>   "URI":  
> “sip:2.2.2.2:5060;transport=tcp",
>   "FLAGS":
> "AP",
>   "PRIORITY": 
> 5
>   }
>   }]
>   }
>   }]
> 
> But when Kamailio sends an OPTIONS keep alive, the source port for the worker 
> is 33940, and not 5060 (which is the TCP listen port), as received by 
> Freeswitch:
> 
> recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
>
>OPTIONS sip:2.2.2.2:5060;transport=tcp SIP/2.0
>Via: SIP/2.0/TCP 
> 1.1.1.1;branch=z9hG4bK1525.80a9e442.0
>To: 
>From: 
> ;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
>CSeq: 10 OPTIONS
>Call-ID: 3aa18693487268dc-2790@1.1.1.1
>Max-Forwards: 70
>Content-Length: 0
>User-Agent: kamailio (5.4.2 (x86_64/linux))
>
>
> 
> Also, I get weird debug messages when this tcp worker is spun up 
> (specifically about Resource temporarily unavailable):
> 
> 11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): probe 
> all, mode DS_PROBE_ALL
> 11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set #1, 
> URI sip:2.2.2.2:5060;transport=tcp
> 11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default 
> ping_from: sip:inbound-kamailio-01
> 11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default outbound 
> proxy: 
> 11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): 
> next_hop=
> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
> 11(2790) DEBUG:  [core/tcp_main.c:1993]: tcp_send(): no open tcp 
> connection found, opening new one
> 11(2790) DEBUG:  [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp 
> connection: 2.2.2.2
> 11(2790) DEBUG:  [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, 
> type 2, socket -1
> 11(2790) DEBUG:  [core/tcp_main.c:1494]: tcpconn_add(): hashes: 
> 2712:0:0, 1
> 11(2790) DEBUG:  [core/tcp_main.c:2886]: tcpconn_1st_send(): pending 
> write on new connection 0x7f24e64c1e18 sock 8 (-1/447 bytes written) (err: 11 
> - Resource temporarily unavailable)
> 11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac: 
> 0x7f24e65285a8  branch: 0  to 2.2.2.2:5060
> 11(2790) DEBUG:  [core/onsend.c:50]: run_onsend(): required parameters 
> are not available - ignoring
> 27(2806) DEBUG:  [core/tcp_main.c:3792]: handle_ser_child(): read 
> response= 7f24e64c1e18, 5, fd 46 from 11 (2790)
> 27(2806) DEBUG:  [core/io_wait.h:375]: io_watch_add(): DBG: 
> io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37
> 27(2806) DEBUG:  [core/io_wait.h:782]: io_watch_chg(): DBG: 
> io_watch_chg (0x56490f0f8060, 46, 0x1, 0x) fd_no=38 called
> 27(2806) DEBUG:  [core/io_wait.h:600]: io_watch_del(): DBG: 
> io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called
> 27(2806) DEBUG:  [core/tcp_main.c:4457]: handle_tcpconn_ev(): sending 
> to child, events 1
> 27(2806) DEBUG:  [core/tcp_main.c:4127]: send2child(): selected tcp 
> worker idx:0 proc:19 pid:2798 for activity on [tcp:1.1.1.1:5060], 
> 0x7f24e64c1e18
> 19(2798) DEBUG:  [core/tcp_read.c:1749]: handle_io(): received n=8 
> con=0x7f24e64c1e18, fd=8
> 19(2798) DEBUG:  [core/tcp_read.c:1548]: tcp_read_req(): 
> content-length=0
> 19(2798) DEBUG:  [core/parser/msg_parser.c:620]: parse_msg(): SIP Reply 
>  (status):
> 19(2798) DEBUG:  [core/parser/msg_parser.c:622]: parse_msg():  version: 
> 
> 19(2798) DEBUG:  [core/parser/msg_parser.c:624]: parse_msg():  status:  
> <200>
> 19(2798) DEBUG:

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Alex Balashov

Sorry to have missed your other question: 

The “resource temporarily unavailable” is a normal occurrence in a nonblocking 
connect(), and nothing to worry about. 

Unless the socket literally connects instantaneously, EAGAIN is what it’ll 
throw out when polled until connection is established.

—
Sent from mobile, with due apologies for brevity and errors.

> On Oct 29, 2020, at 3:27 PM, Alex Balashov  wrote:
> 
> Internally generated requests are a little quirky in that they’re generated 
> by outside timer processes or tasks in core timers — activity that takes 
> place outside the SIP worker pool. However, the expectation is that any 
> replies will be processed (in this case, absorbed) by the SIP workers. 
> 
> Asymmetric signalling is permitted in SIP, so sending from source port X 
> while specifying a return port of Y in the top Via hop is perfectly 
> acceptable.
> 
> — Alex
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>>> On Oct 29, 2020, at 3:21 PM, Noah Mehl  wrote:
>>> 
>> Hey all,
>> 
>> I’m a little stuck on an implementation of a set of dispatchers via TCP.  
>> There are some oddities about the behavior of the TCP source port of the 
>> Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem 
>> valid.  For instance, I have a dispatcher:
>> 
>>  "RECORDS":  [{
>>  "SET":  {
>>  "ID":   1,
>>  "TARGETS":  [{
>>  "DEST": {
>>  "URI":  
>> “sip:2.2.2.2:5060;transport=tcp",
>>  "FLAGS":
>> "AP",
>>  "PRIORITY": 
>> 5
>>  }
>>  }]
>>  }
>>  }]
>> 
>> But when Kamailio sends an OPTIONS keep alive, the source port for the 
>> worker is 33940, and not 5060 (which is the TCP listen port), as received by 
>> Freeswitch:
>> 
>> recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
>>
>>OPTIONS sip:2.2.2.2:5060;transport=tcp SIP/2.0
>>Via: SIP/2.0/TCP 
>> 1.1.1.1;branch=z9hG4bK1525.80a9e442.0
>>To: 
>>From: 
>> ;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
>>CSeq: 10 OPTIONS
>>Call-ID: 3aa18693487268dc-2790@1.1.1.1
>>Max-Forwards: 70
>>Content-Length: 0
>>User-Agent: kamailio (5.4.2 (x86_64/linux))
>>
>>
>> 
>> Also, I get weird debug messages when this tcp worker is spun up 
>> (specifically about Resource temporarily unavailable):
>> 
>> 11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): probe 
>> all, mode DS_PROBE_ALL
>> 11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set #1, 
>> URI sip:2.2.2.2:5060;transport=tcp
>> 11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default 
>> ping_from: sip:inbound-kamailio-01
>> 11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default 
>> outbound proxy: 
>> 11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): 
>> next_hop=
>> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
>> 11(2790) DEBUG:  [core/tcp_main.c:1993]: tcp_send(): no open tcp 
>> connection found, opening new one
>> 11(2790) DEBUG:  [core/ip_addr.c:229]: print_ip(): tcpconn_new: new 
>> tcp connection: 2.2.2.2
>> 11(2790) DEBUG:  [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, 
>> type 2, socket -1
>> 11(2790) DEBUG:  [core/tcp_main.c:1494]: tcpconn_add(): hashes: 
>> 2712:0:0, 1
>> 11(2790) DEBUG:  [core/tcp_main.c:2886]: tcpconn_1st_send(): pending 
>> write on new connection 0x7f24e64c1e18 sock 8 (-1/447 bytes written) (err: 
>> 11 - Resource temporarily unavailable)
>> 11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac: 
>> 0x7f24e65285a8  branch: 0  to 2.2.2.2:5060
>> 11(2790) DEBUG:  [core/onsend.c:50]: run_onsend(): required parameters 
>> are not available - ignoring
>> 27(2806) DEBUG:  [core/tcp_main.c:3792]: handle_ser_child(): read 
>> response= 7f24e64c1e18, 5, fd 46 from 11 (2790)
>> 27(2806) DEBUG:  [core/io_wait.h:375]: io_watch_add(): DBG: 
>> io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37
>> 27(2806) DEBUG:  [core/io_wait.h:782]: io_watch_chg(): DBG: 
>> io_watch_chg (0x56490f0f8060, 46, 0x1, 0x) fd_no=38 called
>> 27(2806) DEBUG:  [core/io_wait.h:600]: io_watch_del(): DBG: 
>> io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called
>> 27(2806) DEBUG:  [core/tcp_main.c:4457]: handle_tcpconn_ev(): sending 
>> to child, events 1
>> 27(2806) DEBUG:  [core/tcp_main.c:4127]: send2child(): selected tcp 
>> worke

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Alex Balashov

Oh — one more thing (sorry, on mobile):

When port is absent in Via, it’s presumed 5060. Perhaps that will inform your 
interpretation of some of these events.

—
Sent from mobile, with due apologies for brevity and errors.

> On Oct 29, 2020, at 3:27 PM, Alex Balashov  wrote:
> 
> Internally generated requests are a little quirky in that they’re generated 
> by outside timer processes or tasks in core timers — activity that takes 
> place outside the SIP worker pool. However, the expectation is that any 
> replies will be processed (in this case, absorbed) by the SIP workers. 
> 
> Asymmetric signalling is permitted in SIP, so sending from source port X 
> while specifying a return port of Y in the top Via hop is perfectly 
> acceptable.
> 
> — Alex
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>>> On Oct 29, 2020, at 3:21 PM, Noah Mehl  wrote:
>>> 
>> Hey all,
>> 
>> I’m a little stuck on an implementation of a set of dispatchers via TCP.  
>> There are some oddities about the behavior of the TCP source port of the 
>> Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem 
>> valid.  For instance, I have a dispatcher:
>> 
>>  "RECORDS":  [{
>>  "SET":  {
>>  "ID":   1,
>>  "TARGETS":  [{
>>  "DEST": {
>>  "URI":  
>> “sip:2.2.2.2:5060;transport=tcp",
>>  "FLAGS":
>> "AP",
>>  "PRIORITY": 
>> 5
>>  }
>>  }]
>>  }
>>  }]
>> 
>> But when Kamailio sends an OPTIONS keep alive, the source port for the 
>> worker is 33940, and not 5060 (which is the TCP listen port), as received by 
>> Freeswitch:
>> 
>> recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
>>
>>OPTIONS sip:2.2.2.2:5060;transport=tcp SIP/2.0
>>Via: SIP/2.0/TCP 
>> 1.1.1.1;branch=z9hG4bK1525.80a9e442.0
>>To: 
>>From: 
>> ;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
>>CSeq: 10 OPTIONS
>>Call-ID: 3aa18693487268dc-2790@1.1.1.1
>>Max-Forwards: 70
>>Content-Length: 0
>>User-Agent: kamailio (5.4.2 (x86_64/linux))
>>
>>
>> 
>> Also, I get weird debug messages when this tcp worker is spun up 
>> (specifically about Resource temporarily unavailable):
>> 
>> 11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): probe 
>> all, mode DS_PROBE_ALL
>> 11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set #1, 
>> URI sip:2.2.2.2:5060;transport=tcp
>> 11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default 
>> ping_from: sip:inbound-kamailio-01
>> 11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default 
>> outbound proxy: 
>> 11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): 
>> next_hop=
>> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
>> 11(2790) DEBUG:  [core/tcp_main.c:1993]: tcp_send(): no open tcp 
>> connection found, opening new one
>> 11(2790) DEBUG:  [core/ip_addr.c:229]: print_ip(): tcpconn_new: new 
>> tcp connection: 2.2.2.2
>> 11(2790) DEBUG:  [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, 
>> type 2, socket -1
>> 11(2790) DEBUG:  [core/tcp_main.c:1494]: tcpconn_add(): hashes: 
>> 2712:0:0, 1
>> 11(2790) DEBUG:  [core/tcp_main.c:2886]: tcpconn_1st_send(): pending 
>> write on new connection 0x7f24e64c1e18 sock 8 (-1/447 bytes written) (err: 
>> 11 - Resource temporarily unavailable)
>> 11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac: 
>> 0x7f24e65285a8  branch: 0  to 2.2.2.2:5060
>> 11(2790) DEBUG:  [core/onsend.c:50]: run_onsend(): required parameters 
>> are not available - ignoring
>> 27(2806) DEBUG:  [core/tcp_main.c:3792]: handle_ser_child(): read 
>> response= 7f24e64c1e18, 5, fd 46 from 11 (2790)
>> 27(2806) DEBUG:  [core/io_wait.h:375]: io_watch_add(): DBG: 
>> io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37
>> 27(2806) DEBUG:  [core/io_wait.h:782]: io_watch_chg(): DBG: 
>> io_watch_chg (0x56490f0f8060, 46, 0x1, 0x) fd_no=38 called
>> 27(2806) DEBUG:  [core/io_wait.h:600]: io_watch_del(): DBG: 
>> io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called
>> 27(2806) DEBUG:  [core/tcp_main.c:4457]: handle_tcpconn_ev(): sending 
>> to child, events 1
>> 27(2806) DEBUG:  [core/tcp_main.c:4127]: send2child(): selected tcp 
>> worker idx:0 proc:19 pid:2798 for activity on [tcp:1.1.1.1:5060], 
>> 0x7f24e64c1e18
>> 19(2798) DEBUG:  [core/tcp_read.c:1749]: handle_io():

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Noah Mehl

Alex,

Is there no way to send the requests from the listen port?

And if they’re not going to come from the listen port, can you please help me 
with the a way to update the message for the worker chosen rport?

~Noah

> On Oct 29, 2020, at 3:37 PM, Alex Balashov  > wrote:
> 
> Sorry to have missed your other question: 
> 
> The “resource temporarily unavailable” is a normal occurrence in a 
> nonblocking connect(), and nothing to worry about. 
> 
> Unless the socket literally connects instantaneously, EAGAIN is what it’ll 
> throw out when polled until connection is established.
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>> On Oct 29, 2020, at 3:27 PM, Alex Balashov > > wrote:
>> 
>> Internally generated requests are a little quirky in that they’re generated 
>> by outside timer processes or tasks in core timers — activity that takes 
>> place outside the SIP worker pool. However, the expectation is that any 
>> replies will be processed (in this case, absorbed) by the SIP workers. 
>> 
>> Asymmetric signalling is permitted in SIP, so sending from source port X 
>> while specifying a return port of Y in the top Via hop is perfectly 
>> acceptable.
>> 
>> — Alex
>> 
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>> 
>>> On Oct 29, 2020, at 3:21 PM, Noah Mehl >> > wrote:
>>> 
>>> Hey all,
>>> 
>>> I’m a little stuck on an implementation of a set of dispatchers via TCP.  
>>> There are some oddities about the behavior of the TCP source port of the 
>>> Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem 
>>> valid.  For instance, I have a dispatcher:
>>> 
>>> "RECORDS":  [{
>>> "SET":  {
>>> "ID":   1,
>>> "TARGETS":  [{
>>> "DEST": {
>>> "URI":  
>>> “sip:2.2.2.2:5060;transport=tcp ",
>>> "FLAGS":
>>> "AP",
>>> "PRIORITY": 
>>> 5
>>> }
>>> }]
>>> }
>>> }]
>>> 
>>> But when Kamailio sends an OPTIONS keep alive, the source port for the 
>>> worker is 33940, and not 5060 (which is the TCP listen port), as received 
>>> by Freeswitch:
>>> 
>>> recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
>>>
>>>OPTIONS sip:2.2.2.2:5060;transport=tcp  
>>> SIP/2.0
>>>Via: SIP/2.0/TCP 
>>> 1.1.1.1;branch=z9hG4bK1525.80a9e442.0
>>>To: >
>>>From: >> >;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
>>>CSeq: 10 OPTIONS
>>>Call-ID: 3aa18693487268dc-2790@1.1.1.1 
>>> 
>>>Max-Forwards: 70
>>>Content-Length: 0
>>>User-Agent: kamailio (5.4.2 (x86_64/linux))
>>>
>>>
>>> 
>>> Also, I get weird debug messages when this tcp worker is spun up 
>>> (specifically about Resource temporarily unavailable):
>>> 
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): 
>>> probe all, mode DS_PROBE_ALL
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set 
>>> #1, URI sip:2.2.2.2:5060;transport=tcp 
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default 
>>> ping_from: sip:inbound-kamailio-01 
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default 
>>> outbound proxy: 
>>> 11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): 
>>> next_hop=>
>>> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
>>> 11(2790) DEBUG:  [core/tcp_main.c:1993]: tcp_send(): no open tcp 
>>> connection found, opening new one
>>> 11(2790) DEBUG:  [core/ip_addr.c:229]: print_ip(): tcpconn_new: new 
>>> tcp connection: 2.2.2.2
>>> 11(2790) DEBUG:  [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, 
>>> type 2, socket -1
>>> 11(2790) DEBUG:  [core/tcp_main.c:1494]: tcpconn_add(): hashes: 
>>> 2712:0:0, 1
>>> 11(2790) DEBUG:  [core/tcp_main.c:2886]: tcpconn_1st_send(): pending 
>>> write on new connection 0x7f24e64c1e18 sock 8 (-1/447 bytes written) (err: 
>>> 11 - Resource temporarily unavailable)
>>> 11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac: 
>>> 0x7f24e65285a8  branch: 0  to 2.2.2.2:5060
>>> 11(2790) DEBUG:  [core/onsend.c:50]: run_onsend(): required 
>>> parameters are not available - ignoring
>>> 27(2806) DEBUG:  [core/tcp_main.c:3792]: handle_ser_child(): read 
>>> response= 7f24e64c1e18, 5, fd 46 from 11 (2790)
>>> 27(2806) DEBUG:  [core/io_w

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Sergiu Pojoga

In a nutshell, with TCP, it's the OS's network stack that assigns the port.

For more: https://lists.kamailio.org/pipermail/sr-users/2018-May/101529.html

On Thu, Oct 29, 2020 at 4:00 PM Noah Mehl  wrote:

> Alex,
>
> Is there no way to send the requests from the listen port?
>
> And if they’re not going to come from the listen port, can you please help
> me with the a way to update the message for the worker chosen rport?
>
> ~Noah
>
> On Oct 29, 2020, at 3:37 PM, Alex Balashov 
> wrote:
>
> Sorry to have missed your other question:
>
> The “resource temporarily unavailable” is a normal occurrence in a
> nonblocking connect(), and nothing to worry about.
>
> Unless the socket literally connects instantaneously, EAGAIN is what it’ll
> throw out when polled until connection is established.
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
> On Oct 29, 2020, at 3:27 PM, Alex Balashov 
> wrote:
>
> Internally generated requests are a little quirky in that they’re
> generated by outside timer processes or tasks in core timers — activity
> that takes place outside the SIP worker pool. However, the expectation is
> that any replies will be processed (in this case, absorbed) by the SIP
> workers.
>
> Asymmetric signalling is permitted in SIP, so sending from source port X
> while specifying a return port of Y in the top Via hop is perfectly
> acceptable.
>
> — Alex
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
> On Oct 29, 2020, at 3:21 PM, Noah Mehl  wrote:
>
> Hey all,
>
> I’m a little stuck on an implementation of a set of dispatchers via TCP.
> There are some oddities about the behavior of the TCP source port of the
> Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem
> valid.  For instance, I have a dispatcher:
>
> "RECORDS": [{
> "SET": {
> "ID": 1,
> "TARGETS": [{
> "DEST": {
> "URI": “sip:2.2.2.2:5060;transport=tcp",
> "FLAGS": "AP",
> "PRIORITY": 5
> }
> }]
> }
> }]
>
> But when Kamailio sends an OPTIONS keep alive, the source port for the
> worker is 33940, and not 5060 (which is the TCP listen port), as received
> by Freeswitch:
>
> recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
>
>OPTIONS sip:2.2.2.2:5060;transport=tcp SIP/2.0
>Via: SIP/2.0/TCP
> 1.1.1.1;branch=z9hG4bK1525.80a9e442.0
>To: 
>From:  >;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
>CSeq: 10 OPTIONS
>Call-ID: 3aa18693487268dc-2790@1.1.1.1
>Max-Forwards: 70
>Content-Length: 0
>User-Agent: kamailio (5.4.2 (x86_64/linux))
>
>
>
> Also, I get weird debug messages when this tcp worker is spun up
> (specifically about Resource temporarily unavailable):
>
> 11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper():
> probe all, mode DS_PROBE_ALL
> 11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set
> #1, URI sip:2.2.2.2:5060;transport=tcp
> 11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default
> ping_from: sip:inbound-kamailio-01
> 11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default
> outbound proxy:
> 11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): next_hop=<
> sip:2.2.2.2:5060;transport=tcp>
> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
> 11(2790) DEBUG:  [core/tcp_main.c:1993]: tcp_send(): no open tcp
> connection found, opening new one
> 11(2790) DEBUG:  [core/ip_addr.c:229]: print_ip(): tcpconn_new: new
> tcp connection: 2.2.2.2
> 11(2790) DEBUG:  [core/tcp_main.c:1175]: tcpconn_new(): on port
> 5060, type 2, socket -1
> 11(2790) DEBUG:  [core/tcp_main.c:1494]: tcpconn_add(): hashes:
> 2712:0:0, 1
> 11(2790) DEBUG:  [core/tcp_main.c:2886]: tcpconn_1st_send(): pending
> write on new connection 0x7f24e64c1e18 sock 8 (-1/447 bytes written) (err:
> 11 - Resource temporarily unavailable)
> 11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac:
> 0x7f24e65285a8  branch: 0  to 2.2.2.2:5060
> 11(2790) DEBUG:  [core/onsend.c:50]: run_onsend(): required
> parameters are not available - ignoring
> 27(2806) DEBUG:  [core/tcp_main.c:3792]: handle_ser_child(): read
> response= 7f24e64c1e18, 5, fd 46 from 11 (2790)
> 27(2806) DEBUG:  [core/io_wait.h:375]: io_watch_add(): DBG:
> io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37
> 27(2806) DEBUG:  [core/io_wait.h:782]: io_watch_chg(): DBG:
> io_watch_chg (0x56490f0f8060, 46, 0x1, 0x) fd_no=38 called
> 27(2806) DEBUG:  [core/io_wait.h:600]: io_watch_del(): DBG:
> io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called
> 27(2806) DEBUG:  [core/tcp_main.c:4457]: handle_tcpconn_ev():
> sending to child, events 1
> 27(2806) DEBUG:  [core/tcp_main.c:4127]: send2child(): selected tcp
> worker idx:0 proc:19 pid:2798 for activity on [tcp:1.1.1.1:5060],
> 0x7f24e64c1e18
> 19(2798) DEBUG:  [core/tcp_read.c:1749]: handl

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Henning Westerholt

Hello,

Have you already tried this core option:

https://www.kamailio.org/wiki/cookbooks/devel/core#tcp_reuse_port

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com<https://gilawa.com/>

From: sr-users  On Behalf Of Noah Mehl
Sent: Thursday, October 29, 2020 8:57 PM
To: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Confusion about TCP worker ports

Alex,

Is there no way to send the requests from the listen port?

And if they’re not going to come from the listen port, can you please help me 
with the a way to update the message for the worker chosen rport?

~Noah


On Oct 29, 2020, at 3:37 PM, Alex Balashov 
mailto:abalas...@evaristesys.com>> wrote:

Sorry to have missed your other question:

The “resource temporarily unavailable” is a normal occurrence in a nonblocking 
connect(), and nothing to worry about.

Unless the socket literally connects instantaneously, EAGAIN is what it’ll 
throw out when polled until connection is established.
—
Sent from mobile, with due apologies for brevity and errors.


On Oct 29, 2020, at 3:27 PM, Alex Balashov 
mailto:abalas...@evaristesys.com>> wrote:
Internally generated requests are a little quirky in that they’re generated by 
outside timer processes or tasks in core timers — activity that takes place 
outside the SIP worker pool. However, the expectation is that any replies will 
be processed (in this case, absorbed) by the SIP workers.

Asymmetric signalling is permitted in SIP, so sending from source port X while 
specifying a return port of Y in the top Via hop is perfectly acceptable.

— Alex
—
Sent from mobile, with due apologies for brevity and errors.


On Oct 29, 2020, at 3:21 PM, Noah Mehl 
mailto:noahm...@gmail.com>> wrote:
Hey all,

I’m a little stuck on an implementation of a set of dispatchers via TCP.  There 
are some oddities about the behavior of the TCP source port of the Kamailio tcp 
worker/s, and maybe this is expected, but it doesn’t seem valid.  For instance, 
I have a dispatcher:

   "RECORDS":   [{
  "SET":   {
  
"ID":  1,
  
"TARGETS":[{

 "DEST": {

"URI":   
“sip:2.2.2.2:5060;transport=tcp",

"FLAGS": "AP",

"PRIORITY":   5

 }

  }]
  }
  }]

But when Kamailio sends an OPTIONS keep alive, the source port for the worker 
is 33940, and not 5060 (which is the TCP listen port), as received by 
Freeswitch:

recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
   
   OPTIONS sip:2.2.2.2:5060;transport=tcp SIP/2.0
   Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bK1525.80a9e442.0
   To: 
   From: ;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
   CSeq: 10 OPTIONS
   Call-ID: 3aa18693487268dc-2790@1.1.1.1<mailto:3aa18693487268dc-2790@1.1.1.1>
   Max-Forwards: 70
   Content-Length: 0
   User-Agent: kamailio (5.4.2 (x86_64/linux))

   
Also, I get weird debug messages when this tcp worker is spun up (specifically 
about Resource temporarily unavailable):

11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): probe 
all, mode DS_PROBE_ALL
11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set #1, 
URI sip:2.2.2.2:5060;transport=tcp
11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default ping_from: 
sip:inbound-kamailio-01
11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default outbound 
proxy:
11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): 
next_hop=
11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
11(2790) DEBUG:  [core/tcp_main.c:1993]: tcp_send(): no open tcp 
connection found, opening new one
11(2790) DEBUG:  [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp 
connec

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Alex Balashov


On 10/29/20 3:57 PM, Noah Mehl wrote:


Is there no way to send the requests from the listen port?


The OPTIONS pinging dispatcher does internally is opaque, so I'm not sure.

However, the source shows that dispatcher uses the UAC module for its 
internally generated OPTIONS pings, which is sensible:


https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c#L3445

If so, it stands to reason that loading 'uac' and setting this modparam 
may have some effect:


https://kamailio.org/docs/modules/5.4.x/modules/uac.html#uac.p.default_socket

I am not sure if it applies only to requests synthesised within the 
config script and sent using uac_req_send(), or to any requests 
constructed by the UAC module, though.



And if they’re not going to come from the listen port, can you please
help me with the a way to update the message for the worker chosen
rport?


Try the above and see if it does anything.

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Alex Balashov


Noah,

It is also possible that this core config parameter will in and of 
itself cure your problem:


https://www.kamailio.org/wiki/cookbooks/5.4.x/core#tcp_reuse_port

Not sure whether it helps only in tandem with the previous UAC 
default_socket modparam suggestion, or is sufficient in and of itself.


-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Noah Mehl

Alex,

No dice.

So now my question is what is the correct way to fix the Via?

If this is the original:

Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1

Then do I update the port like this:

Via: SIP/2.0/TCP 
1.1.1.1:33940;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1

Or should I use an rport tag:

Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1;rport=33940

Thanks!

~Noah

> On Oct 29, 2020, at 4:12 PM, Alex Balashov  wrote:
> 
> Noah,
> 
> It is also possible that this core config parameter will in and of itself 
> cure your problem:
> 
> https://www.kamailio.org/wiki/cookbooks/5.4.x/core#tcp_reuse_port
> 
> Not sure whether it helps only in tandem with the previous UAC default_socket 
> modparam suggestion, or is sufficient in and of itself.
> 
> -- Alex
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Alex Balashov

There's not really a reasonable way for you to add your own Via header 
to this outgoing request. If Kamailio is doing something wrong or 
inconsistent in this context, it should be fixed there.


On 10/29/20 4:42 PM, Noah Mehl wrote:

Alex,

No dice.

So now my question is what is the correct way to fix the Via?

If this is the original:

Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1

Then do I update the port like this:

Via: SIP/2.0/TCP 
1.1.1.1:33940;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1

Or should I use an rport tag:

Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1;rport=33940

Thanks!

~Noah


On Oct 29, 2020, at 4:12 PM, Alex Balashov  wrote:

Noah,

It is also possible that this core config parameter will in and of itself cure 
your problem:

https://www.kamailio.org/wiki/cookbooks/5.4.x/core#tcp_reuse_port

Not sure whether it helps only in tandem with the previous UAC default_socket 
modparam suggestion, or is sufficient in and of itself.

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Noah Mehl

Alex,

In the original example:

recv 1481 bytes from tcp/[1.1.1.1]:33940 at 16:56:47.920698:
   
   INVITE sip:991...@sip.domain.com SIP/2.0
   Record-Route: 
   Record-Route: 
   Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
   Via: SIP/2.0/TLS 
172.22.199.110:55304;received=5.5.5.5;rport=39518;branch=z9hG4bKPj5Css6JomCt9Cli2cCINbXi4FbPM5wewG;alias
   Max-Forwards: 69
   From: "Noah Mehl" 
;tag=s3i3y2tiOCgnUId5TD4Vp0UChf9GyEy9
   To: 
   Contact: 

   Call-ID: 5aoRBMBHahxqSLzrIpFnlfRz.UcGsmfq
   CSeq: 27271 INVITE
   Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
   Supported: replaces, norefersub, gruu
   User-Agent: Blink Pro 4.6.0 (MacOSX)
   Content-Type: application/sdp
   Content-Length:   528

The top Via header is not identifying port 33940 which is where the request is 
coming from. Or the expectation is that the receiving side will send replies to 
port 5060 (which I guess is broken in Freeswitch sometimes?)

I guess I would like to update that existing Via header with the source port 
(since it’s not 5060)?

~Noah

> On Oct 29, 2020, at 4:45 PM, Alex Balashov  wrote:
> 
> There's not really a reasonable way for you to add your own Via header to 
> this outgoing request. If Kamailio is doing something wrong or inconsistent 
> in this context, it should be fixed there.
> 
> On 10/29/20 4:42 PM, Noah Mehl wrote:
>> Alex,
>> No dice.
>> So now my question is what is the correct way to fix the Via?
>> If this is the original:
>> Via: SIP/2.0/TCP 
>> 1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
>> Then do I update the port like this:
>> Via: SIP/2.0/TCP 
>> 1.1.1.1:33940;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
>> Or should I use an rport tag:
>> Via: SIP/2.0/TCP 
>> 1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1;rport=33940
>> Thanks!
>> ~Noah
>>> On Oct 29, 2020, at 4:12 PM, Alex Balashov  
>>> wrote:
>>> 
>>> Noah,
>>> 
>>> It is also possible that this core config parameter will in and of itself 
>>> cure your problem:
>>> 
>>> https://www.kamailio.org/wiki/cookbooks/5.4.x/core#tcp_reuse_port
>>> 
>>> Not sure whether it helps only in tandem with the previous UAC 
>>> default_socket modparam suggestion, or is sufficient in and of itself.
>>> 
>>> -- Alex
>>> 
>>> -- 
>>> Alex Balashov | Principal | Evariste Systems LLC
>>> 
>>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>> 
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-29 Thread Alex Balashov


On 10/29/20 4:48 PM, Noah Mehl wrote:


Or the expectation is that the receiving side will send replies to
port 5060 (which I guess is broken in Freeswitch sometimes?)
That is precisely the expectation, because dispatcher doesn't keep 
dedicated listeners for replies to its own OPTIONS requests.


That's what I meant about asymmetric signalling: it is completely legal 
to send from an actual port of Y while having a Via header that says 
"hit me back at port X". That's exactly what FS should do.


-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-30 Thread Olle E. Johansson

> On 29 Oct 2020, at 21:51, Alex Balashov  wrote:
> 
> On 10/29/20 4:48 PM, Noah Mehl wrote:
> 
>> Or the expectation is that the receiving side will send replies to
>> port 5060 (which I guess is broken in Freeswitch sometimes?)
> That is precisely the expectation, because dispatcher doesn't keep dedicated 
> listeners for replies to its own OPTIONS requests.
> 
> That's what I meant about asymmetric signalling: it is completely legal to 
> send from an actual port of Y while having a Via header that says "hit me 
> back at port X". That's exactly what FS should do.
> 
Alex - aren’t you thinking UDP now?

For TCP, responses go the path of the request, back on the same socket that is 
already open. From RFC 3261:

18.2.2  Sending Responses

   The server transport uses the value of the top Via header field in
   order to determine where to send a response.  It MUST follow the
   following process:

  o  If the "sent-protocol" is a reliable transport protocol such as
 TCP or SCTP, or TLS over those, the response MUST be sent using
 the existing connection to the source of the original request
 that created the transaction, if that connection is still open.
 This requires the server transport to maintain an association
 between server transactions and transport connections.  If that
 connection is no longer open, the server SHOULD open a
 connection to the IP address in the "received" parameter, if
 present, using the port in the "sent-by" value, or the default
 port for that transport, if no port is specified.  If that
 connection attempt fails, the server SHOULD use the procedures
 in [4 ] for servers in 
order to determine the IP address and
 port to open the connection and send the response to.

/O___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-30 Thread Alex Balashov


Olle,

Yes, but if the request is sent down the path of the existing socket and 
it remains open, the whole issue of port representation in the Via 
header is moot. I presume the Noah's inquiry was motivated by the fact 
that this is not happening, or that the UAS receiving the OPTIONS 
request is not properly associating that TCP socket to the transaction.


-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-30 Thread Henning Westerholt

Hi Alex,

this is not correct. The dispatcher module uses the uac function from TM module 
for the generation and sending out of OPTIONS requests.

So setting the mentioned function from the uac module will probably not help.

Cheers,

Henning

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

-Original Message-
From: sr-users  On Behalf Of Alex Balashov
Sent: Thursday, October 29, 2020 9:11 PM
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Confusion about TCP worker ports

On 10/29/20 3:57 PM, Noah Mehl wrote:

> Is there no way to send the requests from the listen port?

The OPTIONS pinging dispatcher does internally is opaque, so I'm not sure.

However, the source shows that dispatcher uses the UAC module for its 
internally generated OPTIONS pings, which is sensible:

https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c#L3445

If so, it stands to reason that loading 'uac' and setting this modparam may 
have some effect:

https://kamailio.org/docs/modules/5.4.x/modules/uac.html#uac.p.default_socket

I am not sure if it applies only to requests synthesised within the config 
script and sent using uac_req_send(), or to any requests constructed by the UAC 
module, though.

> And if they’re not going to come from the listen port, can you please 
> help me with the a way to update the message for the worker chosen 
> rport?

Try the above and see if it does anything.

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-30 Thread Daniel-Constantin Mierla

Hello,

confirming what Henning said that dispatcher is not using uac module,
not to be any doubt about that. Actually, uac modules uses some of the
TM-UAC functions as dispatcher module, but between dispatcher and uac
module is no relation, no dependency. Sockets can be enforced in
dispatcher via socket attribute (I think is also a modparam for a global
need), however see next remarks about what can happen.

Besides that, I am writing to add on the original topic related to tcp
local ports. Tipically they have nothing to do with the listen port
(5060), the force socket for TCP is mainly a best-effort to use at least
the same network interface, but the OS/kernel may use a different one,
based on IP routing rules and priorities. The local ports are selected
from ephemeral ports range, searching the web should reveal more details
about, for example:

  *
https://superuser.com/questions/1118735/how-are-source-ports-determined-and-how-can-i-force-it-to-use-a-specific-port

On newer kernels there is an option to try to reuse ports even for tcp
(which was possible for UDP before, but not for TCP), kamailio has a
core parameter to enable it. See if enabling that gives what is wanted.
But if one thinks of firewall rules, for tcp it should allow based on IP
and eventually the ephemeral ports range of the source (which is hard to
figure out if it is not another fully managed system).

Olle added relevant details, adding a bit more: the port in Via header
is for "connect back here if the connection of the request is no longer
available", otherwise the connection is reused and Via address is more
for aesthetic purposes (e.g., think also about a device behind nat that
has via with private ip address, in such case is not possible to connect
back at all).

Cheers,
Daniel

On 30.10.20 09:05, Henning Westerholt wrote:
> Hi Alex,
>
> this is not correct. The dispatcher module uses the uac function from TM 
> module for the generation and sending out of OPTIONS requests.
>
> So setting the mentioned function from the uac module will probably not help.
>
> Cheers,
>
> Henning
>
> -- 
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com 
>
> -Original Message-
> From: sr-users  On Behalf Of Alex 
> Balashov
> Sent: Thursday, October 29, 2020 9:11 PM
> To: sr-users@lists.kamailio.org
> Subject: Re: [SR-Users] Confusion about TCP worker ports
>
> On 10/29/20 3:57 PM, Noah Mehl wrote:
>
>> Is there no way to send the requests from the listen port?
> The OPTIONS pinging dispatcher does internally is opaque, so I'm not sure.
>
> However, the source shows that dispatcher uses the UAC module for its 
> internally generated OPTIONS pings, which is sensible:
>
> https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c#L3445
>
> If so, it stands to reason that loading 'uac' and setting this modparam may 
> have some effect:
>
> https://kamailio.org/docs/modules/5.4.x/modules/uac.html#uac.p.default_socket
>
> I am not sure if it applies only to requests synthesised within the config 
> script and sent using uac_req_send(), or to any requests constructed by the 
> UAC module, though.
>
>> And if they’re not going to come from the listen port, can you please 
>> help me with the a way to update the message for the worker chosen 
>> rport?
> Try the above and see if it does anything.
>
> -- Alex
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-30 Thread Alex Balashov


Daniel,

Just to make sure I understood this:

On 10/30/20 4:34 AM, Daniel-Constantin Mierla wrote:


confirming what Henning said that dispatcher is not using uac module,
not to be any doubt about that. Actually, uac modules uses some of the
TM-UAC functions as dispatcher module, but between dispatcher and uac
module is no relation, no dependency. Sockets can be enforced in
dispatcher via socket attribute (I think is also a modparam for a global
need), however see next remarks about what can happen.
So, there's a common set of UAC request synthesis APIs which are 
actually exported by TM, but used by both dispatcher and the UAC module 
per se?


-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

2020-10-30 Thread Henning Westerholt

Hi Alex,

yes, this is correct. This interface used also from other modules that needs to 
exercise UAC like functionality.

https://github.com/kamailio/kamailio/blob/master/src/modules/tm/uac.h

Cheers,

Henning

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

-Original Message-
From: sr-users  On Behalf Of Alex Balashov
Sent: Friday, October 30, 2020 7:07 PM
To: sr-users@lists.kamailio.org
Subject: Re: [SR-Users] Confusion about TCP worker ports

Daniel,

Just to make sure I understood this:

On 10/30/20 4:34 AM, Daniel-Constantin Mierla wrote:

> confirming what Henning said that dispatcher is not using uac module, 
> not to be any doubt about that. Actually, uac modules uses some of the 
> TM-UAC functions as dispatcher module, but between dispatcher and uac 
> module is no relation, no dependency. Sockets can be enforced in 
> dispatcher via socket attribute (I think is also a modparam for a 
> global need), however see next remarks about what can happen.
So, there's a common set of UAC request synthesis APIs which are actually 
exported by TM, but used by both dispatcher and the UAC module per se?

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

Re: [SR-Users] Confusion about TCP worker ports

18 matches

Site Navigation

Mail list logo

Footer information