- FreeSWITCH-users - FreeSWITCH Mailing Lists

Inverted FROM/TO headers for BYE requests
by Unai Rodriguez 05 Jan '21

05 Jan '21

Dear List, We are having FreeSWITCH behind AVAYA infrastructure and when FreeSWITCH sends a BYE the From and the To headers are inverted. For example this call was initiated by John Smith however the BYE request has the From and To inverted: send 619 bytes to tcp/[10.125.15.122]:5060 at 16:57:04.079105: ------------------------------------------------------------------------ BYE sip:5188@10.125.15.122:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 10.155.20.104;branch=z9hG4bKa99Q7j7crjK9K Max-Forwards: 70 From: <sip:1581@10.155.20.104>;tag=Ze68N90tZ1D0c To: "John Smith" <sip:5188@example.com>;tag=54578355~d340a1b2-9d48-464d-9060-03cf872440b9-97644820 Call-ID: 2ad6b00-ff419a57-85bc53-66199b0a(a)10.125.15.122 CSeq: 30379120 BYE User-Agent: FreeSWITCH-mod_sofia/1.8.6~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Reason: Q.850;cause=16;text="NORMAL_CLEARING" Content-Length: 0 These seems to work for Cisco and other Telephony products but not the particular AVAYA system we're working with. Is there any way to modify this behavior and/or is this a known issue? Thank you so much -- unai

2 1

Automatically authenticating client
by Martyn Davies 05 Jan '21

05 Jan '21

I'm trying to support a downstream client (actually a phone on a VoIP gateway) that must work without sending a registration to Freeswitch. I have a definition in the client directory that looks like this: <include> <user id="0101" cidr="192.168.1.0/24"> <variables> : <variable name="user_context" value="default"/> So, I'm assuming that if the source address matches 192.168.1.x, an invite from 0101 will automatically be authenticated, and the user context will be set to 'default' to go through the dialplan. However, what seems to happen is that the dialplan gets executed in the public context, 0101 doesn't match anything, and so the call fails. I also tried adding entries to the acl.conf file, e.g. e.g. <list name="lan" default="allow"> <node type="allow" cidr="192.168.1.0/24"/> </list> or <list name="localnet.auto" default="allow"> <node type="allow" cidr="192.168.1.0/24"/> </list> or adding an 'allow' line to the existing 'domains' list. When I run 'reloadacl', it looks like the rules are being picked up, e.g. 2021-01-05 11:06:07.631090 [NOTICE] switch_utils.c:642 Adding 192.168.1.0/24 (allow) [] to list localnet.auto 2021-01-05 11:06:07.631090 [NOTICE] switch_utils.c:642 Adding 192.168.1.97/32 (allow) [0101(a)192.168.1.241] to list domains However, none of this works, and I still end up in the public context when a call is placed. I would appreciate any examples or advice that people could offer to get my client authenticated, or could anyone give me pointers on how to debug the authentication process when the invite arrives? Regards, Martyn

2 1

Using turn relay in verto client
by António Silva 29 Dec '20

29 Dec '20

Hi, I want to share my experience with verto client and nat. I’m facing a delay issue with verto clients behind some types of nat (symmetric and port restricted cone nat), the port in the SDP is not the same for media and that introduces 3 seconds delay at the begging of the call. It only occurs in the direction Client -> Freeswitch. From the capture I notice that this delay is cause in the dlls negotiation, the Client Hello is sent to a port that is closed at the client side, after 3seconds FS detects that the rtp traffic is arriving in a natted port and it now send the Client Hello to that port. FS —> Client (pkt flow): 1s. Client Hello ——> :49897 <— (port unreached) 2s. Client Hello ——> :49897 <— (port unreached) 3s. Client Hello ——> :1025 <— Server Hello Certificate —> :1025 (Normal audio) Currently I solve it using turn server in the client and forcing to present only relay candidate to FS, DTLS is negotiated immediately, the only issue I see is that FS is not using the relay server (my configuration), it communicates directly to the client so it detects the change of address during media rtp: 1s. Client Hello ——> relay:49897 ——> client:49897 <— Server Hello:49897 FS RTP —> Relay: 49897 ——> client:49897 FS <— RTP from client address: 49897 (FS detects address change, stop send it to relay address and with to client address) FS RTP —> client:49897 The address change detection is perfect in this situation, we only load the relay server for dtls negotiation, then the media flows directly between FS and Client. What do you think of this approach? Do you have a better solution for this problem? -- Saludos / Regards / Cumprimentos António Silva

