May 2015 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Error on SQL - data malformed
by Victor Medina 07 May '15

07 May '15

Hi guys! Im testing Master from yesterday. Im seeing this on the console freeswitch@srv-ovh-devel-in-000001> show registrations 2015-05-07 13:16:03.047907 [ERR] switch_core_db.c:108 SQL ERR [database disk image is malformed] 2015-05-07 13:16:03.047907 [ERR] switch_core_db.c:223 SQL ERR [database disk image is malformed] 2015-05-07 13:16:03.047907 [CRIT] switch_core_sqldb.c:508 Failure to connect to CORE_DB core! 2015-05-07 13:16:03.047907 [ERR] switch_console.c:256 Database Error 2015-05-07 13:16:03.047907 [ERR] switch_core_db.c:108 SQL ERR [database disk image is malformed] 2015-05-07 13:16:03.047907 [ERR] switch_core_db.c:223 SQL ERR [database disk image is malformed] -ERR Database error! 2015-05-07 13:16:03.047907 [CRIT] switch_core_sqldb.c:508 Failure to connect to CORE_DB core! freeswitch@srv-ovh-devel-in-000001> freeswitch@srv-ovh-devel-in-000001> show registrations 2015-05-07 13:16:18.047877 [ERR] switch_core_db.c:108 SQL ERR [database disk image is malformed] 2015-05-07 13:16:18.047877 [ERR] switch_core_db.c:223 SQL ERR [database disk image is malformed] 2015-05-07 13:16:18.047877 [CRIT] switch_core_sqldb.c:508 Failure to connect to CORE_DB core! 2015-05-07 13:16:18.047877 [ERR] switch_console.c:256 Database Error 2015-05-07 13:16:18.047877 [ERR] switch_core_db.c:108 SQL ERR [database disk image is malformed] 2015-05-07 13:16:18.047877 [ERR] switch_core_db.c:223 SQL ERR [database disk image is malformed] 2015-05-07 13:16:18.047877 [CRIT] switch_core_sqldb.c:508 Failure to connect to CORE_DB core! -ERR Database error! -- Víctor E. Medina M. Platform Architect / Chief Infrastructure +58424 291 4561 BB #79A8AFA2 @VMCibersys

2 2

Outbound ESL, typical load average
by royj＠yandex.ru 07 May '15

07 May '15

Hi all. Is there anyone here, who uses outbound ESL and have 200 and more total channels on FreeSWITCH instance. There is https://freeswitch.org/jira/browse/FS-7400 . Seems like FreeSWITCH is OK, at least developers did not found something abnormal with it. If somebody here, who uses similar configuration, what is your typical load average. Any comments are appreciated.

1 1

ClueCon Weekly May 6th, 2015!
by Ken Rice 06 May '15

06 May '15

New Post on freeswitch.org from Kathleen check it out at http://ift.tt/1KMlVAW ClueCon Weekly May 6th, 2015! Check out the weekly conference call to see the latest news!

1 0

DTMF INFO for outbound bridge support
by Sharath Kumar 06 May '15

06 May '15

>From https://freeswitch.org/jira/browse/FS-7532 Yossi Neimann says - "As we aren't bridging from FreeSWITCH to anything that needs SIP INFO, we don't make use of that. It's strictly used in our scenario for inbound calls. All of the outbound systems we communicate with support rfc2833." So, can I assume that "Freeswitch" DOES NOT support sending SIP INFO for dtmf on outbound legs that are bridged ? Please can someone else confirm. If this is so I believe it should be documented. And also I am not sure what is the purpose of dtmf_type in the {} bridge line. https://freeswitch.org/confluence/display/FREESWITCH/Variables Thank you! Sharath

2 2

UNENCRYPTED_SRTCP
by Chris Young 06 May '15

06 May '15

