Anthony Minessale wrote: > FS uses async rtp timers so you may want to set rtp-timer-name=none in > the profile param to simulate asterisk conditions.
I tried that - although I am not using rtp in my scenario - with the same results. > Also keep in mind that asterisk as an atvantage in a tiny crappy 32 bit > single cpu box because that was what was popular when it was designed > and the chance for race conditions is minimal because there is only 1 > cpu. As you scale up to a 8 core 64 bit xeon you will set a drastic > difference. Yes I know that this machine is not well suited for today's test needs. But the issue occurs in every machine as long as it is pushed near (but not quite near) to its limits. I have the same odd durations using a 64 bit low end server. In this case I could achieve a better call/sec rate than that of the crappy PC but around 50-60 calls/sec the same problem showed up. I also used a Mosso Cloud Server (quad core - 64-bit) and the same thing happened at a higher rate. > > I will be happy to investigate this issue a bit if you'd like but i do > not have any box like you describe so if I can't find anything > you may have to lend us your lab. I would appreciate it if you did. After all there this might be a problem that has not surfaced yet but someday will as more and more production boxes start using FS. So it would be better to investigate it now. I don't think lending you access to my old P4 PC would help you very much :) If you have access to a normal 2-4 core system you can easily start raising the sipp parameters until it starts happening. However if you really think it is appropriate to use my test machines I'd be happy to grant access to our low-end Opteron machine (just send me a personal email). I cannot grant you access to larger systems because they are used in production. I used the embedded sipp scenarios : on the UAS side : sipp -i <UAS_IP> -mi <UAS_IP> -ci <UAS_IP> -mp 8000 -sn uas on the UAC side : sipp <FS_IP>:5060 -s 44050505-i <UAC_IP> -mi <UAC_IP> -ci <UAC_IP> -r 70 -d 5000 -l 500 -m 2000 -sn uac The dialplan : <?xml version="1.0" encoding="utf-8"?> <!-- http://wiki.freeswitch.org/wiki/Dialplan_XML --> <include> <context name="mydialplan"> <extension name="dial1"> <condition field="destination_number" expression="(^.*)$"> <!-- Dial Back --> <action application="set" data="absolute_codec_string=PCMU"/> <!-- <action application="set" data="proxy_media=true"/> --> <action application="bridge" data="sofia/gateway/sipp01/$1"/> </condition> </extension> </context> </include> If you need anything else from the config just notify me. In order to verify that at some point the calls start having a duration larger than the scenario's 5secs you can tcpdump on the sipp machine or turn on the cdrs logging (I know that it degrades performance, but as I said it is not a matter of when exactly it starts happening, it is a matter that it DOES start happening). > > > On Thu, Jun 4, 2009 at 12:47 PM, [email protected] > <mailto:[email protected]> <[email protected] <mailto:[email protected]>> wrote: > > Michael Collins wrote: > > > > > > The dialplan : > > > > <?xml version="1.0" encoding="utf-8"?> > > <!-- http://wiki.freeswitch.org/wiki/Dialplan_XML --> > > <include> > > > > <context name="mydialplan"> > > <extension name="dial1"> > > <condition field="destination_number" > > expression="^.*$"> > > > > > > You forgot the parens around .* > > It should be expression="^(.*)$" if you plan to use $1 later in the > > extension... > > > > > > > > <!-- Dial Back --> > > <action application="set" > > data="absolute_codec_string=PCMA"/> > > <action application="bridge" > > data="sofia/gateway/sipp01/$1"/> > > > > ... like here ^^^^^^^ > > :) > > -MC > > You are right! Although, I don't think that would change the outcome of > my test :) > > > > > > > > </condition> > > </extension> > > </context> > > > > </include> > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Freeswitch-users mailing list > > [email protected] > <mailto:[email protected]> > > 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 > [email protected] > <mailto:[email protected]> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org > > > > > -- > Anthony Minessale II > > FreeSWITCH http://www.freeswitch.org/ > ClueCon http://www.cluecon.com/ > > AIM: anthm > MSN:[email protected] > <mailto:msn%[email protected]> > GTALK/JABBER/PAYPAL:[email protected] > <mailto:paypal%[email protected]> > IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch > > FreeSWITCH Developer Conference > sip:[email protected] > <mailto:sip%[email protected]> > iax:[email protected]/888 > <http://iax:[email protected]/888> > googletalk:[email protected] > <mailto:googletalk%3aconf%[email protected]> > pstn:213-799-1400 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Freeswitch-users mailing list > [email protected] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users > http://www.freeswitch.org -- ------------------------------------------- Apostolos Pantsiopoulos Kinetix Tele.com R & D email: [email protected] ------------------------------------------- _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
