September 2011 - FreeSWITCH-dev - FreeSWITCH Mailing Lists

Epoch current time difference
by Glaucio Vaz de Mello 10 Jan '12

10 Jan '12

Hello, I noticed a difference between FreeSWITCH time and system clock time. Is this a standard behaviour? or something is wrong in my system? More details of the issue: Inside FreeSWITCH I look for current epoch time using this function: time_t now = switch_epoch_time_now(NULL); Then I look for system clock current time using: #include <time.h> time_t now = time(NULL); Between both results I noticed a difference of 9 seconds. This can also be viewed using Unix commands. Unix date command from console: # date +%s 1314741992 Then, I start a call and make a DB query: # sqlite3 /var/freeswitch/db/core.db "SELECT call_created_epoch FROM calls;" 1314742000 Then I repeat unix date command: # date +%s 1314741994 Any comments are welcome. Regards, Glaucio

10 22

mod_portaudio multiple endpoints support
by Moises Silva 25 Oct '11

25 Oct '11

Hello, I've been doing some changes to mod_portaudio sponsored by Comrex Corporation. The changes involve adding support for using multiple audio devices simultaneously, including devices with multiple channels (note that is not exactly the same as stereo). The changes are available at git:// github.com/moises-silva/mod_portaudio-endpoints.git Complete documentation on the new functionality in portaudio can be found in the sample configuration in the form of comments (conf/autoload_configs/portaudio.conf.xml). The portaudio changes are totally backwards compatible, existing configurations should keep working as expected. In addition to the new portaudio functionality there are a few other changes that were necessary to use the new functionality. All the changes described below: 1. mod_portaudio.c and pablio.c modifications to allow usage of multiple streams, channels and devices. 2. uuid_outgoing_answer API added to mod_commands.c, this API allows to answer outgoing channels. This may only be useful for portaudio endpoints since most, if not all, endpoints receive the answer notification using some sort of signaling message (200 OK for example). 3. Changes to switch_generate_sln_silence() in switch_resample.c to allow specifying -1 as a special divisor value meaning to zero-out the buffer completely. This option was required by Comrex too since the equipment they have seems to be amplifying the random low-level noise that switch_generate_sln_silence() currently generates by default and they don't like the "hissing noise" on the background while the call is answered and there is no ringback tone. I'd appreciate anyone who can review and comment. I just merged a few moments ago with latest git therefore reviewing should be easy with git diff adding the github repo as a remote. I'd like to get approval from the core FreeSWITCH team to merge this into mainstream. Needless to say I'll be available in the case any bugs are introduced in the portaudio code, virtually impossible, but just in case :-) Thanks, - Moy

6 8

coredump connecting to ldap database from dialplan within lua
by Jyotshna Cherukuri 12 Oct '11

12 Oct '11

