May 2012 - FreeSWITCH-users - FreeSWITCH Mailing Lists

Issues with RPM install
by Dave May 12 May '12

12 May '12

Just tried the RPM install -- great work at reducing the install time! Had some issues on CentOS 6.2 though, and wanted to post my fixes: 1. Default install doesn't include any sounds -- should probably have something basic there. 2. Sounds install via "yum install freeswitch-sounds-en-us-callie freeswitch-sounds-music" did not include sox dependency 3. Default init.d file points to incorrect freeswitch location Should be FS_FILE=${FS_FILE-/usr/bin/freeswitch} Instead of FS_FILE=${FS_FILE-/usr/freeswitch} Dave.

2 1

RTP media Issue
by Mr Nathan Downes 12 May '12

12 May '12

Hi First time trying this mailing list, I have my FS server in a data centre, which feeds site a, site b etc. over a fibre network. We are having really bad call quality issues at one of the sites. The residents report that every second or 2 there is a hiccup in the incoming voice and they miss a portion of the voice. It is consistent and affects everybody. I did some wireshark tracing of both sides of the calls (ext - fs and fs - provider) and to me it appears packets coming from my server have a wrong timestamp every second or so. The server is not over loaded and is pretty default Ubuntu 10.04 LTS, latest FS Head on there. I spent a week trying to diagnose with both the fibre provider and trunk provider but we couldn't figure out the cause. I then tried putting rtp-rewrite-timestamps in both the profiles (external one to provider, and internal one specifically for fibre company) and the problem appears to have gone away. I would like to figure out what is/was causing the issue and also find out if that option puts any extra overhead on the server. If there is almost no overhead I would probably leave it on and just assume I need I for this specific connection. I don't have the issue at another site over same fibre network and trunk provider, and people connecting direct over internet don't suffer same problem. I have about 2gb of wireshark traces I can put online if required. Thanks, Nathan

2 1

Freeswitch hardware cofig
by tarik.bts.gi＠gmail.com 11 May '12

11 May '12

What is the good hardware configuration that needs freeswitch to support more then 30 calls? We have now 1.6 GHz in the CPU and 2 GB in the mem but is not enough.

6 5

mod_xml_cdr is not logging
by Adrian Andrei 11 May '12

11 May '12

Hello I tried to set up mod_xml_cdr but it doesn't work at all. I made the following steps: - Uncomment mod_xml_cdr in modules.conf. - Ok - Edit conf/autoload_configs/modules.conf.xml. - OK - Load mod_xml_cdr from CLI - NO errors - My *xml_cdr.conf.xml* looks like: <configuration name="xml_cdr.conf" description="XML CDR CURL logger"> <settings> <param name="url" value="http://localhost/xml-cdr/cdr.php"/> <param name="retries" value="2"/> <param name="delay" value="120"/> <param name="log-http-and-disk" value="true"/> <param name="log-dir" value="/usr/local/freeswitch/log/cdr"/> <param name="err-log-dir" value="/usr/local/freeswitch/log/cdr/errors"/> </settings> </configuration> (The php files are from contrib/trixter/xml-cdr.) In some posts I read that if log-dir and err-log-dir are changed from "default" I should set also the log-http-and-disk. But it doesn't work. Wiki said that I should check the freeswitch.xml to see if it is included xml_cdr.conf.xml but I can't find any line with xml_cdr.conf.xml. The version of freeswitch is FreeSWITCH Version 1.0.head (git-2c52f23 2012-02-18 08-37-47 -0600) so I think is new enough to have this feature available. Could anyone help me to find out what I'm missing? Are any commands in FS in order to run a mod_cdr_xml debug? Ty in advance.

6 19

Bypass media succeeds from extension to gateway but fails from extension to extension
by Phil Quesinberry 11 May '12

11 May '12

