[reSIProcate] DUM behaviour when ACK not received for a re-invite

[Robert Sparks]

So what does it mean that we didn't get a 200-ACK:

We've been dutifully retransmitting the 200, so either the far end is
not getting it from us, or its 200-ACK is not getting back to us. We  
have
no way to know which, and that's what makes this hard to recover from.

If we simply revert to pre-reinvite state, we can be out of sync with  
the far
end if its the 200-ACK that's getting lost.

If we are agressive with trying to signal return to a different  
state, we're likely
to run into the same problem that led to not getting the 200-ACK in  
the first
place.

That's why the code, by default, right now decides to bail with a  
BYE. There's
nothing better to do in general. (And it shouldn't make any  
difference whether
there should have been an answer in that ACK - the out-of-sync scenario
exists either way).

Any app using the DUM needs to be able to override this behavior if
the special circumstances it operates would allow it to more  
deterministically
recover.

RjS

On Oct 31, 2005, at 5:03 PM, Derek MacDonald wrote:

> The current behavior for a UAS not receiving the ACK to its 200/INV  
> is:
>
>
>
> If the ACK would have contained an answer, go fall back to the pre- 
> reinvite state.
> If the state is Answered or Connected, call OnAckNotReceived, which  
> by default sends a BYE.   Also, the local SDP variables are updated  
> in the transition to Answered, so DUM currently does not have the  
> previous SDP information if OnAckNotReceived does not send a BYE.
>
>
>
> The main question is:  should ACK failure for a re-invite end the  
> dialog?
>
>
>
> --Derek
>
>
>
>
>
> CONFIDENTIALITY NOTICE
>
> This email and any files transmitted with it contains proprietary  
> information and, unless expressly stated otherwise, all contents  
> and attachments are confidential. This email is intended for the  
> addressee(s) only and access by anyone else is unauthorized. If you  
> are not an addressee, any disclosure, distribution, printing or  
> copying of the contents of this email or its attachments, or any  
> action taken in reliance on it, is unauthorized and may be  
> unlawful. If you are not an addressee, please inform the sender  
> immediately and then delete this email and any copies of it. Thank  
> you for your co-operation.
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel