Funny thing... I offered to pay for a fix for this bug by sending a mail to <a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a>,
but nobody responded. Now I spent some of that money reimplementing the
ivr in javascript. The rest is still there if somebody wants it :-)<br>
<br>Regarding pythonistas and stake burnings - I just want the humongous number of libraries that come with python.<br><br>I agree with David - pieces that aren't quite production ready should be marked as such.<br><br>
Regards,<br>Kresho<br><br><div class="gmail_quote">On Fri, Jun 13, 2008 at 7:05 PM, Brian West <<a href="mailto:brian@freeswitch.org">brian@freeswitch.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also let me just say one last thing here.. As long as their is a bug<br>
on Jira about this issue we will get around to it... it's just not a<br>
top priority right now.<br>
<font color="#888888"><br>
/b<br>
</font><div class="Ih2E3d"><br>
On Jun 13, 2008, at 10:49 AM, David Knell wrote:<br>
<br>
</div><div><div></div><div class="Wj3C7c">> Hi Brian,<br>
><br>
>> David,<br>
>> It has to work? We have people running millions of min. a day thru<br>
>> FreeSWITCH and they have zero issues.<br>
><br>
> Yes, but that misses the point. They run millions of minutes<br>
> through a<br>
> well-tested subset of that which FS offers - we ran half a million<br>
> mins<br>
> a day during May through a couple of FS boxes with the odd corrupt<br>
> CDR and occasional barf[1].<br>
><br>
> But that doesn't mean that FS works in its entirety. It means that it<br>
> can<br>
> be made to work, which is a very different thing.<br>
><br>
>> If you have to add the module<br>
>> to modules.conf and compile it.. that is outside the scope of what is<br>
>> well tested and supported. Lua is more tested but still isn't in the<br>
>> default yet. That might happen in <a href="http://1.0.1." target="_blank">1.0.1.</a><br>
><br>
> Here's the solution, then. Someone who knows the answers could<br>
> document the module status in modules.conf; that way, anyone who<br>
> adds a less-well-supported module to their build will at least know<br>
> about it. As a quick aside, mod_xml_curl isn't in the default build;<br>
> it is OK for production use, isn't it..?!<br>
><br>
>> By the tone of your comments you're going to take mod_python under<br>
>> your wing and make sure it works? We do need more people to step up<br>
>> and help. ;)<br>
><br>
> No, I'm not, I'm afraid - (a) I've too much on my plate to have a<br>
> meaningful stab at it, and (b) I'm quite happy with curly brackets to<br>
> indicate where my blocks start and end. But if anyone wants a hand<br>
> with writing IVRs or doing call routing using event sockets and Perl,<br>
> I'd<br>
> be very happy to help.<br>
><br>
> --Dave<br>
><br>
> [1] Mindful of the possibility of having already offended the<br>
> Pythonistas<br>
> by disrespecting whitespace as a syntactic tool, I probably shouldn't<br>
> add that the * boxes which front-end that traffic worked without a<br>
> glitch,<br>
> less I find myself on the wrong end of a stake, a gallon of petrol, a<br>
> pile<br>
> of wood and a match ;-)<br>
><br>
><br>
>><br>
>><br>
>> /b<br>
>><br>
>> On Jun 13, 2008, at 9:34 AM, David Knell wrote:<br>
>><br>
>>> Yes, but..<br>
>>><br>
>>> Neither of Kresho's boxes are registering heavy CPU usage, which is<br>
>>> what<br>
>>> one would expect if this were to do with the overhead of Python. In<br>
>>> addition,<br>
>>> there's the crashes.<br>
>>><br>
>>> On to a hobby horse of mine. If FS is going to make it in the real<br>
>>> world, then<br>
>>> it has to work. And that means that the bits which come with it<br>
>>> need<br>
>>> to work,<br>
>>> and those which don't need to be separated off into a 'beta', 'don't<br>
>>> expect<br>
>>> much from this', 'FFS don't use unless you're prepared to fix it' or<br>
>>> whatever<br>
>>> repository.<br>
>>><br>
>>> New users, such as Kresho, will use whichever scripting tool/<br>
>>> language/<br>
>>> interface suits their needs and that they're familiar with. And<br>
>>> they'll have the<br>
>>> expectation that it'll work, and that expectation is perfectly<br>
>>> reasonable.<br>
>>> Keeping bits in the "release" source tree which don't work properly<br>
>>> or<br>
>>> which<br>
>>> have failings which make them unsuitable for production use does FS<br>
>>> (which is a great thing) a disservice.<br>
>>><br>
>>> Cheers --<br>
>>><br>
>>> Dave<br>
>>><br>
>>>> Python is very heavy.. You should try lua.<br>
>>>><br>
>>>> /b<br>
>>>><br>
>>>> On Jun 12, 2008, at 5:29 AM, Krešimir Tonković wrote:<br>
>>>><br>
>>>>> Hi!<br>
>>>>><br>
>>>>> I'm new to freeswitch and I like to report my success with it<br>
>>>>> and a<br>
>>>>> few failures. I'll be a little bit vague on some details because I<br>
>>>>> must protect some business details. Sorry for that.<br>
>>>>><br>
>>>>> I have no experience with asterisk, so many concepts were new to<br>
>>>>> me.<br>
>>>>><br>
>>>>> We run a hosted IVR system with a few hundred lines. We have a few<br>
>>>>> servers running a SIP/VoiceXML application server and connect to<br>
>>>>> the<br>
>>>>> network with SIP/ISDN gateways.<br>
>>>>><br>
>>>>> Recently we started an IVR with very short calls and very high<br>
>>>>> CPS.<br>
>>>>> Our existing software doesn't handle this scenario very well, so I<br>
>>>>> started looking into alternatives.<br>
>>>>><br>
>>>>> FreeSwitch caught my eye because of its support for multiple<br>
>>>>> scripting languages. I love python and this feature put FS into<br>
>>>>> the<br>
>>>>> evaluation list. So I started on friday. I installed FS from the<br>
>>>>> debian repositories on my ubuntu 8.04 laptop and tried some<br>
>>>>> examples<br>
>>>>> from the wiki ("Some thing to try out!"). I was very impressed<br>
>>>>> that<br>
>>>>> everything worked right out of the box.<br>
>>>>><br>
>>>>> I was a little disappointed that mod_python wasn't included in the<br>
>>>>> distribution so I checked out the source and compiled everything.<br>
>>>>> An<br>
>>>>> hour later I had another installation of FS.<br>
>>>>><br>
>>>>> It took me a few hous to get the dialplan right. Because our<br>
>>>>> service<br>
>>>>> only runs IVRs and uses no switching, I removed everything from<br>
>>>>> the<br>
>>>>> default dialplan (mainly because it conflicted with the ANI<br>
>>>>> numbers<br>
>>>>> we get from the gateways).<br>
>>>>><br>
>>>>> Another hour later, I had a simple IVR in python done: use a web<br>
>>>>> service for a database lookup and play an appropriate prompt. I<br>
>>>>> didn't use the database directly because I wanted the best<br>
>>>>> possible<br>
>>>>> comparison to what our current system does, and (our) VoiceXML<br>
>>>>> can't<br>
>>>>> use databases directly, but can use web services.<br>
>>>>><br>
>>>>> In less than 1 working day I had everything running. Quite good.<br>
>>>>><br>
>>>>> Time for load testing :-) Our old software handles around 20 CPS<br>
>>>>> on<br>
>>>>> my laptop. I inceased max_sessions to 5000 and sessions-per-second<br>
>>>>> to 100 and started sipp. The result was quite bad - I could not<br>
>>>>> get<br>
>>>>> over 8 CPS! The processor barely noticed that FS was running, so I<br>
>>>>> had no idea what the bottleneck was. I still don't. After fiddling<br>
>>>>> with this for a while, I gave up and decided to try it on one of<br>
>>>>> our<br>
>>>>> production machines. Weekends are not very busy, so I took one<br>
>>>>> offline. It's a HP proliant server with 1 quad-core xeon on 2 GHz,<br>
>>>>> 2G ecc ram and 10krpm disks. The server is also running ubuntu<br>
>>>>> 8.04<br>
>>>>> (server edition) so I just copied the binaries.<br>
>>>>><br>
>>>>> I ran sipp from another machine, with the uac scenario and<br>
>>>>> limiting<br>
>>>>> the call duration to 4secs:<br>
>>>>> sipp <FS server ip> -sn uac -d 4000 -s <ivr_number><br>
>>>>> Theoretically, as each call lasts 4 seconds, the total calls<br>
>>>>> number<br>
>>>>> should never exceed 4x current CPS.<br>
>>>>><br>
>>>>> These are the results:<br>
>>>>><br>
>>>>> With up to 27 CPS everything was stable. The calls count was<br>
>>>>> almost<br>
>>>>> exactly 4 timee the CPS, indicating that new calls were ansewered<br>
>>>>> immediately. This I also verified by calling in.<br>
>>>>><br>
>>>>> Up to 30 CPS everything was stable for a while, but then the total<br>
>>>>> calls number exploded to the limit set by sipp. The processor load<br>
>>>>> was very reasonable, so I again I ran into the bottleneck<br>
>>>>> mentioned<br>
>>>>> above. After sipp hits the total call limit, it will not create<br>
>>>>> new<br>
>>>>> calls until some are released. So CPS oscillated between 0 and 30<br>
>>>>> as<br>
>>>>> shown by sipp. CDRs show that there was an average of 27 CPS. At<br>
>>>>> this point, when I called in, I got ringback tone for as long as<br>
>>>>> the<br>
>>>>> operator allows (60s) and then I was dropped. With a softphone I<br>
>>>>> could reach the IVR after about 80 sec.<br>
>>>>><br>
>>>>> When I set sipp to more than 30 CPS, the number of total calls<br>
>>>>> exploded immediately.<br>
>>>>><br>
>>>>> Experimenting some more, I found I could contain the explosion<br>
>>>>> (and<br>
>>>>> the instability in CPS) by limiting the number of total calls to<br>
>>>>> 4x<br>
>>>>> current cps when cps was up to 30. Thus, by starting sipp like<br>
>>>>> this:<br>
>>>>> sipp <FS server ip> -sn uac -d 4000 -s <ivr_number> -l 120<br>
>>>>> I could go up to 30CPS and get reasonably stable real 30CPS. When<br>
>>>>> calling in with a real phone, I would reach the IVR after 2-3<br>
>>>>> seconds of ringback, which is acceptable. This simulation run for<br>
>>>>> several hours without any other problems.<br>
>>>>><br>
>>>>> With<br>
>>>>> sipp <FS server ip> -sn uac -d 4000 -s <ivr_number> -l 160<br>
>>>>> and setting cps to 40, the total calls count obviously never<br>
>>>>> passed<br>
>>>>> 160, but the cps shown by sipp became unstable, oscillating<br>
>>>>> between<br>
>>>>> 0 and 40.<br>
>>>>><br>
>>>>> These results are only slightly better than our current SIP<br>
>>>>> server.<br>
>>>>><br>
>>>>> Today I put FreeSwitch into production. The unexpected thing here<br>
>>>>> was that when FreeSwitch talked to our gateways instead of sipp,<br>
>>>>> it<br>
>>>>> crashed a few times. I don't associate these crashes with load<br>
>>>>> because it happened equally on low and high load. Here's the log:<br>
>>>>><br>
>>>>> 2008-06-09 09:34:33 [NOTICE] switch_core_session.c:753<br>
>>>>> switch_core_session_thread() Session 166 (sofia/internal/----<br>
>>>>> deleted stuff -----) Ended<br>
>>>>> 2008-06-09 09:34:33 [NOTICE] switch_core_session.c:755<br>
>>>>> switch_core_session_thread() Close Channel sofia/internal/----<br>
>>>>> deleted stuff ----- [CS_HANGUP]<br>
>>>>> 2008-06-09 09:34:33 [CRIT] switch_core_state_machine.c:218<br>
>>>>> print_trace() Obtained 10 stack frames.<br>
>>>>> /usr/local/freeswitch/lib/libfreeswitch.so.1 [0xb7e413b1]<br>
>>>>> [0xb7f69420]<br>
>>>>> /usr/local/freeswitch/mod/mod_python.so [0xb011b46a]<br>
>>>>> /usr/lib/libpython2.5.so.1.0(PyCFunction_Call+0xfa) [0xb002a50a]<br>
>>>>> /usr/lib/libpython2.5.so.1.0(PyObject_Call+0x37) [0xafff38d7]<br>
>>>>> /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x4067)<br>
>>>>> [0xb0076907]<br>
>>>>> /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x748) [0xb007a368]<br>
>>>>> /usr/lib/libpython2.5.so.1.0(PyEval_EvalFrameEx+0x601c)<br>
>>>>> [0xb00788bc]<br>
>>>>> /usr/lib/libpython2.5.so.1.0(PyEval_EvalCodeEx+0x748) [0xb007a368]<br>
>>>>> /usr/lib/libpython2.5.so.1.0 [0xb001667f]<br>
>>>>> 2008-06-09 09:34:33 [CRIT] switch_core_state_machine.c:319<br>
>>>>> switch_core_session_run() Thread has crashed for channel sofia/<br>
>>>>> internal/---- deleted stuff -----<br>
>>>>><br>
>>>>> It seems like mod_python is not quite ready for production<br>
>>>>> yet :-) I<br>
>>>>> have a few core dumps available on demand, cca 2MB each.<br>
>>>>><br>
>>>>> Turning crash protection on didn't help. FreeSwitch would reject<br>
>>>>> new<br>
>>>>> calls, and wouldn't shutdown completely. I had to kill it.<br>
>>>>><br>
>>>>> I would still like to replace our existing system with FreeSwitch<br>
>>>>> because I find way more comfortable to work with. It has great<br>
>>>>> potential and I'm sure it is being succesully deployed in many<br>
>>>>> places as I write this.<br>
>>>>><br>
>>>>> The python crash is probably a simple bug. The invisible<br>
>>>>> bottleneck<br>
>>>>> is what troubles me more. Any help would be greatly appreciated.<br>
>>>>><br>
>>>>> Finally, this is all with FreeSwitch Version 1.0.pre4 (8760).<br>
>>>>> --<br>
>>>>> kresho<br>
>>>>> _______________________________________________<br>
>>>>> Freeswitch-users mailing list<br>
>>>>> <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
>>>>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>>>>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>>>>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> Freeswitch-users mailing list<br>
>>>> <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
>>>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>>>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>>>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Freeswitch-users mailing list<br>
>>> <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
>>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>><br>
>> Brian West<br>
>> <a href="mailto:sip%3Abrian@freeswitch.org">sip:brian@freeswitch.org</a><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Freeswitch-users mailing list<br>
>> <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
><br>
> _______________________________________________<br>
> Freeswitch-users mailing list<br>
> <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br>
Brian West<br>
<a href="mailto:sip%3Abrian@freeswitch.org">sip:brian@freeswitch.org</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>kresho