[sr-dev] SIP Congestion/Overload Control
sipp at hirschbichler.biz
Wed Jun 29 08:50:01 CEST 2011
Am 2011-06-28 20:56, schrieb Daniel-Constantin Mierla:
>> 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
Jepp, of course you are right. The (overloaded) downstream server takes
the remaining topmost Via header of the response and manipulates the
oc-parameter according its overload state.
>> 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?
Well, I am defintely no C freak. My first try was to create an oc.h and
include it into the msg_translator.c. Like described, this compiled, but
did not work.
Any hint what to change to get this running as a proof-of-concept
> 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.
I think, this would be a good approach as there are other discussions
about extending the Via-Headers (like for Spit protection).
>> Honestly, I have now no idea how to continue and would be happy on every
More information about the sr-dev