On 12-08 13:17, Andrew Fullford wrote:
BYEs are not reliable. They are initiated solely by
the UA, so
even with a completely reliable network, BYEs will go missing
if the user powers down or disconnects their system before
hanging up.
There is a partial solution if the other end-point is still alive. It
will send a BYE which will be replied with 408 Request Timeout by SER.
You can account such failed transactions too.
If both end-points fail then there is no chance to get a BYE, of
course :-). But this case is in my opinion negligible.
call_ids are not reliable. They are also created by
the UA,
and UAs have bugs. Even major vendors have released firmware
that does not produce unique call_ids.
Yes, that's true. Here you can use the triplet
<call-id, fromtag, totag>.
For the most part, these problems can be banged on
until they go away.
For the former you could do probing from the proxy to confirm calls are
still in progress. This is still a problem. What if the UA simply
ignores the probe? Then the proxy fakes a BYE to close the call but
the call (the RTP path) is still operating and the caller is now
talking for free. Instead, we use multiple accounting sources for
calls we are actually billing for and for SIP<->SIP we just ignore the
problem because we're not billing that path.
I suppose that you have a PSTN gateway in your hands. If you are lucky
then it will support session timer. Session timer gives you the
possibility to send keepalive SIP messages periodically (re-INVITEs),
if the gateway does not receive a proper reply then it will declare
the other end-point dead and terminate the call. Session timer support
in one end-device is enough to make it work. In addition to that
it is possible to detect a failure when the gateway does not receive
RTP traffic anymore (cisco can do it).
It is best to detect failures on the PSTN gateway if possible, because
that's the device that is burning up money.
Jan.