Ken, Thanks for taking the time to write that out. I understand that and that makes perfect sense, although the endpoints in this case are configured to report their external IP addresses, either through STUN or a static NAT IP entry. What still is unclear to me is why this failed when FS was able to successfully bridge the same extension directly to the PSTN gateway. As for my skill level before I continue - Ive got years and years of advanced networking experience but Ive only been running FS for a few months and I still have a lot to learn, so please forgive me if Im still missing the point. I feel like Im really starting to make sense of it all now though, which probably only serves to make me a danger to myself and others. I dont want to waste your time with dumb questions, but I get the impression that there arent that many people out there with the level of understanding to be able to answer questions like this who are actually willing to do so. I REALLY appreciate your time, I want to be sure that I fully understand this. The situation here, endpoint A is a local extension on the same LAN as FS: Endpoint A (192.168.1.4) -> FS (192.168.1.6) -> NAT A -> Internet -> NAT B -> Endpoint B (10.0.0.x/24) Endpoint Bs WAN address is 71.179.xx.xx >From the traffic I pastebinned, we can see that Endpoint A is sending its external WAN address info to FS, right before FS sends Endpoint As internal LAN address to Endpoint B, so I would think that FS should be passing Endpoint As WAN address along instead of its LAN address for media: recv 722 bytes from udp/[192.168.1.4]:5060 at 14:03:20.015051: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 71.179.xx.xx;rport=5060;branch=z9hG4bKgKQKBycpSp0XD;received=192.168.1.6 From: <sip:225@192.168.1.6:5060;user=phone>;tag=6F6tm8F5v3D5j To: "Phil" <sip:102@192.168.1.6:5060>;tag=fce60a24bc Call-ID: cabfc783414db5c6 CSeq: 27863635 UPDATE Contact: "Phil" <sip:102@192.168.1.4:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0 000-1000-8000-00085D296BF3>" Server: Aastra 9480i/3.2.2.2044 Session-Expires: 120;refresher=uas Supported: path, timer Content-Type: application/sdp Content-Length: 178 v=0 o=MxSIP 0 2 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv ------------------------------------------------------------------------ 2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.011485 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:754 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] sofia.c:5628 Channel sofia/internal/102@192.168.1.6:5060 entering state [ready][200] 2012-05-07 10:03:20.039490 [DEBUG] sofia.c:5639 Remote SDP: v=0 o=MxSIP 0 2 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 send 1103 bytes to udp/[74.93.xx.xx]:1067 at 14:03:20.052233: ------------------------------------------------------------------------ INVITE sip:225@74.93.xx.xx:1067;transport=udp SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKHvgcDSXSpZpgS Max-Forwards: 69 From: "Phil" <sip:102@192.168.1.6>;tag=7rZKp308Sc4Qe To: <sip:225@74.93.xx.xx:1067;transport=udp>;tag=1672444754 Call-ID: 3682faf7-12f0-1230-4bae-feffffffffff CSeq: 27863631 INVITE Contact: <sip:mod_sofia@71.179.xx.xx:5060> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Require: timer Supported: timer, precondition, path, replaces Session-Expires: 120;refresher=uas Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 217 X-FS-Support: update_display,send_info Remote-Party-ID: "Phil" <sip:102@192.168.1.6>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1336379701 1336379703 IN IP4 71.179.xx.xx s=FreeSWITCH c=IN IP4 192.168.1.4 WRONG! t=0 0 m=audio 1638 RTP/AVP 0 8 98 3 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=30 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:4817 Our existing sdp is still good [PCMU 71.179.xx.xx:16384], let's keep it. 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:5043 No 2833 in SDP. Disable 2833 dtmf and switch to INFO 2012-05-07 10:03:20.039490 [DEBUG] sofia.c:6212 Processing updated SDP 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:3214 Audio params are unchanged for sofia/internal/102@192.168.1.6:5060. 2012-05-07 10:03:20.039490 [DEBUG] sofia_glue.c:3224 sofia/internal/102@192.168.1.6:5060 Setting audio receive payload in Re-INVITE to 0 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:754 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_ivr_bridge.c:1146 (sofia/internal/102@192.168.1.6:5060) State Change CS_EXECUTE -> CS_HIBERNATE 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:1205 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_ivr_bridge.c:1147 (sofia/internal/sip:225@74.93.xx.xx:1067) State Change CS_PARK -> CS_HIBERNATE 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:1205 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:816 Send signal sofia/internal/sip:225@74.93.xx.xx:1067 [BREAK] 2012-05-07 10:03:20.039490 [DEBUG] switch_core_session.c:816 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] 2012-05-07 10:03:20.053837 [DEBUG] sofia.c:5628 Channel sofia/internal/sip:225@74.93.xx.xx:1067 entering state [calling][0] 2012-05-07 10:03:20.053837 [DEBUG] mod_sofia.c:2191 Not sending same id again "Phil" <102> send 1006 bytes to udp/[192.168.1.4]:5060 at 14:03:20.054056: ------------------------------------------------------------------------ INVITE sip:102@192.168.1.4:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKj594emeXK8c3m Max-Forwards: 70 From: <sip:225@192.168.1.6:5060;user=phone>;tag=6F6tm8F5v3D5j To: "Phil" <sip:102@192.168.1.6:5060>;tag=fce60a24bc Call-ID: cabfc783414db5c6 CSeq: 27863636 INVITE Contact: <sip:225@71.179.xx.xx:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 2012-05-07 10:03:20.053837 [DEBUG] switch_core_state_machine.c:426 (sofia/internal/sip:225@74.93.xx.xx:1067) State PARK going to sleep Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Require: timer Supported: timer, precondition, path, replaces 2012-05-07 10:03:20.053837 [DEBUG] switch_core_state_machine.c:362 (sofia/internal/sip:225@74.93.xx.xx:1067) Running State Change CS_HIBERNATE Session-Expires: 120;refresher=uas Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 218 X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1336377747 1336377749 IN IP4 192.168.1.6 s=FreeSWITCH c=IN IP4 74.93.xx.xx t=0 0 m=audio 51720 RTP/AVP 0 8 98 3 a=rtpmap:98 iLBC/8000 a=fmtp:98 mode=30 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ Call fails with no audio. Now, if I try to make a call from that same endpoint to the PSTN in bypass media mode, FS sends the endpoints WAN address like I would expect it to, and the call works... see below. I'm getting rid of a bunch of ACKs and such for brevity and clarity but the transaction goes like this: Endpoint A sends its invite, complete with WAN address info: ------------------------------------------------------------------------ recv 1279 bytes from udp/[192.168.1.4]:5060 at 18:00:37.133916: ------------------------------------------------------------------------ INVITE sip:94109693xxx@192.168.1.6:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.1.4;branch=z9hG4bK69b9ae7c0bd9ac684;rport Route: <sip:192.168.1.6:5060;lr> Proxy-Authorization: Digest username="102",realm="192.168.1.6",nonce="ecd26c6e-c2d9-4669-b842- 232e99abb7a2",uri="sip:94109693xxx@192.168.1.6:5060;user=phone",response="6e 2edf5ebde2d6eaae7dd46e73cf5f88",algorithm=MD5,qop=auth,cnonce="6defb5b4",nc= 00000001 Max-Forwards: 70 From: "Phil" <sip:102@192.168.1.6:5060>;tag=6de7cac307 To: <sip:94109693xxx@192.168.1.6:5060;user=phone> Call-ID: 8d9c7aa8f30bc1d3 CSeq: 30988 INVITE Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO Allow-Events: talk, hold, conference, LocalModeStatus Contact: "Phil" <sip:102@192.168.1.4:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0 000-1000-8000-00085D296BF3>" Min-SE: 120 Session-Expires: 120 Supported: path, 100rel, replaces, timer User-Agent: Aastra 9480i/3.2.2.2044 Content-Type: application/sdp Content-Length: 255 v=0 o=MxSIP 0 1 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 110 8 9 a=rtpmap:0 PCMU/8000 a=rtpmap:110 PCMU/16000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv Now FS sends the invite to the gateway, complete with proper info: send 1163 bytes to udp/[199.96.248.140]:5060 at 18:00:37.171788: ------------------------------------------------------------------------ INVITE sip:14109693xxx@199.96.248.140 SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx:5080;rport;branch=z9hG4bKK20cSjr649cta Max-Forwards: 69 From: "QSystems" <sip:14109698xxx@71.179.xx.xx>;tag=m2Djgjet89Ztj To: <sip:14109693xxx@199.96.248.140> Call-ID: 0db1020c-1636-1230-a98d-feffffffffff CSeq: 28043554 INVITE Contact: <sip:gw+Alcazar_US@71.179.xx.xx:5080;transport=udp;gw=Alcazar_US> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 279 X-accountcode: 102 X-FS-Support: update_display,send_info Remote-Party-ID: "QSystems" <sip:14109698xxx@71.179.xx.xx>;party=calling;screen=yes;privacy=off v=0 o=MxSIP 3719756330637231183 2523006830856012877 IN IP4 192.168.1.4 s=SIP Call c=IN IP4 71.179.xx.xx t=0 0 m=audio 16384 RTP/AVP 0 110 8 9 a=rtpmap:0 PCMU/8000 a=rtpmap:110 PCMU/16000 a=rtpmap:8 PCMA/8000 a=rtpmap:9 G722/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ In the meantime, FS receives and passes along 180 - Ringing PSTN destination answers the call, gateway comes back with upstream provider's media address: ------------------------------------------------------------------------ recv 886 bytes from udp/[199.96.248.140]:5060 at 18:00:43.320321: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 71.179.xx.xx:5080;rport=5080;branch=z9hG4bKK20cSjr649cta Record-Route: <sip:199.96.248.140;lr=on> From: "QSystems" <sip:14109698xxx@71.179.xx.xx>;tag=m2Djgjet89Ztj To: <sip:14109693xxx@199.96.248.140>;tag=m3p9c1NF8UDyQ Call-ID: 0db1020c-1636-1230-a98d-feffffffffff CSeq: 28043554 INVITE Contact: <sip:14109693xxx@10.1.50.23:5004;transport=udp> User-Agent: AlcazarSBC 1.10 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, NOTIFY Supported: timer, precondition, path, replaces Allow-Events: talk, hold, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 193 X-FS-Support: update_display,send_info v=0 o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3 s=FreeSWITCH c=IN IP4 208.103.143.3 t=0 0 m=audio 16998 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ FS passes upstream info to Endpoint A, and then sends an update (for the display, I think): send 1045 bytes to udp/[192.168.1.4]:5060 at 18:00:43.330695: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.4;branch=z9hG4bK69b9ae7c0bd9ac684;rport=5060 From: "Phil" <sip:102@192.168.1.6:5060>;tag=6de7cac307 To: <sip:94109693xxx@192.168.1.6:5060;user=phone>;tag=0BaHerZS08taQ Call-ID: 8d9c7aa8f30bc1d3 CSeq: 30988 INVITE Contact: <sip:94109693xxx@71.179.xx.xx:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Require: timer Supported: timer, precondition, path, replaces Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Session-Expires: 120;refresher=uac Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 193 v=0 o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3 s=FreeSWITCH c=IN IP4 208.103.143.3 t=0 0 m=audio 16998 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ 2012-05-11 14:00:27.083254 [DEBUG] switch_core_session.c:900 Send signal sofia/internal/102@192.168.1.6:5060 [BREAK] send 973 bytes to udp/[192.168.1.4]:5060 at 18:00:43.331578: ------------------------------------------------------------------------ UPDATE sip:102@192.168.1.4:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 71.179.xx.xx;rport;branch=z9hG4bKN3ej0NXFj8ayj Max-Forwards: 70 From: <sip:94109693xxx@192.168.1.6:5060;user=phone>;tag=0BaHerZS08taQ To: "Phil" <sip:102@192.168.1.6:5060>;tag=6de7cac307 Call-ID: 8d9c7aa8f30bc1d3 CSeq: 28043557 UPDATE Contact: <sip:94109693xxx@71.179.xx.xx:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.1.beta1-git-883dd29 2012-05-06 11-27-00 +0000 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: timer, precondition, path, replaces Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 193 P-Asserted-Identity: "Outbound Call" <sip:14109693xxx@192.168.1.6> v=0 o=FreeSWITCH 1336742245 1336742246 IN IP4 208.103.143.3 s=FreeSWITCH c=IN IP4 208.103.143.3 t=0 0 m=audio 16998 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=ptime:20 ------------------------------------------------------------------------ Call completes normally, and everything works. Help me to understand why FS can't do the same thing for extension to extension calls. Thanks again, - Phil ---------- Ken Rice Thu May 10 19:08:53 MSD 2012 The contact IP has nothing to do with where the media goes... That¹s entirely defined in the SDP... Consider this Endpoint A (192.168.100.100) -> NAT A -> FreeSWITCH (4.2.2.2) -> NAT B -> Endpoint B (192.168.100.200) Now lets assume that NAT A and NAT B are 2 separate nat gateways and that Endpoint A and Endpoint B are on 2 different physical LANs... Telling Endpoint A to talk directly to Endpoint B without proxying media will never work since the endpoints think they are on the same LAN. There is no mechanism there to allow for the redirection and automagic adjustments of ports etc so that they can talk directly to each other... Now lets change this slightly so that endpoint B is 192.168.200.200. Unless NAT A knows how to get to 192.168.200.0/24 (assuming class C sized block) and NAT B knows how to get to 192.168.100.0/24 they are both going to use their default routing which is to NAT the outgoing RTP, and forward it to the next hop... Again, RTP will not make it to other side in either direction... FreeSWITCH cant compensate due to a number of factors... Your Endpoints have to be smart enough to actually compensate for the NAT in this situation OR your NAT boxes have to compensate for it... The simple answer, don¹t use bypass media in this situation, the complex answer I wont get into here... Stop by IRC and ask around... There is a 3rd option here you might want to consider, contact consulting at freeswitch.org <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users> for some professional help... This may not be specifially what you need to get going as I have no clue what your skill level happens to be, and you did say you are still learning. Good Luck!