Hi all, When configuring FreeSWITCH to use SRTP, is it possible to have the UNENCRYPTED_SRTCP parameter appended to the end of the crypto suite when the RTP/SAVP profile is in use? So, far I have an entry similar to the following in the SDP: a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:o+6sFNUpD01VfzI3XXH2/0rGQJJyauPiNgBAvgVl but the gateway we are connecting to seems to require UNENCRYPTED_SRTCP to be present as well e.g. a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:o+6sFNUpD01VfzI3XXH2/0rGQJJyauPiNgBAvgVl UNENCRYPTED_SRTCP Many thanks, Chris Chris Young Software Engineer [cid:image7482a0.PNG@dc00f514.4fb88205] t: +44 118 943 9249 e: chris.young(a)enghouse.com<mailto:chris.young@enghouse.com> w: www.enghouseinteractive.co.uk<http://www.enghouseinteractive.co.uk> [cid:image6c1ba6.PNG@b8963a35.449174f5]

1 0

legB not Disconnected
by Vishal Sharma 06 May '15

06 May '15

Hi All, I am using ESL to control the call flow. My initial call flow is as following 1. INVITE---> FS 2. 180<--------| 3. 200<--------| 4. ------------>ACK 5. *************|-------------->INVITE 6. *************|<---------------180 7. BYE------->| 8. Retransmissions of BYE 9. *************|<----------------200 OK 10. 200(bye)<---| Now Leg B remains hanging... Shouldn't FS have killed it since legA is dead. On Application I get Channel Hangup on 200 bye. leg B call is generated using bridge command with hangup_on_answer = TRUE. Regards, Vishal Sharma

3 4

Polycom VVX Shared Call Appearance
by Bob McCarthy 06 May '15

06 May '15

Trying to upgrade our Polycom Phones from SoundPoint 670's to VVX 600's. We have had Shared Call appearance working for the last couple of years on the 670's. We have it mostly working on the VVX except for the on hold pick-off. The pick-off enters the dial-plan which then fails. We never needed to dial plan this for the 670's. Using the same registrations / IP addresses i.e. one for one swap out. Anyone have VVX's working with SCA ? Bob

2 2

CISCO + FreeSwitch = nobody@domain
by Luiz Fernando Softov 06 May '15

06 May '15

