> With this PR, I understood you actually want to replace the default
> _ksr_slog_func(...)
That is right.
> so I added the option to be able to set the _ksr_slog_func.
Thanks!
I'll try to submit another PR with improvements to the `LOG_XX` macro as
mentioned above for a uniform logging entr
> Source file and line number are part of the structure passed to the
> slog-function:
I understand, my question was about the possibility of adding a flavour of the
`LOG_XX` macro that takes file/line as arguments and populates the slog
structure rather than always using `__FILE__`/`__LINE__`.
@miconda thanks for looking into this! Indeed it seems that structured logging
takes care of most of our needs. But I'm not sure whether it would allow us to
do uniform logging from config files. Let me explain: right now we're using
custom log function from the PR and we're "manually" resolving
> Does it affect in any way the modules log_custom or log_systemd?
Hi @miconda , did the above answer provide sufficient details for you?
> it seems rather important change considering that logging is critical
> component
Perhaps you would us to make any additional changes to further isolate th
> Does it affect in any way the modules log_custom or log_systemd?
It does not. Mentioned modules rely on the `_km_log_func` (set via
`km_log_func_set`) while this patch uses `_km_custom_log_func` (set via
`km_custom_log_func_set`) and makes no changes to the `_km_log_func`. The only
downside
Hi @miconda , is there anything else we need to do in order to ensure this PR
is merged or will the Kamailio team take it from here?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3909#issuecomment-313191
You are receiving this because you are
Hi @miconda ,
thanks for your feedback!
Regarding `ksr_logdata_t`, most likely it got flagged by some static checker,
but we've re-tested the original version and couldn't pin-point which exact
check/rule triggered this.
Regarding the `asprintf` - thanks for spotting the memory leak! We've ne
on implemented?
--
Ivan Ribakov
Software Engineer
www.zaleos.net
On Sat, 29 Apr 2023 at 15:29, Richard Fuchs wrote:
> On 28/04/2023 18.56, [EXT] Ivan Ribakov wrote:
>
> Hi all,
>
> I looked at Kamailio 5.6.3 makefiles and saw mention of clang being
> supported. Yet when I try to build
o/kamailio/modules/tm/t_funcs.h:45:
/tmp/kamailio/kamailio/modules/tm/timer.h:204:2: error: no matching
function for call to 'atomic_cmpxchg_int'
Any suggestions on how to overcome this error or any general suggestions
for using Kamailio + clang?
clang version 14.0.6 (Red Hat 14.0.
Still looking for an answer to how make body multipart for each of the forked
INVITEs or a confirmation of the fact that this can not be done due to the
complications around TX + msg_apply_changes().
Regards,
Ivan
> On 14 Jul 2021, at 13:24, Ivan Ribakov wrote:
>
> Does anyone have
Does anyone have any idea about this?
> On 7 Jul 2021, at 15:04, Ivan Ribakov wrote:
>
> Hi Daniel,
>
> According to textops module documentation, use of “set_body_multipart”
> requires the execution of “msg_apply_changes()” (tested) -
> https://kamailio.org/docs/
s() will change it, impacting
> everything.
>
> But again, you can add/remove headers, etc ... in branch routes and
> changes will be applied when sending out.
>
> Cheers,
> Daniel
>
> On 06.07.21 15:34, Ivan Ribakov wrote:
>> Hi all,
>>
>> I need to
Hi all,
I need to modify headers and body of the ingress INVITE in the
BRANCH_FAILURE_ROUTE block to reflect failure to deliver message to the first
destination and include some additional information. However checking the
documentation of the “sip_msg_apply_changes”
(https://github.com/kamai
Hi all,
Recently I’ve asked the below question in the users mailing list but I didn’t
get any response. I was wondering if someone in this mailing list could at
least tell me whether what I’m trying to achieve is event doable or not so that
I know whether I should invest more effort into findin
### Description
We're considering migrating our Kamailio-based product to Gitlab and attempted
to setup a PoC of a build pipeline using Gitlab's CI capabilities. We used the
same Docker build image but ran into some unexpected problems when running
`make`. In short, sequence of steps can be s
Bump
> On 21 May 2019, at 17:33, Ivan Ribakov wrote:
>
> Hi,
>
> I’ve been using TM module’s C API (tm_load..h -> struct tm_binds ->
> t_request_outside()) for some time now to generate new requests from custom
> module’s C code. What I haven’t come across so f
Hi,
I’ve been using TM module’s C API (tm_load..h -> struct tm_binds ->
t_request_outside()) for some time now to generate new requests from custom
module’s C code. What I haven’t come across so far is any type of switch to
generate TCP traffic. Is it supported? If so, how can that be controlle
ar, e.g.
> bridging an existing dialog. It uses uac_req_t and a TM callback. You find
> the implementation in dlg_transfer.c, e.g. function dlg_bridge(str *from, str
> *to, str *op, str *bd).
>
> Cheers,
>
> Henning
>
> Am 08.05.19 um 09:26 schrieb Ivan Ribakov:
>&g
Not sure if my previous email was posted due to me being not subscribed to the
mailing list so just writing this now (after subscribing) to make sure it gets
posted.
> On 9 May 2019, at 09:38, Ivan Ribakov wrote:
>
> Thanks for your feedback Henning.
>
> Regarding dev mai
19 matches
Mail list logo
