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. This was done to support phones that don't support OPTIONs. So, not only are we relying on the far-end phones to send back the correct error response, but we are also assuming that they see a difference between in-dialog OPTIONs and out-of-dialog OPTIONs. > > > Arjun > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
