Subject: [sip-ops] SIP OPTIONS "ping"

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 12 Aug 2010 01:14:34 -0400

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?

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 12 Aug 2010 08:45:25 -0400

I think this is needed, and I would go for informational.  While I sort of understand that you are "pushing" the definition of OPTIONS, if it was PS, you wouldn't update any RFCs, right?

Brian

On Aug 12, 2010, at 1:14 AM, 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:
> 3)      Forget about the draft and let every SIP device do it the way they want, throwing hope of consistency out the window
>  
> 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?
>  
> 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:
> _______________________________________________
> sip-ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-ops

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Aug 2010 20:44:21 -0700

I think you discuss how to move forward with this draft on dispatch mailing list given that's the point of that list is help with problems like this. 

> http://tools.ietf.org/html/draft-jones-sip-options-ping

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 13 Aug 2010 00:08:41 -0400

The draft does specify the use of 503 to indicate overload.  The 486 was
proposed as a means of indicating that the device is nearing capacity,
versus being totally overloaded.  So, if one sends an OPTIONS message and
the peer device is in great shape, it would return a 200.  If it's nearing
capacity, but still able to accept new requests, it would return a 486.  If
it cannot accept new requests, it would return 503.

The value in using the 486 (and this could be any other code folks agreed to
use) is that it gives an SBC warning that overload is eminent.  It's
important to give given that advanced warning before the peer reaches an
overload state.  Having said that, addressing overload is really a separate
problem entirely and is not the primary focus of OPTIONS "ping".  So, I
would not be opposed to removing this part entirely.  For overload control,
there is a WG focused on doing percentage-based overload control.  I view
that as good for stateless SIP entities, but not very useful (in my opinion)
for peered SBCs.  So, we have a separate draft aimed at overload control
called "Session Capacity Estimate" SIP entities that are stateful:

http://tools.ietf.org/html/draft-jones-sip-overload-sce-00

Anyway, I don't want to get too off-topic :-)  For OPTIONS, I just want to
get the feel of the group as to whether there is value in trying to do
something.  I take it you think this is worthwhile.

I'll remove the paragraph that describes use of 486, since I think use of
Session Capacity Estimate is a far better solution.  OPTIONS is just to
determine if the peer is alive and an SCE value can be returned in an
OPTIONS ping.  Any other changes that would help tighten the language and
reduce interop issues?

Paul

From: $@r\/|>r!`/@ [mailto:[email-masked]] 
Sent: Thursday, August 12, 2010 3:51 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]; Gonzalo
Salgueiro; Hadriel Kaplan
Subject: Re: [Sip-implementors] SIP OPTIONS "ping"

Hi,

Gud to see your initiative.

Instead of using 486 for denoting overload, 503 message can be used. I have
seen this usage to use as overload control mechanism. Entirely in my
opinion, 486 is not apt.

cheers!!!!
sarvpriya

http://sarvpriyak.blogspot.com/

On Thu, Aug 12, 2010 at 10:44 AM, Paul E. Jones <[email-masked]>
wrote:

Folks,

Paul

_______________________________________________
Sip-implementors mailing list
[email-masked]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

--

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 13 Aug 2010 00:18:34 -0400

Brian,

If I could, I'd revise RFC 3261.  It's that document that introduces the use
of OPTIONS as a "ping" mechanism, but gives little guidance to implementers
and, as such, implementations are all over the map.  I've seen at least 6
different variants implemented.

But, I think trying to revise RFC 3261 would open a can of worms.  So, I was
suggesting we progress this as standard track to update RFC 3261, but that
didn't happen.  I'm not trying to introduce anything new, though: just
clarify what should have been elaborated upon more fully in 3261.  Even so,
there are certainly points of contention, I'm sure, since folks do have it
implemented differently.

Paul

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, August 12, 2010 8:45 AM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]; Hadriel Kaplan
Subject: Re: [sip-ops] SIP OPTIONS "ping"

I think this is needed, and I would go for informational.  While I sort of
understand that you are "pushing" the definition of OPTIONS, if it was PS,
you wouldn't update any RFCs, right?

Brian

Folks,

Paul

---

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
> Paul E. Jones wrote:
> > 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"
> > 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.
> >
> >
> >
> > 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?
> 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:
> >

---

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.
> >>
> >>>
> >>> 3)      Forget about the draft and let every SIP device do it the way
> >>>
> >> they
> >>
> >> 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