1 0

SMS with GSMOpen not support Thai charecters encoded in utf-8
by Chaiyawut Sookplang 11 May '12

11 May '12

I used GSMOpen to send SMS and I got this problem. Seem like it doesn't support Thai alphabet even I encoded as UTF-8. The empty message was sent by the way. 2012-05-11 20:49:53.235742 [NOTICE] mod_gsmopen.cpp:2856 rev adae5e5|bbae68a[(nil)|37 ][NOTICA 2856 ][interface_1][-1, 0, 0] chat_send(proto=sms, from=interface_1, to=0860216060, subject=SIMPLE MESSAGE, body=ทดสอบดู, type=NULL, hint=interface_1) 2012-05-11 20:49:53.295735 [ERR] gsmopen_protocol.cpp:2405 rev adae5e5|bbae68a[(nil)|37 ][ERRORA 2405 ][interface_1][-1, 0, 0] error: Invalid or incomplete multibyte or wide character 84

2 1

XML_CURL directory configuration does not fail over to static XML
by Vik Killa 11 May '12

11 May '12

I've noticed that when binding the FS directory configuration to XML_CURL, FS does not fail over to static XML when XML_CURL fails. I've verified this by loading identical directory configurations in XML_CURL and in static XML. When I run the following command, it only returns a result if XML_CURL is available: user_data 1000(a)testdomain.com var mailbox if the XML_CURL query fails, it does not look in the static XML (which is loaded into memory), instead it returns: -ERR no reply Is this the expected behavior or is it a bug? This behavior is not the case for dialplan configuration. While binding XML_CURL to dialplan, if XML_CURL fails, it will use the static XML that is loaded into memory.

