Subject: Re: [sip-overload] (Applicable Initial Methods for Overload Control and Error Code) Comments on SOC Event Package

From: Charles Shen <[email-masked]>
Date: Fri, 12 Oct 2012 12:52:38 -0400

On Wed, Aug 29, 2012 at 10:10 AM, <[email-masked]> wrote:

>  Two comments/questions below.****
>
> ** **
>
> *De :* [email-masked] [mailto:[email-masked]]
> *De la part de* Adam Roach
> *Envoyé :* lundi 30 juillet 2012 19:27
> *À :* [email-masked]
> *Cc :* SOC (SIP Overload Control) WG
> *Objet :* [sip-overload] Comments on SOC Event Package****
>
> **
>
>
> Similarly, we run into an issue in which an ACK response to a 200 is
> dropped, as doing so will cause the 200 to be retransmitted, which again
> exacerbates any overload condition that may arise. In other words, I think
> we need to specify that "drop" cannot be applied to ACK (and reject clearly
> can't, since ACK never sees a response) -- so ACKs must always go through
> regardless of overload filters. For the same reason, proxies that receive
> an ACK response to a non-200 need to always process the ACK rather than
> dropping it.****
>
> * *
>
> *   [BC] I don’t think this can happen. The current text says that
> “Conditions are evaluated on receipt of an initial SIP request for a dialog
> or*
>
> * standalone transaction”. So my understanding is that conditions are not
> evaluated on receipt of an ACK. Moreover, the “ACK” is not a valid value
> for the <method> element and the current text says that when the <method>
> element is not included in a filter, the rule actions are applicable to all
> initial methods. A formal definition of initial method may be missing but I
> assume ACK is not an initial method.
>
> *
>

Yes, it's a good idea to make it more explicit about the applicable
methods. The current draft lists the following methods as possibly subject
to control (in the XML schema section)

MESSAGE
REGISTER
SUBSCRIBE
OPTIONS
PUBLISH

Any suggestions for missing or mis-placed method in this list? I will add
it explicitly in the main text once we are fine with the list.

> * *
>
> *On the other hand, I’m wondering whether this comment about ACK should
> not be made against draft-ietf-soc-overload-control, section 5.10?*
>
>
>
> On to topic of rejects, I note that the current draft simply gives an
> example (500 Server Internal Error) rather than specifying how rejection is
> performed. This will make troubleshooting a system more difficult. I
> would suggest that we add a new 500-class error code that is used to
> indicate this specific situation. We also need to think about whether
> "Retry-After" handling is appropriate in this case. I think it is, but we
> need to work through how it is set (i.e., is it part of the overload rule,
> or is it set by the server itself?)****
>
> * *
>
> *[BC] Is there any reason for rejecting calls with a different response
> code depending on whether overload control information was obtained using
> the feedback-based or even-based solution? I guess the answer is no.
> Section 5.10.2 of draft-ietf-soc-overload-control says that the SIP server
> must reject requests with a 503 response.*
>
>
>
>

So maybe 503 response code should do for the event-package rejection?

Thanks

Charles