November 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

Shared presence not working with callcenter application of Freeswitch
by sagar malam 18 Jan '19

18 Jan '19

I am facing issue related to presence/ shared presence for agents in callcenter(mod_callcenter). Suppose we are dialling a user 1001(a)example.com and it is a shared user in two phones. Shared presence works perfectly if we directly dial extension 1001. But if same extension is configured as agent of callcenter and call is bridged to agent(extension) through callcenter, shared presence does not work. Freeswitch does not generate notify for agent state change. Is this expected behaviour ? If not then what can fix this ? Thanks in advance

3 6

Inviting both normal and webrtc users
by Allan Kristensen 27 Dec '18

27 Dec '18

Hello, I'm trying to implement calling Webrtc clients (through kamailio proxy), which needs ICE, DTLS, etc. in SDP and so we are adding "media_webrtc=true" when calling and it works fine. But once we do this, many of our other sip clients complain because they only support/accept insecure RTP (RTP/AVP). So question is, shouldn't it be possible to offer both secure and insecure RTP in the INVITE from FS? If not then, would it advisable/possible to not send SDP in the initial invite from FS (we don't need early media for inbound anyway) and then wait for the client to offer the SDP instead ? (I'm afraid the ice process might cause a little silence interval at the start of the call because of the late media setup and user would always expect media to be up when answering the call) We really want to have generic way of handling of clients if possible, to avoid client detection (as currently only kamailio has this info, doing the location services) or any special config items on sip accounts. Best regards, Allan

4 10

usernames whith special simbols cant recive calls on FS 1.8
by Miguel Jesús López Valverde 20 Dec '18

20 Dec '18

Hello again guys: I'm sending this question in case someone can tell me how to solve the following problem. We currently have a production platform working with FS 1.6 where users have historically been created in the form username~companyname like usernames and the incoming calls to these users work correctly. Also, a request on console like sofia_contact nameusername~companyname@domain returns a right result. Now I am considering the migration of these platforms to FS 1.8 and, for this, doing an assembly of initial development. Here I have been able to verify that although these users register correctly, they can issue outgoing calls and appear correctly listed in queries of type sofia status profile internal reg, but these users cant receive incoming calls, in console the information " Cannot create outgoing channel of type [error] cause: [USER_NOT_REGISTERED] " is always obtained and when I launch the query sofia_contact nameusername~companyname@domain in console, I get the result error/user_not_registered; I only have to change the value ~ for example by a dot and the incoming calls works correctly and also the query sofia_contact nameusername.companyname@domain return a right result. I guess I need to adjust the configuration of some library of FS 1.8 and recompile it to get back an identical operation to version 1.6, can someone help me in indicating which library or with what adjustment I could get this operation again? Thank you very much and best regards!! Miguel J. Lopez. --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

3 3