I'm not sure I understand what you wanted to achieve.
An endpoint (i.e. not a forking proxy) is expected to send a single
final response for a single INVITE received. In your example, it would
be either the 408 or the 491, but not both. That is why I've suggested
condexec - it allows to easily implement "send just one out of N
possible messages" in a plain scenario flow, without need to use tons of
"label"s and "next", "test" jumps.
So when simulating a normal call flow (rather than testing the DUT's
handling of anomalies), your UAC scenario should send an INVITE, wait
for reception of a single final response, and send an ACK upon reception
of the response.
So once your UAS scenario has sent the 408, it should proceed to
awaiting an ACK. Instead, you've made it wait for another 5 seconds
before ending. For the 491 case, you've tested the retransmission
capability of the UAC by not responding the INVITE with anything at all
for 5 seconds.
The UAC scenario is even worse, as it expects a 491 to come after it has
already received a 408 for a given INVITE. Instead, I would have used
this in the UAC scenario:
<recv response="408" crlf="true" optional="true"/>
<!-- as many <recv response="xxx" optional="true"/> as necessary -->
<recv response="491" crlf ="true"/> <!-- the last one must NOT be optional
-->
<send>
<![CDATA[
ACK sip:...
]]>
</send>
Each scenario's error log should tell you exactly what was the "dead
call message". A dead call message is one which has the same Call-ID
like "normal" messages but it arrives after the last message with such
Call-ID and foreseen by the scenario has been received or sent.
Pavel
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
