sr-users June 2025

sr-users@lists.kamailio.org

35 participants
35 discussions

How to reply 484 to uac, and send bye to uas
by 13715209697＠139.com 19 Jun '25

19 Jun '25

Hi team: uac kamailio uas --> invite --> invite <-- 200 ok <-- 484 bye ---> Here is my reply_route: onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=~"[12][0-9][0-9]") { route(NATMANAGE); } if ($rs == 200) { t_reply("484", "Address Incomplete"); if (!t_cancel_callid("$ci", "$cs", "0", "200")) { xerr("t_cancel_callid failed\n"); } return; } return; } but not woking. Thanks! Han 2025-06-17

3 4

Kamailio SIPREC
by gcampos＠momenta.network 19 Jun '25

19 Jun '25

has anyone made a successful implementation of SIPREC in kamailio + rtpengine?

1 0

What was working Stop working, Send help
by Fernando Lopes 18 Jun '25

18 Jun '25

Hello everyone, I had this problem before https://kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio.org/t… this was fix, but suddenly with everything the same it stop working, I've tried everything and nothing seems to fix the problem Logs: INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 10 INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 11 INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 11 INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 12 INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 12 INFO: rtpengine [rtpengine.c:3040]: rtpp_test(): rtpengine instance <udp:10.0.0.4:2223> found, support for> INFO: jsonrpcs [jsonrpcs_sock.c:471]: jsonrpc_dgram_process(): a new child 0/4164 Started kamailio.service - Kamailio - the Open Source SIP Server. WARNING: <core> [core/tcp_main.c:1301]: find_listening_sock_info(): binding to source address 10.0.0.4:506> INFO: <core> [core/tcp_main.c:3097]: tcpconn_1st_send(): quick connect for 0x7ec47d7cfab8 sock 13 When I run this command I get this sudo kamailio -f /etc/kamailio/kamailio.cfg -DD -E -e loading modules under config path: /usr/lib/x86_64-linux-gnu/kamailio/modules 0(4778) INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Listening on udp: 10.0.0.4 [10.0.0.4]:5060 advertise <PUBLIC IP>:5060 tcp: 10.0.0.4 [10.0.0.4]:5060 advertise <PUBLIC IP>:5060 Aliases: *: 10.0.0.4:* *: <PUBLIC IP>:* 0(4778) INFO: <core> [core/tcp_main.c:5205]: init_tcp(): using epoll_lt as the io watch method (auto detected) 0(4778) INFO: rr [../outbound/api.h:53]: ob_load_api(): unable to import bind_ob - maybe module is not loaded 0(4778) INFO: rr [rr_mod.c:185]: mod_init(): outbound module not available 0(4778) INFO: jsonrpcs [jsonrpcs_sock.c:219]: jsonrpc_dgram_mod_init(): the socket /var/run/kamailio/kamailio_rpc.sock already exists, trying to delete it... 0(4778) INFO: pike [pike.c:93]: pike_init(): PIKE - initializing 0(4778) INFO: pike [ip_tree.c:79]: init_lock_set(): probing 256 set size 0(4778) INFO: <core> [main.c:3189]: main(): processes (at least): 15 - shm size: 67108864 - pkg size: 8388608 0(4778) INFO: <core> [core/udp_server.c:163]: probe_max_receive_buffer(): SO_RCVBUF is initially 1048576 for fd 7 0(4778) INFO: <core> [core/udp_server.c:233]: probe_max_receive_buffer(): SO_RCVBUF is finally 1048576 on fd 7 0(4778) ERROR: <core> [core/tcp_main.c:3260]: tcp_init(): bind(9, 0x74711968d9c8, 16) on 10.0.0.4:5060 : Address already in use 0(4778) INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized and have this sudo iptables -L -n -v | grep 5060 12 13188 ACCEPT 17 -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 5 260 ACCEPT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5060 1 52 ACCEPT 6 -- !br-aeab3c66b5ee br-aeab3c66b5ee 0.0.0.0/0 172.19.0.5 tcp dpt:5060 0 0 ACCEPT 17 -- !br-aeab3c66b5ee br-aeab3c66b5ee 0.0.0.0/0 172.19.0.5 udp dpt:5060

3 3

RTJson current selected route
by Sergio Charrua 17 Jun '25

17 Jun '25

