Hi all,
Is someone know if it's possible to use SER for prefix calls for LNP ?
Then the call will be sent to AS5350 and the prefix must define the
carrier for out ported number.
I search information on this topic but I find nothing about SIP and LNP.
Thanks for our informations.
Regards
Hi everybody,
Currently we are working on an IMS project. This project need a IMS server.
Finally we choiced OpenSER as the IMS server.
But have no experience how to use OpenSER as a IMS server.
Could someone tell me how to config it?
Best regards,
Steven Wu
Hi,
I'm trying to understand better how mediaproxy works. Just read the
mediaproxy-ng.org page... i understood the necessity of using mediaproxy for
NAT traversal, but i have one doubt...
- What's the difference between the dispatcher and the relay?
Can someone explain me the concept or point me to some literature so i
can clear my mind :)
Thanks in advance,
Nuno
Hi all,
i want to share some thoughts where i think the priorities for the next major
release(s) of Kamailio should be. This is the continuation of the work i (and
many others) have done for the previous releases, but i thought it makes sense
to summarize it a bit on a higher (abstraction) level.
1. Refactoring and cleanup
We still have quite a lot of old code in our repository, which is no longer
working or obsolete. Some implementations uses way to much gotos, or macros
that are several pages long. This makes important parts of the core and
modules harder to understand and maintain then necessary. Especially in the
area of utility functions there is still to much duplicated code.
proposed actions:
- identification and removal of no longer working code in the core and modules
- identification and unification of redundant (duplicated) code in core and
modules to one implementation
- identification and removal of obselete code parts in core and modules.
- refactoring of code to use less gotos and macros
2. User and developer documentation
With regards to user documentation quite a lot of work has been done in the
past releases. But with the developer documentation, especially in certain
modules, there is still plenty of content missing. As the involvement of
individuals and companies can change, documentation is necessary to ensure a
continued maintenance of the code.
proposed actions:
- conversion of already existing documentation to doxygen format
- add a short doxygen module definition to every module, explaining the
purpose
- add a short doxygen file definition to every file, explaining the purpose
- extend doxygen docs in important areas like the core and modules like TM
- autogeneration of database related module documentation from the XML scheme
definitions
3. Consolidation in core and modules
At the moment we've 85 modules in our repository. Some modules implement only
one or two functions, which makes no real sense with regards to the
maintainance overhead that comes with it. 24 of the modules are using database
access and 7 implement database interfaces. There is no clear boundary in some
areas of the core and modules, this hinders the further development of the
server.
proposed actions:
- integrate several modules that share responsibilities and not implement that
much functionality on their own into one
- autogeneration of module interface and database infrastructure code from the
XML database scheme definitions
- identify obselete module functions that can be done easily with
pseudo-variables now. Remove these functions.
- move certain core parts that do not need to be there into modules, making
the core smaller and more flexible
- identify core APIs which are used from modules, evaluate eventual
generalisations to make the modules less dependent from the actual core
implementation
4. Quality assurance
The complexity of several modules, and the special dependencies that some of
them carry increase the work to test the server and reproduce bugs. Without
proper test coverage maintenance work is slowed down and flexibility is lost.
All "easy" bugs that get caught automatically will not reach the user,
increasing the quality.
proposed actions:
- extend available test suite to cover more of core and modules
- continue maintenance of available infrastructure for build tests (build bot,
debian package autobuilder), evaluate extensions to increase coverage
All this work will be done as in the past in an open and accountable way on
the developer list. For bigger changes a request for comment will be posted
in advance on this list. If existing functionality is deprecated, then this
RFC will be also posted to the user list. If some functionality is moved or
changed than this will be documented in the wiki (porting docs) as usual.
I understand some changes will be probably add work on your side, in porting,
configuration adjustments and the like. But i think this is necessary to
ensure the further development of the Kamailio project, and to be able to
deal with new challenges that will come up in the future.
Any input and help with this regards to this individual tasks is of course
much appreciated. In the end the success of the project depends in the future
(like it did in the past) on your support. Without your involvement in
contributions, discussions and bug reports i would be only to a much lesser
extend involved in this project.
Thank you,
Henning Westerholt
--
Henning Westerholt - Development Consumer Products / DSL Core
1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe, Germany
