With latest rtpengine module, rtpengine_offer generates to syslog:
Feb 9 03:05:03 lohi /usr/bin/sip-proxy[11835]: NOTICE: rtpengine [rtpengine.c:2792]: select_rtpp_node_old(): rtpengine hash table lookup failed to find node for calllen=16 callid=48e2ba8176be0f4a viabranch=z9hG4bK9c06a007a1197f4b0
Why such a message? Looking at the code, it seems to be OK that the node is not found on a first call of rtpengine_offer:
-- Juha
// lookup node node = select_rtpp_node_old(callid, viabranch, do_test);
// check node if (!node) { // run the selection algorithm node = select_rtpp_node_new(callid, viabranch, do_test);
// check node if (!node) { LM_ERR("rtpengine failed to select new for calllen=%d callid=%.*s\n", callid.len, callid.len, callid.s); return NULL; } }
Also rtpengine_delete() generates the same kind of message. Here are all of them from a new test:
rtpengine_offer(...):
Feb 9 03:38:24 lohi /usr/bin/sip-proxy[11835]: NOTICE: rtpengine [rtpengine.c:2792]: select_rtpp_node_old(): rtpengine hash table lookup failed to find node for calllen=16 callid=d2016dd39cf7e31c viabranch=z9hG4bKd2248c35ea208c050
rtpengine_answer(...):
no NOTICE
rtpengine_delete():
Feb 9 03:38:39 lohi /usr/bin/sip-proxy[11819]: NOTICE: rtpengine [rtpengine.c:2792]: select_rtpp_node_old(): rtpengine hash table lookup failed to find node for calllen=16 callid=d2016dd39cf7e31c viabranch=
Rtpengine is working on this call. Why the messages?
-- Juha
On 09.02.2016 03:09, Juha Heinanen wrote:
With latest rtpengine module, rtpengine_offer generates to syslog:
Feb 9 03:05:03 lohi /usr/bin/sip-proxy[11835]: NOTICE: rtpengine [rtpengine.c:2792]: select_rtpp_node_old(): rtpengine hash table lookup failed to find node for calllen=16 callid=48e2ba8176be0f4a viabranch=z9hG4bK9c06a007a1197f4b0
Why such a message? Looking at the code, it seems to be OK that the node is not found on a first call of rtpengine_offer:
Hi Juha,
The NOTICE message indicates that there is no entry in the hastable for the *(callid, viabranch)* pair, and the node selection algorithm will start running (select_rtpp_node_new()). This means that a new entry will be added in the hastable, containing the selected node for the pair.
The above is applicable for the delete() also, meaning that maybe other node could be selected than the one for the offer() and the call not being deleted properly from the original, offer() node.
IMO, the logs can go LM_DBG, because the info is useful when trying to debug a rtpengine call.
Regards, Stefan
smititelu writes:
The NOTICE message indicates that there is no entry in the hastable for the *(callid, viabranch)* pair, and the node selection algorithm will start running (select_rtpp_node_new()). This means that a new entry will be added in the hastable, containing the selected node for the pair.
OK. Since that is not something special that should draw attention to, please downgrade the message to LM_DBG.
The above is applicable for the delete() also, meaning that maybe other node could be selected than the one for the offer() and the call not being deleted properly from the original, offer() node.
My understanding has been that rtpengine_delete() without a branch param, should delete the whole call specified by just the callid. Is that not the case?
-- Juha
On 09.02.2016 10:13, Juha Heinanen wrote:
My understanding has been that rtpengine_delete() without a branch param, should delete the whole call specified by just the callid. Is that not the case?
It deletes the call. The question is to which rtpengine machine is the delete() command sent. Right now the matching is done based on *both* callid and viabranch, no matter the command. So this scenario might happen:
offer: (callid, viabranch1) -> node1 (callid, viabranch2) -> node1
delete: (callid, "") -> node X (the lookup failed, because "" is not found among viabranch1/2, and thus a new node is selected)
I think this scenario should be considered, and node1 to be returned also for (callid, ""), right?
Regards, Stefan
-
Juha Heinanen -
smititelu