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

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

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:[e-mail]] 
Sent: Thursday, August 12, 2010 3:51 AM
To: Paul E. Jones
Cc: [e-mail]; [e-mail]; 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 <[e-mail]>
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?



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




--