Hi, i'm trying to configure a CISCO 1700 IOS, 12.4 + FXO Is there my conf in CISCO ******************** voice-port 0/0 connection plar opx 1002 description 1002 ! dial-peer voice 1002 voip description INCOMING MATCHING preference 1 destination-pattern .T session protocol sipv2 session target sip-server session transport udp incoming called-number . dtmf-relay rtp-nte no vad ! sip-ua credentials username 1002 password 1415000915102F7F757967 realm 192.168.142.14 authentication username 1002 password 7 08235E4C100D0043435A58 retry invite 3 retry response 3 retry bye 3 retry cancel 3 timers trying 1000 registrar ipv4:192.168.142.14:5061 expires 3600 sip-server ipv4:192.168.142.14:5061 ! ******************** I have a profile running in 192.168.142.14:5061 And trying to use the user 1002 to make (authenticated) calls This register fine, but when i'm trying to make calls i receive this **** sofia/profile_1001/nobody(a)192.168.142.14 I there a way/conf to receive 1002@ip? like: **** sofia/profile_1001/1002(a)192.168.142.14 Or i only receive nobody, and need to create a extension/user nobody? ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------------------------------------------------------------------ freeswitch@internal> recv 1062 bytes from udp/[192.168.140.139]:64907 at 16:55:21.082728: ------------------------------------------------------------------------ INVITE sip:1002@192.168.142.14:5061 SIP/2.0 Via: SIP/2.0/UDP 192.168.140.139:5060;branch=z9hG4bK743303 From: <sip:192.168.142.14>;tag=2E582AC-1000 To: <sip:1002@192.168.142.14> Date: Fri, 01 Mar 2002 13:38:56 GMT Call-ID: 83580E71-2C5011D6-83BFF2FE-86D21958(a)192.168.140.139 Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 2203265591-743444950-2210067198-2261915992 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Max-Forwards: 70 Timestamp: 1014989936 Contact: <sip:192.168.140.139:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 278 v=0 o=CiscoSystemsSIP-GW-UserAgent 9597 428 IN IP4 192.168.140.139 s=SIP Call c=IN IP4 192.168.140.139 t=0 0 m=audio 18060 RTP/AVP 18 101 c=IN IP4 192.168.140.139 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 ------------------------------------------------------------------------ send 315 bytes to udp/[192.168.140.139]:5060 at 16:55:21.082952: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.140.139:5060;branch=z9hG4bK743303 From: <sip:192.168.142.14>;tag=2E582AC-1000 To: <sip:1002@192.168.142.14> Call-ID: 83580E71-2C5011D6-83BFF2FE-86D21958(a)192.168.140.139 CSeq: 101 INVITE Timestamp: 1014989936 0.000085 User-Agent: BrByte Agent Content-Length: 0 ------------------------------------------------------------------------ 2015-05-05 16:55:21.075398 [NOTICE] switch_channel.c:1075 New Channel sofia/profile_1001/nobody(a)192.168.142.14 [b3054ea9-60f3-e411-a31b-e840f23bc0a0] 2015-05-05 16:55:21.075398 [DEBUG] switch_core_session.c:1061 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [BREAK] 2015-05-05 16:55:21.075398 [DEBUG] switch_core_state_machine.c:472 (sofia/profile_1001/nobody(a)192.168.142.14) Running State Change CS_NEW 2015-05-05 16:55:21.075398 [DEBUG] switch_core_session.c:1061 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [BREAK] 2015-05-05 16:55:21.075398 [DEBUG] sofia.c:8848 sofia/profile_1001/nobody(a)192.168.142.14 receiving invite from 192.168.140.139:64907 version: 1.5.15b git d55c4a0 2015-04-07 23:11:34Z 64bit 2015-05-05 16:55:21.075398 [DEBUG] sofia.c:9015 IP 192.168.140.139 Rejected by acl "domains". Falling back to Digest auth. 2015-05-05 16:55:21.075398 [DEBUG] switch_core_state_machine.c:491 (sofia/profile_1001/nobody(a)192.168.142.14) State NEW send 788 bytes to udp/[192.168.140.139]:5060 at 16:55:21.084838: ------------------------------------------------------------------------ SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 192.168.140.139:5060;branch=z9hG4bK743303 From: <sip:192.168.142.14>;tag=2E582AC-1000 To: <sip:1002@192.168.142.14>;tag=gj3vFZ76pevSg Call-ID: 83580E71-2C5011D6-83BFF2FE-86D21958(a)192.168.140.139 CSeq: 101 INVITE User-Agent: BrByte Agent Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Proxy-Authenticate: Digest realm="192.168.142.14", nonce="4e0d4ea9-60f3-e411-a31b-e840f23bc0a0", algorithm=MD5, qop="auth" Content-Length: 0 ------------------------------------------------------------------------ 2015-05-05 16:55:21.075398 [DEBUG] switch_core_session.c:1061 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [BREAK] 2015-05-05 16:55:21.075398 [DEBUG] sofia.c:2065 detaching session b3054ea9-60f3-e411-a31b-e840f23bc0a0 recv 380 bytes from udp/[192.168.140.139]:64907 at 16:55:21.110969: ------------------------------------------------------------------------ ACK sip:1002@192.168.142.14:5061 SIP/2.0 Via: SIP/2.0/UDP 192.168.140.139:5060;branch=z9hG4bK743303 From: <sip:192.168.142.14>;tag=2E582AC-1000 To: <sip:1002@192.168.142.14>;tag=gj3vFZ76pevSg Date: Fri, 01 Mar 2002 13:38:56 GMT Call-ID: 83580E71-2C5011D6-83BFF2FE-86D21958(a)192.168.140.139 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: telephone-event Content-Length: 0 ------------------------------------------------------------------------ recv 1310 bytes from udp/[192.168.140.139]:64907 at 16:55:21.113190: ------------------------------------------------------------------------ INVITE sip:1002@192.168.142.14:5061 SIP/2.0 Via: SIP/2.0/UDP 192.168.140.139:5060;branch=z9hG4bK74418FA From: <sip:192.168.142.14>;tag=2E582AC-1000 To: <sip:1002@192.168.142.14> Date: Fri, 01 Mar 2002 13:38:56 GMT Call-ID: 83580E71-2C5011D6-83BFF2FE-86D21958(a)192.168.140.139 Supported: 100rel,timer,resource-priority,replaces Min-SE: 1800 Cisco-Guid: 2203265591-743444950-2210067198-2261915992 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 102 INVITE Max-Forwards: 70 Timestamp: 1014989936 Contact: <sip:192.168.140.139:5060> Expires: 180 Allow-Events: telephone-event Proxy-Authorization: Digest username="1002",realm="192.168.142.14",uri="sip:1002@192.168.142.14:5061",response="7d6773297fbfb70d44136a2232d62ec5",nonce="4e0d4ea9-60f3-e411-a31b-e840f23bc0a0",cnonce="66998CBE",qop="auth",algorithm=MD5,nc=00000001 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 278 v=0 o=CiscoSystemsSIP-GW-UserAgent 9597 428 IN IP4 192.168.140.139 s=SIP Call c=IN IP4 192.168.140.139 t=0 0 m=audio 18060 RTP/AVP 18 101 c=IN IP4 192.168.140.139 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 ------------------------------------------------------------------------ send 316 bytes to udp/[192.168.140.139]:5060 at 16:55:21.113382: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.140.139:5060;branch=z9hG4bK74418FA From: <sip:192.168.142.14>;tag=2E582AC-1000 To: <sip:1002@192.168.142.14> Call-ID: 83580E71-2C5011D6-83BFF2FE-86D21958(a)192.168.140.139 CSeq: 102 INVITE Timestamp: 1014989936 0.000070 User-Agent: BrByte Agent Content-Length: 0 ------------------------------------------------------------------------ 2015-05-05 16:55:21.106397 [DEBUG] sofia.c:2173 Re-attaching to session b3054ea9-60f3-e411-a31b-e840f23bc0a0 2015-05-05 16:55:21.106397 [DEBUG] switch_core_session.c:1061 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [BREAK] 2015-05-05 16:55:21.106397 [DEBUG] switch_core_session.c:1061 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [BREAK] 2015-05-05 16:55:21.126156 [DEBUG] sofia.c:8848 sofia/profile_1001/nobody(a)192.168.142.14 receiving invite from 192.168.140.139:64907 version: 1.5.15b git d55c4a0 2015-04-07 23:11:34Z 64bit 2015-05-05 16:55:21.126156 [DEBUG] sofia.c:9015 IP 192.168.140.139 Rejected by acl "domains". Falling back to Digest auth. 2015-05-05 16:55:21.126156 [DEBUG] sofia.c:6627 Channel sofia/profile_1001/nobody(a)192.168.142.14 entering state [received][100] 2015-05-05 16:55:21.126156 [DEBUG] sofia.c:6637 Remote SDP: v=0 o=CiscoSystemsSIP-GW-UserAgent 9597 428 IN IP4 192.168.140.139 s=SIP Call c=IN IP4 192.168.140.139 t=0 0 m=audio 18060 RTP/AVP 18 101 c=IN IP4 192.168.140.139 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3221 Activate Buggy RFC2833 Mode! 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3666 Audio Codec Compare [G729:18:8000:20:8000:1]/[PCMU:0:8000:20:64000:1] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3666 Audio Codec Compare [G729:18:8000:20:8000:1]/[PCMA:8:8000:20:64000:1] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3666 Audio Codec Compare [G729:18:8000:20:8000:1]/[GSM:3:8000:20:13200:1] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3666 Audio Codec Compare [G729:18:8000:20:8000:1]/[G722:9:8000:20:64000:1] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3666 Audio Codec Compare [G729:18:8000:20:8000:1]/[opus:116:48000:20:0:1] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3582 Set telephone-event payload to 101 2015-05-05 16:55:21.126156 [DEBUG] switch_core_media.c:3929 Set 2833 dtmf send/recv payload to 101 2015-05-05 16:55:21.126156 [NOTICE] sofia.c:6981 Hangup sofia/profile_1001/nobody(a)192.168.142.14 [CS_NEW] [INCOMPATIBLE_DESTINATION] 2015-05-05 16:55:21.126156 [DEBUG] switch_channel.c:3242 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [KILL] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_session.c:1396 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [BREAK] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:472 (sofia/profile_1001/nobody(a)192.168.142.14) Running State Change CS_HANGUP 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:735 (sofia/profile_1001/nobody(a)192.168.142.14) Callstate Change DOWN -> HANGUP 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:737 (sofia/profile_1001/nobody(a)192.168.142.14) State HANGUP 2015-05-05 16:55:21.126156 [DEBUG] mod_sofia.c:413 Channel sofia/profile_1001/nobody(a)192.168.142.14 hanging up, cause: INCOMPATIBLE_DESTINATION 2015-05-05 16:55:21.126156 [DEBUG] mod_sofia.c:549 Responding to INVITE with: 488 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:60 sofia/profile_1001/nobody(a)192.168.142.14 Standard HANGUP, cause: INCOMPATIBLE_DESTINATION 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:737 (sofia/profile_1001/nobody(a)192.168.142.14) State HANGUP going to sleep 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:504 (sofia/profile_1001/nobody(a)192.168.142.14) State Change CS_HANGUP -> CS_REPORTING 2015-05-05 16:55:21.126156 [DEBUG] switch_core_session.c:1396 Send signal sofia/profile_1001/nobody(a)192.168.142.14 [BREAK] 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:472 (sofia/profile_1001/nobody(a)192.168.142.14) Running State Change CS_REPORTING send 816 bytes to udp/[192.168.140.139]:5060 at 16:55:21.132211: ------------------------------------------------------------------------ SIP/2.0 488 Not Acceptable Here Via: SIP/2.0/UDP 192.168.140.139:5060;branch=z9hG4bK74418FA Max-Forwards: 70 From: <sip:192.168.142.14>;tag=2E582AC-1000 To: <sip:1002@192.168.142.14>;tag=HUvNHtramQjcc Call-ID: 83580E71-2C5011D6-83BFF2FE-86D21958(a)192.168.140.139 CSeq: 102 INVITE User-Agent: BrByte Agent Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Reason: Q.850;cause=88;text="INCOMPATIBLE_DESTINATION" Content-Length: 0 2015-05-05 16:55:21.126156 [DEBUG] switch_core_state_machine.c:823 (sofia/profile_1001/nobody(a)192.168.142.14) State REPORTING Remote-Party-ID: "1002" <sip:1002@192.168.142.14>;party=calling;privacy=off;screen=no ------------------------------------------------------------------------ -- Luiz Fernando Softov http://www.softov.com.br fernando(a)softov.com.br

