- FreeSWITCH-users - FreeSWITCH Mailing Lists

Internal extension and external CELL phone - revisited
by Sean Devoy 25 Oct '21

25 Oct '21

Hi, With Avi's help I have the dial string corrected to: Dial an internal extension. Delay 10 seconds, then dial external number (which happens to be a cell phone) The goal is to set the call timeout to keep the voicemail in FreeSwitch. (For this discussion let's ignore the variability of time to make a connection to a cell phone.) After 10 second delay, FreeSwitch dials the external number just fine. Then the external leg gets a switch_core_media.c:8980 sofia/external/14108089999 Set 2833 dtmf receive payload to 101 It immediately hangs up the internal extension with a switch_ivr_originate.c:3716 Hangup sofia/internal/220@68.143.96.162:1458<mailto:sofia/internal/220@68.143.96.162:1458> [CS_CONSUME_MEDIA] [LOSE_RACE] Note, the cell phone never gets answered by the recipient. Sadly, the call does go to the cell voicemail. Here are my questions: 1 - Is that because the Cell Carrier has actually "answered" the call and is now routing it to the phone? 2 - Can I even go to voicemail on FS after that event or is the call "answered"? Regards, Sean

1 0

PortAudio and codecs
by Clive Lansink 24 Oct '21

24 Oct '21

Hello again. I've at least managed to solve my problem but I always like to know why things work the way they do so I would still appreciate an answer on this. I found a helpful article on how Freeswitch negotiates codecs at https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation. I added the following line to my dial plan at the point where it catches and directs the call to the number I am dialing: <action application="export" data="nolocal:absolute_codec_string=$${outbound_codec_prefs}"/> <action application="bridge" data="sofia/gateway/outbound/$1"/> The example in the article is <action application="export" data="nolocal:absolute_codec_string=PCMA,PCMU"/>, but I preferred to refer back to the global variable outbound_codec_prefs set in vars.xml. So now I presume Freeswitch is transcoding from PortAudio's raw PCM to whatever codec is negotiated when the call is made. So why did this not work in the first place. Why is Freeswitch not honouring outbound_codec_prefs when I make a call from PortAudio? I'm pretty sure this used to work out of the box so I suspect something has changed. Thank you. Clive Lansink Email: Clive(a)Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999 -----Forwarded message----- From: Clive Lansink <clive(a)lansink.co.nz> To: Freeswitch users list <freeswitch-users(a)lists.freeswitch.org> Subject: [Freeswitch-users] PortAudio and codecs Reply-to: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Date: Sun, 24 Oct 2021 01:09:41 +0000 Hi everyone. I need help please to make a call using PortAudio which is failing at the CODEC negotiation step. I've done this successfully in the past but that was a number of Freeswitch versions ago and on a different laptop and something may have changed. I have a recent installation of Freeswitch on a laptop with PortAudio enabled. It registers to our main box running Freeswitch (though a rather older version) which in turn registers to our VOIP provider. When I call a number with the api pa call command, it appears to be successful but nothing happens. Freeswitch.log on the main box shows the following lines that may explain the problem: a13d9197-2a00-4858-92d4-5aed6dc7652d 2021-10-24 13:46:23.400156 [ERR] mod_sofia.c:2247 CODEC NEGOTIATION ERROR. SDP: a13d9197-2a00-4858-92d4-5aed6dc7652d v=0 a13d9197-2a00-4858-92d4-5aed6dc7652d o=FreeSWITCH 1635011588 1635011589 IN IP4 192.168.1.90 a13d9197-2a00-4858-92d4-5aed6dc7652d s=FreeSWITCH a13d9197-2a00-4858-92d4-5aed6dc7652d c=IN IP4 192.168.1.90 a13d9197-2a00-4858-92d4-5aed6dc7652d t=0 0 a13d9197-2a00-4858-92d4-5aed6dc7652d m=audio 24794 RTP/AVP 102 101 a13d9197-2a00-4858-92d4-5aed6dc7652d a=rtpmap:102 L16/16000 a13d9197-2a00-4858-92d4-5aed6dc7652d a=rtpmap:101 telephone-event/16000 a13d9197-2a00-4858-92d4-5aed6dc7652d a=fmtp:101 0-16 a13d9197-2a00-4858-92d4-5aed6dc7652d a=ptime:20 a13d9197-2a00-4858-92d4-5aed6dc7652d a13d9197-2a00-4858-92d4-5aed6dc7652d 2021-10-24 13:46:23.400156 [NOTICE] switch_channel.c:3438 Hangup sofia/internal/1015(a)192.168.1.61 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] I know nothing about SDP but when I look at this it kind of suggests to me that the originating machine is only offering L16/16000 as the CODEC to use. If that is the case then that is the problem because I'm pretty sure the main Freeswitch box is not set up to accept that codec. Back to the laptop, in SIP profiles external.xml, outbound-codec-prefs is set to "$${outbound_codec_prefs}". In vars.xml, outbound_codec_prefs is set to PCMU,PCMA,GSM. I think when it makes the call it should be offering these codecs which are all acceptable to the main Freeswitch box. But then I would expect to see that in the SDP stuff in the log. It should mean the laptop would transcode from the raw PCM data from PortAudio to the codec agreed between the two machines. But that doesn't seem to be happening. The PortAudio configuration does have a parameter for sample-rate which is currently 16000, and there is something to do with timing set to 20. But those are the only parameters I can see that relate to codecs and neither of them actually specify the codec to use. So I'm thinking that PortAudio has nothing to do with codecs, which would make sense. But that means something else in Freeswitch needs to transcode to the real world. Can anyone explain why this is failing? Thank you. Clive Lansink Email: Clive(a)Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999 _________________________________________________________________________ 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

