Hello,
I just pushed a patch to git master branch to write that log message to info message. I will backport it these days to the stable branches.
Cheers, Daniel
On 13.12.18 09:01, Olli Attila wrote:
Hello,
Yes the log message level is the thing I was referring to with the handling. I didn't wrote it clearly, sorry about that.
Is there any way to change this from ERROR to INFO? Surely this is not a big deal (calls are working) but there is a little bit of confusion when we browse these logs and ERROR and CRITICAL messages are usually the ones that we will focus on.
Cheers, Olli to 13. jouluk. 2018 klo 9.49 Daniel-Constantin Mierla (miconda@gmail.com) kirjoitti:
Hello,
On 13.12.18 07:22, Olli Attila wrote:
Hello,
I'm getting these error messages on kamailio log from time to time: Dec 11 19:18:30 /usr/sbin/kamailio[23913]: ERROR: tm [t_reply.c:482]: _reply_light(): can't generate 487 reply when a final 200 was sent out Dec 8 04:44:56 /usr/sbin/kamailio[14960]: ERROR: tm [t_reply.c:482]: _reply_light(): can't generate 487 reply when a final 486 was sent out Dec 5 07:46:04 /usr/sbin/kamailio[14961]: ERROR: tm [t_reply.c:482]: _reply_light(): can't generate 487 reply when a final 480 was sent out
Kamailio is configured to act as a proxy between SBC and a softswitch. According to the signaling we can see that these errors occure when the SBC sends CANCEL message towards Kamailio when at the same time final reply is received from the Softswitch side. The call seems to be teared down nicely and finally Kamailio replies to SBC by sending "200 ok, no more pending brances". I guess Kamailio treats this situation as an error because the sip processing engine has sent the final reply out and at the same time SBC sends the CANCEL to Kamailio. Is there any way we could handle this situation better on Kamailio end? The three example ERROR messages are from cases where B subscriber has answered the call, the B has been busy and the last one is from a case where B subscriber has been temporarily unavailable.
this kind of the race can happen and it is ok from specs point of view. The proxy already finished the transaction from its perspective, once it sent out a final response, so changing that makes no sense. Probably this log message should not be an ERROR, maybe an INFO or even DEBUG.
Cheers, Daniel
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training -- www.asipto.com