Module: sip-router
Branch: master
Commit: c44529a8078f7c58d621e5116757da10084180f1
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c44529a…
Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Date: Thu Sep 30 17:04:00 2010 +0300
modules:carrierroute Fix documentation when using cr_route/t_relay in failure routes
Starting with 3.0 version, there is no need to call append_branch in failure routes
before t_relay if the RURI is new(it is done automatically from t_relay).
---
modules/carrierroute/README | 69 +++++++++++------------
modules/carrierroute/doc/carrierroute_admin.xml | 6 +-
2 files changed, 36 insertions(+), 39 deletions(-)
Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=c44…
Module: sip-router
Branch: master
Commit: 22cb194483a7b0d15b823cb8f851cd1fe9746a8c
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=22cb194…
Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Date: Fri Oct 1 12:52:33 2010 +0300
modules/carrierroute: change doc to reflect latest changes in append branch
---
modules/carrierroute/README | 10 +++++-----
modules/carrierroute/doc/carrierroute_admin.xml | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/modules/carrierroute/README b/modules/carrierroute/README
index 5c4f15d..1c28e22 100644
--- a/modules/carrierroute/README
+++ b/modules/carrierroute/README
@@ -272,11 +272,11 @@ Chapter 1. Admin Guide
modules. But for smaller installations it probably make more sense to
use the lcr and dispatcher module.
- Starting with version 3.0 of kamailio, if you want to use this module
- in failure routes, it is not needed to call“append_branch()” after
- rewriting the request URI in order to relay the message to the new
- target. Its also supportes the usage of database derived failure
- routing descisions with the carrierfailureroute table.
+ Starting with version 3.1 , if you want to use this module in failure
+ routes, it is not needed to call“append_branch()” after rewriting the
+ request URI in order to relay the message to the new target. Its also
+ supportes the usage of database derived failure routing descisions with
+ the carrierfailureroute table.
2. Dependencies
diff --git a/modules/carrierroute/doc/carrierroute_admin.xml b/modules/carrierroute/doc/carrierroute_admin.xml
index f83b2c0..d30bb29 100644
--- a/modules/carrierroute/doc/carrierroute_admin.xml
+++ b/modules/carrierroute/doc/carrierroute_admin.xml
@@ -66,7 +66,7 @@
installations it probably make more sense to use the lcr and dispatcher module.
</para>
<para>
- Starting with version 3.0 of kamailio, if you want to use this module in failure routes,
+ Starting with version 3.1 , if you want to use this module in failure routes,
it is not needed to call<quote>append_branch()</quote> after rewriting the request URI in order to
relay the message to the new target. Its also supportes the usage of database
derived failure routing descisions with the carrierfailureroute table.
I was checking what are current differences between the two major
flavours: ser and kamailio.
Apart of the name and default config file, kamailio flavour enables at
compile time KMSTATS, FMSTATS and WITHAS, precisely these are:
ifeq ($(KMSTATS), 1)
C_DEFS+= -DUSE_CORE_STATS -DSTATISTICS
endif
ifeq ($(FMSTATS), 1)
C_DEFS+= -DMALLOC_STATS
endif
ifeq ($(WITHAS), 1)
C_DEFS+= -DWITH_AS_SUPPORT
endif
I am thinking that maybe we can make them (all or some) enabled by
default now that Andrei added the new statistics API.
WITH_AS_SUPPORT enables extra api in TM, iirc this would be needed at
least by seas module.
Anyone with pro/cons?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Hi Daniel, Andrei, Jan, etc.
I have been trying to learn Git so that I can maybe help with the
documentation on the project like I said once I would. Along the way,
I have become curious how the project is managed as it relates to Git.
I have read over Jan's impromptu Git tutorial that he posted on the
Kamailio-devel list some time ago to try to help out people switching
from SVN, but still have some questions.
I am curious, what methodologies and tools do you use for hosting the
central Git repository for sip-router? For instance, what scripts and
tools are used to generate e-mails about submitted patches to the
sr-dev list -- are they standard ones that come with Git, or something
handcrafted or third-party? Also, how do you handle automated pushing
and pulling of various developers' branches? Does the system only
pull your personal branch, so that any topic branches you make are
purely your own and when you want them put into the mainline code, you
merge them into your main branch so they get pulled upstream? What
does the workflow/process like?
Thank you!
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Hello,
soon we have to create the branch for v3.1. This time is going to be a
single branch, therefore we need a clear naming policy, maybe:
- branch_3.1 (or branch-3.1)
- version_3.1 (or version-3.1)
- or simply: 3.1
Other opinions?
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
The jabber module is obsolete and it still exists in both (s) and (k)
module version.
We should remove this module from the upcoming 3.1 release.
Regards,
Ovidiu Sas
Starting with 3.1.x, (k) radius accounting is done via a new module
(acc_radius).
However, the acc module is still refering to radius files via the RAD_ACC flag.
In order to keep the code clean, the RAD_ACC and the associated code
should be removed from the acc module.
If someone will compile kamailio with the RAD_ACC flag enabled an it
will try to use radius accounting via the acc_radius module, we will
have some conflicts: acc with radius enabled and acc_radius.
Regards,
Ovidiu Sas
For the kamailio 3.0.x release, the (s) modules were not included in
the binary distribution (the modules.lst did not include
modules_s_all).
I see that for upcoming kamailio 3.1.x release, while building the
modules list by using 'make FLAVOUR=kamailio cfg' the modules_s_all is
present in the modules.lst. Is this done on purpose?
Do we want to ship the (s) modules with kamailio?
Regards,
Ovidiu Sas