1 0

PortAudio and codecs
by Clive Lansink 24 Oct '21

24 Oct '21

Hi everyone. I need help please to make a call using PortAudio which is failing at the CODEC negotiation step. I've done this successfully in the past but that was a number of Freeswitch versions ago and on a different laptop and something may have changed. I have a recent installation of Freeswitch on a laptop with PortAudio enabled. It registers to our main box running Freeswitch (though a rather older version) which in turn registers to our VOIP provider. When I call a number with the api pa call command, it appears to be successful but nothing happens. Freeswitch.log on the main box shows the following lines that may explain the problem: a13d9197-2a00-4858-92d4-5aed6dc7652d 2021-10-24 13:46:23.400156 [ERR] mod_sofia.c:2247 CODEC NEGOTIATION ERROR. SDP: a13d9197-2a00-4858-92d4-5aed6dc7652d v=0 a13d9197-2a00-4858-92d4-5aed6dc7652d o=FreeSWITCH 1635011588 1635011589 IN IP4 192.168.1.90 a13d9197-2a00-4858-92d4-5aed6dc7652d s=FreeSWITCH a13d9197-2a00-4858-92d4-5aed6dc7652d c=IN IP4 192.168.1.90 a13d9197-2a00-4858-92d4-5aed6dc7652d t=0 0 a13d9197-2a00-4858-92d4-5aed6dc7652d m=audio 24794 RTP/AVP 102 101 a13d9197-2a00-4858-92d4-5aed6dc7652d a=rtpmap:102 L16/16000 a13d9197-2a00-4858-92d4-5aed6dc7652d a=rtpmap:101 telephone-event/16000 a13d9197-2a00-4858-92d4-5aed6dc7652d a=fmtp:101 0-16 a13d9197-2a00-4858-92d4-5aed6dc7652d a=ptime:20 a13d9197-2a00-4858-92d4-5aed6dc7652d a13d9197-2a00-4858-92d4-5aed6dc7652d 2021-10-24 13:46:23.400156 [NOTICE] switch_channel.c:3438 Hangup sofia/internal/1015(a)192.168.1.61 [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] I know nothing about SDP but when I look at this it kind of suggests to me that the originating machine is only offering L16/16000 as the CODEC to use. If that is the case then that is the problem because I'm pretty sure the main Freeswitch box is not set up to accept that codec. Back to the laptop, in SIP profiles external.xml, outbound-codec-prefs is set to "$${outbound_codec_prefs}". In vars.xml, outbound_codec_prefs is set to PCMU,PCMA,GSM. I think when it makes the call it should be offering these codecs which are all acceptable to the main Freeswitch box. But then I would expect to see that in the SDP stuff in the log. It should mean the laptop would transcode from the raw PCM data from PortAudio to the codec agreed between the two machines. But that doesn't seem to be happening. The PortAudio configuration does have a parameter for sample-rate which is currently 16000, and there is something to do with timing set to 20. But those are the only parameters I can see that relate to codecs and neither of them actually specify the codec to use. So I'm thinking that PortAudio has nothing to do with codecs, which would make sense. But that means something else in Freeswitch needs to transcode to the real world. Can anyone explain why this is failing? Thank you. Clive Lansink Email: Clive(a)Lansink.Co.NZ Phone: +64 9 520-4242 Mobile: +64 21 663-999

1 0

Internal Interface suddenly freezes
by Stefan Kainz 22 Oct '21

22 Oct '21

Hi everbody, I have a little bit of a problem. Im using Version 1.10.3. ( but this problem also occurs on version 1.4.18 ) Sometimes the internal Sofia interface just stops responding to SIP Requests. It sometimes happens once every day, and sometimes once a week. It happens at completely random times, like one day in the morning, and the next day in the middle of the night. The freeswitch.log gives me nothing, its like the Sofia interface was stopped. When I try to restart the interface with "sofia profile internal restart” nothing happens. The fs_cli just remains stuck with that command. The solution is to restart the freeswitch service. Sometimes when I recognise it too late, for example in the middle of the night, it seems like the problem solves itself after about 2 hours. The profile just starts working again, without somebody doing anything. I have checked a variety of things, including the firewall & fail2ban, network connection, made sure watchdog is disabled, and also tested it on different Debian-versions and freeswitch versions. It seems this problem occurs on every freeswitch version i have tested. The external-profile on the other hand, keeps working like nothing happened. Both Interfaces listen on the same network-device with a public ip. The only difference is, the internal profile uses a Lua file to handle registrations. Has anybody come across anything similar? Any help is much appreciated! Regards,

