1. Ah, that helps explain it! Thank you. [😊] Is the long form or short form
generally preferred?
2. Thank you, that did the trick. It now sees the entire scenario.
Messages Retrans Timeout Unexpected-Msg
INVITE ----------> 1 5 1
100 <---------- 0 0 0 0
180 <---------- 0 0 0 0
183 <---------- 0 0 0 0
200 <---------- E-RTD1 0 0 0 0
ACK ----------> 0 0
Pause [ 0ms] 0 0
BYE ----------> 0 0 0
200 <---------- 0 0 0 0
3. Interesting... I'll sniff traffic as it exits towards voicemail and verify
if it detects a checksum error.... No checksum errors showing up in Wireshark.
I'll try to comb through some more logs to see if I can turn anything up.
4.
$ grep localhost /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
13:40:50.338851 IP (tos 0x0, ttl 64, id 14685, offset 0, flags [DF], proto UDP
(17), length 551)
129.82.3.26.sip > 10.20.128.149.sip: [bad udp cksum 0x113a -> 0x15d2!] SIP,
length: 523
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 129.82.3.26:5060;branch=z9hG4bK-21667-1-0
From: sipp <sip:[email protected]:5060>;tag=21667SIPpTag001
To: 15500 <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected]:5060
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 133
v=0
o=user1 53655765 2353687637 IN IP4 129.82.3.26
s=-
c=IN IP4 129.82.3.26
t=0 0
m=audio 6000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Robert Remsik
ACNS
Desk Phone: 970 491 7120
[email protected]
________________________________
From: sindelka <[email protected]>
Sent: Thursday, August 4, 2016 1:09 PM
To: Remsik,Robert; [email protected]
Subject: Re: [Sipp-users] Troubleshooting a basic call
Robert,
1. adding </recv> after my recv tags which have already been closed by the /
right before the closing > was not the right thing to do. SIPp is not really
good in detecting wrong syntax in the scenario file, which explains why only
the initial INVITE and 100 are displayed on the runtime screen now after your
modification.
In fact,
<recv attribute1="value1" attribute2="value2"/>
is equivalent to
<recv attribute1="value1" attribute2="value2">
</recv>
but shorter. Of course, the longer variant is the only possible one for tags
which contain a body, like all cases of send or if the recv contains some
action, like ereg.
2. the actual mistake causing SIPp to complain about an undefined label was a
typo: a "-" (dash) instead of "_" (underscore) in the label name (after the
<recv response="407"/>)
3. the bad UDP checksum is likely to cause the voicemail server not to answer,
but I'm not sure it is a SIPp issue - normally, an application sends only the
payload to a protocol socket, and the calculation of checksums is a job of the
protocol stack in the kernel. If your network card eventually supports UDP
checksum offloading, it may be that the error doesn't actually exist, although
in such case I would expect the wrong value shown by tcpdump to be 0. To check
that, you'll need to capture the packets anywhere else at their way from the
sender to the recipient but at the sending machine (because there, the
capturing point is before the UDP checksum is calculated if the offloading is
used). If you can see the UDP checksum error after the packet has left the
sending machine, it is really there and likely to cause the receiving machine's
IP stack to drop the packet rather than deliver it to the application.
4. can you please run the tcpdump with -n option added, or place the output of
grep localhost /etc/hosts here?
It seems strange to me that the packet would have 127.0.0.1 as source address
as the localhost.localdomain fqdn suggests, but if it does, the voicemail might
to send the responses to itself if it looks at the source address of the
request packet rather than at the address given in the Via header.
P.
Dne 4.8.2016 v 20:34 Remsik,Robert napsal(a):
Thank you for the help! This is indeed my base case copy+pasted, just calling
into voicemail and then either voicemail hangs up or I hang up.
I added the modifications you suggested but I had to add </recv> after each
recv tag to have the program not throw an error of: (The label
'auth_challenge_received' was not defined (index 2, next attribute)). However
now the scenario only lists an invite and 100 message, not the full scenario
that I was expecting.
Interestingly the INVITE lists a bad UDP checksum. That might help explain why
I'm not getting a response back from anything.
12:35:17.894298 IP (tos 0x0, ttl 64, id 62100, offset 0, flags [DF], proto UDP
(17), length 891)
localhost.localdomain.sip > 10.20.128.149.sip: [bad udp cksum 0x128e ->
0xb0db!] SIP, length: 863
INVITE sip:[email protected];user=phone;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 129.82.3.26;branch=z9hG4bK-17371-1-0
From: "Robert Remsik"
<sip:[email protected]><sip:[email protected]>;tag=1
To:
<sip:[email protected];user=phone><sip:[email protected];user=phone>
CSeq: 1 INVITE
Call-ID: [email protected]<mailto:[email protected]>
Contact:
<sip:[email protected];transport=UDP><sip:[email protected];transport=UDP>
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
NOTIFY, PRACK, UPDATE, REFER
User-Agent: PolycomVVX-VVX_410-UA/4.1.8.0628
Accept-Language: en
Supported: 100rel,replaces
Allow-Events: conference,talk,hold
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 245
v=0
o=- 1470166919 1470166919 IN IP4 129.82.3.26
s=Polycom IP Phone
c=IN IP4 129.82.3.26
t=0 0
a=sendrecv
m=audio 6000 RTP/AVP 9 0 8 101
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
Messages Retrans Timeout Unexpected-Msg
INVITE ----------> 1 0
100 <---------- 0 0 0 0
<recv response="100" optional="true"/>
</recv>
<recv response="401" optional="true" auth="true"
next="auth_challenge_received"/>
</recv>
<recv response="407" auth="true"/>
</recv>
<label id="auth_challenge-received"/>
</recv>
Robert Remsik
ACNS
Desk Phone: 970 491 7120
[email protected]<mailto:[email protected]>
________________________________
From: sindelka <[email protected]><mailto:[email protected]>
Sent: Tuesday, August 2, 2016 9:12 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: [Sipp-users] Troubleshooting a basic call
Hi Robert,
if the scenario you've provided is a verbatim copy of the one you
actually use, not an edited version for illustration purposes, the
trouble is that you blindly fire a series of requests without waiting
for any response from the server. Normally, the authentication challenge
comes in a 401 or 407 response to the first INVITE, and the generation
of the authentication response as requested by the [authentication]
keyword depends on the information from the authentication challenge.
So you must insert some optional and mandatory <recv> statements between
the first INVITE and first ACK - namely,
<recv response="100" optional="true"/>
<recv response="401" optional="true" auth="true"
next="auth_challenge_received"/>
<recv response="407" auth="true"/>
<label id="auth_challenge-received"/>
This ensures that regardless whether the sipx device sends the 100 or
not, and regardless whether it uses 401 or 407 to send the
authentication challenge, you'll handle it properly.
Also, remove the auth="true" AVPs from all the <send> blocks, they are
useless there.
On top of that, please <recv> optionally a 100, a 180, a 183 and then
compulsorily a 200 between sending the second INVITE (with the
authentication response) and sending the second ACK, otherwise you may
run into some other issues.
And the last point, if you specify user and password inside the
scenario, SIPp does not use the -au and -ap specified on the command line.
Pavel
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/sipp-users
Sipp-users Info Page -
SourceForge<https://lists.sourceforge.net/lists/listinfo/sipp-users>
lists.sourceforge.net
This is the sipp users mailing list. Use it to get support for sipp or ask for
features or even post your own features to be included in sipp!
------------------------------------------------------------------------------
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
