On 11/21/08, Robert Joly <[EMAIL PROTECTED]> wrote: >> 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. > > Can you expand on why that is a problem?
I already to session timer support for interaction with the ITSP since I cannot rely upon UAs to provide session timer re-INVITE. I hence have no need to forward your session timer INVITE. Please make sure the inbound SDP session version for re-INVITE is unchanged when you send the session timer INVITE. I can then distinguish it from a media renegotiation attempt and refrain from forwarding it. > Support for UDPATE is not widespread enough the be relied upon for this > purpose. > OK. We'll go with re-INVITE. -- 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
