| < Previous by Date | Date Index | Next by Date > |
| Thread Index | Next in Thread > |
|
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 |