< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] DUM: Detecting Stale Re-Invites


I may have misunderstood but why do we need a timer at all? Can't we
just tear down the dialog with a BYE if we receive a 408 to the
reINVITE?

On 10/1/07, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
>
>
>
>
> DUM currently has a mechanism to detect stale initial client invite
> sessions, ie. those that receive a provisional response, but never a final
> response.  We do this by starting a Stale call timer and tearing the usage
> down if it fires.
>
>
>
> We do NOT have a similar mechanism for re-INVITES
>
>
>
> Consider the following scenario:
>
> -          We have an established Invite Session
>
> -          The remote UA goes "offline"
>
> -          DUM sends a re-INVITE request (either user initiated or session
> timer refresh)
>
> -          The stack receives a 100 Trying from the first hop proxy – so we
> will never see a 408 generated to DUM.
>
> -          DUM is now stuck in the SentReInvite state.
>
> -          Calling end(), causes a transition into the WaitingToTerminate
> state, where we will wait forever for the final response to the reInvite
> request.
>
> -          Apparently calling end() a second time, will cleanup the usage,
> but this means the application must be responsible for this, and it is not
> very clean
>
>
>
> Note: mid-dialog non-INVITE transitions will always see a 408 if no final
> response is seen.
>
>
>
> I propose we add a ReInviteStaleCall timer to the DUM state machine in order
> to be able recover better from this situation.  The timer can be relatively
> short (say 32seconds) since this is a re-INVITE and a final response is
> expected to be fast.
>
> 1.        Timer is started when we send a re-INVITE.
>
> 2.       Time is effectively stopped when we get a final response to the
> re-INVITE.
>
> 3.       If timer fires in the SentReInvite or WaitingToTerminate states,
> then we continue to send a BYE and tear down the usage.
>
>
>
> Make sense?
>
>
>
> Scott
>
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>