Juan Antonio Alvarez wrote:
> On 1/25/07, flavio <[EMAIL PROTECTED]> wrote:
>   
>>> Does this happen after you started several sipp
>>> with the same command line arguments or does it happen just from start?
>>>       
>> A problem happen from start after several calls are generated
>> (tipically from 20 to 30 calls).
>> I have modified uac_pcap.xml file download from
>> http://sipp.sourceforge.net as follows:
>>
>> !-- Play a pre-recorded PCAP file (RTP stream)                       -->
>>   <nop>
>>     <action>
>>       <exec play_pcap_audio="pcap/g711a_moh.pcap"/>
>>     </action>
>>   </nop>
>>
>>   <!-- Pause 20 seconds, which is approximately the duration of the      -->
>>   <!-- PCAP file                                                        -->
>>   <pause milliseconds="20000"/>
>>
>> where g711a_moh.pcap is a pcap rtp stream audio dumped by Ethereal.
>>
>>
>>     
>>> Does  SIPp default pcap scenario works well "off the shelf"?
>>>       
>> SIPp defaul uac_pcap scenario does work very well!!
>>
>>
>> Maybe message error is related to my own uac_pcap.xml file?
>>
>>
>> --
>> ********************************
>> * (o<     ing. Patria Flavio
>> * //\      phone 0823451358
>> * V_/_  mobile 3407873357
>> *
>> ********************************
>>
>>     
>
> The weird thing is that it doesn't look like a scalability problem,
> judging from the error...
>
> I think I got an error like that once, but it happened just from the
> start. It was temporarily solved by using the -i [local_ip] option. It
> was an issue with my system back then. But you can try it out, just in
> case.
>
> Also, instead of modifying the file from the docs, try modifying the
> one you get when running
>
> ./sipp -sd uac_pcap
>
> since the docs could be a little outdated.
>
> If none of that work, send back the command you use to run sipp. It
> could give us something.
>
> Good luck,
>
> Juan
>
>   

Agree with Juan's advices, always start from the embedded scenario. From 
my experience, the limits I have been able to reach with pcap play 
feature and the embedded scenario is:
130 calls/s with scenarios of ~9s duration. That's around 1,200 
simultaneous calls. Because of G711 usage, this is also around the limit 
of the 100Mb ethernet link I was using.
 From the command line, it looks that you are on the safe side (have you 
looked at "top"?)
just as reminder, the CLI you used:

 ./sipp -sf uac_pcap.xml -f 60 -d 25000 -s 123 10.28.52.110 -r 10 -rp
30 -rate_increase 5 -fd 30 -l 200 -mi 10.28.22.183 -mp 5606 -i
10.28.22.183 -trace_screen -trace_stat -trace_err

And yes, I agree that the sendto error with invalid argument is kind of 
weird...

pcap play is great to reproduce media streams that have been recorded. 
But SIPp will be better having an additional true RTP/media stack. 
Having both capabilities would be great.
I'm thinking of pjmedia (GPL) which offers nice capabilities like wav 
play and record, echo cancellation, DTMF RFC 2833 support. I thought I 
would have time to look at this but I don't. It doesn't look like a big 
task, but still... Anyone interested?

-- 
Olivier
HP OpenCall Software
http://www.hp.com/go/opencall/


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users

Reply via email to