> 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.
So, if I understand correctly, the problem is one of unecessary overhead? Given that Arjun's re-INVITE is once every 5 minutes for held calls, I do not think this represents any kind of load to lose sleep over unless I'm missing something. > > 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
