On Thu, 2008-10-16 at 18:50 -0400, Arjun Nair wrote: > http://track.sipfoundry.org/browse/XECS-1594 > > Hi, > > I am looking into using in-dialog OPTIONs to implement a keep-alive > mechanism for the MOH and park server. > > >From the RFC: > > 11.2 Processing of OPTIONS Request > > An OPTIONS request received within a dialog generates a 200 (OK) > response that is identical to one constructed outside a dialog and > does not have any impact on the dialog. > > This use of OPTIONS has limitations due to the differences in proxy > handling of OPTIONS and INVITE requests. While a forked INVITE can > result in multiple 200 (OK) responses being returned, a forked > OPTIONS will only result in a single 200 (OK) response, since it is > treated by proxies using the non-INVITE handling. See Section 16.7 > for the normative details. > > > I don't think this limitation affects us.. While using re-INVITEs > would be ideal for keep-alives, most phones don't don't seem to > support handling re-INVITEs from the MOH server. Does anyone have > opinion against this method?
The forking issue above doesn't apply in our case, since the Route set of the dialog will prevent any forking. Note that if the remote system doesn't support OPTIONS, you may get an error back - the key will be to accept any error except on that indicates that it can't find the dialog. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
