Hi Paulo,
that's unbelievable. Can you attach your UAC scenario and the pcap you
are replaying, and the complete pcap of the result as taken on the
Asterisk machine?
As a workaround, I'd suggest to use a dirty trick, allowing you to
convert your UAC scenario into an UAS one as seen by SIPp while
maintaining its functionality as seen by the Asterisk. To do so, insert
the following before the initial
|<send retrans="500">||
|| <![CDATA[||
|| INVITE ...|
of your UAC scenario:
<recv request="INVITE" optional="true" />
<recvCmd/>
Then, create a "trigger" scenario:
|<scenario name="3pcc trigger">||
|
| <send>||
|| <![CDATA[||
|||| INFO||
|| ]]>||
|| </send>||
|
| <sendCmd>||
|| <![CDATA[||
|| Call-ID: [call_id]||
|| ]]>||
|| </sendCmd>||
|| <pause milliseconds="whatever_the_duration_of_your_test_call +
10000"/>||
||
</scenario>|
Then, run your modified UAC scenario first, with an additional command
line parameter |-3pcc localhost:9001| and without the parameters
controlling the call rate and number of calls (|-r|, |-rp|, |-m|). As it
is an UAS one now, it will start and do nothing spontaneously, just
waiting for external stimuli to come. Next, run the trigger scenario,
with the same|-3pcc localhost:9001| command line parameter and the
parameters controlling the call rate and number of calls, and with
destination address |localhost:xxxx| (where |xxxx| is a UDP port at
which nothing is listening at the machine).
What will happen: by adding the |<recv>| to the beginning of your
originally UAC scenario, we've made it an UAS one, so the |pcapplay|
should start working if the UDP checksum issue really depends on UAS/UAC
mode of the scenario. A UAS scenario does not generate call IDs and
initiate calls, so we must provide that using the trigger scenario. In
order to make SIPp treat the trigger scenario as an UAC one, its first
statement must be |<send>|, so we send a bogus SIP message to a
blackhole first. Right after, the trigger scenario sends a 3pcc command
to the main one. Reception of the 3pcc command triggers the execution of
the rest of the main scenario, which uses the call ID value extracted
from the received command. The pause in the trigger scenario is
necessary because the call in the trigger scenario must not finish
before it finishes in the main one.
Hope that helps get you up and running.
Pavel
Dne 29.10.2016 v 16:39 Paulo R. Vieira Jr napsal(a):
Hi,
I made a role`s swap, the machine that was UAS became UAC, and the
machine that was UAC became UAS, and the packets comming from UAS
arrive correctly to asterisk and asterisk send to UAC, but the packets
comming from UAC aways had a bad checksum, so i can only simulate one
way audio to the load test. Seens like the problem is in the
method/procedure that sends packets from UAC if not the same that
sends from UAS.
Thanks.
2016-10-29 8:11 GMT-02:00 sindelka <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>>:
Sorry, I was too quick when reading your initial message because
99% of "bad UDP checksum" cases are resolved this way.
So reading it more carefully now, when you've mentioned trying
different machines, did you try to swap the roles of the two
machines running the UAC and UAS scenarios? I.e. can you confirm
that if you run the UAC scenario with its RTP-containing pcap on
the machine which replays its own RTP-containing pcap properly if
the replay is spawned from an UAS scenario, the packets come to
the Asterisk with a bad UDP checksum as well? And, vice versa, do
the RTP packets sent from an UAS scenario running on the
previously UAC machine have a correct UDP checksum on arrival to
the Asterisk machine?
If both answers are "yes", this would mean that the behaviour
depends on whether the pcapplay is executed from an UAC or an UAS
scenario. This is hard to believe, yet it would allow to suggest a
workaround.
Pavel
Dne 28.10.2016 v 18:59 Paulo R. Vieira Jr napsal(a):
Hi, thanks for response.
They are all (uas, asterisk and uac) on different machines. The
packets were captured on asterisk server. The packets are not
being delivered to asterisk, with "rtp set debug on" no packets
are seen.
The server stays 98% 99% idle.
The firewall is disable, the ports are correct and sip exchange
messages too. i have no idea what to do...
Thanks.
2016-10-28 14:47 GMT-02:00 sindelka <sinde...@ttc.cz
<mailto:sinde...@ttc.cz>>:
Hi Paulo,
on which machine did you run Wireshark/tcpdump? The thing is
that the
UDP/TCP/IP checksums are often wrong in the capture if
capturing on the
sending machine because the frame is captured before the
checksum is
actually calculated. So it may be just a red herring and the
actual
problem may be somewhere else.
Pavel
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET <http://ASP.NET> CLI. Get your
free copy!
http://sdm.link/telerik
_______________________________________________
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>
--
Paulo R. Vieira Jr
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET andASP.NET <http://ASP.NET> CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
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>
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers Did the
resurgence of CLI tooling catch you by surprise? Reconnect with
the command line and become more productive. Learn the new .NET
and ASP.NET <http://ASP.NET> CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________ 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>
--
Paulo R. Vieira Jr
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
