- FreeSWITCH-users - FreeSWITCH Mailing Lists

voice mail to email silently failing
by Alan Dawson 21 Jul '10

21 Jul '10

Hi, I'm running FreeSWITCH Version 1.0.head (git-1cbf30a 2010-07-02 20-19-03 -0300) I've configured a mailbox like <params> <param name="password" value="$${default_password}"/> <param name="vm-password" value="1000"/> <param name="vm-email-all-messages" value="true"/> <param name="vm-attach-file" value="true"/> <param name="vm-mailto" value="aland(a)burngreave.net"/> </params> and tried several variations on <param name="mailer-app" value="/usr/local/bin/eximcompat.sh"/>  or using the perl script http://svn.freeswitch.org/svn/freeswitch/trunk/scripts/perl/sendmail in switch.conf.xml In my freeswitch.log I see 2010-07-14 02:37:49.664750 [DEBUG] switch_utils.c:631 Emailed file [/tmp/mail.12790714694210] to [aland(a)burngreave.net] 2010-07-14 02:37:49.668750 [DEBUG] mod_voicemail.c:2571 Sending message to aland(a)burngreave.net 2010-07-14 02:41:57.277097 [DEBUG] switch_utils.c:631 Emailed file [/tmp/mail.12790717177ad8] to [aland(a)burngreave.net] 2010-07-14 02:41:57.277097 [DEBUG] mod_voicemail.c:2571 Sending message to aland(a)burngreave.net but no email is delivered, nor any entries appear in my MTA logs I _do_ have a working MTA on this machine, and if I ( as user freeswitch or root ) do cat /tmp/msg.txt | /usr/local/bin/eximcompat.sh mail is successfully sent and delivered. Thanks in advance, -- Alan Dawson

1 1

TLS error?
by Federico Beffa 21 Jul '10

21 Jul '10

Hi All, I've found the problem: for some reason, during installation (make install) mod_dingaling is not linked against libgnutls.so. As a test I have added the "-lgnutls" switch in src/mod/endpoints/mod_dingaling/mod_dingaling.la to gcc in the relink_command. After re-issuing "make install" everything works fine and I can connect to gtalk. I guess this can be classified as a "configure" error. Regards, Fede

1 0

Slightly OT: Pulling specific git "revisions"
by Kristian Kielhofner 21 Jul '10

21 Jul '10

Hello everyone, I've got scripts for building specific SVN revisions of FreeSWITCH (for AstLinux, etc). How do I best accomplish this with git? I'm looking for something like this: svn co -r 17856 ...but for git. Any ideas? I've looked at various git docs, sites, etc and I can't seem to come up with something equivalent. -- Kristian Kielhofner http://www.astlinux.org http://blog.krisk.org http://www.star2star.com http://www.submityoursip.com http://www.voalte.com

3 2

RTP Timing
by Neil Burgess 21 Jul '10

21 Jul '10

Hi, We are capturing packets for call quality monitoring purposes, and as part of the capture, we are grabbing the outbound packets from FreeSwitch. We are noticing what appears to be an odd behaviour in the RTP sequence timing where suddenly the timing will jump from the regular 160 increments to a number in the 10's of millions! See packet 38 below. Now I have no idea as to whether such a timing change is OK in RTP, and although the actual RTP stream does not appear to be affected, I do see that Wireshark believes there is a massive amount of jitter on the line when it analyses the packets, and any RTCP Sender Reports from the target device (and indeed several different target types have been tried) also report very large inter arrival jitter numbers at this point! It's the RTCP side of things that are more of interest here, as trying to get accurate results of our downstream jitter by capturing the returned RTCP packets. I believe that all the times we see this, there is however a Marker bit present! So I guess the question is whether this is expected behaviour, and if not any ideas? No. Time Source Destination Protocol Info 1 0.000000 gmtpbx02.redmatter.com sil1.magrathea.net SIP/SDP Request: INVITE sip:441277849884@sipipgw.magrathea.net, with session description 2 0.001595 sil1.magrathea.net gmtpbx02.redmatter.com SIP Status: 100 Giving a try 3 1.103160 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=0, Time=0 4 1.124816 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=1, Time=160 5 1.142758 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=2, Time=320 6 1.163702 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=3, Time=480 7 1.184239 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=4, Time=640 8 1.203259 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=5, Time=800 9 1.223456 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=6, Time=960 10 1.243953 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=7, Time=1120 11 1.264504 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=8, Time=1280 12 1.284839 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=9, Time=1440 13 1.304590 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=10, Time=1600 14 1.323589 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=11, Time=1760 15 1.344672 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=12, Time=1920 16 1.359227 sil1.magrathea.net gmtpbx02.redmatter.com SIP/SDP Status: 183 Session Progress, with session description 17 1.364522 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=13, Time=2080 18 1.377484 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53974, Time=160, Mark 19 1.383466 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=14, Time=2240 20 1.397476 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53975, Time=320 21 1.403953 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=15, Time=2400 22 1.417484 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53976, Time=480 23 1.423616 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=16, Time=2560 24 1.437474 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53977, Time=640 25 1.444930 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=17, Time=2720 26 1.457475 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53978, Time=800 27 1.463341 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=18, Time=2880 28 1.477473 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53979, Time=960 29 1.484235 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=19, Time=3040 30 1.497483 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53980, Time=1120 31 1.503415 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=20, Time=3200 32 1.517474 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53981, Time=1280 33 1.523541 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=21, Time=3360 34 1.537472 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53982, Time=1440 35 1.543428 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=22, Time=3520 36 1.557567 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53983, Time=1600 37 1.563656 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=23, Time=3680 38 1.577496 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53984, Time=130238272, Mark 39 1.584747 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=24, Time=3840 40 1.597474 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53985, Time=130238432 41 1.603871 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=25, Time=4000 42 1.617465 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53986, Time=130238432 43 1.624224 lon-avon-four.magrathea.net gmtpbx02.redmatter.com RTP PT=ITU-T G.711 PCMU, SSRC=0x216DE2D9, Seq=26, Time=4160 44 1.637466 gmtpbx02.redmatter.com lon-avon-four.magrathea.net RTP PT=ITU-T G.711 PCMU, SSRC=0x1855F3A7, Seq=53987, Time=130238592 Many thanks, Neil

