[reSIProcate] 200/ACK retransmission Question

["Scott Godin" <slgodin@xxxxxxxxxxxx>]

On reception of a 200/invite right now the Invite session code will first check to see if it has already sent an ACK for this CSeq (the ACK map is maintained for 32s).

-          if we have sent an ACK before, then it just retransmit the ACK

-          if it can’t find an ack in the map, then we don’t consider this as a retransmission and we handle via Invite Session states and will end up sending an ACK using the CSEq from the last Invite request sent out.

 

Question:

1. Should we be verifying the CSeq in the 200 matches the last invite request sent out.   I’m sure the answer is yes.  J
2. If it doesn’t (and it wasn’t in the ACK map) – should we try to generate a new ACK, or just drop the 200?  Note:  If we try to generate a new ACK, then it will not be able to contain the Authorization headers – since we only store the last invite attempt.

 

Scott

 

PS.  I’m sure this is a known issue – but to completely fix all of this 200 retrans stuff, we also need to make a change that causes a Dialog to stay active for at least 32s after it has sent an invite – even if it sends or receives a BYE.  Does that make sense?