[ S N O M 4 S N A T F I L T E R ]
4.4.2 Call Timeouts
Unfortunately, in SIP little attention has been given to the prob- lem of a user agent disconnecting from the network without further no- tification. This situation typically occurs on power failure or system crash or when the Internet connection becomes unavailable. In these cases the filter needs to disconnect the call.
Even more unfortunate, there is no way this problem can be ad- dressed. Therefore, the filter uses several mechanisms to check if the call is still alive.
The first way to find out if the call is still alive is to send OPTIONS requests to the user agents directly connected to the filter. The OPTIONS are sent outside of the dialog, because sending them inside the dialog would cause a sequence numbering problem. If no response comes back, it is an indication that the user agent is not connected any more (the reverse it not necessarily true: some user agents boot up so fast that op- tions responses might be returned in time). The Refresh Interval tell the filter after how many seconds it should send; the No Response Timeout tells the filter how long it should wait for a response.
If there is absolutely no media, this is also a fairly good indica- tion that the call is over. The setting No Media Timeout defines how many seconds the filter will tolerate calls without media. This setting only applies when any media has been received at all. This means if you, for example, had started an instant messaging session without any media, the filter will not remove this session because of a media timeout.
Another famous case is one way audio. Imagine a user agent calling a mailbox and then crashing/rebooting. The media server will play
Another famous problem in SIP is to detect when the call is really over. In SIP, it is possible to challenge a request and wait for a relatively long time until the challenge is answered (for example, if the user has to answer the challenge by entering some data). If the challenged request
4.