<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Alex,</div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Is there no way to send the requests from the listen port?<div class=""><br class=""></div><div class="">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?<br class=""><div class=""><br class=""></div><div class="">~Noah<br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Oct 29, 2020, at 3:37 PM, Alex Balashov <<a href="mailto:abalashov@evaristesys.com" class="">abalashov@evaristesys.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class="">Sorry to have missed your other question: <div class=""><br class=""></div><div class="">The “resource temporarily unavailable” is a normal occurrence in a nonblocking connect(), and nothing to worry about. </div><div class=""><br class=""></div><div class="">Unless the socket literally connects instantaneously, EAGAIN is what it’ll throw out when polled until connection is established.<br class=""><br class=""><div dir="ltr" class="">—<div class="">Sent from mobile, with due apologies for brevity and errors.</div></div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Oct 29, 2020, at 3:27 PM, Alex Balashov <<a href="mailto:abalashov@evaristesys.com" class="">abalashov@evaristesys.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class="">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. <div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">— Alex<br class=""><br class=""><div dir="ltr" class="">—<div class="">Sent from mobile, with due apologies for brevity and errors.</div></div><div dir="ltr" class=""><br class=""><blockquote type="cite" class="">On Oct 29, 2020, at 3:21 PM, Noah Mehl <<a href="mailto:noahmehl@gmail.com" class="">noahmehl@gmail.com</a>> wrote:<br class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div dir="ltr" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">Hey all,<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"RECORDS":<span class="Apple-tab-span" style="white-space:pre"> </span>[{<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"SET":<span class="Apple-tab-span" style="white-space:pre"> </span>{<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"ID":<span class="Apple-tab-span" style="white-space:pre"> </span>1,<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"TARGETS":<span class="Apple-tab-span" style="white-space:pre"> </span>[{<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"DEST":<span class="Apple-tab-span" style="white-space:pre"> </span>{<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"URI":<span class="Apple-tab-span" style="white-space:pre"> </span>“<a href="sip:2.2.2.2:5060;transport=tcp" class="">sip:2.2.2.2:5060;transport=tcp</a>",<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"FLAGS":<span class="Apple-tab-span" style="white-space:pre"> </span>"AP",<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>"PRIORITY":<span class="Apple-tab-span" style="white-space:pre"> </span>5<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}]<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}]</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:<br class=""> ------------------------------------------------------------------------<br class=""> OPTIONS <a href="sip:2.2.2.2:5060;transport=tcp" class="">sip:2.2.2.2:5060;transport=tcp</a> SIP/2.0<br class=""> Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bK1525.80a9e442000000000000000000000000.0<br class=""> To: <<a href="sip:2.2.2.2:5060;transport=tcp" class="">sip:2.2.2.2:5060;transport=tcp</a>><br class=""> From: <<a href="sip:inbound-kamailio-01" class="">sip:inbound-kamailio-01</a>>;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f<br class=""> CSeq: 10 OPTIONS<br class=""> Call-ID: <a href="mailto:3aa18693487268dc-2790@1.1.1.1" class="">3aa18693487268dc-2790@1.1.1.1</a><br class=""> Max-Forwards: 70<br class=""> Content-Length: 0<br class=""> User-Agent: kamailio (5.4.2 (x86_64/linux))<br class=""> <br class=""> ------------------------------------------------------------------------<br class=""><br class=""></div><div class="">Also, I get weird debug messages when this tcp worker is spun up (specifically about Resource temporarily unavailable):</div><div class=""><br class=""></div><div class="">11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): probe all, mode DS_PROBE_ALL<br class="">11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set #1, URI <a href="sip:2.2.2.2:5060;transport=tcp" class="">sip:2.2.2.2:5060;transport=tcp</a><br class="">11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default ping_from: <a href="sip:inbound-kamailio-01" class="">sip:inbound-kamailio-01</a><br class="">11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default outbound proxy: <br class="">11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): next_hop=<<a href="sip:2.2.2.2:5060;transport=tcp" class="">sip:2.2.2.2:5060;transport=tcp</a>><br class="">11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073<br class="">11(2790) DEBUG: <core> [core/tcp_main.c:1993]: tcp_send(): no open tcp connection found, opening new one<br class="">11(2790) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new tcp connection: 2.2.2.2<br class="">11(2790) DEBUG: <core> [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, type 2, socket -1<br class="">11(2790) DEBUG: <core> [core/tcp_main.c:1494]: tcpconn_add(): hashes: 2712:0:0, 1<br class="">11(2790) DEBUG: <core> [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)<br class="">11(2790) DEBUG: tm [uac.c:678]: send_prepared_request_impl(): uac: 0x7f24e65285a8 branch: 0 to 2.2.2.2:5060<br class="">11(2790) DEBUG: <core> [core/onsend.c:50]: run_onsend(): required parameters are not available - ignoring<br class="">27(2806) DEBUG: <core> [core/tcp_main.c:3792]: handle_ser_child(): read response= 7f24e64c1e18, 5, fd 46 from 11 (2790)<br class="">27(2806) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG: io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37<br class="">27(2806) DEBUG: <core> [core/io_wait.h:782]: io_watch_chg(): DBG: io_watch_chg (0x56490f0f8060, 46, 0x1, 0xffffffff) fd_no=38 called<br class="">27(2806) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called<br class="">27(2806) DEBUG: <core> [core/tcp_main.c:4457]: handle_tcpconn_ev(): sending to child, events 1<br class="">27(2806) DEBUG: <core> [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<br class="">19(2798) DEBUG: <core> [core/tcp_read.c:1749]: handle_io(): received n=8 con=0x7f24e64c1e18, fd=8<br class="">19(2798) DEBUG: <core> [core/tcp_read.c:1548]: tcp_read_req(): content-length=0<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): SIP Reply (status):<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:622]: parse_msg(): version: <SIP/2.0><br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:624]: parse_msg(): status: <200><br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:626]: parse_msg(): reason: <OK><br class="">19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK1525.80a9e442000000000000000000000000.0>; state=6<br class="">19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 235, <rport> = <33940>; state=16<br class="">19(2798) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:498]: parse_headers(): Via found, flags=2<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:500]: parse_headers(): this is the first via<br class="">19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=1mB9HryQ8ZBFc<br class="">19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [59]; uri=[<a href="sip:2.2.2.2:5060;transport=tcp" class="">sip:2.2.2.2:5060;transport=tcp</a>]<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (39)[<<a href="sip:2.2.2.2:5060;transport=tcp" class="">sip:2.2.2.2:5060;transport=tcp</a>>], to tag (13)[1mB9HryQ8ZBFc]<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <10> <OPTIONS><br class="">19(2798) DEBUG: <core> [core/receive.c:319]: receive_msg(): --- received sip message - reply - call-id: [<a href="mailto:3aa18693487268dc-2790@1.1.1.1" class="">3aa18693487268dc-2790@1.1.1.1</a>] - cseq: [10 OPTIONS]<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:185]: get_hdr_field(): content_length=0<br class="">19(2798) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header</div><div class=""><br class=""></div><div class="">Are these SIP messages expected to come from other ports than the listen port (5060 in this case)? Also, if the worker source port is not 5060, shouldn’t the SIP message get updated with the correct port?</div><div class=""><br class=""></div><div class="">In the case of OPTIONS, Freeswitch is replying correctly to the source port: 33940.</div><div class=""><br class=""></div><div class="">However, in the case of an in dialog BYE, Freeswitch is NOT replying to the source port of the Kamailio messages, but only to port 5060. Here is an example (relayed from web sockets to freeswitch over TCP) INVITE (as received from Freeswitch):</div><div class=""><br class=""></div><div class="">recv 1481 bytes from tcp/[1.1.1.1]:33940 at 16:56:47.920698:<br class=""> ------------------------------------------------------------------------<br class=""> INVITE <a href="sip:991012@sip.domain" class="">sip:991012@sip.domain</a>.com SIP/2.0<br class=""> Record-Route: <<a href="sip:1.1.1.1;transport=tcp;r2=on;lr;nat=yes" class="">sip:1.1.1.1;transport=tcp;r2=on;lr;nat=yes</a>><br class=""> Record-Route: <<a href="sip:1.1.1.1:5061;transport=tls;r2=on;lr;nat=yes" class="">sip:1.1.1.1:5061;transport=tls;r2=on;lr;nat=yes</a>><br class=""> Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1<br class=""> Via: SIP/2.0/TLS 172.22.199.110:55304;received=5.5.5.5;rport=39518;branch=z9hG4bKPj5Css6JomCt9Cli2cCINbXi4FbPM5wewG;alias<br class=""> Max-Forwards: 69<br class=""> From: "Noah Mehl" <<a href="sip:5135555555@inbound-jail" class="">sip:5135555555@inbound-jail</a>>;tag=s3i3y2tiOCgnUId5TD4Vp0UChf9GyEy9<br class=""> To: <<a href="sip:991012@inbound-jail" class="">sip:991012@inbound-jail</a>><br class=""> Contact: <<a href="sip:74895612@172.22.199.110:54887;transport=tls;alias=5.5.5.5~39518~3" class="">sip:74895612@172.22.199.110:54887;transport=tls;alias=5.5.5.5~39518~3</a>><br class=""> Call-ID: 5aoRBMBHahxqSLzrIpFnlfRz.UcGsmfq<br class=""> CSeq: 27271 INVITE<br class=""> Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER<br class=""> Supported: replaces, norefersub, gruu<br class=""> User-Agent: Blink Pro 4.6.0 (MacOSX)<br class=""> Content-Type: application/sdp<br class=""> Content-Length: 528<br class=""> <br class=""> v=0<br class=""> o=- 3812979407 3812979407 IN IP4 5.5.5.5<br class=""> s=Blink Pro 4.6.0 (MacOSX)<br class=""> t=0 0<br class=""> m=audio 50016 RTP/SAVP 113 0 101<br class=""> c=IN IP4 5.5.5.5<br class=""> a=rtcp:50017<br class=""> a=rtpmap:113 opus/48000/2<br class=""> a=fmtp:113 useinbandfec=1<br class=""> a=rtpmap:0 PCMU/8000<br class=""> a=rtpmap:101 telephone-event/8000<br class=""> a=fmtp:101 0-16<br class=""> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:UhHq6hth9HqALmiJ3AEeoGkixObBzkLURG60wJKT<br class=""> a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:VKYaSCVwgvXCPaRvudTrgLORhWmOA7wyDJVeGjcu<br class=""> a=sendrecv<br class=""> a=oldmediaip:172.22.199.110<br class=""> a=oldmediaip:172.22.199.110<br class=""> ------------------------------------------------------------------------<br class=""><br class=""></div><div class="">This doesn’t seem valid, as the top Via doesn’t have a port specified?</div><div class=""><br class=""></div><div class="">For reference, just rebuilt form the 5.4 branch today:</div><div class=""><br class=""></div><div class="">commit 62dff5b8b157236cae7defe64291a6e4a8ae27b5 (upstream/5.4)<br class="">Author: Kamailio Dev <<a href="mailto:kamailio.dev@kamailio.org" class="">kamailio.dev@kamailio.org</a>><br class="">Date: Wed Oct 28 20:16:28 2020 +0100<br class=""><br class=""> modules: readme files regenerated - modules ... [skip ci]<br class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">~Noah</div><div class=""><br class=""></div><span class="">_______________________________________________</span><br class=""><span class="">Kamailio (SER) - Users Mailing List</span><br class=""><span class=""><a href="mailto:sr-users@lists.kamailio.org" class="">sr-users@lists.kamailio.org</a></span><br class=""><span class=""><a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a></span><br class=""></div></blockquote></div></div></blockquote></div></div>_______________________________________________<br class="">Kamailio (SER) - Users Mailing List<br class=""><a href="mailto:sr-users@lists.kamailio.org" class="">sr-users@lists.kamailio.org</a><br class=""><a href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users" class="">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a><br class=""></div></blockquote></div><br class=""></div></div></div></body></html>