- FreeSWITCH-users - FreeSWITCH Mailing Lists

Tell Conference to stop music by ESL/progammatically?
by Richard Chan 19 May '20

19 May '20

Can I tell the Cnference application to stop the music even if there is only one user programmatically or by ESL? Scenario: I want the default behaviour: when there is one participant, Conference will play music. However one of my "participants" is actually another Conference application (not FreeSWITCH) that can signal to me the number of callers it is currently muxing. In this case if it signals two or more I want to stop the music. From FreeSWITCH POV there is only one channel. Is there a way to use ESL to stop/start the music? (At the moment Confluence seems to be down, and google is drawing a blank here.) -- Richard Chan

3 2

Freeswitch conference Lua
by Ankit 19 May '20

19 May '20

originate {}dialstring &test.lua test.lua looks like api = freeswitch.API() freeswitch.consoleLog("DEBUG", "test1") session:execute("conference", "test_conf"); freeswitch.consoleLog("DEBUG", "test2") Lua script losses control after executing conference Is it possible to continue session in lua after adding the caller to conference ? -- Sent from: http://freeswitch-users.2379917.n2.nabble.com/

3 2

Mulitple execute_on_answers?
by David Villasmil 18 May '20

18 May '20

Hell guys, Any way to execute multiple execute_on_answer? i saw a thread where the OP was directed to https://freeswitch.org/confluence/display/FREESWITCH/Channel+Variables#The_… but i'm not sure i see the relationship. Many thanks! David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

6 10

Correlation between jitter/discarded_packets with choppy audio streams
by Unai Rodriguez 18 May '20

18 May '20

Dear List, We're experiencing choppy/distorted audio streams at times and have been looking into understanding the definition and units of measure of these values reported on the main FS log (i.e. /var/log/freeswitch/freeswitch.log) - r = received - l = lost - j = jitter - p = playout_delay - d = discarded_packets - i = ignored_packets The following log lines seemed to correspond with choppy/distorted audio: ======================================================== ... 2020-05-15 10:18:05.202714 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:18800 <- 10.252.148.73:17592 [r:403 l:0 j:651 p:0 d:87 i:0] ... 2020-05-15 10:25:53.622708 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:22660 <- 10.252.148.56:18572 [r:402 l:0 j:143 p:0 d:84 i:0] ... 2020-05-15 10:43:42.642722 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:18940 <- 10.252.148.72:20800 [r:356 l:0 j:838 p:0 d:79 i:0] ... 2020-05-15 11:00:52.102707 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:20952 <- 10.252.148.61:16540 [r:582 l:0 j:806 p:0 d:66 i:0] ... ======================================================== At this point we believe that having a (d)iscarded value of more than 60 correlates with choppy calls and most of the time those come with (j)itter value of several hundreds. Would it be possible for someone to point out where we could find the definition and unit of measure of those values (i.e.: r, l, j, p, d, i)? Is there any baseline that could be references to determine which calls are being choppy/distorted based on these numbers? We've been trying to understand FS source code and find documentation to no avail. Thank you so much Unai Rodriguez

1 0

Possible incorrectly routed BYE [probably user error]
by . 17 May '20

17 May '20

Hi, I have a situation where we are using FreeSWITCH to field calls through an SBC, which hit an IVR on our FS box. The SBC maintainer is reporting that FreeSWITCH is not sending a BYE upon caller-initiated hangup. The process is: - User calls - Routed through SBC - Our FS box answers and user progresses through IVR, eventually hanging up - SBC does not receive BYE from FreeSWITCH, then 9-10 seconds later SBC sends BYE request due to timeout [not more media] In the logs for a call I see the following: > a16fead2-95b9-11ea-9904-671e76a847b4 2020-05-14 08:05:32.289018 [DEBUG] mod_sofia.c:491 Sending BYE to sofia/external/+41798845230(a)10.8.x.x however this address is _not_ the contact header address, and we never detect any actual BYE message in the SIP logs associated with this. About 10 seconds later we receive a BYE from the SBC via the original contact header address (172.30.xx.xx for example), and everything is finally wrapped up. The BYE IP would NOT be publicly accessible. Based on other similar messages and questions I am assuming that this is a configuration issue somewhere on my part, but I am not certain as to where. Thanks for any insights!

1 0

Correlation between jitter/discarded_packets with choppy audio streams
by Unai Rodriguez 16 May '20

16 May '20

