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 > <[email protected] <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> 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.tcp_set_otcpid >> >> <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: >>> 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:[email protected]:5060 >>> <http://sip:[email protected]: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:[email protected]: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:[email protected]:5060 >>> <http://sip:[email protected]: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:[email protected]:5060 >>> <http://sip:[email protected]: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:[email protected]:5060 >>> <http://sip:[email protected]: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:[email protected]: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:[email protected]:5060 >>> <http://sip:[email protected]: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:[email protected]:5060 >>> <http://sip:[email protected]: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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> 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> >> > -- > 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> > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
