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

Reply via email to