[reSIProcate] DUM: Detecting Stale Re-Invites

[Scott Godin]

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

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20071001/0734d9bf/attachment.htm>