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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <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.2.2.2:5060;transport=tcp> >>> SIP/2.0 >>> Via: SIP/2.0/TCP >>> 1.1.1.1;branch=z9hG4bK1525.80a9e442000000000000000000000000.0 >>> To: <sip:2.2.2.2:5060;transport=tcp <sip:2.2.2.2:5060;transport=tcp>> >>> From: <sip:inbound-kamailio-01 >>> <sip:inbound-kamailio-01>>;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f >>> CSeq: 10 OPTIONS >>> Call-ID: [email protected] >>> <mailto:[email protected]> >>> 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 <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 <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 <sip:2.2.2.2:5060;transport=tcp>> >>> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073 >>> 11(2790) DEBUG: <core> [core/tcp_main.c:1993]: tcp_send(): no open tcp >>> connection found, opening new one >>> 11(2790) DEBUG: <core> [core/ip_addr.c:229]: print_ip(): tcpconn_new: new >>> tcp connection: 2.2.2.2 >>> 11(2790) DEBUG: <core> [core/tcp_main.c:1175]: tcpconn_new(): on port 5060, >>> type 2, socket -1 >>> 11(2790) DEBUG: <core> [core/tcp_main.c:1494]: tcpconn_add(): hashes: >>> 2712:0:0, 1 >>> 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) >>> 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> [core/onsend.c:50]: run_onsend(): required >>> parameters are not available - ignoring >>> 27(2806) DEBUG: <core> [core/tcp_main.c:3792]: handle_ser_child(): read >>> response= 7f24e64c1e18, 5, fd 46 from 11 (2790) >>> 27(2806) DEBUG: <core> [core/io_wait.h:375]: io_watch_add(): DBG: >>> io_watch_add(0x56490f0f8060, 46, 2, 0x7f24e64c1e18), fd_no=37 >>> 27(2806) DEBUG: <core> [core/io_wait.h:782]: io_watch_chg(): DBG: >>> io_watch_chg (0x56490f0f8060, 46, 0x1, 0xffffffff) fd_no=38 called >>> 27(2806) DEBUG: <core> [core/io_wait.h:600]: io_watch_del(): DBG: >>> io_watch_del (0x56490f0f8060, 46, -1, 0x0) fd_no=38 called >>> 27(2806) DEBUG: <core> [core/tcp_main.c:4457]: handle_tcpconn_ev(): sending >>> to child, events 1 >>> 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 >>> 19(2798) DEBUG: <core> [core/tcp_read.c:1749]: handle_io(): received n=8 >>> con=0x7f24e64c1e18, fd=8 >>> 19(2798) DEBUG: <core> [core/tcp_read.c:1548]: tcp_read_req(): >>> content-length=0 >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): SIP >>> Reply (status): >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:622]: parse_msg(): >>> version: <SIP/2.0> >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:624]: parse_msg(): >>> status: <200> >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:626]: parse_msg(): >>> reason: <OK> >>> 19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): >>> Found param type 232, <branch> = >>> <z9hG4bK1525.80a9e442000000000000000000000000.0>; state=6 >>> 19(2798) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): >>> Found param type 235, <rport> = <33940>; state=16 >>> 19(2798) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of >>> header reached, state=5 >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:498]: parse_headers(): Via >>> found, flags=2 >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:500]: parse_headers(): >>> this is the first via >>> 19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: >>> parse_to_param(): add param: tag=1mB9HryQ8ZBFc >>> 19(2798) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: >>> parse_addr_spec(): end of header reached, state=29 >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): >>> <To> [59]; uri=[sip:2.2.2.2:5060;transport=tcp >>> <sip:2.2.2.2:5060;transport=tcp>] >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to >>> body (39)[<sip:2.2.2.2:5060;transport=tcp >>> <sip:2.2.2.2:5060;transport=tcp>>], to tag (13)[1mB9HryQ8ZBFc] >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): >>> cseq <CSeq>: <10> <OPTIONS> >>> 19(2798) DEBUG: <core> [core/receive.c:319]: receive_msg(): --- received >>> sip message - reply - call-id: [[email protected] >>> <mailto:[email protected]>] - cseq: [10 OPTIONS] >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:185]: get_hdr_field(): >>> content_length=0 >>> 19(2798) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): >>> found end of header >>> >>> 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? >>> >>> In the case of OPTIONS, Freeswitch is replying correctly to the source >>> port: 33940. >>> >>> 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): >>> >>> recv 1481 bytes from tcp/[1.1.1.1]:33940 at 16:56:47.920698: >>> ------------------------------------------------------------------------ >>> INVITE sip:[email protected] <sip:[email protected]>.com SIP/2.0 >>> Record-Route: <sip:1.1.1.1;transport=tcp;r2=on;lr;nat=yes >>> <sip:1.1.1.1;transport=tcp;r2=on;lr;nat=yes>> >>> Record-Route: <sip:1.1.1.1:5061;transport=tls;r2=on;lr;nat=yes >>> <sip:1.1.1.1:5061;transport=tls;r2=on;lr;nat=yes>> >>> 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" <sip:5135555555@inbound-jail >>> <sip:5135555555@inbound-jail>>;tag=s3i3y2tiOCgnUId5TD4Vp0UChf9GyEy9 >>> To: <sip:991012@inbound-jail <sip:991012@inbound-jail>> >>> Contact: >>> <sip:[email protected]:54887;transport=tls;alias=5.5.5.5~39518~3 >>> <sip:[email protected]:54887;transport=tls;alias=5.5.5.5~39518~3>> >>> 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 >>> >>> v=0 >>> o=- 3812979407 3812979407 IN IP4 5.5.5.5 >>> s=Blink Pro 4.6.0 (MacOSX) >>> t=0 0 >>> m=audio 50016 RTP/SAVP 113 0 101 >>> c=IN IP4 5.5.5.5 >>> a=rtcp:50017 >>> a=rtpmap:113 opus/48000/2 >>> a=fmtp:113 useinbandfec=1 >>> a=rtpmap:0 PCMU/8000 >>> a=rtpmap:101 telephone-event/8000 >>> a=fmtp:101 0-16 >>> a=crypto:1 AES_CM_128_HMAC_SHA1_80 >>> inline:UhHq6hth9HqALmiJ3AEeoGkixObBzkLURG60wJKT >>> a=crypto:2 AES_CM_128_HMAC_SHA1_32 >>> inline:VKYaSCVwgvXCPaRvudTrgLORhWmOA7wyDJVeGjcu >>> a=sendrecv >>> a=oldmediaip:172.22.199.110 >>> a=oldmediaip:172.22.199.110 >>> ------------------------------------------------------------------------ >>> >>> This doesn’t seem valid, as the top Via doesn’t have a port specified? >>> >>> For reference, just rebuilt form the 5.4 branch today: >>> >>> commit 62dff5b8b157236cae7defe64291a6e4a8ae27b5 (upstream/5.4) >>> Author: Kamailio Dev <[email protected] >>> <mailto:[email protected]>> >>> Date: Wed Oct 28 20:16:28 2020 +0100 >>> >>> modules: readme files regenerated - modules ... [skip ci] >>> >>> Thanks! >>> >>> ~Noah >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> [email protected] <mailto:[email protected]> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> > _______________________________________________ > Kamailio (SER) - Users Mailing List > [email protected] <mailto:[email protected]> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
