We are seeing a lot of error messages like:
> ERROR: pua [pua_db.c:895]: get_record_puadb(): Too many rows found (2)
After some investigation I come up with a couple of fixes:
* pua: improve the query to support caller|callee with same pres_id (same dialog)
* pua_dialoginfo: support uuid to generate pres_id to improve randomness
Change-Id: I43d5c58fe20c776b03af217f644443d800c9453e
If the module uses an SDP taken from a pvar, and the current message
uses a multipart content, don't replace the entire message body with the
rewritten SDP, but only the part of the body that is SDP.
Change-Id: I9e43a7c2179c4887f16213c1a2fa2d2bf76b7764
Introduce new function: `allow_register_include_port()`
to be able to check the whole Contact header including port.
Example, register.deny content is:
ALL : "^sip:.*127.0.0.1:5062"
If the Contact is: "Contact: <sip:testuser1004@127.0.0.1:5062>"
then this will check the Contact hf including port of it.
Otherwise if usual `allow_register()` function is used,
then only the "testuser1004@127.0.0.1" will be taken into
account, which will lead the regex to be failing.
The func `allow_register_include_port()` works similarly
as `allow_register()` except it checks Contact's port.
Change-Id: I47820627e8ef91a09d7564d0848d5c356b3017d9
Introduce a versatile behavior of the rtpengine module
in terms of ability to parse flags on the daemon side,
instead of module. Previous behavior is also kept.
General points:
- rtpengine daemon supports rtpp flags processing from now on
- module still provides in the bencode (when calling daemon):
call-id, to/from tags, viabranch (so identification call data)
- even though the module's interface is updated,
a backwards compatibility is given, so no obligatory changes
from kamailio script users required
- each rtpengine module's function which takes rtpp flags
as a parameter, now is able to get a third parameter `viabranch`,
which is used to detect, which approach to use (older/newer):
- without the viabranch - older one used
- with the viabrnach - new one used, so rtpp flags parsing on
the daemoin side
The goal is to deprecate processing of option flags on the module
side and only parse them on the daemon side.
This brings a list of benifits, such as:
- no need to keep in sync daemon and module (for specific flags)
- support of different rtpp flag string formats (raw), so that,
for example, kamailio script users can use plain text or
bencode dictionary like format
Change-Id: I2e7874a6e425d0f25556a45645fa9417cc9f459d
This places the file definitions at the top, and makes sure these long
license texts are shared by multiple File stanzas.
For file specific licenses that are not common we leave them as is in
their File stanzas.
Change-Id: Iddc350c7543ec01c58c2d0b65b6a82a0512df6bd
The location of the license on Debian systems is not part of the
license, nor the license itself. Move it into a Comment to avoid
confusion.
Change-Id: I97685edfc05cb813058ebba25d7ad1e5eb986ab4
When invoking lcr.get_statistics and lcr.stats from kamcmd,
print gateway "flags" field as "gw_id" instead of gw_id because "flags" reflects
what it is reported in webui.
Change-Id: I880d251657c3b0cb87327cb55ed4ce5e28ce027b
For MIME multipart SDPs, the embedded MIME section can contain a
Content-Length header. Update this field if preset after rewriting the
SDP.
Change-Id: If4d8027e79b6976e2e0d30f27868416a1774f2bd
ddd4bc1b1481c1ea7c8d5339efd9969a39da0f04 instroduced a change in the
dialog API, but get_dlg_var is not included in 5.6 branch
Change-Id: I0a0064b50f72821a9874b4c3b95ee261c9ae6faa
Previously all speed dials were related to subscribers. This modification allows having large speed dial numbers (like *999) related to a customer/domain.
Change-Id: I082bd41ca25af8fabd8017f4c42c47bbc079cf77
"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 out master.
Without that UPDATE processing is still not working correctly
within an early stage of a dialog.
Change-Id: I3e151a604ea3ba7de9bb87e4f393cf9dae6120bf
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
* 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
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
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
Sipwise Jenkins Builder
Victor Seva
Richard Fuchs
Donat Zenichev
Guillem Jover
Alessio Garzi
Fabricio Santolin da Silva