Subject: [sipcore] SIP OPTIONS "ping"

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 29 Apr 2010 21:11:14 -0400

Guys,

I decided to start this new thread, because the previous one is proving to
be a bit challenging to respond to.

Let's back up and review where we are and what we're trying to accomplish.

Many devices today use OPTIONS as a "ping" method.  The reason is that there
was nothing better or more appropriate for an out-of-dialog means of
determining status of a peer SIP device.  These devices include PBXes, SBCs,
etc.

The problems are:
1) Response codes vary from one device to another (e.g., 600 vs. 503 vs.
486)
2) Nowhere is it documented that an OPTIONS can be used as an
application-level "ping"

Taking note of the current state of affairs and desiring to improve it
without changing SIP in any significant way, we prepared the OPTIONS "ping"
draft.

Is it a ping message or not?  The thread has focused heavily on the contents
of the message, but we're not proposing changes to the contents of a
message.  We only wish to focus on response codes: the contents of headers
and body were not subject to change.

We proposed sending OPTIONS "ping" messages to the IP address of the peer
device with a request URI of "sip:hostport" since that seemed most logical
to us.  Christer pointed out that that's the address used when addressing a
SIP proxy server.  I think that's OK, since we're not suggesting that the
proxy server actually alter its behavior.  That said, we would like to
propose use of 503 to indicate that the device is overloaded, rather than
600: that's what RFC 3261 says. But, note that we're not saying a 600 is
illegal if that were the appropriate code -- it just isn't in this case.

We also expect this to be used only between two devices that agree to do so.
The interval for messages I also wanted to keep locally configured.

It might be useful to indicate that the message was a "ping" -- I have no
objection.  But, I would not implement a different code path, personally.
That's why I felt it wasn't terribly important to include.

If we do nothing, the world will continue to use OPTIONS as they do today.
Introducing PING will take time to standardize and we still have to support
OPTIONS for a decade.  So, why bother?

My recommendation is that we not boil the ocean and try to create the most
architecturally pure solution.  Let's recognize the use of OPTIONS in this
way as legitimate, keep it peer-to-peer (maxforward=1), recommend response
codes, and expect a locally provisioned usage policy (e.g., message
frequency).

I've captured the groups' comments in this draft, though I'd like to
reinstate the paragraph relating to the SIP Request URI (sip:hostport):
http://hive.packetizer.com/users/paulej/internet-drafts/pre-draft-jones-sip-
options-ping-01.pdf

In any case, I'll go along with whatever the group wishes to do.
 
Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Apr 2010 04:39:11 -0400

Hi Paul,
Good idea to reset.

Right, so one of the sub-threads previous was on the need or not for an indicator.

In the snippet of your email below, you're saying the OPTIONS is no different and the code path would be the same.  That's the part that confuses me.  If the code path is the same on the responder, such that it doesn't do anything different than what it does today, then by definition it won't fix the interop issues we've all seen in the wild.  The whole point of documenting consistent behavior for response codes is to fix the interop issues, and that means the box getting the OPTIONS request has to know the sender expects the behavior of this document.  For the responder to know that, there needs to be something in the OPTIONS message to tell it that.  And for the box that sent the OPTIONS, it may also need to know the responder does the draft so that it can treat the response codes appropriately, by something in the response telling it so.

I don't think that means it needs to be a new Method name, because we're not actually changing the OPTIONS from being an OPTIONS - using OPTIONS for this purpose is in rfc3261, it just wasn't succinct enough to avoid interop issues.

And the advantage of continuing to use an OPTIONS is that if the receiver does NOT support this new draft, it will still "work" as before.  In that sense using a new target URI username is probably not the best idea.  We could use a new options-tag in Supported, but since that would also still need something else in the message to say "I'm using this options-tag mechanism for this request", there's not much benefit to that.  So the easiest/simplest/most-likely-to-succeed path probably is Paul Kyzivat's suggestion of just defining a new header for both the request and response. 

-hadriel

> -----Original Message-----
> From: Paul E. Jones [mailto:[email-masked]]
> Sent: Thursday, April 29, 2010 9:11 PM
> Subject: SIP OPTIONS "ping"
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Apr 2010 10:43:42 -0400

> In the snippet of your email below, you're saying the OPTIONS is no different and the code path would be the same.  That's the part that confuses me.  If the code path is the same on the responder,…

Right!

> I don't think that means it needs to be a new Method name, because we're not actually changing the OPTIONS from being an OPTIONS - using OPTIONS for this purpose is in rfc3261, it just wasn't succi…

If there is no intent to have *different* behavior for the ping usage, 
then there is also no reason to indicate in the OPTIONS request that it 
is being used as a ping. Nor is there any need to have a side agreement 
between the UAC and UAS that the UAC will be pinging the UAS.

> And the advantage of continuing to use an OPTIONS is that if the receiver does NOT support this new draft, it will still "work" as before.  In that sense using a new target URI username is probably…

There really isn't any need to put *anything* new into the request.
All that is really needed is a header that says:

"This response complies with the *new improved* OPTIONS definition."

Unfortunately, just to accomplish that small step will still require a 
standards track draft to be approved. And if we are going to go to that 
much trouble, would it be worthwhile to do a separate ping mechanism?

I'm not advocating that we *should* do that - just asking.

If the clarified OPTIONS is what is desired, then maybe it isn't just 
about OPTIONS - is is really about more specific use of error codes for 
*all* requests?

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Apr 2010 13:21:15 -0600

Thanks for the reset.

I think the reasons this thread has been so unproductive is we are unclear on what the problem is we are trying to solve. "We need a way to do PING" is not a problem. It is a solution to some problem. If the problem is figure out which of multiple next hops to use based on load balancing and if the hop is dead or alive, well the PING approach here will fail miserably (see the overload discussion and simulations) and we have WG going to the IESG to try and solve that problem. 

Let me make it very clear I am against the working group working on this draft until someone can describe what the problem is. The current draft hand waves at a few problems - does not say what it is trying to do. Then proposes some syntax with no backing semantics that would help solve any of the problems it mentions. 

Cullen

On Apr 29, 2010, at 7:11 PM, Paul E. Jones wrote:

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

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