[SR-Users] Setting $conid per branch
Daniel-Constantin Mierla
miconda at gmail.com
Tue Mar 30 13:08:37 CEST 2021
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
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210330/e7137e1a/attachment.htm>
More information about the sr-users
mailing list