June 2022 - FreeSWITCH-users - FreeSWITCH Mailing Lists

WebSocket client in a lua script
by Peiffer Eric 23 Jun '22

23 Jun '22

Hi all, Is it a way in order to implement a websocket client in a LUA script? Regards Eric

1 0

XML dialplan for Bridging two incoming calls with bypass media
by Aditya Uppuluri 22 Jun '22

22 Jun '22

Hello Team, I am new to freeswitch and trying figure out if there is a way to bridge two incoming calls using XML dialplan. I saw that we can use conference app but i want to bridge them with bypass media at first and then involve freeswitch later if I require to play any greeting/announcements etc., caller ====> kamailio ====> FS <==== kamailio <==== callee Regards, Aditya Uppuluri

2 1

Re: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE
by Brian West 22 Jun '22

22 Jun '22

Igore, It's called 3pcc or Third Party Call Control, you'll need to enable it on every profile that call will touch, we also support the setting to true or proxy. https://freeswitch.org/confluence/display/FREESWITCH/Sofia+Configuration+Fi… Thanks, Brian On Wed, Jun 22, 2022 at 9:38 AM kaiduan xie via FreeSWITCH-users < freeswitch-users(a)lists.freeswitch.org> wrote: > > > > ---------- Forwarded message ---------- > From: kaiduan xie <kaiduanx(a)yahoo.ca> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Cc: > Bcc: > Date: Wed, 22 Jun 2022 13:12:31 +0000 (UTC) > Subject: Re: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE > The first reINVITE with inactive looks like a hold, the second reINVITE > without SDP looks like a resume, what is the third reINVITE for? Does FS > receive ACK for the third reINVITE? > > I think if FS returns sendonly for reINVITE without SDP, FS will not > receive BYE. > > /Kaiduan > > On Wednesday, June 22, 2022 at 08:14:08 a.m. EDT, Igor Potjevlesch < > igor.potjevlesch(a)gmail.com> wrote: > > > Hello, > > > > No idea? > > > > Regards, > > > > Igor. > > Le ven. 17 juin 2022 à 16:44, Igor Potjevlesch <igor.potjevlesch(a)gmail.com> > a écrit : > > Hi! > > > > I cannot figure out why my call is disconnected in this scenario: > > UA1 --> FS --> GW --> UA2 (I think it’s a Cisco Phone and/or CUCM) > > > > UA2 sends a first RE-INVITE with media attribute "inactive". FS is > replying with 200 OK inactive. > > Then, UA2 sends a second RE-INVITE without SDP. FS is replying with 200 OK > inactive. > > Then, UA2 sends a third RE-INVITE without SDP. FS is replying with 200 OK > inactive. > > And just a couple of ms after, FS sends the BYE with 488 No answer to > offer. > > > > Do you have any idea of the origin? > > > > Regards, > > > > Igor. > > _________________________________________________________________________ > > The FreeSWITCH project is sponsored by SignalWire https://signalwire.com > Enhance your FreeSWITCH install with disruptive priced SMS and PSTN > services. > Build your next product on our scalable cloud platform. > > Join our online community to chat in real time > https://signalwire.community > > Professional FreeSWITCH Services > sales(a)freeswitch.com > https://freeswitch.com > > Official FreeSWITCH Sites > https://freeswitch.com/oss > https://freeswitch.org/confluence > https://cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > https://freeswitch.com > > > > ---------- Forwarded message ---------- > From: kaiduan xie via FreeSWITCH-users < > freeswitch-users(a)lists.freeswitch.org> > To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> > Cc: > Bcc: > Date: Wed, 22 Jun 2022 06:38:13 -0700 (PDT) > Subject: Re: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE > _________________________________________________________________________ > > The FreeSWITCH project is sponsored by SignalWire https://signalwire.com > Enhance your FreeSWITCH install with disruptive priced SMS and PSTN > services. > Build your next product on our scalable cloud platform. > > Join our online community to chat in real time > https://signalwire.community > > Professional FreeSWITCH Services > sales(a)freeswitch.com > https://freeswitch.com > > Official FreeSWITCH Sites > https://freeswitch.com/oss > https://freeswitch.org/confluence > https://cluecon.com > > FreeSWITCH-users mailing list > FreeSWITCH-users(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > https://freeswitch.com -- Brian West | Co-founder and Developer Need Commercial support? email sales(a)freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&e…> Email: brian(a)freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>

