September 2018 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Stumped by mod_portaudio permissions issue
by Mark Haun 02 Feb '20

02 Feb '20

I built freeswitch version 1.7.0+git~20150730T192909Z~ab7f83c654~32bit for my ARM-based home server (an NVIDIA Jetson board), with the intention of using mod_portaudio with a wireless USB headset for my main home phone. It works well when running freeswitch directly as root, but when I configured freeswitch to run at system startup, mod_portaudio could no longer find any audio devices. No problem, I thought, it's a simple permissions issue. I am using the example debian init script from the wiki (this is a Jessie install with SysV init rather than systemd). It runs freeswitch as user freeswitch, group daemon using the -u and -g command-line options. So I added "freeswitch" to the audio group, then used sudo to verify that I could play sound files with "aplay" as the freeswitch user. That worked, but it did not solve the mod_portaudio failure. Thinking there must be an issue with portaudio separate from ALSA, I fetched and built the "pa_devs" utility which enumerates and prints the available audio devices. (This is basically what mod_portaudio is doing on startup.) Running as the freeswitch user, that worked too. Hmmmm. I tried running freeswitch from the command line using sudo rather than the -u and -g options, i.e. $ sudo freeswitch /usr/local/freeswitch/bin/freeswitch -nc and that worked as well! Then I started experimenting with -u and -g and discovered that $ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch allows mod_portaudio to load correctly, whereas $ /usr/local/freeswitch/bin/freeswitch -nc -u freeswitch -g daemon causes mod_portaudio to fail. Can anyone explain what's happening here? In both cases the process UID, GID, EUID, EGID, FUID, and FGID are the same (freeswitch:daemon) as displayed with "ps xao pid,uid,gid,euid,egid,fuid,fgid". Could this be a bug in freeswitch? There are a couple of threads from 2-3 years ago in the archives, where mod_portaudio permissions issues were never resolved and the solution remained a mystery. For the time being I guess this (not using -g) is a workaround, but I'd sure like to understand what is going on. Mark

5 7

ICE/DTLS handshake
by Mirko Brankovic 25 Oct '19

25 Oct '19

HI, Has anyone experienced DTLS handshake takes 5s to get to SETUP state: > 2017-09-21 11:40:40.021178 [INFO] switch_rtp.c:3515 Changing audio DTLS > state from OFF to HANDSHAKE > 2017-09-21 11:40:45.319457 [INFO] switch_rtp.c:3172 Changing audio DTLS > state from HANDSHAKE to SETUP In network dump i see that answering side is not sending STUN for this 5s and then suddenly answers last 5 STUNs from A side. Has anyone encountered this kind of problem ? I have a pcap if necessary... Thanks, -- Regards, Mirko

3 7

Change SIP Contact header on b-leg
by Кирилл Преслер 22 Feb '19

22 Feb '19

Provider not accepting calls because of "bad" Contact header sip:gw+ss@10.50.244.15:5060;transport=udp;gw=ss ITSP needs sip:username@10.50.244.15:5060, where username should be passed from dialplan for every call and there is no params. I've tried following variables with set and export, but nothing seems to work. sip_contact_user sip_outgoing_contact_uri sip_invite_contact_params

3 2

Re: [Freeswitch-users] INCOMPATIBLE_DESTINATION
by Paul Muaddib 13 Feb '19

13 Feb '19

vars.xml <X-PRE-PROCESS cmd="set" data="global_codec_prefs=PCMA,PCMU"/> <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMA,PCMU"/> My phones, all Grandstream GXP2140, accept PCMA and PCMU I don't have trouble with other people calling me Am Mi., 22. Aug. 2018 um 15:21 Uhr schrieb Thorsten Göllner < tg-maillistings(a)level5.de>: > Only PCMA@8000 is offered. Check device if codec is activated. > > Am 21.08.2018 um 15:06 schrieb Paul Muaddib: > > Hi, > > I have a rarely error where I get this failure message in the log file. I > am bit wondering because this is suposed to be a normal voice call and not > a fax. > > Best regards, > Paul. > > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 2018-08-20 14:04:54.056776 [INFO] > switch_ivr_originate.c:1215 Sending early media > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 2018-08-20 14:04:54.056776 [ERR] > mod_sofia.c:2343 CODEC NEGOTIATION ERROR. SDP: > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 v=0^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 o=- 20012711 20012711 IN IP4 > 217.0.15.67^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 s=on transit^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 c=IN IP4 X.X.X.X^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 t=0 0^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 m=audio 13274 RTP/AVP 8 118 126 101^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=rtpmap:8 PCMA/8000^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=rtpmap:118 PCMA/8000^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=rtpmap:126 CLEARMODE/8000^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=rtpmap:101 telephone-event/8000^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=fmtp:101 0-15^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=gpmd:118 vbd=yes^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=ptime:20^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 m=image 11232 udptl t38^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=T38FaxVersion:0^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=T38MaxBitRate:14400^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=T38FaxMaxBuffer:3000^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=T38FaxMaxDatagram:500^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 > a=T38FaxRateManagement:transferredTCF^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 a=T38FaxUdpEC:t38UDPRedundancy^M > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 > fe3eed7c-e03a-40af-bc2e-ae0bfe54bb28 2018-08-20 14:04:54.056776 [NOTICE] > switch_channel.c:3515 Hangup sofia/external/+ > 49XXXXXXXXX(a)sip-trunk.telekom.de [CS_EXECUTE] [INCOMPATIBLE_DESTINATION] > > > _________________________________________________________________________ > Professional FreeSWITCH Servicessales@freeswitch.comhttps://freeswitch.com > > Official FreeSWITCH Siteshttps://freeswitch.com/osshttps://freeswitch.org/confluencehttps://clu… > > FreeSWITCH-users mailing listFreeSWITCH-users@lists.freeswitch.orghttp://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-usershtt… > > >

