sr-users December 2021

sr-users@lists.kamailio.org

47 participants
44 discussions

by David Villasmil

Anyone knows about this? https://nvd.nist.gov/vuln/detail/CVE-2020-28361 -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337

2 years, 4 months

Re: [SR-Users] probles with listen advertise address trying to be resolved

by Richard Robson

no the problem appear to be with the advertise this makes all listeners listen = PRIV_SOCK advertise MY_PUB_SOCK name = "ext" but listen = PRIV_SOCK_TLS advertise MY_PUB_SOCK_TLS name = "ext_tls" is failing with a look up error on MY_PUB_SOCK_TLS if I try : listen = PRIV_SOCK_TLS advertise "MY_PUB_SOCK_TLS" name = "ext_tls" it fails on a lookup for what ever the def is for that variable e.g. 1.2.3.4:5061 the defs are of the correct syntax if it replace the defs it works e.g listen = tls:10.10.10.10:5061 advertise 1.2.3.4:5061 name = "ext_tls" the two defs math the text above the problen is its working for the "global" defs without any protocl, so its making the tls listener for the wrong port as 5060 so listen = LISTEN_EXTERNAL_SOCKET advertise ADVERTISE_NAT_ADDRESS name = "ext" is working with #!substdef "!LISTEN_EXTERNAL_SOCKET!10.10.10.10:5060!g" and #!substdef "!ADVERTISE_NAT_ADDRESS!1.2.3.4:5060!g" the _TLS versions are not changing the tls port so i have tls on port 5060 when iot should be on 5061 and the name ext_tls where all other sockets are called "ext" Regards, Richard On 30/11/2021 20:03, Karsten Horsmann wrote: > Hi Richard, > > Hmmm for some reason I split my vars into parts. > > And you prefix that with tls? Like this? > > "!ADVERTISE_NAT_ADDRESS_TLS!tls:1.2.3.4:5061!g" > > Best > Karsten > > Richard Robson <richard(a)rikrobson.co.uk> schrieb am Di., 30. Nov. > 2021, 17:48: > > Hi > > > the missing = was my typo in the email and not the config. > > the probelm is only with the TLS advertise and not the non tls > advertise > > these work as expected > > listen = LISTEN_EXTERNAL_SOCKET advertise ADVERTISE_NAT_ADDRESS > name = "ext" > > #!substdef "!ADVERTISE_NAT_ADDRESS!1.2.3.4:5060!g" > > > these do not works > > #!substdef "!ADVERTISE_NAT_ADDRESS_TLS!1.2.3.4:5061!g" does not work > > listen = LISTEN_EXTERNAL_SOCKET_TLS advertise > ADVERTISE_NAT_ADDRESS_TL name = "ext-tls" > > or > > listen = LISTEN_EXTERNAL_SOCKET_TLS advertise > ADVERTISE_NAT_ADDRESS_TLS name = "ext-tls" > > > > if its not quoted then error = cannot resolve 1.2.3.4:5061 > <http://1.2.3.4:5061> of not quoted error = cannot resolve > ADVERTISE_NAT_ADDRESS_TLS > > > if i replace the def with the 1.2.3.4:5061 <http://1.2.3.4:5061> > it works > > > what is hte difference if also changed the name to > ADVERTISE_NAT_ADDRESS_SEC with the same results > > > > > On 30/11/2021 16:21, Karsten Horsmann wrote: >> Hi Richard, >> >> seems that you forgot the equal signs in the listen directive. >> Did kamailio -c -f /etc/kamailio/kamailio.cfg return something? >> http://www.kamailio.org/wiki/cookbooks/devel/core#listen >> >> I did the same with puppet. And I only manipulate my >> /etc/kamailio/kamailio-local.cfg with the configuration >> management tool. >> Small example from my templating. >> >> grep MY_PUB_IP /etc/kamailio/kamailio-local.cfg >> #!substdef "!MY_PUB_IP!1.2.3.4!g" >> .... >> egrep 'MY_HTTPS_ADDR|MY_PUB_IP|_PORT' /etc/kamailio/kamailio.cfg >> import_file "kamailio-local.cfg" >> .... >> #!substdef "!MY_HTTPS_ADDR!tls:MY_PUB_IP:MY_WSS_HTTPS!g" >> .... >> listen=udp:MY_PUB_IP:5060 >> listen=tcp:MY_PUB_IP:5060 >> listen=tls:MY_PUB_IP:5061 >> listen=MY_HTTPS_ADDR >> >> Kind regards >> Karsten >> >> Am Di., 30. Nov. 2021 um 16:57 Uhr schrieb Richard Robson >> <richard(a)rikrobson.co.uk>: >> >> I have a problem when trying to add an advertised address in >> Kamailio 5.4.2 >> >> >> we have a checf config that is populating various variable. >> some of these are for the Listeners >> >> >> >> we have this working and Im getting all protocols for the >> listeners based on the non _TLS Vars but the TLS config is >> trying to resolve ADVERTISE_NAT_ADDRESS_TLS. If I try and >> quote the variable "ADVERTISE_NAT_ADDRESS_TLS" id get an >> error saying 1.2.3.4:5061 <http://1.2.3.4:5061> is not resolvable >> >> >> therefroe I have udp,tcp and tls listeners all on the default >> ports where i need the tls on port 5061 ans not 5060 >> >> >> listen = LISTEN_EXTERNAL_SOCKET advertise >> ADVERTISE_NAT_ADDRESS name = "ext" >> >> listen = LISTEN_INTERNAL_SOCKET name = "int" >> >> listen = LISTEN_EXTERNAL_SOCKET_TLS advertise name = "ext-tls" >> >> listen = LISTEN_INTERNAL_SOCKET_TLS name = "int-tls" >> >> the Vars are defined as >> >> #!define TOPO_NAT >> >> #!substdef "!LISTEN_EXTERNAL_SOCKET!10.10.10.10:5060!g" >> >> #!substdef "!LISTEN_INTERNAL_SOCKET!10.10.10.10:5080!g" >> >> #!substdef "!ADVERTISE_NAT_ADDRESS!1.2.3.4:5060!g" >> >> #!define ENABLE_TLS >> >> #!define TLS_CONFIG_FILE "chef-managed/tls.cfg" >> >> #!substdef "!LISTEN_EXTERNAL_SOCKET_TLS!tls:10.225.73.16:5061!g" >> >> #!substdef "!LISTEN_INTERNAL_SOCKET_TLS!tls:10.225.73.16:5061!g" >> >> #!substdef "!ADVERTISE_NAT_ADDRESS_TLS!1.2.3.4:5061!g" >> >> REgards, >> >> >> Richard >> >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> * sr-users(a)lists.kamailio.org >> Important: keep the mailing list in the recipients, do not >> reply only to the sender! >> Edit mailing list options or unsubscribe: >> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> >> -- >> Mit freundlichen Grüßen >> *Karsten Horsmann* >> >> __________________________________________________________ >> Kamailio - Users Mailing List - Non Commercial Discussions >> *sr-users(a)lists.kamailio.org >> Important: keep the mailing list in the recipients, do not reply only to the sender! >> Edit mailing list options or unsubscribe: >> *https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >

2 years, 4 months

Using path with DMQ to send calls to origin SBC - not sure when to modify destination URI

by Rhys Hanrahan

Hi Everyone, I am trying to add DMQ for redundancy of registrations and USRLOC, and I’m trying to send calls to the correct SBC that is the original registrar for a handset. I’ve been using the thread here where Charles gave some guidance on how to use path to store and use the original SBC: https://lists.kamailio.org/pipermail/sr-users/2018-February/100246.html and https://lists.kamailio.org/pipermail/sr-users/2013-September/079736.html I am struggling with when to decide to modify the destination URI. My testing shows this is required otherwise some handsets will ignore the invite, but right now I am doing it in a blanket form, right before SIPOUT (which is where the origin SBC handles the invite instead of LOCATION). I am sure this is being too heavy-handed though and there are some cases where I won’t want to set this, but I am not sure which? # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) { record_route(); } … xlog("Setting du according to path. Current du is $du\n"); xlog("Current route header: $(hdr(Route))\n"); xlog("Current route: $(hdr(Route){uri.host})\n"); >>> $du = $(hdr(Route){param.value,received}); #xlog("New du destination uri is: $du\n"); # dispatch requests to foreign domains route(SIPOUT); In the linked threads, Charles mentioned that only the last-hop registrar should make this change, but what’s the best way to determine if I am on the last-hop registrar? As per the snippet above, I tried using the {uri.host} transformation to extract the origin SBC’s IP from the route header. My plan is to then compare this against “myself” but I am struggling to extract the right info from the route header. And I am not even sure if this is the right general approach? The route header looks like this: <sip:ORIGIN_SBC_IP:5060;received=sip:UAC_WAN_IP:2048;lr> Any guidance or examples would be appreciated. Thanks! Rhys Hanrahan | Chief Information Officer e: rhys(a)nexusone.com.au<mailto:rhys@nexusone.com.au> [www.nexusone.com.au]<http://www.nexusone.com.au/> [signature_555064778] <http://www.fusiontech.com.au/> NEXUS ONE | FUSION TECHNOLOGY SOLUTIONS p: 1800 NEXUS1 (1800 639 871) or 1800 565 845 | a: Suite 12.03 Level 12, 227 Elizabeth Street, Sydney NSW 2000 www.nexusone.com.au<http://www.nexusone.com.au/> | www.fusiontech.com.au<http://www.fusiontech.com.au/> The information in this email and any accompanying attachments may contain; a. Confidential information of Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties; b. Legally privileged information of Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties; and or c. Copyright material Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties. If you have received this email in error, please notify the sender immediately and delete this message. Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd does not accept any responsibility for loss or damage arising from the use or distribution of this email. Please consider the environment before printing this email.

