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

[Byron Campen <bcampen@xxxxxxxxxxxx>]

	Yeah, but DUM never sees 100 Trying, which will have this effect  
(and DUM won't get a chance to bail).

Best regards,
Byron Campen

> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature