I managed to figure out what was going on here. I discovered that the
problem as described only manifests for scenarios in which
*authenticated* INVITE's are in use. In that circumstance the ACK
which follows the 401 response incorrectly results in SIPp internal
state for that call-id being marked 'call_established=true'. In turn
that leads to BYE being sent on unexpected message rather than ACK.
I fixed the bug and created this patch (below) against the the file
call.cpp. I'll leave it to someone more knowledgeable than me to
decide whether or not to bless this and incorporate for next sipp
turnaround. At least in my testing of it w/ my scenario file the
default unexpected message behavior is now correct.
- Russ
*** call.cpp 2009-07-28 06:16:12.000000000 -0400
--- call.cpp.new 2010-02-22 13:02:22.000138000 -0500
***************
*** 1245,1252 ****
}
if (strcmp(msg_name,"ACK") == 0) {
- call_established = true ;
ack_is_pending = false ;
}
*send_status = send_raw(dest, index, *len);
--- 1245,1255 ----
}
if (strcmp(msg_name,"ACK") == 0) {
ack_is_pending = false ;
+ /* If 401 then INVITE is being challenged -- no call established. */
+ if (get_reply_code(last_recv_msg) != 401) {
+ call_established = true ;
+ }
}
*send_status = send_raw(dest, index, *len);
r...@cedarpointcom wrote:
> At one point the documentation for sipp 3.1 regarding the default
> behavior for unexpected messages states:
>
> "...if no 200 OK message has been received...(and) the unexpected
> message is a 4XX or 5XX, SIPp will send an ACK"
>
> At a later point the "online help" (sipp -h) is documented as such:
>
> -nd : No Default. Disable all default behavior of SIPp which
> are the following:
> - On UDP retransmission timeout, abort the call by
> sending a BYE or a CANCEL
> - On receive timeout with no ontimeout attribute, abort
> the call by sending a BYE or a CANCEL
> - On unexpected BYE send a 200 OK and close the call
> - On unexpected CANCEL send a 200 OK and close the call
> - On unexpected PING send a 200 OK and continue the call
> - On any other unexpected message, abort the call by
> sending a BYE or a CANCEL
>
> Notice that in this second description there's no mention of sending ACK
> under any circumstance.
> So, at the very least, it appears to me that there's conflicting info in
> the documentation.
>
> The correct response when a 4XX/5XX is rec'd prior to a call being
> connected is the first one -- to send ACK.
>
> In fact the current behavior of sipp 3.1 (2009-07-29) is to send BYE.
> Here's an excerpt for a single call id from the short message trace file:
>
> 2010-02-19 15:52:40:648 1266612760.648841 S
> 15729-31...@100.0.9.2 CSeq:1 INVITE INVITE
> sip:8252007...@10.99.25.253;user=phone SIP/2.0
> 2010-02-19 15:52:40:649 1266612760.649834 R
> 15729-31...@100.0.9.2 CSeq: 1 INVITE SIP/2.0 401 Unauthorized
> 2010-02-19 15:52:40:649 1266612760.649959 S
> 15729-31...@100.0.9.2 CSeq:1 ACK ACK sip:8252007...@8252007456:5060
> SIP/2.0
> 2010-02-19 15:52:40:850 1266612760.850845 S
> 15729-31...@100.0.9.2 CSeq:2 INVITE INVITE
> sip:8252007...@10.99.25.253;user=phone SIP/2.0
> 2010-02-19 15:52:40:852 1266612760.852562 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 100 Trying
> 2010-02-19 15:52:40:858 1266612760.858710 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:52:40:858 1266612760.858825 S
> 15729-31...@100.0.9.2 CSeq:3 BYE BYE
> sip:8252007...@10.99.25.253;user=phone SIP/2.0
> 2010-02-19 15:52:40:860 1266612760.860048 R
> 15729-31...@100.0.9.2 CSeq: 3 BYE SIP/2.0 481 Call/Transaction Does Not
> Exist
> 2010-02-19 15:52:41:358 1266612761.358890 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:52:42:358 1266612762.358308 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:52:44:358 1266612764.358286 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:52:48:358 1266612768.358527 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:52:52:358 1266612772.358358 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:52:56:357 1266612776.357566 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:53:00:357 1266612780.357227 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:53:04:357 1266612784.357154 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:53:08:357 1266612788.357302 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
> 2010-02-19 15:53:12:356 1266612792.356628 R
> 15729-31...@100.0.9.2 CSeq: 2 INVITE SIP/2.0 486 Busy Here
>
>
> I did a search of the mailing list archive on this topic and found one
> item which suggested that this was indeed working correctly (.ie sending
> ACK) but implied that one must be using one of the default embedded
> scenarios (i'm using custom.)
>
> I realize that I can make the call flow correct by handling 4xx/5xx as
> optional responses w/ branching etc within my custom scenario file, but
> in doing so these become no longer "unexpected" messages and thus don't
> show up in the error log, unexpected msg counts etc, which makes it not
> so satisfying a solution for me.
>
> - Russ
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
