Module: sip-router
Branch: 3.3
Commit: 8ad086aa81bc6ca4fb762264ffcc5e53be819ec2
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=8ad086a…
Author: Anca Vamanu <anca.vamanu(a)1and1.ro>
Committer: Anca Vamanu <anca.vamanu(a)1and1.ro>
Date: Fri Jul 13 16:50:07 2012 +0300
lib/srdb1 : put pooling constans into separate header file to reduce
include dependancy
(cherry picked from commit f3ff581dbd0a53c4c5eafdf829bef0c25e8e8f28)
---
lib/srdb1/db.h | 7 +------
lib/srdb1/db_id.h | 2 +-
lib/srdb1/db_pooling.h | 41 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 43 insertions(+), 7 deletions(-)
diff --git a/lib/srdb1/db.h b/lib/srdb1/db.h
index 2cbcdf7..0844c05 100644
--- a/lib/srdb1/db.h
+++ b/lib/srdb1/db.h
@@ -50,12 +50,7 @@
#include "db_cap.h"
#include "db_con.h"
#include "db_row.h"
-
-
-typedef enum {
- DB_POOLING_PERMITTED,
- DB_POOLING_NONE
-} db_pooling_t;
+#include "db_pooling.h"
/**
* \brief Specify table name that will be used for subsequent operations.
diff --git a/lib/srdb1/db_id.h b/lib/srdb1/db_id.h
index 13ffc85..6d5a93f 100644
--- a/lib/srdb1/db_id.h
+++ b/lib/srdb1/db_id.h
@@ -31,7 +31,7 @@
#define _DB1_ID_H
#include "../../str.h"
-#include "db.h"
+#include "db_pooling.h"
/** Structure representing a database ID */
struct db_id {
diff --git a/lib/srdb1/db_pooling.h b/lib/srdb1/db_pooling.h
new file mode 100644
index 0000000..30daa49
--- /dev/null
+++ b/lib/srdb1/db_pooling.h
@@ -0,0 +1,41 @@
+/*
+ * $Id$
+ *
+ * Copyright (C) 2001-2003 FhG Fokus
+ * Copyright (C) 2007-2008 1&1 Internet AG
+ *
+ * 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
+ */
+
+/**
+ * \file lib/srdb1/db_pooling.h
+ * \ingroup db1
+ * \brief Defines Pooling states
+ *
+ */
+
+#ifndef DB1_POOLING_H
+#define DB1_POOLING_H
+
+
+typedef enum {
+ DB_POOLING_PERMITTED,
+ DB_POOLING_NONE
+} db_pooling_t;
+
+
+#endif /* DB1_POOLING_H */
Hi everyone,
I recently built packages for ARMel, but I'm getting errors compiling for ARMhf.
See http://paste.debian.net/186456/
I believe I need to compile with -DNO_SMP but I'm not sure where those
flags are passed into the build process.
Any assistance would be appreciated.
--Adam
Hi everyone,
I've built ARMel packages of Kamailio (useful for Guruplug, Dreamplug,
Sheevaplug etc).
They are available at http://ge.tt/8efpriM as I have nowhere to host
them. I'm happy for these to be re-hosted.
The ARM-hf builds (Raspberry Pi) will be in progress soon.
Thanks,
Adam
Hello,
I thought I would try and produce a short summary (basically just bullet
points) of what is required for Outbound just to make sure I haven't
missed anything.
There are three use cases for Kamailio with Outbound/Path:
* EDGE server between client and registrar
* Registrar with EDGE server between it and client
* Single server (EDGE server and registrar combined) using Outbound
instead of aliasing for NAT traversal
EDGE server
-----------
* Path
- Existing Path module does (most of) what is required when called for
REGISTER requests
- Received parameters are not needed on Path: headers because we will
use Outbound flow tokens now
* Outbound
- Need to generate/add flow token and ;ob parameter to the
Path/Record-Route headers when:
# It's an initial request (out-of-dialog INVITE, REGISTER, SUBSCRIBE,
or REFER), with
# A single Via:, and
# Top Route: points to us and has ;ob parameter or Contact: has ;ob
parameter or it's a REGISTER with ;+sip.instance, or
# force_outbound() API has been called
- Need to maintain mapping of flow tokens to connections (flow token
to/from source address and port)
- Need an Outbound routing API (related to loose_route()) that sets $du
correctly based on flow token in Route: header (R-URI no longer used)
- If the flow token doesn't match a connection send 430 response
(response sending in kamailio.cfg, but Outbound routing API needs to
return an appropriate error to support this)
Registrar
---------
* Path
- Path already supported in usrloc
* Outbound
- instance and reg IDs already stored in usrloc
- multiple registrations with the same instance ID but different reg IDs
must be supported (may be already)
- Parallel and serial forking behaviour must be preserved, when forking
branch to each unique instance ID not reg ID.
- Need a new/improved lookup() API that returns the location for the
best reg ID and populates an AVP with the other instance IDs in order
they should be tried
- On receipt of 430 response to a request the failed location should be
removed from the usrloc table and the next location (from the AVP)
tried. Similar to the way dispatcher works.
Single server
-------------
* Path
- Use this to add single (local) Path header - just needed to get the
Outbound flow token into the usrloc table
- Received parameters are not needed on Path: headers because we will
use Outbound flow tokens now
* Outbound
- Similar to the combined behaviour of EDGE server and Registrar, but
because the mapping of flow token to connection is local there is no
need for the 430 response stuff - can just loop through the list of
matching connections locally until a good one is found.
Note: Double-Path and advertised address...
* Talking to one of my colleagues he thought that double-Path headers
wouldn't be required. Double-RR is used to make sure the route-set is
good in both directions when there are transport/network changes. Because
Path is just used in the one direction this shouldn't be required. Does
this make sense?
* Because the Path header needs to show the address of the outbound
interface it should use the advertised address for that interface, not the
listening address of the interface. Is this correct?
Proposed API
------------
Right thing to do might be a new outbound module which provides both the
EDGE server and registrar functions. The module would bind (through C-API
- which might need extended/tweaked for each of the modules) to path, rr,
registrar, and location modules to make use of the functions already
implemented there. Probably (when Outbound is used) path, rr, and
registrar will not be called from kamailio.cfg directly - the outbound
wrapper functions will be used instead:
* outbound_route(): use instead of rr.loose_route() (may well call
rr.loose_route() internally but will also use flow token to work out value
for $du)
* outbound_record_route(): use instead of rr.record_route() (may well call
rr.record_route() internally - but will also add the flow token (if the
requirements for Outbound are met in the request))
* outbound_add_path(): use instead of path.add_path() (may well call
path.add_path() internally - but will also add the flow token and generate
it (and add to token/connection mapping table) for new connections (if the
requirements for Outbound are met in the request))
* outbound_lookup(): use instead of registrar.lookup() (may well call
registrar.lookup() internally - but will select the contact(s) with the
best reg IDs and fill in AVP)
* outbound_next_contact(): new API which will remove the first contact
from the AVP _and_ location table and select the best remaining reg ID
* force_outbound(): new API which will make sure flow tokens are added by
outbound_record_route() and outbound_add_path() even if the request
doesn't indicate client support
Token/connection map maintenance
----------------------------------
* Is there a need to add an event_route[] to catch connection closes (and
a corresponding outbound module API to remove a token/connection mapping)
as previously suggested by OEJ?
* Is it OK for the outbound.outbound_route() function just to check that a
connection found in the mapping table is valid when attempting to route a
request (and removing the mapping and returning that there was no mapping
when it isn't) - or would this lead to stuck entries in the mapping table?
* Perhaps entries in the map should expire automatically anyway (so no
catching of closes required) - they will be created when a client
registers so there is an expiry time available?
Thanks,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd