[reSIProcate] DUM: Detecting Stale Re-Invites

[Byron Campen]

	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 at estacado.net> 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 at icescape.com> 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 at resiprocate.org
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>>
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20071001/40cef4ef/attachment.bin>