9 Mar
2021
9 Mar
'21
10:56 a.m.
Hi all,
I'm currently adding a feature to our Kamailio configuration to fork calls
based on user agent.
To do so I'm getting the registered endpoints with reg_fetch_contacts()
iterating through and matching on them, then using seturi() /
append_branch() and setting the dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP connection,
despite the logs showing the correct destination IP and port in the ONSEND
route.
Looking in the location table I can see each registration has a
connection_id, and the debug log indicates it's finding the connection by
ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find(): found connection by
id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
10 Mar
10 Mar
7 a.m.
Hi,
I've done a bit more digging and realised that $conid is read-only, and
only available for an inbound connection - so I dont think it will achieve
what I need.
I did a bit more troubleshooting and observed the differences in the debug
log between two identical calls:
This example failed - the INVITEs went out to the incorrect endpoint / TCP
connection. The "ulc_conid" from the location table for the TCP endpoint is
13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding to
main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid: 0
flags: 192 ci: 162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding to
child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp
ulc_conid: 13 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found *by id, *which in this
case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND: rm:
INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: udp src: 185.28.212.61:5060 dest: 203.0.113.1:1046 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND: rm:
INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: tcp src: 185.28.212.61:5062 dest: 203.0.113.1:50130 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:1651]: _tcpconn_find(): found connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:2545]: tcpconn_send_put(): found fd in cache (5,
0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the correct endpoints / TCP
connections. The "ulc_conid" from the location table for the TCP endpoint
is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding to
main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid: 0
flags: 192 ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding to
child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp
ulc_conid: 13 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found *by peer address *and
determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND: rm:
INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: udp src: 185.28.212.61:5060 dest: 203.0.113.1:1046 conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND: rm:
INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: tcp src: 185.28.212.61:5062 dest: 203.0.113.1:50130 conid: <null>
ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:1670]: _tcpconn_find(): found connection by peer address
(id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:2548]: tcpconn_send_put(): tcp connection found
(0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs / Ports before a failed
and working call and they had not changed, it was the same TCP connection -
so it doesn't appear to be some interaction with a connection closing or
changing. We also don't see this issue using the standard lookup() function.
Does anyone know why Kamailio is intermittently switching between finding
by peer address and id, and why it's using the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold <kamailio(a)marrold.co.uk> wrote:
Hi all,
I'm currently adding a feature to our Kamailio configuration to fork calls
based on user agent.
To do so I'm getting the registered endpoints with reg_fetch_contacts()
iterating through and matching on them, then using seturi() /
append_branch() and setting the dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP connection,
despite the logs showing the correct destination IP and port in the ONSEND
route.
Looking in the location table I can see each registration has a
connection_id, and the debug log indicates it's finding the connection by
ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find(): found connection
by id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
9:27 a.m.
Hello,
a while ago I did some work to make possible to specify the outgoing tcp
connection id, see:
*
https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.t…
And the next function after it.
However, the testing was minimal, maybe not verifying the entire chain
with t_relay()/forward(). Even more, the specifying of the outbound tcp
connection was supposed to be done internally by the lookup("location"),
the functions from tcpops being added for more config flexibility,
suitable for single branch forwarding or branch_route blocks.
However, in your seem to do manual processing with reg_fetch_contacts(),
not rely on lookup location. You can test with master and use
$sbranch(...) and corresponding functions from pv module, instead of
setting the r-uri and append_branch().
Cheers,
Daniel
On 10.03.21 06:00, Marrold wrote:
Hi,
I've done a bit more digging and realised that $conid is read-only,
and only available for an inbound connection - so I dont think it will
achieve what I need.
I did a bit more troubleshooting and observed the differences in the
debug log between two identical calls:
This example failed - the INVITEs went out to the incorrect endpoint /
TCP connection. The "ulc_conid" from the location table for the TCP
endpoint is 13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>:
Adding to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du: sip:203.0.113.1:1046
<http://203.0.113.1:1046> ulc_conid: 0 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>:
Adding to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found /by id, /which in
this case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du: sip:203.0.113.1:1046
<http://203.0.113.1:1046> proto: udp src: 185.28.212.61:5060
<http://185.28.212.61:5060> dest: 203.0.113.1:1046
<http://203.0.113.1:1046> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du: sip:203.0.113.1:1046
<http://203.0.113.1:1046> proto: tcp src: 185.28.212.61:5062
<http://185.28.212.61:5062> dest: 203.0.113.1:50130
<http://203.0.113.1:50130> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:1651]: _tcpconn_find(): found connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:2545]: tcpconn_send_put(): found fd in cache (5,
0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the correct endpoints /
TCP connections. The "ulc_conid" from the location table for the TCP
endpoint is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>:
Adding to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du: sip:203.0.113.1:1046
<http://203.0.113.1:1046> ulc_conid: 0 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>:
Adding to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found /by peer address
/and determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du: sip:203.0.113.1:1046
<http://203.0.113.1:1046> proto: udp src: 185.28.212.61:5060
<http://185.28.212.61:5060> dest: 203.0.113.1:1046
<http://203.0.113.1:1046> conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du: sip:203.0.113.1:1046
<http://203.0.113.1:1046> proto: tcp src: 185.28.212.61:5062
<http://185.28.212.61:5062> dest: 203.0.113.1:50130
<http://203.0.113.1:50130> conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:1670]: _tcpconn_find(): found connection by peer
address (id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:2548]: tcpconn_send_put(): tcp connection found
(0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs / Ports before a
failed and working call and they had not changed, it was the same TCP
connection - so it doesn't appear to be some interaction with a
connection closing or changing. We also don't see this issue using the
standard lookup() function.
Does anyone know why Kamailio is intermittently switching between
finding by peer address and id, and why it's using the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold <kamailio(a)marrold.co.uk
<mailto:kamailio@marrold.co.uk>> wrote:
Hi all,
I'm currently adding a feature to our Kamailio configuration to
fork calls based on user agent.
To do so I'm getting the registered endpoints
with reg_fetch_contacts() iterating through and matching on
them, then using seturi() / append_branch() and setting the
dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP
connection, despite the logs showing the correct destination IP
and port in the ONSEND route.
Looking in the location table I can see each registration has a
connection_id, and the debug log indicates it's finding the
connection by ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find(): found
connection by id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
11 Mar
11 Mar
11:55 a.m.
Hi Daniel,
I didn't spot those TCPOPs functions, I'll give them a try and let you know
how I get on.
Do you have any idea why Kamailio is intermittently selecting the wrong
connection using ID vs peer address?
Thanks for the suggestions.
Matthew
On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
a while ago I did some work to make possible to specify the outgoing tcp
connection id, see:
*
https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.t…
And the next function after it.
However, the testing was minimal, maybe not verifying the entire chain
with t_relay()/forward(). Even more, the specifying of the outbound tcp
connection was supposed to be done internally by the lookup("location"),
the functions from tcpops being added for more config flexibility, suitable
for single branch forwarding or branch_route blocks.
However, in your seem to do manual processing with reg_fetch_contacts(),
not rely on lookup location. You can test with master and use $sbranch(...)
and corresponding functions from pv module, instead of setting the r-uri
and append_branch().
Cheers,
Daniel
On 10.03.21 06:00, Marrold wrote:
Hi,
I've done a bit more digging and realised that $conid is read-only, and
only available for an inbound connection - so I dont think it will achieve
what I need.
I did a bit more troubleshooting and observed the differences in the debug
log between two identical calls:
This example failed - the INVITEs went out to the incorrect endpoint / TCP
connection. The "ulc_conid" from the location table for the TCP endpoint is
13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding to
main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid: 0
flags: 192 ci: 162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding to
child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found *by id, *which in this
case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: udp src: 185.28.212.61:5060 dest: 203.0.113.1:1046 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: tcp src: 185.28.212.61:5062 dest: 203.0.113.1:50130 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:1651]: _tcpconn_find(): found connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:2545]: tcpconn_send_put(): found fd in cache (5,
0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the correct endpoints / TCP
connections. The "ulc_conid" from the location table for the TCP endpoint
is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding to
main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid: 0
flags: 192 ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding to
child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found *by peer address *and
determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: udp src: 185.28.212.61:5060 dest: 203.0.113.1:1046 conid: <null>
ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046
proto: tcp src: 185.28.212.61:5062 dest: 203.0.113.1:50130 conid: <null>
ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:1670]: _tcpconn_find(): found connection by peer address
(id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:2548]: tcpconn_send_put(): tcp connection found
(0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs / Ports before a failed
and working call and they had not changed, it was the same TCP connection -
so it doesn't appear to be some interaction with a connection closing or
changing. We also don't see this issue using the standard lookup()
function.
Does anyone know why Kamailio is intermittently switching between finding
by peer address and id, and why it's using the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold <kamailio(a)marrold.co.uk> wrote:
Hi all,
I'm currently adding a feature to our Kamailio configuration to fork
calls based on user agent.
To do so I'm getting the registered endpoints with reg_fetch_contacts()
iterating through and matching on them, then using seturi() /
append_branch() and setting the dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP connection,
despite the logs showing the correct destination IP and port in the ONSEND
route.
Looking in the location table I can see each registration has a
connection_id, and the debug log indicates it's finding the connection by
ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find(): found connection
by id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
17 Mar
17 Mar
9:18 a.m.
Hello,
On 11.03.21 10:55, Marrold wrote:
Hi Daniel,
I didn't spot those TCPOPs functions, I'll give them a try and let you
know how I get on.
Do you have any idea why Kamailio is intermittently selecting the
wrong connection using ID vs peer address?
have you tried and got that with lookup("location") or only with your
script-based reg_fetch_contact()?
Cheers,
Daniel
Thanks for the suggestions.
Matthew
On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
a while ago I did some work to make possible to specify the
outgoing tcp connection id, see:
*
https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.t…
<https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.tcp_set_otcpid>
And the next function after it.
However, the testing was minimal, maybe not verifying the entire
chain with t_relay()/forward(). Even more, the specifying of the
outbound tcp connection was supposed to be done internally by the
lookup("location"), the functions from tcpops being added for more
config flexibility, suitable for single branch forwarding or
branch_route blocks.
However, in your seem to do manual processing with
reg_fetch_contacts(), not rely on lookup location. You can test
with master and use $sbranch(...) and corresponding functions from
pv module, instead of setting the r-uri and append_branch().
Cheers,
Daniel
On 10.03.21 06:00, Marrold wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hi,
I've done a bit more digging and realised that $conid is
read-only, and only available for an inbound connection - so I
dont think it will achieve what I need.
I did a bit more troubleshooting and observed the differences in
the debug log between two identical calls:
This example failed - the INVITEs went out to the incorrect
endpoint / TCP connection. The "ulc_conid" from the location
table for the TCP endpoint is 13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>:
Adding to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> ulc_conid: 0
flags: 192 ci: 162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>:
Adding to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found /by id, /which
in this case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: udp src:
185.28.212.61:5060 <http://185.28.212.61:5060> dest:
203.0.113.1:1046 <http://203.0.113.1:1046> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: tcp src:
185.28.212.61:5062 <http://185.28.212.61:5062> dest:
203.0.113.1:50130 <http://203.0.113.1:50130> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:1651]: _tcpconn_find(): found connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:2545]: tcpconn_send_put(): found fd in cache (5,
0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the correct
endpoints / TCP connections. The "ulc_conid" from the location
table for the TCP endpoint is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>:
Adding to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> ulc_conid: 0
flags: 192 ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>:
Adding to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found /by peer
address /and determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: udp src:
185.28.212.61:5060 <http://185.28.212.61:5060> dest:
203.0.113.1:1046 <http://203.0.113.1:1046> conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>:
ONSEND: rm: INVITE ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: tcp src:
185.28.212.61:5062 <http://185.28.212.61:5062> dest:
203.0.113.1:50130 <http://203.0.113.1:50130> conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:1670]: _tcpconn_find(): found connection by peer
address (id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:2548]: tcpconn_send_put(): tcp connection found
(0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs / Ports before
a failed and working call and they had not changed, it was the
same TCP connection - so it doesn't appear to be some interaction
with a connection closing or changing. We also don't see this
issue using the standard lookup() function.
Does anyone know why Kamailio is intermittently switching between
finding by peer address and id, and why it's using the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold <kamailio(a)marrold.co.uk
<mailto:kamailio@marrold.co.uk>> wrote:
Hi all,
I'm currently adding a feature to our Kamailio configuration
to fork calls based on user agent.
To do so I'm getting the registered endpoints
with reg_fetch_contacts() iterating through and matching on
them, then using seturi() / append_branch() and setting the
dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP
connection, despite the logs showing the correct destination
IP and port in the ONSEND route.
Looking in the location table I can see each registration has
a connection_id, and the debug log indicates it's finding the
connection by ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find(): found
connection by id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
19 Mar
19 Mar
12:13 p.m.
We don't see the issue when using the standard lookup() function, only when
we start manually appending branches with the results
from reg_fetch_contact()
Thanks
Matthew
On Wed, Mar 17, 2021 at 7:18 AM Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
On 11.03.21 10:55, Marrold wrote:
Hi Daniel,
I didn't spot those TCPOPs functions, I'll give them a try and let you
know how I get on.
Do you have any idea why Kamailio is intermittently selecting the wrong
connection using ID vs peer address?
have you tried and got that with lookup("location") or only with your
script-based reg_fetch_contact()?
Cheers,
Daniel
Thanks for the suggestions.
Matthew
On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
Hello,
a while ago I did some work to make possible to specify the outgoing tcp
connection id, see:
*
https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.t…
And the next function after it.
However, the testing was minimal, maybe not verifying the entire chain
with t_relay()/forward(). Even more, the specifying of the outbound tcp
connection was supposed to be done internally by the lookup("location"),
the functions from tcpops being added for more config flexibility, suitable
for single branch forwarding or branch_route blocks.
However, in your seem to do manual processing with reg_fetch_contacts(),
not rely on lookup location. You can test with master and use $sbranch(...)
and corresponding functions from pv module, instead of setting the r-uri
and append_branch().
Cheers,
Daniel
On 10.03.21 06:00, Marrold wrote:
Hi,
I've done a bit more digging and realised that $conid is read-only, and
only available for an inbound connection - so I dont think it will achieve
what I need.
I did a bit more troubleshooting and observed the differences in the
debug log between two identical calls:
This example failed - the INVITEs went out to the incorrect endpoint /
TCP connection. The "ulc_conid" from the location table for the TCP
endpoint is 13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding
to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid: 0
flags: 192 ci: 162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding
to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found *by id, *which in
this case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: udp src: 185.28.212.61:5060 dest:
203.0.113.1:1046 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: tcp src: 185.28.212.61:5062 dest:
203.0.113.1:50130 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:1651]: _tcpconn_find(): found connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:2545]: tcpconn_send_put(): found fd in cache (5,
0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the correct endpoints / TCP
connections. The "ulc_conid" from the location table for the TCP endpoint
is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding
to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid: 0
flags: 192 ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding
to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found *by peer address *and
determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: udp src: 185.28.212.61:5060 dest:
203.0.113.1:1046 conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: tcp src: 185.28.212.61:5062 dest:
203.0.113.1:50130 conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:1670]: _tcpconn_find(): found connection by peer address
(id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:2548]: tcpconn_send_put(): tcp connection found
(0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs / Ports before a failed
and working call and they had not changed, it was the same TCP connection -
so it doesn't appear to be some interaction with a connection closing or
changing. We also don't see this issue using the standard lookup()
function.
Does anyone know why Kamailio is intermittently switching between finding
by peer address and id, and why it's using the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold <kamailio(a)marrold.co.uk> wrote:
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hi all,
I'm currently adding a feature to our Kamailio configuration to fork
calls based on user agent.
To do so I'm getting the registered endpoints with reg_fetch_contacts()
iterating through and matching on them, then using seturi() /
append_branch() and setting the dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP connection,
despite the logs showing the correct destination IP and port in the ONSEND
route.
Looking in the location table I can see each registration has a
connection_id, and the debug log indicates it's finding the connection by
ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find(): found connection
by id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
--
30 Mar
30 Mar
2:08 p.m.
Hello,
can you try with master branch to use sbranch-related functions from pv
module along with the result from reg_fetch_contact().
Cheers,
Daniel
On 19.03.21 11:13, Marrold wrote:
We don't see the issue when using the standard
lookup() function, only
when we start manually appending branches with the results
from reg_fetch_contact()
Thanks
Matthew
On Wed, Mar 17, 2021 at 7:18 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 11.03.21 10:55, Marrold wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hi Daniel,
I didn't spot those TCPOPs functions, I'll give them a try and
let you know how I get on.
Do you have any idea why Kamailio is intermittently selecting the
wrong connection using ID vs peer address?
have you tried and got that with lookup("location") or only with
your script-based reg_fetch_contact()?
Cheers,
Daniel
Thanks for the suggestions.
Matthew
On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
a while ago I did some work to make possible to specify the
outgoing tcp connection id, see:
*
https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.t…
<https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.tcp_set_otcpid>
And the next function after it.
However, the testing was minimal, maybe not verifying the
entire chain with t_relay()/forward(). Even more, the
specifying of the outbound tcp connection was supposed to be
done internally by the lookup("location"), the functions from
tcpops being added for more config flexibility, suitable for
single branch forwarding or branch_route blocks.
However, in your seem to do manual processing with
reg_fetch_contacts(), not rely on lookup location. You can
test with master and use $sbranch(...) and corresponding
functions from pv module, instead of setting the r-uri and
append_branch().
Cheers,
Daniel
On 10.03.21 06:00, Marrold wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
Hi,
I've done a bit more digging and realised that $conid is
read-only, and only available for an inbound connection - so
I dont think it will achieve what I need.
I did a bit more troubleshooting and observed the
differences in the debug log between two identical calls:
This example failed - the INVITEs went out to the incorrect
endpoint / TCP connection. The "ulc_conid" from the location
table for the TCP endpoint is 13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR:
<script>: Adding to main branch. ua: Yealink SIP-T42G
29.83.0.120 ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> ulc_conid: 0
flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR:
<script>: Adding to child branch. ua: Yealink SIP-T58
58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags:
192 ci: 162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found /by id,
/which in this case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: udp
src: 185.28.212.61:5060 <http://185.28.212.61:5060> dest:
203.0.113.1:1046 <http://203.0.113.1:1046> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: tcp
src: 185.28.212.61:5062 <http://185.28.212.61:5062> dest:
203.0.113.1:50130 <http://203.0.113.1:50130> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG:
<core> [core/tcp_main.c:1651]: _tcpconn_find(): found
connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG:
<core> [core/tcp_main.c:2545]: tcpconn_send_put(): found fd
in cache (5, 0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the correct
endpoints / TCP connections. The "ulc_conid" from the
location table for the TCP endpoint is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR:
<script>: Adding to main branch. ua: Yealink SIP-T42G
29.83.0.120 ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> ulc_conid: 0
flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR:
<script>: Adding to child branch. ua: Yealink SIP-T58
58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192
ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found /by
peer address /and determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: udp
src: 185.28.212.61:5060 <http://185.28.212.61:5060> dest:
203.0.113.1:1046 <http://203.0.113.1:1046> conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto: tcp
src: 185.28.212.61:5062 <http://185.28.212.61:5062> dest:
203.0.113.1:50130 <http://203.0.113.1:50130> conid: <null>
ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG:
<core> [core/tcp_main.c:1670]: _tcpconn_find(): found
connection by peer address (id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG:
<core> [core/tcp_main.c:2548]: tcpconn_send_put(): tcp
connection found (0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs / Ports
before a failed and working call and they had not changed,
it was the same TCP connection - so it doesn't appear to be
some interaction with a connection closing or changing. We
also don't see this issue using the standard lookup() function.
Does anyone know why Kamailio is intermittently switching
between finding by peer address and id, and why it's using
the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold
<kamailio(a)marrold.co.uk <mailto:kamailio@marrold.co.uk>> wrote:
Hi all,
I'm currently adding a feature to our Kamailio
configuration to fork calls based on user agent.
To do so I'm getting the registered endpoints
with reg_fetch_contacts() iterating through and matching
on them, then using seturi() / append_branch() and
setting the dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP
connection, despite the logs showing the correct
destination IP and port in the ONSEND route.
Looking in the location table I can see each
registration has a connection_id, and the debug log
indicates it's finding the connection by ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find():
found connection by id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
14 May
14 May
1:44 p.m.
Hi,
Apologies for the delay updating this one - it took longer than expected to
get our test platform upgraded to the latest kamailio version that included
the newer TCPOPS functions.
I can confirm that using tcp_get_conid() and tcp_set_otcpid() appears to
work around the issue. I'm still curious why Kamailio is intermittently
getting the wrong connection ID internally.
Thinking about it some more, the issue is actually occuring on the
*main* branch
when we set the following vars from the output of reg_fetch_contacts, as
it's only returning a single contact during testing.
$ru = $var(addr);
$du = $var(received);
$bf = $var(cflags);
$fs = $var(socket);
Thanks
On Tue, Mar 30, 2021 at 12:08 PM Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
Hello,
can you try with master branch to use sbranch-related functions from pv
module along with the result from reg_fetch_contact().
Cheers,
Daniel
On 19.03.21 11:13, Marrold wrote:
We don't see the issue when using the standard lookup() function, only
when we start manually appending branches with the results
from reg_fetch_contact()
Thanks
Matthew
On Wed, Mar 17, 2021 at 7:18 AM Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
Hello,
On 11.03.21 10:55, Marrold wrote:
Hi Daniel,
I didn't spot those TCPOPs functions, I'll give them a try and let you
know how I get on.
Do you have any idea why Kamailio is intermittently selecting the wrong
connection using ID vs peer address?
have you tried and got that with lookup("location") or only with your
script-based reg_fetch_contact()?
Cheers,
Daniel
Thanks for the suggestions.
Matthew
On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hello,
a while ago I did some work to make possible to specify the outgoing tcp
connection id, see:
*
https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.t…
And the next function after it.
However, the testing was minimal, maybe not verifying the entire chain
with t_relay()/forward(). Even more, the specifying of the outbound tcp
connection was supposed to be done internally by the lookup("location"),
the functions from tcpops being added for more config flexibility, suitable
for single branch forwarding or branch_route blocks.
However, in your seem to do manual processing with reg_fetch_contacts(),
not rely on lookup location. You can test with master and use $sbranch(...)
and corresponding functions from pv module, instead of setting the r-uri
and append_branch().
Cheers,
Daniel
On 10.03.21 06:00, Marrold wrote:
Hi,
I've done a bit more digging and realised that $conid is read-only, and
only available for an inbound connection - so I dont think it will achieve
what I need.
I did a bit more troubleshooting and observed the differences in the
debug log between two identical calls:
This example failed - the INVITEs went out to the incorrect endpoint /
TCP connection. The "ulc_conid" from the location table for the TCP
endpoint is 13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding
to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid:
0 flags: 192 ci: 162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR: <script>: Adding
to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found *by id, *which in
this case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: udp src: 185.28.212.61:5060 dest:
203.0.113.1:1046 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: tcp src: 185.28.212.61:5062 dest:
203.0.113.1:50130 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:1651]: _tcpconn_find(): found connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG: <core>
[core/tcp_main.c:2545]: tcpconn_send_put(): found fd in cache (5,
0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the correct endpoints /
TCP connections. The "ulc_conid" from the location table for the TCP
endpoint is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding
to main branch. ua: Yealink SIP-T42G 29.83.0.120 ru:
sip:442079460000@10.0.130.218:5060 du: sip:203.0.113.1:1046 ulc_conid:
0 flags: 192 ci: 95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR: <script>: Adding
to child branch. ua: Yealink SIP-T58 58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found *by peer address *and
determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: udp src: 185.28.212.61:5060 dest:
203.0.113.1:1046 conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO: <script>: ONSEND:
rm: INVITE ru: sip:442079460000@10.0.130.218:5060 du: sip:
203.0.113.1:1046 proto: tcp src: 185.28.212.61:5062 dest:
203.0.113.1:50130 conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:1670]: _tcpconn_find(): found connection by peer address
(id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG: <core>
[core/tcp_main.c:2548]: tcpconn_send_put(): tcp connection found
(0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs / Ports before a
failed and working call and they had not changed, it was the same TCP
connection - so it doesn't appear to be some interaction with a connection
closing or changing. We also don't see this issue using the standard
lookup() function.
Does anyone know why Kamailio is intermittently switching between
finding by peer address and id, and why it's using the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold <kamailio(a)marrold.co.uk> wrote:
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-- Hi all,
I'm currently adding a feature to our Kamailio configuration to fork
calls based on user agent.
To do so I'm getting the registered endpoints with reg_fetch_contacts()
iterating through and matching on them, then using seturi() /
append_branch() and setting the dst-uri and flags as required.
However, calls are intermittently going to the wrong TCP connection,
despite the logs showing the correct destination IP and port in the ONSEND
route.
Looking in the location table I can see each registration has a
connection_id, and the debug log indicates it's finding the connection by
ID:
DEBUG: <core> [core/tcp_main.c:1651]: _tcpconn_find(): found
connection by id: 3
Is there a way to set the conid per branch? Is it necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
--
2:07 p.m.
Hello,
you can look at the code of lookup("location") function to see what
other attributes are set vs what you set via config operations, as you
wrote that with lookup("location") you don't face the issue.
Cheers,
Daniel
On 14.05.21 12:44, Marrold wrote:
Hi,
Apologies for the delay updating this one - it took longer than
expected to get our test platform upgraded to the latest kamailio
version that included the newer TCPOPS functions.
I can confirm that using tcp_get_conid() and tcp_set_otcpid() appears
to work around the issue. I'm still curious why Kamailio is
intermittently getting the wrong connection ID internally.
Thinking about it some more, the issue is actually occuring on the
/main/ branch when we set the following vars from the output
of reg_fetch_contacts, as it's only returning a single contact during
testing.
$ru = $var(addr);
$du = $var(received);
$bf = $var(cflags);
$fs = $var(socket);
Thanks
On Tue, Mar 30, 2021 at 12:08 PM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
can you try with master branch to use sbranch-related functions
from pv module along with the result from reg_fetch_contact().
Cheers,
Daniel
On 19.03.21 11:13, Marrold wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online
May 17-20, 2021 (Europe Timezone) - June 7-10, 2021 (America Timezone)
* https://www.asipto.com/sw/kamailio-advanced-training-online/
We don't see the issue when using the
standard lookup() function,
only when we start manually appending branches with the results
from reg_fetch_contact()
Thanks
Matthew
On Wed, Mar 17, 2021 at 7:18 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
On 11.03.21 10:55, Marrold wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
Hi Daniel,
I didn't spot those TCPOPs functions, I'll give them a try
and let you know how I get on.
Do you have any idea why Kamailio is
intermittently selecting the wrong connection using ID vs
peer address?
have you tried and got that with lookup("location") or only
with your script-based reg_fetch_contact()?
Cheers,
Daniel
Thanks for the suggestions.
Matthew
On Wed, Mar 10, 2021 at 7:27 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
Hello,
a while ago I did some work to make possible to specify
the outgoing tcp connection id, see:
*
https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.t…
<https://www.kamailio.org/docs/modules/stable/modules/tcpops.html#tcpops.f.tcp_set_otcpid>
And the next function after it.
However, the testing was minimal, maybe not verifying
the entire chain with t_relay()/forward(). Even more,
the specifying of the outbound tcp connection was
supposed to be done internally by the
lookup("location"), the functions from tcpops being
added for more config flexibility, suitable for single
branch forwarding or branch_route blocks.
However, in your seem to do manual processing with
reg_fetch_contacts(), not rely on lookup location. You
can test with master and use $sbranch(...) and
corresponding functions from pv module, instead of
setting the r-uri and append_branch().
Cheers,
Daniel
On 10.03.21 06:00, Marrold wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
Hi,
I've done a bit more digging and realised that $conid
is read-only, and only available for an
inbound connection - so I dont think it will achieve
what I need.
I did a bit more troubleshooting and observed the
differences in the debug log between two identical calls:
This example failed - the INVITEs went out to the
incorrect endpoint / TCP connection. The "ulc_conid"
from the location table for the TCP endpoint is 13:
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR:
<script>: Adding to main branch. ua: Yealink SIP-T42G
29.83.0.120 ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046
<http://203.0.113.1:1046> ulc_conid: 0 flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:20 proxy-01 /sbin/kamailio[27014]: ERROR:
<script>: Adding to child branch. ua: Yealink SIP-T58
58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13
flags: 192 ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
The debug log shows the wrong connection was found /by
id, /which in this case was 2, but should have been 13:
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto:
udp src: 185.28.212.61:5060 <http://185.28.212.61:5060>
dest: 203.0.113.1:1046 <http://203.0.113.1:1046> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto:
tcp src: 185.28.212.61:5062 <http://185.28.212.61:5062>
dest: 203.0.113.1:50130 <http://203.0.113.1:50130> ci:
162e3e84-4036-48d7-a1d1-79cc92b7cea4-2-1@sip-server-01
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG:
<core> [core/tcp_main.c:1651]: _tcpconn_find(): found
connection by id: 2
Mar 9 10:30:21 proxy-01 /sbin/kamailio[27014]: DEBUG:
<core> [core/tcp_main.c:2545]: tcpconn_send_put():
found fd in cache (5, 0x7fedc49d2448, 2)
This example worked - the INVITEs went out to the
correct endpoints / TCP connections. The "ulc_conid"
from the location table for the TCP endpoint is still 13:
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR:
<script>: Adding to main branch. ua: Yealink SIP-T42G
29.83.0.120 ru: sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046
<http://203.0.113.1:1046> ulc_conid: 0 flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:30 proxy-01 /sbin/kamailio[27016]: ERROR:
<script>: Adding to child branch. ua: Yealink SIP-T58
58.85.0.5 ru:
sip:442079460000@10.0.130.241:50130;transport=TCP du:
sip:203.0.113.1:50130;transport=tcp ulc_conid: 13
flags: 192 ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
The debug log shows the correct connection was found
/by peer address /and determined the correct connection 13:
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto:
udp src: 185.28.212.61:5060 <http://185.28.212.61:5060>
dest: 203.0.113.1:1046 <http://203.0.113.1:1046> conid:
<null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO:
<script>: ONSEND: rm: INVITE ru:
sip:442079460000@10.0.130.218:5060
<http://sip:442079460000@10.0.130.218:5060> du:
sip:203.0.113.1:1046 <http://203.0.113.1:1046> proto:
tcp src: 185.28.212.61:5062 <http://185.28.212.61:5062>
dest: 203.0.113.1:50130 <http://203.0.113.1:50130>
conid: <null> ci:
95ba0691-bdfc-4293-b99d-d46946cb5180-2-1@sip-server-01
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG:
<core> [core/tcp_main.c:1670]: _tcpconn_find(): found
connection by peer address (id: 13)
Mar 9 10:42:31 proxy-01 /sbin/kamailio[27016]: DEBUG:
<core> [core/tcp_main.c:2548]: tcpconn_send_put(): tcp
connection found (0x7fedc49ce0e8), acquiring fd
Additionally I checked the connection IDs and IPs /
Ports before a failed and working call and they had not
changed, it was the same TCP connection - so it doesn't
appear to be some interaction with a connection closing
or changing. We also don't see this issue using the
standard lookup() function.
Does anyone know why Kamailio is intermittently
switching between finding by peer address and id, and
why it's using the wrong ID?
Thanks again
Matthew
On Tue, Mar 9, 2021 at 8:56 AM Marrold
<kamailio(a)marrold.co.uk
<mailto:kamailio@marrold.co.uk>> wrote:
Hi all,
I'm currently adding a feature to our Kamailio
configuration to fork calls based on user agent.
To do so I'm getting the registered endpoints
with reg_fetch_contacts() iterating through and
matching on them, then using seturi() /
append_branch() and setting the dst-uri and flags
as required.
However, calls are intermittently going to the
wrong TCP connection, despite the logs showing the
correct destination IP and port in the ONSEND route.
Looking in the location table I can see each
registration has a connection_id, and the debug log
indicates it's finding the connection by ID:
DEBUG: <core> [core/tcp_main.c:1651]:
_tcpconn_find(): found connection by id: 3
Is there a way to set the conid per branch? Is it
necessary?
We're using kamailio 5.3.3 on Debian 10.
Thanks
Matthew
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla
<https://www.paypal.me/dcmierla>
1318
days inactive
1384
days old
8 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Marrold