2 years, 4 months

Re-writing presentity domain for DMQ

by Rhys Hanrahan

Hi Everyone, I am trying to get DMQ working for presence/dialog notifications. Presence works fine locally on the same SBC. The DMQ part itself is also working fine and I can see that the entries in presentity are being replicated between my DMQ nodes. The problem is that when the presentity records are being replicated from another SBC, the domain for that record stays as the IP of the original SBC. Then when the local_watchers is populated, the presentity_uri doesn’t match, and no NOTIFY packets are sent as a consequence. What am I missing here? I can’t see anything in the docs about how to handle this, and I can’t find any examples in the list on how to handle this either, which suggests it isn’t as common of an issue at it seems. See example of what I see in the presentity table below. In this case handset 103 is subscribed to BLFs for 103 and 104. A call came into 103 and generated an early state dialog in the presentity table. MariaDB [kamailio]> select * from presentity; +-------+-------------+--------------+--------+-- | id | username | domain | event | +-------+-------------+--------------+--------+-- 27100 | nexusone103 | x.x.x.53 | dialog | I have modified my registrations and have re-written my SUBSCRIBE and PUBLISH packet headers so that everything uses a common FQDN for both SBCs, that does DNS RR to both SBC IPs. I am also registering from the handset using this FQDN now, and yet although my active_watchers table now expects a presentity URI of XXX(a)sbc.fqdn<mailto:XXX@sbc.fqdn>, the presentity table is still using the IP addresses of the individual node that originated the dialog. MariaDB [kamailio]> select presentity_uri,watcher_username,watcher_domain,event from active_watchers; +----------------------------------------------+------------------+----------------------+-----------------+ | presentity_uri | watcher_username | watcher_domain | event | +----------------------------------------------+------------------+----------------------+-----------------+ | sip:104@sbc.fqdn | nexusone103 | sbc.fqdn | dialog | | sip:103@sbc.fqdn | nexusone103 | sbc.fqdn | dialog | +----------------------------------------------+------------------+----------------------+-----------------+ I’m out of ideas unfortunately. Any advice would be appreciated. Thanks! Rhys Hanrahan | Chief Information Officer e: rhys(a)nexusone.com.au<mailto:rhys@nexusone.com.au> [www.nexusone.com.au]<http://www.nexusone.com.au/> [signature_1328564021] <http://www.fusiontech.com.au/> NEXUS ONE | FUSION TECHNOLOGY SOLUTIONS p: 1800 NEXUS1 (1800 639 871) or 1800 565 845 | a: Suite 12.03 Level 12, 227 Elizabeth Street, Sydney NSW 2000 www.nexusone.com.au<http://www.nexusone.com.au/> | www.fusiontech.com.au<http://www.fusiontech.com.au/> The information in this email and any accompanying attachments may contain; a. Confidential information of Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties; b. Legally privileged information of Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties; and or c. Copyright material Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd or third parties. If you have received this email in error, please notify the sender immediately and delete this message. Fusion Technology Solutions Pty Ltd, Nexus One Pty Ltd does not accept any responsibility for loss or damage arising from the use or distribution of this email. Please consider the environment before printing this email.

2 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users December 2021