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

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


Excellent point. I agree - we need a timer....oops.

On 10/1/07, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> Yes - you are right.  All of this doesn't really matter though.  The
> fact that the stack get's a 100 - is enough to stop it from generating a
> 408.
>
> > -----Original Message-----
> > From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf
> > Of Jason Fischl
> > Sent: Monday, October 01, 2007 3:50 PM
> > To: Byron Campen
> > Cc: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > Subject: Re: [reSIProcate] DUM: Detecting Stale Re-Invites
> >
> > I was pretty sure that dum did see 100 Trying since we have a callback
> > in DialogSetHandler.
> >
> > On 10/1/07, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
> > >         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
> > > >>
> > > >>
> > > >>
> > >
> > >
> > >
>
>