[Sipp-users] UAC sending RTP packet with bad checksum

Discussion:

Paulo R. Vieira Jr

2016-10-28 16:39:27 UTC

Hi,

I'm trying to test the following scenario:

UAC (192.168.1.24) --->>> Asterisk (192.168.1.19) -->>> UAS (192.168.1.23)

UAS is started with -rtp_echo
UAC is started with uac_pcap.xml from sipp docs, playing g711a.pcap from
sipp.

In asterisk i just have a extension that call UAS. The problem is that UAC
send RTP packets but all with bad checksum, so they are discarded when they
arrive in linux machine.

I'm using ubuntu 16.04 and sipp 3.3-pcap, i've tried with other version
(3.2, 3.1) and i got the same thing, packets are received by the linux and
are not being delivered to asterisk. I can't see the packets with "rtp set
debug on" on asterisk.

With sipp 3.5 and 3.6-dev from git i've got segmentation fault when try to
send audio. send_packet.c send to failed with error: Invalid argument.

If i start the UAS with a scenario that play some pcap file, the packets
are received by linux correctly and they are sent to UAC.
If i start the UAC directly to UAS, same thing happens, the packets are
received by linux but not delivered to UAS, it shows "0 Total echo RTP
packets 1st stream", with wireshark i can see the packets, but all marked
with bad checksum.

As i said, i have tried with different version of sipp and different
machines, but same thing.

Any idea? Am i doing something wrong?
Thanks

--
Paulo.

sindelka

2016-10-28 16:47:03 UTC

Permalink

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

Paulo R. Vieira Jr

2016-10-28 16:59:47 UTC

Permalink

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.

Post by sindelka
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 CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
Sipp-users mailing list
https://lists.sourceforge.net/lists/listinfo/sipp-users

--
Paulo R. Vieira Jr

sindelka

2016-10-29 10:11:23 UTC

Permalink

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

Post by Paulo R. Vieira Jr
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.
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
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
https://lists.sourceforge.net/lists/listinfo/sipp-users

Paulo R. Vieira Jr

2016-10-29 14:39:16 UTC

Permalink

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.

Post by sindelka
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
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.

--
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
_______________________________________________
------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/sipp-users

--
Paulo R. Vieira Jr

sindelka

2016-10-29 15:52:09 UTC

Permalink

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

Post by Paulo R. Vieira Jr
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.
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

Post by Paulo R. Vieira Jr
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.
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/sipp-users