[SR-Users] Setting $conid per branch
Marrold
kamailio at marrold.co.uk
Fri Mar 19 11:13:52 CET 2021
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>
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> 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:442079460000 at 10.0.130.218:5060 du: sip: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 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 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 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 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 du: sip: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 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 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 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 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> 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 Listsr-users at lists.kamailio.orghttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20210319/2117b60f/attachment.htm>
More information about the sr-users
mailing list