20 Aug
2019
20 Aug
'19
9:40 p.m.
My Kamailio master based test sip proxy has two rtpengine sets:
```
# sip-proxy_ctl rtpengine.show all
{
url: udp:192.26.134.1:6050
set: 0
index: 0
weight: 1
disabled: 0
recheck_ticks: 0
}
{
url: udp:192.26.134.40:6050
set: 1
index: 1
weight: 1
disabled: 0
recheck_ticks: 0
}
```
Config calls set_rtpengine_set() with two set argument followed by rtpengine_offer():
```
set_rtpengine_set("1", "0");
rtpengine_offer("...");
```
Debug shows that sip proxy sends TWO offer commands to the
rtpproxy in the first set 1 and NONE to the rtpproxy in the second set 0.
Debug at set 1 engine:
```
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: NOTICE: [5e1407211cc50fd9]: Creating new
call
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: INFO: [5e1407211cc50fd9]: Replying to
'offer' from 192.26.134.1:33284 (elapsed time 0.000812 sec)
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: INFO: [5e1407211cc50fd9]: Received command
'offer' from 192.26.134.1:33284
Aug 19 18:06:08 buster-10-0 rtpengine[1314]: INFO: [5e1407211cc50fd9]: Replying to
'offer' from 192.26.134.1:33284 (elapsed time 0.005247 sec)
```
This looks like a bug to me, since according to README, rtpengine should first send the
offer to an engine in the first set and then to an engine in the second set.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2039
22 Aug
22 Aug
5:27 p.m.
I added some INFO call to set_rtpengine_set_f():
``` INFO("set1/set2 = %u/%u\n", selected_rtpp_set_1->id_set,
selected_rtpp_set_2->id_set);
return 1;
```
and it correctly printed:
```
Aug 22 17:20:47 salmon /usr/bin/sip-proxy[29734]: INFO: set_rtpengine_set(1, 0)
```
Then I added INFO call to set_rtpengine_set_from_avp():
```
if ((setid_avp_param == NULL) ||
(avp = search_first_avp(setid_avp_type, setid_avp, &setid_val, 0)) == NULL) {
if (direction == 1 || !selected_rtpp_set_2)
active_rtpp_set = selected_rtpp_set_1;
else
active_rtpp_set = selected_rtpp_set_2;
LM_INFO("active_rttp_set = %u\n", active_rtpp_set->id_set);
return 1;
}
```
and it showed that first active set is 1 and second is 0:
```
Aug 22 17:20:47 salmon /usr/bin/sip-proxy[29734]: INFO: rtpengine [rtpengine.c:3169]:
set_rtpengine_set_from_avp(): active_rttp_set = 1
Aug 22 17:20:47 salmon /usr/bin/sip-proxy[29734]: INFO: rtpengine [rtpengine.c:3169]:
set_rtpengine_set_from_avp(): active_rttp_set = 0
```
Still both offers are sent to engine in set 1.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2039#issuecomment-523930224
6:11 p.m.
I think I found where the bug is. In select_rtpp_node() function there is this function
call:
``` // lookup node
node = select_rtpp_node_old(callid, viabranch, do_test, op);
```
When select_rtpp_node() is called second time, active_rttp_set is set2, but
select_rtpp_node_old() returns the previous node from set1 and a node from set2 is not
selected.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2039#issuecomment-523948555
6:54 p.m.
I made this kind of patch and it seems to work in my tests, but I may have missed
something.
```
unsigned int node_in_set(struct rtpp_node *node, struct rtpp_set *set) {
struct rtpp_node *current = set->rn_first;
while (current) {
if (current->idx == node->idx) return 1;
current = current->rn_next;
}
return 0;
}
```
```
static struct rtpp_node * select_rtpp_node(...) {
...
// lookup node
node = select_rtpp_node_old(callid, viabranch, do_test, op);
// check node
if (!node || (node_in_set(node, active_rtpp_set) == 0)) {
...
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2039#issuecomment-523965844
26 Aug
26 Aug
10:02 p.m.
Closed #2039.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2039#event-2584666320
10:02 p.m.
Fixed by https://github.com/kamailio/kamailio/pull/2040.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2039#issuecomment-524987390
1920
days inactive
1926
days old
5 comments
1 participants
participants (1)
-
juha-h