hi,
i am developing a module. i am generating some string value.
how can i get those value in my cfg file.
i saw source code of avpops module but it work with database and lots of thing.
is there any short module what can help me to this thing implement thing.
any link or suggestion is appreciated.
TOWHID
Hi guys,
I was wondering what happened to this line from t_reply.h:
enum route_mode { MODE_REQUEST=1, MODE_ONREPLY, MODE_ONFAILURE };
It was there in ser 2.1.0, but not it's gone from sr, altough the tm_binds
still defines a enum route_mode* as a parameter. Maybe it was just
forgotten?
I found the solution in a k module - the route_type extern variable, just
want to make sure that this is the new right way to tell on which route a
function was called.
--
Best Regards,
Dragos Vingarzan
Hello,
some time ago I created a new branch in GIT named 'daniel/xavp' that
includes code for a new pseudo-variable class 'xavp' - name being a
shortcut to 'extended attribute value pair'. I collected some design
details in wiki:
http://sip-router.org/wiki/devel/xavp
It is not a replacement for current AVP api implementation, although in
the future can replace it. In the past we had couple of discussions
about the limitations of avps which I tried to overcome. Here are some
highlights of xavp design:
- string names only - various tests showed that having the complex
addressing scheme with integer id and string name does not pay off
performance gains. XAVP computes and integer id for each name that is
used to speed up comparison
- possibility to store more data types - AVP allow string and integer
data types. More can be handled by XAVP, including a generic data type
where you can build your own structure and store it in the list. This is
good for example to store custom structures for transaction lifetine --
right now dialog module needs to store reference to dialog structure.
Optimizations can be done for any case of serial forking -- uri, dst
uri, q, etc can be stored in a structure without a need to parse and
build it from an encoded value stored in one or many avps
- possibility to group XAVPs inside another XAVP - practically is
building lists of XAVPs. This should overcome issues with naming
conflicts between modules - e.g., dispatacher module can group its avps
in a list named "dispatacher", lcr module in a list named 'lcrl, then
there can be XAVP with name 'uri' in both lists, without the risk of
misusage. Another benefit would be reducing the number of parameters,
right now each module exports a parameter to set the name for each AVP,
with xavp there is need for one parameter to set the name of the list,
then inside that list the module is free to use predefined names without
the risk of overlapping.
- xavp having value integer or string can be used directly in config,
whether they are in a sublist or not
Check the wiki (link above) for more. Looking forward for comments,
suggestions and improvements.
Cheers,
Daniel
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
Hello,
the new sip router core and librarization of kamailio management (MI)
and statistics interfaces affected the module interface. At this time,
although all the fields are still in the module interface, some are passive:
- mi commands exports
- statistics exports
- extra processes
The modules in the public GIT repository use the either mod_init or
mod_register to export them, so everything should work as expected.
fyi: if you didn't know so far - mod_register is a function
automatically called when a module is loaded, giving the possibility to
export components from module in very early stage, e.g., transfomations
must be exported via mod_register since they are lookep up while parsing
the routing blocks -- mod_register is available in kamailio since 1.5,
back ported from sip router core, you just need to implement it in the
module, it is not part of module interface.
Back to module interface, the three fields mislead private module
implementations as everything compiles ok, but at startup the fields are
not actually exported. I propose to remove them and document the
transition process to new interface, which is practically couple of code
lines. It this way people migrating private stuff will notice the change
and update.
Since we are here and we have to go through each K module and remove the
fields from the module interface, maybe we can create a single interface
for k and s modules. Doing a short analysis and considering the above
three fields removed from k interface, then:
- K interface has extra
- dlopen flags - needed to specify how the .so is open, required so
far by perl module, iirc
- PV exports - the list of pseudo-variables exported by module
- the cmd (function) exports structure has a field to specify a free
fixup function (not implemented for all exported commands). The goal is
to allow calling functions exported by modules for higher application
languages, like perl so far, where it is needed to free the memory
allocated by fixup function
- S interface has extra
- rpc exports - exported rpc commands
- onbreak function - is this used?!? couldn't find docs about or a
use case, so I consider it obsolete
Then common interface would be:
- name
- dlopen flags
- mod parameters
- mod commands with free fixup
- rpc commands
- PV exports
- mod init
- child init
- mod destroy
- onreply callback
Probably we can normalize it a bit more, comments and suggestions are
welcome!
Thanks,
Daniel
--
Daniel-Constantin Mierla
* SIP Router Bootcamp
* Kamailio (OpenSER) and Asterisk Training
* Berlin, Germany, Sep 1-4, 2009
* http://www.asipto.com/index.php/sip-router-bootcamp/
brandon,
i hope that the http_query crash is now fixed in sr and k 1.5. i added
a check on the actual size of the reply body. and as klaus suggested, the
result is now the whole body if it does not contain a linefeed.
-- juha
