June 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

Audio quality
by Adiseshu Channasamudhram 25 Jul '22

25 Jul '22

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

2 2

Using Specific TLS Ciphers (1.10.7)
by Michael Meehan 14 Jul '22

14 Jul '22

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: <X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=TLS_RSA_WITH_AES_128_CBC_SHA256"/> 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. <X-PRE-PROCESS cmd="set" data="sip_tls_ciphers=ALL:!ADH:!DH:!ECDH:!LOW:!EXP:!MD5:@STRENGTH"/> 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

1 1

xml_cdr problem using sip_from_user
by Jason Holden 04 Jul '22

04 Jul '22

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 <http://www.thinksimplicity.com>

3 2

Outbound call works for 30 seconds
by Terry Barnum 29 Jun '22

29 Jun '22

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

1 0

Unexpected BYE reason 488 after RE-INVITE
by Igor Potjevlesch 27 Jun '22

27 Jun '22

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

2 5

Re: [Freeswitch-users] WebSocket client in a lua script
by Denis Papes 24 Jun '22

24 Jun '22

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(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