[sr-dev] [kamailio/kamailio] core: add new param sip_parser_oneline (PR #2904)

Daniel-Constantin Mierla notifications at github.com
Wed Oct 27 14:18:02 CEST 2021

First, I find the name of the parameter a bit confusing, because it does not control the "parser" mode , but logging, so can eventually be something like `sip_parser_log_oneline`, `log_msg_error_online` or something that reflect it is about logging in case of error.

Then, somehow I feel it's opening the door for troubles, as it replaces content inside the incoming buffer. Probably now the logging is like last action done with the buffer content, but the current paradigm is that incoming buffer is not changed.

I would propose to create a more generic solution that can be used even when an error occurs, but it is not last use of the buffer (e.g., processing error, but it is still ok to send a reply or do something else).

My idea right now would be to create a function like:

char *ksr_buf_oneline(char *inbuf, int inlen)
   static outbuf[BUF_SIZE];
   int outlen;
   int i = 0;

  if (cfg_get(core, core_cfg, sip_parser_oneline) == 0) {
     return inbuf;

  if(inbuf==NULL) {
    outbuf[0] = '\0';
    return outbuf;

  outlen = (inlen<BUF_SIZE)?inlen:BUF_SIZE-1;
  memcpy(outbuf, inbuf, outlen);
  outbuf[outlen] = '\0';

  for (i = 0; i < outlen;  i++) {
        if(buf[i] == '\r') ...
  return outbuf;

Then can be used like:

	LOG(cfg_get(core, core_cfg, sip_parser_log), "ERROR: parse_msg: message=<%.*s>\n",
			(int)msg->len, ZSW(ksr_buf_oneline(msg->buf, (int)msg->len)));

There is a memcpy, but this is expected to be used on error or troubleshooting.

Also, as a side note, you don't need to do `strlen(msg->buf)`, its length is in `msg->len` field.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20211027/8821671c/attachment.htm>

More information about the sr-dev mailing list