6 9

DTMF negotiation
by kaiduan xie 04 Feb '19

04 Feb '19

Hi, We are encountering the following DTMF issue, FreeSwitch adds telephone-event support in INVITE to SBC, SBC replies back without telephone-event support in 200. However FreeSwitch still sends out DTMF in RFC 2833 event. I think FreeSwitch should send out DTMF inband instead of 2833 event, what is the configuration for this? Many thanks for help, /Kaiduan

2 4

Sofia stops responding after a few days
by Bipin Patel 01 Feb '19

01 Feb '19

hi, I have 2 instances of FS running on a single windows box, first instance uses normal sip UDP profiles mainly used for routing calls to carriers and its running as a service since a few months without any issues. The second instance runs a sip TLS profile and accepts inbound registrations and forwards calls in sip UDP ahead, it uses xml_curl for directory users but the problem is every 2-3 days the inbound TLS profile stops responding to registrations, and when that happens i cant even stop and restart the service, have to kill it and start again. FS_CLI works but doesnt show any error, at first i though it could be the xml_curl causing the issue but later realized it never sends any requests when sofia stops responding. i have been banging my head from the past week or so but not able to find the cause, could any1 help in guiding me what to check when this happens so can find the root cause, im using commercial certs for TLS and when its running there r no issues other than sofia stops responding every few days, it happens at random times. -- Regards, Bipin ------------------------------------------------------------------------

4 9

zRTP + OPUS one-way audio issue
by Andrea Mazzeo 30 Jan '19

30 Jan '19

Hi, I'm facing an one-way audio issue with zRTP while using OPUS. zRTP is set in passthru mode. Called party can hear Calling party but not vice versa. Full log: https://pastebin.freeswitch.org/view/639adfe9 This issue is happening *only* with dynamic payloads codecs. Everything is working fine if I use G722 or G729. Scenario Leg-A (207) -> FS -> Leg-B (213) Checking FS logs, I see Leg-A's SDP: a=rtpmap:103 opus/48000/2 Leg-B's SDP: a=rtpmap:102 opus/48000/2 Actually having different payloads should not be an issue. I opened a case to Acrobits, they said the issue is in the actual RTP traffic sent to Leg-A from FS: >From the client log Leg-A Sending RTP packet #200 192.168.128.158:59176 > 31.102.111.134:28560, len=116, really=116, data=80679E55DF67E34A291167D899830CC03C124F353DA3C069574410EC0333125F This is using 103, correct as agreed on this side of the call Received RTP packet #200 31.102.111.134:28560 > 192.168.128.158:59176, len=90, data=80663D3B22CC8CB414490864A230F49B6EFF42E7BCA9EB64B864374B1377965C This is using 102, which is wrong for this side of the call. Seems that after negotiated payload 102 with Leg-B, FS is trying to use it on Leg-A, where it should be used 102 instead. Any idea? FreeSWITCH Version 1.8.1-2-4f54cff~64bit (-2-4f54cff 64bit) OS.: Debian 8.11 Linux pbx-186 3.16.0-4-amd64 #1 SMP Debian 3.16.51-3 (2017-12-13) x86_64 GNU/Linux Thank you, Andrea Mazzeo

1 2

Audio delayed for about 3sec.
by 王聡 20 Dec '18

20 Dec '18

Hey all, Today I moved my freeswitch server from VM to cloud server, but I found there has an audio delay on both caller and receiver for about 3sec in each call during call test. Is there any idea for this audio delay? Regards.

7 13