Hi, I am having a problem connecting to LDAP database from dialplan using lua script. When I run the below script from xml dialplan it causing a coredump and Freeswitch crashes. The coredump looks like: Core was generated by `/usr/local/freeswitch/bin/freeswitch -nonat -nc -heavy-timer'. Program terminated with signal 11, Segmentation fault. #0 0x00002aaab6ff1720 in ldap_set_option () from /usr/lib64/libldap-2.3.so.0 (gdb) bt #0 0x00002aaab6ff1720 in ldap_set_option () from /usr/lib64/libldap-2.3.so.0 #1 0x00002aaab6dbb68a in lualdap_open_simple () from /usr/local/lib/lua/5.1/lualdap.so #2 0x00002aaab6b91704 in luaD_precall (L=0x14e12740, func=<value optimized out>, nresults=-1) at ldo.c:319 #3 0x00002aaab6b9a4a4 in luaV_execute (L=0x14e12740, nexeccalls=1) at lvm.c:587 #4 0x00002aaab6b91b4e in luaD_call (L=0x14e12740, func=0x14e12b20, nResults=0) at ldo.c:377 #5 0x00002aaab6b912a7 in luaD_rawrunprotected (L=0x14e12740, f=0x2aaab6b8ed40 <f_call>, ud=0x409f4e00) at ldo.c:116 #6 0x00002aaab6b91325 in luaD_pcall (L=0xffffffffb002d5d0, func=0, u=0x2aaab002d5b8, old_top=46912585783072, ef=0) at ldo.c:463 #7 0x00002aaab6b8ebc5 in lua_pcall (L=0x14e12740, nargs=0, nresults=0, errfunc=<value optimized out>) at lapi.c:821 #8 0x00002aaab6b76d61 in docall (L=0x14e12740, narg=0, clear=1, perror=0) at mod_lua.cpp:91 #9 0x00002aaab6b77194 in lua_parse_and_execute (L=0x14e12740, input_code=0x2aaab004c220 "ldapdirectory.lua") at mod_lua.cpp:183 #10 0x00002aaab6b77e92 in lua_function (session=0x14e5bb68, data=<value optimized out>) at mod_lua.cpp:414 #11 0x00002b027ace8cd9 in switch_core_session_exec (session=0x14e5bb68, application_interface=0x2aaaac0622d8, arg=0x14d75968 "ldapdirectory.lua") at src/switch_core_session.c:2048 #12 0x00002b027ace9176 in switch_core_session_execute_application_get_flags (session=0xffffffffb002d5d0, app=0x14d758e8 "lua", arg=0x14d75968 "ldapdirectory.lua", flags=0x0) at src/switch_core_session.c:1962 #13 0x00002b027ad57a1a in CoreSession::execute (this=0x14d74d60, app=0x14d758e8 "lua", data=0x14d75968 "ldapdirectory.lua") at src/switch_cpp.cpp:658 #14 0x00002aaab6b861c0 in _wrap_CoreSession_execute (L=0x2aaaac002050) at mod_lua_wrap.cpp:5678 #15 0x00002aaab6b91704 in luaD_precall (L=0x2aaaac002050, func=<value optimized out>, nresults=0) at ldo.c:319 #16 0x00002aaab6b9a4a4 in luaV_execute (L=0x2aaaac002050, nexeccalls=1) at lvm.c:587 #17 0x00002aaab6b91b4e in luaD_call (L=0x2aaaac002050, func=0x2aaaac012400, nResults=0) at ldo.c:377 #18 0x00002aaab6b912a7 in luaD_rawrunprotected (L=0x2aaaac002050, f=0x2aaab6b8ed40 <f_call>, ud=0x409f5800) at ldo.c:116 #19 0x00002aaab6b91325 in luaD_pcall (L=0xffffffffb002d5d0, func=0, u=0x2aaab002d5b8, old_top=46912585783072, ef=0) at ldo.c:463 #20 0x00002aaab6b8ebc5 in lua_pcall (L=0x2aaaac002050, nargs=0, nresults=0, errfunc=<value optimized out>) at lapi.c:821 #21 0x00002aaab6b76d61 in docall (L=0x2aaaac002050, narg=0, clear=1, perror=0) at mod_lua.cpp:91 #22 0x00002aaab6b77194 in lua_parse_and_execute (L=0x2aaaac002050, input_code=0x14de5e00 "helloworld.lua") at mod_lua.cpp:183 #23 0x00002aaab6b77e92 in lua_function (session=0x14e5bb68, data=<value optimized out>) at mod_lua.cpp:414 #24 0x00002b027ace8cd9 in switch_core_session_exec (session=0x14e5bb68, application_interface=0x2aaaac0622d8, arg=0x14e2f368 "helloworld.lua") at src/switch_core_session.c:2048 #25 0x00002b027ace9176 in switch_core_session_execute_application_get_flags (session=0xffffffffb002d5d0, app=0x14e2f360 "lua", arg=0x14e2f368 "helloworld.lua", flags=0x0) at src/switch_core_session.c:1962 #26 0x00002b027acec4ad in switch_core_session_run (session=0x14e5bb68) at src/switch_core_state_machine.c:176 #27 0x00002b027ace8720 in switch_core_session_thread (thread=<value optimized out>, obj=0x14e5bb68) at src/switch_core_session.c:1271 #28 0x0000003ce900673d in start_thread () from /lib64/libpthread.so.0 #29 0x0000003ce84d44bd in clone () from /lib64/libc.so.6 However if I run the same lua script from fs_cli it works fine. Can anyone please let me know what is going wrong when I call from the dialplan. Any help is greatly appreciated. Thanks Jyotshna require "lualdap" ld = assert (lualdap.open_simple ("192.168.2.xx")) s= ld:search { base = "ou=People,dc=voalte,dc=com" , scope="subtree", filter = 'cn=A*', attrs = { "cn", "telephoneNumber" }} for dn, attribs in s do freeswitch.consoleLog("info",""..dn.."\n"); for name, values in pairs (attribs) do -- stream:write("["..name.."] : "); --stream:write (values); --stream:write ("\n"); end end assert(ld:close())

2 2

questions on the new mod_sms
by Seven Du 07 Oct '11

07 Oct '11

Fatastic! I cannot help to try the new mod_sms, and here's some quick questions for developers and I'm seeing what can I help with testing/coding etc. to speed this up. 1) I see no event when I use the chat app "fire" with /event all in fs_cli, is there a problem or unfinished code? 2) Also I see nothing when I use the "send" app, I guess a catch all chatplan with <action application="send" data=""/> would have the same effect as before(when no mod_sms). I tried with a. unload mod_sms, two US send text messages to each other without problem b. load mod_sms, I see this log but nothing happened 2011-09-24 10:03:48.921888 [INFO] mod_sms.c:299 Processing text message 1004->1001 in context default Chatplan: 1001 parsing [default->demo] continue=false Chatplan: 1001(a)192.168.7.2 Regex (PASS) [demo] to(1001(a)192.168.7.2) =~ /^(.*)$/ break=on-false Chatplan: 1001(a)192.168.7.2 Action send() 2) How to get variables in lua? will there be an event object like session in dialplan based ? 3) also I see the chat api also hit the chatplan, is that supposed to? Sorry for so many questions, thanks. -- About: http://about.me/dujinfang Blog: http://www.dujinfang.com Proj: http://www.freeswitch.org.cn Sent with Sparrow (http://www.sparrowmailapp.com)

4 11

FreeSWITCH Conference Call Oct 5: All about git
by Michael Collins 30 Sep '11

30 Sep '11

Hello FreeSWITCHers! Travis Cross will be presenting on the subject of git. Many of us have a love-hate (or a hate-hate) relationship with git so Travis is going to help us get over the hump. The agenda page has a place where you can post questions: http://wiki.freeswitch.org/wiki/FS_weekly_2011_10_05#Featured_Presentation Looking forward to next Wednesday! -MC

1 0

mod_fifo.c question re: fifo count values
by Michael Collins 29 Sep '11

29 Sep '11

I was curious about this code snippet which appears in mod_fifo.c near line 3775 and again near line 3786: len = node_caller_count(node); switch_mutex_lock(node->update_mutex); stream->write_function(stream, "%s:%d:%d:%d\n", argv[1], node->consumer_count, node_caller_count(node), len); switch_mutex_unlock(node->update_mutex); I was curious: what's the difference in the stream->write between node_caller_count(node) and len? Under what circumstances would they be different? (I'm assuming the locking of the mutex after setting the value of len may have something to do with it...) Thanks, MC

2 1

FreeSWITCH Conference Call Today
by Michael Collins 28 Sep '11

28 Sep '11

Hello folks! We have a few items to discuss today. Here's the agenda: http://wiki.freeswitch.org/wiki/FS_weekly_2011_09_28 We have a few updates to share with everyone and we also would like to hear from you if you have been using mod_sms that just came out last week. Talk to you soon, Michael

1 0

Re: [Freeswitch-dev] MTU setting and application buffer size
by Juraj Fabo 28 Sep '11

28 Sep '11

Thank you for your answers. > ---------- Forwarded message ---------- > From: Moises Silva <moises.silva(a)gmail.com> > To: freeswitch-dev(a)lists.freeswitch.org > Date: Thu, 22 Sep 2011 16:05:06 -0400 > Subject: Re: [Freeswitch-dev] MTU setting and application buffer size > On Mon, Sep 19, 2011 at 12:30 PM, Juraj Fabo <juraj.fabo(a)gmail.com> wrote: >> Target application is reading/writing from/to another network stack >> A-law data with 20ms frame length. >> >> With default MTU settings (80) I am experiencing latency which I >> consider too high, it is about 400ms from targetApp to loopback and >> back to targetApp. > > There is something wrong with your app. The MTU in wanpipeX.conf is > meant to control the transfer size between the driver and the card, > not between the user space app and the driver. In general, higher MTU > means lower interrupt load. The lowest value is probably 8, which is > used for applications working in DAHDI-mode, where one interrupt is > received every millisecond and 8 bytes are transferred from the driver > to the hardware and viceversa. > >> I think I missed some point about proper setting of MTU and consequences. >> Decreasing the MTU configuration setting in the >> /etc/wanpipe/wanpipe1.conf from default value 80 to e.g 40 or 16 leads >> to desired lower latency, however, the data the targetApp is reading >> are often corrupted with many gaps. > > 80 means a hardware interrupt is received every 10ms with 80 bytes per > time slot. This is the recommended mode. A value of 40 will increase > interrupt load and not necesarily reduce your latency, you must reduce > the "user period", which is how often the driver will deliver > media/data to the user application. This is done using > sangoma_tdm_set_usr_period(). > >> Please, what is the proper way of setting MTU? >> I assume I have to set the same MTU per wXg1 sections in >> /etc/wanpipe/wanpipeX.conf files on both servers, since the serverA >> card is providing a clock for server B cards. >> Is it necessary to change the value of codec_ms in the >> /usr/local/freetdm/conf/wanpipe.conf ? > > The codec_ms is used to call sangoma_tdm_set_usr_period(). This is how > often the driver will deliver data to the user application (for > example, waking it up from select()). > >> I also noticed following behaviour of ifconfig: >> a. MTU set to 40 or higher in section w1g1 in wanpipe1.conf >> also all other spans of the card which has the w1g1 (so w2g1 for >> the dualspan and w2g1, w3g1,w4g1 for quad card) will be displayed in >> ifconfig output with MTU: 40 >> >> b. MTU set to 80 or higher (e.g. 160) in section w1g1 in wanpipe1.conf >> ifconfig will display MTU:80 also for higher values > > Some MTU values are disallowed, you would have to check which ones in > the driver, I don't recall. You can't use any value, as this values > are directly related with the capabilities of the hardware (some > cards, like analog cards, may only accept MTU of 8 for example). > I did set of latency / delay measurements in reduced testenvironment. Single server, single quad card with interconnected spans 1 and 2, testapplication is doing dump of read and written data on both call ends to binary files in the single thread. Please, have a look at the results with various parameters used: mtu:80 txqueue_size=1 rxqueue_size=1 one-direction delay=60ms round-trip delay=120ms mtu:80 txqueue_size=2 rxqueue_size=2 one-direction delay=80ms round-trip delay=160ms mtu:80 txqueue_size=10 rxqueue_size=10 one-direction delay=240ms round-trip delay=480ms mtu:40 txqueue_size=1 rxqueue_size=1 one-direction delay=40ms round-trip delay=80ms mtu:40 txqueue_size=2 rxqueue_size=2 one-direction delay=60ms round-trip delay=120ms mtu:40 txqueue_size=5 rxqueue_size=5 one-direction delay=120ms round-trip delay=240ms mtu:16 txqueue_size=1 rxqueue_size=1 one-direction delay=30ms round-trip delay=60ms mtu:8 txqueue_size=1 rxqueue_size=1 one-direction delay=25ms round-trip delay=50ms mtu:8 txqueue_size=10 rxqueue_size=10 one-direction delay=205ms round-trip delay=410ms The result from these tests is that the rxqueue_size is affecting the delay and no matter what is the MTU chunk size, increasing the rxqueue_size by one will increase the one-direction delay by 20ms. I also realized, that assymetric setting of tx/rx queue size can be used: e.g. tx_q_s=1 rx_q_s=10 to reduce the delay. Comment in the wanpipe.conf says: ; size of the driver queue of elements of MTU size ; typical case is 10 elements of 80 bytes each (10ms of ulaw/alaw) ; don't mess with this if you don't know what you're doing but I had not seen 80 bytes per element in the logs. With enabled DEBUG_TDMAPI following can be seen: Sep 27 20:02:34 v184 kernel: [2806213.900348] wanpipe1: Configuring Interface: w1g1 (log supress) Sep 27 20:02:34 v184 kernel: [2806213.900355] wanpipe1: Active Ch Map :0x00000004 Sep 27 20:02:34 v184 kernel: [2806213.900357] wanpipe1: First TSlot :2 Sep 27 20:02:34 v184 kernel: [2806213.900366] w1g1: TDM API ACTIVE CH 0x00000004 CHAN=2 Sep 27 20:02:34 v184 kernel: [2806213.900368] w1g1: TDM API ACTIVE CH 0x00000004 SPAN=1 CHAN=2 Sep 27 20:02:34 v184 kernel: [2806213.900370] w1g1: SPAN=1, CHAN=2 Chunk=80 Period=10 Mtu=80 Sep 27 20:02:34 v184 kernel: [2806213.900371] w1g1: conf->mtu=0 Sep 27 20:02:34 v184 kernel: [2806213.900372] w1g1: tdm_api_chunk=80, tdm_api_period=10 Sep 27 20:02:34 v184 kernel: [2806213.900374] wanpipe1: Chunk=160, Period=20, MTU=160 Sep 27 20:02:34 v184 kernel: [2806213.900398] wanpipe_tdm_api_reg(): usr_period: 20, hw_mtu_mru: 8 Sep 27 20:02:34 v184 kernel: [2806213.900400] wanpipe1: Configuring TDM API NAME=wanpipe1_if2 Qlen=5 TS=1 MTU=224 Here I found interesting these 2lines: Sep 27 20:02:34 v184 kernel: [2806213.900374] wanpipe1: Chunk=160, Period=20, MTU=160 Sep 27 20:02:34 v184 kernel: [2806213.900398] wanpipe_tdm_api_reg(): usr_period: 20, hw_mtu_mru: 8 which are result of the aft_core_prot.c 721 if (chan->wp_tdm_api_dev->cfg.usr_mtu_mru < 160) { 722 chan->tdm_api_period=20; 723 chan->wp_tdm_api_dev->cfg.usr_period=20; 724 chan->tdm_api_chunk=160; 725 chan->wp_tdm_api_dev->cfg.usr_mtu_mru=160; 726 } As I understand it, this chan->tdm_api_period=20 and chan->tdm_api_chunk=160 is the reason of 20ms increase interval measured in my tests. >> Finally, I tried to access the card more often than the default 20ms >> with default MTU:80 >> Since 80Bytes is 10ms, application was configured to read/write on >> 10ms rate with 80Bytes buffer. >> Following pseudocode ftdm_channel_read(fchan, bufferPtr, 80) failed >> with kernel error message in dmesg coming from wanpipe_tdm_api.c >> "User API Error: User Rx Len=144 < Driver Rx Len=224 (hdr=64). User >> API must increase expected rx length" >> Does it mean, that the smallest buffer used in the ftdm_channel_read() >> must be at least 160 B length even if MTU is 80 (or less) ? > > I suspect you changed the MTU to 80 but not the codec_ms to 10. If I > were you I'd stop messing around with the MTU unless you're willing to > look at the Wanpipe driver code. Not all values are meant to work for > all hardware and there are many types of hardware and many modes (API > mode, span mode, DAHDI mode etc) that can get complex to get right. > > Setting MTU to 80 (the default for TDM API mode) and codec_ms to 10 > you should not have latency bigger than 10ms. If you do, there is > something wrong with your app. The best I achieved with MTU:80 was by using txqueue_size=1 and this resulted in 60ms one-direction latency. Results were the same with wanpipe-3.5.20 and wanpipe-3.5.23. With best regards Juraj Fabo > > Moises Silva > Senior Software Engineer, Software Development Manager > Sangoma Technologies Inc. | 100 Renfrew Drive, Suite 100, Markham ON > L3R 9R6 Canada > t. 1 905 474 1990 x128 | e. moy(a)sangoma.com

1 1

A Chance To "Give Back" To FreeSWITCH
by Michael Collins 27 Sep '11

27 Sep '11

Hello all, I have a few FreeSWITCH-related projects with which I could use a hand. We have some non-glamorous janitorial items that need some attention. Specifically I could use assistance with a few freeswitch.org and wiki.freeswitch.org items. Some research/digging for answers is involved. If you have PHP skills those are a plus. Please email me off list if you are able to devote a few hours to some projects that I have pending. We will also discuss some of these on the FreeSWITCH conference call tomorrow. Thanks for giving back <http://www.freeswitch.org/node/339>. -Michael Collins

1 0

MTU setting and application buffer size
by Juraj Fabo 22 Sep '11

22 Sep '11

Hi, I'm writing and application using freetdm library and also a testtool which works as a loopback for voice data on B channels. Server A is running the loopback test tool is with a104d sangoma card configured in NET mode simulating telko infrastructure, clock on each span set to MASTER. Server B is running target aplication with 2 a102de cards configured in CPE mode and clock on each span is set to NORMAL. Spans of two serversSpans are connected with E1 cables, both servers running in sles11 sp1. Target application is reading/writing from/to another network stack A-law data with 20ms frame length. With default MTU settings (80) I am experiencing latency which I consider too high, it is about 400ms from targetApp to loopback and back to targetApp. I think I missed some point about proper setting of MTU and consequences. Decreasing the MTU configuration setting in the /etc/wanpipe/wanpipe1.conf from default value 80 to e.g 40 or 16 leads to desired lower latency, however, the data the targetApp is reading are often corrupted with many gaps. Please, what is the proper way of setting MTU? I assume I have to set the same MTU per wXg1 sections in /etc/wanpipe/wanpipeX.conf files on both servers, since the serverA card is providing a clock for server B cards. Is it necessary to change the value of codec_ms in the /usr/local/freetdm/conf/wanpipe.conf ? I also noticed following behaviour of ifconfig: a. MTU set to 40 or higher in section w1g1 in wanpipe1.conf also all other spans of the card which has the w1g1 (so w2g1 for the dualspan and w2g1, w3g1,w4g1 for quad card) will be displayed in ifconfig output with MTU: 40 b. MTU set to 80 or higher (e.g. 160) in section w1g1 in wanpipe1.conf ifconfig will display MTU:80 also for higher values Finally, I tried to access the card more often than the default 20ms with default MTU:80 Since 80Bytes is 10ms, application was configured to read/write on 10ms rate with 80Bytes buffer. Following pseudocode ftdm_channel_read(fchan, bufferPtr, 80) failed with kernel error message in dmesg coming from wanpipe_tdm_api.c "User API Error: User Rx Len=144 < Driver Rx Len=224 (hdr=64). User API must increase expected rx length" Does it mean, that the smallest buffer used in the ftdm_channel_read() must be at least 160 B length even if MTU is 80 (or less) ? Thank you very much Juraj

2 1