[sr-dev] SIP Congestion/Overload Control

Michael Hirschbichler sipp at hirschbichler.biz
Tue Jun 28 15:32:06 CEST 2011

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, ...
static param_export_t params[]={
  	{"oc_enabled", PARAM_INT, &OC_ENABLED},
and the rpc-methods
static rpc_export_t rpc_methods[] = {
	{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. 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.

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


Michael Hirschbichler, Mag. Dipl.-Ing.
Institute of Telecommunications
Vienna University of Technology
A-1040 Wien, Favoritenstr. 9-11/388
Phone: +43 1 58801 38846

More information about the sr-dev mailing list