Re: [Freeswitch-users] Multiple Diversion headers
by Sjoerd Boomstra 09 Nov '18

09 Nov '18

Hi, Yes I’m interested in your patch; I’d like to be able to send multiple headers (Diversion in my case). For receiving there’s already a solution with the param parse-all-invite-headers=true. Best regards, Sjoerd. Van: Vallimamod Abdullah - SIP Solutions [mailto:vma@sip.solutions] Verzonden: woensdag 22 augustus 2018 19:02 Aan: Sjoerd Boomstra Onderwerp: Re: [Freeswitch-users] Multiple Diversion headers Hi, I have faced the same issue when passing certification tests with Orange-FR. There is a bug in freeswitch that makes it impossible to manage multiple headers with same name, either receiving or sending; the last value overwrites all the previous ones. I wrote a patch to correct it. I didn't get the chance to publish it yet, but if you are interested I can share it with you. Btw, I provide freeswitch consulting services for carriers. If you have any need, feel free to ping me. Best Regards, -- Vallimamod Abdullah SIP Solutions vma(a)sip.solutions<mailto:vma@sip.solutions> +33 6 62 60 68 97 linkedin.com/in/vallimamod<http://linkedin.com/in/vallimamod> . On 22 Aug 2018, at 16:10, Sjoerd Boomstra <S.Boomstra(a)telecats.nl<mailto:S.Boomstra@telecats.nl>> wrote: Hi All, I’m struggling with multiple Diversion headers. In our case we have an incoming call with multiple diversion headers, we do some processing and want to add a diversion header ourselves to the outgoing call. What I’ve found so far is that for inbound calls one needs to set the profile param parse-all-invite-headers=true, this results in a sip_i_Diversion variable that uses the ARRAY:: syntax and has all the values I want. So far so good. Example: ARRAY::<sip:Carol@uas2.isp.com>;privacy=off;reason=unconditional;counter=2;screen=no|:<sip:Bert@uas2.isp.com>;privacy="full";reason=user-busy;counter=3;screen=no|:<sip:Bob@uas1.isp.com>;reason=do-not-disturb;counter=1 For the outbound call it’s more difficult, I cannot get FreeSwitch to produce multiple Diversion headers. The only syntax I’ve found is using comma’s in the value, like this: <action application="export" data="sip_h_Diversion=<sip:Carol@uas2.isp.com>;privacy=off;reason=unconditional;counter=2;screen=no,<sip:Bert@uas2.isp.com>;privacy="full";reason=user-busy;counter=3;screen=no,<sip:Bob@uas1.isp.com>;reason=do-not-disturb;counter=1,<sip:Bert@uas2.isp.com>;reason=user-busy"/> This results in a single diversion header with the contents I put in. From the RFC’s I understand that this is technically equivalent to 4 (in my case) Diversion headers, is this true? Is there a way I can convince FS to generate multiple separate diversion headers? Best regards, Sjoerd. BTW I’ve tested with FS 1.6.20 and 1.4.26

2 1

Re: [Freeswitch-users] h264 video call between endpoints with one end at bad resolution of 352x288
by Michael Jerris 23 Oct '18

23 Oct '18

sounds like you might be doing the option to mirror resolution > On Jun 28, 2018, at 9:07 AM, antonio via FreeSWITCH-users <freeswitch-users(a)lists.freeswitch.org> wrote: > > > From: antonio <asilva(a)wirelessmundi.com> > Subject: h264 video call between endpoints with one end at bad resolution of 352x288 > Date: June 26, 2018 at 6:05:20 AM EDT > To: freeswitch-users(a)lists.freeswitch.org > > > Hi, > > Calling between two Grandstream GXV3275 i expected to have a video call at 1280x720, but the video that is present at destination as the resolution of 352x288 and the image as poor quality, originator is sending video at 1280×720. If i swap the devices the result is the same, the destination always get a bad resolution of 352x288 but the originator receives the video at expected resolution of 1280x720. > > If i set rtp_direct between the two endpoints it work as expected. > > I also tested a conference room and force the it resolution to 1280*x720 it work well, if i don't force the canvas-size i see: > > 2018-06-26 13:55:02.077824 [WARNING] mod_conference.c:3157 Unspecified video-canvas-size, falling back to 1280x720 > > And the conference is done at 1280x720. > > > I've open a jira where you can find a full log with this behavior: > > https://freeswitch.org/jira/browse/FS-11140 > > > I don't understand why there is transcoding and mod_av is used, the codec negotiated is the same.. i understand that the resolution is at 352x288 for the first frames sent by the phone but then it send them at 1280x720, mod_av should detected and adjust the new resolution, no? > > > Anyone experience this behavior? >

2 1