On Thu, 2008-11-20 at 12:17 -0500, M. Ranganathan wrote: > On Thu, Nov 20, 2008 at 12:07 PM, Arjun Nair <[EMAIL PROTECTED]> wrote: > > keccles wrote: > >> Robert Joly <rjoly <at> nortel.com> writes: > >> > >>>> http://track.sipfoundry.org/browse/XECS-1594 > >>>> > >>>> Hi, > >>>> > >>>> I am looking into using in-dialog OPTIONs to implement a > >>>> keep-alive mechanism for the MOH and park server. > >>>> > >> <snip> > >> > >>> As a point of reference, the NAT Traversal feature also relies on > >>> sending OPTIONS to keep NAT bindings alive and that is not causing any > >>> trouble with the phones that I tested with: LG, Polycom and Counterpath. > >>> > >> Is there any reason NOT to use exclusively OPTIONS for this keep alive? A > >> fix > >> was developed that uses OPTIONS for MOH but uses re-INVITEs for calls in > >> park > >> orbits. Using only OPTIONS would simplify this fix and simplify things for > >> sipXbridge. From Robert's NAT comment it semms unlikely to complicate or > >> break > >> other parkers (ie phones). > >> > >> Any objections to OPTIONS only? > >> > >> -Kathy > >> > > > > I agree that using only OPTIONs will simplify the code and the call > > processing, but I think re-INVITEs are a much more reliable way to do > > keep-alives. > > I dont see this as being an issue on a LAN. > > > When using in-dialog OPTIONs we are limited to parsing only a 404, 408, or > > 481 response, for marking dialogs as terminated. > > > Why? Any kind of response means the other end is alive.... perhaps I > don't understand the issue. If you use OPTIONS exclusively, I know > not to forward that OPTIONS message. Re-INVITEs are end to end. > The purpose of this keep alive is to tell whether the DIALOG still exists, not just the endpoint.
-Kathy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
