I've asked you to send me the pcap file, not the result of its
processing by cloudshark, but even this way I can see that there is a
blank space between the "sip:2010000081@" and "ims.com". No wonder that
the server goes crazy since what it gets on the INVITE line is not a
valid SIP uri.
Check To and From for the same issue.
P.
Dne 20.3.2018 v 13:42 Sunil Kumar napsal(a):
more-
2364
273.582105 10.224.61.13 10.224.61.22 SIP 1245 Request: REGISTER
sip:ims.com <http://ims.com> (1 binding) |
2365
273.596708 10.224.61.22 10.224.61.13 SIP 925 Status: 200 OK (1
binding) |
2402
280.504694 10.224.61.13 10.224.61.22 SIP/SDP 2264 Request:
INVITE sip:2010000081@ ims.com <http://ims.com> |
2404
280.506174 10.224.61.22 10.224.61.13 SIP 414 Status:
100 Trying |
2406
280.563608 10.224.61.22 10.224.61.13 SIP 703 *Status: 503
Service Unavailable |*
2463
291.567453 <tel:291567453> 10.224.61.13 10.224.61.22 SIP 1127
Request: REGISTER sip: ims.com <http://ims.com> (1 binding) |
2465
291.636028 <tel:291636028> 10.224.61.22 10.224.61.13 SIP 574
Status: 401 Unauthorized |
2467
291.636427 <tel:291636427> 10.224.61.13 10.224.61.22 SIP 1245
Request: REGISTER sip: ims.com <http://ims.com> (1 binding) |
2469
291.654531 <tel:291654531> 10.224.61.22 10.224.61.13 SIP 925
Status: 200 OK (1 binding) |
Frame 2406: 703 bytes on wire (5624 bits), 703 bytes captured (5624 bits)
Ethernet II, Src: PcsCompu_ff:d2:88 (08:00:27:ff:d2:88), Dst:
PcsCompu_ab:71:0f (08:00:27:ab:71:0f)
Internet Protocol Version 4, Src: 10.224.61.22, Dst: 10.224.61.13
Transmission Control Protocol, Src Port: rlm-admin (5054), Dst Port:
34312 (34312), Seq: 349, Ack: 2199, Len: 637
Session Initiation Protocol (503)
On Tue, Mar 20, 2018 at 6:06 PM, Sunil Kumar <skgola1...@gmail.com
<mailto:skgola1...@gmail.com>> wrote:
Thanks pavel,
I used cloudshark now i am able to see the sip. It showing the -
status: 401 unauthorized
29
2.299500 10.224.61.13 10.224.61.22 SIP 1123 Request:
REGISTER sip:ims.com <http://ims.com> (1 binding) |
34
2.314584 10.224.61.13 10.224.61.22 SIP 1123 Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
39
2.323569 10.224.61.13 10.224.61.22 SIP 1123 Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
41
2.332869 10.224.61.22 10.224.61.13 SIP 570 Status:
401
Unauthorized |
43
2.333258 10.224.61.13 10.224.61.22 SIP 1241 Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
47
2.335517 10.224.61.13 10.224.61.22 SIP 1123 Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
49
2.338780 10.224.61.22 10.224.61.13 SIP 570 Status:
401
Unauthorized |
51
2.339165 10.224.61.13 10.224.61.22 SIP 1241 Request:
REGISTER sip: ims.com <http://ims.com> (1 binding) |
52
2.344367 10.224.61.22 10.224.61.13 SIP 570 Status:
401
Unauthorized |
so what i need to do to fix this issue.
On Tue, Mar 20, 2018 at 5:30 PM, Šindelka Pavel <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>> wrote:
Show me all the parameters you start sipp with, and send me
the file. tcpdump won't show you that SIP is inside the IP
packets unless you add some other command line options. That's
why I've told you to open the file using Wireshark. You can
use cloudshark.org <http://cloudshark.org> if you don't want
to install Wireshark locally.
P.
Dne 20.3.2018 v 12:46 Sunil Kumar napsal(a):
Hi pavel,
Thanks again. I tried tcpdump in parallel but there is no SIP
i found all are IP, STP, ARP etc.
*[]ubuntu@stress:~$ sudo tcpdump -i eth0 -s 0 -w 0007.pcap*
following i used to read the .pcap file-
*sudo tcpdump -r 0006.pcap*
thanks,
sunil
On Tue, Mar 20, 2018 at 4:13 PM, Šindelka Pavel
<sinde...@ttc.cz <mailto:sinde...@ttc.cz>> wrote:
Sunil,
the exact command would be
tcpdump -i interface_name -s 0 -w
/tmp/some_file_name.pcap port x.y.z
where:
- interface_name is the name of the interface through
which the machine running sipp communicates with the
machine where the server sending the 503 is running; if
both run at the same machine, the interface name would be lo
- /tmp/some_file_name.pcap is the name of the resulting file
- xyz is the tcp or udp port at which the server is
listening.
The typical reason why a server would send 503 is that it
has some serious problem, either with your message (such
as when you send a message using a TCP transport and
indicate an UDP Via), or it has some internal problem
which is not related to the received message in
particular. The server logs should tell you more but
those log messages you've sent were not related.
Pavel
Dne 20.3.2018 v 10:07 Sunil Kumar napsal(a):
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 <mailto: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 <http://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 <tel:01082712>
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 <http://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
<mailto:sip%3Apoll-sip@10.224.61.22>>;tag=683401
To: <sip:poll-sip@10.224.61.22
<mailto:sip%3Apoll-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
<http://10.224.61.22:5052>: got incoming TCP
connection from 10.224.61.8:40825
<http://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 <mailto: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.224.61.13;branch=z9hG4bK-21501-1-0
Record-Route: <sip:scscf.sprout.ims.com
<http://scscf.sprout.ims.com>;transport=TCP;lr;billing-role=charge-term>
Record-Route: <sip:scscf.sprout. ims.com
<http://ims.com>
;transport=TCP;lr;billing-role=charge-orig>
Call-ID: 1-21501@127.0.1.1
<mailto:1-21501@127.0.1.1>
From: <sip:2010000012@ ims.com <http://ims.com>
>;tag=21501SIPpTag001
To: <sip:2010000045@ ims.com <http://ims.com>
>;tag=z9hG4bKPjKAqRQhSEDZfI8vg52uWhPdLZWlb4.o7s
CSeq: 1 INVITE
P-Charging-Vector:
icid-value="21501SIPpTag001";orig-ioi= ims.com
<http://ims.com> ;term-ioi= ims.com
<http://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 list
Sipp-users@lists.sourceforge.net
<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users
<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
<mailto:Sipp-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/sipp-users
<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