Menu
▾
▴
Re: [Sipp-users] IMS Bench & OpenIMSCore (SIPp and SIP errors)
|
From: Mohammad I. <m.i...@gm...> - 2014-02-24 14:00:32
|
Hi all,
Sorry, I was too busy to continue working on the issue. Anyway, I could get
some tests successfully. Actually, there was no problem with ims_bench or
sipp configurations; the problem was about of the small number of
provisioned users (30 users) in my setup compared to the high rates of
default call/msg attempts. The default number of users was 24000 :) . Due
to these high rates, the ims_bench pools were getting empty soon.
Anyway, I created 6000 users in imscore and by setting scenario rates to
1/4 of default values, it was all OK.
Thanks.
On Sun, Jan 19, 2014 at 5:59 PM, Mohammad Isargar <m.i...@gm...>wrote:
> Thanks for that details. I've attached message and error logs. The timeout
> log was empty.
>
>
>
> On Sun, Jan 19, 2014 at 5:14 PM, Rob Day <rk...@rk...> wrote:
>
>> The reason you're seeing such an odd BYE is that, when SIPp detects
>> that a call has failed, it tries to end it gracefully by sending a
>> BYE, CANCEL or ACK. The code to create the BYE looks like this
>> (ims_bench branch, call.cpp, line 2223):
>>
>> L_param += sprintf(L_param,
>> "BYE sip:[service]@[remote_ip]:[remote_port]
>> SIP/2.0\n"
>> "Via: SIP/2.0/[transport]
>> [local_ip]:[local_port];branch=[branch]\n"
>> "From: sipp
>> <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]\n"
>> "To: sut
>> <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param]\n"
>> "Call-ID: [call_id]\n");
>> cseq = compute_cseq(src_recv);
>> if ((cseq != NULL) && (*cseq)) {
>> L_param += sprintf(L_param, "%s BYE\n", cseq);
>> }
>> L_param += sprintf(L_param,
>> "Contact:
>> <sip:[local_ip]:[local_port];transport=[transport]>\n"
>> "Content-Length: 0\n");
>>
>> So that's where 127.0.01 is coming from (it uses the local IP) and
>> where sipp/sut is coming from (hardcoded in). (I believe this code has
>> been cleaned up a bit in the main SIPp branch and now uses
>> [last_From:], [last_To:] and so on.)
>>
>> In other words, the BYE is really just a symptom of the problem - SIPp
>> thinks your test has failed and the BYE is its attempt to clean up.
>> There are error logging options you can pass to SIPp (described at
>>
>> http://sipp.sourceforge.net/ims_bench/reference.html#Log+files+%28error+%2B+log+%2B+screen%29
>> )
>> which will create an error log file - that should have a much better
>> description of what the real problem is (message timeouts, bad IP
>> address, and so on).
>>
>> I don't have many good guesses about what it is, without seeing that
>> file - given that you don't see any messages between the 200 OK for
>> the INVITE and the BYE, maybe the 200 OK isn't being recognised by
>> SIPp, maybe it's waiting to receive an INVITE or MESSAGE and timing
>> out, or (if you're running tshark on your OpenIMSCore rather than your
>> SIPp node) maybe it's sending it's messages somewhere else, not to the
>> IMS core, and failing to get a response.
>>
>> Best,
>> Rob
>>
>> On 19 January 2014 12:36, Mohammad Isargar <m.i...@gm...> wrote:
>> > Hi Rob,
>> >
>> > Sure, and sorry about the attachment, my mistake.
>> >
>> > I used IMS Bench Perl script, scripts/ims_bench.pl, to generate
>> > configurations. The things that I've changed:
>> > - Number of users, set to 30.
>> > - IMPI & IMPU formats slightly modified.
>> > - SUT address, which I changed to open-ims.test (I was afraid of using
>> this
>> > IP as realm)
>> > - Manager itself calls SIPp instances.
>> >
>> > Also, I did changed the argument of sipp -i option from 127.0.0.1 to
>> > open-ims.test (in run_1.sh script generated by IMS Bench), again
>> because of
>> > the mentioned reason.
>> >
>> > I did No changes to the default scenarios, by the way I've attached
>> them too
>> > along with manager.xml, ims_bench.xml and report.xml.
>> >
>> > Please let me know if you need any more information.
>> > Thanks for your attention.
>> >
>> >
>> >
>> >
>> > On Sun, Jan 19, 2014 at 2:44 PM, Rob Day <rk...@rk...> wrote:
>> >>
>> >> Hi Mohammed,
>> >>
>> >> I don't know a great deal about the IMSBench extensions, I'm afraid,
>> >> so I may not be much help - but I can take a look into this.
>> >> Could you send the SIPp XML files that IMSBench is using (I don't
>> >> think they were attached to your original email), and any information
>> >> you can give about how you've configured IMSBench?
>> >>
>> >> Thanks,
>> >> Rob
>> >>
>> >> On 19 January 2014 10:17, Mohammad Isargar <m.i...@gm...>
>> wrote:
>> >> > The following is the trace of the dialogs (important headers
>> included)
>> >> > between subs5000011 and P-CSCF.
>> >> > At first, user registers successfully with Call-ID
>> >> > 13-20607@open-ims.test ,
>> >> > then re-registers (due to re-registration scenario?) with Call-ID
>> >> > 33-20607@open-ims.test. At the end, user sends a BYE request with a
>> >> > "new"
>> >> > Call-ID 79-20607@open-ims.test. Would anyone please explain about
>> the
>> >> > purpose of this BYE request? As far as I know, client uses BYE to
>> >> > terminate
>> >> > an "existing" dialog established by INVITE and it is destined for the
>> >> > callee. But, here the Request-URI is set to P-CSCF address and the
>> >> > Call-ID
>> >> > is a new one (I didn't find it in the dumps). And we see the error
>> from
>> >> > OpenIMSCore: "Status-Line: SIP/2.0 403 Forbidden - Originating
>> >> > subsequent
>> >> > requests outside dialog not allowed".
>> >> >
>> >> > Finally I should mention that I have no subscriber named "service@
>> ..."
>> >> > or
>> >> > "sipp@..." in HSS DB.
>> >> >
>> >> > Thanks for any help.
>> >> >
>> >> > 7329:User Datagram Protocol, Src Port: talon-disc (7011), Dst Port:
>> >> > dsmeter-iatc (4060)
>> >> > 7336:Session Initiation Protocol
>> >> > 7337: Request-Line: REGISTER sip:open-ims.test SIP/2.0
>> >> > 7348: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=13
>> >> > 7354: To: "subs5000011" <sip:subs5000011@open-ims.test>
>> >> > 7359: Call-ID: 13-20607@open-ims.test
>> >> > 7363: Contact:
>> >> > <sip:subs5000011@open-ims.test:7011>;expires=1000000
>> >> > 7369: Expires: 1000000
>> >> > --
>> >> > 9793:User Datagram Protocol, Src Port: dsmeter-iatc (4060), Dst Port:
>> >> > talon-disc (7011)
>> >> > 9800:Session Initiation Protocol
>> >> > 9801: Status-Line: SIP/2.0 401 Unauthorized - Challenging the UE
>> >> > 9802: Status-Code: 401
>> >> > 9812: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=13
>> >> > 9818: To: "subs5000011"
>> >> >
>> >> > <sip:subs5000011@open-ims.test
>> >;tag=4c56058d6355f7ec7bd4f0a9441112ef-fc5d
>> >> > 9824: Call-ID: 13-20607@open-ims.test
>> >> >
>> >> > --
>> >> > 10077:User Datagram Protocol, Src Port: talon-disc (7011), Dst Port:
>> >> > dsmeter-iatc (4060)
>> >> > 10084:Session Initiation Protocol
>> >> > 10085: Request-Line: REGISTER sip:open-ims.test SIP/2.0
>> >> > 10096: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=13
>> >> > 10102: To: "subs5000011" <sip:subs5000011@open-ims.test>
>> >> > 10107: Call-ID: 13-20607@open-ims.test
>> >> > 10111: Contact:
>> >> > <sip:subs5000011@open-ims.test:7011>;expires=1000000
>> >> > 10117: Expires: 1000000
>> >> > --
>> >> > 13139:User Datagram Protocol, Src Port: dsmeter-iatc (4060), Dst
>> Port:
>> >> > talon-disc (7011)
>> >> > 13146:Session Initiation Protocol
>> >> > 13147: Status-Line: SIP/2.0 200 OK - SAR succesful and registrar
>> >> > saved
>> >> > 13148: Status-Code: 200
>> >> > 13161: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=13
>> >> > 13167: To: "subs5000011"
>> >> >
>> >> > <sip:subs5000011@open-ims.test
>> >;tag=4c56058d6355f7ec7bd4f0a9441112ef-625c
>> >> > 13173: Call-ID: 13-20607@open-ims.test
>> >> > 13178: Contact: <sip:subs5000011@open-ims.test
>> :7011>;expires=3600
>> >> > --
>> >> > 24277:User Datagram Protocol, Src Port: talon-disc (7011), Dst Port:
>> >> > dsmeter-iatc (4060)
>> >> > 24284:Session Initiation Protocol
>> >> > 24285: Request-Line: REGISTER sip:open-ims.test SIP/2.0
>> >> > 24296: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=33
>> >> > 24302: To: "subs5000011" <sip:subs5000011@open-ims.test>
>> >> > 24307: Call-ID: 33-20607@open-ims.test
>> >> > 24311: Contact:
>> >> > <sip:subs5000011@open-ims.test:7011>;expires=1000000
>> >> > 24317: Expires: 1000000
>> >> > --
>> >> > 24582:User Datagram Protocol, Src Port: dsmeter-iatc (4060), Dst
>> Port:
>> >> > talon-disc (7011)
>> >> > 24589:Session Initiation Protocol
>> >> > 24590: Status-Line: SIP/2.0 401 Unauthorized - Challenging the UE
>> >> > 24591: Status-Code: 401
>> >> > 24601: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=33
>> >> > 24607: To: "subs5000011"
>> >> >
>> >> > <sip:subs5000011@open-ims.test
>> >;tag=4c56058d6355f7ec7bd4f0a9441112ef-3c3f
>> >> > 24613: Call-ID: 33-20607@open-ims.test
>> >> >
>> >> > 24677:User Datagram Protocol, Src Port: talon-disc (7011), Dst Port:
>> >> > dsmeter-iatc (4060)
>> >> > 24684:Session Initiation Protocol
>> >> > 24685: Request-Line: REGISTER sip:open-ims.test SIP/2.0
>> >> > 24697: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=33
>> >> > 24703: To: "subs5000011" <sip:subs5000011@open-ims.test>
>> >> > 24708: Call-ID: 33-20607@open-ims.test
>> >> > 24712: Contact:
>> >> > <sip:subs5000011@open-ims.test:7011>;expires=1000000
>> >> > 24718: Expires: 1000000
>> >> > --
>> >> > 24987:User Datagram Protocol, Src Port: dsmeter-iatc (4060), Dst
>> Port:
>> >> > talon-disc (7011)
>> >> > 24994:Session Initiation Protocol
>> >> > 24995: Status-Line: SIP/2.0 200 OK - SAR succesful and registrar
>> >> > saved
>> >> > 24996: Status-Code: 200
>> >> > 25009: From: "subs5000011" <sip:subs5000011@open-ims.test
>> >;tag=33
>> >> > 25015: To: "subs5000011"
>> >> >
>> >> > <sip:subs5000011@open-ims.test
>> >;tag=4c56058d6355f7ec7bd4f0a9441112ef-aa78
>> >> > 25021: Call-ID: 33-20607@open-ims.test
>> >> > 25026: Contact: <sip:subs5000011@open-ims.test
>> :7011>;expires=3600
>> >> > --
>> >> > 57540:User Datagram Protocol, Src Port: talon-disc (7011), Dst Port:
>> >> > dsmeter-iatc (4060)
>> >> > 57547:Session Initiation Protocol
>> >> > 57548: Request-Line: BYE sip:service@127.0.0.1:4060 SIP/2.0
>> >> > 57561: From: sipp <sip:sipp@open-ims.test:7011>;tag=79
>> >> > 57568: To: sut <sip:service@127.0.0.1:4060>
>> >> > 57574: Call-ID: 79-20607@open-ims.test
>> >> > 57578: Contact: <sip:open-ims.test:7011;transport=UDP>
>> >> >
>> >> > 57627:User Datagram Protocol, Src Port: dsmeter-iatc (4060), Dst
>> Port:
>> >> > talon-disc (7011)
>> >> > 57634:Session Initiation Protocol
>> >> > 57635: Status-Line: SIP/2.0 403 Forbidden - Originating subsequent
>> >> > requests outside dialog not allowed
>> >> > 57636: Status-Code: 403
>> >> > 57649: From: sipp <sip:sipp@open-ims.test:7011>;tag=79
>> >> > 57656: To: sut
>> >> > <sip:service@127.0.0.1:4060
>> >;tag=bf17b8f52ba8a335422fa78ec37a5922.a875
>> >> > 57663: Call-ID: 79-20607@open-ims.test
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Sat, Jan 18, 2014 at 5:03 PM, Mohammad Isargar
>> >> > <m.i...@gm...>
>> >> > wrote:
>> >> >>
>> >> >> Hi all
>> >> >>
>> >> >> I'm trying to use IMS Bench to test OpenIMSCore as SUT.
>> >> >>
>> >> >> All components are in the same machine.
>> >> >>
>> >> >> The manager execution ends with this message: "Over IHS detected **
>> >> >> STOP
>> >> >> NOW ** ".
>> >> >>
>> >> >> I have plenty of the following errors in the SIPp error log:
>> >> >> ...
>> >> >> 2014-01-18 16:25:48.889: Call '2856-27604@127.0.0.1' - pick_user()
>> >> >> returned NULL in pool 2.
>> >> >> 2014-01-18 16:25:48.889: Call '2856-27604@127.0.0.1' - Action
>> >> >> 'move_user'
>> >> >> without a user assigned!.
>> >> >> 2014-01-18 16:25:48.893: Call '2857-27604@127.0.0.1' - pick_user()
>> >> >> returned NULL in pool 2.
>> >> >> 2014-01-18 16:25:48.893: Call '2857-27604@127.0.0.1' - Action
>> >> >> 'move_user'
>> >> >> without a user assigned!.
>> >> >> 2014-01-18 16:25:48.910: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:48.937: Call '2858-27604@127.0.0.1' - pick_user()
>> >> >> returned NULL in pool 2.
>> >> >> 2014-01-18 16:25:48.937: Call '2858-27604@127.0.0.1' - Action
>> >> >> 'move_user'
>> >> >> without a user assigned!.
>> >> >> 2014-01-18 16:25:48.950: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:48.956: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:48.977: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:48.992: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:49.090: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:49.096: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:49.109: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:49.122: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:49.133: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> 2014-01-18 16:25:49.155: !! ERROR !! There should have been calls in
>> >> >> SYNC
>> >> >> !!.
>> >> >> ...
>> >> >>
>> >> >> In the tshark dumps, I have this SIP error:
>> >> >> "Originating subsequent requests outside dialog not allowed".
>> >> >> which is on behalf of OpenIMSCore. Here are two samples of
>> >> >> request/response SIP packets involved in this error:
>> >> >>
>> >> >> Session Initiation Protocol
>> >> >> Request-Line: BYE sip:service@127.0.0.1:4060 SIP/2.0
>> >> >> Method: BYE
>> >> >> Request-URI: sip:service@127.0.0.1:4060
>> >> >> Request-URI User Part: service
>> >> >> Request-URI Host Part: 127.0.0.1
>> >> >> Request-URI Host Port: 4060
>> >> >> [Resent Packet: False]
>> >> >> Message Header
>> >> >> Via: SIP/2.0/UDP 127.0.0.1:7072;branch=z9hG4bK-20969-161--1
>> >> >> Transport: UDP
>> >> >> Sent-by Address: 127.0.0.1
>> >> >> Sent-by port: 7072
>> >> >> Branch: z9hG4bK-20969-161--1
>> >> >> From: sipp <sip:sipp@127.0.0.1:7072>;tag=161
>> >> >> SIP Display info: sipp
>> >> >> SIP from address: sip:sipp@127.0.0.1:7072
>> >> >> SIP from address User Part: sipp
>> >> >> SIP from address Host Part: 127.0.0.1
>> >> >> SIP from address Host Port: 7072
>> >> >> SIP tag: 161
>> >> >> To: sut <sip:service@127.0.0.1:4060>
>> >> >> SIP Display info: sut
>> >> >> SIP to address: sip:service@127.0.0.1:4060
>> >> >> SIP to address User Part: service
>> >> >> SIP to address Host Part: 127.0.0.1
>> >> >> SIP to address Host Port: 4060
>> >> >> Call-ID: 161-20969@127.0.0.1
>> >> >> CSeq: 2 BYE
>> >> >> Sequence Number: 2
>> >> >> Method: BYE
>> >> >> Contact: <sip:127.0.0.1:7072;transport=UDP>
>> >> >> Contact-URI: sip:127.0.0.1:7072;transport=UDP
>> >> >> Contact-URI Host Part: 127.0.0.1
>> >> >> Contact-URI Host Port: 7072
>> >> >> Contact parameter: transport=UDP>
>> >> >> Content-Length: 0
>> >> >>
>> >> >> Session Initiation Protocol
>> >> >> Status-Line: SIP/2.0 403 Forbidden - Originating subsequent
>> >> >> requests
>> >> >> outside dialog not allowed
>> >> >> Status-Code: 403
>> >> >> [Resent Packet: False]
>> >> >> [Request Frame: 1889]
>> >> >> [Response Time (ms): 0]
>> >> >> [Release Time (ms): 0]
>> >> >> Message Header
>> >> >> Via: SIP/2.0/UDP
>> >> >> 127.0.0.1:7072;branch=z9hG4bK-20969-161--1;rport=7072
>> >> >> Transport: UDP
>> >> >> Sent-by Address: 127.0.0.1
>> >> >> Sent-by port: 7072
>> >> >> Branch: z9hG4bK-20969-161--1
>> >> >> RPort: 7072
>> >> >> From: sipp <sip:sipp@127.0.0.1:7072>;tag=161
>> >> >> SIP Display info: sipp
>> >> >> SIP from address: sip:sipp@127.0.0.1:7072
>> >> >> SIP from address User Part: sipp
>> >> >> SIP from address Host Part: 127.0.0.1
>> >> >> SIP from address Host Port: 7072
>> >> >> SIP tag: 161
>> >> >> To: sut
>> >> >> <sip:service@127.0.0.1:4060
>> >;tag=bf17b8f52ba8a335422fa78ec37a5922.f9dc
>> >> >> SIP Display info: sut
>> >> >> SIP to address: sip:service@127.0.0.1:4060
>> >> >> SIP to address User Part: service
>> >> >> SIP to address Host Part: 127.0.0.1
>> >> >> SIP to address Host Port: 4060
>> >> >> SIP tag: bf17b8f52ba8a335422fa78ec37a5922.f9dc
>> >> >> Call-ID: 161-20969@127.0.0.1
>> >> >> CSeq: 2 BYE
>> >> >> Sequence Number: 2
>> >> >> Method: BYE
>> >> >> Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore
>> >> >> (x86_64/linux))
>> >> >> Content-Length: 0
>> >> >> Warning: 392 0.0.0.0:4060 "Noisy feedback tells: pid=16999
>> >> >> req_src_ip=127.0.0.1 req_src_port=7072
>> >> >> in_uri=sip:service@127.0.0.1:4060
>> >> >> out_uri=sip:service@127.0.0.1:4060 via_cnt==1"
>> >> >>
>> >> >> Something that I don't understand here is that the address
>> >> >> `sip:service@127.0.0.1:4060' been used as
>> >> >> Request-URI of BYE message. But, my OpenIMSCore installation does
>> not
>> >> >> work
>> >> >> with 127.0.0.1 as realm for
>> >> >> SIP addresses.
>> >> >>
>> >> >> I don't know that the problem is with IMS Bench or OpenIMSCore.
>> >> >>
>> >> >> Also, the files manager.xml and ims_bench.xml have been attached.
>> >> >>
>> >> >> Thanks for any comment.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> ------------------------------------------------------------------------------
>> >> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>> >> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
>> >> > Critical Workloads, Development Environments & Everything In Between.
>> >> > Get a Quote or Start a Free Trial Today.
>> >> >
>> >> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>> >> > _______________________________________________
>> >> > Sipp-users mailing list
>> >> > Sip...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/sipp-users
>> >> >
>> >
>> >
>>
>
>
|