May 2022 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Re: [Freeswitch-users] Issue with Enterprise originate and 487 "ORIGINATOR_CANCEL".
by Christian Berger 25 Oct '22

25 Oct '22

Thanks :) Am 14.01.22 um 16:15 schrieb Zvonimir Bužanić via FreeSWITCH-users: > Hi, I've created pull request: > > https://github.com/signalwire/freeswitch/pull/1520 Christian Berger foncloud GmbH & Co KG Hahlweg 2a 36093 Künzell Tel: / Fax: +49 661 968990-99 Email: Christian.Berger(a)foncloud.net Web: www.foncloud.net P.S.: Wussten Sie schon? Unter https://www.foncloud.net/wissen finden Sie zahlreiche Informationen und hilfreiche Artikel rund um unsere Produkte und Services. Registergericht: Amtsgericht Fulda, Persönlich haftende Gesellschafterin der foncloud GmbH&Co.KG: Global Brain Network GmbHGeschäftsführer der Global Brain Network GmbH: Peter Krug Sitz der Gesellschaft: Künzell. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

4 9

Too long Reason header swallowed
by Gilles SAUVAIRE 02 Sep '22

02 Sep '22

I often have this case. https://github.com/signalwire/freeswitch/issues/1481 does anyone find a workaround ? has anyone made a sofia patch ? This problem happens frequently for me. (Ms Teams send very long text cause) Thanks. Gilles

2 2

Spurious DTMF characters when using RFC2833 with SRTP
by Andy Newlands 04 Aug '22

04 Aug '22

Hi, We have a reproducible problem where spurious DTMF characters are introduced on calls from Freeswitch to a remote (3rd party) IVR, but ONLY when using SRTP (not with RTP) When the spurious character is generated it is: 1. Only ever following a valid/legitimate character (one that was genuinely keyed) 2. Often has a very long duration (see below) 3. Appears to be a random character - often 0x00, but sometimes 0-9/A-F,#,* (and that's when we get problems with the IVR - FS automatically drops the 0x00 values). We have been able to reproduce this from mobile/cell phones and traditional land-lines. I added some code to: switch_rtp.c, in static handle_rfc2833_result_t handle_rfc2833(switch_rtp_t *rtp_session, switch_size_t bytes, int *do_cng), to try to address this. It logs an error (with the character hex value and duration) for DTMF characters with "long" durations (over 10000) and then discards them. As you can see, below, this is a fairly frequent occurrence (although most of the time, the character value is null, so FS drps it, anyway - but sometimes, "real" characters are introduced). 2022-02-28 14:00:53.743665 [NOTICE] switch_vpx.c:599 VPX encoder reset (WxH/BW) from 0x0/0 to 352x288/1024 2022-02-28 14:00:56.103665 [INFO] switch_channel.c:522 RECV DTMF 4:2400 2022-02-28 14:00:56.303664 [ERR] switch_channel.c:557 Ignored invalid DTMF on Call-ID: 3b5d08d3-d898-40b6-ae00-5886713ca6dd, DTMF: 0x0 Duration: 5063 2022-02-28 14:00:56.383661 [INFO] switch_channel.c:522 RECV DTMF 4:2400 2022-02-28 14:00:56.583665 [INFO] switch_channel.c:522 RECV DTMF 5:2400 2022-02-28 14:00:57.063662 [INFO] switch_channel.c:522 RECV DTMF 5:2400 2022-02-28 14:00:57.123670 [INFO] switch_channel.c:522 RECV DTMF 8:2720 2022-02-28 14:00:57.323673 [ERR] switch_rtp.c:686 Discarded long-duration DTMF on Call-ID: 3b5d08d3-d898-40b6-ae00-5886713ca6dd, DTMF: 0x0 Duration: 54088 2022-02-28 14:00:57.603671 [INFO] switch_channel.c:522 RECV DTMF 9:2400 2022-02-28 14:00:57.824102 [INFO] switch_channel.c:522 RECV DTMF 8:2720 2022-02-28 14:00:57.903663 [ERR] switch_rtp.c:686 Discarded long-duration DTMF on Call-ID: 3b5d08d3-d898-40b6-ae00-5886713ca6dd, DTMF: 0x0 Duration: 57002 2022-02-28 14:00:58.183668 [INFO] switch_channel.c:522 RECV DTMF 6:2400 2022-02-28 14:00:58.363666 [ERR] switch_rtp.c:686 Discarded long-duration DTMF on Call-ID: 3b5d08d3-d898-40b6-ae00-5886713ca6dd, DTMF: 0x35 Duration: 57073 2022-02-28 14:00:58.503667 [INFO] switch_channel.c:522 RECV DTMF 9:2400 2022-02-28 14:00:58.643667 [INFO] switch_channel.c:522 RECV DTMF 1:2400 2022-02-28 14:00:58.963663 [INFO] switch_channel.c:522 RECV DTMF 6:2400 2022-02-28 14:00:59.283665 [INFO] switch_channel.c:522 RECV DTMF 1:2400 The first spurious character is 0x00 (which FS will drop anyway) but this could easily be a valid character (and would escape detection because its duration is not too long - it's long but not unreasonable). So, this is an imperfect "fix" as we occasionally see a spurious character with a legitimate value and a "sensible" duration - sufficiently often for users to complain. The last [ERR] entry shows a '5' being introduced but this is dropped because the duration is "crazy" (57073) As mentioned, this does not happen with secure media disabled - only with SRTP. So, I am wondering if the code correctly processes a digit then, sometimes (somehow) incorrectly attempts to decode part of an audio packet as though it were RFC2833. Has anyone else experienced this? Does anyone know what may be causing the problem and what the fix might be. I can provide console output and tcp dumps if required, along with any other details that may help (I'm also comfortable making code changes - to for extra logging/diagnostics etc). Thank you. Kind regards, Andy

