Subject: Re: [dispatch] [Sip-implementors] SIP OPTIONS "ping"

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 16 Aug 2010 09:17:03 -0400

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

> -----Original Message-----
> From: marius zbihlei [mailto:[email-masked]]
> Sent: Monday, August 16, 2010 6:00 AM
> To: Paul E. Jones
> Cc: [email-masked]; [email-masked]; 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
> > [email-masked]
> > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 16 Aug 2010 12:45:44 -0400

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

> Sent: Monday, August 16, 2010 10:04 AM
> To: Paul E. Jones
> Cc: [email-masked]; [email-masked]; 'Gonzalo
> Salgueiro'; 'Hadriel Kaplan'; [email-masked]
> > 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.
> > 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.
> >>> 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.
> >>
> >>>
> >> 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
> >>

---

From: Michael Miller <[email-masked]>
Date: Mon, 16 Aug 2010 17:18:06 -0400

The end the end OPTIONS ping sounds like a great ideal, but does this change this doc from more of a informational/best practice to some thing that would require a change to SIP (like a header or something). 

I'm new to this

Michael L. Miller
Sent from my Mobile Device

On Aug 16, 2010, at 12:45 PM, "Paul E. Jones" <[email-masked]> wrote:

> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 16 Aug 2010 18:54:09 -0400

We had a side discussion and reached agreement that this end-to-end procedure really ought to be a separate document. I think the scope of each is enough to justify two documents.

So, we'll collaborate to produce two separate documents. Whether those will be informational or standards track is TBD.

Paul

---

From: Michael Miller <[email-masked]>
Date: Mon, 16 Aug 2010 19:37:28 -0400

Ok. Sounds good. I like to help where I can. 

Michael L. Miller