On Thu, Nov 20, 2008 at 4:01 PM, Robert Joly <[EMAIL PROTECTED]> wrote: >> On Thu, Nov 20, 2008 at 3:00 PM, Arjun Nair <[EMAIL PROTECTED]> wrote: I>> > 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)
The problem is whether or not to forward Re-INVITE that I see from a UA. In sipxbridge, I maintain my own session timer with the iTSP (required) Many / most phones send OPTIONS for liveness testing. Then you have park server that now wants to send Re-INVITE. What do you want the bridge to do with it? How do I know it is a session timer and not a re-negotiation attempt with the ITSP? Since I cant distinguish between the two cases, I have to blindly forward it ( unless you want some really ugly <do-not-forward-if-reinvite-is-from-park-server> switch). Now I also need to forward Re-INVITE for reasons other than session timer. There are genuine use cases for end to end codec renegotiation - consider FAX and call transfer. So now I have a problem. How can I distinguish between the two usages of it ( i.e. codec renegotiation vs. liveness testing ) ? Since I cant in general do so, I have to blindly forward the re-INVITE. If you really must insist on not using OPTIONS, I would lean towards UPDATE rather than Re-INVITE. Ranga > -- 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
