[reSIProcate] 200/ACK retransmission Question

[Scott Godin]

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.  :-)
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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051103/1d8a91a0/attachment.htm>