Hi all! doing some integrations with RTJson module for Kamailio 5.8.4, calling a REST API to return the RTJson's JSON object with 1 or multiple route elements. Kamailio converts the whole SIP headers to JSON using a Javascript function, executed by APP_JDST module, and POSTing the resulting object to the REST API via http_async module. I couldn't find a way to get the current selected route, from the RTJson object, once Kamailio iterates through the JSON object (i.e: using rtjson_push_routes or rtjson_next_route). When the RTJson module iterates through the different routes of the JSON object, is there a way to get the JSON part that defines the route currently being used by RTJson? The goal is to return some custom properties set in each route element of the route array. Once those properties are returned, Kamailio should process them. For example, RTJson supports From and To headers modification and appending new headers with the "extras" element, but there is no way that I know of to modify other headers or remove headers depending on the route. Does anyone know how: 1 - to return current route element from the routes array of the RTJson object ? 2 - to modify / remove headers other than the From and To headers, according to the custom values set in the RTJson returned from a REST API ? Thanks in advance! Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

3 4

usrloc deletes other server's data (suspected bug)
by James Browne 17 Jun '25

17 Jun '25

Hi I've two servers sharing the same postgres database, using kamailio's "server_id" value. One has server_id=184 and the other has server_id=186. I've set these parameters. modparam("usrloc", "server_id_filter", 1) modparam("usrloc", "db_mode", 1) modparam("usrloc", "db_ops_ruid", 1) # I've tested this with both 0 and 1. When a user REGISTERs, I see data being written to two tables, as normal, from server 184. update location set expires='2025-06-11 16:31:58' ... server_id=184 ...' where ruid='uloc-b8-684999a9-31e-1' delete from location_attrs where ruid='uloc-b8-684999a9-31e-1' insert into location_attrs (username,ruid,...) values (...'uloc-b8-684999a9-31e-1' ... The problem comes when I start server 186. select contact,... etc. ..., username from location where server_id=186 select username,ruid,aname,atype,avalue from location_attrs delete from location_attrs where ruid='uloc-b8-684999a9-31e-1' What I see is that server 186 always deletes the data from the location_attrs table that belongs to server 184, which I don't think it should do. According to the usrloc documentation, server_id_filter must be set (as I've done) or "Otherwise one instance of proxy cleans records made by another proxy and that breaks its cache." Therefore this looks like a usrloc bug to me. Am I doing something wrong? I'm testing with a commit that was made yesterday (kamailio 6.1.0-dev1). James

2 1

Question about how $rc works
by Joel Serrano 17 Jun '25

17 Jun '25

Hi All, I have a simple doubt: are these snippets the same? *One:* secf_check_country($hdr(X-SRC-IP-CC)); $var(secf_cc_rc) = $rc; if ($var(secf_cc_rc) == -2) { ... *Two:* $var(secf_cc_rc) = secf_check_country($hdr(X-SRC-IP-CC)); if ($var(secf_cc_rc) == -2) { ... They both seem to work, the docs say to use option -one-. In case they do the same, is there a reason I should pick one over the other? Or is this purely cosmetic? Thanks, Joel.

2 2

Re: dns_hash_put(): unlinked item errors
by JR Richardson 17 Jun '25

17 Jun '25

> > On Jun 10, 2025, at 4:00 PM, JR Richardson via sr-users <sr-users(a)lists.kamailio.org> wrote: > > > > Hey Folks, > > > > Running kamailio 5.8.4, haven't needed or used DNS functions > > previously but recently completed clearip integration, which requires > > sip request to use URL instead of IP and resolve where to send > > request. Within hours of adding URL lookups I started getting dns_hash > > unlinked errors. I correlated the log errors to when the URL changed > > IP. I assume the caching is working because kamailio sends to the same > > IP for a few minutes, then switches IP, sends to new IP for a few > > minutes, then switches IP again and this activity continues. > > > > Here are some log errors: > > > > switch IP > > Jun 10 14:14:17 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b9fcc0 > > Jun 10 14:14:19 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b9fcc0 > > > > switch IP > > Jun 10 14:15:00 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b9ee00 > > Jun 10 14:15:03 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b9ee00 > > > > switch IP > > Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8110]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b8e640 > > Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b8e640 > > > > switch IP > > Jun 10 14:20:37 siprouter1-pve186 /usr/local/sbin/kamailio[8109]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b3eb60 > > > > switch IP > > Jun 10 14:21:12 siprouter1-pve186 /usr/local/sbin/kamailio[8117]: > > WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item > > 0x7fa0f9b830f0 > > Jun 10 14:21:23 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: > > WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): > > unlinked item 0x7fa0f9b830f0 > > > > Here are my DNS config parameters, nothing I've changed made any > > difference. And as far as I can tell I'm not dropping any clearip > > queries. > > dns=no > > rev_dns=no > > use_dns_failover=on > > dns_try_ipv6=no > > > > I did find a patch update for this error back from 2023 and the patch > > is in my /src/core/dns_cache.c as expected but still getting errors. > > > > Any guidance in clearing this error? > > > > Thanks. > > JR > > > Not an answer to your question, but to use failover, use_dns_cache (I believe) needs to be on. > > https://github.com/kamailio/kamailio/blob/master/doc/tutorials/dns.txt > > Fred Posner Hi Fred, I read through the DNS docs and believe I have a good understanding, dns_cache is on my default so you don't have to explicitly define it in the config. After further diagnosis I found the dns errors "dns_hash_put(): unlinked item" happen at the same time the DNS query goes out (around 4min30sec to 5min intervals) but the errors in the log don't happen on every DNS query, they only appear when the URL IP changes. This is what I'm seeing, matching timestamps to DNS queries and SIP Invites to clearip. DNS query clearip.com IP#1 no error DNS query clearip.com IP#1 no error DNS query clearip.com IP#2 error DNS query clearip.com IP#1 error DNS query clearip.com IP#1 no error DNS query clearip.com IP#2 error DNS query clearip.com IP#2 no error DNS query clearip.com IP#2 no error DNS query clearip.com IP#1 error Because I'm not seeing any performance or SIP processing issues, I now believe the log entry is a false positive and can be disregarded, I mean it is a warning, but there is no ill effect as far as I can tell, just a lot of log messages, maybe this message should be downgraded to informational? WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item ...... WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item ...... *****(why is this one "shm_unsafe") Thanks. JR

2 1

Kamailio 5.8.6 confusing ip protocol version of $nh(d) - where does siptrace capture the packet?
by Benoit Panizzon 17 Jun '25

17 Jun '25

Hi Gang I have come across an strange issue. To make rtpengine use the same IP protocol as signaling I examine: ip_type($nh(d)) Now I have encountered a very strange case involving Kamailio with topos and Asterisk. Initial INVITE was performed via IP6 from Asterisk to Kamailio. Then two Re-Invites were performed Kamailio => Asterisk to refresh the session. The first one happened via IPv6 and the $nh(d) ip_type was IPv6 as rtpengine got hinted to use IPv6 On the second one, something went wrong: According to what Kamailio sent to Homer via siptrace module, the Invite was sent to the IPv6 address of the Asterisk machine. rtpengine got hinted IP4, so $nh(d) must have contained an ipv4 address! But the R-URI (provided by topos) contains the IPv6 address of the Asterisk machine. The HEP capture on Asterisk did not record that Re-Invite sent from Kamailio. Neiter via IPv4 nor via IPv6. Has anyone else seen such issues? At which level does the siptrace module work? Is it capturing 'on wire' or is it capturing what kamailio believes it is sending which might be altered when sent out on the wire? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

1 0

$http_rs shows 401 even when final response is 201 (http_async_query + Basic Auth)
by Joel Serrano 17 Jun '25

17 Jun '25

Hi all, I'm seeing some unexpected behavior from $http_rs when using http_async_query() to send a POST request to an endpoint that requires Basic (username/password) authentication. When I use: ``` $http_req(username) = "someuser"; $http_req(password) = "somepass"; ``` the request goes through and the server responds with a *201 Created*, as expected. The response body ($http_rb) contains the correct result. However, $http_rs still shows *401 Unauthorized*. I believe this happens because curl receives a 401 challenge first, then retries with the provided credentials and gets the correct 201. It seems $http_rs is reflecting the status from the initial challenge rather than the final response. This is on Kamailio v6.0.1. As a workaround, I tried manually setting the *Authorization* header like this: ``` $var(credentials) = "someuser:somepass"; $http_req(hdr) = "Authorization: Basic " + $(var(credentials){s.encode.base64}); ``` In that case, $http_rs correctly shows 201. Is it expected for $http_rs to stay at 401 in the first scenario? Or should it reflect the final status code after curl completes the full request cycle? Thanks, Joel.

2 1

Kamailio server not forwarding acknowledgement of 200-OK response to callee
by smh2017＠zoho.com 16 Jun '25

16 Jun '25

Problem: The Kamailio server sends an ack back to the caller UA [Frame 67 below] that it has received its ACK to callee's SIP-Request but Kamailio does not forward the caller UA response to the callee UA. Callee UA continues to send 200-OKs, waiting for an ACK that never arrives, and eventually hangs up. (Note: Blink UAs substitute number ids for user names during call transactions.) Below is some config info. WOW (192.168.1.13) = Blink caller UA registered with Kamailio server on 5060 AMD (192.168.1.11) = Blink callee UA registered with Kamailio server on 5060 Kamailio server @ (192.168.100.50) Kamailio config snippet listen=tls:192.168.100.50:6050 advertise pub-ip-domain.net:6050 listen=tls:192.168.100.50:5061 advertise pub-ip-domain.net:5061 listen=tcp:192.168.100.50:5060 advertise pub-ip-domain.net:5060 Rtpengine config snippet interface = internal/192.168.100.50;external/pub-ip-domain.net WOW and AMD are in a common LAN, Kamailio is in a separate LAN. Both LANs are behind an edge router internet firewall, with port forwarding for SIP port and designated RTP ports to the Kamailio server. The internal LANs are not firewalled from each other. A domain name is associated with the public ip address. Upon answering a call from WOW, AMD sends a 200-OK, expecting WOW to ACK. Kamailio forwards the 200-OK to WOW. The WOW UA responds to the Kamailio Server, sending its ACK [Frame 62] for forwarding, but that does not happen. [Packet 62: 200-OK ACK sent to Kamailio server for forwarding to AMD, but it is not forwarded] Frame 62: 560 bytes on wire (4480 bits), 560 bytes captured (4480 bits) on interface enp1s0, id 0 Section number: 1 Interface id: 0 (enp1s0) Interface name: enp1s0 Encapsulation type: Ethernet (1) Arrival Time: Jun 8, 2025 14:53:39.351196234 EDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1749408819.351196234 seconds [Time delta from previous captured frame: 0.008882710 seconds] [Time delta from previous displayed frame: 0.008882710 seconds] [Time since reference or first frame: 91.952560276 seconds] Frame Number: 62 Frame Length: 560 bytes (4480 bits) Capture Length: 560 bytes (4480 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp:sip] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] .... .... = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Internet Protocol Version 4, Src: 192.168.1.13, Dst: 192.168.100.50 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 546 Identification: 0x9af3 (39667) 010. .... = Flags: 0x2, Don't fragment 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 127 Protocol: TCP (6) Header Checksum: 0x1466 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.1.13 Destination Address: 192.168.100.50 Transmission Control Protocol, Src Port: 49990, Dst Port: 5060, Seq: 5605, Ack: 5124, Len: 506 Source Port: 49990 Destination Port: 5060 [Stream index: 0] [Conversation completeness: Incomplete, DATA (15)] [TCP Segment Len: 506] Sequence Number: 5605 (relative sequence number) Sequence Number (raw): 1801511342 [Next Sequence Number: 6111 (relative sequence number)] Acknowledgment Number: 5124 (relative ack number) Acknowledgment number (raw): 2050979231 0101 .... = Header Length: 20 bytes (5) Flags: 0x018 (PSH, ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 1... = Push: Set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: Â•Â•Â•Â•Â•Â•Â•APÂ•Â•Â•] Window: 8212 [Calculated window size: 2102272] [Window size scaling factor: 256] Checksum: 0x7522 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [Timestamps] [Time since first frame in this TCP stream: 91.952560276 seconds] [Time since previous frame in this TCP stream: 0.051442183 seconds] [SEQ/ACK analysis] [This is an ACK to the segment in frame: 49] [The RTT to ACK the segment was: 0.051442183 seconds] [iRTT: 0.000813889 seconds] [Bytes in flight: 506] [Bytes sent since last PSH flag: 506] TCP payload (506 bytes) Session Initiation Protocol (ACK) Request-Line: ACK sip:19350768@192.168.1.11:64901;transport=tcp SIP/2.0 Method: ACK Request-URI: sip:19350768@192.168.1.11:64901;transport=tcp Request-URI User Part: 19350768 Request-URI Host Part: 192.168.1.11 Request-URI Host Port: 64901 [Resent Packet: False] Message Header Via: SIP/2.0/TCP 192.168.1.13:49990;rport;branch=z9hG4bKPja851a221d11c4c9798e08f721afa637f;alias Transport: TCP Sent-by Address: 192.168.1.13 Sent-by port: 49990 RPort: rport Branch: z9hG4bKPja851a221d11c4c9798e08f721afa637f alias Max-Forwards: 70 From: "WOW" <sip:WOW@pub-ip-domain.net>;tag=7c6e2bc0567345288372495eb190f198 SIP from display info: "WOW" SIP from address: sip:WOW@pub-ip-domain.net SIP from address User Part: WOW SIP from address Host Part: pub-ip-domain.net SIP from tag: 7c6e2bc0567345288372495eb190f198 To: <sip:AMD@pub-ip-domain.net>;tag=347c5038ee5c41d8b92a6d473e80cf24 SIP to address: sip:AMD@pub-ip-domain.net SIP to address User Part: AMD SIP to address Host Part: pub-ip-domain.net SIP to tag: 347c5038ee5c41d8b92a6d473e80cf24 Call-ID: 7f8b4805ba4c4bc784370f99085af625 [Generated Call-ID: 7f8b4805ba4c4bc784370f99085af625] CSeq: 18468 ACK Sequence Number: 18468 Method: ACK Route: <sip:pub-ip-domain.net;transport=tcp;lr;nat=yes> Route URI: sip:pub-ip-domain.net;transport=tcp;lr;nat=yes Route Host Part: pub-ip-domain.net Route URI parameter: transport=tcp Route URI parameter: lr Route URI parameter: nat=yes User-Agent: Blink 6.0.3 (Windows) Content-Length: 0 [Packet 67: Kamailio sends acknowledgement back to WOW that it received the 200-OK ACK, but does NOT forward the ACK to AMD.] Frame 67: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface enp1s0, id 0 Section number: 1 Interface id: 0 (enp1s0) Interface name: enp1s0 Encapsulation type: Ethernet (1) Arrival Time: Jun 8, 2025 14:53:39.394825056 EDT [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1749408819.394825056 seconds [Time delta from previous captured frame: 0.013882451 seconds] [Time delta from previous displayed frame: 0.013882451 seconds] [Time since reference or first frame: 91.996189098 seconds] Frame Number: 67 Frame Length: 54 bytes (432 bits) Capture Length: 54 bytes (432 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp] [Coloring Rule Name: TCP] [Coloring Rule String: tcp] Internet Protocol Version 4, Src: 192.168.100.50, Dst: 192.168.1.13 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT) Total Length: 40 Identification: 0xacb3 (44211) 010. .... = Flags: 0x2, Don't fragment ...0 0000 0000 0000 = Fragment Offset: 0 Time to Live: 64 Protocol: TCP (6) Header Checksum: 0x4390 [validation disabled] [Header checksum status: Unverified] Source Address: 192.168.100.50 Destination Address: 192.168.1.13 Transmission Control Protocol, Src Port: 5060, Dst Port: 49990, Seq: 5124, Ack: 6111, Len: 0 Source Port: 5060 Destination Port: 49990 [Stream index: 0] [Conversation completeness: Incomplete, DATA (15)] [TCP Segment Len: 0] Sequence Number: 5124 (relative sequence number) Sequence Number (raw): 2050979231 [Next Sequence Number: 5124 (relative sequence number)] Acknowledgment Number: 6111 (relative ack number) Acknowledgment number (raw): 1801511848 0101 .... = Header Length: 20 bytes (5) Flags: 0x010 (ACK) 000. .... .... = Reserved: Not set ...0 .... .... = Accurate ECN: Not set .... 0... .... = Congestion Window Reduced: Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 0... = Push: Not set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set [TCP Flags: Â•Â•Â•Â•Â•Â•Â•AÂ•Â•Â•Â•] Window: 501 [Calculated window size: 64128] [Window size scaling factor: 128] Checksum: 0x4a97 [unverified] [Checksum Status: Unverified] Urgent Pointer: 0 [Timestamps] [Time since first frame in this TCP stream: 91.996189098 seconds] [Time since previous frame in this TCP stream: 0.043628822 seconds] [SEQ/ACK analysis] [This is an ACK to the segment in frame: 62] [The RTT to ACK the segment was: 0.043628822 seconds] [iRTT: 0.000813889 seconds] Note: When the call is reversed (AMD-to-WOW), WOW responds with 200-OK, which Kamailio forwards to AMD, but there is no ack-reponse at all from AMD to Kamailio server. WOW eventually hangs up.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users June 2025