> 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? > > In sipxbridge, I maintain my own session timer with the iTSP > (required) > > Many / most phones send OPTIONS for liveness testing. Leveliness of what? Dialog or endpoint? 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? I'm missing the background information. The pre-condition for all these discussions is the knowledge that sipXbridge needs to treat session timer and re-negotiations differently but I do not know why this has to be true. Please provide some background info that would explain why a differentiation is required in the first place. That will help me (and hopefully others) understand the types of technical challenges you face at your end and will help us better converge on the right solution. > Since I cant distinguish between the two cases, I have to > blindly forward it ... And that is bad because <fill in> ( 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. Support for UDPATE is not widespread enough the be relied upon for this purpose. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