1 0

REFER handling problem
by Thomas de Rooij | CM.com 22 Jun '22

22 Jun '22

Hi all, I'm having trouble with Freeswitch handing a REFER scenario. The following flow is from an actual call where 10.10.10.10 is a Freeswitch machine that should handle the REFER message: 222.22.222.222:5060 10.10.10.10:5060 10.10.10.11:5060 10.10.10.12:5060 ──────────┬───────── ──────────┬───────── ──────────┬───────── ──────────┬───────── │ INVITE (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.001396 │ 100 Trying │ │ │ │ <────────────────────────── │ │ │ +0.000845 │ 180 Ringing │ │ │ │ <────────────────────────── │ │ │ +0.003244 │ │ INVITE (SDP) │ │ │ │ ──────────────────────────> │ │ +0.005757 │ │ 100 Trying │ │ │ │ <────────────────────────── │ │ +0.115697 │ │ 200 OK (SDP) │ │ │ │ <────────────────────────── │ │ +0.020056 │ 200 OK (SDP) │ │ │ │ <────────────────────────── │ │ │ +0.095132 │ ACK │ │ │ │ ──────────────────────────> │ │ │ +0.000696 │ │ ACK │ │ │ │ ──────────────────────────> │ │ +1.901472 │ │ REFER │ │ │ │ <────────────────────────── │ │ +0.000528 │ │ 202 Accepted │ │ │ │ ──────────────────────────> │ │ +0.000105 │ │ NOTIFY │ │ │ │ ──────────────────────────> │ │ +0.000198 │ INVITE (SDP) │ │ │ │ <────────────────────────── │ │ │ +0.003230 │ │ 200 OK │ │ │ │ <────────────────────────── │ │ +0.000296 │ │ BYE │ │ │ │ ──────────────────────────> │ │ +0.001659 │ 100 Trying │ │ │ │ ──────────────────────────> │ │ │ +0.019175 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.002738 │ ACK │ │ │ │ <────────────────────────── │ │ │ +0.000287 │ INVITE (SDP) │ │ │ │ <────────────────────────── │ │ │ +0.005444 │ 100 Trying │ │ │ │ ──────────────────────────> │ │ │ +0.021372 │ │ INVITE (SDP) │ │ │ ────────────────────────────────────────────────────────> │ +0.007074 │ │ 100 Trying │ │ │ <──────────────────────────────────────────────────────── │ +0.006919 │ │ 200 OK (SDP) │ │ │ <──────────────────────────────────────────────────────── │ +0.036307 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.005278 │ ACK │ │ │ │ <────────────────────────── │ │ │ +0.179349 │ INVITE │ │ │ │ <────────────────────────── │ │ │ +0.003849 │ 100 Trying │ │ │ │ ──────────────────────────> │ │ │ +0.002510 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.007616 │ │ 200 OK │ │ │ │ <────────────────────────── │ │ +0.265244 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.227210 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +0.772969 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.227103 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +1.772828 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.228480 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.770628 │ │ 200 OK (SDP) │ │ │ <──────────────────────────────────────────────────────── │ +0.228179 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +3.772980 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.227158 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.773918 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.225763 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.775424 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.224982 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.776155 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.223281 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.776986 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.223503 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.777505 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.223478 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +0.271627 │ │ BYE │ │ │ <──────────────────────────────────────────────────────── │ +0.000958 │ │ 200 OK │ │ │ ────────────────────────────────────────────────────────> │ +0.000117 │ │ ACK │ │ │ ────────────────────────────────────────────────────────> │ +0.020239 │ BYE │ │ │ │ <────────────────────────── │ │ │ +0.008562 │ 200 OK │ │ │ │ ──────────────────────────> │ │ │ +0.000251 │ ACK │ │ │ │ <────────────────────────── │ │ │ As you can see the far end sends a BYE because of an ACK timeout. The thing is, I can see in the Freeswitch debug logs that the 200 OK, from both legs, is received by Freeswitch (logs after the last 200 OK from the A leg): tport.c:3052 tport_deliver() tport_deliver(0x7f17c00043d0): msg 0x7f17c0074950 (840 bytes) from udp/222.22.222.222:5060/sip next=(nil) nta.c:3370 agent_recv_response() nta: received 200 OK for INVITE (52572546) nta.c:3437 agent_recv_response() nta: 200 OK is going to a transaction nta.c:9716 outgoing_duplicate() nta: 200 OK is duplicate response to 52572546 INVITE nta.c:9723 outgoing_duplicate() Via: SIP/2.0/UDP 10.10.10.10 ;branch=z9hG4bKprBXUe0Xyc7eH nta.c:7236 _nta_incoming_timer() nta: timer J fired, terminate 202 response nta.c:5896 incoming_reclaim_queued() incoming_reclaim_all((nil), (nil), 0x7f17e93b3c10) nta.c:7265 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 1/9 term, 1/9 free nta.c:1308 agent_timer() nta: timer set next to 20 ms nta.c:7236 _nta_incoming_timer() nta: timer J fired, terminate 200 response nta.c:5896 incoming_reclaim_queued() incoming_reclaim_all((nil), (nil), 0x7f17e93b3c10) nta.c:7265 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 1/8 term, 1/8 free nta.c:1308 agent_timer() nta: timer set next to 5 ms nta.c:9221 outgoing_timer_dk() nta: timer D fired, terminate INVITE (52572544) nta.c:8893 outgoing_reclaim_queued() outgoing_reclaim_all((nil), (nil), 0x7f17e93b3d00) nta.c:9040 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/2 tout, 1/4 term, 1/6 free nta.c:1308 agent_timer() nta: timer set next to 2 ms nta.c:9102 outgoing_timer_bf() nta: timer F fired, terminating ACK (52572544) nta.c:8893 outgoing_reclaim_queued() outgoing_reclaim_all((nil), (nil), 0x7f17e93b3d00) nta.c:9040 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 1/2 tout, 0/3 term, 1/5 free nta.c:1308 agent_timer() nta: timer set next to 41 ms In the end, after the 200 OK on the BYE transaction, the ACK that should follow the 200 OK for the INVITE transaction is sent. nta.c:6868 incoming_reply() nta: sent 200 OK for BYE (52572561) nua_dialog.c:397 nua_dialog_usage_remove_at() nua(0x7f17c0019a70): removing session usage soa.c:1730 soa_activate() soa_activate(static::0x7f17c000e670, (nil)) called nta.c:2707 nta_tpn_by_url() nta: selecting scheme sip tport.c:3286 tport_tsend() tport_tsend(0x7f17c00043d0) tpn = */10.10.10.12:5060 tport.c:4075 tport_resolve() tport_resolve addrinfo = 10.10.10.12:5060 tport.c:4709 tport_by_addrinfo() tport_by_addrinfo(0x7f17c00043d0): not found by name */10.10.10.12:5060 tport.c:3623 tport_vsend() tport_vsend(0x7f17c00043d0): 498 bytes of 498 to udp/10.10.10.12:5060 tport.c:3521 tport_send_msg() tport_vsend returned 498 2022-06-03 12:38:26.009764 [DEBUG] switch_core_state_machine.c:848 (sofia/Default/2398) Callstate Change ACTIVE -> HANGUP send 498 bytes to udp/[10.10.10.12]:5060 at 12:38:26.027864: ------------------------------------------------------------------------ ACK sip:mailto:2398@10.10.10.50:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.10.10.10;rport;branch=z9hG4bKQ14NX9g1UNX1c Route: <sip:10.10.10.12;lr=on;ftag=X8gN4t41XD8Dc;did=56a.da01> Max-Forwards: 70 From: "31761234567" <sip:mailto:31761234567@10.10.10.10>;tag=X8gN4t41XD8Dc To: <sip:mailto:2398@10.10.10.12:5060>;tag=F6g6a1UDjmBXB Call-ID: 57ac2def-8718-4ea9-a70c-74c4acc3ab49 CSeq: 52572545 ACK Contact: <sip:gw+mailto:fs@10.10.10.10:5060;transport=udp;gw=fs> Content-Length: 0 nta.c:8390 outgoing_send() nta: sent ACK (52572545) to */10.10.10.12:5060 nta.c:8816 outgoing_free() nta: outgoing_free(0x7f17c0016ef0) nua_stack.c:301 nua_stack_event() nua(0x7f17c0019a70): event r_invite 481 Call/Transaction Does Not Exist nua_session.c:4140 signal_call_state_change() nua(0x7f17c0019a70): call state changed: completing -> terminated nua_stack.c:301 nua_stack_event() nua(0x7f17c0019a70): event i_state 200 Early Session Terminated nua_stack.c:301 nua_stack_event() nua(0x7f17c0019a70): event i_terminated 200 Early Session Terminated soa.c:356 soa_destroy() soa_destroy(static::0x7f17c000e670) called nta.c:4541 nta_leg_destroy() nta_leg_destroy(0x7f17c0021720) nua_stack.c:599 nua_stack_signal() nua(0x7f17c0019a70): recv signal r_destroy nta.c:4541 nta_leg_destroy() nta_leg_destroy((nil)) 2022-06-03 12:38:26.009764 [DEBUG] switch_core_state_machine.c:850 (sofia/Default/2398) State HANGUP From the logs I can't figure out why the ACK is only sent AFTER the BYE and not immediately after the first 200 OK. Any help would be greatly appreciated. Kind regard, Thomas