2 4

FreeSWITCH, OSX, Libtool, Macports
by Chris Mylonas 11 May '12

11 May '12

Hi FS Users, tl;dr; - removed macports, removed tree, pulled fresh tree = installed FS on OSX. Here is the longer version that had a bit of a pre-emptive whinge about libtool version mismatch. But we never got there - it worked! I'm in the process of re-installing FS on OSX (10.6.8). I have removed Macports to try and get this up and running. I re-bootstrapped and got this error: quiet_libtool: Version mismatch error. This is libtool 2.4, but the quiet_libtool: definition of this LT_INIT comes from libtool 2.2.4. quiet_libtool: You should recreate aclocal.m4 with macros from libtool 2.4 quiet_libtool: and run autoconf again. make[1]: *** [libfreeswitch_la-switch_apr.lo] Error 63 make: *** [all] Error 2 Removed the whole git tree just in case there was some left over junk. Pulled a fresh tree and noticed this remark during a fresh bootstrap arakis:freeswitch-git chrismylonas$ rm -Rf freeswitch/ arakis:freeswitch-git chrismylonas$ git clone git://git.freeswitch.org/freeswitch.git Cloning into freeswitch... remote: Counting objects: 185609, done. remote: Compressing objects: 100% (39208/39208), done. remote: Total 185609 (delta 143241), reused 181443 (delta 140035) Receiving objects: 100% (185609/185609), 77.85 MiB | 267 KiB/s, done. Resolving deltas: 100% (143241/143241), done. arakis:freeswitch-git chrismylonas$ cd freeswitch/ arakis:freeswitch chrismylonas$ ./bootstrap.sh bootstrap: checking installation... bootstrap: autoconf version 2.61 (ok) bootstrap: automake version 1.10 (ok) bootstrap: aclocal version 1.10 (ok) bootstrap: libtool version 2.2.4 (ok) Bootstrapping using: autoconf : /usr/bin/autoconf automake : /usr/bin/automake aclocal : /usr/bin/aclocal libtool : /usr/bin/glibtool (2.2.4.) libtoolize: /usr/bin/glibtoolize make : /usr/bin/make (GNU Make 3.81) awk : () It is still reporting a 2.2.4 version of libtool. ... ... ... In the end, it has been compiled and installed though

