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]> 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]> 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 >> >> 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 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:[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 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:[email protected]: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:[email protected]: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:[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 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:[email protected]: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 <[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 >> [email protected]https://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 >> >> -- > Daniel-Constantin Mierla -- www.asipto.comwww.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
