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

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
> >>
> >>
> >>
>
>
>