September 2015 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Streaming local ogg vorbis file
by Jason Moran 16 Sep '15

16 Sep '15

What simple thing am I missing to play a local .ogg? When I use streamfile I get the error: "Invalid file format [ogg] for [/usr/local/freeswitch/recordings/temp/t1.ogg]!" Meanwhile, as for shout it only allows URL (reads via curl)

3 2

OPUS codec and optimal settings for "bad" 3G reception.
by Michael Nielsen 16 Sep '15

16 Sep '15

Hi, I'm looking into a good codec for a client when bad 3G coverage is present. OPUS seems as a good choice. Can anyone recommend settings for this on the FS server side, or should it be done in the client?

3 2

help needed for adding freeswitch.py to the freeswitch-mod-python debian package
by Raphael Lechner 16 Sep '15

16 Sep '15

Hi, I’m trying to create a patch for integrating the freeswitch.py to the freeswitch-mod-python package because the file is missing and there is a ticket (https://freeswitch.org/jira/browse/FS-5660 <https://freeswitch.org/jira/browse/FS-5660>) that asks for a patch. I tried adding a file /usr/src/freeswitch/src/debian/freeswitch-mod-python.install with: usr/lib/python*/*-packages/freeswitch.py But probably I missed something, because the debian package don’t contains the freeswitch.py Can someone give me a hint, what files I need to look to understand what I need to change? Thanks! Raphael

1 0

May be bug in mod_callcenter
by Kamil Nigmatullin 16 Sep '15

16 Sep '15

Hello again. Have a question. Maybe a bug though... If I set contact for agent like this [call_timeout=20]sofia/gateway/supernode1/bnFuW4kqoKfL, call_timeout doesn't work. Is it something that I do illigal or should I report to Jira? Thanks -- Kamil Nigmatullin Tel: 77272323748 mob: 7 (707) 2517003 Skype: kamil.nigmatullin

3 6

Is the current FreeSWITCH release 1.4.21 or 1.6.0?
by Andrew Keil 16 Sep '15

16 Sep '15

To FreeSWITCH users, I just need clarification as to which is the current FreeSWITCH release: 1.4.21 or 1.6.0? Currently my client is not yet in production and is running FreeSWITCH 1.4.20 on CentOS 6.7. I know FreeSWITCH 1.6.0 requires CentOS 7.0 as a minimum, however if 1.6.0 is now the current release then now is the best time for me to move my client to this release. Please let me know which version is the current release version we should be using. Regards, Andrew Keil

2 1

RFC 1918 (private) IPs not accepted in SDP?
by Thomas 15 Sep '15

15 Sep '15

Hello list, testing some things on a LAN, I noticed Chrome and FS having problems establishing a direct LAN connection. Without any ICE servers and the SDP being limited to the host address, FS rejects what looks like a perfectly fine SDP with a codec negotiation error. When TURN servers are available, Chrome already puts a TURN server's IP into the c= line. Other than that, there are just additional relay ice candidates. FS will choose the TURN server in the c= line first, but later "auto change" to the LAN address. I could not find any other differences between the two SDPs. I've added some delay and checked listening ports to make sure this isn't a timing issue on Chrome's end: It does listen on the ports it announced ... Is there a configuration option, which could cause this? I can't quite believe this being a bug, because a lot of people should have noticed ... Thanks, Thomas P.S.: Log snippet of rejected call: 2015-09-14 16:12:54.962238 [DEBUG] switch_core_media.c:3260 Save audio Candidate cid: 1 proto: udp type: host addr: 192.168.1.113:50602 2015-09-14 16:12:54.962238 [DEBUG] switch_core_media.c:3260 Save audio Candidate cid: 2 proto: udp type: host addr: 192.168.1.113:50603 2015-09-14 16:12:54.962238 [DEBUG] switch_core_media.c:3300 Searching for rtp candidate. 2015-09-14 16:12:54.962238 [DEBUG] switch_core_media.c:3300 Searching for rtcp candidate. 2015-09-14 16:12:54.962238 [DEBUG] switch_core_media.c:3344 sofia/internal/tauge(a)sip.abc.com no suitable candidates found. 2015-09-14 16:12:54.962238 [DEBUG] switch_core_media.c:4427 Set 2833 dtmf send/recv payload to 126 2015-09-14 16:12:54.962238 [ERR] mod_sofia.c:2284 CODEC NEGOTIATION ERROR. SDP: Broken SDP: v=0 o=ABC-WEB-2.0 6876809645794559979 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS ec8f8f88-2e4f-4cbc-9c38-f51d6e6850d8 m=audio 64149 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 126 c=IN IP4 192.168.1.113 a=rtcp:64150 IN IP4 192.168.1.113 a=candidate:2624638470 1 udp 2122260223 192.168.1.113 64149 typ host generation 0 a=candidate:2624638470 2 udp 2122260222 192.168.1.113 64150 typ host generation 0 a=candidate:3539153654 1 tcp 1518280447 192.168.1.113 0 typ host tcptype active generation 0 a=candidate:3539153654 2 tcp 1518280446 192.168.1.113 0 typ host tcptype active generation 0 a=ice-ufrag:BOWdiCKMBJ5j5dcx a=ice-pwd:zn1o5HVNk8ZjbFUlouk2bT3O a=fingerprint:sha-256 9C:A5:CB:27:A8:B1:3D:4D:41:1A:F5:2A:B7:60:B9:06:6B:A3:A4:8F:5A:F6:AD:1D:50:28:E5:AE:28:70:28:AD a=setup:actpass a=mid:audio b=AS:96 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=sendrecv a=rtcp-mux a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; usedtx=0; maxplaybackrate=48000; sprop-maxcapturerate=48000; maxaveragebitrate=64000; sprop-stereo=0; stereo=0 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:1980631361 cname:3nFhXh/3h3cqLn4p a=ssrc:1980631361 msid:ec8f8f88-2e4f-4cbc-9c38-f51d6e6850d8 f63ca3d0-1e11-43ec-8bba-e3cf9beb55c2 a=ssrc:1980631361 mslabel:ec8f8f88-2e4f-4cbc-9c38-f51d6e6850d8 a=ssrc:1980631361 label:f63ca3d0-1e11-43ec-8bba-e3cf9beb55c2 Working SDP: v=0 o=ABC-WEB-2.0 8443069933158526980 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS 5aa672c6-f6ac-49ee-a7fa-758e85f1d569 m=audio 54843 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 126 c=IN IP4 184.173.227.184 a=rtcp:50649 IN IP4 184.173.227.184 a=candidate:2624638470 1 udp 2122260223 192.168.1.113 57019 typ host generation 0 a=candidate:2624638470 2 udp 2122260222 192.168.1.113 57020 typ host generation 0 a=candidate:3539153654 1 tcp 1518280447 192.168.1.113 0 typ host tcptype active generation 0 a=candidate:3539153654 2 tcp 1518280446 192.168.1.113 0 typ host tcptype active generation 0 a=candidate:2388703359 1 udp 25108223 184.173.227.184 54843 typ relay raddr 200.86.231.43 rport 2480 generation 0 a=candidate:2388703359 2 udp 25108222 184.173.227.184 50649 typ relay raddr 200.86.231.43 rport 2483 generation 0 a=candidate:296579010 1 udp 25108223 46.37.165.198 51332 typ relay raddr 200.86.231.43 rport 2486 generation 0 a=candidate:296579010 2 udp 25108222 46.37.165.198 61376 typ relay raddr 200.86.231.43 rport 2489 generation 0 a=candidate:296579010 1 udp 8331007 46.37.165.198 63945 typ relay raddr 200.86.231.43 rport 2485 generation 0 a=candidate:296579010 1 udp 8331007 46.37.165.198 64219 typ relay raddr 200.86.231.43 rport 2484 generation 0 a=candidate:296579010 2 udp 8331006 46.37.165.198 52149 typ relay raddr 200.86.231.43 rport 2488 generation 0 a=candidate:296579010 2 udp 8331006 46.37.165.198 61407 typ relay raddr 200.86.231.43 rport 2487 generation 0 a=ice-ufrag:6aKotQHXO+YIa4SB a=ice-pwd:x26eZydsmKS3CujQnJt+yagB a=fingerprint:sha-256 9C:A5:CB:27:A8:B1:3D:4D:41:1A:F5:2A:B7:60:B9:06:6B:A3:A4:8F:5A:F6:AD:1D:50:28:E5:AE:28:70:28:AD a=setup:actpass a=mid:audio b=AS:96 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=sendrecv a=rtcp-mux a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1; usedtx=0; maxplaybackrate=48000; sprop-maxcapturerate=48000; maxaveragebitrate=64000; sprop-stereo=0; stereo=0 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:3496827522 cname:useDs2Io3ldUsLU6 a=ssrc:3496827522 msid:5aa672c6-f6ac-49ee-a7fa-758e85f1d569 687fb926-afe8-433f-8b82-793d1e6f2f2a a=ssrc:3496827522 mslabel:5aa672c6-f6ac-49ee-a7fa-758e85f1d569 a=ssrc:3496827522 label:687fb926-afe8-433f-8b82-793d1e6f2f2a

3 4

TLS and 5061 doesn't seem to work
by Michael Nielsen 15 Sep '15

15 Sep '15

I'm running this clean installation of FS: https://github.com/voxserv/freeswitch_conf_minimal Everything seems to work and I would now like to add TLS and SRTP encryption - for use on public WiFi and such. I've tried the following from this http://wiki.freeswitch.org/wiki/SIP_TLS#TLS.2C_SSL_and_SRTP_Encryption: ./gentls_cert setup -cn pbx.freeswitch.org -alt DNS:pbx.freeswitch.org -org freeswitch.org ./gentls_cert create_server -cn pbx.freeswitch.org -alt DNS:pbx.freeswitch.org -org freeswitch.org And in vars.xml: <X-PRE-PROCESS cmd="set" data="sip_tls_version=sslv23"/> <X-PRE-PROCESS cmd="set" data="internal_ssl_enable=true"/> Of course with my own domain when generating certificates. Restarting FS and trying to connect to 5061 over TLS doesn't work. Looking in fs_cli with debug 7 doesn't output anything when the client tries to connect. How to debug or does anyone know what's wrong? My certificates are generated automatically in /usr/conf/ssl.

4 9

Lua dialplan extracting variables inline
by Jonathan Hunter 15 Sep '15

15 Sep '15

Hi Guys, Sorry for the post here but I just wanted to check if this was possible. I am using one large .lua script, and Im setting up channel variables before the call is connected, so for example I am setting in line; table.insert(xml, [[<action application="set" data="closedop=voicemail" inline="true"/>]]);table.insert(xml, [[<action application="set" data="closedopact=2000" inline="true"/>]]); This then terminates on a dialplan, where I would like to use the value of closedop and closedopact as an anti-action; <anti-action application="]]..closedop..[[" data="default ]]..h.Customer_Domain..[[ ]]..closedopact..[["/> I can see in the logs the value is set; Action set(closedop=voicemail) INLINEEXECUTE sofia/internal/07917190439(a)62.239.9.74 set(closedop=voicemail)2015-09-14 20:41:47.828526 [DEBUG] mod_dptools.c:1435 sofia/internal/07917190438(a)62.239.9.74 SET [closedop]=[voicemail]Dialplan: sofia/internal/07917190439(a)62.239.9.74 Action set(closedopact=2000) INLINEEXECUTE sofia/internal/07917190439(a)62.239.9.74 set(closedopact=2000)2015-09-14 20:41:47.828526 [DEBUG] mod_dptools.c:1435 sofia/internal/07917190438(a)62.239.9.74 SET [closedopact]=[2000] So I want to set the application to voicemail, and the extension to 2000. How can I extract this? I have tried using ${closedop}, and session:getvariables, however this is only suitable when session established I believe? Plus I'm doing this inline, so setting variables, then wanting to get them again before answer. Can anyone advise? Thanks J

1 0

Dialplan question....
by Igor Olhovskiy 15 Sep '15

15 Sep '15

Hi! I have a really strange dialplan problem or total misunderstanding of FreeSwitch dialplans.... I've created file test_cases.xml in dialplan directory with content: <include> <context name="test_cases"> <extension name="testing"> <condition field="destination_number" expression="^3335$"> <action application="info"/> </condition> </extension> </context> </include> Than, after reloadxml. verify, that I have in log/freeswitch.xml.fsxml section with it (section="dialplan" and other....) In fs_cli I've firing a commnand originate loopback/3555/test_cases/XML user/101 But can't get to 3555 extension in dialplan. Got in log ..... 2015-09-14 18:16:31.000258 [INFO] mod_dialplan_xml.c:635 Processing <0000000000>->3555 in context test_cases 2015-09-14 18:16:31.000258 [INFO] switch_core_state_machine.c:241 No Route, Aborting 2015-09-14 18:16:31.000258 [NOTICE] switch_core_state_machine.c:242 Hangup loopback/3555-b [CS_ROUTING] [NO_ROUTE_DESTINATION] ..... But why? I have a context test_cases and corresponding extension with condition field..... Looks like dumb question, but I'm desperate... -- Best regards, Igor

7 11

Multiple "gateways" outbound registration and socket reuse
by David Villasmil 15 Sep '15

15 Sep '15

hello list, I need yo register 500+ accounts via TCP transport on a remote server from FS. I configured the 500 accounts a gateways. I need each account to use its own tcp socket. I know this is done via "reuse_connection" or something similar on sofia config. I did this and its done properly. Mu issue comes when FS is refreshing (re-registering) on the remote server. Because fs is configure to NOT reuse the connection, it closes the previous and makes a brand new connection. Is it possible for FS to continue using the same socket, instead of closing it and create a new one? On the othet hand, i think FS is missing some incoming packets. Aftet about 190 accounts, it seems FS doesn't receives all the incoming packets and the regustration fails, although on the temote side we see the registration process complete. I will investigate this latter issue more in-depth. Any help with the socket question? Thanks! David Villasmil

1 1