14 May
2007
14 May
'07
1:11 p.m.
Hello everybody,
as we want to provide more examples for the configuration the following the
question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would
like to know what you prefer or if you see other options.
Thanks
Nils
14 May
14 May
1:46 p.m.
Instead of one big example, you can provide some big example in order
to cover "main desired feature", easy to maintain :D
2007/5/14, Nils Ohlmeier <nils(a)iptel.org>rg>:
Hello everybody,
as we want to provide more examples for the configuration the following the
question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would
like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
********************************
* (o< ing. Patria Flavio
* //\ phone 0823451358
* V_/_ mobile 3407873357
*
********************************
2:03 p.m.
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the
question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would
like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Ideally, I'd like to see:
-One big configuration, well documented (per line or per block at the
VERY least).
-Smaller configuration examples for options that might not fit into a
larger overall config (block-level, which blocks/modparams/etc in the
large config would be replaced with/added by the option blocks provided;
detailed documentation on the blocks and modparams and what they do/mean
(perhaps with links to the proper lines in the module documentation).
That way you're not keeping separate configs for each option (unless
it's something that completely replaces all the rest of the config), and
as more tricks/suggestions come up, it's easier to add an option or two
to the options sections since they're just small blocks of code.
Just an idea.
N.
2:04 p.m.
Hi Nils,
Good initiative!
I think we need to coordinate our efforts so we avoid duplicate work.
ONsip.org and iptel.org merged partly because we wanted to align the SER
- Getting Started configuration files with the development of SER. As
you probably have seen on the lists, the intention is to add the
document and the config files to the cvs (SER 2.0).
Most beginners of SER (and many OpenSER beginners) start out with the
SER - Getting Started document and configs. From what I have seen, there
are now many, many production configs out there using the basic
structure from the getting started files.
We have learned quite a lot about maintaining example configuration files:
1. People need small pieces in order to understand how each feature is
implemented
2. Without an expert pre-integrating configs/features, many/most? people
struggle to integrate a feature into another config
3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created a
document with commented config files. We made the config files
available standalone (ready to be run) and subsequently focused more and
more on maintaining the configuration files and add more features and
then let the comments/document come afterwards. Keeping everything in
sync was a problem. We had early decided to keep everything in one
common structure and let each config build on each other (to
incrementally add functionality). This helped us in making sure
everything worked and people didn't have to integrate small examples
into one big themselves.
Our biggest problem was to keep adding features and making sure that we
updated configs to new SER versions.
Based on these experiences, we have done the following:
- Migrated the document to docbook
- Created the m4 build system (http://www.iptel.org/ser/doc/buildsystem)
which keeps the configuration files WITH comments and allows
auto-generation of the commented config ready for inclusion in SER -
Getting Started document
In creating the build system, I put emphasize on the capability to
maintain different configuration sets (called feature packages, ex.
gettingstarted) composed of different feature sets (helloworld, auth,
natrtpproxy etc), each consisting of a set of features (natdetection,
natmangling, etc). The configuration files are easier to maintain and as
added value, people can automatically generate their config file based
on an example with correct IP address, port etc. (BTW, I work on
allowing people to generate their config files directly from from iptel.org)
This may sound complicated, but I believe a quick look at the doc
(http://www.iptel.org/ser/doc/buildsystem) will quickly give you the idea.
Currently, the helloworld version of SER - Getting Started has been
migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the
current ser.cfg config with the optimized NAT example, and we will try
to use that config as a starting point for a new NAT SER - Getting
Started configuration file.
I don't think everything should go into the SER - Getting Started
feature package (though we should at least avoid creating two versions
of exactly the same functionality), but I hope you will spend some
minutes to see how a new feature package in the build system can help
your goals. I will of course be happy to assist you (as I have waited to
see interest before documenting creating new feature packages).
g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the
question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would
like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
2:22 p.m.
Indeed, a coordination of these two efforts would be ideal. The OnSIP
Getting Started documentation was(is) well documented and shows
essentially a large configuration example with added options and
detailed information about the options themselves.
More than once, I found myself referring to it for both debugging what I
might have done wrong, and for an understanding of what configurations
options do what. The module documentation is one thing, but more often
than not, a lot more is needed than just a simple function definition in
order to truly understand how a function behaves and should be implemented.
Greger V. Teigre wrote:
Hi Nils,
Good initiative!
I think we need to coordinate our efforts so we avoid duplicate work.
ONsip.org and iptel.org merged partly because we wanted to align the
SER - Getting Started configuration files with the development of SER.
As you probably have seen on the lists, the intention is to add the
document and the config files to the cvs (SER 2.0).
Most beginners of SER (and many OpenSER beginners) start out with the
SER - Getting Started document and configs. From what I have seen,
there are now many, many production configs out there using the basic
structure from the getting started files.
We have learned quite a lot about maintaining example configuration
files:
1. People need small pieces in order to understand how each feature is
implemented
2. Without an expert pre-integrating configs/features, many/most?
people struggle to integrate a feature into another config
3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created
a document with commented config files. We made the config files
available standalone (ready to be run) and subsequently focused more
and more on maintaining the configuration files and add more features
and then let the comments/document come afterwards. Keeping
everything in sync was a problem. We had early decided to keep
everything in one common structure and let each config build on each
other (to incrementally add functionality). This helped us in making
sure everything worked and people didn't have to integrate small
examples into one big themselves.
Our biggest problem was to keep adding features and making sure that
we updated configs to new SER versions.
Based on these experiences, we have done the following:
- Migrated the document to docbook
- Created the m4 build system
(http://www.iptel.org/ser/doc/buildsystem) which keeps the
configuration files WITH comments and allows auto-generation of the
commented config ready for inclusion in SER - Getting Started document
In creating the build system, I put emphasize on the capability to
maintain different configuration sets (called feature packages, ex.
gettingstarted) composed of different feature sets (helloworld, auth,
natrtpproxy etc), each consisting of a set of features (natdetection,
natmangling, etc). The configuration files are easier to maintain and
as added value, people can automatically generate their config file
based on an example with correct IP address, port etc. (BTW, I work on
allowing people to generate their config files directly from from
iptel.org)
This may sound complicated, but I believe a quick look at the doc
(http://www.iptel.org/ser/doc/buildsystem) will quickly give you the
idea.
Currently, the helloworld version of SER - Getting Started has been
migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the
current ser.cfg config with the optimized NAT example, and we will try
to use that config as a starting point for a new NAT SER - Getting
Started configuration file.
I don't think everything should go into the SER - Getting Started
feature package (though we should at least avoid creating two versions
of exactly the same functionality), but I hope you will spend some
minutes to see how a new feature package in the build system can help
your goals. I will of course be happy to assist you (as I have waited
to see interest before documenting creating new feature packages).
g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the
following the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features"
into one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I
would like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:36 p.m.
New subject: [Serdev] Re: [Serusers] Configuration examples
Hi Greger,
thanks for your detailed answer.
I have absolutely no problem with using the new m4 buildsystem. But correct me
if I'm wrong, but AFAIK it is not yet ready to be used, or?
And Jiri keeps pushing me that these configuration examples are important for
the Ottendorf release :-)
So I would propose that I'll keep on putting new config examples into the etc
directory on the CVS until the new buildsystem is ready to be used. And then
I will transfer my configurations to that system.
Greetings
Nils
On Monday 14 May 2007 13:04:23 Greger V. Teigre wrote:
Hi Nils,
Good initiative!
I think we need to coordinate our efforts so we avoid duplicate work.
ONsip.org and iptel.org merged partly because we wanted to align the SER
- Getting Started configuration files with the development of SER. As
you probably have seen on the lists, the intention is to add the
document and the config files to the cvs (SER 2.0).
Most beginners of SER (and many OpenSER beginners) start out with the
SER - Getting Started document and configs. From what I have seen, there
are now many, many production configs out there using the basic
structure from the getting started files.
We have learned quite a lot about maintaining example configuration files:
1. People need small pieces in order to understand how each feature is
implemented
2. Without an expert pre-integrating configs/features, many/most? people
struggle to integrate a feature into another config
3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created a
document with commented config files. We made the config files
available standalone (ready to be run) and subsequently focused more and
more on maintaining the configuration files and add more features and
then let the comments/document come afterwards. Keeping everything in
sync was a problem. We had early decided to keep everything in one
common structure and let each config build on each other (to
incrementally add functionality). This helped us in making sure
everything worked and people didn't have to integrate small examples
into one big themselves.
Our biggest problem was to keep adding features and making sure that we
updated configs to new SER versions.
Based on these experiences, we have done the following:
- Migrated the document to docbook
- Created the m4 build system (http://www.iptel.org/ser/doc/buildsystem)
which keeps the configuration files WITH comments and allows
auto-generation of the commented config ready for inclusion in SER -
Getting Started document
In creating the build system, I put emphasize on the capability to
maintain different configuration sets (called feature packages, ex.
gettingstarted) composed of different feature sets (helloworld, auth,
natrtpproxy etc), each consisting of a set of features (natdetection,
natmangling, etc). The configuration files are easier to maintain and as
added value, people can automatically generate their config file based
on an example with correct IP address, port etc. (BTW, I work on
allowing people to generate their config files directly from from
iptel.org)
This may sound complicated, but I believe a quick look at the doc
(http://www.iptel.org/ser/doc/buildsystem) will quickly give you the idea.
Currently, the helloworld version of SER - Getting Started has been
migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the
current ser.cfg config with the optimized NAT example, and we will try
to use that config as a starting point for a new NAT SER - Getting
Started configuration file.
I don't think everything should go into the SER - Getting Started
feature package (though we should at least avoid creating two versions
of exactly the same functionality), but I hope you will spend some
minutes to see how a new feature package in the build system can help
your goals. I will of course be happy to assist you (as I have waited to
see interest before documenting creating new feature packages).
g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following
the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into
one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I
would like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
15 May
15 May
8:25 a.m.
New subject: [Serdev] Re: [Serusers] Configuration examples
It's ready to be used :-)
I'll try to prioritize the how-to for new feature packages and I will commit it to cvs
trunk.
If you like, I can add the first example for you as a template.
g-)
------- Original message -------
From: Nils Ohlmeier <nils(a)iptel.org>
Cc: greger(a)teigre.com, serdev(a)iptel.org, serusers(a)iptel.org
Sent: 14.5.'07, 16:36
Hi Greger,
thanks for your detailed answer.
I have absolutely no problem with using the new m4 buildsystem. But correct me
if I'm wrong, but AFAIK it is not yet ready to be used, or?
And Jiri keeps pushing me that these configuration examples are important for
the Ottendorf release :-)
So I would propose that I'll keep on putting new config examples into the etc
directory on the CVS until the new buildsystem is ready to be used. And then
I will transfer my configurations to that system.
Greetings
Nils
On Monday 14 May 2007 13:04:23 Greger V. Teigre wrote:
Hi Nils,
Good initiative!
I think we need to coordinate our efforts so we avoid duplicate work.
ONsip.org and iptel.org merged partly because we wanted to align the SER
- Getting Started configuration files with the development of SER. As
you probably have seen on the lists, the intention is to add the
document and the config files to the cvs (SER 2.0).
Most beginners of SER (and many OpenSER beginners) start out with the
SER - Getting Started document and configs. From what I have seen, there
are now many, many production configs out there using the basic
structure from the getting started files.
We have learned quite a lot about maintaining example configuration files:
1. People need small pieces in order to understand how each feature is
implemented
2. Without an expert pre-integrating configs/features, many/most? people
struggle to integrate a feature into another config
3. Maintaining many config files quickly becomes an impossible task
We started out with a focus on the "getting started" and thus created a
document with commented config files. We made the config files
available standalone (ready to be run) and subsequently focused more and
more on maintaining the configuration files and add more features and
then let the comments/document come afterwards. Keeping everything in
sync was a problem. We had early decided to keep everything in one
common structure and let each config build on each other (to
incrementally add functionality). This helped us in making sure
everything worked and people didn't have to integrate small examples
into one big themselves.
Our biggest problem was to keep adding features and making sure that we
updated configs to new SER versions.
Based on these experiences, we have done the following:
- Migrated the document to docbook
- Created the m4 build system (http://www.iptel.org/ser/doc/buildsystem)
which keeps the configuration files WITH comments and allows
auto-generation of the commented config ready for inclusion in SER -
Getting Started document
In creating the build system, I put emphasize on the capability to
maintain different configuration sets (called feature packages, ex.
gettingstarted) composed of different feature sets (helloworld, auth,
natrtpproxy etc), each consisting of a set of features (natdetection,
natmangling, etc). The configuration files are easier to maintain and as
added value, people can automatically generate their config file based
on an example with correct IP address, port etc. (BTW, I work on
allowing people to generate their config files directly from from
iptel.org)
This may sound complicated, but I believe a quick look at the doc
(http://www.iptel.org/ser/doc/buildsystem) will quickly give you the idea.
Currently, the helloworld version of SER - Getting Started has been
migrated to SER 2.0 and Alfred Heggestad and Ladislav have merged the
current ser.cfg config with the optimized NAT example, and we will try
to use that config as a starting point for a new NAT SER - Getting
Started configuration file.
I don't think everything should go into the SER - Getting Started
feature package (though we should at least avoid creating two versions
of exactly the same functionality), but I hope you will spend some
minutes to see how a new feature package in the build system can help
your goals. I will of course be happy to assist you (as I have waited to
see interest before documenting creating new feature packages).
g-)
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following
the question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into
one config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I
would like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 
6:51 p.m.
New subject: [Serdev] Re: [Serusers] Configuration examples
Hi
its need both, one big example file
and seperated example file each module config files should be good idea
ram
14 May
14 May
7:01 p.m.
New subject: [Serusers] Re: [Serdev] Configuration examples
Hi Nils
It would be very useful to have 1 (one) big configuration file implementing
a superset of the most popular features (nathelper, tls, presence etc..)
and split into logical parts, so people can remove/disable unwanted features.
If you can publish the ser.cfg for the SER running on sip:iptel.org that would
be even better.. Nothing beats a working config from long-term deployment.
I am currently also assisting Greger now, to get the ser.cfg build system
up2dated with working configuration files..
/alfred
Nils Ohlmeier wrote:
Hello everybody,
as we want to provide more examples for the configuration the following the
question came up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would
like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
7:21 p.m.
New subject: [Serusers] Re: [Serdev] Configuration examples
As for me I am largely in favor of having a kind of config-file "super-store" or
"exchange" -- it
appears there is never enough of those :-)
-jiri
At 18:01 14/05/2007, Alfred E. Heggestad wrote:
Hi Nils
It would be very useful to have 1 (one) big configuration file implementing
a superset of the most popular features (nathelper, tls, presence etc..)
and split into logical parts, so people can remove/disable unwanted features.
If you can publish the ser.cfg for the SER running on sip:iptel.org that would
be even better.. Nothing beats a working config from long-term deployment.
I am currently also assisting Greger now, to get the ser.cfg build system
up2dated with working configuration files..
/alfred
Nils Ohlmeier wrote:
--
Jiri Kuthan http://iptel.org/~jiri/
Hello everybody,
as we want to provide more examples for the configuration the following the question came
up:
Do you prefer
- one big example configuration
- probably harder to understand
- easier to maintain for us
- one example config file per "feature"
- probably easier to understand your desired "feature"
- you might have problems to integrate all your desired "features" into one
config without breaking anything
- harder to maintain for us, as we have to update several files :-)
As the configuration examples are indented to be for the community, I would like to know
what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 
8:23 p.m.
New subject: [Serusers] Re: [Serdev] Configuration examples
With the named routes it wouldn't be too difficult to follow a big config
file...
just my 0.02,
sam.
2007/5/14, Jiri Kuthan <jiri(a)iptel.org>rg>:
As for me I am largely in favor of having a kind of config-file
"super-store" or "exchange" -- it
appears there is never enough of those :-)
-jiri
At 18:01 14/05/2007, Alfred E. Heggestad wrote:
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
Hi Nils
It would be very useful to have 1 (one) big configuration file
implementing
a superset of the most popular features
(nathelper, tls, presence etc..)
and split into logical parts, so people can remove/disable unwanted
features.
If you can publish the ser.cfg for the SER running on sip:iptel.org that
would
be even better.. Nothing beats a working config
from long-term
deployment.
I am currently also assisting Greger now, to get the ser.cfg build system
up2dated with working configuration files..
/alfred
Nils Ohlmeier wrote:
>Hello everybody,
>as we want to provide more examples for the configuration the following
the
question came up:
>Do you prefer
>- one big example configuration
> - probably harder to understand
> - easier to maintain for us
>- one example config file per "feature"
> - probably easier to understand your desired "feature"
> - you might have problems to integrate all your desired "features"
into one config without breaking anything
> - harder to maintain for us, as we have to
update several files :-)
>As the configuration examples are indented to be for the community, I
would
like to know what you prefer or if you see other options.
Thanks
Nils
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
6405
days inactive
6406
days old
10 comments
9 participants
participants (9)
-
Alfred E. Heggestad -
flavio -
Greger V. Teigre -
Greger Viken Teigre
-
Jiri Kuthan -
Nils Ohlmeier -
ram -
samuel -
SIP