[sr-dev] SIP Congestion/Overload Control

Michael Hirschbichler 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
> well?

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.

ok.

> 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
implementation?

> 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).

BR
Michael

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




More information about the sr-dev mailing list