Hello,
The current kamailio devel supports a single P-Asserted-ID or
P-Preferred-ID header value, but the RFC allows one or two either in one
or two headers. [RFC3325 <http://tools.ietf.org/html/rfc3325>]
I am most of the way through coding a fix, but Daniel's comment about
kamailio module licensing has prompted me to wonder about why
parse_ppi/pai is in lib/kcore.
The dev-guide says new headers should be put in parser/parse_xxx.[ch],
but I wasn't going to change the location unless something forces me to.
Is there any guidance on whether I should leave the parse_pai/ppi files
in /lib/kcore or if they should be placed with other files in /parser/?
For information, my change extends the $ai, $pd, $pu, $pn and $pU psuedo
variables so they can be accessed with an index (e.g. $ai[0] and $ai[1])
for the first and second instances of the header values, whether they
occur on one header (comma separated) or on two headers. Existing usage
will not be changed as $ai will continue to return the first instance.
Regards,
Hugh
--
Hugh Waite
Principal Design Engineer
Crocodile RCS Ltd.
Hello,
I am considering to pull out some functions from core and add them to a
new module to be named 'corex (core eXtensions), for few reasons:
- most of the core functions have support for static parameters, some of
them could become more useful if cfg variables (pv + selects) will be
supported there
- then it is easier to export some of these functions to inter-module
API for usage from embedded scripts (lua, perl, ...)
- there are many situations when no core function is used in a config
file (like load balancing cfgs), not loading the code will make the
footprint smaller for embedded system (although, I guess this would be
the least important, the extra size is not that significant).
Why a new module is because it has to stay within the licensing decision
made when we merged ser+kamailio, new core code has to be released under
BSD license, if it is not left under FhG GPL2 (e.g., the case of small
touches to existing code). So if it is gonna be a major copy, it will be
moved with the license, if it is going to be re-coded to support
variables, then will be BSD. With this approach I hope nobody has
anything against, the code can be used like so far.
Any comments?
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw
Hello,
I thought I would update this based on today's feedback... Please let me
know if anything is incorrect or missing.
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
- path and rr modules will be updated to support Outbound (see API
details below)
- NAT keep-alive from section 5.4 support required
- STUN stuff from section 8
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.
- registrar and usrloc modules will be updated to support Outbound (see
API details below)
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 430 response handling - can just loop through the list of
matching connections locally until a good one is found.
Note: Double-Path and advertised address...
* Double-Path is not required as, unlike Record-Route, Path is only used
for routing in the server to client direction.
* 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.
Proposed API
------------
* Either new module (outbound) or additions to an existing utils module that:
- Contains either an exposed function (force_outbound()) or has a
modparam that indicates which flag is used to specify when Outbound
should be forced for a request.
- Contains a modparam that specifies the string to be used as the
encryption key for the flow-token
- Contains a C-API function to perform the Outbound check (deciding
based on message or flag whether to put Outbound stuff in Path: or
Record-Route:)
- Contains a C-API function to generate a flow token string from a set
of connection details (using mechanism recommended in Outbound
specification)
- Contains a C-API function to generate a set of connection details from
a flow token string
* Add new modparam to path and rr module to enable outbound. When
outbound is enabled these modules bind to module providing the Outbound
C-API functions.
- They then use these functions add Outbound Path: and Record-Route:
compatible headers when needed.
- loose_route() function updated to set $du based on decoded flow token
when present [1].
* Add new modparam to enable outbound on registrar and usrloc.
- When outbound is used lookup() populates an AVP (specified as another
modparam) with the ordered list (by reg ID) of contacts
- New lookup_next_dest() API to remove "dead" contact and try the next
[1] If flow token has been tampered with, or indicates a connection that
does not exist (so not active WS, WSS, TCP, TLS, or SCTP connection) then
an error is returned from loose_route() and a 430 should be generated.
Other connection errors (for example, time-outs) handled in
failure_route[] on the EDGE server and converted to 430 where needed.
Token/connection map maintenance
--------------------------------
Map not required. Token is calculated from source address, port, and
protocol and these can be recovered from the token.
Questions
---------
* NAT keep-alive from section 5.4 support... does this need to be handled
in the core before things like the sanity module are called?
* STUN stuff from section 8... again, in the core?
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
We now seem to be experiencing problems with Kamailio running out of
memory after a period of time running our soak test. After dumping the
shared memory I can see that there is no memory leak, but the problem is
that memory is hugely fragmented with all the free blocks being less
that 10k in size, which is too small for the tcp buffer it is trying to
allocate memory for.
We've noticed that there is a new kamailio runtime option mem_join that
by default is 0. Was the previous default dehaviour the equivalent to
this being set to 1?
Thanks
Paul