msilo/m_dump includes in front of dumped message a string, such as
[Offline message - Mon Oct 5 14:20:38 2009] hello
this is ok, if content type of body is text/plain, but not ok, if
content type is, for example, text/xml.
in my opinion this should be fixed, for example, by calling
m_build_body only of content type is text/plain.
-- juha
Module: sip-router
Branch: master
Commit: d953ef7a6060793aebb06fedc986cd88acb194e4
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d953ef7…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Mon Oct 5 13:03:52 2009 +0200
db schemes(k): fix loading of DTD from internet, reported from Juha
---
doc/stylesheets/dbschema_k/catalog.xml | 84 ++++++++++++++++++++++++++++++++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/doc/stylesheets/dbschema_k/catalog.xml b/doc/stylesheets/dbschema_k/catalog.xml
new file mode 100644
index 0000000..fd30722
--- /dev/null
+++ b/doc/stylesheets/dbschema_k/catalog.xml
@@ -0,0 +1,84 @@
+<?xml version="1.0"?>
+
+<!--
+ * $Id: catalog.xml 4566 2008-08-05 15:03:51Z klaus_darilion $
+ *
+ * XSL converter script for docbook
+ *
+ * Copyright (C) 2001-2007 FhG Fokus
+ *
+ * This file is part of Kamailio, a free SIP server.
+ *
+ * Kamailio is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version
+ *
+ * Kamailio is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+ -->
+
+<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
+ "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
+<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog" prefer="public">
+
+ <!-- DTDs and XSL stylesheets for DBSchema are bundled with Kamailio
+ so we will just redirect xsltproc to their location in the
+ source tree
+ -->
+
+ <public publicId="-//kamailio.org//DTD DBSchema V1.1//EN"
+ uri="dtd/dbschema.dtd"/>
+
+ <rewriteURI uriStartString="http://kamailio.org/pub/kamailio/dbschema/dtd/1.1/"
+ rewritePrefix="dtd/"/>
+
+ <rewriteURI uriStartString="http://kamailio.org/dbschema/xsl/current/"
+ rewritePrefix="xsl/"/>
+
+ <!-- Uncomment the following entry if you have docbook DTDs in unusual
+ location or if you would like to validate the documentation against
+ newer docbook version
+ -->
+ <!--
+ <public publicId="-//OASIS//DTD DocBook XML V4.3//EN"
+ uri="file:///home/henning/docbook/dtd/docbookx.dtd"/>
+ -->
+
+ <!-- Uncomment the following entry if you have docbook XSL stylesheets
+ in unusual location, the value of rewritePrefix parameter should
+ point to the top level directory of your XSL stylesheets
+ -->
+ <!--
+ <rewriteURI uriStartString="http://docbook.sourceforge.net/release/xsl/current/"
+ rewritePrefix="file:///home/henning/docbook/xsl/"/>
+ -->
+
+ <!-- Try the system wide catalogs as the last step before reverting
+ to using the value of system identifiers and URI references
+ from the documents being processed (they usualy contain HTTP
+ URIs).
+ -->
+ <delegatePublic publicIdStartString="" catalog="file:///etc/xml/catalog"/>
+ <delegateURI uriStartString="" catalog="file:///etc/xml/catalog"/>
+
+ <!-- If xsltproc gets here while searching the catalog then no entry was
+ found in the catalog files for the requested resource and in this case
+ xsltproc will attempt to download the resource from the internet using
+ the HTTP protocol. It will use the HTTP URIs from system identifiers
+ and URI references (therefore the XSL customization stylesheets in SER
+ refer to the original XSL stylesheets using HTTP URIs).
+
+ Note: Downloading DTDs and XSL stylesheets can be very slow, because
+ each file will be downloaded several times, because xsltproc
+ does not cache downloaded files.
+ -->
+</catalog>
It's very frustrating that some functions don't accept pseudovariables
and there's no workaround.
For example, in this case I need rtpproxy_offer() and rtpproxy_answer()
to accept an IP address argument that is retrieved from a database.
However, this won't work.
rtpproxy_offer("", $var(src_ip)); # Config compilation error
rtpproxy_offeR("", "$var(src_ip)"); # Results in $var(src_ip)
# literally being placed in the
# SDP body.
I understand it is difficult to go back and update all legacy functions
to accept PVs everywhere. But isn't it possible to provide a
wrapper/compatibility function in the core that will parse a PV and
generate as a result something that other functions can see as a string
literal?
--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Bugs item #2824350, was opened at 2009-07-20 18:49
Message generated for change (Comment added) made by miconda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Hermann (axlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Presence DB support completely broken
Initial Comment:
As subject.
commit 5840 did the damage
----------------------------------------------------------------------
>Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-10-05 10:07
Message:
IIRC, this was fixed, so item can be closed, right?
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-24 15:43
Message:
I agree that choice is better, but it requires a major rewrite. Maybe a
common library can be created for all modules using DB and cache. Maybe
even throw in a memcached cache as a choice. And prepared statements in
case the DB is used during runtime.....
Just missing my favorite mode:
=4: cache only at runtime, DB save/restore at shutdown/init time.
----------------------------------------------------------------------
Comment By: Klaus Darilion (klaus_darilion)
Date: 2009-07-21 16:43
Message:
What about having a new parameter like userloc?
db_mode=
=0: no DB
=1: read from cache, write/update to cache and DB
=2: read from cache, write to cache and delayed write/update to DB
=3: db_only, no cache
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-21 15:00
Message:
Patch is ok, cleaner with new parameter rather than playing with falback2db
value. I will apply it.
Updating on timer is good for the cases of sudden crash, maybe a new mode
to skip timer updates and store only at shutdown is more appropriate.
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-21 14:11
Message:
I decided to dive into the code some more. It's a bit messy. There are 2
modes of operation determined by fallback2db. Both modes don't work
correctly, the documentation for the modes contradict the code it
contradicts ITSELF. So the first thing to do to fix this is to get the
desired behavior for both modes documented.
>From the code I deduced the following behavior:
fallback mode:
init: load from database, keep data in tables
runtime: insert/update records in table on timer event
shutdown: flush cache to db
non-fallback mode:
init: load from database, empty table
runtime: no inserts but try to update table (won't work because table is
emptied)
shutdown: flush cache to db (fails, because all entries are marked
NO_UPDATEDB_FLAG du to the (failed) updates at runtime). Result is an empty
table after shutdown.
The documentation says in fallback mode the cache isn't used. This is
impossible in the current code. Later in the docs it is said only on cache
misses, the db is used. This seems reasonable behavior.
The main question is: should the db be updated during runtime or only on
shutdown when in non-fallback mode?
Attached patch creates the following behavior:
for both modes:
init: load from database, keep table contents
runtime: update/insert into table on timer event
shutdown: update/insert final time
The only difference in the modes is on lookup (as documentation says) and
is untouched by this patch.
The non-fallback mode should be optimized by not updating the table if the
answer to the above question says so, but that is not as trivial as this
patch.
ps. I found some nice descriptive function names: update_db_subs() and
update_subs_db()....
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 20:52
Message:
fallback to db is in presence and the insert function is used by rls module
as well. I had no time to check the impact now.
With this idea, to be safe, fallback2db param has to be directed to
another variable, fallback2db initialized to 0 and set to param value in
each child, via child_init. Otherwise can be a conflict of loading order.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 19:37
Message:
I don't know if changing the API and ABI is appropriate for the stable
series.
What about setting the fallback2db variable only AFTER loading the DB
contents?
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 19:22
Message:
The function is used in presence and rls modules. Does not look like big
changes to add a new param to specify the mode. Do you think of something
else?
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-07-20 19:07
Message:
New subscriptions don't get stored in the DB because the test for
'fallback2db' was wrong.
I just noticed the insert_shtable() function is also used to load from DB
initially, so my patch is wrong. Fix is a bit more non-trivial.
The problem is that the function is used for both DB-load at startup and
new subscriptions during runtime. The db_flag in the hash table record
needs to be INSERTDB_FLAG during runtime, and NO_UPDATEDB_FLAG for initial
load.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-20 18:53
Message:
Please provide a bit more details of what got broken.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…
Bugs item #2819457, was opened at 2009-07-10 11:47
Message generated for change (Comment added) made by miconda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.5.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexandr Dubovikov (baron76)
Assigned to: Nobody/Anonymous (nobody)
Summary: dialog module. BYE with bad Cseq.
Initial Comment:
the dialog module in timeout BYE request send thru tm_module Cseq number from INVITE.
dlg_req_within.c:
function:
dlg_t * build_dlg_t(struct dlg_cell * cell, int dir){
line:
td->loc_seq.value = loc_seq;
if before final 200 OK, we will recieve PRACK/200 (new Cseq) , the dialog module will send bad Cseq number (loc_seq + 1);
Scenario:
----INVITE ( Cseq: 1) ->
<--- 183 ( Cseq: 1) ----
---- PRACK ( Cseq: 3) ->
<---- 200 OK ( Cseq: 3) -
---------- timeout ---->
---- BYE ( Cseq: 2) ->
<------ 503 (Bad CSeq number) -------
Quickly Solution:
td->loc_seq.value = loc_seq + 100;
----------------------------------------------------------------------
>Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-10-05 10:04
Message:
it got met some time :-) -- but majority of dialog module users should
decide. Probably the default of dlg matching should be the one that handles
all cases properly and definitely the docs should be updated.
If there are requests within dialog, the cseq is updated (e.g., update,
re-invite). Delicate situation is pre-confirmed dialog.
----------------------------------------------------------------------
Comment By: Alexandr Dubovikov (baron76)
Date: 2009-07-10 17:02
Message:
should but didn't.
because dlg_onroute check record-route param. If the param is not present,
than ignored this message.
if ( seq_match_mode!=SEQ_MATCH_NO_ID ) {
if( d_rrb.get_route_param( req, &rr_param, &val)!=0) {
LM_DBG("Route param '%.*s' not found\n",
rr_param.len,rr_param.s);
if (seq_match_mode==SEQ_MATCH_STRICT_ID )
return;
}
default value for dlg_match_mode is 0;
so. should works only in dlg_match_mode 2
2 - DID_NONE - the match is done exclusively based on SIP elements; no DID
information is added in RR.
.
so fix should be anyway. Or default value set to 2, or loc_cseq +100 or a
notice in the README: "in 100rel mode, use only dlg_match_mode 2.
Daniel. you should decide. :-)
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2009-07-10 16:22
Message:
CSeq should be increased in dialog module also for PRACKs.
What's the original problem? Is dialog module not able to detect the PRACK
as belonging to the dialog?
----------------------------------------------------------------------
Comment By: Alexandr Dubovikov (baron76)
Date: 2009-07-10 16:19
Message:
ok, in this case we couldn't remove Require, but can use this solution:
http://www.faqs.org/rfcs/rfc3261.html
8.2.2.3 Require
UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0
Require: 100rel
UAS->UAC: SIP/2.0 420 Bad Extension
Unsupported: 100rel
This behavior ensures that the client-server interaction will
proceed without delay when all options are understood by both
sides, and only slow down if options are not understood (as in the
example above). For a well-matched client-server pair, the
interaction proceeds quickly, saving a round-trip often required
by negotiation mechanisms. In addition, it also removes ambiguity
when the client requires features that the server does not
understand. Some features, such as call handling fields, are only
of interest to end systems.
anyway, all ways are posible. But as I told before, just make loc_seq
+=100;
it will be enougth.
Wbr,
Alexandr
----------------------------------------------------------------------
Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-07-10 15:37
Message:
Imagine that the UAC uses "Require: 100rel" instead of "Supported". The
header cannot be removed or the call won't take place.
A proxy shouldn't play to be god :)
----------------------------------------------------------------------
Comment By: Alexandr Dubovikov (baron76)
Date: 2009-07-10 14:56
Message:
> and PRACK/200 ok in the dialog. But I think, the best solution, set
and PRACK/200 are not ok in the dialog. But I think, the best solution,
set
----------------------------------------------------------------------
Comment By: Alexandr Dubovikov (baron76)
Date: 2009-07-10 14:55
Message:
Hi miconda,
much better remove_hf("Supported:") from INVITE request; :-)
and PRACK/200 ok in the dialog. But I think, the best solution, set
loc_seq +100.
P.S. don't forget about UPDATE method.
----------------------------------------------------------------------
Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-07-10 14:48
Message:
quick fix: reply pracks on server, with sl_send_reply() as they just get
into config?!?!
----------------------------------------------------------------------
Comment By: Iñaki Baz Castillo (ibc_sf)
Date: 2009-07-10 13:59
Message:
This is a good example of why a proxy shouldn't try to behave as a B2BUA
XD
----------------------------------------------------------------------
Comment By: Alexandr Dubovikov (baron76)
Date: 2009-07-10 11:50
Message:
oops:
Scenario:
----INVITE ( Cseq: 1) ->
<--- 183 ( Cseq: 1) ----
---- PRACK ( Cseq: 3) ->
<---- 200 OK ( Cseq: 3 PRACK) -
<---- 200 OK ( Cseq: 1 INVITE) -
---------- timeout dialog ---->
---- BYE ( Cseq: 2) ->
<------ 503 (Bad CSeq number) -------
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2819457&group_…
Bugs item #2822344, was opened at 2009-07-16 12:06
Message generated for change (Comment added) made by miconda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2822344&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: ver 1.4.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alex Hermann (axlh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Branch route has wrong ruri or missing headers
Initial Comment:
The scenario:
In branch route, I rewrite the ruri and add an additional header. When the destination fails and DNS-based failover takes place, the branch route is called again. For this second branch, the ruri is not the same as the ruri at t_relay time. Also the extra header is missing.
So this bug could be either:
- The ruri and rest of variables/packet for each branch should be the same as the ruri at t_relay time
or
- The header added in the first branch route should also be present for the second branch (in the case of DNS-based failover)
I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both.
Before t_relay:
$rU = "*1234567890"
t_relay("0x03");
my branch route:
xlog("L_NOTICE", "Branch: <$ru> via <$du>\n");
if (is_method("INVITE") and $(rU{s.substr,0,3}) == "*12") {
strip(3);
append_hf("X-Test: 12\r\n");
}
The log:
Jul 15 09:14:38 Branch: <sip:*1234567890@test.domain;transport=udp> via <<null>>
Jul 15 09:14:38 Reply Status: 503 Service Unavailable
Jul 15 09:14:38 Branch: <sip:234567890@test.domain;transport=udp> via <<null>>
Jul 15 09:14:38 Reply Status: 100 Trying
----------------------------------------------------------------------
>Comment By: Daniel-Constantin Mierla (miconda)
Date: 2009-10-05 09:57
Message:
Have you said on the mailing list that calling t_on_branch() from
branch_route gets what you need?
----------------------------------------------------------------------
Comment By: Alex Hermann (axlh)
Date: 2009-09-04 18:03
Message:
And when there is no response at all from th destination, resulting in a
local generated 408, the behaviour is even different. Then branch route
isn't called at all, but the packet headed for the failover host is
different from the original as it misses any headers added in the branch
route.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2822344&group_…