Hi everybody,
we are trying to collect the items to be included in the roadmap to the next release. I have written a draft with the ideas discussed on the mailing list, the items which were not accomplished in v1.0.0 and a few more. There is no weight attached, and the presence in the roadmap does not imply that the feature will be for sure implemented until the next release. The roadmap should guide the development of the project.
Please send your suggestions, if possible with some description. As a general rule, the features to be implemented must follow the standard, if they are related directly to SIP, or they must have a clear and common usage in real cases.
Cheers, Daniel
Draft of the roadmap to OpenSERv1.1.0 -------------------------------------
OpenSER core:
- generic communication interface which must offer an abstract layer between core/modules and transports (e.g., fifo, unix sockets) - move the code of the implemented trasports as module - NAPTR lookup - TLS multi-domain support - TLS configuration values to be set via a module, to keep core less exposed to often changes - better error reporting and handling - pseudo-variables to be introduced in different modules - security checks of destination addess (white/black lists) - memory defragmentation - tcp enhancements - OpenSER command line interface (terminal)
OpenSER modules:
[acc] - possibility to disable values from db_fmt
[avpops] - more coherent format of the parameters (=>to be used the one from pseudo-variables) - ability to take the name of the AVP to be loaded from the value of another AVP - global avps - avps to be stored during run time, shared between processes - local avps - avps to be stored locally, specific per script, not per transaction
[cpl-c] - possibility to configure table and columns' names - import registrar paramters insted of redefine
[dbtext] - replace support - reload support
[dispatcher] - serial forking when selected destination fails - database support
[enum] [-] - parallel/serial forking based on order and preference fields
[postgres] - connection pool - shift to memory manager used by openser
[tm] - unification of t_relay_to_*() in a form of t_relay_to("proto:host:port")
[uac] - qop authentication support - proper CSeq value after authentication challenge
[usrloc] - better handling of the natted contacts, to uniquely identify a contact - cacheless usrloc - path support for registrations - sip instance support - possibility to attach to a contact a set of values (similar to log_extra in acc)
On Thu, 3 Nov 2005, Daniel-Constantin Mierla wrote:
Hello,
we are trying to collect the items to be included in the roadmap to the next release. I have written a draft with the ideas discussed on the mailing list, the items which were not accomplished in v1.0.0 and a few more. There is no weight attached, and the presence in the roadmap does not imply that the feature will be for sure implemented until the next release. The roadmap should guide the development of the project.
Please send your suggestions, if possible with some description. As a general rule, the features to be implemented must follow the standard, if they are related directly to SIP, or they must have a clear and common usage in real cases.
Maybe try to port all the last PA work done in SER.
Saludos JesusR.
------------------------------- Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------
Jesus Rodriguez wrote:
On Thu, 3 Nov 2005, Daniel-Constantin Mierla wrote:
Hello,
we are trying to collect the items to be included in the roadmap to the next release. I have written a draft with the ideas discussed on the mailing list, the items which were not accomplished in v1.0.0 and a few more. There is no weight attached, and the presence in the roadmap does not imply that the feature will be for sure implemented until the next release. The roadmap should guide the development of the project.
Please send your suggestions, if possible with some description. As a general rule, the features to be implemented must follow the standard, if they are related directly to SIP, or they must have a clear and common usage in real cases.
Maybe try to port all the last PA work done in SER.
I think there is still ongoing development - maybe it's better to wait till the PA work is (more or less) stable in ser.
klaus
On Mon, 7 Nov 2005, Klaus Darilion wrote:
Hi,
we are trying to collect the items to be included in the roadmap to the next release. I have written a draft with the ideas discussed on the mailing list, the items which were not accomplished in v1.0.0 and a few more. There is no weight attached, and the presence in the roadmap does not imply that the feature will be for sure implemented until the next release. The roadmap should guide the development of the project.
Please send your suggestions, if possible with some description. As a general rule, the features to be implemented must follow the standard, if they are related directly to SIP, or they must have a clear and common usage in real cases.
Maybe try to port all the last PA work done in SER.
I think there is still ongoing development - maybe it's better to wait till the PA work is (more or less) stable in ser.
Yes, agreed. Just to keep it in mind :)
Saludos JesusR.
------------------------------- Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------
daniel,
there is one more thing.
long time ago i added to ser parsing of Allow header and methods contact parameter. the idea was that if register request has methods contact parameter for a contact or Allow header for the request (the former takes precedence), new location/methods column of type unsigned int would be set accordingly. then it would be possible to select if it makes sense to send a request (such as SUBSCRIBE or REFER) to a particular contact or not.
the plan was that jan would write the location related part of this code, but it was forgotten and never happened. i still think that it would be useful to have this functionality and it would not be a big deal to add this to ul module. i would, however, prefer that someone more familiar with ul module would do it in order to avoid making mistakes.
so perhaps daniel could add this one to the list too.
-- juha
Daniel-Constantin Mierla wrote:
- generic communication interface which must offer an abstract layer between core/modules and transports (e.g., fifo, unix sockets)
- move the code of the implemented trasports as module
- NAPTR lookup
with failover to next server/protocol? interpret ICMP error messages
- TLS multi-domain support
- TLS configuration values to be set via a module, to keep core less exposed
I will write a separe emails for my TLS ideas :-)
- security checks of destination addess (white/black lists)
maybe not only based on IP address, but IP address, port and protocol (which may be also * for all ports/protocols)
[enum] [-] - parallel/serial forking based on order and preference fields
isn't this already possible using load_gw, next_gw?
[postgres]
- connection pool
- shift to memory manager used by openser
there was a big patch by jan for ser - maybe we can use this patch.
klaus
How about usrloc-cl?
Ray
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Klaus Darilion Sent: 2005年11月7日 18:22 To: daniel@voice-system.ro Cc: devel@openser.org; users@openser.org Subject: [Users] Re: [Devel] roadmap to v1.1.0
Daniel-Constantin Mierla wrote:
- generic communication interface which must offer an abstract layer
between
core/modules and transports (e.g., fifo, unix sockets)
- move the code of the implemented trasports as module
- NAPTR lookup
with failover to next server/protocol? interpret ICMP error messages
- TLS multi-domain support
- TLS configuration values to be set via a module, to keep core less
exposed
I will write a separe emails for my TLS ideas :-)
- security checks of destination addess (white/black lists)
maybe not only based on IP address, but IP address, port and protocol (which may be also * for all ports/protocols)
[enum] [-] - parallel/serial forking based on order and preference fields
isn't this already possible using load_gw, next_gw?
[postgres]
- connection pool
- shift to memory manager used by openser
there was a big patch by jan for ser - maybe we can use this patch.
klaus
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Klaus,
Klaus Darilion wrote:
Daniel-Constantin Mierla wrote:
- generic communication interface which must offer an abstract layer
between core/modules and transports (e.g., fifo, unix sockets)
- move the code of the implemented trasports as module
- NAPTR lookup
with failover to next server/protocol? interpret ICMP error messages
first step will be only NAPTR lookup and interpretation of priorities, protocols, etc.
- TLS multi-domain support
- TLS configuration values to be set via a module, to keep core less
exposed
I will write a separe emails for my TLS ideas :-)
ok :)
- security checks of destination addess (white/black lists)
maybe not only based on IP address, but IP address, port and protocol (which may be also * for all ports/protocols)
yes, makes sense
[enum] [-] - parallel/serial forking based on order and preference fields
isn't this already possible using load_gw, next_gw?
the idea behind was to move the functionality of load_gw and next_gw into core to allow a standard mechanism for serial forking for all modules (without interdependencies). Enum, registrar, NAPTR lookup, etc will be able to do serial forking also without depending of lcr module.
[postgres]
- connection pool
- shift to memory manager used by openser
there was a big patch by jan for ser - maybe we can use this patch.
can you extract the patch ;)?
regards, bogdan
Hi,
the new roadmap is now online. http://openser.org/roadmap.php
I collected all the suggestions sent on the mailing list, please let me know if something was missed. The roadmap is just a guide for the new release, many other features will be implemented till the next release, although some of the one listed in the document may not be ready in this time frame.
Please use the tracker on sourceforge to request new features, it is easier to review and manage them. http://sourceforge.net/tracker/?group_id=139143
The document from the web site will be updated accordingly from time to time.
Cheers, Daniel
On 11/03/05 18:47, Daniel-Constantin Mierla wrote:
Hi everybody,
we are trying to collect the items to be included in the roadmap to the next release. I have written a draft with the ideas discussed on the mailing list, the items which were not accomplished in v1.0.0 and a few more. There is no weight attached, and the presence in the roadmap does not imply that the feature will be for sure implemented until the next release. The roadmap should guide the development of the project.
Please send your suggestions, if possible with some description. As a general rule, the features to be implemented must follow the standard, if they are related directly to SIP, or they must have a clear and common usage in real cases.
Cheers, Daniel
Draft of the roadmap to OpenSERv1.1.0
OpenSER core:
- generic communication interface which must offer an abstract layer between core/modules and transports (e.g., fifo, unix sockets)
- move the code of the implemented trasports as module
- NAPTR lookup
- TLS multi-domain support
- TLS configuration values to be set via a module, to keep core less exposed to often changes
- better error reporting and handling
- pseudo-variables to be introduced in different modules
- security checks of destination addess (white/black lists)
- memory defragmentation
- tcp enhancements
- OpenSER command line interface (terminal)
OpenSER modules:
[acc]
- possibility to disable values from db_fmt
[avpops]
- more coherent format of the parameters (=>to be used the one from pseudo-variables)
- ability to take the name of the AVP to be loaded from the value of another AVP
- global avps - avps to be stored during run time, shared between processes
- local avps - avps to be stored locally, specific per script, not per transaction
[cpl-c]
- possibility to configure table and columns' names
- import registrar paramters insted of redefine
[dbtext]
- replace support
- reload support
[dispatcher]
- serial forking when selected destination fails
- database support
[enum] [-] - parallel/serial forking based on order and preference fields
[postgres]
- connection pool
- shift to memory manager used by openser
[tm]
- unification of t_relay_to_*() in a form of t_relay_to("proto:host:port")
[uac]
- qop authentication support
- proper CSeq value after authentication challenge
[usrloc]
- better handling of the natted contacts, to uniquely identify a contact
- cacheless usrloc
- path support for registrations
- sip instance support
- possibility to attach to a contact a set of values (similar to log_extra in acc)
Devel mailing list Devel@openser.org http://openser.org/cgi-bin/mailman/listinfo/devel
-
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Jesus Rodriguez -
Juha Heinanen -
Klaus Darilion -
Raymond Chen