It has been noticed, that after a list of contributions into lcr:
* 14e6fc8
* d8583d6
* 470fd5b
* aa8d3ed
the gateways matching when a search is being done based on
the IP address and the src_port (through the list of GWs with the same IP)
works, but not fully correct.
It is only related to the usage with the third parameter 'src_port',
when calling from_gw() and from_any_gw(), and, only when the search
is done through the gateways list, which have the same IP address
(but different ports). If gateways have different IPs, the issue
is not catchable.
The problem is in the algorithm used for matching based on
two objects (ip_addr and src_port) - the binary search.
It's not fully suitable for a search based on two (or more) objects.
The binary works completely fine, when only one object is used for searching,
but works not fully correct when the search is based on a comparison
of two (or more) objects. A division happening based on the value of
the first object, gives a chance that the second object will never
be found in the current half being looked up.
This commit concerns switching to a full cycling through the list of
gateways of the same lcr_id, and gives a proper work of the do_from_gw().
The slight drawback of the new method is that we have to do a cycling
through the whole list of GWs of the same lcr_id, but on the other hand
it is much more efficient than trying to build up a matching using binary
based on two objects (ip_addr and src_port) being used for comparison.
Change-Id: I8751adb5137a79e585c21b182319e7496412d81f
This commit deprecates:
* tm: previously added function t_append_branch_by_contact().
* tsilo: previously added functions ts_append_by_contact() / ts_append_by_contact_to()
TM. This commit introduces a possibility of TM's API to append a branch
based on a specific location (Contact's URI).
The function 't_append_branches()' has been extended, and is now able
to obtain a parameter Contact of str type and takes care of appending a branch only for it.
The way how the function acts now depends on if the contact parameter of str type
is given or not (empty or not). If the contact parameter is given, then only a desired location
is meant for appending. If not found in the location table, an append will not happen for this AOR.
Otherwise create branches for all existing location records
of this particular AOR. Search for locations is done in the location table.
TSILO. Add support of a lookup and branch creating by contact
Improvement of the TSILO module, which allows to run a lookup using the provided RURI,
but only to create a new branch for the Contact, which is set in the currently processed REGISTER.
Or optionally a Contact URI value given as a parameter to the function.
If the Contact URI for a lookup, is given as a parameter,
it is possible to provide it as a pseudo-variable.
Hence it is now possible to append new branch(es) for only UAC(s)
getting REGISTERED at the moment of calling script function 'ts_append_by_contact()'.
Previously it was only possible to create new branches
for all previously present location records (for this specific URI), which was in some circumstances undesired.
New script functions introduced: ts_append_by_contact(table, ruri [, contact])
New module functions introduced:
* w_ts_append_by_contact2() / ki_ts_append_by_contact()
* w_ts_append_by_contact3 / ki_ts_append_by_contact_uri()
Change-Id: Idd4775000f8e80999455680704c64a1208c67b3f
* skip_headers is now ignored when a branch's xavps are cloned,
this is needed to transparency that all headers that came with
the SIP message are avaialable via $x_hdr, wheres pv_headers
skips them when they are applied to the SIP message.
Change-Id: I742b373a3a0d38c755aa5ecfb8683e172a4d52f2
generate an uuid for PUBLISH id field instead of callid
https://github.com/kamailio/kamailio/issues/2906
Not exactly the same version from upstream since we
have changes in the module not yet merged
Change-Id: I50dd72f427b94da41c1d46236c05aa041b15f1cb
We need to rewrok TSILO module and partially TM's API,
so that it is able to run a lookup using the provided RURI,
but only create a new branch for the Contact,
which is set in the currently processed REGISTER.
Optionally add a possibility to provide a contact as a pseudo-variable.
Hence we will be able to append new branches for only UAC(s) comming
online now (being REGISTERED).
New script functions introduced, tsilo:
- ts_append_by_contact(table, ruri [, contact])
New functions introduced, tsilo:
- w_ts_append_by_contact2() / ki_ts_append_by_contact()
- w_ts_append_by_contact3 / ki_ts_append_by_contact_uri()
- ts_append_by_contact() / ts_append_by_contact_to()
New functions introduced, TM:
- t_append_branch_by_contact()
Change-Id: Id321a261b137c83bfa38a150c6ff67ca312ae61d
It has been noticed, that after a list of contributions into lcr.so of kamailio,
the from_gw() and from_any_gw() functions are not working fully correct.
However it is only related to the usage with the third parameter 'src_port'.
Last time (last commit into lcr.so), the back compatibility was provided not to break anything for the kamailio community,
this means, it's only related to usage with the 'src_port' parameter.
from_gw() and from_any_gw() functions are not working fine,
when we have tens of gateways with the same IP address in the 'lcr_gw', and you use src_port for searching as well.
It works fine, if you have 2-5 gateways, but not with tens of them.
This is all the matter of the implementation and some limitations of how
the iteration through the memory is done (memory allocated for a list of specific structures),
and binary search used for that.
This is our own Sipwise's patch to handle that case which is intended to be kept internally.
This patch introduces a more simple iteration, but it works more efficient,
when the search for two objects at a time for matching items is done.
Change-Id: I0e7fb2ea59edb7d22636e58f002ca9cb59d42315
Improve binary search in the lcr module and add a possibility
to do a matching not only based on an IP address of a GW, but also using a source port.
When a possibility to use 'src_port' parameter in from_gw() and from_any_gw() was introduced,
the bsearch() remained untouched, and hence the matching (iteration through existing GWs)
is now done only based on an IP address.
This leads to the issue, when there are more than one GW with the same IP address in gws table,
and from_gw() and from_any_gw() functions are used with the 'src_port' parameter,
it can happen that a wrong GW is picked out by bsearch() from gws table (lcr_gw) and
a check by from_gw() and from_any_gw() returns False.
Hence the matching based on IP address and source port is required for bsearch(),
when from_gw() and from_any_gw() functions are used with the 'src_port' parameter.
This means backwards compatibility is still present (when one uses functions without 'src_port').
Change-Id: I90327ef69d8132cc9e11522567cbc026e0808602
A simple change, which allows to check, if a coming request matches
not only by an IP address and a transport protocol,
but also using the source port of a request.
Improvements are done for the following functions of the lcr module:
- from_any_gw()
- from_gw()
Back compatibility provided, hence it does not affect already existing behavior.
Change-Id: Id0496fad75ce64f1abecaa4747b4a77ec6b87cbf
If we set Diversion in split_headers and we get a header like
> "RULTEST, normalaa" <sip:0046341355354340@whatever.net;user=phone>;reason=unconditional
There was false detection of two Diversion headers.
Skip split marker between double quotes to avoid this
Change-Id: Ib2189bc0029f244fd59f14df5b3d1df745271038
Victor Seva
Guillem Jover
Donat Zenichev
Kirill Solomko
Sipwise Jenkins Builder