Res_pjsip_header_funcs: LOG_ERROR flood on non-PJSIP channels — wrong log level?

Development
1

Hey all,

In res_pjsip_header_funcs.c, every guard check that validates the channel is PJSIP logs at LOG_ERROR:

if (!channel || strncmp(ast_channel_name(chan), "PJSIP/", 6)) {
    ast_log(LOG_ERROR, "This function requires a PJSIP channel.\n");
    return -1;
}

This fires on any non-PJSIP leg — Local channels, and on a busy system it floods the log to the point where real errors get buried. It’s not really an error, it’s just the wrong channel type.

Seems like ast_debug(3, …) with the channel name included is the right fix:

ast_debug(3, "This function requires a PJSIP channel (got '%s').\n",
    chan ? ast_channel_name(chan) : "NULL");

Anyone know if there was a reason this was set to LOG_ERROR originally? And is level 3 the right debug tier or should it be 1?

any idea insights ?

2

It can be an error, or maybe it isn’t. That’s the problem. If you’ve written dialplan with the expectation and logic that expects it to work and you then use channels where it doesn’t you can be caught by surprise. I expect that is why it is an error.

When it comes to changing non-debug log messages I don’t like doing it without trying to solicit input and feedback from the actual users.

3

agree 100 %

wanted to hear input …

the issue starts with the history of having 2 implementations and trying to keep each off from the other .

as of now you need to have a test before each time you want to do something with the the header
which is annoying and if you are lazy … you get the errors

how about having the function being able to execute also on local channels (did not do any research if this is anything plausible .)

ah

i see there is a new function [1] PJSIP_INHERITABLE_HEADER which solves this issue at large i think

[1] PJSIP_INHERITABLE_HEADER - Asterisk Documentation

maybe add in the error if channel is local suggest using PJSIP_INHERITABLE_HEADER

4

That functionality is only applicable when writing headers to be sent out on the outgoing leg. All of the read ones it is not applicable.

5

reads where ok by me

(for the simple reason had to test the channel to read or else it did not work . )

the hardship was on the writes

as this changed the way it was implemented in chan_sip ..

we are saving it to a variable PJSIPADDHEADER

because we could not write to a local channel that would be set on the outbound leg…

the reason PJSIP_INHERITABLE_HEADER were introduced.

monolog

question if the channel stays a local will it have the header or is it someplace abstracted just for pjsip ?

answer it is stored in a ast_channel_datastore and not in the header so it is not avail for a local channel ..