Re: [Sipp-users] How to use sipp in windows ?
Hi, This exe which was available unfortunately wasn't supporting pcap play. You can try the latest exe available (3.1.1) . Regards Anuj -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Sent: Friday, May 30, 2008 7:45 AM To: Sipp-users@lists.sourceforge.net Subject: [Sipp-users] How to use sipp in windows ? Hi, all This below is the xml scenario file I'm using . = ?xml version=1.0 encoding=ISO-8859-1 ? !DOCTYPE scenario SYSTEM sipp.dtd !-- This program is free software; you can redistribute it and/or -- !-- modify it under the terms of the GNU General Public License as -- !-- published by the Free Software Foundation; either version 2 of the -- !-- License, or (at your option) any later version.-- !---- !-- This program is distributed in the hope that it will be useful,-- !-- but WITHOUT ANY WARRANTY; without even the implied warranty of -- !-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -- !-- GNU General Public License for more details. -- !---- !-- You should have received a copy of the GNU General Public License -- !-- along with this program; if not, write to the -- !-- Free Software Foundation, Inc.,-- !-- 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA -- !---- !-- Sipp 'uac' scenario with pcap (rtp) play -- !---- scenario name=UAC with media !-- In client mode (sipp placing calls), the Call-ID MUST be -- !-- generated by sipp. To do so, use [call_id] keyword.-- send retrans=500 ![CDATA[ INVITE sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: [field0] sip:[EMAIL PROTECTED]:[local_port];tag=[call_number] To: [field1] sip:[EMAIL PROTECTED]:[remote_port] Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:[EMAIL PROTECTED]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len] v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=- c=IN IP[local_ip_type] [local_ip] t=0 0 m=audio [auto_media_port] RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 ]] /send recv response=407 auth=true /recv !-- By adding rrs=true (Record Route Sets), the route sets -- !-- are saved and used for following messages sent. Useful to test -- !-- against stateful SIP proxies/B2BUAs. -- !-- Packet lost can be simulated in any send/recv message by -- !-- by adding the 'lost = 10'. Value can be [1-100] percent. -- send ![CDATA[ ACK sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: [field0] sip:[EMAIL PROTECTED]:[local_port];tag=[call_number] To: [field1] sip:[EMAIL PROTECTED]:[remote_port][peer_tag_param] Call-ID: [call_id] CSeq: 1 ACK Contact: sip:[EMAIL PROTECTED]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ]] /send send retrans=500 ![CDATA[ INVITE sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port] From: [field0] sip:[EMAIL PROTECTED]:[local_port];tag=[call_number] To: [field1] sip:[EMAIL PROTECTED]:[remote_port] Call-ID: [call_id] CSeq: 2 INVITE Contact: sip:[EMAIL PROTECTED]:[local_port] [field2] Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len] v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=- t=0 0 c=IN IP[media_ip_type] [media_ip] m=audio [auto_media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 ]] /send recv response=100 optional=true /recv recv response=180 optional=true /recv recv response=200 rtd=true crlf=true /recv !-- Play a pre-recorded PCAP file (RTP stream) -- nop action exec play_pcap_audio=pcap/g711a.pcap/ /action /nop !-- Pause 8 seconds, which is approximately the duration of the -- !-- PCAP file-- pause milliseconds=5000/ !-- Play an out of band DTMF '1' '2' '3' '4' '5' '6' '7' '8' '9' '*' -- nop action exec
[Sipp-users] Problem with 3PCC Extended scenarios
I have a fairly complicated set of 3PCC Extended scenario files. I have
a master SIPp instance that talks to a Network SIP Server (whose only
job is to determine which of a number of Premise SIP Servers to send a
call to) and receives a 302 Moved Permanently. The master scenario
then determines the appropriate Premise SIP Server endpoint address from
the contact header in the 302 message and sends the information to the
appropriate slave SIPp instance (Using SendCmd), each of which is
connected to a different Premise Sip Server. When the master sends a
message to the slave, it is then finished its work and can exit, but if
it does exit, the slaves die. To remedy this I tried placing a recvCmd
in the master and added a sendCmd in the slave that will signal the
master when the call has completed.
The problem is, that If we put a SendCmd in the master followed by a
recvCmd so we will be notified when the slave's call has completed, the
call rate is very low (Essentially, 1 call goes to each slave and no
more calls are generated until those calls have completed). By removing
the recvCmd from the master and replacing it with a pause of 60 seconds
(Call duration is a little less than 60 seconds), we see the calls
processed at the rate we expect (10 calls / sec default or whatever we
put in -r and -rp). A pause of only 1 second causes the same problem as
no pause.
Inserting a pause of appropriate duration does make the problem go away,
but the problem with this is that we don't know how long the calls will
be processed by the slave. When no agents are available the calls are
queued and could be in the queue for a while. This makes it difficult to
predict how long to make the pause , and we don't want to put in
something ridiculously large. The question is - why does adding a
recvCmd in the master and a sendCmd in the slave cause this behaviour?
I have attached the shell scripts, the 3PCC Extended config files and
the scenario files.
They are called in the following order:
callGeneratorToPremiseSIPServer-1.sh
callGeneratorToPremiseSIPServer-2.sh
callGeneratorToNetworkSIPServer.sh
thanks for any help you can give,
Michael Lynch
---
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
confidential and proprietary information of Alcatel-Lucent and/or its
affiliated entities. Access by the intended recipient only is authorized. Any
liability arising from any party acting, or refraining from acting, on any
information contained in this e-mail is hereby excluded. If you are not the
intended recipient, please notify the sender immediately, destroy the original
transmission and its attachments and do not disclose the contents to any other
person, use it for any purpose, or store or copy the information in any medium.
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or
its affiliated entities.
callGeneratorToPremiseSIPServer-2.sh
Description: callGeneratorToPremiseSIPServer-2.sh
slave.cfg
Description: slave.cfg
slave-1.cfg
Description: slave-1.cfg
slave-2.cfg
Description: slave-2.cfg
callGeneratorToNetworkSIPServer.sh
Description: callGeneratorToNetworkSIPServer.sh
?xml version=1.0 encoding=ISO-8859-1?
!DOCTYPE scenario SYSTEM sipp.dtd
scenario name=Initial call into Network SIP Server
send retrans=2000
![CDATA[
INVITE sip:[EMAIL PROTECTED]:[remote_port] SIP/2.0
Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
From: sipp sip:[EMAIL PROTECTED]:[local_port];tag=[call_number]
To: sut sip:[EMAIL PROTECTED]:[remote_port]
Call-ID: [call_id]
CSeq: 1 INVITE
Contact: sip:[EMAIL PROTECTED]:[local_port]
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: [len]
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=SIPPLOADGENERATOR
c=IN IP[local_ip_type] [local_ip]
t=0 0
m=audio [auto_media_port] RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11,16
]]
/send
nop
action
log message=[clock_tick] - Invite sent - waiting for response./
/action
/nop
recv response=100 optional=true
/recv
recv response=180 optional=true retrans=1000
/recv
recv response=302
action
ereg regexp=.* search_in=hdr header=Call-ID: assign_to=1/
ereg regexp=.* search_in=hdr header=Contact: assign_to=6/
ereg regexp=([0-9]{1,3}\.){3}([0-9]{1,3})(:{0,1})([0-9]{0,5}) search_in=hdr header=Contact: assign_to=7/
/action
/recv
!-- Packet lost can be simulated in any send/recv message by --
!-- by adding the 'lost = 10'. Value can be [1-100] percent. --
send
Re: [Sipp-users] Problem with 3PCC Extended scenarios
Michael, My guess is that you are bumping into an open-call limit on the master. You can remove that with -l 0 and it will follow the correct rate for you. If that doesn't work (or if it does) let me know, and I'll try looking at your scenarios and scripts in more detail. Charles [EMAIL PROTECTED] wrote on 05/30/2008 01:54:25 PM: I have a fairly complicated set of 3PCC Extended scenario files. I have a master SIPp instance that talks to a Network SIP Server (whose only job is to determine which of a number of Premise SIP Servers to send a call to) and receives a ?302 Moved Permanently?. The master scenario then determines the appropriate Premise SIP Server endpoint address from the contact header in the 302 message and sends the information to the appropriate slave SIPp instance (Using SendCmd), each of which is connected to a different Premise Sip Server. When the master sends a message to the slave, it is then finished its work and can exit, but if it does exit, the slaves die. To remedy this I tried placing a recvCmd in the master and added a sendCmd in the slave that will signal the master when the call has completed. The problem is, that If we put a SendCmd in the master followed by a recvCmd so we will be notified when the slave?s call has completed, the call rate is very low (Essentially, 1 call goes to each slave and no more calls are generated until those calls have completed). By removing the recvCmd from the master and replacing it with a pause of 60 seconds (Call duration is a little less than 60 seconds), we see the calls processed at the rate we expect (10 calls / sec default or whatever we put in ?r and ?rp). A pause of only 1 second causes the same problem as no pause. Inserting a pause of appropriate duration does make the problem go away, but the problem with this is that we don?t know how long the calls will be processed by the slave. When no agents are available the calls are queued and could be in the queue for a while. This makes it difficult to predict how long to make the pause , and we don?t want to put in something ridiculously large. The question is ? why does adding a recvCmd in the master and a sendCmd in the slave cause this behaviour? I have attached the shell scripts, the 3PCC Extended config files and the scenario files. They are called in the following order: callGeneratorToPremiseSIPServer-1.sh callGeneratorToPremiseSIPServer-2.sh callGeneratorToNetworkSIPServer.sh thanks for any help you can give, Michael Lynch CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.[attachment callGeneratorToPremiseSIPServer-2.sh deleted by Charles P Wright/Watson/IBM] [attachment slave.cfg deleted by Charles P Wright/Watson/IBM] [attachment slave-1.cfg deleted by Charles P Wright/Watson/IBM] [attachment slave-2.cfg deleted by Charles P Wright/Watson/IBM] [attachment callGeneratorToNetworkSIPServer.sh deleted by Charles P Wright/Watson/IBM] [attachment callGeneratorToNetworkSIPServer.xml deleted by Charles P Wright/Watson/IBM] [attachment callGeneratorToPremiseSIPServer.xml deleted by Charles P Wright/Watson/IBM] [attachment callGeneratorToPremiseSIPServer-1.sh deleted by Charles P Wright/Watson/IBM] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