1 0

uuid_bridge with bypass media
by Aditya Uppuluri 22 Jun '22

22 Jun '22

Hello Team, I have an ESL socket inbound to freeswitch that listens for CHANNEL_CREATE events. The XML dialplan does park the call when a call lands on freeswitch. <extension name="sip_forward"> <condition field="destination_number" expression="^sip:(.*)$"> <action application="set" data = "bypass_media=true"/> <action application="park"/> </condition> </extension> Based on some business logic I need to bridge two CHANNELS via esl inbound socket. When I do `uuid_bridge channel1 channel2`, freeswitch is complaining that *at least one channel must be in answered state*. If i answer one of the channels and then do the bridging, then freeswitch is also in the media path. Is there a better way to handle this? Regards, Aditya

1 0

Packaging for EL9 (AlmaLinux)
by Callum Guy 21 Jun '22

21 Jun '22

Hi All, Has anyone in the community been working on packaging against RHEL9? I'm currently running into issues which appear related to the crypto/openssl 3 so i'm hoping someone out there with more experience might have the answers! Many thanks, Callum -- *0333 332 0000 | x-on.co.uk <https://www.x-on.co.uk> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> ** | Coronavirus <https://www.x-on.co.uk/service/surgery-connect/coronavirus.htm>** | Practice Index Reviews <https://practiceindex.co.uk/gp/x-on>* *Our new office address: 22 Riduna Park, Melton IP12 1QT.* X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.

