Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm

[Adam Roach <[e-mail]>]

On 3/9/12 1:40 PM, Vijay K. Gurbani wrote:
> On 03/08/2012 03:28 PM, Adam Roach wrote:
>> So, here's what I propose. It's based heavily on your most recent code,
>> but it handles inbound and outbound messages separately and explains
>> where the SIP messages are coming from:  [...]
>
> Adam: Sorry for the delay, was tied up in meetings.
>
> I went through your proposal of breaking the processing down.
> I am fine with it, however, I think there are some nuances in the
> "case inbound request" that we need to be more intelligent about.
>
> I think something along the following lines should be specified for
> that case:
>
> ...
> case inbound request:
>
> if (we are not in overload)  {
>    process_msg(sip_msg)
> }
> else {  // We are in overload
>    if (sip_msg has oc parameters)  {  // Upstream client supports oc
>       process_msg(sip_msg)  // and only sends important requests
>    }
>    else {  // Upstream client does not support oc
>       if (local_policy(sip_msg) says process message)  {
>          process_msg(sip_msg)
>       }
>       else  {
>          send_response(sip_msg, 503)
>       }
>    }
> }
>
> Here, if the above code is being executed by an overloaded
> proxy and the upstream client does not support overload, then the
> proxy has to consult local policy on what to do.  If local policy
> says process the request, then the request gets added to the work
> queue and re-appears back in the event loop and is handled by the
> "case outbound request" part of the code.
>
> If the above code is being executed by a terminal UAS under the same
> conditions (i.e., UAS is overloaded and the upstream client does
> not support overload), then local policy can decide whether to
> accept that request or send a 503.
>
> Thoughts?

That sounds good to me.

/a