sr-users

sr-users@lists.kamailio.org

48 participants
37555 discussions

NIST advisory
by David Villasmil 02 Dec '21

02 Dec '21

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

5 4

Re: [SR-Users] probles with listen advertise address trying to be resolved
by Richard Robson 01 Dec '21

01 Dec '21

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 … [View More]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 > [View Less]

2 1

Using path with DMQ to send calls to origin SBC - not sure when to modify destination URI
by Rhys Hanrahan 01 Dec '21

01 Dec '21

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 … [View More]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. [View Less]

2 5

Re-writing presentity domain for DMQ
by Rhys Hanrahan 01 Dec '21

01 Dec '21

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 … [View More]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. [View Less]

1 0

probles with listen advertise address trying to be resolved
by Richard Robson 30 Nov '21

30 Nov '21

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 is not resolvable therefroe I have udp,tcp and tls … [View More]

2 2

Kamailio and RTPEngine acting as SBC : wrong IP address returned
by Cyril Ramière 28 Nov '21

28 Nov '21

Hi there, I'm already using Kamailio as a simple proxy and it worked flawlessly. This time, I need to have a new setup like this: [UAC (sip phone)] <--- register & has to deal only with ----> | PUBLIC | [Kamailio + RtpEngine] | PRIVATE | <----> [Asterisk] Client = 37.100.100.100 (public) Asterisk = 172.17.200.20 (private) Kamailio/RtpEngine = 172.17.203.102 (private, advertising 3.99.99.99 public IP) Kamailio and RtpEngine will behave as a SBC/B2BUA, the client will deal … [View More]

2 1

Problem implementing Outbound Proxy
by Christoph Russow 26 Nov '21

26 Nov '21

Hi all, im currently trying to add a Outbound Proxying to our system which right now does inbound loadbalancing for our application servers. Current: Inbound SIP Trunk -> Kamailio -> dispatcher -> ApplicationServer 1..n i now want to add the ability for our internal Application Servers to terminate their outbound calls through the kamailio system. currently i've setup a gateway in the (freeswitch) application server that has the kamailio system set as outbound-proxy. this leads … [View More]

3 11

Call limiting with Kamailio
by Olli Attila 26 Nov '21

26 Nov '21

Hello, What choices do I have to implement a feature to Kamailio which would limit calls per customer? The environment: Two kamailio nodes sitting in different sites and they are not aware of each others sessions/dialogs and thus serving customer calls independently. Configurations on the nodes are identical excluding ip addresses. Customer call can be routed through either one of these Kam nodes. The two nodes share a common external mysql database from which all dialplan and htable entries … [View More]

4 3

cannot adopt OIDs in KAMAILIO-SIP-COMMON-MIB
by Arun Bonela 26 Nov '21

26 Nov '21

Hi we have configured snmp module on our Kamailio server following https://www.kamailio.org/dokuwiki/doku.php/utils:kamailio-and-snmp guidance. Description we could able to poll or snmpwalk most of the OIDs in KAMAILIO-REG-MIB , KAMAILIO-SIP-SERVER-MIB but having issues below from KAMAILIO-SIP-COMMON-MIB snmpd[358730]: Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: kamailioSIPStatsMethod ::= { kamailioSIPMethodStatsEntry 1 } Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: … [View More]kamailioSIPStatsOutbounds ::= { kamailioSIPMethodStatsEntry 2 } Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: kamailioSIPStatsInbounds ::= { kamailioSIPMethodStatsEntry 3 } Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: kamailioSIPStatusCodeMethod ::= { kamailioSIPStatusCodesEntry 1 } Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: kamailioSIPStatusCodeValue ::= { kamailioSIPStatusCodesEntry 2 } Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: kamailioSIPStatusCodeIns ::= { kamailioSIPStatusCodesEntry 3 } Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: kamailioSIPStatusCodeOuts ::= { kamailioSIPStatusCodesEntry 4 } Cannot adopt OID in KAMAILIO-SIP-COMMON-MIB: kamailioSIPStatusCodeRowStatus ::= { kamailioSIPStatusCodesEntry 5 } Troubleshooting root@host# snmpwalk -v2c -c public localhost .1.3.6.1.4.1.34352.3.1.1.1.4.1.1.2.0 SNMPv2-SMI::enterprises.34352.3.1.1.1.4.1.1.2.0 = No Such Object available on this agent at this OID root@host# snmpwalk -v2c -c public localhost .1.3.6.1.4.1.34352.3.1.1.1.4.1.1.2 SNMPv2-SMI::enterprises.34352.3.1.1.1.4.1.1.2 = No Such Object available on this agent at this OID Reproduction using snmpwalk or snmget to any of the above mentioned kamailioSIPStats* OIDs will do Additional Information * Kamailio Version - output of kamailio -v version: kamailio 5.5.1 (x86_64/linux) 307af8-dirty * Operating System: No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.2 LTS Release: 20.04 Any advice, why we seeing this issue for these OIDs ? Are these decremented now ? Regards, Arun Bonela Arun Bonela UCaaS Ops – Technical Lead Tel: 0333 043 7319 Mobile: 07468 728 007 Email: Arun.Bonela(a)gamma.co.uk This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster(a)gamma.co.uk Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place, London, EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY. [View Less]

2 2

Re: [SR-Users] How to not write logs to journald with kamailio
by Ginhoux, Patrick 26 Nov '21

26 Nov '21

Hi, I resend this mail because of the initial destination address was not correct. The topic was a logging problem : With the upgrade of my SIP Router proxies to RHEL 7 (and Kamailio 5.0.7) , we encounter problems where the logs are blocked to be written in the syslog. This problem is similar as the one reported in this article : [SR-Users] Kamailio logs in RHEL 7 environment <https://lists.kamailio.org/pipermail/sr-users/2018-April/101065.html> . The resolution was to … [View More]

5 5

Jump to page:

2025

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