> On Thu, Nov 20, 2008 at 3:00 PM, Arjun Nair <[EMAIL PROTECTED]> wrote: > > M. Ranganathan wrote: > >> > >> 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. > >> > > > > It's ok if the re-INVITEs are end to end (as long as the > park-server gets a response back). Are there any issues with > forwarding the re-INVITEs? If indeed there are problems with > that, we could probably work in an exception for sipXbridge. > > I send my own session timers to the ITSP. Those session > timers are INVITEs. Now I have to forward your session timers as well. > > ALL phones send OPTIONS. Why should the park server be different?
We need to make sure we understand the intent here. The goal here is to check whether a *dialog* is active on a given endpoint. As you say, OPTIONS is typically used by phones but their goal is to either refresh a NAT binding or to verify that the server is still alive - they do not typically care about individual dialogs. This is a different goal than ours. After thinking about it and reading the debates, I reckon that reINVITE is a better way of testing for dialog liveliness for three reasons: 1- Some endpoints may not respond to OPTIONS 2- For those that do, they need to be well-behaved and reply with 481 Call/Transaction Does Not Exist when we send an OPTIONS within a dialog that has already been torn down. If an endpoint does not check for dialog existence, or it sends the wrong response code when the dialog doesn't exist then we run into interop issues. 3- IETF has already thought about that problem space and concluded that reINVITEs (or UPDATEs) are the best way of testing for dialog liveliness (see RFC4028) _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