2 3

Gaps In RTP (wideband) Packets From mod_voicemail
by Jerry Richards 11 May '12

11 May '12

Hello, I'm seeing a audio problem when listening to the operator when calling into voicemail to listen to messages and a wideband codec is used. Looking at a wireshark trace, I see gaps between transmitted RTP packets that exceed the jitter buffer depth in the endpoint softphone, causing underflow. This causes clipping of the front-end of words such as "Pressed" sounds like 'ess' and "Last name" sounds like 'ast name'. While this is generally not noticeable with the G.711 codec, it causes these clipped audio phrases with wideband codecs, such as BV32. It might be due to the processing delay in mod_voicemail between phrases? Has anyone seen this? Is there a tag to help improve this? Thanks, Jerry

2 6

Freetdm DTMF
by Shane Harrison 11 May '12

11 May '12

Hi All, Have a situation where I have a call between a SIP phone and a FreeTDM channel. Pushing *3 on the analog FreeTDM phone is detected and this is bound to a dialplan extension (attended transfer) that does a read(): <action application="read" data="3 3 'tone_stream://%(10000,0,350,440)' digits 30000 #"/> However pushing further digits on the analog phone ie. extension number of phone we wish to do an attended transfer to , doesn't result in the DTMF being detected. Note that this all works the other way around ie. using the SIP phone. When the *3 digits are pushed on the analog phone I see the logs report: ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF * (debug = 0) mod_freetdm.c:702 Queuing DTMF [*] in channel FreeTDM/2:1/ ftdm_io.c:3463 [s2c1][1:4] Queuing DTMF 4 (debug = 0) mod_freetdm.c:702 Queuing DTMF [4] in channel FreeTDM/2:1/ When the further keys are pushed ftdm_io reports nothing. I have tried inserting a start_dtmf before the read() but it had no effect. Any thoughts as to why DTMF isn't being seen from the analog phone after the read()? Cheers Shane

3 12