Thanks for replying. What is the main cause of of 503 service unavailable
according to you. What is exact command for tcpdump.
On Tue, Mar 20, 2018 at 2:14 PM, Sunil Kumar <skgola1...@gmail.com> wrote:
> Hi Pavel,
> Thanks for replying. I am using project clearwater, in which i am doing
> stress testing which is using SIPp basically. But when i am running that
> command all calls are failing giving 503 error, can you provide some
> solution regarding that.
>
> here i am trying 100 call 5 min is duration and this is going to *sprout
> node. *ims.com is my home domain
> *[]ubuntu@stress:~$ sudo /usr/share/clearwater/bin/run_stress ims.com
> <http://ims.com> 100 5*
> [sudo] password for ubuntu:
> Starting initial registration, will take 1 seconds
> Initial registration succeeded
> Starting test
> Test complete
>
> Elapsed time: 00:04:36
> Start: 2018-03-20 21:37:12.980619
> End: 2018-03-20 21:42:01.082712
>
> Total calls: 5
> Successful calls: 0 (0.0%)
> Failed calls: 5 (100.0%)
> Unfinished calls: 0
>
> Retransmissions: 0
>
> Average time from INVITE to 180 Ringing: 0.0ms
> # of calls with 0-2ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 2-10ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 10-20ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 20-50ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 50-100ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 100-200ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 200-500ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 500-1000ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 1000-2000ms from INVITE to 180 Ringing: 0 (0.0%)
> # of calls with 2000+ms from INVITE to 180 Ringing: 0 (0.0%)
> Failed: call success rate 0.0% is lower than target 100.0%!
>
> Total re-REGISTERs: 16
> Successful re-REGISTERs: 16 (100.0%)
> Failed re-REGISTERS: 0 (0.0%)
>
> REGISTER retransmissions: 0
>
> Average time from REGISTER to 200 OK: 52.0ms
>
> Log files at /var/log/clearwater-sip-stress/26840_*
>
>
>
> sprout node log:
> *[sprout]ubuntu@sprout:/var/log/sprout$ tail -50 sprout_current.txt*
>
>
> --end msg--
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug uri_classifier.cpp:139:
> home domain: false, local_to_node: true, is_gruu: false,
> enforce_user_phone: false, prefer_sip: true, treat_number_as_phone: false
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug uri_classifier.cpp:172:
> Classified URI as 3
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
> common_sip_processing.cpp:180: Skipping SAS logging for OPTIONS request
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
> thread_dispatcher.cpp:554: Recieved message 0x7f32a422b620 on worker thread
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
> thread_dispatcher.cpp:571: Admitted request 0x7f32a422b620 on worker thread
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
> thread_dispatcher.cpp:606: Incoming message 0x7f32a422b620 cloned to
> 0x7f32a406b528
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
> thread_dispatcher.cpp:625: Queuing cloned received message 0x7f32a406b528
> for worker threads with priority 15
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
> event_statistic_accumulator.cpp:32: Accumulate 0 for 0x2a0f708
> 20-03-2018 16:07:52.719 UTC [7f32aa704700] Debug
> event_statistic_accumulator.cpp:32: Accumulate 0 for 0x2a0f780
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug utils.cpp:872: Added
> IOHook 0x7f32e076fe30 to stack. There are now 1 hooks
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> thread_dispatcher.cpp:178: Worker thread dequeue message 0x7f32a406b528
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> thread_dispatcher.cpp:183: Request latency so far = 82us
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug pjsip: sip_endpoint.c
> Distributing rdata to modules: Request msg OPTIONS/cseq=683401
> (rdata0x7f32a406b528)
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug uri_classifier.cpp:139:
> home domain: false, local_to_node: true, is_gruu: false,
> enforce_user_phone: false, prefer_sip: true, treat_number_as_phone: false
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug uri_classifier.cpp:172:
> Classified URI as 3
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug pjsip: endpoint
> Response msg 200/OPTIONS/cseq=683401 (tdta0x7f333c2de180) created
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Verbose
> common_sip_processing.cpp:103: TX 282 bytes Response msg
> 200/OPTIONS/cseq=683401 (tdta0x7f333c2de180) to TCP 10.224.61.22:46000:
> --start msg--
>
> SIP/2.0 200 OK
> Via: SIP/2.0/TCP 10.224.61.22;rport=46000;received=10.224.61.22;branch=
> z9hG4bK-683401
> Call-ID: poll-sip-683401
> From: "poll-sip" <sip:poll-sip@10.224.61.22>;tag=683401
> To: <sip:poll-sip@10.224.61.22>;tag=z9hG4bK-683401
> CSeq: 683401 OPTIONS
> Content-Length: 0
>
>
> --end msg--
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> common_sip_processing.cpp:275: Skipping SAS logging for OPTIONS response
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug pjsip: tdta0x7f333c2d
> Destroying txdata Response msg 200/OPTIONS/cseq=683401 (tdta0x7f333c2de180)
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> thread_dispatcher.cpp:270: Worker thread completed processing message
> 0x7f32a406b528
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> thread_dispatcher.cpp:284: Request latency = 220us
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> event_statistic_accumulator.cpp:32: Accumulate 220 for 0x2a0b778
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> event_statistic_accumulator.cpp:32: Accumulate 220 for 0x2a0b7f0
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug load_monitor.cpp:341: Not
> recalculating rate as we haven't processed 20 requests yet (only 3).
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug utils.cpp:878: Removed
> IOHook 0x7f32e076fe30 to stack. There are now 0 hooks
> 20-03-2018 16:07:52.719 UTC [7f32e0770700] Debug
> thread_dispatcher.cpp:158: Attempting to process queue element
> 20-03-2018 16:07:54.720 UTC [7f32aa704700] Verbose pjsip: tcps0x7f32a422
> TCP connection closed
> 20-03-2018 16:07:54.720 UTC [7f32aa704700] Debug
> connection_tracker.cpp:67: Connection 0x7f32a422b2e8 has been destroyed
> 20-03-2018 16:07:54.720 UTC [7f32aa704700] Verbose pjsip: tcps0x7f32a422
> TCP transport destroyed with reason 70016: End of file (PJ_EEOF)
> 20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: tcplis:5052
> TCP listener 10.224.61.22:5052: got incoming TCP connection from
> 10.224.61.8:40825, sock=442
> 20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: tcps0x7f32a422
> tcp->base.local_name: 10.224.61.22
> 20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: tcps0x7f32a422
> TCP server transport created
> 20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: tcps0x7f32a42b
> TCP connection closed
> 20-03-2018 16:07:56.623 UTC [7f32aa704700] Debug
> connection_tracker.cpp:67: Connection 0x7f32a42bc998 has been destroyed
> 20-03-2018 16:07:56.623 UTC [7f32aa704700] Verbose pjsip: tcps0x7f32a42b
> TCP transport destroyed with reason 70016: End of file (PJ_EEOF)
>
>
> On Tue, Mar 20, 2018 at 1:55 PM, Šindelka Pavel <sinde...@ttc.cz> wrote:
>
>> Hi Sunil,
>>
>> Please give some solution.
>>
>> Please give some information.
>>
>> From what you have sent so far it is clear that the 503 is coming from
>> some UAS which I guess is not another SIPp instance running an UAS script.
>> So either your UAC script in SIPp is sending something that makes that UAS
>> go crazy, or that UAS has some problem irrelevant to SIPp at all.
>>
>> Pavel
>>
>> Dne 20.3.2018 v 9:12 Sunil Kumar napsal(a):
>>
>> Hi team sipp,
>> I am getting SIP/2.0 503 Service Unavailable. Please give some solution.
>>
>> *[]ubuntu@stress:/var/log/clearwater-sip-stress$ cat
>> 21491_caller_errors.log*
>> sipp: The following events occured:
>> 2018-03-20 19:13:22.256018 1521553402.256018: Aborting call on
>> unexpected message for Call-Id '1-21501@1
>> 27.0.1.1': while expecting '183' (index 2), received 'SIP/2.0 503 Service
>> Unavailable
>> Via: SIP/2.0/TCP 127.0.1.1:41238;received=10.22
>> 4.61.13;branch=z9hG4bK-21501-1-0
>> Record-Route: <sip:scscf.sprout.ims.com;tran
>> sport=TCP;lr;billing-role=charge-term>
>> Record-Route: <sip:scscf.sprout. ims.com ;transport=TCP;lr;billing-role
>> =charge-orig>
>> Call-ID: 1-21501@127.0.1.1
>> From: <sip:2010000012@ ims.com >;tag=21501SIPpTag001
>> To: <sip:2010000045@ ims.com >;tag=z9hG4bKPjKAqRQhSEDZfI8vg
>> 52uWhPdLZWlb4.o7s
>> CSeq: 1 INVITE
>> P-Charging-Vector: icid-value="21501SIPpTag001";orig-ioi= ims.com
>> ;term-ioi= ims.com
>> P-Charging-Function-Addresses: ccf=0.0.0.0
>> Content-Length: 0
>>
>>
>>
>> Thanks,
>> Sunil
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Sipp-users mailing
>> listSipp-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/sipp-users
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Sipp-users mailing list
>> Sipp-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/sipp-users
>>
>>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