1 0

Trigger playback via network?
by David P 18 Jun '22

18 Jun '22

I would like to trigger playback into a channel, and I'd like to do that using a networked request that indicates the filename. Is there a better way to do it than the following? I'm considering using ESL (in inbound mode). I already have a large dialplan, and rather than reimplement all of it as ESL commands, I thought I could add the uuid_park application into the dialplan at the spot where the inbound channel(s) should be fully configured and active. There would be a separate server running an ESL client, and once it gets an ESL CHANNEL_ANSWER event it would be able to invoke playback until it receives a CHANNEL_DESTROY event. I considered other programmatic ways of doing playback such as mod_python, but they don't address the networked requirement. David

1 1

Disable SOME METHODS in Freeswitch ALLOW header
by Patrick Karton 16 Jun '22

16 Jun '22

Hello, I want to disable/remove some Methods From ALLOW header and freeswitch must generate 405 if it receives a request with unsupported methods. how do we achieve that is freeswitch . Thanks.

1 0

Call center scalability
by Peiffer Eric 13 Jun '22

13 Jun '22

Hi, I'm new in freeswitch and I'm in charge to study the developmnet of a call center using freeswitch. I have read some books and documents about freeswitch scalability, and I have also read the document : "Giovanni_Maruzzelli-OpenSIPS_Summit2016-FreeSWITCH_HA.pdf", here in the link: https://opensips.org/pub/events/2016-05-10_OpenSIPS-Summit_Amsterdam/Giovan… FreeSWITCH High Availability and Scaling - openSIPS<https://opensips.org/pub/events/2016-05-10_OpenSIPS-Summit_Amsterdam/Giovan…> 12/36 OpenSIPS Summit 2016 - Amsterdam gmaruzz(a)OpenTelecom.IT Many FreeSWITCHes as ONE ALL FreeSWITCH Boxes are ACTIVE (and most other boxes are too) – HA Database: Keeps its own State – Distributed FileSystem: Has its own Configuration Writes and Reads Voice Mails – HA Load Balancers and Proxies: Manages NAT Handling (RTP Media and SIP Signaling) opensips.org  In page 32 it is wrote that call center is a special case and the answer is partitioning. Can you tell me a little more about this solution? Regards, Eric

