Hi again Pavel, - Yes, I understand that I need the Dial line on my dialplan. I only removed the lines on the dialplan to verify how it is working and if that is the reason Asterisk is replying immediately to SIPp's requests.
- I tried setting my UAS from 'friend' to 'peer' under the sip.conf, then re-ran the test, and it was exactly the same call flow :( - So far, I haven't seen any major CPU or memory utilization issues. Hardware depletion isn't an issue yet. - I'm not familiar yet with the 3PCC. I'm working to achieve my full end-to-end SIP call flow using the UAC/UAS or BRANCHC/BRANCHS scnearios with the necessary modifications. So far, I've managed to get successful registration of both UAC and UAS, however, when the UAC sends the INVITE next, Asterisk still replies to the call flow by itself. - Have you ever managed to get the full call flow simulated with SIPp ? If so, Can you please share the command lines you used for both ! I'm suspecting I have a missing parameter Best Regards, *Yasir Saad Al-Ibrahem+1-312-428-0301* On Wed, Jul 27, 2016 at 3:30 PM, <sipp-users-requ...@lists.sourceforge.net> wrote: > Send Sipp-users mailing list submissions to > sipp-users@lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/sipp-users > or, via email, send a message with subject or body 'help' to > sipp-users-requ...@lists.sourceforge.net > > You can reach the person managing the list at > sipp-users-ow...@lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Sipp-users digest..." > > > Today's Topics: > > 1. Re: Use the CSV file? To run 1 script that would send a list > of different rejections (sindelka) > 2. Re: Sipp-users Digest, Vol 119, Issue 4 (yasir al-ibrahem) > 3. Re: Sipp-users Digest, Vol 119, Issue 4 (sindelka) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 Jul 2016 13:16:03 +0200 > From: sindelka <sinde...@ttc.cz> > Subject: Re: [Sipp-users] Use the CSV file? To run 1 script that would > send a list of different rejections > To: sipp-users@lists.sourceforge.net > Message-ID: <7afba172-25d2-fa2d-bc94-534e8edeb...@ttc.cz> > Content-Type: text/plain; charset=windows-1252; format=flowed > > I'm not sure I understand what you wanted to achieve. > > An endpoint (i.e. not a forking proxy) is expected to send a single > final response for a single INVITE received. In your example, it would > be either the 408 or the 491, but not both. That is why I've suggested > condexec - it allows to easily implement "send just one out of N > possible messages" in a plain scenario flow, without need to use tons of > "label"s and "next", "test" jumps. > > So when simulating a normal call flow (rather than testing the DUT's > handling of anomalies), your UAC scenario should send an INVITE, wait > for reception of a single final response, and send an ACK upon reception > of the response. > > So once your UAS scenario has sent the 408, it should proceed to > awaiting an ACK. Instead, you've made it wait for another 5 seconds > before ending. For the 491 case, you've tested the retransmission > capability of the UAC by not responding the INVITE with anything at all > for 5 seconds. > > The UAC scenario is even worse, as it expects a 491 to come after it has > already received a 408 for a given INVITE. Instead, I would have used > this in the UAC scenario: > > <recv response="408" crlf="true" optional="true"/> > > <!-- as many <recv response="xxx" optional="true"/> as necessary --> > > <recv response="491" crlf ="true"/> <!-- the last one must NOT be > optional --> > > <send> > <![CDATA[ > ACK sip:... > > ]]> > </send> > > Each scenario's error log should tell you exactly what was the "dead > call message". A dead call message is one which has the same Call-ID > like "normal" messages but it arrives after the last message with such > Call-ID and foreseen by the scenario has been received or sent. > > Pavel > > > > > ------------------------------ > > Message: 2 > Date: Wed, 27 Jul 2016 13:08:26 -0500 > From: yasir al-ibrahem <alibrahem.ya...@gmail.com> > Subject: Re: [Sipp-users] Sipp-users Digest, Vol 119, Issue 4 > To: sipp-users@lists.sourceforge.net > Message-ID: > <CABt= > g-k2ped8ncisj3tuuw+suxjv84_qos609na86t88uu1...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi > ? Sindelka?, > > Thanks for the reply. > So. All I want to do is to achieve a real flow of SIP messages to assess > the performance of Asterisk using SIPp. > > I have created the 8001 account in sip.conf and it's related dial plan on > extensions.conf, but I haven't started the sipphone software, so It's not > registered. > I did a test where I removed the first line of the dial plan (exten => > 8001,1,Dial(8001,20)) and tried the SIPp call, and then Asterisk replied > with 404 Not Found immediately as a reply to the INVITE. > > My objective is to do performance testing for my Asterisk, and have it > process the SIP calls for both parties (UAC, UAS). > I'm running my UAS on the same machine as the Asterisk and I see that > Asterisk doesn't send any INVITE or other SIP messages towards the UAS. As > previously mentioned, it immediately replies to the UAC according to the > configured dial plan. > > BTW: I have altered to the branchc.xml to have the registration messages > and it did work, however, it's the same behaviour where Asterisk replies > immediately without any SIP messages sent to the UAS. > > Can you please share a sample of the commands you run for UAC and UAS so > that you force Asterisk to send SIP messages to both ? > Do you run the UAC and UAS on different machies than the Asterisk machine ? > > ?Best Regards,? > > > *Yasir Saad Al-Ibrahem+1-312-428-0301* > > On Tue, Jul 26, 2016 at 5:10 AM, <sipp-users-requ...@lists.sourceforge.net > > > wrote: > > > Send Sipp-users mailing list submissions to > > sipp-users@lists.sourceforge.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.sourceforge.net/lists/listinfo/sipp-users > > or, via email, send a message with subject or body 'help' to > > sipp-users-requ...@lists.sourceforge.net > > > > You can reach the person managing the list at > > sipp-users-ow...@lists.sourceforge.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Sipp-users digest..." > > > > > > Today's Topics: > > > > 1. SIPp Traffic Flow with Asterisk (yasir al-ibrahem) > > 2. Re: SIPp Traffic Flow with Asterisk (sindelka) > > 3. Re: Res: Res: Sipp-users Digest, Vol 53, Issue 1 (Iswarya) > > > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 25 Jul 2016 10:43:34 +0200 > > From: sindelka <sinde...@ttc.cz> > > Subject: Re: [Sipp-users] SIPp Traffic Flow with Asterisk > > To: sipp-users@lists.sourceforge.net > > Message-ID: <b13752d7-c202-d914-5b7a-326398732...@ttc.cz> > > Content-Type: text/plain; charset="utf-8" > > > > Hi Yasir, > > > > half of your questions is actually irrelevant to SIPp :-) In the > > Asterisk configuration, you've stated to continue by responding the > > incoming INVITE with Ringing if the routing step > > > > exten => 8001,1,Dial(SIP/8001,20) > > > > returns with any result. So I suspect that you haven't registered any > > SIP phone as extension 8001, and maybe you haven't even defined it in > > sip.conf, so the Asterisk doesn't know where to send the INVITE > > specified in step 1, so it returns immediately to step 2. > > > > Back to the SIPp setup necessary for your application: if you want to > > stress-test any SIP PBX using SIPp, you need two SIPp instances: one > > running the UAC scenario, i.e. acting as the calling side, where you > > "modulate" the call rate and number of concurrent calls, and another one > > running an UAS scenario, i.e. acting as called party, which responds all > > calls with no delays (with 4xx or with 200 followed by sent or expected > > BYE depending on what you want to test). So at the called side, the > > embedded UAS scenario may not be enough. > > > > If you want to test calls to a registered local SIP user on Asterisk in > > particular (because processing of such calls takes a specific path > > through Asterisk's code),which seems to be your case given how you've > > described it, the SIPp scenario imitating the called party must include > > registration which is not the simplest task - to do that, you have to > > create a pair of scenarios at the called side, an UAS one which expects > > an incoming INVITE or a Cmd from the other scenario. The received INVITE > > is processed normally, the received Cmd triggers sending of a REGISTER. > > I've written more on this topic here at sipp-users less than a month ago. > > > > Also, the -ap is necessary to authorize the calling or registering > > party, i.e. it must correspond to the From uri of the request sent. So > > for calls *to* 8001, -ap for 8001 is useless. Plus Asterisk normally > > rejects calls which come in with a locally defined number in From via a > > trunk. > > > > As for rejection of calls coming from unknown calling parties, that's > > purely an Asterisk question I don't feel competent to answer. > > > > Just a final remark, some time ago there was a problem that Asterisk had > > first allocated all resources needed to process a call and only then it > > checked whether the call was allowed, which was causing it it to hang > > under floods of INVITEs. So if you manage to generate a high enough rate > > of call attempts, you may have to restart the Asterisk after such test. > > But it may need a farm of machines running SIPp, or not be possible at > > all if the Asterisk code has changed since. > > > > Pavel > > > > > > Dne 25.7.2016 v 5:49 yasir al-ibrahem napsal(a): > > > Hello dears, > > > > > > I've been using SIPp for a week now, and I need some help to > > > understand the expected message flow please. > > > > > > My test procedure was: > > > (1) I've configured an extension on my Asterisk as '8001/8001mike' in > > > sip.conf > > > (2) I configured a simple dialplan for that extension so that it can > > > be dialled, as: > > > exten => 8001,1,Dial(SIP/8001,20) > > > exten => 8001,2,Ringing() > > > exten => 8001,3,Answer() > > > exten => 8001,4,Hangup() > > > (3) on another machine, I installed SIPp and ran it as below > > > # sipp -sn uac <Asterisk IP> -s 8001 -ap 8001mike -r 1 -l 5 -m 5 > > > > > > Results: > > > (1) calls were all successful > > > (2) The call flow on Asterisk was > > > --> INVITE > > > <-- 100 Trying > > > <-- 200 OK > > > --> ACK > > > --> BYE > > > <-- 200 OK > > > > > > Questions: > > > (1) Asterisk generated the above messages without issuing any actual > > > messages towards the 8001 as a called party. This isn't a reliable > > > stress test for Asterisk since it didn't interact with 8001. > > > Is that a correct test procedure ? > > > Is there a way to make SIPp traffic tests with Asterisk to generate > > > SIP messages completely to both parties ? > > > note: I know that If I start the sipphone (e.g. X-Lite, Zoiper) that I > > > get the ringing and I must answer it manually, but I can't answer > > > calls manually at a rate of 50 calls per second. > > > > > > (2) This is for Asterisk. > > > SIPp generates INVITE messages with a caller as 'sipp@<IP>'. Do you > > > know how to force Asterisk to reject INVITE messages if the caller > > > isn't a registered client ? > > > > > > T > > > ?hanks a lot? > > > Best Regards, > > > /Yasir Saad Al-Ibrahem > > > +1-312-428-0301/// > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > What NetFlow Analyzer can do for you? Monitors network bandwidth and > > traffic > > > patterns at an interface-level. Reveals which users, apps, and > protocols > > are > > > consuming the most bandwidth. Provides multi-vendor support for > NetFlow, > > > J-Flow, sFlow and other flows. Make informed decisions using capacity > > planning > > > reports.http://sdm.link/zohodev2dev > > > > > > > > > _______________________________________________ > > > Sipp-users mailing list > > > Sipp-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/sipp-users > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > Message: 3 > Date: Wed, 27 Jul 2016 22:30:17 +0200 > From: sindelka <sinde...@ttc.cz> > Subject: Re: [Sipp-users] Sipp-users Digest, Vol 119, Issue 4 > To: sipp-users@lists.sourceforge.net > Message-ID: <e5f8fa61-5414-db29-76ff-9e25d1391...@ttc.cz> > Content-Type: text/plain; charset="utf-8" > > Hi Yasir, > > > I removed the first line of the dial plan (exten => > 8001,1,Dial(8001,20)) and tried the SIPp call, and then Asterisk replied > with 404 Not Found immediately as a reply to the INVITE. > > This seems to be the first mistake because AFAIK there must always be a > rule No. 1 in the Asterisk dialplan for each "exten => x". But the good > news is that you may remove all the other rules instead. > > > I'm running my UAS on the same machine as the Asterisk and I see that > Asterisk doesn't send any INVITE or other SIP messages towards the UAS. > > If you're running both on the same machine, each of them must use a > different local port or at least on a different IP address (although I > think Asterisk listens on all IPs unless you specially tell it not to do > so). But let's assume you did so. Then the Asterisk can only send the > INVITE to the "UAS" scenario if > > * you put back your original rule "1" (exten => > 8001,1,Dial(SIP/8001,20)) *and* > * you either configure the UAS scenario as a peer in sip.conf or leave > the sip.conf unchanged but let the "UAS" (actually, > called-party-simulating) scenario register first. Asterisk needs the > Contact from the REGISTER to learn the destination socket to which > it should send INVITEs. If you set 8001 as a peer, the destination > socket is in the configuration so no REGISTER is necessary. > > What is also important - if you want to assess Asterisk performance, > running the called-side SIPp scenario on the same hardware will heavily > affect the result, so running the calling and called side SIPp scenarios > on the same machine might be a better option if you are short of > hardware (but for a real performance test, the summary power of the > hardware running SIPp should be at least 10 times higher than that of > the one running Asterisk. > > > I have altered to the branchc.xml to have the registration messages > and it did work, however, it's the same behaviour where Asterisk replies > immediately without any SIP messages sent to the UAS. > > The branchc.xml does not do what you need as it *sends* an INVITE > instead of receiving it, and even worse, I think it is wrong in > principle because it uses the same Call-ID for the REGISTER and for the > INVITE which is confusing for any normal SIP peer. > > What you need is that your called-side scenario would act as UAC when > sending the REGISTER but also act as an UAS to accept an incoming > INVITE. To do that, you need a pair of interworking scenarios. So I'd > recommend you to start from the 8001 as a trunk (where a plain UAS > scenario is OK) and to revert to the 8001 as registering CPE in the next > step. > > The pair of called side scenarios would look the following way: > > Main: > <scenario ...> > <recv request="INVITE" optional="true" next="process_INVITE"/> > > <recvCmd/> > > <label id="send_REGISTER"/> > <send> > <![CDATA[ > > REGISTER sip:... > > ]]> > </send> > > <recv response="200"/> > > <pause milliseconds="300" next="send_REGISTER"/> > <label id="process_INVITE"/> > <send> > <![CDATA[ > > SIP/2.0 100 Trying... > > ]]> > </send> > ... > </scenario> > > > Auxiliary (timer): > <scenario ... > > <send> > <![CDATA[ > > BOGUS sip:... > > ]]> > </send> > <sendCmd> > <![CDATA[ > > Call-ID: [call_id] > > ]]> > </sendCmd> > > <pause milliseconds="1800000"/> <!-- for test duration of 30 min. --> > </scenario> > > Both of them must be run with a "-3pcc localhost:9001" command line > option, the master one first. The timer one must be launched with -m 1 > and with some blackhole as destination socket (we don't want any > response to the BOGUS request which must be there so that SIPp would let > this scenario generate Call-IDs). > > Only after both these scenarios are running, you may start the > calling-side one. > > If Asterisk can accept that the socket in REGISTER's Contact differs > from the source socket of the REGISTER, you could run an UAC scenario > which would only REGISTER and an UAS scenario which would only respond > INVITEs and the two wouldn't need to talk to each other, but I am not > sure whether Asterisk handles that - most SIP services don't, so the > 3pcc way is universal although slightly more complex. > > Pavel > > > -------------- next part -------------- > An HTML attachment was scrubbed... > > ------------------------------ > > > ------------------------------------------------------------------------------ > > > ------------------------------ > > _______________________________________________ > Sipp-users mailing list > Sipp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sipp-users > > > End of Sipp-users Digest, Vol 119, Issue 6 > ****************************************** >
------------------------------------------------------------------------------
_______________________________________________ Sipp-users mailing list Sipp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sipp-users