5 6

Conf Call Just Started!
by Michael Collins 21 Jul '10

21 Jul '10

Here's today's agenda page: http://wiki.freeswitch.org/wiki/FS_weekly_2010_07_21 -MC

1 0

Re: [Freeswitch-users] calls ending with MEDIA_TIMEOUT
by Dan 21 Jul '10

21 Jul '10

Gotcha, if I sort wireshark by source freeswitch sends 2 RTP packets and then a handful if ICMP errors, this pattern repeats for the entire call (2 voice packets and 5+ icmp errors). 192.168.24.22 = freeswitch 192.168.21.4 = endpoint ID Time Source Src Port Destination Dest Port 12 0.186121 192.168.24.22 27176 192.168.21.4 16752 RTP PT=ITU-T G.711 PCMU, SSRC=0x33CF6C8, Seq=5202, Time=240, Mark 13 0.186126 192.168.24.22 27176 192.168.21.4 16752 RTP PT=ITU-T G.711 PCMU, SSRC=0x33CF6C8, Seq=5202, Time=240, Mark 57 1.477101 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) 92 2.467948 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) 93 2.467949 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) 194 5.465388 192.168.24.22 16752 192.168.21.4 27176 ICMP Destination unreachable (Port unreachable) The ICMP erros have the ports reversed, is this normal ? Thanks, Dan- From: "Brian West" <brian(a)freeswitch.org> To: "FreeSWITCH Users Help" <freeswitch-users(a)lists.freeswitch.org> Sent: Wednesday, July 21, 2010 8:30:40 AM Subject: Re: [Freeswitch-users] calls ending with MEDIA_TIMEOUT NO that would mean that it was sending RTP to that IP and the firewall returned and ICMP port unreachable. /b On Jul 21, 2010, at 8:43 AM, Dan wrote: > I was able to pull the box out yesterday and try some load testing under tcpdump. It looks like under load freeswitch was trying to ping the far end RTP port which was failing: > > 57 1.477101 192.168.24.22 192.168.21.4 ICMP Destination unreachable (Port unreachable) > > I'm guessing this is part of auto nat detection? Is this a tunable option? I don't need stun/nat functionality at this point so I'm running freeswitch with the -nonat flag right now to see if its playing a part here. > > I have the tcpdump of a call if anyone is interested. > > Thanks > Dan- _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

1 0

calls ending with MEDIA_TIMEOUT
by Dan 21 Jul '10

21 Jul '10

