17 Mar
2021
17 Mar
'21
10: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>