Thanks Paul.
//
Its reasonable for checking general availability of the UA, assuming of
course that you know the URI of the UA, rather than just of the AOR.
Thanks,
Paul
> BR,
> Manoj
>
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi...@cisco.com]
> Sent: Sun 8/9/2009 2:48 AM
> To: Manoj Priyankara [TG]
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] SIP OPTIONS
>
>
>
> Manoj Priyankara [TG] wrote:
> > Dear All,
> >
> > According to the RFC 3261, SIP OPRIONS message should be used to
query
> > the statue of other UAC or the UAS. Is it OK to use the OPTIONS as
a
> > keep alive message to know whether the UAS is alive?
> >
> > Is it necessary to send the OPTIONS message from a registered user
or is
> > it possible to send the OPTIONS message from a general user and get
200-
> > OK as the response?
>
> Its not entirely clear what you want to determine by using OPTIONS.
>
> Are you looking to verify the liveness of your peer UA in a dialog?
> If not, what?
>
> OPTIONS isn't a good choice for testing the peer in a dialog.
> If you send it in-dialog (using the remote target, route set, call ID,
> from and to tags of the dialog), then presumably it will follow the
path
> of dialog. But when it reaches the UAS, according to 3261 it is
supposed
> to treat the same as an OPTIONS received out of dialog. Its not
entirely
> clear what that means. It might mean that it could succeed even though
> the UA has lost track of the dialog. (Consider for instance that the
UA
> has rebooted and lost all state.)
>
> Because the handling is somewhat ambiguous in this case, you can't
trust
> the results to report what you want to know.
>
> To test the liveness of your peer in an invite dialog you are better
off
> to use reINVITE or UPDATE.
>
> Thanks,
> Paul
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