7 21

Log dialplan actions?
by Antony Stone 22 Oct '21

22 Oct '21

Hi. I'm just getting the hang of FreeSwitch (long-time user of Asterisk), and wondering: - is there a way to get FS to log dialplan actions as they are executed? Basically, the equivalent of Asterisk's "messages", or even better, "verbose" log files. I'm looking for a way to see how FS is processing calls as they come in, so I can be sure my dialplans are doing what I think they should be. I know I can add "log" actions of my own, but is there something that will simply log each dialplan action automatically? Antony. -- BASIC is to computer languages what Roman numerals are to arithmetic. Please reply to the list; please *don't* CC me.

6 10

Database docs?
by Antony Stone 22 Oct '21

22 Oct '21

Hi. https://freeswitch.com/index.php/2019/08/20/freeswitch-v1-10-1-release/ tells me that there's a 2-year old module called mod_mariadb, but I cannot find anywhere on https://freeswitch.org/confluence/ the documentation about how to use it. Can someone kindly point me in the right direction? Also, just in case there's a simple answer, why isn't mod_odbc_query built into the Debian release packages available at https://files.freeswitch.org/repo/deb/debian-release/ ? I'm running FS 1.10.6 Thanks, Antony. -- "Hi, I've found a fault with the English language and I need an entomologist." "I think you mean an etymologist." "No. It's a bug, not a feature." Please reply to the list; please *don't* CC me.

2 1

UDP/DTLS/SCTP webrtc-datachannel Freeswitch 1.10.6 and sip.js
by Jonathan Hunter 21 Oct '21

21 Oct '21

Hi guys, Just wondered if anyone had suggestions around this or had this issue before, we have 2 web clients using the sip.js library and we are trying to use the data channel to send messages to one another. If I bypass media and send media peer to peer it works fine, however if I try and send an invite with the data channel defined; m=application 52004 UDP/DTLS/SCTP webrtc-datachannel Freeswitch seems to consume this when bridging to the target end point/user. Does freeswitch support SCTP/ webrtc-datachannel if I wanted to present it from leg A to leg B so the media can flow via freeswitch? This is using debian:buster container. Thanks Jon

3 4

RE: Recovery capabilities
by Chris B. Ware 21 Oct '21

21 Oct '21

Hi, I'm playing with, so called, FS High Availability recently. I've had the same feeling of a work in progress features.It works on resuming calls (just few seconds of audio missing during the switchover) and probably keeps the status of the call, also respect the dialplan. It is basically thought to handle two FS box with keepalived managing a shared IP, so if you need to shutdown one of the FS nodes ( I need it in my project)it doesn't work, since the dying FS will drop all the calls, cleaning Recovery table on DB. In 2014 there was a project for a module called mod_ha_cluster, I think is a dead project. Anyway this is a feature that would deserve more attention, indeed. KR,Chris ------------------------------ Message: 3Date: Mon, 18 Oct 2021 22:00:51 +0000From: "Telium Technical Support" <support(a)telium.io>To: <freeswitch-users(a)lists.freeswitch.org>Subject: [Freeswitch-users] Recovery capabilitiesMessage-ID: <0100017c956bef7e-c066e025-cdd8-4e7c-8ee4-94d02bd8ddda-000000(a)email.amazonses.com> Content-Type: text/plain; charset="utf-8" I've been reading about the recovery capabilities of FreeSwitch. It SOUNDSa bit like a work in progress (possibly waiting for funding) - but maybe thedocs are out of date. In terms of current state, can FS: 1. resume calls in progress (on restart) 2. place existing calls back into the dialplan where they where 3. restore queue agents & callers (and their order) -------------- next part --------------An HTML attachment was scrubbed...URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20211018…>

1 0

Hangup and wait for connection after dialed extension is busy.
by Paweł Femur Wojtal 21 Oct '21

21 Oct '21

Hello! Imagine the situation. I call internal extension. It is busy. So I press *0 and hangup. When leg B finishes its connection, freeswitch calls us both and bridges. How do I get such functionality? I will be grateful for any suggestion. -- fe

2 2

playback results in silence
by Bernd Krueger-Knauber 19 Oct '21

19 Oct '21

Hi, we use mod_nibblebill and want to play a wav when the low ballance amount is reached. We noticed alreday that the example in our nibblebill.conf.xml 'play ding' is not working. There is no application play and no file ding. We use now 'playback misc/sorry.wav' for testing. We can see in the log that the file is played and we can here a silence during the playback of the file, but not the voice. If we build a small dialplan entry with 'answer', 'playback misc/sorry.wav', 'hangup', we can here the voice. Any ideas? Best regards, Bernd

1 0