Dear List, We're experiencing choppy/distorted audio streams at times and have been looking into understanding the definition and units of measure of these values reported on the main FS log (i.e. /var/log/freeswitch/freeswitch.log) - r = received - l = lost - j = jitter - p = playout_delay - d = discarded_packets - i = ignored_packets The following log lines seemed to correspond with choppy/distorted audio: ======================================================== ... 2020-05-15 10:18:05.202714 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:18800 <- 10.252.148.73:17592 [r:403 l:0 j:651 p:0 d:87 i:0] ... 2020-05-15 10:25:53.622708 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:22660 <- 10.252.148.56:18572 [r:402 l:0 j:143 p:0 d:84 i:0] ... 2020-05-15 10:43:42.642722 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:18940 <- 10.252.148.72:20800 [r:356 l:0 j:838 p:0 d:79 i:0] ... 2020-05-15 11:00:52.102707 [INFO] mpf_rtp_stream.c:541 () Close RTP Receiver 10.252.148.75:20952 <- 10.252.148.61:16540 [r:582 l:0 j:806 p:0 d:66 i:0] ... ======================================================== At this point we believe that having a (d)iscarded value of more than 60 correlates with choppy calls and most of the time those come with (j)itter value of several hundreds. Would it be possible for someone to point out where we could find the definition and unit of measure of those values (i.e.: r, l, j, p, d, i)? Is there any baseline that could be references to determine which calls are being choppy/distorted based on these numbers? We've been trying to understand FS source code and find documentation to no avail. Thank you so much Unai Rodriguez

1 0

View conference user connected codec and bitrates
by Spencer Lowe 15 May '20

15 May '20

I am trying to find how to view each conference members connected codec and bitrates. They are connecting between a mix of verto and just regular sip. Looking at the data in the channel vars I see the ones for the audio but just not the video. Thanks! Spencer Lowe

1 0

Web site down?
by David Villasmil 15 May '20

15 May '20

-- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

4 6

call after vm is sent
by Joli Martinez 14 May '20

14 May '20

Hello, I have a mailbox that I need to get a call if I get a voicemail message. Is there something like this avail on freeswitch? We have a shared mailbox for after-hours usage and based on whoever is on call, they should get notified that a new VM is avail and be able to check it. We dont want to forward the call directly cause some people will call after hours for nonsense and it could wait until the morning, but if it is important then we will call them back.

2 1

Re: [Freeswitch-users] OPUS: Jitter Buffer for bridged calls to use FEC?
by Alexander Haugg 13 May '20

13 May '20

Hi, thanks for the fast answer. How is it possible to transport the package lost information from the “leg Client B” to the “leg Client A”? If I understand You correct, for the bridged scenario OPUS to OPUS I don’t start a JB on Freeswitch side? Without the JB the OPUS FEC feature cannot used on the Freeswitch. For this case, the Client A need the package lost information from the “leg Client B” to repair the stream via FEC info. The sequence numbers for the “leg Client A” will set new, completely independent from the sequence numbers of the “leg Client B”, for which reason the Client A have no PL (package lost) information. OPUS OPUS Client A (JB) <--------------------- FreeSwitch <------------------- Client B No PL info Package lost Because new Sequence Numbering Is there a FreeSwitch pattern to solve this problem? Or is it not solvable without JB on FreeSwitch side? Thanks a lot! Von: FreeSWITCH-users <freeswitch-users-bounces(a)lists.freeswitch.org> Im Auftrag von Dragos Oancea Gesendet: Dienstag, 12. Mai 2020 14:49 An: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Betreff: Re: [Freeswitch-users] OPUS: Jitter Buffer for bridged calls to use FEC? That snip of documentation for JB is pretty old and obsolete I'd say, it does not mention transcoding + FEC . But where transcoding is used/needed is like a "point of termination". Relevant docs (and best practices) about OPUS + JB + FEC here: https://freeswitch.org/confluence/display/FREESWITCH/FreeSWITCH+And+The+Opu… If there's no JB then it can't be any FEC decoding. If you just do OPUS->FS(bridge)->OPUS then no point of enabling the JB, it only adds delay. Cheers, Dragos On Tue, May 12, 2020 at 10:23 AM Alexander Haugg <Alexander.Haugg(a)c4b.de<mailto:Alexander.Haugg@c4b.de>> wrote: Hi, I try to find out the best practice to use the OPUS features. The scenario is: Client A -------> (JitterBuffer) FreeSwitch -----------------------> Client B <---------------------- FreeSwitch (JitterBuffer) <-------- Is this the correct way? In the documentation for OPUS the message is, JitterBuffer is needed to use FEC. But in the documentation for the JitterBuffer is written: If both sides of a bridge are RTP and both sides have a jb, its fairly useless. In fact if anything, it can worsen call quality. You should only run jitterbuffers at points of termination change of protocol. Examples, if FS was hosting a conference or IVR, if you are bridging the call to a phone for instance, you want to not use a jitterbuffer because you want to preserve the original timestamps so your phone can use its own jitterbuffer. I think, package lost is the start indicator for FEC and normally the RTP sequence number is the indicator for package lost, but the sequence number is valid for the own SSRC space only. That means, if I have lost packages from Client A to Freeswitch is this information on the other side to client B missing, correct? Now the question, what is the best practice handle this scenario? Thanks a lot! Alex _________________________________________________________________________ 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<mailto:sales@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<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com

2 2