Hi guys, I have been running two freeswitch boxes (13754M) that answer calls from a cisco 5300 (both on the same network) and records them to disk with a small lua application. This has been working well for the past few months. I decided to upgrade one of them to trunk ( git-3fbd9e2 2010-06-11 11-08-51 -0500 ) and have run into a problem. Some calls will fail with a MEDIA_TIMEOUT after a few minutes, the time it takes to fail ranges from 4 minutes to 10 minutes, I don't have a full sip trace or pcap dump yet, I reverted back to the old freeswitch version (on the same hardware) and have not been able to reproduce it in a test environment yet ( I continue to try). Below are the relevant lines from the log files for one of the calls: 2010-06-23 07:42:19.033466 [DEBUG] switch_channel.c:2257 (sofia/external/nobody(a)192.168.21.4) Callstate Change ACTIVE -> HANGUP 2010-06-23 07:42:19.033466 [NOTICE] mod_sofia.c:884 Hangup sofia/external/nobody(a)192.168.21.4 [CS_EXECUTE] [MEDIA_TIMEOUT] 2010-06-23 07:42:19.033466 [DEBUG] switch_channel.c:2273 Send signal sofia/external/nobody(a)192.168.21.4 [KILL] 2010-06-23 07:42:19.033466 [DEBUG] switch_core_session.c:1023 Send signal sofia/external/nobody(a)192.168.21.4 [BREAK] 2010-06-23 07:42:19.033466 [DEBUG] switch_core_codec.c:146 sofia/external/nobody(a)192.168.21.4 Restore previous codec PCMU:0. My configuration is bone stock, so the rtp timeout value is at 300, but I have some calls that have lasted only 4 minutes. One other piece of information is that on one of the recordings that was hung up after 4 minutes and 17 seconds the recorded file was only 24 seconds long (it stopped recording after the first 24 seconds) , so I'm assuming freeswitch did not think there were any rtp packets to record. Any ideas on where to start debugging this? I have setup a new freeswitch box connected to the same 5300 to reproduce, but have not been able to generate the call volume ( there where around 30 calls being recorded) yet, but I'm working on it. Thanks!

4 6

Re: [Freeswitch-users] Howler - Gone?
by Kristian Kielhofner 21 Jul '10

21 Jul '10

I was working on a project with IBM, speex, and the University of Sao Paulo to do this a few years ago. Very interesting. Either way Sony disabled the "install other OS" feature so no more Linux on the PS3. -- Kristian Kielhofner http://blog.krisk.org ----- Original Message ----- From: freeswitch-users-bounces(a)lists.freeswitch.org <freeswitch-users-bounces(a)lists.freeswitch.org> To: FreeSWITCH Users Help <freeswitch-users(a)lists.freeswitch.org> Sent: Tue Jul 20 22:00:50 2010 Subject: Re: [Freeswitch-users] Howler - Gone? But finally howler show to us something good: With the Cell chips used in the Leadteck (are the same on a PS3), we can make a transcoding equipment with a PS3 for $299 USD... :) Using the Ethernet of the PS3 we can send the RTP to the transcoding software and the device has enough power to convert 400+ concurrent calls.... only think about it. Best Regards... Fernando Romo On Jul 20, 2010, at 7:50 PM, Steve Underwood wrote: > On 07/21/2010 08:42 AM, Moises Silva wrote: >> On Tue, Jul 20, 2010 at 8:33 PM, Steve Underwood <steveu(a)coppice.org >> <mailto:steveu@coppice.org>> wrote: >> >> Someone may be able to give you a copy of the drivers, but won't you >> need access to Howler's licencing server to enable your licences? >> >> >> At least with Sangoma transcoding card you don't need any servers to >> enable licensing (and you have a bunch of codecs, not just G729). >> > You have a custom card at Sangoma, so I guess you have more fine grained > control with the card itself. Howler just used commercial Cell based > cards from Leadtek, and had to live with their strengths and weaknesses. > Since they sold the licences separate from the card, so you could buy a > card with just a few licences for a sensible price, I think they tied > down the licences in the same way they did for codecs running on the > server's CPU. Perhaps an actual Howler user could chime in here with > more info. > > Steve > > > > _______________________________________________ > FreeSWITCH-users mailing list > FreeSWITCH-users(a)lists.freeswitch.org > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org _______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users(a)lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org

1 0

ESL: api command
by Helmut Kuper 21 Jul '10

21 Jul '10

Hello, I have an inbound ESL script which has subscribed to several events. So there is more or less a continuing stream of events. When it sends a blocking api command to FS is it there a risk to get back an event first before FS sends the command reply or does FS guarantee that the command reply is always next after issuing a api command? regards helmut

3 3

eavesdroping!
by babak yakhchali 21 Jul '10

21 Jul '10

Hi what do u suggest for this scenario: I want to be able to listen to calls from a web page. so there should be a streaming server to place a call to freeswitch(on dialplan there should be an extension which matches this call and uses eavesdropping for requested channel) and stream the incoming media from freeswitch to client browser. browser -> media server(sip) <--> freeswitch I think the main problem is media server! thanx

6 13