[SR-Users] Kamailio ERROR: _reply_light(): can't generate xxx reply when a final yyy was sent out

Daniel-Constantin Mierla miconda at gmail.com
Thu Dec 13 10:27:26 CET 2018


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 at 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
>>
>
-- 
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




More information about the sr-users mailing list