[reSIProcate] DUM: Detecting Stale Re-Invites

[Byron Campen]

	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/10138da8/attachment.bin>