2 1

DTMF relay with INFO across bridge
by Sharath Kumar 05 May '15

05 May '15

Hi, I looked around in the mailing list and don't see any conclusive solution to this problem. I have a setup like this below. Webrtc client -----FS----sonus gateway. The Webrtc client is sending INFO as DTMF. The FS currently bridges the call to the gateway and in the outbound leg uses rfc2833. Problem: Some calls suffer from missing DTMF and repeated duplicate DTMF. Solution: Use INFO all through to sonus gateway ? How do I achieve this ? In the internal profile if I change the "dtmf-type" to "info". Nothing really happens, it still sends rfc2833 dtmf. I believe it is because of "liberal-dtmf" is "true".[accept any but always offer rfc2833] But if I change "liberal-dtmf" to "false". I get "channel is not configured to use info dtmf". Is this a bug ? Is there any way around it ? Any input much appreciated. Thank you, Sharath

2 7

Simulate incoming SIP Message
by Kurtis Heimerl 05 May '15

05 May '15

Hello FreeSWITCH Users, I am trying to simulate an incoming SIP message in order to test my chatplan programmatically. Basically, I want FS to send itself a SIP message, which will then be routed through the chatplan. I've been able to generate the message using ESL and events, however FS refuses to send it noting that it is "Not sending message to ourselves!" That's exactly what I want it to do. I've used this functionality before for calls, as generating a call that connects back to FS (and hooking it to echo) is a great way to test the dialplan. Is there no way to get FS to send itself a message? Thanks!

3 2