1 0

Calls dropping due to SDP change
by Nicola von Thadden 28 Dec '20

28 Dec '20

Hi, I'm currently investigating reproducable call drops when calling mobile-phone numbers from Deutsche Telekom (T-Mobile Germany). My provider has a NGN (SIP) Interconnection with Deutsche Telekom and is transparend for the messages involved here (although IP rewriting is happening). The calls contain following SDP in the invite from my FreeSwitch towards my provider: v=0 o=FreeSWITCH 1608967203 1608967204 IN IP4 *redacted* s=FreeSWITCH c=IN IP4 *redacted* t=0 0 m=audio 32256 RTP/AVP 9 8 0 101 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 Once the call is established, FS sends a re-invite after 50% of the expiration timer is elapsed, 15 minutes in this case. The re-invite contains a slightly modified SDP: v=0 o=FreeSWITCH 1608967203 1608967204 IN IP4 *redacted* s=FreeSWITCH c=IN IP4 *redacted* t=0 0 m=audio 32256 RTP/AVP 8 101 9 0 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 The new codec on position 1 (PCMA) is not necessary the chosen one for the session, that call was using G.722 (verified via 'show channels'). Telekom does not like my SDP change and responds with: SIP/2.0 488 SDP Parameter Error In SIP Request The freeswitch console only logs: 2020-12-26 16:32:49.578925 [DEBUG] sofia.c:7326 Channel sofia/external/*redacted*entering state [calling][0] 2020-12-26 16:32:49.618925 [DEBUG] sofia.c:7319 Channel sofia/external/*redacted* skipping state [ready][488] The call is disconnected 15 minutes later because the session timer has expired: 2020-12-26 16:47:53.838925 [NOTICE] sofia.c:1089 Hangup sofia/external/*redacted* [CS_EXCHANGE_MEDIA] [NORMAL_CLEARING] This does not happen when I only allow PCMA (or any other codec) since the SDP can't get mixed up. I have reproduced that behaviour with 1.10.5~release~6~25569c1631~buster-1~buster+1 and 1.6.20~37~987c9b9-1~jessie+1. Do you have any idea why FS changes the SDP (without reason?) and what I can do about it? Thanks Nico

3 3

docker image
by Joli Martinez 28 Dec '20

28 Dec '20

Hello, Our company is pushing toward Docker now. That is the new focus for next year. Is there a Freeswitch Docker image already available? I searched on Dockerhub and could not find one. If there is not one avail. I was thinking of building one. I was planning on using the latest Debian base image and creating a Dockerfile with the installation of FreeSwitch. Is that the best approach or is there a better alternative? Also is there any reason not to Dockerize Freeswitch? Thanks,

7 8

Rings Versus Seconds
by KitchM 24 Dec '20

24 Dec '20

The system appears to use seconds instead of rings to measure incoming call timing. Is that correct? If so, is there a way to change things to use number or rings instead? -- Sent from: http://freeswitch-users.2379917.n2.nabble.com/

1 0

Fwd: [CFP] FOSDEM 2021, RTC devroom, speakers, volunteers neeeded
by FOSDEM RTC Team 23 Dec '20

23 Dec '20

