<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.32.2">
</HEAD>
<BODY>
Understood that they do use re-invites, however the negotiation is conducted between the endpoints, whether the endpoints are effectively the softswitch B2BUA and a media gateway, or the 2 endpoints, however I can appreciate from the softswitch vendor perspective, this is simply not assured that ANY of the endpoints will support it.<BR>
<BR>
Metaswitch disregards this entirely and uses a global polling interval, with re-invites determined by the softswitch and not negotiated by endpoints, removing one more potential client side issue. <BR>
<BR>
Our Sylantro platofrm used RFC 4028 for this, and we encountered numerous issues where the endpoints simply wouldn't behave appropriately<BR>
<BR>
On Tue, 2011-06-07 at 17:00 -0400, Alex Balashov wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
On 06/07/2011 04:55 PM, anorexicpoodle wrote:
> Im not familliar with Broadsofts method, but Metaswitch does something
> similar, and instead of using session timers, uses regular re-invites to
> detect if all involved endpoints are still alive.
>
> We found this a little heavy handed with their stock timers, so we
> fiddled with it until we were happy.
>
> I suspect the rationale here is that using RFC 4028 depends on both far
> ends supporting that RFC, and implementing it properly, which takes the
> control out of the softswitch's hands. Using a re-invite as a polling
> mechanism guarantees the polling works with even older (or cheaper) SIP
> endpoints that dont support session timers.
What? RFC 4028 only requires that one endpoint support timers.
If the far end does not support them, the softswitch UA will take on the
refresher role and send the reinvites, and the other endpoint need not
support SSTs or know what they're for, but just to answer them.
If both endpoints support SSTs, they'll negotiate the refresher role
amongst themselves. But that's optional. In practice, the essence of
the standard _is_ the sending of periodic reinvites as a signaling-only
method of dead peer detection, not ping-pong between UAs.
From 4028 section 7.1:
"They are not needed, since the extension works even when only the
UAC supports the extension."
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>