Re: [sip-ops] [Sip-implementors] SIP OPTIONS "ping"

["Paul E. Jones" <[e-mail]>]

Marius,

There is another important consideration to give to this.  The OPTIONS
"ping" we described was intended to be between a device and its next hop.
What you would actually want is an OPTIONS that goes end-to-end.

I think both need clarification, but I'm now thinking that perhaps we ought
to document these separately.  Of course, I'd be happy to work with you on
both.

Paul

> -----Original Message-----
> From: marius zbihlei [mailto:[e-mail]]
> Sent: Monday, August 16, 2010 10:04 AM
> To: Paul E. Jones
> Cc: [e-mail]; [e-mail]; 'Gonzalo
> Salgueiro'; 'Hadriel Kaplan'; [e-mail]
> Subject: Re: [Sip-implementors] SIP OPTIONS "ping"
> 
> Paul E. Jones wrote:
> > Marius,
> >
> > It is certainly true that we were focused entirely on out-of-dialog
> > OPTIONS messages when we wrote the draft.  I'm certainly not opposed
> > to also including in-dialog OPTIONS exchanges if it fit smoothly within
> the draft.
> > Alternatively, we could create two drafts.
> >
> > Would you like to draft some initial text for in-dialog and see if it
> > makes sense to include it in this same draft or a separate one?  If in
> > the same draft, then perhaps in-dialog and OOD would be two separate
> sections?
> >
> > Paul
> >
> >
> Hello again,
> 
> I would gladly draft some initial text around this idea, but I am a little
> torn apart between what I expect from the draft(and current
> implementations) and what previous standards say.
> 
> Quote from RFC 3261
> 12.2.2 UAS Behavior "Requests that do not change in any way the state of a
> dialog may be received within a dialog (for example, an OPTIONS request).
> They are processed as if they had been received outside the dialog."
> 
> Along with other texts[1], this means that in-dialog OPTIONS requests
> should be treated as OOD(also the thread I have linked seems to suggest
> that). But I know for certain that lots of implementors do return a 481,
> and several services rely on that error code to check if a dialog is still
> running. I know about SIP Session Timers but using OPTIONS ping like
> this(to discover if a dialog has finished) has some benefits(like the
> proxy being able to terminate a call , which is not possible using SST
> [2]), and more and more this looks like a "de facto" behavior.
> 
> With this in mind, I have to ask the question: Should we allow (or
> inforce) the 481 response for a in-dialog OPTIONS request(if the dialog
> does not exits)(this is what I personally want and many implementors
> already do), or should we respond with a 200 OK regardless if the dialog
> exists or not?!
> 
> Thank you in advance for answering this.
> 
> [1] RFC 5057 section 5.3: "OPTIONS does not belong to any usage. Only
> those failures discussed in Section 5.1 and Section 5.2 that destroy
> entire dialogs will have any effect on the usages sharing the dialog with
> a failed OPTIONS request."
> 
> This in fact might prove usefull, as a failed in-dialog OPTIONS request
> will guaranty that the dialog will not be destroyed
> 
> [2] http://www.rfc-editor.org/rfc/rfc4028.txt
> 8.3. Session Expiration
> 
> When the current time equals or passes the session expiration for a
> session, the proxy MAY remove associated call state, and MAY free any
> resources associated with the call. Unlike the UA, it MUST NOT send a BYE.
> >> -----Original Message-----
> >> From: marius zbihlei [mailto:[e-mail]]
> >> Sent: Monday, August 16, 2010 6:00 AM
> >> To: Paul E. Jones
> >> Cc: [e-mail]; [e-mail]; Gonzalo
> >> Salgueiro; Hadriel Kaplan
> >> Subject: Re: [Sip-implementors] SIP OPTIONS "ping"
> >>
> >> Paul E. Jones wrote:
> >>
> >>> Folks,
> >>>
> >>>
> >>>
> >>> Gonzalo and I produced an Internet Draft aiming at trying to bring
> >>> some consistency to the way in which SIP user agents implement an
> >>>
> >> OPTIONS "ping"
> >>
> >>> procedure.  It seems that a very large number of vendors do this,
> >>> but unfortunately, there seems to be little consistency.
> >>>
> >>>
> >>>
> >>> Initially, we positioned the document as a standards track RFC,
> >>> since this essentially builds on RFC 3261.  However, there was some
> >>> pushback from folks in the IETF for a variety of reasons, not the
> >>> least of which is the fact that there is no working group chartered
> >>> to do the work.  We don't feel this one draft warrants the creation
> >>> of a working
> >>>
> >> group.
> >>
> >>>
> >>> So, we've got three options we can consider:
> >>>
> >>> 1)      Forge ahead outside of a working group
> >>>
> >>> 2)      Change the status of the draft to Informational
> >>>
> >>> 3)      Forget about the draft and let every SIP device do it the way
> >>>
> >> they
> >>
> >>> want, throwing hope of consistency out the window
> >>>
> >>>
> >>>
> >>> (Yeah, you can tell I prefer not to go for the third option.)
> >>>
> >>>
> >>>
> >>> In any case, I'd like to get feedback from the on the SIP operators
> >>> and SIP implementers lists.  Do you think it's worth trying to
> >>> address
> >>>
> >> this issue?
> >>
> >>> If so, which option do you think we should pursue?
> >>>
> >>>
> >>>
> >>>
> >> Hello,
> >>
> >> I have read the draft and as far I can tell it addresses OPTIONS
> >> outside a dialog. I know that this has already been discussed on this
> >> mailing list[1], but there still are many vendors/SIP implementors
> >> that use a in- dialog OPTIONS to figure out if a dialog is still
> >> running(if not the UAS "will" respond with a 481- Call does not
> >> exist). By reading the comments and the RFC I know this is wrong(a
> >> UAS might return a 200 OK even if the dialog does not exist), but I
> >> think this enters into the "3) Forget about the draft and let every
> >> SIP device do it the way they want, throwing hope of consistency out
> the window " category.
> >>
> >> My first reaction is also to address this topic in the draft. What do
> >> you think?
> >>
> >> Marius
> >>
> >> [1]https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-
> >> May/019278.html
> >>
> >>> Note that we're certainly open to feedback on the draft.  I'd prefer
> >>> it to have a few more "MUST" statements in the text, rather than
> >>> "SHOULD".  But, we need to find that right balance:
> >>>
> >>> http://tools.ietf.org/html/draft-jones-sip-options-ping
> >>>
> >>>
> >>>
> >>> Paul
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Sip-implementors mailing list
> >>> [e-mail]
> >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >>>
> >>>
> >>>
> >
> >
> >
> >