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 >> >> >> >> >> > _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
