Subject: Re: [sipcore] SIP OPTIONS "ping"

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 4 May 2010 19:37:04 -0400

Cullen,

Problem Statement:

Recognizing that if a SIP entity does not know the basic operational state
of a peer device, there is a risk of delays in delivering service and
weakened ability for administrators to correct service issues.

Further recognizing that SIP specifies the use of OPTIONS as a means of
determining the basic state of a UAS, but RFC 3261's description of the
usage is shallow and does not lend itself to interoperability, resulting in
a wide variety of implementations of OPTIONS for this purpose. 

Proposed Solution:

Define procedures for using the current OPTIONS method defined in RFC 3261
in a way that improves interoperability and lends to consistent
implementation when used to determine the operational status of peer SIP
entities so as to reduce delays, improve overall operational efficiency, and
provide reliable/useful operational status information to administrators.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Cullen Jennings
> Sent: Friday, April 30, 2010 3:21 PM
> To: Paul E. Jones
> Cc: 'Michael Miller'; [email-masked]; 'Hadriel Kaplan'
> Subject: Re: [sipcore] SIP OPTIONS "ping"
> 
> 
> 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:
> 
> > 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
> >
> >
> > _______________________________________________
> > 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
> 
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 5 May 2010 14:54:41 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul E. Jones
> Sent: 05 May 2010 00:37
> To: 'Cullen Jennings'
[JRE] To a first approximation, a 2xx versus a 4xx/5xx/6xx should tell you the basic operational state of the responder. So we need more precise information on what is broken.

John

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 5 May 2010 08:56:09 -0600

> weakened ability for administrators to correct service issues.

So for many devices, there is one one logical next hop and the existing DNS and ICMP approaches seem to be adequate but for other situations, there has always been a desire to do something better than that. So for the type of servers that had many possible next hops to choose from, I think people do want to have a better way to choose which next hop to use that minimizes delays due to servers being down or overloaded. Right now a new working group has been proposed to work on that problem. Is there anything you see we need to do to expand the scope of the SIP Overload Control Charter to make sure the problem you are envision is in scope for that WG? As far as I can tell, this is the simple case of what they hope to solve. 

> a wide variety of implementations of OPTIONS for this purpose. 

Actually, I don't think this was the purpose of OPTIONS in 3261 so I'm not surprised there are some difficulties in using it this way. However, I don't see that as a problem. 

Cullen

Cullen Jennings

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 May 2010 01:55:05 -0400

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, May 05, 2010 8:55 AM
> To: Paul E. Jones; 'Cullen Jennings'
> 
> [JRE] To a first approximation, a 2xx versus a 4xx/5xx/6xx should tell you
> the basic operational state of the responder. So we need more precise
> information on what is broken.

But it doesn't in practice.  Both because it's not a binary on/off operational state, and because of targeting/addressing issues.  

Some devices send a 503 when they're too busy, and don't want new requests for retry-after time, but still expect in-dialog requests.  Some devices send a 486 instead.

Some devices send a 503 when they're admin-down.  Some devices send a 500 instead.  In either case, some expect in-dialog messages, others don't.

Some send a 483 Too Many Hops, because the requestor had to set a max-forwards of 0 or 1 to prevent it going past the next-hop. (because the addressing for the OPTIONS is ambiguous)  And that prevents either a 2xx or 5xx.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 6 May 2010 02:03:24 -0400

> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, May 05, 2010 10:56 AM
> To: Paul E. Jones
> 
> So for many devices, there is one one logical next hop and the existing
> DNS and ICMP approaches seem to be adequate but for other situations,
> there has always been a desire to do something better than that. So for
> the type of servers that had many possible next hops to choose from, I
> think people do want to have a better way to choose which next hop to use
> that minimizes delays due to servers being down or overloaded. Right now a
> new working group has been proposed to work on that problem. Is there
> anything you see we need to do to expand the scope of the SIP Overload
> Control Charter to make sure the problem you are envision is in scope for
> that WG? As far as I can tell, this is the simple case of what they hope
> to solve.

Yes, I also noted that when Paul first submitted the draft.  But his point was that (1) it's not just load state, it's also admin state, and (2) it's a ping as well.  I suppose one could argue that if the overload WG covers real state information and not just load, then OPTIONS could be the carrier for that info.

> Actually, I don't think this was the purpose of OPTIONS in 3261 so I'm not
> surprised there are some difficulties in using it this way. However, I
> don't see that as a problem.

>From rfc3261 page 68:

11.2 Processing of OPTIONS Request

   The response to an OPTIONS is constructed using the standard rules
   for a SIP response as discussed in Section 8.2.6.  The response code
   chosen MUST be the same that would have been chosen had the request
   been an INVITE.  That is, a 200 (OK) would be returned if the UAS is
   ready to accept a call, a 486 (Busy Here) would be returned if the
   UAS is busy, etc.  This allows an OPTIONS request to be used to
   determine the basic state of a UAS, which can be an indication of
   whether the UAS will accept an INVITE request.

-hadriel