Menu

#94 ACK of error final response not in message history

open
kitcat (30)
6
2011-05-19
2011-01-05
Eric
No

In this code fragment:

caller.call(callee);
pause(2000);
callee.sendResponse(486);
pause(2000);
assertThat(callee, has(recvdRequest("ACK")));

The assertion fails even though the callee has received ACK. Message history does not show the received ACK:

[junit] </message>
[junit]
[junit] 4732 [main] INFO KitCAT.Tester - test failed
[junit] java.lang.AssertionError: TestName = org.echarts.test.sip.examples.SelfTests.testBusyError
[junit]
[junit] Expected: message present in message history - request with method ACK
[junit] got: <Agent Bob
[junit] ================Current state = Ended
[junit] null:Idle:MsgRecvd - INVITE sip:Bob@135.207.176.147:23456 SIP/2.0(CSeq:1 INVITE)
[junit] null:Invited:MsgSent - SIP/2.0 486 Busy here(CSeq:1 INVITE)
[junit] >

Discussion

  • Eric

    Eric - 2011-05-19

    required by user.

     
  • Eric

    Eric - 2011-05-19
    • priority: 5 --> 6
     
  • Jack Lucas

    Jack Lucas - 2012-09-27

    This behavior is caused by the fact that the NIST JAIN SIP stack does not pass the ACK for an error response to KitCAT. (The NIST JAIN SIP stack is acting as the SIP transaction layer, and this behavior is correct.) Because KitCAT never sees the ACK, it does not appear in the message history and any assertion about receiving the ACK will fail.

    I've investigated and found that it would be possible to fix this. The NIST stack has a property , gov.nist.javax.sip.PASS_INVITE_NON_2XX_ACK_TO_LISTENER, that is false by default. When set to true, the ACK to an error response will be passed to KitCAT.

    The fix would require:
    -- Changing org.echarts.jain.sip.E4JSHelper.createSipStack() to set the property above. (The code already sets a number of other properties.)

    -- Changing the FSM that runs when a SIPAgent is handling an INVITE server transaction. (InvitedFSM.ech) Currently, the FSM sends an error response and immediately transitions to the FAIL state. The FSM would need instead to transition to a new state where it waits for an ACK on the SIP port. Once the ACK is received, it would transition to the FAIL state.

     

Log in to post a comment.