lua_current will be set to 0 by memset after the memory check anyway
Change-Id: I3bae75611a6f872c7d621ca2dd2b271507c6c074
(cherry picked from commit 3351788015)
ddd4bc1b1481c1ea7c8d5339efd9969a39da0f04 instroduced a change in the
dialog API, but get_dlg_var is not included in 5.6 branch
Change-Id: I0a0064b50f72821a9874b4c3b95ee261c9ae6faa
(cherry picked from commit 6930119dae)
(cherry picked from commit de2e4e136d)
"Use a tag based on the request direction, for an early
transaction record loading."
Important backport from the upstream which we lack in the 5.6.0
version of the kamailio, which is present in mr10.5 .
Without that UPDATE processing is still not working correctly
within an early stage of a dialog.
Change-Id: I61ba4251f395bf5e72aeab450b624cdfaaf9e06c
previously if an error was found we were bailing out and the value
was kept so at next round the value will be there and no more values
where removed
Change-Id: I33bb45f5593dad43f3b5b8b962c77fe99c6f0e38
(cherry picked from commit 07ebcf8f24)
* fix KEMI interface, this is suppose to be called
like pvh_remove_header_param(header_name, string_to_remove)
* use pv buffer for temporal value
* use xavi interface to set the new value
Change-Id: Iaaf5397dd78c0bd3c188eb7a5d55c55a9ce50282
(cherry picked from commit c25de5f099)
The 'dlg.profile_get_size' is specified to return a single value, so
we cannot return a list, otherwise on the XMLRPC interface it gets
serialized into a concatenated list of structs, instead of an actual
array of structs.
Instead we remove the previous overloaded semantics and add a new
command that returns a list, and has a more explicit plural name
following the existing naming convention.
Fixes: commit 7168dd66db
Change-Id: Ib4a620ed680fac340bf4926dc0f1529195c9818c
(cherry picked from commit 73b9d6dd6f)
When using the command 'dlg.profile_get_size' in 'ngcp-kamcmd' one must specify the profile to get its size.
Whith this modification when no parameter is used a list of all profiles with their sizes,
this avoid having to execute the command multiple times.
Change-Id: Ia49a5b1feb08b592d7be9b8d2ce0bc43311aaa24
(cherry picked from commit 7168dd66db)
allows to skip processing messages that don't belong to a test scenario
* improve detection of dynamic format
* fix memory leaks
Change-Id: I63bf4176a5e8dace49c7bd8595a6fb77016818cd
Previously, to remove a parameter from a header it was needed to create a complex method on the configuration file for each header/parameter. This modification moves this complexity to the 'pv_headers' module.
Two new functions:
* pvh_header_param_exists
* pvh_remove_header_param
Both functions take as parameters the name of the header and the name of the parameter.
It returns '-1' if the combination header/parameter:
- is not found (pvh_header_param_exists)
- couldn't be removed (pvh_remove_header_param).
Examples (proxy configuration):
if (pvh_header_param_exists("Supported", "100rel"))
{
// "100rel" is present on the "Supported" header
}
if (pvh_remove_header_param("Supported", "100rel"))
{
// "100rel" removed from header "Supported"
}
Change-Id: I2a95bcb54bf21d64cbf2c6f894b76e9f3cc7bdbc
In the current implementation only parsing of ICE candidate
attributes is supported, which makes it Possible to work
with ICE candidates and parameters specifically related per
candidate, but makes it Impossible to work
with ICE options of the media stream level (ICE options which
have an impact on the whole specific media stream).
ICE candidate attributes and ICE media options have different
dedication.
In order to target this matter, a new linked list is introduced
to store ICE media stream options.
Additionally, now when parsing media stream's attributes,
a couple of new helper functions have been introduced to
properly extract and store ICE media options:
- extract_ice_option()
- add_sdp_ice_opt()
The following extraction approaches are supported:
- multi-valued ICE options attribute (more than one value per a= header)
- one value per attribute (multiple a= headers with ICE options present)
Also now the way how a "zeroed" on-hold is detected is improved,
in case of the ICE (re)negotiation (when the connection address is equal
to '0.0.0.0', the media port is equal to '9' and ice-option 'trickle' is
present) the SDP is Not considered as an on-hold case, and it clearly
detects it's the ICE (re)negotiation (RFC 8840), which for e.g.
leads to a proper work of other side modules' functions (which use SDP
parser's data structures),
such as 'is_audio_on_hold()' from the textops.so module.
Additionally:
core: improve an existing data structures cloning in the SDP parser
It's been noticed that the cloning of SDP session(s) and
SDP stream(s) structures doesn't allocate the ICE candidate attributes,
nor it allocates (recently introduced) ICE media stream options.
In order to target this a couple of new functions have been introduced:
- clone_sdp_opt_attr()
- clone_sdp_ice_attr()
And additionally the following functions have been improved, in order to
properly clone/free ICE candidate attributes and (recently introduced)
ICE media stream options:
- clone_sdp_stream_cell()
- free_cloned_sdp_stream()
- free_sdp()
- print_sdp_stream()
Additionally for a proper new structure length calculation, the following
function is fixed:
- clone_sdp_session_cell()
Change-Id: Ie357cb236af35f1fc7f0efceababc8920206b375
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
Donat Zenichev
Victor Seva
Alessio Garzi
Guillem Jover
Fabricio Santolin da Silva
Kirill Solomko