Hi Henning,

Thank you for answer.

I am referring to regular logging to syslog.

Пятница, 7 сентября 2018, 13:32 +03:00 от Henning Westerholt hw@kamailio.org:

Am Freitag, 7. September 2018, 12:17:17 CEST schrieb Konstantin Polyakov:

...

Could somebody help with one issue?

In some cases Kamailio can send messages itself. For example, when fr_inv_timer is expired Kamailio sends 408 to the INVITE sender and CANCEL to the INVITE receiver. These two messages (408 and CANCEL) are not printed into the log and I cannot find a way to do that. There are also other scenarios when some Kamailio modules send SIP messages by its own.

So is there way to print out into log all such messages? My goal is to get full message flow in the log per certain call-id.

Hello Konstantin,

are you referring to accounting logging? Then have a look to the acc module README (e.g. early_media, failed_transaction_flag, report_ack, report_cancel)

• you can configure the logging this way.

Best regards,

Henning

-- Henning Westerholt https://skalatan.de/blog/

С уважением, Константин Поляков.

Ok,

In my configuration file I print into the log information about each SIP message transferred by Kamailio. For example, xlog("L_NOTICE", "Request: $rm CSeq:$cs CID:$ci from $si:$sp\n");

Request: ACK CSeq:18467 CID:473ae5eb58f9b271 from 192.168.158.139:5060

So when we want to find message flow which belongs to some call, we need just grep by Call-Id.

The problem is that messages generated by Kamailio are not passed through request_route function of configuration script. So script writer cannot log such messages.

My question - is there way to log messages sent by Kamailio itself?

Пятница, 7 сентября 2018, 14:03 +03:00 от Henning Westerholt hw@kamailio.org:

Am Freitag, 7. September 2018, 12:49:02 CEST schrieb Konstantin Polyakov:

...

Hi Henning,

Thank you for answer.

I am referring to regular logging to syslog. [..]

Hi Konstantin,

ok, can you show an example what kind of logging do you expect?

Best regards,

Henning

-- Henning Westerholt https://skalatan.de/blog/

С уважением, Константин Поляков.

Thank you very much. And that is great we fixed documentation issue )

Пятница, 7 сентября 2018, 16:04 +03:00 от Henning Westerholt hw@kamailio.org:

Am Freitag, 7. September 2018, 14:48:01 CEST schrieb Konstantin Polyakov:

...

In my configuration file I print into the log information about each SIP message transferred by Kamailio. For example, xlog("L_NOTICE", "Request: $rm CSeq:$cs CID:$ci from $si:$sp\n");

Request: ACK CSeq:18467 CID:473ae5eb58f9b271 from 192.168.158.139:5060

So when we want to find message flow which belongs to some call, we need just grep by Call-Id.

The problem is that messages generated by Kamailio are not passed through request_route function of configuration script. So script writer cannot log such messages.

My question - is there way to log messages sent by Kamailio itself?

Hello,

have a look to the "failure_route" and "sl/tm:local-reponse" route functionality in the example cfg or in the sl/tm module READMEs. There is some documentation about this missing in tm, I will just add this.

This routes allows you to process failures (including local ones) and also local generated responses.

Best regards,

Henning

-- Henning Westerholt https://skalatan.de/blog/

С уважением, Константин Поляков.

Am Montag, 10. September 2018, 13:58:09 CEST schrieb Konstantin Polyakov:

I used your advise and added into my configuration file two routes sl:local-response and tm:local-response. The log became more detailed.

But when 408 is sent by Kamailio on fr_inv_timer is expired, tm/sl:local-response is not called. This situation can be processed in failure_route using t_branch_timeout() function. However, I believe it is duty of local-response callback function as well.

Something wrong or it is expected behavior?

Hello Konstantin,

good that it logs now what you are expected. It seems that the tm module did not go into the event route for this certain internal generated response. But this should be available in the mentioned (branch-)failure routes.

It could be extended, with a change in the code though.

Best regards,

Henning