FOSDEM - Real Time Communications devroom CfP ============================================= NOTE: we have extended the deadline but we will give preference to people who submitted earlier when we set the time for each talk. Please submit your proposal ASAP so that you can get your preferred time slot. Overview -------- [FOSDEM](https://fosdem.org) is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2021 takes place 6-7 February 2021 and for the very first time, it will be online. This document contains information about: - Real-Time Communications developer room (devroom) - speaking opportunities - volunteering New rules for the online edition -------------------------------- This year FOSDEM will be fully online instead of being held in Brussels, here are the most important things to know about this (quite significant) change: - The reference time will be Brussels local time (CET) - Talks will be pre-recorded in advance, and streamed during the event - The Q/A session will be live - A facility will be provided for people watching to chat between themselves - A facility will be provided for people watching to submit questions Call for participation - Real Time Communications (RTC) ------------------------------------------------------- The Real-Time devroom is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, peer-to-peer, privacy and encryption. **We are looking for speakers for the devroom and volunteers who can help manage the scheduling and live Q&A sessions.** The devroom is only on Saturday, 6th of February 2021. To discuss the devroom, volunteer or ask questions, please join the [Free-RTC mailing list](http://lists.freertc.org/mailman/listinfo/discuss). ### Key dates - 20th Dec: Submission deadline (extended to 8 January) - 24th Dec: Announcement of selected talks - 15th Jan: Presentations upload deadline - 6th & 7th Feb: Conference dates (online) - 6th Feb: RTC devroom date (online) ### Speaking opportunities Note: if you used FOSDEM Pentabarf before, please use the same account/username Real-Time Communications devroom: deadline 23:59 UTC on 20th of December. Please use the [Pentabarf](https://penta.fosdem.org/submission/FOSDEM21/) system to submit a talk proposal for the devroom. On the "General" tab, please look for the "Track" option and choose "Real Time Communications devroom". ### First-time speaking? FOSDEM devrooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the devroom administrators personally if you would like to ask any questions about it. This year this is more true than ever, being able to record your presentation offline without an audience in front can greatly help build up one's confidence! ### Submission guidelines The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one. In the "Submission notes", please tell us about: - The purpose of your talk - Any other talk applications (devrooms, lightning talks, main track) - Availability constraints and special needs You can use HTML and links in your bio, abstract and description. If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work. We will be looking for relevance to the conference and devroom themes, presentations aimed at developers of free and open source software about RTC-related topics. Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the devroom administrators based on the number of received proposals. As the two previous devrooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate. Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used. ### Recording help The devroom organization is able to provide help with recording your session. The recording would be performed at a scheduled time with one of us, so you won't be alone giving your presentation. Minimal edits will be possible, but the ideal plan is to record it in one shot. Thanks Dan Jenkins for providing us with the means to do this! Volunteers needed ----------------- To make the devroom run successfully, we are looking for volunteers. This year many things be done for the first time, so all the help we can get is more than welcome. Spread the word and discuss --------------------------- If you know of any mailing lists where this CfP would be relevant, please forward this document. If this devroom excites you, please blog or microblog about it, especially if you are submitting a talk. If you regularly blog about RTC topics, please send details about your blog to the planet site administrators: - All projects https://planet.freertc.org planet(a)freertc.org - XMPP https://planet.jabber.org ralphm(a)ik.nu - SIP https://planet.sip5060.net planet(a)sip5060.net Please also link to the Planet sites from your own blog or web site as this helps everybody in the free real-time communications community. Contact ------- For any private queries, contact us directly using the address **fosdem-rtc-admin(a)freertc.org** and for any other queries please ask on the [Free-RTC mailing list](http://lists.freertc.org/mailman/listinfo/discuss). The devroom administration team: - Saúl Ibarra Corretgé <s(a)saghul.net> - Ralph Meijer <ralphm(a)ik.nu> - Daniel-Constantin Mierla <miconda(a)gmail.com> - Daniel Pocock <daniel(a)pocock.pro> - Guus der Kinderen <guus.der.kinderen(a)gmail.com>

1 0

VLC Errormessage
by R G 20 Dec '20

20 Dec '20

Hi all, i have a problem with the mod_vlc Plugin. Regardless of whether i try to record a conference to stream or a file i get the following error message: 2020-12-19 22:08:09.523574 [INFO] mod_conference.c:433 Auto recording file: vlc://#standard{access=file,mux=raw,dst=/var/freeswitch/meetings/test.wav} 2020-12-19 22:08:09.523574 [DEBUG] conference_loop.c:1338 Setup timer soft success interval: 20 samples: 960 from codec opus 2020-12-19 22:08:09.523574 [DEBUG] conference_record.c:304 Setup timer success interval: 20 samples: 960 2020-12-19 22:08:09.523574 [ERR] mod_vlc.c:772 VLC error: cannot initialise VLC handle 2020-12-19 22:08:09.523574 [ERR] conference_record.c:277 Error Opening File [vlc://#standard{access=file,mux=raw,dst=/var/freeswitch/meetings/test.wav}] 2020-12-19 22:08:09.523574 [ERR] switch_core_timer.c:117 Timer is not properly configured. 2020-12-19 22:08:09.523574 [INFO] conference_record.c:425 Recording of vlc://#standard{access=file,mux=raw,dst=/var/freeswitch/meetings/test.wav} Stopped This is my conference.conf.xml: <param name="auto-record" value="vlc://#standard{access=file,mux=raw,dst=/var/freeswitch/meetings/test.wav}"/> I use a Ubuntu 16.04 and libVLC is installed: libvlc-dev/xenial-updates,xenial-security,now 2.2.2-5ubuntu0.16.04.4 amd64 [installed] libvlc5/xenial-updates,xenial-security,now 2.2.2-5ubuntu0.16.04.4 amd64 [installed,automatic] libvlccore-dev/xenial-updates,xenial-security,now 2.2.2-5ubuntu0.16.04.4 amd64 [installed] libvlccore8/xenial-updates,xenial-security,now 2.2.2-5ubuntu0.16.04.4 amd64 [installed,automatic] vlc-data/xenial-updates,xenial-updates,xenial-security,xenial-security,now 2.2.2-5ubuntu0.16.04.4 all [installed,automatic] Kind regards, Robert

1 1

Tracking Call Leg through Callcenter
by Nathan Stratton 19 Dec '20

19 Dec '20

On calls flowing them my FreeSWITCH box I use: <action application="set" data="sip_h_In-Reply-To=${sip_call_id}"/> Before bridge, to correlate my call legs between my public and private networks. The problem is if I put that before application callcenter it is not added. Is there any way to make correlate legs going into and then out from callcenter? <extension name="HesslerKnivesSams-queue_en"> <condition field="destination_number" expression="^HesslerKnivesSams-queue_en$"> <action application="export" data="dialed_extension=$1"/> <action application="set" data="hangup_after_bridge=true"/> <action application="set" data="bypass_media=false"/> <action application="set" data="record_concat_video=true"/> <action application="set" data="enable_file_write_buffering=false"/> <action application="set" data="core_video_blank_image=/media/frame.png"/>  <action application="callcenter" data=" HesslerKnivesSams-queue_en(a)troc.vocinity.com"/> <action application="export" data="nolocal:absolute_codec_string=VP8,OPUS"/> <action application="bridge" data="sofia/gateway/gateway/HesslerKnivesSams-busy_en"/> </condition> </extension> ><> nathan stratton

1 0

Reasons for call dropped/RFC2543 incompatible destination
by Robert Fitzjohn 19 Dec '20

19 Dec '20

Hello, FreeSwitch v. 1.6.20 I'm calling my own mobile no. via my localphone gateway, and while this used to work when I last tested it a while ago, recently the call no longer goes through, with freeswitch dropping the call with the RFC2543 warning and then 'incompatible destination'. Codecs on both sides look good & calling other mobile numbers on other networks via the same gateway works fine, for what it's worth. The fuller/anonymized paste is at: https://pastebin.freeswitch.org/view/ddafee03 but the bits which I think matter are below. Could someone give me any hints as to whether this is a FS issue or whether the problem lies with my gateway or otherwise. Thanks - recv 1205 bytes from udp/[94.0.0.0]:5060 at 10:21:18.751270: - ------------------------------------------------------------------------ - SIP/2.0 183 Session Progress - Via: SIP/2.0/UDP 45.0.0.0:5080;rport=5080;branch=z9hG4bKHNUQK4208H7Br - Record-Route: <sip:95.0.0.0:5070 ;lr;ftag=lp-2k9-5ee88476-00002a55-0005d2b3R2d70439b.a>,<sip:94.1.1.1;lr=on>,<sip:94.0.0.0;lr=on;ftag=B3N7U1NHeem0F;an=YWJjREVENjg5JiUnPDkyE2laNj48LXtVYWEGaiYpXA--> - To: <sip:447970000000@proxy.localphone.com >;tag=lp-2k9-5ee88476-00002a55-0005d2b3R2d70439b.b - From: "Robert" <sip:1234567@localphone.com>;tag=B3N7U1NHeem0F - Call-ID: 45818239-b574-1239-8a8e-5600002a6bbb - CSeq: 29244045 INVITE - Allow: PUBLISH,MESSAGE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL - Contact: <sip:94.2.2.2;did=2d6.a9862935> - Content-Type: application/sdp - Content-Length: 474 - - v=0 - o=UK1-SBC-15-1 70259913 70259914 IN IP4 0.0.0.0 - s=sip call - c=IN IP4 0.0.0.0 - t=0 0 - m=audio 0 RTP/SAVP 18 8 0 101 - a=rtpmap:18 G729/8000 - a=fmtp:18 annexb=no - a=rtpmap:8 PCMA/8000 - a=rtpmap:0 PCMU/8000 - a=rtpmap:101 telephone-event/8000 - a=fmtp:101 0-15 - a=ptime:20 - m=audio 0 RTP/AVP 18 8 0 101 - a=rtpmap:18 G729/8000 - a=fmtp:18 annexb=no - a=rtpmap:8 PCMA/8000 - a=rtpmap:0 PCMU/8000 - a=rtpmap:101 telephone-event/8000 - a=fmtp:101 0-15 - a=ptime:20 - a=nortpproxy:yes - ------------------------------------------------------------------------ - 2020-12-10 10:21:18.738771 [DEBUG] sofia.c:7084 Channel sofia/external/447970000000 entering state [proceeding][183] - 2020-12-10 10:21:18.738771 [NOTICE] sofia.c:7192 Ring-Ready sofia/external/447970000000! - 2020-12-10 10:21:18.738771 [DEBUG] switch_channel.c:3346 (sofia/external/447970000000) Callstate Change DOWN -> RINGING - 2020-12-10 10:21:18.738771 [DEBUG] sofia.c:7084 Channel sofia/external/447970000000 entering state [proceeding][183] - 2020-12-10 10:21:18.738771 [DEBUG] sofia.c:7094 Remote SDP: - v=0 - o=UK1-SBC-15-1 70259913 70259914 IN IP4 0.0.0.0 - s=sip call - c=IN IP4 0.0.0.0 - t=0 0 - m=audio 0 RTP/SAVP 18 8 0 101 - m=audio 0 RTP/AVP 18 8 0 101 - - 2020-12-10 10:21:18.738771 [WARNING] switch_core_media.c:3951 RFC2543 from March 1999 called; They want their 0.0.0.0 hold method back..... - 2020-12-10 10:21:18.738771 [NOTICE] sofia.c:7273 Hangup sofia/external/447970000000 [CS_CONSUME_MEDIA] [INCOMPATIBLE_DESTINATION] - 2020-12-10 10:21:18.738771 [DEBUG] switch_core_state_machine.c:584 (sofia/external/447970000000) Running State Change CS_HANGUP (Cur 4 Tot 65) - 2020-12-10 10:21:18.738771 [DEBUG] switch_core_state_machine.c:850 (sofia/external/447970000000) Callstate Change RINGING -> HANGUP - 2020-12-10 10:21:18.738771 [DEBUG] switch_core_state_machine.c:852 (sofia/external/447970000000) State HANGUP - 2020-12-10 10:21:18.738771 [DEBUG] mod_sofia.c:438 Channel sofia/external/447970000000 hanging up, cause: INCOMPATIBLE_DESTINATION

1 1