4 4

Need help to setup stir shaken in Freeswitch
by Pete Kay 04 Aug '22

04 Aug '22

Hi Does anyone know how to configure Freeswitch for stir shaken? Could you give me some info or doc how to do it? Thanks, Pete

3 3

Re: [Freeswitch-users] debian repos for Raspberry Pi broken?
by Mohammad-Reza Tazari 10 Jun '22

10 Jun '22

Dear Andrey, any news here? Thanks and 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 <julf at julf.com <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>>: > > > >* 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/ <http://files.freeswitch.org/repo/deb/rpi/debian-release/> bullseye main *> >* deb-src http://files.freeswitch.org/repo/deb/rpi/debian-release/ <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 *

3 2

force SIP INFO
by David Villasmil 06 Jun '22

06 Jun '22

Anyway to force SIP INFO on the outbound side even if telephone event is present? Thanks! David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 3

Intermittent RTP gaps when using playback app
by Shaun Stokes 30 May '22

30 May '22

Hi All, We're experiencing intermittent RTP gaps from FreeSWITCH (roughly every 1 in 3 calls), when using the playback app in the dialplan on FreeSWITCH '1.10.7', when listening to the call it sounds like jitter. We've tried using sleep 1000 (after answer), 'jitterbuffer_msec=100:200:20', 'rtp_rewrite_timestamps=true', and 'send_silence_when_idle=400', but the problem remains the same. The problem only occurs when the server is under load, but calls not using the playback app are not affected. Here is an example. [cid:c78434ce-b599-4717-a140-4f250cc2be59] Has anyone come across this problem before, are there any solutions, or could this be a bug? Thanks, Shaun

1 0

freeswitch.org confluence\wiki is down
by Shaun Stokes 28 May '22

28 May '22

Hi All, The freeswitch.org confluence\wiki has been down all day, the following error is displayed when accessing the site. 503 SERVICE UNAVAILABLE CONTACT TEAM(a)SIGNALWIRE.COM OR CALL +1.650.382.0000 I assume there's ongoing maintenance but haven't seen any announcements. Thanks, Shaun

3 2

Build a WebRTC Gateway for Asterisk with Freeswitch (WebRTC to SIP/RTP).
by Manuel Montes Reinhardt 26 May '22

26 May '22

Hello all, I've been looking for documentation on how to build a WebRTC Gateway with Freeswitch (WebRTC to SIP/RTP) but I haven't found anything which could help me. I found something on this maillist: https://lists.freeswitch.org/pipermail/freeswitch-users/2020-April/133228.h… "FreeSwitch for WebRTC to SIP/RTP gateway?" so it seems it could be done but there is no documentation. I'm trying to build a gateway which could translate webrtc into SIP in order to let some users connect their extensions to a PBX based on Asterisk that does not support WebRTC. I'm looking for documentation but also a Company who could help us in the initial configuration. Thank you very much. Regards, Manuel

1 0

Changed mod_xml_cdr
by Gregor Nanger 23 May '22

23 May '22

Something changed in XML that mod_xml_cdr produce with version 1.10.7. When transfer inbound call to extension caller_id_number variable is now extension number instead of number that call inbound. Here is example: *Before 1.10.7* <cdr core-uuid="4649fdb9-37f3-4930-a358-2e04837eb596" switchname="WORK-GREGZ"> <channel_data> <state>CS_REPORTING</state> <direction>outbound</direction> <state_number>11</state_number> <flags>0=1;2=1;22=1;40=1;42=1;91=1;96=1;110=1;112=1;113=1;114=1;115=1</flags> <caps>2=1;4=1;5=1;7=1</caps> </channel_data> <call-stats /> <variables> * <caller_id_number>16006554321</caller_id_number>* *Version 1.10.7* <cdr core-uuid="6733f6e5-2d81-453c-a8c4-e2220df4755b" switchname="WORK-GREGZ"> <channel_data> <state>CS_REPORTING</state> <direction>outbound</direction> <state_number>11</state_number> <flags>0=1;2=1;22=1;40=1;42=1;92=1;97=1;112=1;114=1;115=1;116=1;117=1</flags> <caps>2=1;4=1;5=1;7=1</caps> </channel_data> <call-stats /> <variables> * <caller_id_number>003</caller_id_number>* This kind of change breaks CDR import logic. I am asking if someone else noticed this? Is there some kind of bug or feature request that changed this? BR, Gregor

1 0