2 1

REFER handling problem
by Thomas de Rooij | CM.com 13 Jun '22

13 Jun '22

Hi all, I'm having trouble with Freeswitch handing a REFER scenario. The following flow is from an actual call where 10.10.10.10 is a Freeswitch machine that should handle the REFER message: 222.22.222.222:5060 10.10.10.10:5060 10.10.10.11:5060 10.10.10.12:5060 ──────────┬───────── ──────────┬───────── ──────────┬───────── ──────────┬───────── │ INVITE (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.001396 │ 100 Trying │ │ │ │ <────────────────────────── │ │ │ +0.000845 │ 180 Ringing │ │ │ │ <────────────────────────── │ │ │ +0.003244 │ │ INVITE (SDP) │ │ │ │ ──────────────────────────> │ │ +0.005757 │ │ 100 Trying │ │ │ │ <────────────────────────── │ │ +0.115697 │ │ 200 OK (SDP) │ │ │ │ <────────────────────────── │ │ +0.020056 │ 200 OK (SDP) │ │ │ │ <────────────────────────── │ │ │ +0.095132 │ ACK │ │ │ │ ──────────────────────────> │ │ │ +0.000696 │ │ ACK │ │ │ │ ──────────────────────────> │ │ +1.901472 │ │ REFER │ │ │ │ <────────────────────────── │ │ +0.000528 │ │ 202 Accepted │ │ │ │ ──────────────────────────> │ │ +0.000105 │ │ NOTIFY │ │ │ │ ──────────────────────────> │ │ +0.000198 │ INVITE (SDP) │ │ │ │ <────────────────────────── │ │ │ +0.003230 │ │ 200 OK │ │ │ │ <────────────────────────── │ │ +0.000296 │ │ BYE │ │ │ │ ──────────────────────────> │ │ +0.001659 │ 100 Trying │ │ │ │ ──────────────────────────> │ │ │ +0.019175 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.002738 │ ACK │ │ │ │ <────────────────────────── │ │ │ +0.000287 │ INVITE (SDP) │ │ │ │ <────────────────────────── │ │ │ +0.005444 │ 100 Trying │ │ │ │ ──────────────────────────> │ │ │ +0.021372 │ │ INVITE (SDP) │ │ │ ────────────────────────────────────────────────────────> │ +0.007074 │ │ 100 Trying │ │ │ <──────────────────────────────────────────────────────── │ +0.006919 │ │ 200 OK (SDP) │ │ │ <──────────────────────────────────────────────────────── │ +0.036307 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.005278 │ ACK │ │ │ │ <────────────────────────── │ │ │ +0.179349 │ INVITE │ │ │ │ <────────────────────────── │ │ │ +0.003849 │ 100 Trying │ │ │ │ ──────────────────────────> │ │ │ +0.002510 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +0.007616 │ │ 200 OK │ │ │ │ <────────────────────────── │ │ +0.265244 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.227210 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +0.772969 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.227103 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +1.772828 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.228480 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.770628 │ │ 200 OK (SDP) │ │ │ <──────────────────────────────────────────────────────── │ +0.228179 │ 200 OK (SDP) │ │ │ │ ──────────────────────────> │ │ │ +3.772980 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.227158 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.773918 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.225763 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.775424 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.224982 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.776155 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.223281 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.776986 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.223503 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +3.777505 │ │ 200 OK (SDP) │ │ │ <<<────────────────────────────────────────────────────── │ +0.223478 │ 200 OK (SDP) │ │ │ │ ────────────────────────>>> │ │ │ +0.271627 │ │ BYE │ │ │ <──────────────────────────────────────────────────────── │ +0.000958 │ │ 200 OK │ │ │ ────────────────────────────────────────────────────────> │ +0.000117 │ │ ACK │ │ │ ────────────────────────────────────────────────────────> │ +0.020239 │ BYE │ │ │ │ <────────────────────────── │ │ │ +0.008562 │ 200 OK │ │ │ │ ──────────────────────────> │ │ │ +0.000251 │ ACK │ │ │ │ <────────────────────────── │ │ │ As you can see the far end sends a BYE because of an ACK timeout. The thing is, I can see in the Freeswitch debug logs that the 200 OK, from both legs, is received by Freeswitch (logs after the last 200 OK from the A leg): tport.c:3052 tport_deliver() tport_deliver(0x7f17c00043d0): msg 0x7f17c0074950 (840 bytes) from udp/222.22.222.222:5060/sip next=(nil) nta.c:3370 agent_recv_response() nta: received 200 OK for INVITE (52572546) nta.c:3437 agent_recv_response() nta: 200 OK is going to a transaction nta.c:9716 outgoing_duplicate() nta: 200 OK is duplicate response to 52572546 INVITE nta.c:9723 outgoing_duplicate() Via: SIP/2.0/UDP 10.10.10.10 ;branch=z9hG4bKprBXUe0Xyc7eH nta.c:7236 _nta_incoming_timer() nta: timer J fired, terminate 202 response nta.c:5896 incoming_reclaim_queued() incoming_reclaim_all((nil), (nil), 0x7f17e93b3c10) nta.c:7265 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 1/9 term, 1/9 free nta.c:1308 agent_timer() nta: timer set next to 20 ms nta.c:7236 _nta_incoming_timer() nta: timer J fired, terminate 200 response nta.c:5896 incoming_reclaim_queued() incoming_reclaim_all((nil), (nil), 0x7f17e93b3c10) nta.c:7265 _nta_incoming_timer() nta_incoming_timer: 0/0 resent, 0/0 tout, 1/8 term, 1/8 free nta.c:1308 agent_timer() nta: timer set next to 5 ms nta.c:9221 outgoing_timer_dk() nta: timer D fired, terminate INVITE (52572544) nta.c:8893 outgoing_reclaim_queued() outgoing_reclaim_all((nil), (nil), 0x7f17e93b3d00) nta.c:9040 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/2 tout, 1/4 term, 1/6 free nta.c:1308 agent_timer() nta: timer set next to 2 ms nta.c:9102 outgoing_timer_bf() nta: timer F fired, terminating ACK (52572544) nta.c:8893 outgoing_reclaim_queued() outgoing_reclaim_all((nil), (nil), 0x7f17e93b3d00) nta.c:9040 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 1/2 tout, 0/3 term, 1/5 free nta.c:1308 agent_timer() nta: timer set next to 41 ms In the end, after the 200 OK on the BYE transaction, the ACK that should follow the 200 OK for the INVITE transaction is sent. nta.c:6868 incoming_reply() nta: sent 200 OK for BYE (52572561) nua_dialog.c:397 nua_dialog_usage_remove_at() nua(0x7f17c0019a70): removing session usage soa.c:1730 soa_activate() soa_activate(static::0x7f17c000e670, (nil)) called nta.c:2707 nta_tpn_by_url() nta: selecting scheme sip tport.c:3286 tport_tsend() tport_tsend(0x7f17c00043d0) tpn = */10.10.10.12:5060 tport.c:4075 tport_resolve() tport_resolve addrinfo = 10.10.10.12:5060 tport.c:4709 tport_by_addrinfo() tport_by_addrinfo(0x7f17c00043d0): not found by name */10.10.10.12:5060 tport.c:3623 tport_vsend() tport_vsend(0x7f17c00043d0): 498 bytes of 498 to udp/10.10.10.12:5060 tport.c:3521 tport_send_msg() tport_vsend returned 498 2022-06-03 12:38:26.009764 [DEBUG] switch_core_state_machine.c:848 (sofia/Default/2398) Callstate Change ACTIVE -> HANGUP send 498 bytes to udp/[10.10.10.12]:5060 at 12:38:26.027864: ------------------------------------------------------------------------ ACK sip:2398@10.10.10.50:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.10.10.10;rport;branch=z9hG4bKQ14NX9g1UNX1c Route: <sip:10.10.10.12;lr=on;ftag=X8gN4t41XD8Dc;did=56a.da01> Max-Forwards: 70 From: "31761234567" <sip:31761234567@10.10.10.10>;tag=X8gN4t41XD8Dc To: <sip:2398@10.10.10.12:5060>;tag=F6g6a1UDjmBXB Call-ID: 57ac2def-8718-4ea9-a70c-74c4acc3ab49 CSeq: 52572545 ACK Contact: <sip:gw+fs@10.10.10.10:5060;transport=udp;gw=fs> Content-Length: 0 nta.c:8390 outgoing_send() nta: sent ACK (52572545) to */10.10.10.12:5060 nta.c:8816 outgoing_free() nta: outgoing_free(0x7f17c0016ef0) nua_stack.c:301 nua_stack_event() nua(0x7f17c0019a70): event r_invite 481 Call/Transaction Does Not Exist nua_session.c:4140 signal_call_state_change() nua(0x7f17c0019a70): call state changed: completing -> terminated nua_stack.c:301 nua_stack_event() nua(0x7f17c0019a70): event i_state 200 Early Session Terminated nua_stack.c:301 nua_stack_event() nua(0x7f17c0019a70): event i_terminated 200 Early Session Terminated soa.c:356 soa_destroy() soa_destroy(static::0x7f17c000e670) called nta.c:4541 nta_leg_destroy() nta_leg_destroy(0x7f17c0021720) nua_stack.c:599 nua_stack_signal() nua(0x7f17c0019a70): recv signal r_destroy nta.c:4541 nta_leg_destroy() nta_leg_destroy((nil)) 2022-06-03 12:38:26.009764 [DEBUG] switch_core_state_machine.c:850 (sofia/Default/2398) State HANGUP From the logs I can't figure out why the ACK is only sent AFTER the BYE and not immediately after the first 200 OK. Any help would be greatly appreciated. Kind regard, Thomas

1 0