Re: [reSIProcate] DUM: Detecting Stale Re-Invites
Ah, good point. In fact, I think we don't handle the provisional
response case on a reinvite correctly right now anyways. At least, the
last time I looked we didn't.
On 10/1/07, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
> We won't get a 408 if the other end sends a provisional.
>
> Best regards,
> Byron Campen
>
> > 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
> >>
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxx
> > https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
>