[SR-Users] Setting $conid per branch

Daniel-Constantin Mierla miconda at gmail.com
Fri May 14 13:07:15 CEST 2021


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 at gmail.com <mailto:miconda at 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 at gmail.com <mailto:miconda at 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 at gmail.com <mailto:miconda at 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.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:442079460000 at 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 at 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 at 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 at 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 at 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 at sip-server-01
>>>>             Mar  9 10:30:21 proxy-01 /sbin/kamailio[27014]: INFO:
>>>>             <script>: ONSEND: rm: INVITE ru:
>>>>             sip:442079460000 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at sip-server-01
>>>>             Mar  9 10:42:31 proxy-01 /sbin/kamailio[27016]: INFO:
>>>>             <script>: ONSEND: rm: INVITE ru:
>>>>             sip:442079460000 at 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 at 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 at marrold.co.uk
>>>>             <mailto:kamailio at 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 at lists.kamailio.org <mailto:sr-users at 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>
>>>
>>         -- 
>>         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
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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210514/33f58f27/attachment.htm>


More information about the sr-users mailing list