INVITE server transaction OK retransmissions don't stop after ACK

[GoogleCodeExporter]

First of all, thank you so much for sipml.

When sipml is a browser UAS, in an initial INVITE server transaction, after 
sipml sends OK and receives the ACK it doesn't stop sending OK retransmissions. 
To me it looks like the stx state machine doesn't connect the Accepted state to 
Confirmed/Terminated/Completed.

Attached is a quick patch for my testing that shortcuts the states. It works 
for me, but I am not sure about the overall purpose of your extended FSM, so it 
might be missing something.

Thanks for any advice.

Original issue reported on code.google.com by vladimir...@gmail.com on 1 Sep 2012 at 9:56

Attachments:

• sipml_ACK_fsm_loophole_fix.txt

[GoogleCodeExporter]

Thanks for the patch.
Is it possible to have wireshark trace reproducing the issue or tell us the sip 
server you're using?

Original comment by boss...@yahoo.fr on 4 Sep 2012 at 12:43

• Changed state: Accepted

[GoogleCodeExporter]

Attached is wireshark of two unpatched sipml clients. One is UAC role the other 
is UAS. The problem is in the UAS, you can see that it just keeps 
retransmitting the OK. I hope you have a nice websocket packet dissector to see 
it clearly though.

But may be it will be easier to focus on the code in this case. I just can't 
see even theoretical way of server transaction to transition from Accepted 
state to Completed or Terminated without error. Why does it make sense to stay 
in Accepted state after we receive ACK?

    tsk_fsm_entry.prototype.CreateAlways(tsip_transac_ist_states_e.ACCEPTED, tsip_transac_ist_actions_e.RECV_ACK, tsip_transac_ist_states_e.ACCEPTED, __tsip_transac_ist_Accepted_2_Accepted_iACK, "tsip_transac_ist_Accepted_2_Accepted_iACK"),

In most other stx FSMs I've seen the states moves onto COMPLETED or some linger 
state.

I am using a simple server based on the NIST JAIN SIP library.

Original comment by vladimir...@gmail.com on 4 Sep 2012 at 1:21

Attachments:

• sipml_ack_retrans.pcap

[GoogleCodeExporter]

Fixed in r90
The issue was that the timerX is not canceled.
The transaction MUST NOT transit from Accepted to Completed.
Two paths:
- Proceeding -> 300-699 -> Completed -> TimerH -> Terminated
or
- Proceeding -> 2xx -> Accepted -> TimerL -> Terminated

Original comment by boss...@yahoo.fr on 12 Sep 2012 at 2:45

• Changed state: Fixed