From david.villasmil.work at gmail.com Wed Jun 1 12:07:23 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Wed, 1 Jun 2022 13:07:23 +0100 Subject: [Freeswitch-users] force SIP INFO In-Reply-To: References: Message-ID: Anyone on this? Can anyone shed some light ? On Wed, 1 Jun 2022 at 00:03, David Villasmil wrote: > Anyway to force SIP INFO on the outbound side even if telephone event is > present? > > Thanks! > > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > -- Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 -------------- next part -------------- An HTML attachment was scrubbed... URL: From uppuluriaditya at gmail.com Wed Jun 1 15:14:26 2022 From: uppuluriaditya at gmail.com (Aditya Uppuluri) Date: Wed, 1 Jun 2022 20:44:26 +0530 Subject: [Freeswitch-users] Programatically constructing switch_r_sdp Message-ID: Hello Team, Is there a way to programmatically copy the SDP from one leg to the other? I have a situation, where i have two incoming legs and want to bridge them without answering them in freeswitch. I want to know if i can copy the SDP from one leg to the other programmatically (Not via XML but via ESL inbound) I Found that there is a way to do it in XML dialplan like this: How to achieve something similar using ESL inbound? Regards, Aditya -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at freeswitch.org Wed Jun 1 17:54:14 2022 From: mike at freeswitch.org (Mike Jerris) Date: Wed, 1 Jun 2022 11:54:14 -0600 Subject: [Freeswitch-users] force SIP INFO In-Reply-To: References: Message-ID: https://freeswitch.org/confluence/display/FREESWITCH/dtmf_type > On Jun 1, 2022, at 6:07 AM, David Villasmil wrote: > > Anyone on this? Can anyone shed some light ? > > On Wed, 1 Jun 2022 at 00:03, David Villasmil > wrote: > Anyway to force SIP INFO on the outbound side even if telephone event is present? -------------- next part -------------- An HTML attachment was scrubbed... URL: From orn at arnarson.net Thu Jun 2 09:45:37 2022 From: orn at arnarson.net (=?UTF-8?Q?=C3=96rn_Arnarson?=) Date: Thu, 2 Jun 2022 09:45:37 +0000 Subject: [Freeswitch-users] User Variables from directory not accessible Message-ID: Hello guys, I have a bit of a conundrum; I recently upgraded from FreeSWITCH 1.6.12 to 1.10.6. I copied most of the configuration over as-is and most everything works as expected. However, any variables set in the user directory that were previously accessible in the dialplan, such as accountcode and other custom variables that I set are no longer accessible from the dialplan when users originate calls. I can access them via the user_data function as a workaround, but I am struggling to understand why I need to do this. That is, I can access them like so: ${user_data(${caller_id_number}@${domain_name} var accountcode)} But not like so: ${accountcode} In the previous version (and on another FreeSWITCH installation of the same version), the latter is enough. Can anyone think of a reason why this would be the case? I have another FreeSWITCH instance running the same exact version where I can access directory variables without a problem, so it must be a configuration issue or a module that I am missing or something. Regards, Örn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahmood.alkhalil at outlook.com Thu Jun 2 15:35:55 2022 From: mahmood.alkhalil at outlook.com (Mahmood Alkhalil) Date: Thu, 2 Jun 2022 15:35:55 +0000 Subject: [Freeswitch-users] Freeswitch on Kubernetes Message-ID: Would like to hear from anyone who managed to run Freeswitch on Kubernetes ? how did u setup the pod specs ? how did you expose the pod to public access ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From support at naud.io Thu Jun 2 19:15:24 2022 From: support at naud.io (Support from NetworkedAudio LLC) Date: Thu, 2 Jun 2022 19:15:24 +0000 Subject: [Freeswitch-users] Extending mod_esf Message-ID: I’m looking to do multicast send and receive as a module, I’ve looked at mod_esf and also using gstreamer but a mod_portaudio style module would really help. Looking through this list, there have been a few mentions, and a mod_rtp_stream that was begun – I have time and money to put into this now, does anyone know of any projects that already add multicast RTP send and receive capabilities to FreeSWITCH rather than starting fresh? -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidswalkabout at gmail.com Fri Jun 3 02:53:19 2022 From: davidswalkabout at gmail.com (David P) Date: Fri, 3 Jun 2022 14:53:19 +1200 Subject: [Freeswitch-users] Trigger playback via network? Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.villasmil.work at gmail.com Mon Jun 6 19:18:49 2022 From: david.villasmil.work at gmail.com (David Villasmil) Date: Mon, 6 Jun 2022 20:18:49 +0100 Subject: [Freeswitch-users] force SIP INFO In-Reply-To: References: Message-ID: Anyone? Regards, David Villasmil email: david.villasmil.work at gmail.com phone: +34669448337 On Wed, Jun 1, 2022 at 1:07 PM David Villasmil < david.villasmil.work at gmail.com> wrote: > Anyone on this? Can anyone shed some light ? > > On Wed, 1 Jun 2022 at 00:03, David Villasmil < > david.villasmil.work at gmail.com> wrote: > >> Anyway to force SIP INFO on the outbound side even if telephone event is >> present? >> >> Thanks! >> >> >> David Villasmil >> email: david.villasmil.work at gmail.com >> phone: +34669448337 >> > -- > Regards, > > David Villasmil > email: david.villasmil.work at gmail.com > phone: +34669448337 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajnivanza at gmail.com Mon Jun 6 12:24:25 2022 From: rajnivanza at gmail.com (Rajnikant Vanza) Date: Mon, 6 Jun 2022 17:54:25 +0530 Subject: [Freeswitch-users] freeswitch logs don't want to write when call setVariable() and Play TTS prompt Message-ID: Hi Users, We have one scenario, in which we don't want to write any logs when calling set variable function during active call and playing TTS prompt (Refer highlighted string) 86e386f6-ff4c-4fa7-9b53-52836aa8e150 2022-06-06 06:53:19.530899 98.77% [DEBUG] switch_cpp.cpp:773 CoreSession::*setVariable(customerId, 123654789258)* ----------- 2022-06-06 07:09:06.830902 99.03% [INFO] mrcp_client_connection.c:530 (TTS-6) Send MRCPv2 Data 172.28.230.145:41052 <-> 172.28.199.43:20032 [304 bytes] MRCP/2.0 304 SPEAK 1 Channel-Identifier: 8de38aa0-6053-4b00-9 at speechsynth Content-Type: text/plain Speech-Language: en-us Voice-Name: Jackie Vendor-Specific-Parameters: tts-engine=unimrcp:lumenvox;tts-voice=Jackie Content-Length: 62 * 147258369456 * 2022-06-06 07:09:06.910901 99.03% [INFO] mrcp_client_connection.c:635 () Receive MRCPv2 Data 172.28.230.145:41052 <-> 172.28.199.43:20032 [125 bytes] Thank you in advance. Best Regards, Rajnikant Vanza -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.peiffer at al-enterprise.com Wed Jun 8 14:24:03 2022 From: eric.peiffer at al-enterprise.com (Peiffer Eric) Date: Wed, 8 Jun 2022 14:24:03 +0000 Subject: Mod_callcenter scalability In-Reply-To: References: Message-ID: Hi, I'm new in freeswitch world, My goals is to study a call center system using freeswitch. System must be scalable in order to add new freeswitch instance. To do that I have created 2 freeswitch instances loadbalanced by opensips. The 2 freeswitch instances used the same postgres datasbase in order to shared configuration data. Xml files for directory, dialplan, config, etc .. are also the same. So I have one agent associated to one queue configured in the shared postgres database. When user call the callcenter if the agent is free then the call is offered to this agent. If a second user call occurs (call handled by the other fresswitch instance) this call is queued. So every think is working. Then I do not understand why call center is not scalable. If there is issue with callcenter scalablity please could you tell me what? and what would be the solution? Regards. Eric Peiffer -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.peiffer at al-enterprise.com Thu Jun 9 14:07:36 2022 From: eric.peiffer at al-enterprise.com (Peiffer Eric) Date: Thu, 9 Jun 2022 14:07:36 +0000 Subject: Call center scalability Message-ID: 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/Giovanni_Maruzzelli-OpenSIPS_Summit2016-FreeSWITCH_HA.pdf FreeSWITCH High Availability and Scaling - openSIPS 12/36 OpenSIPS Summit 2016 - Amsterdam gmaruzz at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From saied.tazari at gmail.com Fri Jun 10 14:08:01 2022 From: saied.tazari at gmail.com (Saied Tazari) Date: Fri, 10 Jun 2022 16:08:01 +0200 Subject: [Freeswitch-users] debian repos for Raspberry Pi broken? In-Reply-To: References: Message-ID: Dear Andrey, many thanks for the updated instructions under https://freeswitch.org/confluence/display/FREESWITCH/Raspberry+Pi This is to contribute my solution for the errors I got when following these instructions. The problem I realised: apt update failed due to E: Failed to fetch https://freeswitch.signalwire.com/repo/deb/debian-release/dists/bullseye/InRelease 401 Unauthorized E: The repository 'https://freeswitch.signalwire.com/repo/deb/debian-release bullseye InRelease' is not signed. W: GPG error: https://freeswitch.signalwire.com/repo/deb/rpi/debian-release bullseye InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY I "solved" this by adapting your instructions the following way (changes highlighted in red): TOKEN=YOURSIGNALWIRETOKEN apt update && apt install -y gnupg2 wget lsb-release wget --http-user=signalwire --http-password=$TOKEN -O - https://freeswitch.signalwire.com/repo/deb/rpi/debian-release/freeswitch_archive_g0.pub | apt-key add - echo "deb [ Allow-Insecure=yes ] https://freeswitch.signalwire.com/repo/deb/rpi/debian-release/ `lsb_release -sc` main" > /etc/apt/sources.list.d/freeswitch.list echo "deb-src [ Allow-Insecure=yes ] https://freeswitch.signalwire.com/repo/deb/rpi/debian-release/ `lsb_release -sc` main" >> /etc/apt/sources.list.d/freeswitch.list echo "machine freeswitch.signalwire.com login signalwire password $TOKEN" > /etc/apt/auth.conf apt update && apt install -y --allow-unauthenticated freeswitch-meta-all I would be happy to be corrected if there is a better way, because my way is actually generating warnings that this is bad practice. Otherwise, I would be happy to see these changes in your instructions to be sure that my way is ok from your point of view. Kind regards, -- Saied > Andrey Volk wrote on 21-Dec-2021 21:36: > > > > Let me see what I can do. May take some time. > > > > вт, 21 дек. 2021 г. в 23:19, Johan Helsingius >: > > > > > >/Hi, /> >//> >/Trying to install freeswitch on a RPi 4 (Debian 11 Bullseye), /> >/my /etc/apt/sources.list.d/freeswitch.list has: /> >//> >/deb http://files.freeswitch.org/repo/deb/rpi/debian-release/ bullseye > main /> >/deb-src http://files.freeswitch.org/repo/deb/rpi/debian-release/ > bullseye /> >/main /> >//> >/but when I try /> >//> >/apt-get update && apt-get install -y freeswitch-meta-all /> >//> >/I get /> >//> >/Unable to locate package freeswitch-meta-all /> >//> >/apt-cache search freeswitch only gives me: /> >/libsipwitch-dev - secure peer-to-peer SIP VoIP server - development > files /> >/libsipwitch1 - secure peer-to-peer SIP VoIP server - shared libraries /> >/libsipwitch1-dbg - secure peer-to-peer SIP VoIP server - debug symbols /> >/sipwitch - secure peer-to-peer VoIP server for the SIP protocol /> >/sipwitch-cgi - secure peer-to-peer SIP VoIP server - CGI XML-RPC > interface /> >//> >/Any suggestions? /> >//> >/Julf / > -------------- next part -------------- An HTML attachment was scrubbed... URL: From len at freeswitch.org Fri Jun 10 18:40:07 2022 From: len at freeswitch.org (Len Graham) Date: Fri, 10 Jun 2022 14:40:07 -0400 Subject: [Freeswitch-users] debian repos for Raspberry Pi broken? In-Reply-To: References: Message-ID: Hello, Please update the gpg key you used with this one wget --http-user=signalwire --http-password=$TOKEN -O /usr/share/keyrings/signalwire-freeswitch-repo.gpg https://freeswitch. signalwire.com/repo/deb/debian-release/signalwire-freeswitch-repo.gpg Thanks, ~Len On Fri, Jun 10, 2022 at 10:08 AM Saied Tazari wrote: > Dear Andrey, > > many thanks for the updated instructions under > https://freeswitch.org/confluence/display/FREESWITCH/Raspberry+Pi > > This is to contribute my solution for the errors I got when following > these instructions. > > The problem I realised: apt update failed due to > > E: Failed to fetch > https://freeswitch.signalwire.com/repo/deb/debian-release/dists/bullseye/InRelease > 401 Unauthorized > E: The repository ' > https://freeswitch.signalwire.com/repo/deb/debian-release bullseye > InRelease' is not signed. > W: GPG error: > https://freeswitch.signalwire.com/repo/deb/rpi/debian-release bullseye > InRelease: The following signatures couldn't be verified because the > public key is not available: NO_PUBKEY > > > I "solved" this by adapting your instructions the following way (changes > highlighted in red): > > TOKEN=YOURSIGNALWIRETOKEN > apt update && apt install -y gnupg2 wget lsb-release > wget --http-user=signalwire --http-password=$TOKEN -O - > https://freeswitch.signalwire.com/repo/deb/rpi/debian-release/freeswitch_archive_g0.pub > | apt-key add - > echo "deb [ Allow-Insecure=yes ] > https://freeswitch.signalwire.com/repo/deb/rpi/debian-release/ > `lsb_release -sc` main" > /etc/apt/sources.list.d/freeswitch.list > echo "deb-src [ Allow-Insecure=yes ] > https://freeswitch.signalwire.com/repo/deb/rpi/debian-release/ > `lsb_release -sc` main" >> /etc/apt/sources.list.d/freeswitch.list > echo "machine freeswitch.signalwire.com login signalwire password $TOKEN" > > /etc/apt/auth.conf > apt update && apt install -y --allow-unauthenticated freeswitch-meta-all > > > I would be happy to be corrected if there is a better way, because my way > is actually generating warnings that this is bad practice. > > Otherwise, I would be happy to see these changes in your instructions to > be sure that my way is ok from your point of view. > > Kind regards, > > -- Saied > > > > > Andrey Volk wrote on 21-Dec-2021 21:36: > > > > Let me see what I can do. May take some time. > > > > вт, 21 дек. 2021 г. в 23:19, Johan Helsingius >: > > > > > >* Hi, > *> >> >* Trying to install freeswitch on a RPi 4 (Debian 11 Bullseye), > *> >* my /etc/apt/sources.list.d/freeswitch.list has: > *> >> >* deb http://files.freeswitch.org/repo/deb/rpi/debian-release/ bullseye main > *> >* deb-src http://files.freeswitch.org/repo/deb/rpi/debian-release/ bullseye > *> >* main > *> >> >* but when I try > *> >> >* apt-get update && apt-get install -y freeswitch-meta-all > *> >> >* I get > *> >> >* Unable to locate package freeswitch-meta-all > *> >> >* apt-cache search freeswitch only gives me: > *> >* libsipwitch-dev - secure peer-to-peer SIP VoIP server - development files > *> >* libsipwitch1 - secure peer-to-peer SIP VoIP server - shared libraries > *> >* libsipwitch1-dbg - secure peer-to-peer SIP VoIP server - debug symbols > *> >* sipwitch - secure peer-to-peer VoIP server for the SIP protocol > *> >* sipwitch-cgi - secure peer-to-peer SIP VoIP server - CGI XML-RPC interface > *> >> >* Any suggestions? > *> >> >* Julf > * > > > _________________________________________________________________________ > > 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 at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > https://freeswitch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrickarton at hotmail.com Sat Jun 11 13:19:23 2022 From: patrickarton at hotmail.com (Patrick Karton) Date: Sat, 11 Jun 2022 14:19:23 +0100 Subject: [Freeswitch-users] Sharing session between 2 freeswitch Message-ID: An HTML attachment was scrubbed... URL: From lists at telium.io Sun Jun 12 00:12:27 2022 From: lists at telium.io (TTT) Date: Sun, 12 Jun 2022 00:12:27 +0000 Subject: [Freeswitch-users] Sharing session between 2 freeswitch In-Reply-To: References: Message-ID: <0100018155413c64-8e7fc6f5-365a-4062-9491-1e8a33610309-000000@email.amazonses.com> I’m not sure what sharing a SIP session means...you can conference in another leg to the call? HAfs will move calls in progress upon failing over the cluster (https://telium.io/hafs) , but the standby node is not part of the SIP call until failover occurs. -Raj- From: FreeSWITCH-users [mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Patrick Karton Sent: Saturday, June 11, 2022 9:19 AM To: freeswitch-users at lists.freeswitch.org Subject: [Freeswitch-users] Sharing session between 2 freeswitch Hello, Is there an option to share sip sessions between 2 freeswitch instances ? Kind of nominal backup set up. If one fails the other is able to revover and route calls transparently. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan at opensips.org Mon Jun 13 14:58:28 2022 From: bogdan at opensips.org (Bogdan-Andrei Iancu) Date: Mon, 13 Jun 2022 17:58:28 +0300 Subject: [Freeswitch-users] Call center scalability In-Reply-To: References: Message-ID: <581cc4d2-f974-46a6-3072-a737a5e27be4@opensips.org> Hi Eric, I think Giovanni recommends here to use a front OpenSIPS to split the incoming traffic across multiple FreeSWITCH boxes, where each FS box may host an individual queue - this means partitioning the overall Call Center, by running different queues on different FS boxes, not on a single one, to allow some better scalability. Another option may be to us OpenSIPS as front-end running the call queuing part (see the call center module in OpenSIPS) for all the FS boxes. Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer https://www.opensips-solutions.com OpenSIPS Summit 27-30 Sept 2022, Athens https://www.opensips.org/events/Summit-2022Athens/ On 6/9/22 5:07 PM, Peiffer Eric wrote: > 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/Giovanni_Maruzzelli-OpenSIPS_Summit2016-FreeSWITCH_HA.pdf > > FreeSWITCH High Availability and Scaling - openSIPS > > 12/36 OpenSIPS Summit 2016 - Amsterdam gmaruzz at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Thomas.deRooij at cm.com Mon Jun 13 08:20:24 2022 From: Thomas.deRooij at cm.com (Thomas de Rooij | CM.com) Date: Mon, 13 Jun 2022 08:20:24 +0000 Subject: REFER handling problem Message-ID: 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 at 10.10.10.50:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.10.10.10;rport;branch=z9hG4bKQ14NX9g1UNX1c Route: Max-Forwards: 70 From: "31761234567" ;tag=X8gN4t41XD8Dc To: ;tag=F6g6a1UDjmBXB Call-ID: 57ac2def-8718-4ea9-a70c-74c4acc3ab49 CSeq: 52572545 ACK Contact: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrickarton at hotmail.com Thu Jun 16 15:51:44 2022 From: patrickarton at hotmail.com (Patrick Karton) Date: Thu, 16 Jun 2022 15:51:44 +0000 Subject: [Freeswitch-users] Disable SOME METHODS in Freeswitch ALLOW header Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.potjevlesch at gmail.com Fri Jun 17 14:44:32 2022 From: igor.potjevlesch at gmail.com (Igor Potjevlesch) Date: Fri, 17 Jun 2022 16:44:32 +0200 Subject: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE Message-ID: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> 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. -- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidswalkabout at gmail.com Sat Jun 18 11:44:47 2022 From: davidswalkabout at gmail.com (David P) Date: Sat, 18 Jun 2022 23:44:47 +1200 Subject: [Freeswitch-users] Trigger playback via network? In-Reply-To: References: Message-ID: If there were any responses to my query below, please repost them. My subscription to this list was auto-disabled due to 'too many bounces', and I just discovered that and resubscribed. On Fri, 3 Jun 2022, 2:53 pm David P, wrote: > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From callum.guy at x-on.co.uk Tue Jun 21 13:19:35 2022 From: callum.guy at x-on.co.uk (Callum Guy) Date: Tue, 21 Jun 2022 14:19:35 +0100 Subject: [Freeswitch-users] Packaging for EL9 (AlmaLinux) Message-ID: 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   |   **      **  |  Coronavirus **  |   Practice Index Reviews * *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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uppuluriaditya at gmail.com Wed Jun 22 11:10:41 2022 From: uppuluriaditya at gmail.com (Aditya Uppuluri) Date: Wed, 22 Jun 2022 16:40:41 +0530 Subject: [Freeswitch-users] XML dialplan for Bridging two incoming calls with bypass media Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From uppuluriaditya at gmail.com Wed Jun 22 12:01:34 2022 From: uppuluriaditya at gmail.com (Aditya Uppuluri) Date: Wed, 22 Jun 2022 17:31:34 +0530 Subject: [Freeswitch-users] uuid_bridge with bypass media Message-ID: 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.potjevlesch at gmail.com Wed Jun 22 12:13:23 2022 From: igor.potjevlesch at gmail.com (Igor Potjevlesch) Date: Wed, 22 Jun 2022 14:13:23 +0200 Subject: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE In-Reply-To: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> References: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> Message-ID: Hello, No idea? Regards, Igor. Le ven. 17 juin 2022 à 16:44, Igor Potjevlesch 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaiduanx at yahoo.ca Wed Jun 22 13:12:31 2022 From: kaiduanx at yahoo.ca (kaiduan xie) Date: Wed, 22 Jun 2022 13:12:31 +0000 (UTC) Subject: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE In-Reply-To: References: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> Message-ID: <569778354.3983061.1655903551339@mail.yahoo.com> 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 wrote: Hello,   No idea?   Regards,   Igor. Le ven. 17 juin 2022 à 16:44, Igor Potjevlesch 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 at 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 at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at freeswitch.com Wed Jun 22 15:09:17 2022 From: brian at freeswitch.com (Brian West) Date: Wed, 22 Jun 2022 11:09:17 -0400 Subject: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE In-Reply-To: References: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> Message-ID: 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+Files#SofiaConfigurationFiles-enable-3pcc Thanks, Brian On Wed, Jun 22, 2022 at 9:38 AM kaiduan xie via FreeSWITCH-users < freeswitch-users at lists.freeswitch.org> wrote: > > > > ---------- Forwarded message ---------- > From: kaiduan xie > To: FreeSWITCH Users Help > 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 at gmail.com> wrote: > > > Hello, > > > > No idea? > > > > Regards, > > > > Igor. > > Le ven. 17 juin 2022 à 16:44, Igor Potjevlesch > 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 at 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 at 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 at lists.freeswitch.org> > To: FreeSWITCH Users Help > 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 at 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 at 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 at freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 Email: brian at freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com [image: https://www.facebook.com/signalwireinc?src=email] [image: https://twitter.com/freeswitch] -------------- next part -------------- An HTML attachment was scrubbed... URL: From krice at freeswitch.org Wed Jun 22 15:39:03 2022 From: krice at freeswitch.org (krice at freeswitch.org) Date: Wed, 22 Jun 2022 10:39:03 -0500 Subject: [Freeswitch-users] XML dialplan for Bridging two incoming calls with bypass media In-Reply-To: References: Message-ID: <046101d8864e$33f22d30$9bd68790$@freeswitch.org> cant really do that, but what you can do is once they bridge is up, then via API uuid_media off ${UUID} this will reinvite FS out of the media path. uuid_media ${UUID} will inturn take a call that is in bypass and reinvite FS into the media stream From: FreeSWITCH-users On Behalf Of Aditya Uppuluri Sent: Wednesday, June 22, 2022 6:11 AM To: freeswitch-users at lists.freeswitch.org Subject: [Freeswitch-users] XML dialplan for Bridging two incoming calls with bypass media 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Thomas.deRooij at cm.com Wed Jun 22 13:43:00 2022 From: Thomas.deRooij at cm.com (Thomas de Rooij | CM.com) Date: Wed, 22 Jun 2022 13:43:00 +0000 Subject: REFER handling problem Message-ID: <2A7D64D3-7885-4EC3-8869-7120D86ECF14@cm.com> 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 at 10.10.10.50:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 10.10.10.10;rport;branch=z9hG4bKQ14NX9g1UNX1c Route: Max-Forwards: 70 From: "31761234567" ;tag=X8gN4t41XD8Dc To: ;tag=F6g6a1UDjmBXB Call-ID: 57ac2def-8718-4ea9-a70c-74c4acc3ab49 CSeq: 52572545 ACK Contact: 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 From igor.potjevlesch at gmail.com Thu Jun 23 15:45:34 2022 From: igor.potjevlesch at gmail.com (Igor Potjevlesch) Date: Thu, 23 Jun 2022 17:45:34 +0200 Subject: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE In-Reply-To: References: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> Message-ID: Hi, Thank you for your answers. I could move forward with sip_unhold_nosdp=true so now FS replies with the initial proposal in 200 OK when an INVITE without SDP is received. Now that's the UA2 that sends the BYE...but not clear why yet. Regards, Igor. Le mer. 22 juin 2022 à 14:13, Igor Potjevlesch a écrit : > Hello, > > > > No idea? > > > > Regards, > > > > Igor. > > Le ven. 17 juin 2022 à 16:44, Igor Potjevlesch > 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.peiffer at al-enterprise.com Thu Jun 23 16:48:06 2022 From: eric.peiffer at al-enterprise.com (Peiffer Eric) Date: Thu, 23 Jun 2022 16:48:06 +0000 Subject: WebSocket client in a lua script Message-ID: Hi all, Is it a way in order to implement a websocket client in a LUA script? Regards Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaiduanx at yahoo.ca Thu Jun 23 22:02:53 2022 From: kaiduanx at yahoo.ca (kaiduan xie) Date: Thu, 23 Jun 2022 22:02:53 +0000 (UTC) Subject: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE In-Reply-To: References: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> Message-ID: <2129381574.4415849.1656021773669@mail.yahoo.com> Can you paste all SIP messages please? /Kaiduan On Thursday, June 23, 2022 at 11:46:20 a.m. EDT, Igor Potjevlesch wrote: Hi, Thank you for your answers. I could move forward with sip_unhold_nosdp=true so now FS replies with the initial proposal in 200 OK when an INVITE without SDP is received. Now that's the UA2 that sends the BYE...but not clear why yet. Regards, Igor. Le mer. 22 juin 2022 à 14:13, Igor Potjevlesch a écrit : Hello,   No idea?   Regards,   Igor. Le ven. 17 juin 2022 à 16:44, Igor Potjevlesch 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 at 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 at lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.papes at shishko.eu Fri Jun 24 07:50:34 2022 From: denis.papes at shishko.eu (Denis Papes) Date: Fri, 24 Jun 2022 08:50:34 +0100 Subject: [Freeswitch-users] WebSocket client in a lua script In-Reply-To: References: Message-ID: <44daaf8a-a9fc-4e5a-7e41-7bee976a730f@shishko.eu> Yes, by using lua-http https://daurnimator.github.io/lua-http/0.1/ On 6/24/22 08:24, Peiffer Eric via FreeSWITCH-users wrote: > _________________________________________________________________________ > > 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 at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > https://freeswitch.com -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xF10BB43FE31E7C04_and_old_rev.asc Type: application/pgp-keys Size: 6120 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From mmeehan at djsequel.com Fri Jun 24 13:09:11 2022 From: mmeehan at djsequel.com (Michael Meehan) Date: Fri, 24 Jun 2022 13:09:11 +0000 Subject: [Freeswitch-users] Using Specific TLS Ciphers (1.10.7) Message-ID: We’ve been trying to prevent using specific ciphers, mainly Diffie-Hellman. According to the documentation I’ve seen and previous posts in this group, that should be accomplished by using something like this: This doesn’t work. This specific cipher is offered in the CLIENT HELLO and shown as also supported from the SERVER HELLO response amongst others, however, we continue to see DH as being agreed upon: tport_tls.c:974 tls_connect() tls_connect(0x7ff738006e70): events CONNECTING tport_tls.c:974 tls_connect() tls_connect(0x7ff738006e70): events NEGOTIATING tport_tls.c:974 tls_connect() tls_connect(0x7ff738006e70): events NEGOTIATING tport_tls.c:617 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (name): ECDHE-RSA-AES128-GCM-SHA256 tport_tls.c:619 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (version): TLSv1/SSLv3 tport_tls.c:622 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (bits/alg_bits): 128/128 tport_tls.c:625 tls_post_connection_check() tls_post_connection_check(0x7ff738006e70): TLS cipher chosen (description): ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD Other attempts have been made using the following, which also doesn’t appear to function as expected. Any help is appreciated, thanks. FreeSWITCH Version 1.10.7-release.13~64bit (-release.13 64bit) CENTOS 7 3.10.0-1160.62.1.el7.x86_64 -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.potjevlesch at gmail.com Mon Jun 27 09:22:15 2022 From: igor.potjevlesch at gmail.com (Igor Potjevlesch) Date: Mon, 27 Jun 2022 11:22:15 +0200 Subject: [Freeswitch-users] Unexpected BYE reason 488 after RE-INVITE In-Reply-To: References: <000d01d88258$cf8e1dc0$6eaa5940$@gmail.com> Message-ID: <000001d88a07$64aca5b0$2e05f110$@gmail.com> Hi Kaduan, Not easy to anonymize. Do you want to see the final BYE I referred to in my last message or all SIP messages? Regards, Igor. -- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -------------- next part -------------- An HTML attachment was scrubbed... URL: From csadi at hotmail.com Wed Jun 29 02:06:24 2022 From: csadi at hotmail.com (Adiseshu Channasamudhram) Date: Wed, 29 Jun 2022 02:06:24 +0000 Subject: [Freeswitch-users] Audio quality Message-ID: Hello There, I'm having the below audio issue and would really appreciate any help Caller =======Carrier========FS SBC======IVR When i took a packet capture on the FS, I could observe that the audio stream quality from IVR to SBC is really good when compared to the audio quality stream between the SBC and the caller. Bad quality => first syllable of certain words lost, choppy ... Using PCMU 8K on both legs ... Between SBC and IVR - Max Delta is 96ms, max jitter is 22.5 Between sbc and caller - max delta is 120 and max jitter is 9.5 Any suggestion or help would be greatly appreciated Regards A -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry at digital-outpost.com Wed Jun 29 02:09:42 2022 From: terry at digital-outpost.com (=?UTF-8?Q?Terry_Barnum?=) Date: Wed, 29 Jun 2022 02:09:42 +0000 Subject: [Freeswitch-users] Outbound call works for 30 seconds References: <3D0C80E4-A6EA-494A-93BC-4092A07F6957@digital-outpost.com> Message-ID: <01010181ad38aedd-fe86c1e0-c6f7-4f32-89c7-18a7eb812329-000000@us-west-2.amazonses.com> I've got an old version of freeswitch (1.4.6) that's been working in the house for several years with just one extension as a "land line" for an elderly relative. This weekend I added a pfSense box in front of the home network. I followed the docs at https://docs.netgate.com/pfsense/en/latest/recipes/nat-voip-pbx.html so freeswitch and the extension are receiving calls fine but outgoing calls work for only 30 seconds. Some searching suggests an ACK is not making it to the correct place. I got pfSense packet captures of port 5060 on the WAN and the LAN during an outgoing call. I can see the BYE but I don't really know what I'm looking at or what to change in pfSense or freeswitch. Can someone who's familiar with this issue have a look? I'm happy to send the captures to the list but am wondering if there's anything sensitive like login or auth info that might be contained in them? If it's important, vars.xml has external_rtp_ip=stun:stun4.l.google.com:19302 external_sip_ip=stun:stun4.l.google.com:19302 and on startup freeswitch throws: Error checking for PMP [general error]. Thanks for any help! -Terry From jasonh at thinksimplicity.com Wed Jun 29 16:00:21 2022 From: jasonh at thinksimplicity.com (=?UTF-8?Q?Jason_Holden?=) Date: Wed, 29 Jun 2022 16:00:21 +0000 Subject: [Freeswitch-users] xml_cdr problem using sip_from_user References: Message-ID: <01000181b0312ae1-6339ad3f-b5b9-44f9-a612-7969b12d1485-000000@email.amazonses.com> All, Currently using fs 1.8.56 on a demo unit. I’ve noticed that on some CDRS the sip_from_user shows the dialed number that the extension placed when it should show the extension number. This is a speratic issue and I can’t narrow down why this may be happening. I am using a php script to post my CDRS. Does anyone have any suggestions? I do have set to record a / b legs of the call and to prefix the a leg. A snippit from the php script is below.                   $var = $cdr->variables;                 $sql = sprintf("INSERT INTO cdrClients (site_code,npa,call_direction,cac_call_type_id,call_uuid,direction,user,domain,from_user,from_host,to_user,to_host,req_user,req_host,bridge_channel,sip_term_status,sip_term_cause,sip_hangup_disposition,bridge_hangup_cause,hangup_cause,hangup_cause_q850,start_stamp,answer_stamp,end_stamp,duration,billsec)                 VALUES('%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s');",                 $var->site,$var->NPA,$var->call_direction,$var->cac_call_type_id,$var->call_uuid,$var->direction,$var->user_name,$var->domain_name,$var->sip_from_user,$var->sip_from_host,$var->sip_to_user,$var->sip_to_host,$var->sip_req_user,$var->sip_req_host,rawurldecode($var->bridge_channel),$var->sip_term_status,$var->sip_term_cause,$var->sip_hangup_disposition,$var->bridge_hangup_cause,$var->hangup_cause,$var->hangup_cause_q850,rawurldecode($var->start_stamp),rawurldecode($var->answer_stamp),rawurldecode($var->end_stamp),$var->duration,$var->billsec);     Jason Holden   Phone: 1-866-836-9198 X405 Direct: 7868009949 www.thinksimplicity.com     -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1004 bytes Desc: not available URL: From gregor at infomedia.si Thu Jun 30 08:48:48 2022 From: gregor at infomedia.si (Gregor Nanger) Date: Thu, 30 Jun 2022 10:48:48 +0200 Subject: [Freeswitch-users] xml_cdr problem using sip_from_user In-Reply-To: <01000181b0312ae1-6339ad3f-b5b9-44f9-a612-7969b12d1485-000000@email.amazonses.com> References: <01000181b0312ae1-6339ad3f-b5b9-44f9-a612-7969b12d1485-000000@email.amazonses.com> Message-ID: We had a same issue. It started with version 1.10.7. Also posted this question in mailing list. It was told that nothing changed in source code. We solved it to change logic how we are processing cdrs On Wed, 29 Jun 2022, 22:05 Jason Holden, wrote: > All, > > Currently using fs 1.8.56 on a demo unit. > > I’ve noticed that on some CDRS the sip_from_user shows the dialed number > that the extension placed when it should show the extension number. > > This is a speratic issue and I can’t narrow down why this may be happening. > > I am using a php script to post my CDRS. > > Does anyone have any suggestions? > > I do have set to record a / b legs of the call and to prefix the a leg. > > A snippit from the php script is below. > > > > $var = $cdr->variables; > > $sql = sprintf("INSERT INTO cdrClients > (site_code,npa,call_direction,cac_call_type_id,call_uuid,direction,user,domain,from_user,from_host,to_user,to_host,req_user,req_host,bridge_channel,sip_term_status,sip_term_cause,sip_hangup_disposition,bridge_hangup_cause,hangup_cause,hangup_cause_q850,start_stamp,answer_stamp,end_stamp,duration,billsec) > > > VALUES('%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s','%s');", > > > $var->site,$var->NPA,$var->call_direction,$var->cac_call_type_id,$var->call_uuid,$var->direction,$var->user_name,$var->domain_name,$var->sip_from_user,$var->sip_from_host,$var->sip_to_user,$var->sip_to_host,$var->sip_req_user,$var->sip_req_host,rawurldecode($var->bridge_channel),$var->sip_term_status,$var->sip_term_cause,$var->sip_hangup_disposition,$var->bridge_hangup_cause,$var->hangup_cause,$var->hangup_cause_q850,rawurldecode($var->start_stamp),rawurldecode($var->answer_stamp),rawurldecode($var->end_stamp),$var->duration,$var->billsec); > > > > > > Jason Holden > > > > Phone: 1-866-836-9198 X405 > > Direct: 7868009949 > > www.thinksimplicity.com > > > > [image: Logo 2019 Email Final 250] > > > _________________________________________________________________________ > > 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 at 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 at lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > https://freeswitch.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1004 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 1004 bytes Desc: not available URL: