Module: sip-router
Branch: 3.1
Commit: a568684930e5dfea48b0044e17ee2ee57bfede57
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a568684…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Tue Jun 7 22:57:32 2011 +0200
kamctl: don't require sercmd all the time
- sercmd is not needed for all commands - throw error only when it is
going to be executed but it is not found
(cherry picked from commit 8b445f464c7d3904eae5d62a571148c621c3c6f8)
---
utils/kamctl/kamctl | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/utils/kamctl/kamctl b/utils/kamctl/kamctl
index 2ec550a..a68093f 100755
--- a/utils/kamctl/kamctl
+++ b/utils/kamctl/kamctl
@@ -74,8 +74,7 @@ if [ -z "$SERCMD" ] ; then
# try locate it with which
SERCMD=`which sercmd`
if [ ! -f "$SERCMD" -o ! -x "$SERCMD" ] ; then
- merr "sercmd tool not found"
- exit -1;
+ mdbg "sercmd tool not found"
fi
fi
fi
@@ -137,6 +136,14 @@ fi
##### ------------------------------------------------ #####
### CTLENGINE
#
+
+require_sercmd() {
+ if [ -z "$SERCMD" ] ; then
+ merr "sercmd tool is missing"
+ exit -1
+ fi
+}
+
CTLENGINELOADED=0
if [ -z "$CTLENGINE" ] ; then
CTLENGINE="FIFO"
@@ -155,6 +162,7 @@ case $CTLENGINE in
fi
;;
SER_MI|ser_mi|SERCMD_MI|sercmd_mi|SERCMDMI|sercmdmi)
+ require_sercmd
if [ -f "$MYLIBDIR/kamctl.ser_mi" ]; then
. "$MYLIBDIR/kamctl.ser_mi"
CTLENGINELOADED=1
@@ -2398,6 +2406,7 @@ case $1 in
;;
ser|sercmd)
+ require_sercmd
shift
$SERCTLCMD "$@"
;;
Module: sip-router
Branch: master
Commit: 843b411829bbfcd14fd0c18b0271e4b72e9c6ce7
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=843b411…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Fri Jul 1 17:16:19 2011 +0200
presence: document fallback2db parameter, add a obselete warning# Please enter the commit message for your changes. Lines starting
---
modules_k/presence/README | 5 ++++-
modules_k/presence/doc/presence_admin.xml | 6 +++++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/modules_k/presence/README b/modules_k/presence/README
index 060eef3..51ae45e 100644
--- a/modules_k/presence/README
+++ b/modules_k/presence/README
@@ -352,7 +352,10 @@ modparam("presence", "server_address", "sip:10.10.10.10:5060")
this mode, in case a searched record is not found in cache, the search
is continued in database. Useful for an architecture in which
processing and memory load might be divided on more servers using the
- same database.
+ same database. This parameter overwrite the configuration specified
+ from the “db_mode” parameter.
+
+ This parameter is obsolet and will be removed in future releases.
Example 1.11. Set fallback2db parameter
...
diff --git a/modules_k/presence/doc/presence_admin.xml b/modules_k/presence/doc/presence_admin.xml
index 854224f..b2a1629 100644
--- a/modules_k/presence/doc/presence_admin.xml
+++ b/modules_k/presence/doc/presence_admin.xml
@@ -287,7 +287,11 @@ modparam("presence", "server_address", "sip:10.10.10.10:5060")
In this mode, in case a searched record is not found in cache,
the search is continued in database. Useful for an architecture in
which processing and memory load might be divided on more servers
- using the same database.
+ using the same database. This parameter overwrite the configuration
+ specified from the <quote>db_mode</quote> parameter.
+ </para>
+ <para>
+ This parameter is obsolet and will be removed in future releases.
</para>
<example>
<title>Set <varname>fallback2db</varname> parameter</title>
Module: sip-router
Branch: master
Commit: 44ffefe75f3627669d93f574c4f09a77ebd32867
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=44ffefe…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Fri Jul 1 17:12:35 2011 +0200
presence: rename recently added parameter to the 'standard' db_mode that others uses
---
modules_k/presence/README | 18 +++++++++---------
modules_k/presence/doc/presence_admin.xml | 12 ++++++------
modules_k/presence/presence.c | 2 +-
3 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/modules_k/presence/README b/modules_k/presence/README
index d5e4458..060eef3 100644
--- a/modules_k/presence/README
+++ b/modules_k/presence/README
@@ -44,7 +44,7 @@ Juha Heinanen
3.9. max_expires (int)
3.10. server_address (str)
3.11. fallback2db (int)
- 3.12. dbmode (int)
+ 3.12. db_mode (int)
3.13. subs_htable_size (int)
3.14. pres_htable_size (int)
3.15. enable_sphere_check (int)
@@ -96,7 +96,7 @@ Juha Heinanen
1.9. Set max_expires parameter
1.10. Set server_address parameter
1.11. Set fallback2db parameter
- 1.12. Set dbmode parameter
+ 1.12. Set db_mode parameter
1.13. Set subs_htable_size parameter
1.14. Set pres_htable_size parameter
1.15. Set enable_sphere_check parameter
@@ -131,7 +131,7 @@ Chapter 1. Admin Guide
3.9. max_expires (int)
3.10. server_address (str)
3.11. fallback2db (int)
- 3.12. dbmode (int)
+ 3.12. db_mode (int)
3.13. subs_htable_size (int)
3.14. pres_htable_size (int)
3.15. enable_sphere_check (int)
@@ -175,7 +175,7 @@ Chapter 1. Admin Guide
instances, maybe on different servers using the same database. This
parameter remains only for legacy purposes. As a new feature for the
presence engine, it is possible to have three database modes, which one
- can configure through the dbmode parameter. Setting dbmode to 0, 1, 2
+ can configure through the db_mode parameter. Setting db_mode to 0, 1, 2
respective will cause the subscribers to be retrieved from memory only,
from memory and to fallback to database mode in case a record is not
found in memory, and from database only.
@@ -217,7 +217,7 @@ Chapter 1. Admin Guide
3.9. max_expires (int)
3.10. server_address (str)
3.11. fallback2db (int)
- 3.12. dbmode (int)
+ 3.12. db_mode (int)
3.13. subs_htable_size (int)
3.14. pres_htable_size (int)
3.15. enable_sphere_check (int)
@@ -359,18 +359,18 @@ modparam("presence", "server_address", "sip:10.10.10.10:5060")
modparam("presence", "fallback2db", 1)
...
-3.12. dbmode (int)
+3.12. db_mode (int)
This parameter sets the mode in which records are retrieved. Setting
this parameter to 0 or 1 is equivalent to setting fallback2db to 0 or
- 1, respectiv. The dbmode parameter can also take a third value, 2, in
+ 1, respectiv. The db_mode parameter can also take a third value, 2, in
which records are retrieved from database only. So, the three database
modes in which the presence engine can operate are: memory only,
fallback to database, and database only.
- Example 1.12. Set dbmode parameter
+ Example 1.12. Set db_mode parameter
...
-modparam("presence", "dbmode", 2)
+modparam("presence", "db_mode", 2)
...
3.13. subs_htable_size (int)
diff --git a/modules_k/presence/doc/presence_admin.xml b/modules_k/presence/doc/presence_admin.xml
index d13d913..854224f 100644
--- a/modules_k/presence/doc/presence_admin.xml
+++ b/modules_k/presence/doc/presence_admin.xml
@@ -33,8 +33,8 @@
an architecture in which processing and memory load might be divided on
several &kamailio; instances, maybe on different servers using the same database.
This parameter remains only for legacy purposes. As a new feature for the presence engine, it is possible
- to have three database modes, which one can configure through the dbmode parameter.
- Setting dbmode to 0, 1, 2 respective will cause the subscribers to be retrieved from memory only,
+ to have three database modes, which one can configure through the db_mode parameter.
+ Setting db_mode to 0, 1, 2 respective will cause the subscribers to be retrieved from memory only,
from memory and to fallback to database mode in case a record is not found in memory, and from database only.
</para>
<para>The module implements several API functions, that can be used by other
@@ -299,18 +299,18 @@ modparam("presence", "fallback2db", 1)
</example>
</section>
<section>
- <title><varname>dbmode</varname> (int)</title>
+ <title><varname>db_mode</varname> (int)</title>
<para>
This parameter sets the mode in which records are retrieved.
Setting this parameter to 0 or 1 is equivalent to setting fallback2db to 0 or 1, respectiv.
- The dbmode parameter can also take a third value, 2, in which records are retrieved from database only.
+ The db_mode parameter can also take a third value, 2, in which records are retrieved from database only.
So, the three database modes in which the presence engine can operate are: memory only, fallback to database, and database only.
</para>
<example>
- <title>Set <varname>dbmode</varname> parameter</title>
+ <title>Set <varname>db_mode</varname> parameter</title>
<programlisting format="linespecific">
...
-modparam("presence", "dbmode", 2)
+modparam("presence", "db_mode", 2)
...
</programlisting>
</example>
diff --git a/modules_k/presence/presence.c b/modules_k/presence/presence.c
index a1cb13f..df1a4ac 100644
--- a/modules_k/presence/presence.c
+++ b/modules_k/presence/presence.c
@@ -177,7 +177,7 @@ static param_export_t params[]={
{ "server_address", STR_PARAM, &server_address.s},
{ "subs_htable_size", INT_PARAM, &shtable_size},
{ "pres_htable_size", INT_PARAM, &phtable_size},
- { "dbmode", INT_PARAM, &dbmode},
+ { "db_mode", INT_PARAM, &dbmode},
{ "fallback2db", INT_PARAM, &fallback2db},
{ "enable_sphere_check", INT_PARAM, &sphere_enable},
{ "timeout_rm_subs", INT_PARAM, &timeout_rm_subs},
Hi all,
as described before, I am currently implementing
draft-ietf-soc-overload-control-02
(http://tools.ietf.org/html/draft-ietf-soc-overload-control-02) and I
have to add one or more additional parameters to the (remaining) topmost
Via-header in SIP-responses.
So, if my server (server10.biloxi.com) gets (e.g., from rfc3261) a
response from a downstream server like
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.com
;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
...
if of course have to remove the topmost via and then - according to the
oc-draft - add additional oc-paramters (in this example "oc=20"). The
resulting SIP response looks like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com
;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2;oc=20
Via: SIP/2.0/UDP pc33.atlanta.com
;branch=z9hG4bK776asdhds ;received=192.0.2.1
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
...
Well, my question is now, where to modify/add this parameter.
If I understood the code correctly, the function
"build_res_buf_from_sip_buf()" (in msg_translator.c) might be the right
location to add the modification. My aditional oc-parameter is stored in
a char* and the msg is stored in the struct sip_msg. I saw that many
request-modifications are done with the "lumps"-functions, but I don't
get an idea how they are helping to solve my problem.
So, how can I add this char* to the end of the remaining topmost
via-header?
Any hint/idea?
br
Michael Hirschbichler
--
Michael Hirschbichler, Mag. Dipl.-Ing.
Institute of Telecommunications
Vienna University of Technology
A-1040 Wien, Favoritenstr. 9-11/388
Phone: +43 1 58801 38846
Hi, RFC 3261 states that using a SIP URI in the Request Line or Route
header with sips scheme and ;transport=tls is deprecated, and instead
sips schema and ;transport=tcp (or absence of ;transport param) should
be used.
Sip-Router behaves correctly when the URI schema is sips (it performs
_sips._tcp SRV query or directly tries to open a TLS connection if the
URI has ;transport=tcp).
But in case Sip-Router receives a request with RURI
"sip:alice@domain.org;transport=tls" (and no Route header) it ignores
the transport param and behaves as if the URI would be
"sip:alice@domain.org;transport=udp".
I opened a thread in sip-implementors and the conclusion is that a
proxy receiving a request with sip sheme and ;transport=tls should use
TLS transport (so if there is no port it should use 5061):
https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-June/027277.h…https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-June/027299.h…
Some responses during the thread:
------------------
Is RFC 3261 really stating that transport=tls is no longer valid? The
mention of transport=tls being deprecated in "Section 26.2.2 SIPS URI
Scheme" indicates that the use of the transport=tls option is deprecated for
SIPS URIs which means it should still be a perfectly valid option for SIP
URIs. And in fact in "Section 28.2 Minor Functional Changes" one of the
items is "Added TLS and SCTP as valid SIP transports" so it would seem
strange for RFC 3261 to add it and deprecate it at the same time. And of
course transport=tls is perfectly valid according to the BNF.
------------------
------------------
My understanding is that transport=tls is a valid option for SIP URIs.
For SIPS URIs it's a valid but deprecated option and I guess the
reason it's deprecated is that TLS is already implied to be mandatory.
-----------------
In fact, some UA's set a Contact "sip:user@IP:PORT;transport=tls" when
they register using TLS. Incoming in-dialog requests to such UA would
fail as the proxy would try to open/reuse a TCP connection with such
IP:PORT (rather than a TLS connection).
IMHO if Sip-Router receives a request with transport=tls it should
resolve the domain (A/AAAA query if it's a domain), set port =5061 (if
port is not given) and open/reuse a TLS connection.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>