[sr-dev] SIP Congestion/Overload Control

[Daniel-Constantin Mierla]

Hello,

On 6/28/11 3:32 PM, Michael Hirschbichler wrote:
> Hi all,
>
> I am currently developing a module for offering overload control support
> as proposed in
> http://tools.ietf.org/html/draft-ietf-soc-overload-control-02 .
>
> As background: the idea behind draft-ietf-soc-overload-control-02 is,
> that the upstream node ads parameters to the own Via-header to signal
> the next downstream node its ability to understand overload-control
> signalling. In case of overload of the downstream node, this node
> downstream node extends the own Via-Header (sent in replies to the
> upstream node) with e.g., a droprate.
>
> Well, and the job of the oc-module will be to
> 1) add "oc" to the Via-headers in requests (ok)
> 2) parse the Via-Header of the replies for oc-droprates and durations (ok)
> 3) keep a list of overloaded downstream-hosts, the droprate and the
> duration of the droprate (failed - see below)
> 4) its own droprate and the duration communicated to other upstream
> neighbors (failed - see below)
>
> The module "oc" (currently) exports the following commands and params
> static cmd_export_t cmds[]={
>   	{"oc_check_enabled", ...
>   	{"oc_check_downstream_overloaded", ...
> 	{"oc_setdroprate", oc_setdroprate, ...
> 	{0,0,0,0,0}
> };
> static param_export_t params[]={
>    	{"oc_enabled", PARAM_INT,&OC_ENABLED},
> 	{0,0,0}
> };
> and the rpc-methods
> static rpc_export_t rpc_methods[] = {
> 	{"oc.stats",...},
> 	{"oc.set_oc"...},
> 	{"oc.set_oc_duration",...},
> 	{0, 0, 0, 0}
> };
>
> Well, and now my problem: Manipulating the own Via-Header is (in my
> understanding) a very tricky part: in msg_translator.c the functions
> "build_req_buf_from_sip_req()" and "build_res_bug_from_sip_res()" are
> responsible for adding the own Via-Header and its parameters.

When building the response there is no own via, the first via will be 
the previous hop in the request path, do you need to update that one as 
well?

>   So, I had
> to add a function call to functions inside my oc-module:
> oc_via_manipulation() and oc_builder().
>
> And here is the problem: I cannot access the shared memory variables of
> the oc-module like oc_duration and oc_droprate when I call the
> oc_via_manipulation() and oc_builder()-functions from within
> "build_req_buf_from_sip_req()" and "build_res_bug_from_sip_res()". My
> conclusion was, that when calling functions of the oc-module from within
> the ser-"core", the shared-memory variables set by rpc_methods, cmds and
> params are not accessible.

The shared memory is available in the core, so it should be no problem 
to access it. The problem might be how you pass the pointers to the 
share memory.

Normally, the core should not call the functions implemented by the 
module directly, but via some interface. How do you get the pointers to 
your module functions to be executed from the core?

Like an idea right now, we could think about a generic function to add 
extra parameters to own via header to be offered by the core and called 
from inside modules.

Cheers,
Daniel

>
> Honestly, I have now no idea how to continue and would be happy on every
> idea,
>
> br
> Michael
>
>
>
>
>

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda