[SR-Users] Re: SDP getting modified.

[Ovidiu Sas via sr-users]

Search the Internet for sip alg and see how can you disable it on your
router.

-ovidiu

On Sun, Apr 28, 2024 at 09:34 Pavan Kumar via sr-users <
sr-users@lists.kamailio.org> wrote:

> Hi everyone,
>
> Here is my setup
>
> SIP Client (MacBook) <=> Kamailio (AWS) <=> Freeswitch (AWS)
>
> When I initiate a call from Client, audio won't be sent out, but the
> client can receive audio. (When the client receives the call
> everything works fine). I started to trace the SIP message using tdpdump.
> And here is an interesting thing.
>
> Kamailio sends the following SDP message while sending 200 OK
>
> v=0
> o=FreeSWITCH 1714278184 1714278185 IN IP4 **
> s=FreeSWITCH
> c=IN IP4 **
> t=0 0
> m=audio 27644 RTP/AVP 120 101
> a=rtpmap:120 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=ptime:20
>
>
> But on my computer where SIP client is running I receive following message
>
> v=0
> o=FreeSWITCH 1714278184 1714278185 IN IP4 **
> s=FreeSWITCH
> c=IN IP4 **
> t=0 0
> m=audio 27644 RTP/AVP 120 101
> a=rtpmap:120 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=ptime:20
>
> Somehow, somewhere, somebody is modifying the IP address in the SDP
> message, hence the SIP client is sending audio to "Kamailio" instead of
> "Freeswitch" server.
>
> My initial guess was my router might be modifying it. After checking the
> router settings I found SIP ALG is enabled. I disabled it, yet no use.
>
> I changed my internet connection to a different provider and things
> started working. SDP is not getting modified.
>
> Have you ever faced such an issue where someone/something is modifying the
> SDP messages. How did you debug to figure out which component was modifying
> it? And common fixes for such weird situations?
>
>
>
> Thanks and Regards,
> Pavan Kumar
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Issue with MS Teams OPTIONS ping - no response

[Ovidiu Sas via sr-users]

Domain of URI works ok with sip.pstnhub.microsoft.com.
Domain of From works ok with localhost.
Domain of To works ok with sip.pstnhub.microsoft.com.
Those are not important.

It is important that you have the right Contact:
Contact: 

If your Contact is right, then something is misconfigured on MS side.
Check that you have the right licences, the right port, that there are
no typos ...
Enable debug logs and check that connection is successful and ensure
that all the certs are valid and set to be verified.

-ovidiu

On Mon, Apr 15, 2024 at 1:38 PM Tyler Preder via sr-users
 wrote:
>
> We set the URI domain in the OPTIONS to match our system’s fqdn.  From your 
> OTPIONS that would be sip:msteams.domain.com.  We do not use 
> sip.pstnhub.microsoft.com as the domain.
>
>
>
> From: Barry Flanagan via sr-users 
> Sent: Monday, April 15, 2024 9:08 AM
> To: sr-users@lists.kamailio.org
> Cc: Barry Flanagan 
> Subject: [SR-Users] Issue with MS Teams OPTIONS ping - no response
>
>
>
> Hi
>
> Using Kamailio 5.6 and trying to get Teams integration working. Failing at 
> the first step! I receive no reply from MS to my OPTIONS ping. AFAIK it is 
> correect, here is the OPTIONs sent:
>
>
>
> OPTIONS sip:sip.pstnhub.microsoft.com;transport=tls SIP/2.0
>
> Via: SIP/2.0/TLS 
> msteams.domain.com:5061;branch=z9hG4bK0c2b.da69f3c3.0
>
> To: 
>
> From: ;tag=6d9effc2a8ec7e0b16377e93bd9e71e2-470e3c71
>
> CSeq: 10 OPTIONS
>
> Call-ID: 6ea8091201db565b-605531@159.65.196.10
>
> Max-Forwards: 70
>
> Content-Length: 0
>
> User-Agent: ABC SBC
>
> Contact: 
>
>
>
> From the logs (below) I can see that w are accepting the MS cert OK but get 
> no response and ends with a 408. The domain is configured in Teams, and a 
> user with a license was added. MY Cert is issued by GeoTrust TLS RSA CA G1.
>
>
>
> Any idea if the issue might be on my side?
>
>
>
> 024-04-15T14:53:19.302610+00:00 msteams /usr/sbin/kamailio[605600]: DEBUG: 
> tls [tls_domain.c:798]: sr_ssl_ctx_info_callback(): SSL handshake done
>
> 2024-04-15T14:53:19.302692+00:00 msteams /usr/sbin/kamailio[605600]: DEBUG: 
> tls [tls_server.c:542]: tls_connect(): TLS connect successful
>
> 2024-04-15T14:53:19.302762+00:00 msteams /usr/sbin/kamailio[605600]: DEBUG: 
> tls [tls_server.c:545]: tls_connect(): tls_connect: new connection to 
> 52.114.14.70:5061 using TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256
>
> 2024-04-15T14:53:19.302824+00:00 msteams /usr/sbin/kamailio[605600]: DEBUG: 
> tls [tls_server.c:550]: tls_connect(): tls_connect: sending socket: 
> 159.65.196.10:0
>
> 2024-04-15T14:53:19.302868+00:00 msteams /usr/sbin/kamailio[605600]: DEBUG: 
> tls [tls_server.c:418]: tls_dump_cert_info(): tls_connect: server certificate 
> subject:/C=US/ST=WA/L=Redmond/O=Microsoft 
> Corporation/CN=sip.pstnhub.microsoft.com
>
> 2024-04-15T14:53:19.302917+00:00 msteams /usr/sbin/kamailio[605600]: DEBUG: 
> tls [tls_server.c:422]: tls_dump_cert_info(): tls_connect: server certificate 
> issuer:/C=US/O=Microsoft Corporation/CN=Microsoft Azure RSA TLS Issuing CA 03
>
> 2024-04-15T14:53:19.470476+00:00 msteams /usr/sbin/kamailio[605606]: DEBUG: 
> tls [tls_server.c:729]: tls_h_tcpconn_close_f(): Closing SSL connection 
> 0x7fd3c77639c8
>
> 2024-04-15T14:53:28.770710+00:00 msteams /usr/sbin/kamailio[605591]: DEBUG: 
> dispatcher [dispatch.c:3617]: ds_options_callback(): OPTIONS-Request was 
> finished with code 408 (to sip:sip.pstnhub.microsoft.com;transport=tls, group 
> 1)
>
>
>
> -Barry
>
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: About the operating environment of Kamailio

[Ovidiu Sas via sr-users]

On a side note.
It doesn't compile by default on raspberry pi 2 (armv7l).
$ make
make -C src/
make[1]: Entering directory '/mnt/data/kamailio/kamailio_master/src'
CC (gcc) [kamailio] main.o
cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU
make[1]: *** [Makefile.rules:100: main.o] Error 1
make[1]: Leaving directory '/mnt/data/kamailio/kamailio_master/src'
make: *** [Makefile:38: default] Error 2

$ uname -a
Linux raspberrypi2 6.6.20+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.20-1+rpt1
(2024-03-07) armv7l GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/12/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian
12.2.0-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-12
--program-prefix=arm-linux-gnueabihf- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libitm --disable-libquadmath
--disable-libquadmath-support --enable-plugin --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions
--with-arch=armv6+fp --with-float=hard --disable-werror
--enable-checking=release --build=arm-linux-gnueabihf
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Raspbian 12.2.0-14+rpi1)


However, on raspberry pi 4 it works flawlessly (aarch64).

$ uname -a
Linux raspberrypi4 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian
1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/12/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-12
--program-prefix=aarch64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libquadmath
--disable-libquadmath-support --enable-plugin --enable-default-pie
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu
--host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)


Regards,
Ovidiu Sas

On Mon, Apr 15, 2024 at 1:22 AM 山本 哲也 via sr-users
 wrote:
>
> Thanks for the reply
>
> The OS is Linux
>
> We are still in the preliminary investigation stage because we do not have 
> the actual machine at hand
>
> And I found that in the "Makefile.defs"
> # arm8 not supported yet from core atomic operations, fallback to arm7
> I found a sentence that said, so I asked
>
>
> -Original Message-
> From: Noriyuki Hayashi via sr-users 
> Sent: Saturday, April 13, 2024 1:05 PM
> To: Kamailio (SER) - Users Mailing List 
> Cc: Noriyuki Hayashi 
> Subject: [SR-Users] Re: About the operating environment of Kamailio
>
> Hello,
>
> I think depends by OS.
> If you use 
> https://dl.rockylinux.org/pub/sig/9/altarch/aarch64/images/RockyLinuxRpi_9-latest.img.xz
> and rpmbuild that shuld work on it.
>
> Regards,
> Hayashi
>
>
> On Fri, 12 Apr 2024 02:39:08 +
> 山本 哲也 via sr-users  wrote:
>
> > Hello
> >
> > Sorry for the elementary question, please tell me
> >
> > Does kamailio work with ARMv8?
>
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
> Telecommunications Association License No. A-18-9191 Government Resell  
> License No. 301039703002
>   WATS CO.,LTD.
>   Kawana Bldg, 5F  Kamata
> Ota-ku Tokyo, 144-0052 JAPAN
>Phone 81-50-5830-5940
>Ext：201 VoiceMailDirect：201*1
>FAX   81-50-5830-5941
> http://wats.gr.jp
>   Mail： wats @ wats.gr.jp
> Please remove the space between @ as double side
>
> Key fingerprint = B53D FF2F BFEA FDA8 1439  38AA 8281 9A3E C9B6 2FC9
>
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
> 

[SR-Users] Re: RFC: uptime metric for xhttp_prom module

[Ovidiu Sas via sr-users]

For now, I pushed the new uptime statistic to follow the naming
convention that was in place:
https://www.kamailio.org/docs/modules/devel/modules/xhttp_prom.html#xhttp_prom.p.xhttp_prom_uptime_stat

We could implement the following naming convention:
# This is the modparam for stats_stats.get_statistics
# kamcmd stats.get_statistics sl:
modparam("xhttp_prom", "stats_stats.get_statistics", "sl:")
# kamcmd stats.get_statistics 1xx_replies
modparam("xhttp_prom", "stats_stats.get_statistics", "1xx_replies")
# This is the modparam for stats_pkg.stats
# kamcmd pkg.stats
modparam("xhttp_prom", "stats_pkg.stats", 1)
# This is the modparam for stats_core.uptime
# kamcmd core.uptime
modparam("xhttp_prom", "stats_core.uptime", 1)

With the above naming convention, the existing code will be re-used
and the behaviour of the module will be unchanged.
Support for a list of custom stats from the stats.get_statistics
command can be implemented in the future.

-ovidiu
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: RFC: uptime metric for xhttp_prom module

[Ovidiu Sas via sr-users]

Hi Ben,

You made me discover that the xhttp_prom_stats modparam doesn't work
the way I thought it would work :)
I was always using all and I didn't check the scenario that you described.
I was under the impression that xhttp_prom_stats is accepting a csv
with all the stats to be collected.
So this calls for a feature request :)
We could call the modparam several times or we could pass a list.

I think it would make sense to keep a specific modparam for each
corresponding RPC command to avoid ambiguities and keep a clean
implementation.
If all is provided for stats, then all the other values should be ignored.
If a group is provided, all explicit statistics that belong to that
group should be ignored.
modparam("xhttp_prom", "stats", "stats.get_statistics sl:")
# this entry should be ignored based on the previous entry
modparam("xhttp_prom", "stats", "stats.get_statistics 1xx_replies")
modparam("xhttp_prom", "stats", "stats.get_statistics core:")
modparam("xhttp_prom", "stats", "pkg.stats")
modparam("xhttp_prom", "stats", "core.uptime")

Based on the above I think it's better (and maybe easier to implement)
to keep a specific modparam for each RPC:
# This is the modparam for stats stats
# kamcmd stats.get_statistics sl:
modparam("xhttp_prom", "stats_stats", "get_statistics sl:")
# kamcmd stats.get_statistics 1xx_replies
modparam("xhttp_prom", "stats_stats", "get_statistics 1xx_replies")
# This is the modparam for pkg stats
# kamcmd pkg.stats
modparam("xhttp_prom", "stats_pkg", "stats")
# This is the modparam for core stats
# kamcmd core.uptime
modparam("xhttp_prom", "stats_core", "uptime")

Moving the RPC module name inside the name of the modapram provides
the first level of internal indexation (inside the xhttp_prom module)
making it easier to implement.
I'm open to suggestions :)
Implementing the logic for dealing with all the statistics provided by
the stats.get_statistics RPC command should not be very complicated,
but it 's not trivial either :)

The xhttp_prom_ prefix was there before and the new
xhttp_prom_pkg_stats modparam was implemented the same way to be
consistent.

The current implementation is described here:
https://www.kamailio.org/docs/modules/devel/modules/xhttp_prom.html


SUMMARY:
We are dealing with two issues here:
 1. Refactoring the modparam names
 2. Implementing support for a given set of statistics provided by the
'stats.get_statistics' RPC command


Regards,
Ovidiu Sas


On Thu, Apr 4, 2024 at 6:12 PM Ben Kaufman  wrote:
>
> Is this a variable named "xhttp_prom_stats", or the modparam key 
> "xhttp_prom_stats"? There's already two separate parameters, right:
>
> - xhttp_prom_stats - corresponds to the rpc stats.get_statistics, thus it's 
> argument corresponds to that RPC call
> - xhttp_prom_pkg_stats - Corresponds to the rpc pkg.stats, takes a Boolean 
> argument
>
>
> A few thoughts:
>
> - The leading 'xhttp_prom_' prefix on the modparam key is unnecessary, since 
> the first argument to modparam is the module itself.  I point this out 
> because if the issue is backwards compatibility, then my recommendation would 
> be to keep 'xhttp_prom_stats' as is, and introduce a param 'stats' that can 
> introduce new syntax in the third parameter.  As an idea, the third parameter 
> could be literally what would be passed to RPC.  Not every possible RPC 
> command would need to be implemented (many wouldn't make sense), but this 
> would keep the syntax predictable:
> modparam("xhttp_prom", "stats", "corex.uptime");  ## Would 
> provide uptime
> modparam("xhttp_prom", "stats", "stats.get_statistics all:")  ## Same 
> result as modparam("xhttp_prom", "xhttp_prom_stats", "all")
> modparam("xhttp_prom", "stats", "pkg.stats"); ## Same 
> result as modparam("xhttp_prom", "xhttp_prom_pkg_stats", "1")
>
> - My current test env is 5.7.3, but it looks like the existing ' 
> xhttp_prom_stats' parameter can only be declared once, thus there's no syntax 
> for selecting multiple specific items.  In other words this configuration 
> doesn't give counters for the sl module and the core module. It only provides 
> the counters from which ever is declared last (core in this case).
>
> modparam("xhttp_prom", "xhttp_prom_stats", "sl:")
> modparam("xhttp_prom", "xhttp_prom_stats", "core:")
>
>
> Rather than chan

[SR-Users] Re: RFC: uptime metric for xhttp_prom module

[Ovidiu Sas via sr-users]

Hello Henning,

I have nothing against using a single variable, except that it is confusing.
It is not backward compatible. If you enable all vars, then all new
stats will be enabled by default.
In the current stable version, the names of the stats vars and stats
groups are inherited from the "stats.get_statistics" RPC command.
That's why we don't have explicit documentation for them in the README
file.
For the new stats we don't have a group and the stats vars have sort
of arbitrary names.

Having dedicated modparams for all these new stats not covered by the
generic ones require a simple and clean implementation along with an
easy way to switch them on and off while keeping backward
compatibility.
If more kamailio admin feel that we should merge them, we could :)

-ovidiu


On Thu, Apr 4, 2024 at 1:45 PM Henning Westerholt  wrote:
>
> Hello Ovidiu,
>
> nothing against it from my side. I would recommend using the existing 
> variable " xhttp_prom_stats" for activating/deactivation. Just think we 
> should not introduce to many single purpose variables, especially for a value 
> which is always available without any dependencies.
>
> Cheers,
>
> Henning
>
> > -Original Message-
> > From: Ovidiu Sas via sr-users 
> > Sent: Donnerstag, 4. April 2024 18:54
> > To: Kamailio (SER) - Users Mailing List 
> > Cc: Ovidiu Sas 
> > Subject: [SR-Users] RFC: uptime metric for xhttp_prom module
> >
> > Hello all,
> >
> > The xhttp_module can export all stats under "stats.get_statistics" RPC
> > command.
> > I was thinking of adding an optional "uptime" stat that will return the 
> > kamailio
> > server uptime (like the "core.uptime" RPC command). This will make it easier
> > to add an uptime panel in grafana.
> > The new stat would be controlled by a module parameter (by default
> > disabled).
> > Something like:
> > modparam("xhttp_prom", "xhttp_prom_uptime_stat" 1) And this will
> > generate something like:
> > kam_uptime 671 1712249054631
> >
> > This can be already implemented in the script using the "prom_gauge_set()"
> > and retrieving the uptime via "jsonrpc_exec()", but it would be nicer and 
> > faster
> > to implement it in the module itself.
> >
> > Comments?
> >
> > -ovidiu
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe
> > send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to the
> > sender!
> > Edit mailing list options or unsubscribe:



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] RFC: uptime metric for xhttp_prom module

[Ovidiu Sas via sr-users]

Hello all,

The xhttp_module can export all stats under "stats.get_statistics" RPC command.
I was thinking of adding an optional "uptime" stat that will return
the kamailio server uptime (like the "core.uptime" RPC command). This
will make it easier to add an uptime panel in grafana.
The new stat would be controlled by a module parameter (by default disabled).
Something like:
modparam("xhttp_prom", "xhttp_prom_uptime_stat" 1)
And this will generate something like:
kam_uptime 671 1712249054631

This can be already implemented in the script using the
"prom_gauge_set()" and retrieving the uptime via "jsonrpc_exec()", but
it would be nicer and faster to implement it in the module itself.

Comments?

-ovidiu
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

It all depends on the hardware, but I noticed that after you pass 3-4k cps
you run into this kind of issues.

- ovidiu

On Sat, Mar 23, 2024 at 22:11 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

>
> > On Mar 23, 2024, at 9:30 PM, Ovidiu Sas  wrote:
> >
> > In the end, we agree with each other and my feeling is that we are
> repeating the same concept.
>
> Yeah, I think that's mostly right.
>
> > In most of my deployments I don’t need to mess with the udp queue size.
> > For high cps traffic, from my experience, it’s a must.
>
> Although I don't deal with very high-CPS deployments (500-1000 CPS) much
> these days, I used to, and my experiences there led me to the diametrically
> opposite conclusion: one should never increase the UDP queue size, and if
> you find yourself doing that, you're doing something wrong, _except_ in the
> occasional burst case we discussed.
>
> You can be absolutely sure that when I first encountered the problem, my
> first impulse was to increase the receive queue as high as it will go,
> then, gradually, to a lesser extent. I ultimately found that the proper
> amount by which to raise it is 0. ;)
>
> -- Alex
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

The OP didn’t provide any additional info. Maybe he’s doing db operations.
Maybe he’s running something else on the server.
The traffic can be generally ok and then the OS is doing something weird or
some other application is doing something weird that can affect kamailio
for a short period of time. Then you have this extremely short bottlenecks
and packets are dropped.

And it all depends on the testing environment: CPU, synch or asynch
logging, etc.

One can stress kamailio on low performing hardware to reach the limit of a
sistem faster and the results can be “misleading” for others that are used
to test on server grade hardware.

In the end, we agree with each other and my feeling is that we are
repeating the same concept.

Checking for dropped packets is always a good idea. How to deal with
dropped packets depends a lot of the context.

In most of my deployments I don’t need to mess with the udp queue size.
For high cps traffic, from my experience, it’s a must.

And of course, going overboard and increasing it too much just makes things
worse.

- ovidiu

On Sat, Mar 23, 2024 at 20:02 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

>
> > On Mar 23, 2024, at 7:29 PM, Ovidiu Sas via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >
> > Because you have dropped packets.
> > The queue it’s empty most of the time and if is full for a few
> milliseconds and that’s the moment when you experience dropped packets.
>
> Totally fair. Just wondering if that's what we're discussing here. OP said
> he's running sipp, and sipp doesn't push out volatile workloads that are
> offset by periods of little to no activity to rapidly drain the queue.
>
> -- Alex
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

Because you have dropped packets.
The queue it’s empty most of the time and if is full for a few milliseconds
and that’s the moment when you experience dropped packets.

On Sat, Mar 23, 2024 at 19:23 Sergiu Pojoga via sr-users <
sr-users@lists.kamailio.org> wrote:

> >  if most of the time the udp queue is empty and dropped packets are
> observed, then the size of the udp queue is too small.
>
> Hmm.. why would you need to increase the queue size if nothing gets queued
> up?
>
> On Sat, Mar 23, 2024 at 6:38 PM Alex Balashov via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
>>
>> > On Mar 23, 2024, at 6:05 PM, Ovidiu Sas  wrote:
>> >
>> > if most of the time the udp queue is empty and dropped packets are
>> observed, then the size of the udp queue is too small.
>>
>> But would that happen with a sipp load test, once the threshold of
>> dropped requests is observed?
>>
>> --
>> Alex Balashov
>> Principal Consultant
>> Evariste Systems LLC
>> Web: https://evaristesys.com
>> Tel: +1-706-510-6800
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

Things could cascade due to retransmission.
It all depends on how much the system is loaded and the type of the traffic
and message handling in kamailio.
Sometimes the system recovers and works ok for a while until the next burst.

-ovidiu

On Sat, Mar 23, 2024 at 18:28 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

>
> > On Mar 23, 2024, at 6:05 PM, Ovidiu Sas  wrote:
> >
> > if most of the time the udp queue is empty and dropped packets are
> observed, then the size of the udp queue is too small.
>
> But would that happen with a sipp load test, once the threshold of dropped
> requests is observed?
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

I’ve had issues with cpp and just to get more throughput I had to increase
the size of the udp queue. It is also true that the cps was ten times
higher.

In the end, is very simple: if most of the time the udp queue is empty and
dropped packets are observed, then the size of the udp queue is too small.
Any other scenario must be handled differently.

-ovidiu

On Sat, Mar 23, 2024 at 17:49 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

>
> > On Mar 23, 2024, at 5:19 PM, Ovidiu Sas  wrote:
> >
> > But the CPU is not the limiting factor.
>
> We can agree on that, at least. :-)
>
> > Back to the funnel analogy: you have a big bottle and you are using a
> small funnel. That will not work well. If you use a bigger funnel with the
> same bottle (the bigger funnel must fit the bottle), than you can handle
> more liquid.
> > If the funnel is too big for the bottle, then you are spilling out and
> this is the scenario that you are referring to.
>
> I'm not sure how far this bottle metaphor works, because water falls into
> the bottle at a constant rate and at a constant acceleration (force of
> gravity), notwithstanding the moderating effect of funnel shape or other
> geometric irregularities.
>
> I think in the real world, we are dealing with a situation where water
> falls into the bottle (through the bottle?) at different speeds, so most
> limits are related to that flow and not to funnel or bottle size.
>
> Or to say it differently: under most typical Kamailio workloads, which are
> I/O-bound, a single Kamailio process (bottle) can handle a certain amount
> of messages per second. You can't really make it handle more messages than
> it does without tweaking the nature of the workload. Assuming the workload
> is held constant, the only way to get more messages through the system is
> to have more worker processes, or bottles if you like, which has its own
> performance implications and limits (locking and CPU contention).
>
> Consequently, there's a certain throughput-maximising amount of bottles
> for a given workload that is neither so low as to under-utilise available
> resources, nor so high as to degrade the overall throughput from fighting
> for CPU, big locks over shared resources, overwhelming I/O dependencies
> (e.g. databases with queries), etc. The main input variable is the number
> of bottles itself.
>
> The size of the funnel isn't really relevant. If there are enough bottles
> and water goes into them at sufficient velocity, bigger funnels won't help.
> If the velocity is not sufficient or there aren't enough bottles, funnels
> of any size will just back up and overflow.
>
> About the only scenario where the funnel matters is the one you pointed
> out previously, where the inflow is highly irregular, is modally moderate,
> and only momentarily bursts to high volumes.
>
> -- Alex
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

But the CPU is not the limiting factor.

Back to the funnel analogy: you have a big bottle and you are using a small
funnel. That will not work well. If you use a bigger funnel with the same
bottle (the bigger funnel must fit the bottle), than you can handle more
liquid.
If the funnel is too big for the bottle, then you are spilling out and this
is the scenario that you are referring to.

-ovidiu

On Sat, Mar 23, 2024 at 17:12 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

> Fair, but when have you found CPU to be the limiting factor in Kamailio's
> throughput? Kamailio's workload isn't really computational / CPU-bound.
> It's closer to something like Node; it's an I/O multiplexer.
>
> > On Mar 23, 2024, at 4:53 PM, Fred Posner  wrote:
> >
> > That could be one scenario. But when I’ve seen there being more than
> enough CPU it has been there’s a more for 2MB worth of traffic and the OS
> is making an issue that is easily solved by letting the system handle more
> traffic.
> >
> > It’s a bottleneck before kamailio.
> >
> > The analogy would be a funnel. At some point, when you’re pouring a lot
> of liquid, you need to use a wider funnel. Ain’t nothing you do after the
> funnel will matter. The funnel is the problem.
> >
> > -- Fred Posner
> > Sent from mobile
> > Phone: +1 (352) 664-3733
> > qxork.com
> >
> >
> >
> >> On Mar 23, 2024, at 4:13 PM, Alex Balashov via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >>
> >> Sure, but if you're blowing through the default, that means you're not
> consistently coping with the load due to some other factors. Does it not
> follow that enlarging the queue will just give you more backlog without
> increasing throughput?
> >>
> >> -- Alex
> >>
> >>> On Mar 23, 2024, at 1:54 PM, Fred Posner  wrote:
> >>>
> >>> The default queue I believe is about 2MB. Not very hard to exceed that
> queue while still having a good amount of CPU/processor available.
> >>>
> >>> -- Fred Posner
> >>> Sent from mobile
> >>> Phone: +1 (352) 664-3733
> >>> qxork.com
> >>>
> >>>
> >>>
> >>>>> On Mar 23, 2024, at 11:47 AM, Alex Balashov via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >>>>
> >>>> 
> >>>>> On Mar 22, 2024, at 10:21 PM, Ovidiu Sas 
> wrote:
> >>>>>
> >>>>> The default udp queue length is not enough for high cps.
> >>>>
> >>>> That's interesting. I'm not necessarily saying you're wrong, but I'd
> be curious to know more about what informs this theory.
> >>>>
> >>>> --
> >>>> Alex Balashov
> >>>> Principal Consultant
> >>>> Evariste Systems LLC
> >>>> Web: https://evaristesys.com
> >>>> Tel: +1-706-510-6800
> >>>>
> >>>> __
> >>>> Kamailio - Users Mailing List - Non Commercial Discussions
> >>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> >>>> Important: keep the mailing list in the recipients, do not reply only
> to the sender!
> >>>> Edit mailing list options or unsubscribe:
> >>
> >> --
> >> Alex Balashov
> >> Principal Consultant
> >> Evariste Systems LLC
> >> Web: https://evaristesys.com
> >> Tel: +1-706-510-6800
> >>
> >> __
> >> Kamailio - Users Mailing List - Non Commercial Discussions
> >> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> >> Important: keep the mailing list in the recipients, do not reply only
> to the sender!
> >> Edit mailing list options or unsubscribe:
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

That will happen only if your CPUs are already maxed out.
Under ideal conditions, the default should work fine. But if you are
dealing with network jitter and several clients pumping traffic at
different rates, for a short period of time all the workers will be busy
while new SIP messages will pile up and the default queue will not be able
to hold all of them.
An increased UDP queue will hold all the SIP messages giving time the
workers to consume them.
The idea is that you have the UDP queue empty all most of the time, and
only when there’s a short temporary traffic burst, it will come to the
rescue.
If the UDP queue of full most of the time, then increasing it obviously
won’t help. The increased UDP queue works only for coping with short
traffic bursts.

-ovidiu

On Sat, Mar 23, 2024 at 16:22 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

> Sure, but if you're blowing through the default, that means you're not
> consistently coping with the load due to some other factors. Does it not
> follow that enlarging the queue will just give you more backlog without
> increasing throughput?
>
> -- Alex
>
> > On Mar 23, 2024, at 1:54 PM, Fred Posner  wrote:
> >
> > The default queue I believe is about 2MB. Not very hard to exceed that
> queue while still having a good amount of CPU/processor available.
> >
> > -- Fred Posner
> > Sent from mobile
> > Phone: +1 (352) 664-3733
> > qxork.com
> >
> >
> >
> >> On Mar 23, 2024, at 11:47 AM, Alex Balashov via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >>
> >> 
> >>> On Mar 22, 2024, at 10:21 PM, Ovidiu Sas 
> wrote:
> >>>
> >>> The default udp queue length is not enough for high cps.
> >>
> >> That's interesting. I'm not necessarily saying you're wrong, but I'd be
> curious to know more about what informs this theory.
> >>
> >> --
> >> Alex Balashov
> >> Principal Consultant
> >> Evariste Systems LLC
> >> Web: https://evaristesys.com
> >> Tel: +1-706-510-6800
> >>
> >> __
> >> Kamailio - Users Mailing List - Non Commercial Discussions
> >> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> >> Important: keep the mailing list in the recipients, do not reply only
> to the sender!
> >> Edit mailing list options or unsubscribe:
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

The OP mentioned that the load is around 10% at 330cps, so load is not an
issue. Traffic bottleneck can be an issue.
The default udp queue length is not enough for high cps.
And of course, you need to keep a balance between all the variables that
affect traffic :)

-ovidiu


On Fri, Mar 22, 2024 at 15:15 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

> I don't know that I would do that. If your server isn't coping with the
> load, making the kernel receive queue deeper doesn't increase throughput,
> it just relocates the queueing -- or rather, adds another layer of
> queueing.
>
> Squeeze the balloon in one place, it inflates in another.
>
> -- Alex
>
> > On Mar 22, 2024, at 1:05 PM, Ovidiu Sas via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >
> > I assume that you are using udp.
> > Please increase the length of the udp queue:
> >
> https://medium.com/@CameronSparr/increase-os-udp-buffers-to-improve-performance-51d167bb1360
> >
> > Regards.
> > Ovidiu Sas
> >
> >
> > On Fri, Mar 22, 2024 at 12:56 Sergio Charrua via sr-users <
> sr-users@lists.kamailio.org> wrote:
> > Hi all!
> >
> > I have been doing some performance tests with Kamailio 5.7.4 and SIPp.
> > The infrastructure is as follows:3 VMs running on VMWare ESXi running:
> > UAC on 10.20.0.1 with SIPP-> Kamailio on 10.20.0.5 -> UAS on 10.20.0.3
> >
> > The Kamailio VM has 6 dedicated vCPU of type Intel(R) Xeon(R) Silver
> 4216 CPU @ 2.10GHz and, 2 NICs and 4Gb RAM and MariaDB 10.6 as DB Backend.,
> all running on a HP G380 host with a gazillion CPUs and a googol disk space!
> >
> > I currently have 3 scripts:
> > - script #1 stateful with RTJson and simulating requests to routing
> engine and accounting
> > - script #2 stateful but with just a simple routing to UAS, no rules, no
> DB,
> > - script #3 stateless with a forward to UAS
> >
> > With script #3 I can go up to 2000CPS without issues with CPU at 37%!
> Above that value, I get retransmissions everywhere.
> > On both scripts #1 and #2, the limit is 330CPS max after which I get a
> lot of retransmissions, while CPU/Core usage on Kamailio server stays below
> 10%.
> > So I do not expect this to be a CPU issue.
> >
> > I could not understand why such (low) results, so I followed this
> article found at
> >  https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c
> > and created exact same scenarios, with kamailio script and SIPP
> templates available on the article, hoping for better results.
> > But I get the same results: between 300 and 330CPS which is far, very
> far from the 7000CPS found in the article!
> >
> > I understand that I'm using VMs and probably the tests made for the
> article, which is pretty old already, were made on physical servers. Still,
> I would not expect 95% of lower performance!
> >
> > Any clue what could be the issue? I suspect NICs, but
> > Any tips anyone could share?
> >
> > Thanks in advance!
> >
> > Sérgio Charrua
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> > Edit mailing list options or unsubscribe:
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> > Edit mailing list options or unsubscribe:
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: low performance with no apparent reason

[Ovidiu Sas via sr-users]

I assume that you are using udp.
Please increase the length of the udp queue:
https://medium.com/@CameronSparr/increase-os-udp-buffers-to-improve-performance-51d167bb1360

Regards.
Ovidiu Sas


On Fri, Mar 22, 2024 at 12:56 Sergio Charrua via sr-users <
sr-users@lists.kamailio.org> wrote:

> Hi all!
>
> I have been doing some performance tests with Kamailio 5.7.4 and SIPp.
> The infrastructure is as follows:3 VMs running on VMWare ESXi running:
> UAC on 10.20.0.1 with SIPP-> Kamailio on 10.20.0.5 -> UAS on 10.20.0.3
>
> The Kamailio VM has 6 dedicated vCPU of type Intel(R) Xeon(R) Silver 4216
> CPU @ 2.10GHz and, 2 NICs and 4Gb RAM and MariaDB 10.6 as DB Backend., all
> running on a HP G380 host with a gazillion CPUs and a googol disk space!
>
> I currently have 3 scripts:
> - script #1 stateful with RTJson and simulating requests to routing engine
> and accounting
> - script #2 stateful but with just a simple routing to UAS, no rules, no
> DB,
> - script #3 stateless with a forward to UAS
>
> With script #3 I can go up to 2000CPS without issues with CPU at 37%!
> Above that value, I get retransmissions everywhere.
> On both scripts #1 and #2, the limit is 330CPS max after which I get a lot
> of retransmissions, while CPU/Core usage on Kamailio server stays below 10%.
> So I do not expect this to be a CPU issue.
>
> I could not understand why such (low) results, so I followed this article
> found at
>  https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c
> <https://www.kamailio.org/docs/openser-performance-tests/#tm-tests-c>
> and created exact same scenarios, with kamailio script and SIPP templates
> available on the article, hoping for better results.
> But I get the same results: between 300 and 330CPS which is far, very far
> from the 7000CPS found in the article!
>
> I understand that I'm using VMs and probably the tests made for the
> article, which is pretty old already, were made on physical servers. Still,
> I would not expect 95% of lower performance!
>
> Any clue what could be the issue? I suspect NICs, but
> Any tips anyone could share?
>
> Thanks in advance!
>
> *Sérgio Charrua*
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: best approach to setup SIP Session sharing between servers

[Ovidiu Sas via sr-users]

That’s a huge marginal gain!
Most of the time is 0.01% or less. :-)

High availability is for hardware failures, not for software failures. If
there’s an issue in one node in the cluster and that node goes down, the
next node in the cluster will have the same issue and it will go down the
same way.

-ovidiu

On Tue, Feb 27, 2024 at 17:04 Alex Balashov via sr-users <
sr-users@lists.kamailio.org> wrote:

> Maybe. It's another one of those things where you might spend 99% of your
> effort for that 0.1% marginal gain...
>
> > On 27 Feb 2024, at 14:58, Social Boh via sr-users <
> sr-users@lists.kamailio.org> wrote:
> >
> > Better use corosync and pacemaker to keeep call audio flow  during
> moving virtual IP using master-slave redis
> > ---
> > I'm SoCIaL, MayBe
> > El 27/02/2024 a las 9:07 a. m., Sergio Charrua via sr-users escribió:
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: SSL key logger for Diffie-Hellman cipher

[Ovidiu Sas via sr-users]

Hello Calvin,

Thank you for sharing this!
This would make for a great tutorial on
https://www.kamailio.org/w/documentation/ under the TLS Tutorials
section or maybe a new tutorial section for Monitoring.
Many would appreciate having this documented there.

-ovidiu

On Mon, Jan 29, 2024 at 8:50 PM Calvin E. via sr-users
 wrote:
>
> It turns out the system I was on really uses 
> /lib/systemd/system/kamailio.service, despite /etc/init.d/kamailio also 
> existing.
>
> I was able to make it work by following the Systemd process:
>
> mkdir /etc/default/kamailio.d/
> edit /etc/default/kamailio.d/voipmonitor
> add lines:
> SSLKEYLOG_UDP='127.0.0.1:1234'
> LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so 
> /usr/lib/x86_64-linux-gnu/libssl.so.3"
>
> The keys are captured by the VoIPmonitor sniffer and everything works as 
> expected from there. I'd be happy to explain further to anyone interested in 
> this setup.
>
> On Sun, Jan 28, 2024 at 3:20 AM Sergey Safarov  wrote:
>>
>> You can check this PR
>> https://github.com/kamailio/kamailio/pull/2785
>>
>> On Fri, Jan 26, 2024 at 8:58 PM Calvin E. via sr-users 
>>  wrote:
>>>
>>> I've been tasked to use LD_PRELOAD to log SSL keys for TLS connections 
>>> using a Diffie-Hellman cipher. The first attempt did not work, so I wanted 
>>> to sanity check whether Kamailio's TLS support is built in such a way that 
>>> would defeat LD_PRELOAD.
>>>
>>> The instructions from the vendor are to update /etc/init.d/kamailio like 
>>> this:
>>>
>>> env SSLKEYLOG_UDP='127.0.0.1:1234' 
>>> LD_PRELOAD="/usr/local/src/voipmonitor-git/tools/ssl_keylogger/sslkeylog.so 
>>> /usr/lib/x86_64-linux-gnu/libssl.so.3" \
>>> start-stop-daemon --start --quiet --pidfile $PIDFILE \
>>> --exec $DAEMON -- $OPTIONS || log_failure_msg " already 
>>> running"
>>>
>>> Is there anything special in Kamailio (5.7.3 on Debian 12) that would 
>>> prevent this from working? Not necessarily something to defeat a keylogger, 
>>> but maybe the way tls.so gets loaded?
>>>
>>> The only discrepancy I've noticed is the vendor docs refer to libssl.so.3 
>>> not libssl.so.1, but the vendor said that should be OK.
>>>
>>> I'd love to hear from someone already using VoIPmonitor with Diffie-Hellman 
>>> ciphers and Kamailio.
>>>
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to 
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Modifying SDP as drop-in replacement for overloaded Asterisk box - looking for help/paid consulting fast

[Ovidiu Sas]

Probably you need to modify only the RURI.
If you looking for a paid consultant you should post to the business
mailing list. Also, you can take a look here:
https://www.kamailio.org/w/business/

-ovidiu

On Thu, Sep 21, 2023 at 21:29 Markus  wrote:

> Hi list,
>
> I'm trying to use Kamailio 4.4.4 with rtpengine in a self-inflicted
> emergency situation (didn't monitor traffic growth properly and now
> encountering packet loss during peak times) as a drop-in replacement for
> an overloaded Asterisk box in a call-termination-to-upstream-carrier
> scenario.
>
> My test scenario is to make a call from a SIP softphone to Asterisk IP
> 1.1.1.1 -> Kamailio/rtpengine IP 2.2.2.2 -> Upstream carrier 3.3.3.3
>
> sngrep on Kamailio box 2.2.2.2 - the following SDP will not work -
> carrier is rejecting it. Carrier is authenticating our calls based on
> our IP address 2.2.2.2, no username/pass involved.
>
> 2023/09/22 02:06:49.216136 2.2.2.2:5060 -> 3.3.3.3:5060
> INVITE sip:+32@2.2.2.2;user=phone SIP/2.0
> Record-Route: 
> Via: SIP/2.0/UDP
> 2.2.2.2;branch=z9hG4bKd9c3.d6fa3abe5d52b827e2054de5573028e0.0
> Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK473270e8
> Max-Forwards: 69
> From: "61x" ;tag=as3d75aadd
> To: 
> Contact: 
> Call-ID: 3f31e1622a72b6d17f24e42362f4f1d0@1.1.1.1:5060
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX 20.0.0
> Date: Fri, 22 Sep 2023 00:06:50 GMT
> Session-Expires: 1800
> Min-SE: 90
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
> INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> P-Asserted-Identity: 
> Content-Type: application/sdp
> Content-Length: 314
> X-SIP: 1.1.1.1
>
> v=0
> o=root 1093000903 1093000903 IN IP4 1.1.1.1
> s=Asterisk PBX 20.0.0
> c=IN IP4 2.2.2.2
> t=0 0
> m=audio 25742 RTP/AVP 8 9 0 101
> a=maxptime:150
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=sendrecv
> a=rtcp:25743
> a=ptime:20
>
> I'm comparing this rejected INVITE to a successful INVITE sent by the
> original Asterisk box at IP 2.2.2.2 (now Kamailio box) to the carrier
> without Kamailio in the path, and these are the differences I noticed,
> and probably the things I have to mimick with Kamailio in order to make
> it work:
>
> INVITE sip:+32x@2.2.2.2;user=phone SIP/2.0
> should be
> INVITE sip:+32x@3.3.3.3;user=phone SIP/2.0
>
> To: 
> should be
> To: 
>
> From: "61x" ;tag=as3d75aadd
> should be
> From: "61x" ;tag=as3d75aadd
>
> Contact: 
> should be
> Contact: 
>
> Call-ID: 3f31e1622a72b6d17f24e42362f4f1d0@1.1.1.1:5060
> should be
> Call-ID: 3f31e1622a72b6d17f24e42362f4f1d0@2.2.2.2:5060
>
> o=root 1093000903 1093000903 IN IP4 1.1.1.1
> should be
> o=root 1093000903 1093000903 IN IP4 2.2.2.2
>
> My kamailio.cfg can be found here: https://pastebin.com/6PKcRjPU
>
> These are the Asterisk boxes I want to originate calls from to Kamailio:
>
> [root@voip30 ~]# kamctl address show
> +-+-+--+--+--+---+
> | id  | grp | ip_addr  | mask | port | tag   |
> +-+-+--+--+--+---+
> | 195 |   1 | 1.1.1.1  |   32 |0 | voip20.sv |
> | 196 |   1 | 1.1.1.2  |   32 |0 | voip21.sv |
> | 197 |   1 | 1.1.1.3  |   32 |0 | voip22.sv |
> | 198 |   1 | 1.1.1.4  |   32 |0 | voip23.sv |
> | 199 |   1 | 1.1.1.5  |   32 |0 | voip24.sv |
> | 200 |   1 | 1.1.1.6  |   32 |0 | voip25.sv |
> | 201 |   1 | 1.1.1.7  |   32 |0 | voip26.sv |
> | 202 |   1 | 1.1.1.8  |   32 |0 | voip27.sv |
> | 203 |   1 | 1.1.1.9  |   32 |0 | voip28.sv |
> +-+-+--+--+--+---+
>
> This is the upstream carrier I want Kamailio to proxy calls to:
>
> [root@voip30 ~]# kamctl dispatcher show
> dispatcher gateways
> ++---+--+---+---++--+
> | id | setid | destination  | flags | prio. | attrs  | desc |
> ++---+--+---+---++--+
> | 12 | 1 | sip:3.3.3.3:5060 | 0 | 0 | weight=100 |  |
> ++---+--+---+---++--+
> (output manually slightly modified to look properly over E-Mail)
>
> As you might have guessed I'm a Kamailio noob... and don't have the
> resources to learn it as fast as I must to avoid further packet loss. If
> there's anyone available who can help me to get this done today,
> optionally in exchange for money, I'd be grateful.
>
> Thank you!
> Markus
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to 

[SR-Users] Re: Saving credentials in yaml/txt format

[Ovidiu Sas]

Take a look at db_text module.

On Sun, Jul 30, 2023 at 03:31  wrote:

> Hello all, I want to save some credentials for different users I have that
> are being used in a digest authorization (INVITE),
> with different realms (I don't want the credentials to be hardcoded).
> I tried to look at how can I read into my kamalio.cfg from yaml/txt file,
> but haven't found the right module for this.
>
> Thanks in advance,
> Max
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Kamailio 5.6.4 and htable dbmode=1

[Ovidiu Sas]

Try to change the ownership of the SQLite file and match it to the user
running kamailio.

On Tue, Jul 18, 2023 at 14:45 Bernd Krüger Knauber  wrote:

> Hi,
>
> it is not a problem of the sqlite file:
>
> sqlite> .schema userpush
> CREATE TABLE userpush (
> key_name TEXT,
> "key_type" INTEGER,
> value_type INTEGER,
> key_value TEXT
> );
> sqlite> insert into userpush ('key_name') values ('test');
> sqlite> select * from userpush;
> test|||
> sqlite>
>
> And the file itself has 666 as rights, so everyone is allowed to write to
> it. (at the moment)
>
>
> --
> *Von: *"Henning Westerholt" 
> *An: *"Kamailio" 
> *CC: *"Bernd Krueger-Knauber" 
> *Gesendet: *Dienstag, 18. Juli 2023 11:30:43
> *Betreff: *RE: [SR-Users] Kamailio 5.6.4 and htable dbmode=1
>
> Hello,
>
>
>
> ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed:
> attempt to write a readonly database
> ERROR: db_sqlite [dbase.c:177]: db_sqlite_cleanup_query(): finalize
> failed: attempt to write a readonly database
> ERROR: htable [ht_db.c:668]: ht_db_delete_records(): failed to delete db
> records in [userpush]
> ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed:
> attempt to write a readonly database
>
> This looks that the error is not on the Kamailio side, but your database
> is somehow not working correctly.
>
>
>
> Have you tried to open the database with the sqlite command line shell and
> execute an INSERT or similar? If it also fails, there must be something
> wrong on the DB side.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Bernd Krueger-Knauber 
> *Sent:* Montag, 17. Juli 2023 12:42
> *To:* sr-users@lists.kamailio.org
> *Subject:* [SR-Users] Kamailio 5.6.4 and htable dbmode=1
>
>
>
> Hi Daniel,
>
> thank you for your response.
> As you can see in the provided debug output:
>
>
> kamailio[]: DEBUG: htable [ht_api.c:1046]: ht_table_spec(): htable
>
> [callpush] - dbmode [1]
>
> kamailio[]: DEBUG: htable [ht_api.c:1027]: ht_table_spec(): htable
>
> [callpush] - dbtable [userpush]
>
> kamailio[]: DEBUG: htable [ht_api.c:1036]: ht_table_spec(): htable
>
> [callpush] - expire [86400]
>
> kamailio[]: DEBUG: htable [ht_api.c:1041]: ht_table_spec(): htable
>
> [callpush] - size [10]
>
>
>
> dbmode is set to 1 in the config:
>
>
>
> modparam("htable", "db_url", "sqlite:etc/kamailio/htable.sqlite")
>
> ...
>
> modparam("htable", "htable", 
> "userpush=>size=3;autoexpire=600;dbtable=userpush;dbmode=1")
>
>
>
>
>
> If I execute
>
> kamcmd htable.store userpush
>
> I get
> Ok. Htable successfully stored to DB.
>
> But the table is still empty!!!
>
> In the log I found:
> ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed:
> attempt to write a readonly database
> ERROR: db_sqlite [dbase.c:177]: db_sqlite_cleanup_query(): finalize
> failed: attempt to write a readonly database
> ERROR: htable [ht_db.c:668]: ht_db_delete_records(): failed to delete db
> records in [userpush]
> ERROR: db_sqlite [dbase.c:528]: db_sqlite_commit(): sqlite commit failed:
> attempt to write a readonly database
>
> Ok.
> But I can not see this entries if I shutdown kamailio.
>
> And:
> -rw-rw-rw-  1 kamailio root 16384 Jul 13 16:14 htable.sqlite
>
>
> I never used:
>
> modparam("db_sqlite","db_set_readonly" ...
>
>
> I also restarted kamailio. no difference.
>
> Now more errors then before:
> It is not written at shutdown. (no messages)
> It is not written (live) (with error messages, but why it is readonly?)
> The message of kamcmd is wrong (says Ok but it failed)
>
> Best regards,
>
> Bernd
>
>
>
> Am 17.07.2023 um 08:48 schrieb Daniel-Constantin Mierla:
>
> Hello,
>
>
>
> is dbmode=1 in htable definition?
>
>
>
> If you run rpc command htable.store for the htable, are the records
>
> saved to database?
>
>
>
> Cheers,
>
> Daniel
>
>
>
> On 13.07.23 17:45, Bernd Krueger-Knauber wrote:
>
> Hi,
>
>
>
> I just tried to use sqlite and htable to load and save the values.
>
> At start I can see in the log, that all parameters are correct and
>
> that htable want to load the values from the table.
>
> No errors.
>
>
>
> But if I stop kamailio, nothing is written to the tables.
>
>
>
> At start I can see:
>
>
>
> kamailio[]: DEBUG:  [core/modparam.c:112]:
>
> set_mod_param_regex(): 'htable' matches module 'htable'
>
> kamailio[]: DEBUG:  [core/sr_module.c:814]: find_param_export():
>
> found  in module htable
>
> [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so]
>
> kamailio[]: DEBUG:  [core/modparam.c:128]:
>
> set_mod_param_regex(): found  in module htable
>
> [/usr/lib/x86_64-linux-gnu/kamailio/modules/htable.so]
>
> kamailio[]: DEBUG: htable [ht_api.c:1046]: ht_table_spec(): htable
>
> [callpush] - dbmode [1]
>
> kamailio[]: DEBUG: htable [ht_api.c:1027]: ht_table_spec(): htable
>
> [callpush] - dbtable [userpush]
>
> kamailio[]: DEBUG: htable 

[SR-Users] Re: Handling stateless replies with kemi

[Ovidiu Sas]

Hello Henning,

Everything is working ok.
I guess the docs should be more clear (I was expecting some dedicated route).
I will try to update the docs.

Thanks,
Ovidiu

On Thu, Mar 30, 2023 at 3:30 AM Henning Westerholt  wrote:
>
> Hello,
>
> have you tried to just define a onreply_route:
>
> // Manage incoming replies
> // equivalent of onreply_route[...]{}
> function ksr_onreply_manage()
> {
> KSR.dbg("incoming reply\n");
> var scode = KSR.kx.gets_status();
> if (scode>100 && scode<=299) {
> ksr_route_natmanage();
> }
> return;
> }
>
> And then register this with the tm module function, as indicated in the docs?
> https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.p.on_sl_reply
>
> Cheers,
>
> Henning
>
> -Original Message-
> From: Ovidiu Sas 
> Sent: Montag, 27. März 2023 22:04
> To: Kamailio (SER) - Users Mailing List 
> Subject: [SR-Users] Handling stateless replies with kemi
>
> Hello all,
>
> How can we handle stateless replies with kemi?
> tm has the following param:
> modparam("tm", "on_sl_reply", "stateless_replies")
>
> What's the proper way to map the "stateless_reply" onreply_route to a kemi 
> function.
> I'm playing with the app_jsdt module.
>
> Thanks,
> Ovidiu
> __
> Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe 
> send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: KEMI: app_jsdt_run_ex(): js loading state not initialized (call: ksr_htable_event)

[Ovidiu Sas]

So is this the normal behaviour for 5.6?
If yes, we need to document it somewhere. Other modules might be impacted.

-ovidiu

On Mon, Mar 27, 2023 at 6:57 AM Daniel-Constantin Mierla
 wrote:
>
> Hello,
>
> it could be due to commit 3c1851ad546f574d1fda869348c8f7e5186079d2,
> which was done to avoid sharing the interpreter state before forking the
> child processes.
>
> Cheers,
> Daniel
>
> On 25.03.23 23:15, Ovidiu Sas wrote:
> > Hello all,
> >
> > While using KEMI with app_jsdt I noticed the following possible
> > regression between 5.5 and 5.6.
> >
> > The following config is working ok on 5.5 but throws an error on 5.6:
> > ERROR: app_jsdt [app_jsdt_api.c:555]: app_jsdt_run_ex(): js loading
> > state not initialized (call: ksr_htable_event)
> >
> > kamailio.cfg:
> > debug=2
> > children=1
> >
> > log_facility=LOG_LOCAL0
> > log_name="k"
> >
> > mpath="/home/osas/src/kamailio/src/modules"
> > loadmodule "htable/htable.so"
> >   modparam("htable", "event_callback", "ksr_htable_event")
> >   modparam("htable", "event_callback_mode", 1)
> > loadmodule "kemix/kemix.so"
> > loadmodule "app_jsdt/app_jsdt.so"
> >   modparam("app_jsdt", "load", "/usr/local/etc/kamailio/kamailio.js")
> > cfgengine "jsdt"
> >
> > kamailio.js:
> > function ksr_htable_event(evname) {
> > KSR.info("ksr_htable_event(" + evname + ")\n");
> > }
> >
> > function ksr_request_route() {
> > KSR.x.exit();
> > }
> >
> > If we load the htable module after app_jsdt, then the error is gone.
> > Is there something new during init in 5.6 that requires specific
> > module loading order?
> >
> > -ovidiu
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not reply only to 
> > the sender!
> > Edit mailing list options or unsubscribe:
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
> Kamailio Advanced Training - Online - March 27-30, 2023 - www.asipto.com
>


-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Handling stateless replies with kemi

[Ovidiu Sas]

Hello all,

How can we handle stateless replies with kemi?
tm has the following param:
modparam("tm", "on_sl_reply", "stateless_replies")

What's the proper way to map the "stateless_reply" onreply_route to a
kemi function.
I'm playing with the app_jsdt module.

Thanks,
Ovidiu
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] KEMI: app_jsdt_run_ex(): js loading state not initialized (call: ksr_htable_event)

[Ovidiu Sas]

Hello all,

While using KEMI with app_jsdt I noticed the following possible
regression between 5.5 and 5.6.

The following config is working ok on 5.5 but throws an error on 5.6:
ERROR: app_jsdt [app_jsdt_api.c:555]: app_jsdt_run_ex(): js loading
state not initialized (call: ksr_htable_event)

kamailio.cfg:
debug=2
children=1

log_facility=LOG_LOCAL0
log_name="k"

mpath="/home/osas/src/kamailio/src/modules"
loadmodule "htable/htable.so"
  modparam("htable", "event_callback", "ksr_htable_event")
  modparam("htable", "event_callback_mode", 1)
loadmodule "kemix/kemix.so"
loadmodule "app_jsdt/app_jsdt.so"
  modparam("app_jsdt", "load", "/usr/local/etc/kamailio/kamailio.js")
cfgengine "jsdt"

kamailio.js:
function ksr_htable_event(evname) {
KSR.info("ksr_htable_event(" + evname + ")\n");
}

function ksr_request_route() {
KSR.x.exit();
}

If we load the htable module after app_jsdt, then the error is gone.
Is there something new during init in 5.6 that requires specific
module loading order?

-ovidiu
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: Issues matching regex

[Ovidiu Sas]

This will do it:
if ($rU=~"^(\+?1)?(8(00|44|55|66|77|88))[2-9][0-9][0-9][0-9][0-9][0-9][0-9]$") {
xlog("L_INFO", "Tollfree call: $rU");
}

-ovidiu

On Sat, Feb 11, 2023 at 12:37 PM Nathan Stratton  wrote:
>
> I am having an issue matching toll-free. I tested my regex on regex101.com, 
> and it looks good, but it does not match my if statement. Am I doing 
> something wrong?
>
> if (method=="INVITE") {
> xlog("L_INFO", "Checking Routes $rU");
> if ($rU=~"^(\+?1)?(8(00|44|55|66|77|88)[2-9]\d{6})$") {
> xlog("L_INFO", "Tollfree call");
> };
> };
>
> Logs show 

[SR-Users] no autocomplete for kamcmd for latest debian packages

[Ovidiu Sas]

Hello,

The latest debian packages are built without autocomplete for kamcmd.
Do we have the libreadline-dev package installed on the build machine?
I know that we have kamctl rpc  and kamcli, but if we are still
shipping kamcmd, it should have the autocomplete feature enabled.

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: rtpengine - SRTP <> RTP

[Ovidiu Sas]

Here's a quick guide on how to capture and decrypt encrypted traffic:
https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encrypted-sip-traffic/

-ovidiu

On Thu, Jan 26, 2023 at 9:46 AM Krzysztof Drewicz
 wrote:
>
> śr., 25 sty 2023 o 19:22 Karsten Horsmann  napisał(a):
> >
> > Hi,
> >
> > If you want the signaling that is encrypted see in plaintext you can use 
> > Kamailio module siptrace.
>
> Is siptrace only for working with homer? I just need a plaintext dump
> to a file or something like that.
>
> > sipdump and sipcapture maybe also good for that, I didn't use these.
>
> should look into this.
>
> Thanks
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

[SR-Users] Re: How to make a branch trigger persistent (still being active after failure route is triggered)?

[Ovidiu Sas]

Hello Benoît,

Whatever you modify on a branch, is local to the branch.
The idea is that for parallel forking one might want to send out the
INVITE in different formats.
When the call fails, in the failure route you work on the original
INVITE and you can reformat the outgoing INVITE (it's like a fresh
start).

Regards,
Ovidiu Sas

On Fri, Dec 16, 2022 at 4:11 PM Benoît Panizzon  wrote:
>
> Hi List
>
> Some time ago, during my learning curve with kamailio, I learned that a
> branch route is where you make modifications to callerId's.
>
> So I extensively re-engineered the config to move as much as possible
> of callerid modification into branch routes.
>
> But now I discovered, when a call is dispatched via dispatch group with
> multiple destinations and one destination fails, therefore the failure
> route is triggered, the branch route is not being called on the second
> attempt, thus callerid being in the wrong format.
>
> Example:
>
> dispatcher.lst
>
> As an example, consider having dispatcher group 2001 for national traffic 
> over two
> dedicated links and Dispatcher group 2002 for international traffic.
>
> 2001 sip:192.168.1.1:5060 0 0 name="Carrier1"
> 2001 sip:192.168.2.1:5060 0 0 name="Carrier1"
>
> 2002 sip:192.168.1.3:5060 0 0 name="Carrier2"
>
> request_route
> {
> # We determine where we want to send the call
> # and choose dispatch group 2001, the 'national' one.
> # But there are are other dispatch groups and branch triggers
> # set this way and routed to DISPATCHCALL
> $avp(dispgroup) = 2001;
> t_on_branch("BR_TO_NATIONAL");
> route(DISPATCHCALL);
> }
>
> route[DISPATCHCALL]
> {
> t_set_fr(12,1500); # Fast Failover
> t_set_max_lifetime(30,0);
> t_set_retr(200,800);
> if (ds_select_dst("$avp(dispgroup)", "6")) {
> if (ds_is_from_list(-1,0,"$du")) {
> t_on_failure("DISPATCH_FAILURE");
> route(RELAY);
> }
> }
> }
>
> branch_route[BR_TO_NATIONAL]
> {
> # Here I make sure, all CallerId and Header are correct for the
> # national Carrier
> }
>
> failure_route[DISPATCH_FAILURE]
> {
> if (t_check_status("(5[0-9][0-9])") or (t_branch_timeout() and 
> !t_branch_replied())) {
> # Try next DS.
> if (ds_next_dst()) {
> xlog("L_INFO", " --> retargeting request\n");
> t_on_failure("DISPATCH_FAILURE");
> route(RELAY);  RIGHT HERE!
> exit;
> }
> }
> # We fail
> xlog("L_ERROR", "Call Failed\n");
> }
>
> My issue is not, that if the call is routed after the first path failed
> (marked with  RIGHT HERE!) then the appropriate branch route is not
> triggered again and the headers are wrong. But I can not set t_on_branch
> within route[DISPATCHCALL] or route[DISPATCH_FAILURE] because this is
> called with a different pre-set branch trigger, depending on the target
> dispatch group.
>
> Is there a way to make a branch trigger more persistent?
>
> --
> Mit freundlichen Grüssen
>
> -Benoît Panizzon- @ HomeOffice und normal erreichbar
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Re: [SR-Users] Logs suddenly inundated with qm_malloc errors

[Ovidiu Sas]

Maybe there is a memory leak or maybe the system is not provisioned
with enough memory to cope with the traffic. Increase the amount of
allocated memory and monitor it, see how it evolves over time.

Regards,
Ovidiu Sas

On Tue, Dec 13, 2022 at 6:14 AM George Diamantopoulos
 wrote:
>
> Hello all,
>
> I'm testing out release 5.6.2 on one production kamailio instance, and today 
> our monitoring system triggered an alarm for lack of disk space on /. Indeed, 
> kamailio.log started growing at an alarming rate at some point.
>
> At about the same time disk space started being depleted, the following line 
> was frequently logged in the logs (no instances of it before that time):
>
> qm_malloc(): qm_malloc(0x7f5ade9c0010, 536) called from rtpengine: bencode.c: 
> __bencode_piece_new(79), module: rtpengine; Free fragment not found!
>
> They don't only concern rtpengine, core has produced similar "free fragment 
> not found" errors as well. There's additional multiple "had header field", 
> "bad header" and "invalid header name" errors appearing after that too, but 
> I'm guessing that's only a symptom of the qm_malloc issue?
>
> kamailio is started with -m 2048 -M 16 and there's another instance with 
> almost identical traffic and configuration, but running on 5.6.1, which has 
> never exhibited such failures in several months uptime. So I'm wondering, is 
> there anything in 5.6.2 that could explain this? Thanks!
>
> Best regards,
> George
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@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

Re: [SR-Users] Log levels severely impacts performance

[Ovidiu Sas]

Then rework the logs.
Do you have more than one log per registration? If yes, use only one.
If you already have a single log per registration, then try reducing the
size.
Experiment to see where the system breaks. Try new hardware. Decrease the
number of workers to see if it has an impact.

-ovidiu

On Thu, Sep 15, 2022 at 11:30 Amit  wrote:

> Hi Henning,
>
> No we are using a local graylog server, not cloud.
>
> I suppose if the bottleneck is log generation, it doesn’t matter how or
> where they are handled/sent.
>
> Amit
>
>
>
> *From: *Henning Westerholt 
> *Date: *Thursday, September 15, 2022 at 9:53 AM
> *To: *Amit 
> *Cc: *Kamailio (SER) - Users Mailing List 
> *Subject: *RE: [SR-Users] Log levels severely impacts performance
>
> Hello Amit,
>
>
>
> this sounds strange. If you send them remotely it should not really affect
> the operation anymore.
>
> Maybe it’s a special limitation of the cloud server, if you use a public
> cloud service provider, but just guessing here.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Amit 
> *Sent:* Thursday, September 15, 2022 3:16 PM
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Log levels severely impacts performance
>
>
>
> Hi Henning,
>
>
>
> We are actually sending the logs directly to our local graylog server via
> the $programname property in rsyslog, and we’ve disabled writing Kamailio
> logs to disk (i.e. only in memory by setting Storage=volatile in
> rsyslog.conf) but that didn’t seem to help with the application socket
> receive buffer backlog.
>
>
>
> Keep in mind that for testing purposes, I am blasting Kamailio with a
> fixed 2000 simultaneous registrations, so at log level 2 it really
> struggles and the socket buffer quickly fills up. Reducing the log level to
> 1 allows Kamailio to rip through the requests and the buffer stays at 0.
>
>
>
> 
>
> Amit Nir, MBA
>
> Office: 305.999.0911
>
> www.BryteCall.com
>
>
>
>
>
> *From: *Henning Westerholt 
> *Date: *Thursday, September 15, 2022 at 9:01 AM
> *To: *Amit 
> *Cc: *Kamailio (SER) - Users Mailing List 
> *Subject: *RE: [SR-Users] Log levels severely impacts performance
>
> Hello,
>
>
>
> how much are you actually logging? As already suggested, maybe just need
> to decrease the amount of log messages.
>
>
>
> If you need this much logging, you can of course forward it to a dedicated
> log server over the network.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* Amit 
> *Sent:* Thursday, September 15, 2022 1:33 PM
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Log levels severely impacts performance
>
>
>
> Hi Henning,
>
> Thanks for the suggestion.
>
> Disk I/O was our initial assumption on another Kamilio instance we are
> running.
>
> To test this theory we installed Kamailio on separate hardware and
> configurations with faster underlying SSD disks, however we are seeing the
> same crippled performance and congestion in the applications socket receive
> buffer when LOG level is set to INFO (2).
>
>
>
> 
>
> Amit Nir, MBA
>
> Office: 305.999.0911
>
> www.BryteCall.com
>
>
>
>
> On Sep 15, 2022, at 6:14 AM, Henning Westerholt  wrote:
>
> 
>
> Hello,
>
>
>
> additionally, try to see if you have some general I/O issues, e.g., by
> observing io-wait CPU, looking to I/O transaction times with monitoring
> tools etc..
>
> Maybe there are other services also causing excessive I/O.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* sr-users  *On Behalf Of 
> *Daniel-Constantin
> Mierla
> *Sent:* Wednesday, September 14, 2022 2:25 PM
> *To:* Kamailio (SER) - Users Mailing List ;
> Amit 
> *Subject:* Re: [SR-Users] Log levels severely impacts performance
>
>
>
> Hello,
>
> excessive logging is known to impact the performances. If you have many
> log messages printed from config, try to reduce them.
>
> Performance could be also a matter of how many child processes you
> created, via the children global parameter.
>
> Cheers,
> Daniel
>
> On 14.09.22 04:18, Amit wrote:
>
> Hello,
>
>
>
> We’ve been running Kamailio 5.5.0 for a while now and recently ran into an
> issue where the application buffer would get full and Kamailio has a lot of
> difficulty keeping up with REG requests. This severely impacted Kamailio’s
> ability to perform and resulted in many REG timeouts.
>
>
>
> Running ‘watch netstat -ulpn’ revealed the buffer issue.
>
>
>
> We usually run the production system at log level INFO (2) and had not ran
> into any issues in the past.
>
>
>
> When the buffer issue occurred and after some testing, we discovered that
> changing the log level to 

Re: [SR-Users] Limit cps per destination gw

[Ovidiu Sas]

I had a similar setup, with an empty dbtext table. Works like a charm!

-ovidiu

On Thu, Jul 28, 2022 at 21:20 Jon Bonilla (Manwe)  wrote:

> El Thu, 28 Jul 2022 18:08:33 +
> Henning Westerholt  escribió:
>
> > Hi,
> >
> > pipelimit allows dynamic queues from a DB. But if you want to limit
> > concurrent calls, the best option is probably using dialog profiles with
> the
> > dialog modules. For a cps limit you could also just use htable.
> >
> > Cheers,
> >
>
> Hi Henning
>
> No, concurrent calls is not the issue. CAPS is.
>
> pipelimit seems promising. Don't like the db backend requirement. I guess
> I can
> use dbtext, leave it blank and create pipes on demand with pl_check and
> read
> the limit from a custom header. This system doesn't have db backend as
> it's a
> loadbalancer for multiple kamailio servers and needs to be fast as hell.
>
>
> thank you
>
> Jon
>
>
> --
> PekePBX, the multitenant PBX solution
> https://pekepbx.com
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] SNMP, export concurrent calls count

[Ovidiu Sas]

Take a look at the xhttp_prom module. You will need to upgrade.

-ovidiu

On Mon, May 30, 2022 at 13:37 ZZ Wave  wrote:

> Hello.
>
> Debian 10, Kamailio 5.2.1
>
> I want to monitor concurrent calls in/out per every trunk connected to
> this proxy (it's done with dialog profiles), and export this to Zabbix. But
> I can't find in snmpstats documentation how to export user-defined
> variables. Help me please. Maybe SNMP isn't the best solution for that...
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Using DNS log in

[Ovidiu Sas]

Hello Steve,

Take a look at the alias keyword:
https://www.kamailio.org/wiki/cookbooks/devel/core#alias
Set your domain as an alias and it should work.

-ovidiu

On Fri, Mar 25, 2022 at 18:21 Steve  wrote:

> Hello,
>
> I have a very basic Kamailio 5.4 configuration on Debian 11 with
> RTPProxy 2.2 behind a firewall. It works fine with the sip client
> logging into the server public ip address. However, the sip client is
> not able to log in when using a dns domain name directed to that public
> ip address. Is there a specific setting in the Kamailio and/or RTPProxy
> config files for using a dns domain name instead of a numeric ip address?
>
> Also, is there a Kamailio module that allows use of encrypted keys
> instead of passwords when logging in?
>
> Thanks for any info,
>
> Steve
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] $ru vs. $fu as r/w pseudo variables

[Ovidiu Sas]

Thank you!

-ovidiu

On Tue, Mar 22, 2022 at 12:22 PM Juha Heinanen  wrote:
>
> Juha Heinanen writes:
>
> > I looked at pv_core.c, and based on that these are header R/W variables:
> >
> > $tu, $tU, $td, $tn, $fu, $fU, $fd, $fn
>
> I updated the Wiki page accordingly.
>
> -- Juha
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] $ru vs. $fu as r/w pseudo variables

[Ovidiu Sas]

Should be the same for To header.

On Tue, Mar 22, 2022 at 10:02 Juha Heinanen  wrote:

> Perhaps it would best to explicitly tell on Pseudo-Variables Wiki page,
> which R/W pseudo "variables" are not really variables in the sense that
> setting of the value does not change its value.
>
> Are there others than these three: $fd, $fu, $fU.  If not, I can add a
> note to their entries.
>
> -- Juha
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] $ru vs. $fu as r/w pseudo variables

[Ovidiu Sas]

Hello Juha,

The first line of a SIP request is parsed and kept separately from the
rest of the SIP message. Because of this, it is easy to apply instant
changes to it.
This is what I remember checking the code long time ago, it might not
be 100% accurate.

Hope this helps,
-ovidiu

On Mon, Mar 21, 2022 at 7:15 AM Juha Heinanen  wrote:
>
> Daniel-Constantin Mierla writes:
>
> > Operations to change the headers and body are not applied immediately:
> >
> >   *
> > https://www.kamailio.org/wiki/tutorials/faq/main#why_changes_made_to_headers_or
>
> OK, got it.  What makes $ru special, i.e., why that is applied
> immediately?
>
> -- Juha
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] typo in documentation

[Ovidiu Sas]

Hello David,

Example config updated!
Thank you for reporting it.

-ovidiu

On Tue, Mar 15, 2022 at 8:59 AM David Villasmil
 wrote:
>
> Hello all,
>
> I was trying to implement db_text and the documentation states it should be 
> something like
>
> modparam("usrloc|auth_db", "db_url", "db_text:///tmp/kamailiodb")
>
>
> but that doesn't work, it's
>
> modparam("usrloc|auth_db", "db_url", "text:///tmp/kamailiodb")
>
>
> so this line should probably be updated:
>
> https://github.com/kamailio/kamailio/blob/master/src/modules/db_text/doc/db_text.cfg#L44
>
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] kamailio.cfg : behind the NAT (listen and advertise) understanding

[Ovidiu Sas]

As long as traffic to IPv4_public : 5060 lands on IPv4_private: 5060, yes,
you can use this double NAT setup.

-ovidiu

On Sat, Mar 5, 2022 at 08:35 Youssef Boujraf  wrote:

> Question :
>
> If kamailio is behind a double NAT setup
>
> Internet - (Model-router : NAT 1) - (router - NAT2) - kamailio
>
> Could I use this settings ?
>
> - For public softphone :
>
> listen=udp: IPv4_private: 5060 advertise  IPv4_public : 5060
>
> Domain :  IPv4_public:5060
>
> - For private softphone on same vlan as kamailio
>
> listen=udp: IPv4_private:5066
>
> Domain :  IPv4_private:5066
>
> Best Regards,
>
> Youssef BOUJRAF
> Email: ybouj...@gmail.com
>
>
> On Sat, Mar 5, 2022 at 1:23 AM Youssef Boujraf  wrote:
>
>> Dear,
>>
>> Then;
>>
>> - For public softphone :
>>
>> listen=udp: IPv4_private: 5060 advertise  IPv4_public : 5060
>>
>> Domain :  IPv4_public:5060
>>
>> - For private softphone on same vlan as kamailio
>>
>> listen=udp: IPv4_private:5066
>>
>> Domain :  IPv4_private:5066
>>
>>
>>
>> Best Regards,
>>
>> Youssef BOUJRAF
>> Email: ybouj...@gmail.com
>>
>>
>> On Fri, Mar 4, 2022 at 3:00 PM Youssef Boujraf 
>> wrote:
>>
>>> Hi Dear
>>>
>>> I am trying to understand how "listen" and "advertise" work for sip
>>> signaling purpose ( corebooks : listen
>>>  and
>>> advertise )
>>>
>>> Flow : kamailio behind NAT using softphones on private and public
>>> networks.
>>>
>>> - kamailio :
>>>
>>> Network :
>>>
>>> IPv4_private 192.168.1.6 / IPv4_public
>>>
>>> kamailio.cfg :
>>>
>>> listen=udp: IPv4_private: 5060 advertise  IPv4_public : 5060
>>>
>>> - uac (softphone) :
>>>
>>> zoiper, microsip, cisco spa508g
>>>
>>> USE CASE :
>>>
>>> I 'd like to force all softphone on the same local network to reach
>>> kamailio through a public ip address.
>>>
>>> ??? QUESTION : Do I need to REGISTER on IPv4_private address of Kamailio
>>> OR REGISTER on IPv4_public address of kamailio or DEFINE another "listen"
>>> with another PORT WITHOUT "advertise"  for softphone on same kamailio
>>> network ?
>>>
>>> listen=udp: IPv4_private: 5060 advertise  IPv4_public : 5060
>>> listen=udp: IPv4_private: 5066
>>>
>>>
>>> Do I need to use "kamctl ps" to verify which interface is listening on
>>> port ?
>>>
>>> Thanks in advance
>>>
>>> Best Regards,
>>>
>>> Youssef BOUJRAF
>>> Email: ybouj...@gmail.com
>>>
>> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] rtpengine - SRTP <> RTP missing a=crypto

[Ovidiu Sas]

Are you sure that you have multiple branches?
You mentioned that you have kamailio in between asterisk and MS. In
this case, usually this is a simple call with one branch.
You have multiple branches if you fork the call (parallel forking:
sending to multiple destinations when the initial invite is received
or serial forking: re-routing the call to a new destination when
negative replies are received).

-ovidiu


On Thu, Mar 3, 2022 at 8:50 AM Rhys Hanrahan  wrote:
>
> Hi Richard,
>
>
>
> Yes, from what I’ve seen in the logs there are multiple branches happening. 
> One between Teams and Kamailio and one between Kamailio and Asterisk.
>
>
>
> In terms of the rtpengine processing, I’ve tried lots of different 
> variations, but right now I’ve got:
>
> Rtpengine_manage() by itself for new branches and replies (MANAGE_BRANCH, 
> MANAGE_REPLY)
> Rtpengine_manage(“RTP/AVP”) or rtpengine_manage(“RTP/SAVP”) essentially in 
> request_route for the initial invites to/from Teams
> I do also have the stock NATMANAGE using rtpengine but there’s no NAT 
> involved here so I don’t think it applies.
>
>
>
> So as far as I can tell, I shouldn’t be calling rtpengine_manage multiple 
> times. Is this bad to do? I did have previous configs where I was doing this. 
> E.g. during RELAY I would call it with general options and then just modify 
> AVP or SAVP in another section.
>
>
>
> Interestingly, I noticed that a new branch is created just as I answer the 
> call, and this is when it fails, so perhaps the issue is with how I’m 
> handling new branches then? Below is a bit of a log to try and summarise 
> what’s happening. Unfortunately it’s not logging the MS Teams side of the 
> call except for the initial invite.
>
>
>
> I will work on getting you a sip dump as it’s probably the easiest way to 
> properly see what’s going on. Thanks!
>
>
>
> root@sbc5-syd-01:/etc/kamailio# tail -f /var/log/syslog | grep RTPEngine
>
> Mar  4 00:39:38 sbc5-syd-01 kamailio[9240]: 44(9311) ERROR: {1 1 INVITE 
> 5b76dfb297c455358bb0ec0dac3c1af7} 

Re: [SR-Users] Fwd: CDR preserve original call direction

[Ovidiu Sas]

Check the documentation and adjust your config accordingly:
http://www.kamailio.net/docs/modules/5.3.x/modules/acc.html#acc.p.detect_direction

modparam("acc", "detect_direction", 1)

In your config is set to 0.

Regards,
Ovidiu Sas

On Wed, Feb 9, 2022 at 08:01 Ahmed Fouad  wrote:

>
> Hi,
>
> I've enabled ACC and CDR logging and it's working fine for the logging but
> I noticed something wrong in the CDR table , the call source and
> destinations are depending on the BYE message not the initial invite dialog
>
> ACC table
>
> +-++--+-+---+---+--+--+--+
> | id  | method | callid   | time
>  | src_ip| src_domain| src_user | dst_ouser
>  | dst_domain   |
>
> +-++--+-+---+---+--+--+--+
> | 216 | BYE| 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
> 06:57:51 | x.x.x.x  | domain.com   |  DST_CLID |  SRC_CLID |
> domain.com  |
> | 215 | INVITE | 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
> 06:55:17 | x.x.x.x  | domain.com  | SRC_CLID   | DST_CLID |
> dst_domain.com|
>
> The INVITE is the correct one with SRCIP x.x.x.x and domain.com but the
> BYE reversed the order since the the DST_CLID who sent the BYE so it's now
> logged as the source
>
> and the final CDR log looks like
>
>
> ++--+---+--+--+-+-+--+-+---++---+-+
> | cdr_id | src_username | src_domain| dst_username |
> dst_domain   | call_start_time | call_end_time
>
>
> ++--+---+--+--+-+-+--+-+---++---+-+
> |195 |  DST_CLID | domain.com   |  SRC_CLID | domain.com
>  | 2022-02-09 06:55:12 | 2022-02-09 06:57:51 |
>
> the CDR as shown is reversed regarding the source/dst username
>
> I tried to enable the direction ACC direction flag but didn't help and
> here is my current paramters
>
> modparam("acc", "early_media", 0)
> modparam("acc", "report_ack", 0)
> modparam("acc", "report_cancels", 0)
> modparam("acc", "detect_direction", 0)
> modparam("acc", "log_flag", FLT_ACC)
> modparam("acc", "log_missed_flag", FLT_ACCMISSED)
> modparam("acc", "cdr_enable", 1)
> modparam("acc", "cdrs_table", "cdrs")
>
> Can you please advise how to configure ACC/CDR to log the CDR with the
> correct initial INVITE call flow regardless of the BYE direction ?
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] kamailio log dialog correlation

[Ovidiu Sas]

Hello Chad,

See inline.

On Mon, Jan 24, 2022 at 12:18 PM Chad  wrote:
>
> Are you running 5.5?
Yes.

> Do you have log_prefix_mode=1
> If set to 1, then the log prefix is evaluated before/after each config action 
> (needs to be set when the log_prefix has
> variables that are different based on the context of config execution, e.g., 
> $cfg(line)).
The $ci is evaluated only once for each received request/reply.
There's no need to re-evaluate for each route.
There are special cases when re-evaluation is necessary: when changing
the message and changes are forced to be applied inside the script or
when async operations are performed and variables inside the prefix
can change. None of these applies to your deployment.

> BTW "grep cfgutils /etc/kamailio/kamailio.cfg" may not be good enough, 
> because the loadmodule "cfgutils.so" might be
> inside of an if statement.
> You also need to make sure it is actually loaded above the log_prefix line 
> where you use it.
I'm not sure I follow you here. The modules are loaded before the
script is evaluated.

> I don't know how to show the loaded modules, probably some kamcli command 
> will show you, did you search the internet for
> the answer to that?
I don't need to search, I know the answer :)
Here's the command: kamctl rpc core.modules


I'm not trying to push anything on you. If you don't feel comfortable
running logs in "verbose" mode and prefer to reproduce and
troubleshoot issues after business hours, that's totally fine.

-ovidiu

> -
> ^C
>
>
> On 1/24/22 7:41 AM, marek wrote:
> >
> > [root@sbc~]# grep cfgutils /etc/kamailio/kamailio.cfg
> > loadmodule "cfgutils.so"
> >
> > is there a way how can i check if module is loaded without errors? 
> > (something like Asterisk's "module show like")
> >
> > kamailio 5.5.3
> >
> > Marek
> >
> >
> > Dne 22/01/2022 v 17:27 Chad napsal(a):
> >> loadmodule "cfgutils.so"
> >>
> >>
> >> --
> >> ^C
> >>
> >>
> >> On 1/22/22 2:36 AM, marek wrote:
> >>> thanks
> >>>
> >>> now i understand difference between log_prefix and modparam("xlog", 
> >>> "prefix", "something")
> >>>
> >>> so i'm trying this
> >>>
> >>> log_prefix="{D$dlg(h_id) $cfg(route)}"
> >>>
> >>> but i got this
> >>>
> >>> ERROR:  [core/pvapi.c:924]: pv_parse_spec2(): error searching pvar 
> >>> "cfg"
> >>> ERROR:  [core/pvapi.c:1127]: pv_parse_spec2(): wrong char [r/114] 
> >>> in [$cfg(route)] at [5 (5)]
> >>> ERROR:  [core/dprint.c:463]: log_prefix_init(): wrong 
> >>> format[{D$dlg(h_id) $cfg(route)}]
> >>>
> >>> it's the same if its used in
> >>>
> >>> xlog("L_INFO", "D$dlg(h_id) $cfg(route) some log")
> >>>
> >>> do you think there is a module missing?
> >>>
> >>> Marek
> >>>
> >>>
> >>> Dne 19/01/2022 v 16:23 Henning Westerholt napsal(a):
>  Hello,
> 
>  you could try to use log_prefix. Have not tried it yet with a dialog 
>  variable.
> 
>  http://www.kamailio.org/wiki/cookbooks/5.5.x/core#log_prefix
> 
>  Regarding output of a line number, you could try to use this one:
> 
>  http://www.kamailio.org/wiki/cookbooks/5.4.x/pseudovariables#cfg_key_-_config_file_attributes
> 
>  Cheers,
> 
>  Henning
> 
> >>>
> >>> __
> >>> Kamailio - Users Mailing List - Non Commercial Discussions
> >>>   * sr-users@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
> >
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> >   * sr-users@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
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

Use your 209.x external IP.

On Sun, Jan 16, 2022 at 18:07 Chad  wrote:

> Yes I am using a 172.16.x.x IP and it works, it rewrites the headers, but
> again because 172.16.x.x is also a private IP
> it is the same as using my real 10.x.x.x IP. The carrier's ACK throws away
> the local IP and sends the response to my
> 209.x external IP.
>
>
> --
> ^C
>
>
> On 1/16/22 1:38 PM, Ovidiu Sas wrote:
> > Have you tried using the mask_ip param:
> >
> https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
> > <
> https://www.kamailio.org/docs/modules/devel/modules/topoh.html#topoh.p.mask_ip
> >
> >
> > -ovidiu
> >
> > On Sun, Jan 16, 2022 at 16:09 Chad  ccolu...@hotmail.com>> wrote:
> >
> > I found a sample config file using topoh, which I copied (with some
> changes) and added the topoh module to my config.
> > It works fine, but it does not solve the problem.
> > In fact it has the exact same problem, because all the topoh module
> does is replace one private IP with another in the
> > 2nd (top most) Record-Route header.
> > So the carrier still changes the ACK to the public IP and the call
> is still broken in the exact same way.
> > It was super easy to add, but does not work, 1 possible solution
> down.
> >
> > --
> > ^C
> >
> >
> > On 1/16/22 8:26 AM, Ovidiu Sas wrote:
> >  > Most of the time, if you get the right person on the carrier's
> side
> >  > and you explain the situation, they will come up with a solution.
> >  > If not, you need to break the RFC in a way that will counterpart
> their breakage.
> >  >
> >  > The carrier is also using a SIP proxy (maybe kamailio, who knows).
> >  > In the old days, the default kamailio config was using
> >  > fix_nated_contact() to deal with NATed devices and this is
> exactly the
> >  > behavior that you are seeing.
> >  > The recommended way to deal with NATed devices is to use
> >  > add_contact_alias([ip_addr, port, proto]) which is RFC compliant.
> >  >
> >  > There are several solution for this scenario:
> >  >   - mangle the signaling to allow proper routing on your end
> >  >   - use a B2BUA in between your kamailio and carrier
> >  >   - configure kamailio to use one of the topology hiding modules:
> >  > topoh, topos, topos_redis
> >  >   - maybe something else ... :)
> >  >
> >  > There's no right or wrong approach, one must be comfortable with
> the
> >  > chosen solution to be able to maintain it.
> >  >
> >  > -ovidiu
> >  >
> >  > On Sat, Jan 15, 2022 at 9:14 PM Chad  <mailto:ccolu...@hotmail.com>> wrote:
> >  >>
> >  >> Ok so in short I was not doing anything wrong (although I had
> some miss-configurations), but the carrier is
> > (i.e. they
> >  >> are a bad actor). When they said I was doing it wrong, they did
> not mean in the RFC sense they meant in the "to work
> >  >> with us" sense. Now in order for me to get it to work with their
> SBC I have to mangle the contact on the way out an
> >  >> unmangle it on the return in Kamailio somehow, as I originally
> purposed.
> >  >> However I have no idea how to do that :)
> >  >>
> >  >> Shouldn't we (the Kamailio community) assume there are lots of
> bad actors out there and possibly many Kamailio users
> >  >> with this exact same issue (I personally know of at least 2 bad
> actor carriers right now) and create some kind of
> >  >> template or snippet that we can publicly publish on the Kamailio
> docs or wiki for all of the Kamailio community
> > to use
> >  >> for this use case?
> >  >>
> >  >> I have been fighting with carriers about this for years and they
> always said I was doing it wrong and I don't
> > know the
> >  >> SIP RFC well enough to fight back. So why not build a solution
> for everyone out there that has to deal with a
> > bad actor?
> >  >>
> >  >> --
> >  >> ^C
> >  >>
> >  >>
> >  >> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
> >  >>> As expected, your carrier is bogus and "thinks" it knows better.
> >  >>> Your carrier is treating your setup as a dumb endpoint and is
>

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

Most of the time, if you get the right person on the carrier's side
and you explain the situation, they will come up with a solution.
If not, you need to break the RFC in a way that will counterpart their breakage.

The carrier is also using a SIP proxy (maybe kamailio, who knows).
In the old days, the default kamailio config was using
fix_nated_contact() to deal with NATed devices and this is exactly the
behavior that you are seeing.
The recommended way to deal with NATed devices is to use
add_contact_alias([ip_addr, port, proto]) which is RFC compliant.

There are several solution for this scenario:
 - mangle the signaling to allow proper routing on your end
 - use a B2BUA in between your kamailio and carrier
 - configure kamailio to use one of the topology hiding modules:
topoh, topos, topos_redis
 - maybe something else ... :)

There's no right or wrong approach, one must be comfortable with the
chosen solution to be able to maintain it.

-ovidiu

On Sat, Jan 15, 2022 at 9:14 PM Chad  wrote:
>
> Ok so in short I was not doing anything wrong (although I had some 
> miss-configurations), but the carrier is (i.e. they
> are a bad actor). When they said I was doing it wrong, they did not mean in 
> the RFC sense they meant in the "to work
> with us" sense. Now in order for me to get it to work with their SBC I have 
> to mangle the contact on the way out an
> unmangle it on the return in Kamailio somehow, as I originally purposed.
> However I have no idea how to do that :)
>
> Shouldn't we (the Kamailio community) assume there are lots of bad actors out 
> there and possibly many Kamailio users
> with this exact same issue (I personally know of at least 2 bad actor 
> carriers right now) and create some kind of
> template or snippet that we can publicly publish on the Kamailio docs or wiki 
> for all of the Kamailio community to use
> for this use case?
>
> I have been fighting with carriers about this for years and they always said 
> I was doing it wrong and I don't know the
> SIP RFC well enough to fight back. So why not build a solution for everyone 
> out there that has to deal with a bad actor?
>
> --
> ^C
>
>
> On 1/15/22 11:40 AM, Ovidiu Sas wrote:
> > As expected, your carrier is bogus and "thinks" it knows better.
> > Your carrier is treating your setup as a dumb endpoint and is
> > re-writing the Contact header:
> > You provide this contact header in 200 OK:
> > Contact: 
> > The carrier should set the RURI in ACK like this:
> > ACK sip:928###@10.###.###.104:5060 SIP/2.0
> > Instead, your ACK is sent to you like this:
> > ACK sip:928###@209.###.###.###:5060 SIP/2.0
> >
> > The RURI in ACK should point to the private IP of the asterisk server,
> > not to the public IP of the kamailio server.
> > You need to ask the carrier to follow the SIP RFC and not treat your
> > endpoints like dumb SIP endpoints.
> >
> > There's a high chance that they won't do it :)
> > Your best chance is to manually mangle the URI in Contact in the 200
> > OK in a way that when you receive the ACK with the mangled RURI, you
> > can restore the original URI and let kamailio do the proper routing to
> > the private IP of the asterisk serverr.
> > You should be able to achieve this by using one of the following functions:
> > https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
> > https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact
> > https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode
> >
> > Regards,
> > Ovidiu Sas
> >
> > On Sat, Jan 15, 2022 at 1:28 PM Chad  wrote:
> >>
> >> I changed the listen per your advice and here is the 200 and ACK.
> >> I get no audio and the the call disconnects and I see this is the Asterisk 
> >> log:
> >> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout 
> >> reached on transmission
> >> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 for seqno 102 
> >> (Critical Response) -- See
> >> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
> >> Packet timed out after 6401ms with no response
> >> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call 
> >> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 - no
> >> reply to our critical packet (see https://wiki.asterisk.org/wik
> >>
> >> FYI 10.###.###.254 is the private virtual IP on the Kamailio server and 
> >> 10.###.###.104 is the asterisk box.
> >>
> >> SIP/2.0 200 OK
> >> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac1

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

As expected, your carrier is bogus and "thinks" it knows better.
Your carrier is treating your setup as a dumb endpoint and is
re-writing the Contact header:
You provide this contact header in 200 OK:
Contact: 
The carrier should set the RURI in ACK like this:
ACK sip:928###@10.###.###.104:5060 SIP/2.0
Instead, your ACK is sent to you like this:
ACK sip:928###@209.###.###.###:5060 SIP/2.0

The RURI in ACK should point to the private IP of the asterisk server,
not to the public IP of the kamailio server.
You need to ask the carrier to follow the SIP RFC and not treat your
endpoints like dumb SIP endpoints.

There's a high chance that they won't do it :)
Your best chance is to manually mangle the URI in Contact in the 200
OK in a way that when you receive the ACK with the mangled RURI, you
can restore the original URI and let kamailio do the proper routing to
the private IP of the asterisk serverr.
You should be able to achieve this by using one of the following functions:
https://kamailio.org/docs/modules/5.5.x/modules/mangler.html#mangler.f.encode_contact
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.encode_contact
https://kamailio.org/docs/modules/5.5.x/modules/siputils.html#siputils.f.contact_param_encode

Regards,
Ovidiu Sas

On Sat, Jan 15, 2022 at 1:28 PM Chad  wrote:
>
> I changed the listen per your advice and here is the 200 and ACK.
> I get no audio and the the call disconnects and I see this is the Asterisk 
> log:
> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Retransmission timeout reached 
> on transmission
> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 for seqno 102 (Critical 
> Response) -- See
> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
> Packet timed out after 6401ms with no response
> [Jan 15 10:17:13] WARNING[29953] chan_sip.c: Hanging up call 
> 5ab1525b3712f34c2ab272ae55e649e5@10.44.109.143:5060 - no
> reply to our critical packet (see https://wiki.asterisk.org/wik
>
> FYI 10.###.###.254 is the private virtual IP on the Kamailio server and 
> 10.###.###.104 is the asterisk box.
>
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.0
> Via: SIP/2.0/UDP 
> 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK6gj48a00dolcl3jm2gq0.1
> Record-Route: 
> Record-Route: 
> Record-Route: 
> From: "Anonymous" ;tag=as04035ef0
> To: ;tag=as7047ed05
> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060
> CSeq: 102 INVITE
> Server: Asterisk PBX 16.18.0
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Contact: 
> Content-Type: application/sdp
> Content-Length: 274
>
> v=0
> o=root 1911037741 1911037741 IN IP4 209.###.###.###
> s=Asterisk PBX 16.18.0
> c=IN IP4 209.###.###.###
> t=0 0
> m=audio 11384 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> a=nortpproxy:yes
>
> ACK sip:928###@209.###.###.###:5060 SIP/2.0
> Via: SIP/2.0/UDP 64.###.###.###:5060;branch=z9hG4bK26ab.5547ac15.2
> Via: SIP/2.0/UDP 
> 206.###.###.###:5060;rport=5060;received=206.###.###.###;branch=z9hG4bK91l3it006gr9oiulcqn0.1
> Max-Forwards: 67
> From: "Anonymous" ;tag=as04035ef0
> To: ;tag=as7047ed05
> Contact: 
> Call-ID: 5ab1525b3712f34c2ab272ae55e649e5@10.44.###.###:5060
> CSeq: 102 ACK
> User-Agent: packetrino
> Content-Length: 0
> Route: 
> Route: 
>
>
> --
> ^C
>
>
> On 1/15/22 10:21 AM, Ovidiu Sas wrote:
> > This is false. The IP in the Contact header must be routable by the
> > SIP hop from the top Record-Route header in the reply.
> > The carrier (and it seems that they have a PROXY also) must be able to
> > route to their adjacent SIP hop, which is your public IP (the IP in
> > the second Record-Route header).
> > It seems that the carrier is not taking into account that they might
> > interface with other proxies.
> > Most likely, your carrier expects to interface with a simple SIP UA,
> > not with another proxy. This is a pretty common setup for most of the
> > carriers, although many new carrier implementations are taking care of
> > the proxy to proxy calls.
> >
> > It would be helpful to see the ACK that is sent by the carrier in
> > response to your 200ok (after you fix your config and you have your
> > private IP listed in the Record-Route header).
> >
> > -ovidiu
> >
> > On Sat, Jan 15, 2022 at 12:33 PM Chad  wrote:
> >>
> >> Hmm, I don't think you are right that the Contact header can be a private 
> >> IP even if the RR is correct.
> >&

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

This is false. The IP in the Contact header must be routable by the
SIP hop from the top Record-Route header in the reply.
The carrier (and it seems that they have a PROXY also) must be able to
route to their adjacent SIP hop, which is your public IP (the IP in
the second Record-Route header).
It seems that the carrier is not taking into account that they might
interface with other proxies.
Most likely, your carrier expects to interface with a simple SIP UA,
not with another proxy. This is a pretty common setup for most of the
carriers, although many new carrier implementations are taking care of
the proxy to proxy calls.

It would be helpful to see the ACK that is sent by the carrier in
response to your 200ok (after you fix your config and you have your
private IP listed in the Record-Route header).

-ovidiu

On Sat, Jan 15, 2022 at 12:33 PM Chad  wrote:
>
> Hmm, I don't think you are right that the Contact header can be a private IP 
> even if the RR is correct.
> I did some research on it and I found several places saying it must be a 
> routable IP which is what the carrier also said.
>
> "The Contact header contains the SIP URI where the client wants to be 
> contacted for subsequent requests. That means that
> the host part of the URI must be globally reachable by anyone.
> If your contact contains a private IP (behind a NAT?) then it is wrong, 
> because other peers cannot reach you with that."
>
>
> --
> ^C
>
>
> On 1/15/22 9:05 AM, Ovidiu Sas wrote:
> > You have a different problem then.
> > Having private IPs in Contact is fine. You need to lose route the
> > calls (kamailio will add two Record-Route headers) and the origination
> > server will set the RURI to the private IP from Contact, but it will
> > send the in-dialog requests to the public IP of kamailio. This has
> > nothing to do with virtual IPs.
> > Maybe you have a buggy client that doesn't do proper loose routing.
> >
> > -ovidiu
> >
> > On Sat, Jan 15, 2022 at 11:50 AM Chad  wrote:
> >>
> >> Ovidiu,
> >> Thank you again for your response.
> >> One is public (an internet IP) and one is private (a 10.x ip).
> >> Apparently this is a known problem with virtual IPs, it does not work.
> >> When the asterisk server responds to the invite it sends a contact header 
> >> with the private IP and Kamailio does not
> >> rewrite it to the advertised public IP. So the originating server sees the 
> >> private IP in the Contact header and tries to
> >> send the traffic to the 10.x IP (which is non-routable) and the call dies.
> >> I have been trying things for a long time to fix this (years) what you are 
> >> saying will not fix it because of the virtual
> >> IPs.
> >> If it was a normal IP it would work fine. It has something to do with the 
> >> routing table and how mhomed detects networks.
> >>
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> >>> Hello Chad,
> >>>
> >>> The floating IPs that you have, are they both private IPs or one
> >>> private IP and the other one a public IP?
> >>>
> >>> If you have to two floating private IPs, then you need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> >>> listen=FLOATING_UDP_PRIVATE2
> >>>
> >>> In the config, before relaying the initial INVITE you need to detect
> >>> the direction of the call and set $fs accordingly:
> >>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {
> >>>   $fs = udp:FLOATING_UDP_PRIVATE1
> >>> }
> >>> else {
> >>>   $fs = udp:FLOATING_UDP_PRIVATE2
> >>> }
> >>>
> >>> If you have a floating private IPs and a floating public IP, then you
> >>> need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE
> >>> listen=FLOATING_UDP_PUBLIC
> >>>
> >>> There should be no need to force the socket, but if you do, there's no
> >>> harm (actually it's better and faster).
> >>>
> >>> Hope this clarifies things and helps,
> >>> -ovidiu
> >>>
> >>> On Sat, Jan 15, 2022 at 9:48 AM Chad  wrote:
> >>>>
> >>>> Ovidiu,
> >>>> Thank you for your response.
> >>>>
> >>>> I have done that, in addition to the linux ip_nonlocal_bind I have also 
> >>>> set the Kamailio ip_free_bind=1 and it does not
> >>>> work.
> >>>> Here are my relevant config lines:
> >&

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

Oops ... copy/paste mistake:
You need to replace:
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
with
listen=LISTEN_UDP_PRIVATE

-ovidiu

On Sat, Jan 15, 2022 at 1:07 PM Ovidiu Sas  wrote:
>
> It doesn't look good because you have the public IP twice in the
> Record-Route header.
> You need to replace the
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> with
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> and all should be good.
>
> If your carrier is telling you that the IP address in Contact should
> be public, then you need to find an RFC compliant carrier (or mangle
> the Contact to make them happy).
> Most of the time I fight with them until they have this fixed.
> Sometimes it's a lost battle and you just need to hack your config to
> make it work.
>
> I have deployed kamailio using this setup and if you deal with RFC
> compliant end-point (carriers, softphones, hardphones) then all is
> good.
>
> -ovidiu
>
> On Sat, Jan 15, 2022 at 12:14 PM Chad  wrote:
> >
> > It would be great if you are right and I am simply doing something else 
> > wrong in the config file!
> >
> > Here is the 200 OK (note I have enable_double_rr enabled):
> > SIP/2.0 200 OK
> > Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0
> > Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0
> > Record-Route: 
> > Record-Route: 
> > Record-Route: 
> > From: ;tag=gK0e16642e
> > To: ;tag=as488a6fb4
> > Call-ID: 202251204_54250714@206.###.###.###
> > CSeq: 710596 INVITE
> > Server: Asterisk PBX 16.18.0
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> > PUBLISH, MESSAGE
> > Supported: replaces, timer
> > Session-Expires: 1800;refresher=uas
> > Contact: 
> > Content-Type: application/sdp
> > Require: timer
> > Content-Length: 272
> >
> > v=0
> > o=root 153822920 153822920 IN IP4 209.###.###.###
> > s=Asterisk PBX 16.18.0
> > c=IN IP4 209.###.###.###
> > t=0 0
> > m=audio 17198 RTP/AVP 0 101
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-16
> > a=ptime:20
> > a=maxptime:150
> > a=sendrecv
> > a=nortpproxy:yes
> >
> >
> > --
> > ^C
> >
> >
> > On 1/15/22 9:05 AM, Ovidiu Sas wrote:
> > > You have a different problem then.
> > > Having private IPs in Contact is fine. You need to lose route the
> > > calls (kamailio will add two Record-Route headers) and the origination
> > > server will set the RURI to the private IP from Contact, but it will
> > > send the in-dialog requests to the public IP of kamailio. This has
> > > nothing to do with virtual IPs.
> > > Maybe you have a buggy client that doesn't do proper loose routing.
> > >
> > > -ovidiu
> > >
> > > On Sat, Jan 15, 2022 at 11:50 AM Chad  wrote:
> > >>
> > >> Ovidiu,
> > >> Thank you again for your response.
> > >> One is public (an internet IP) and one is private (a 10.x ip).
> > >> Apparently this is a known problem with virtual IPs, it does not work.
> > >> When the asterisk server responds to the invite it sends a contact 
> > >> header with the private IP and Kamailio does not
> > >> rewrite it to the advertised public IP. So the originating server sees 
> > >> the private IP in the Contact header and tries to
> > >> send the traffic to the 10.x IP (which is non-routable) and the call 
> > >> dies.
> > >> I have been trying things for a long time to fix this (years) what you 
> > >> are saying will not fix it because of the virtual
> > >> IPs.
> > >> If it was a normal IP it would work fine. It has something to do with 
> > >> the routing table and how mhomed detects networks.
> > >>
> > >> --
> > >> ^C
> > >>
> > >>
> > >> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> > >>> Hello Chad,
> > >>>
> > >>> The floating IPs that you have, are they both private IPs or one
> > >>> private IP and the other one a public IP?
> > >>>
> > >>> If you have to two floating private IPs, then you need a config like 
> > >>> this:
> > >>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> > >>> listen=FLOATING_UDP_PRIVATE2
> > >>>
> > >>> In the config, before relaying the initial INVITE you need to detect
> > >>> t

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

It doesn't look good because you have the public IP twice in the
Record-Route header.
You need to replace the
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
with
listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
and all should be good.

If your carrier is telling you that the IP address in Contact should
be public, then you need to find an RFC compliant carrier (or mangle
the Contact to make them happy).
Most of the time I fight with them until they have this fixed.
Sometimes it's a lost battle and you just need to hack your config to
make it work.

I have deployed kamailio using this setup and if you deal with RFC
compliant end-point (carriers, softphones, hardphones) then all is
good.

-ovidiu

On Sat, Jan 15, 2022 at 12:14 PM Chad  wrote:
>
> It would be great if you are right and I am simply doing something else wrong 
> in the config file!
>
> Here is the 200 OK (note I have enable_double_rr enabled):
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 18.###.###.###:5060;branch=z9hG4bK22b2.6b6d30e5.0
> Via: SIP/2.0/UDP 66.###.###.###:5060;branch=z9hG4bK22b2.d15ac8a.0
> Record-Route: 
> Record-Route: 
> Record-Route: 
> From: ;tag=gK0e16642e
> To: ;tag=as488a6fb4
> Call-ID: 202251204_54250714@206.###.###.###
> CSeq: 710596 INVITE
> Server: Asterisk PBX 16.18.0
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, 
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: 
> Content-Type: application/sdp
> Require: timer
> Content-Length: 272
>
> v=0
> o=root 153822920 153822920 IN IP4 209.###.###.###
> s=Asterisk PBX 16.18.0
> c=IN IP4 209.###.###.###
> t=0 0
> m=audio 17198 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:150
> a=sendrecv
> a=nortpproxy:yes
>
>
> --
> ^C
>
>
> On 1/15/22 9:05 AM, Ovidiu Sas wrote:
> > You have a different problem then.
> > Having private IPs in Contact is fine. You need to lose route the
> > calls (kamailio will add two Record-Route headers) and the origination
> > server will set the RURI to the private IP from Contact, but it will
> > send the in-dialog requests to the public IP of kamailio. This has
> > nothing to do with virtual IPs.
> > Maybe you have a buggy client that doesn't do proper loose routing.
> >
> > -ovidiu
> >
> > On Sat, Jan 15, 2022 at 11:50 AM Chad  wrote:
> >>
> >> Ovidiu,
> >> Thank you again for your response.
> >> One is public (an internet IP) and one is private (a 10.x ip).
> >> Apparently this is a known problem with virtual IPs, it does not work.
> >> When the asterisk server responds to the invite it sends a contact header 
> >> with the private IP and Kamailio does not
> >> rewrite it to the advertised public IP. So the originating server sees the 
> >> private IP in the Contact header and tries to
> >> send the traffic to the 10.x IP (which is non-routable) and the call dies.
> >> I have been trying things for a long time to fix this (years) what you are 
> >> saying will not fix it because of the virtual
> >> IPs.
> >> If it was a normal IP it would work fine. It has something to do with the 
> >> routing table and how mhomed detects networks.
> >>
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> >>> Hello Chad,
> >>>
> >>> The floating IPs that you have, are they both private IPs or one
> >>> private IP and the other one a public IP?
> >>>
> >>> If you have to two floating private IPs, then you need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> >>> listen=FLOATING_UDP_PRIVATE2
> >>>
> >>> In the config, before relaying the initial INVITE you need to detect
> >>> the direction of the call and set $fs accordingly:
> >>> if (CAL_FROM_PRIVATE_TO_PUBLIC) {
> >>>   $fs = udp:FLOATING_UDP_PRIVATE1
> >>> }
> >>> else {
> >>>   $fs = udp:FLOATING_UDP_PRIVATE2
> >>> }
> >>>
> >>> If you have a floating private IPs and a floating public IP, then you
> >>> need a config like this:
> >>> listen=FLOATING_UDP_PRIVATE
> >>> listen=FLOATING_UDP_PUBLIC
> >>>
> >>> There should be no need to force the socket, but if you do, there's no
> >>> harm (actually it's better and faster).
> >>>
> >>> Hope this clarifies things and helps,
> >>> -ovidiu
> 

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

You have a different problem then.
Having private IPs in Contact is fine. You need to lose route the
calls (kamailio will add two Record-Route headers) and the origination
server will set the RURI to the private IP from Contact, but it will
send the in-dialog requests to the public IP of kamailio. This has
nothing to do with virtual IPs.
Maybe you have a buggy client that doesn't do proper loose routing.

-ovidiu

On Sat, Jan 15, 2022 at 11:50 AM Chad  wrote:
>
> Ovidiu,
> Thank you again for your response.
> One is public (an internet IP) and one is private (a 10.x ip).
> Apparently this is a known problem with virtual IPs, it does not work.
> When the asterisk server responds to the invite it sends a contact header 
> with the private IP and Kamailio does not
> rewrite it to the advertised public IP. So the originating server sees the 
> private IP in the Contact header and tries to
> send the traffic to the 10.x IP (which is non-routable) and the call dies.
> I have been trying things for a long time to fix this (years) what you are 
> saying will not fix it because of the virtual
> IPs.
> If it was a normal IP it would work fine. It has something to do with the 
> routing table and how mhomed detects networks.
>
> --
> ^C
>
>
> On 1/15/22 8:36 AM, Ovidiu Sas wrote:
> > Hello Chad,
> >
> > The floating IPs that you have, are they both private IPs or one
> > private IP and the other one a public IP?
> >
> > If you have to two floating private IPs, then you need a config like this:
> > listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
> > listen=FLOATING_UDP_PRIVATE2
> >
> > In the config, before relaying the initial INVITE you need to detect
> > the direction of the call and set $fs accordingly:
> > if (CAL_FROM_PRIVATE_TO_PUBLIC) {
> >  $fs = udp:FLOATING_UDP_PRIVATE1
> > }
> > else {
> >  $fs = udp:FLOATING_UDP_PRIVATE2
> > }
> >
> > If you have a floating private IPs and a floating public IP, then you
> > need a config like this:
> > listen=FLOATING_UDP_PRIVATE
> > listen=FLOATING_UDP_PUBLIC
> >
> > There should be no need to force the socket, but if you do, there's no
> > harm (actually it's better and faster).
> >
> > Hope this clarifies things and helps,
> > -ovidiu
> >
> > On Sat, Jan 15, 2022 at 9:48 AM Chad  wrote:
> >>
> >> Ovidiu,
> >> Thank you for your response.
> >>
> >> I have done that, in addition to the linux ip_nonlocal_bind I have also 
> >> set the Kamailio ip_free_bind=1 and it does not
> >> work.
> >> Here are my relevant config lines:
> >> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> >> listen=LISTEN_UDP_PUBLIC
> >>
> >> mhomed=1
> >> ip_free_bind=1
> >>
> >>
> >> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have 
> >> been using it for a long time and have
> >> rebooted as well):
> >> net.ipv4.ip_nonlocal_bind=1
> >> --
> >> ^C
> >>
> >>
> >> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
> >>> Hello Chad,
> >>>
> >>> You can add a listen directive to your config for the virtual IPs
> >>> (both public and private) and then you don't need to manually modify
> >>> any headers or use force_send_socket().
> >>> You need to enable non local IP binding so kamailio can start on the
> >>> server that doesn't have the virtual IP:
> >>> echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
> >>> To make the change permanent, edit your sysctl.conf file and enable it 
> >>> there:
> >>> net/ipv4/ip_nonlocal_bind = 1
> >>>
> >>> Regards
> >>> Ovidiu Sas
> >>>
> >>>
> >>> On Sat, Jan 15, 2022 at 4:16 AM Chad  wrote:
> >>>>
> >>>> We are looking for some help (possibly a paid consultant) to help us 
> >>>> with our Kamailio setup.
> >>>> To keep this as short as possible: we use Kamailio as a NAT proxy to 
> >>>> bridge our external IP and our private IP asterisk
> >>>> servers (via dispatcher).
> >>>> However both the external IP and the internal IP that the Kamailio 
> >>>> server uses are virtual IPs created by keepalived.
> >>>> Because of that neither mhomed nor fix_nated_contact work, and we use 
> >>>> force_send_socket to direct the traffic.
> >>>> We run linux Debian 10 for the OS.
> >>>> Also we do not use a DB at all, eve

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

Hello Chad,

The floating IPs that you have, are they both private IPs or one
private IP and the other one a public IP?

If you have to two floating private IPs, then you need a config like this:
listen=FLOATING_UDP_PRIVATE1 advertise PUBLIC_UDP_IP
listen=FLOATING_UDP_PRIVATE2

In the config, before relaying the initial INVITE you need to detect
the direction of the call and set $fs accordingly:
if (CAL_FROM_PRIVATE_TO_PUBLIC) {
$fs = udp:FLOATING_UDP_PRIVATE1
}
else {
$fs = udp:FLOATING_UDP_PRIVATE2
}

If you have a floating private IPs and a floating public IP, then you
need a config like this:
listen=FLOATING_UDP_PRIVATE
listen=FLOATING_UDP_PUBLIC

There should be no need to force the socket, but if you do, there's no
harm (actually it's better and faster).

Hope this clarifies things and helps,
-ovidiu

On Sat, Jan 15, 2022 at 9:48 AM Chad  wrote:
>
> Ovidiu,
> Thank you for your response.
>
> I have done that, in addition to the linux ip_nonlocal_bind I have also set 
> the Kamailio ip_free_bind=1 and it does not
> work.
> Here are my relevant config lines:
> listen=LISTEN_UDP_PRIVATE advertise MY_PUBLIC_IP:5060
> listen=LISTEN_UDP_PUBLIC
>
> mhomed=1
> ip_free_bind=1
>
>
> In my /etc/sysctl.conf I have (yes I applied it with sysctl -p, and I have 
> been using it for a long time and have
> rebooted as well):
> net.ipv4.ip_nonlocal_bind=1
> --
> ^C
>
>
> On 1/15/22 4:55 AM, Ovidiu Sas wrote:
> > Hello Chad,
> >
> > You can add a listen directive to your config for the virtual IPs
> > (both public and private) and then you don't need to manually modify
> > any headers or use force_send_socket().
> > You need to enable non local IP binding so kamailio can start on the
> > server that doesn't have the virtual IP:
> > echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
> > To make the change permanent, edit your sysctl.conf file and enable it 
> > there:
> > net/ipv4/ip_nonlocal_bind = 1
> >
> > Regards
> > Ovidiu Sas
> >
> >
> > On Sat, Jan 15, 2022 at 4:16 AM Chad  wrote:
> >>
> >> We are looking for some help (possibly a paid consultant) to help us with 
> >> our Kamailio setup.
> >> To keep this as short as possible: we use Kamailio as a NAT proxy to 
> >> bridge our external IP and our private IP asterisk
> >> servers (via dispatcher).
> >> However both the external IP and the internal IP that the Kamailio server 
> >> uses are virtual IPs created by keepalived.
> >> Because of that neither mhomed nor fix_nated_contact work, and we use 
> >> force_send_socket to direct the traffic.
> >> We run linux Debian 10 for the OS.
> >> Also we do not use a DB at all, everything is done with local config files.
> >>
> >> The problem is that when traffic goes out the Contact header has a private 
> >> IP in it, like:
> >> Contact: 
> >>
> >> There are 2 possible solutions to this:
> >> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio 
> >> recognize the virtual IPs so that mhomed and
> >> fix_nated_contact work as usual.
> >>
> >> 2. Create a manual header rewrite system.
> >>
> >> If solution #2:
> >> What we need to do is create a way to rewrite the contact header to the 
> >> external IP on the way out, and on the way back
> >> rewrite it back to the internal server that the call is already connected 
> >> to.
> >>
> >> Not sure if we will need to store those paths on the server or if we can 
> >> do some kind of cheat with another persistant
> >> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the 
> >> internal IP in the name field or something).
> >>
> >> If anyone out there know of a way to do this or wants to give it a try 
> >> please reach out to me.
> >>
> >> Thank you all for your time.
> >>
> >> --
> >> ^C
> >> Chad
> >>
> >> __
> >> Kamailio - Users Mailing List - Non Commercial Discussions
> >>* sr-users@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
> >
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
> >
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> >* sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Help with rewriting headers for NAT manually

[Ovidiu Sas]

Hello Chad,

You can add a listen directive to your config for the virtual IPs
(both public and private) and then you don't need to manually modify
any headers or use force_send_socket().
You need to enable non local IP binding so kamailio can start on the
server that doesn't have the virtual IP:
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
To make the change permanent, edit your sysctl.conf file and enable it there:
net/ipv4/ip_nonlocal_bind = 1

Regards
Ovidiu Sas


On Sat, Jan 15, 2022 at 4:16 AM Chad  wrote:
>
> We are looking for some help (possibly a paid consultant) to help us with our 
> Kamailio setup.
> To keep this as short as possible: we use Kamailio as a NAT proxy to bridge 
> our external IP and our private IP asterisk
> servers (via dispatcher).
> However both the external IP and the internal IP that the Kamailio server 
> uses are virtual IPs created by keepalived.
> Because of that neither mhomed nor fix_nated_contact work, and we use 
> force_send_socket to direct the traffic.
> We run linux Debian 10 for the OS.
> Also we do not use a DB at all, everything is done with local config files.
>
> The problem is that when traffic goes out the Contact header has a private IP 
> in it, like:
> Contact: 
>
> There are 2 possible solutions to this:
> 1. Make changes to linux, keepalived and/or Kamailio so that Kamailio 
> recognize the virtual IPs so that mhomed and
> fix_nated_contact work as usual.
>
> 2. Create a manual header rewrite system.
>
> If solution #2:
> What we need to do is create a way to rewrite the contact header to the 
> external IP on the way out, and on the way back
> rewrite it back to the internal server that the call is already connected to.
>
> Not sure if we will need to store those paths on the server or if we can do 
> some kind of cheat with another persistant
> header like P-Preferred-Identity or P-Asserted-Identity (i.e. store the 
> internal IP in the name field or something).
>
> If anyone out there know of a way to do this or wants to give it a try please 
> reach out to me.
>
> Thank you all for your time.
>
> --
> ^C
> Chad
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



--
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Mid-dialog failover without virtual IP

[Ovidiu Sas]

Maybe we should deprecate and remove the advertise_address.

-ovidiu

On Fri, Jan 14, 2022 at 10:34 Daniel-Constantin Mierla 
wrote:

> Hello,
>
> advertise_address is an old global parameter that is only for Via. Try to
> use the advertise attribute for listen parameter -- see core cookbook for
> more details.
>
> Cheers,
> Daniel
> On 14.01.22 08:27, Muhammad Danish Moosa wrote:
>
> Hi,
>
> I have a pair of kamailio stateful proxies and am trying to achieve
> Active-Passive failover model with DMQ dialog replication. Primary Proxy is
> working in the middle of  2 SBCs and all nodes are within the same network
> so NATing is NOT involved ;secondary proxy is accessible through VPN. It's
> pretty simple configuration, proxy is just adding and removing headers in
> the middle.
>
> So if I stop the kamailio service on primary IP , SBCs blacklist that and
> start sending new invites to secondary IP. That's all good.
>
> But if I reproduce this failover during a connected session , SBCs do not
> send mid-dialog requests/responses to failover IP. I can see they still try
> to send messages to primary SBC which obviously end up with timeout. I
> understand the most natural solution is HA with Virual IP but it's not
> possible because secondary IP is accessible through VPN.
>
> I tried to use DNS SRV record with priorities but that also does not work
> with mid-dialog messages, I also have tried to change record-route/via
> header to fqdn through advertise_address. Its not changing record-route but
> via only but I am still not getting expected results.
>
> Any guidance of possible solution(s) here will be appreciated.
>
>
>
>
>
>
> --
> Muhammad Danish Moosa
>
> " The core of mans' spirit comes from new experiences. "___ Christopher
> McCandless
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio Advanced Training - Online
>   Feb 21-24, 2022 (America Timezone)
>   * https://www.asipto.com/sw/kamailio-advanced-training-online/
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Kamailio Stop processing SIP traffic

[Ovidiu Sas]

Check with htop if you don't have any kamailio procs at 100% CPU (due
to a deadlock).
Do you see any errors in the logs?

-ovidiu


On Wed, Dec 22, 2021 at 11:44 AM pwerspire  wrote:
>
> The CPU is around 30% during the test, is always really stable and memory 
> doesn't increase much.
>
> I'm using children=8.
>
>
>
> Sergio Charrua  escreveu no dia quarta, 22/12/2021 
> à(s) 16:27:
>>
>> any statistics regarding CPU use? how many threads?
>>
>> Sérgio Charrua
>>
>>
>> www.voip.pt
>> Tel.: +351 21 130 71 77
>>
>> Email : sergio.char...@voip.pt
>>
>> This message and any files or documents attached are strictly confidential 
>> or otherwise legally protected.
>>
>> It is intended only for the individual or entity named. If you are not the 
>> named addressee or have received this email in error, please inform the 
>> sender immediately, delete it from your system and do not copy or disclose 
>> it or its contents or use it for any purpose. Please also note that 
>> transmission cannot be guaranteed to be secure or error-free.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Dec 22, 2021 at 3:57 PM pwerspire  wrote:
>>>
>>> Hi Sergio,
>>>
>>> Thanks for your reply.
>>>
>>> This is a google cloud VM with 8 vCPU,  I'm using 100 CPS but the number of 
>>> simultaneous calls is stable at around 1071 at any given time.
>>>
>>> Also, I can always see INVITES going inside the server but Kamailio stops 
>>> answering them, even if you stop sending calls for a long time, and then 
>>> send a single call, Kamailio will not reply anymore to the Invites.
>>>
>>> When Kamailio stops replying to INVITES, If I do for example a "kamcmd 
>>> dispatcher.list" I have the correct output, but if I do a "kamcmd dlg.list" 
>>> it will not provide any output and not give back the prompt( before it 
>>> would just answer that the reply was too big).
>>> I will need to use "control + c" to get the prompt of the shell back and 
>>> after that, all kamcmd commands stop returning any output or giving back 
>>> the prompt.
>>>
>>> If the Kamailio is then restarted, everything starts working correctly 
>>> again. Also, another note is that this seems only to happen when DMQ is in 
>>> use and replicating to the fallback Kamailio.
>>>
>>> Regards,
>>> Tiago
>>>
>>>
>>> Sergio Charrua  escreveu no dia terça, 21/12/2021 
>>> à(s) 13:38:

 What is the call length of each call? How many NICs you have on that 
 server? what networking switches are you using? all these variables have 
 huge impacts on the call flow!

 Let's say you make 100CPS and the call length is 10 minutes.
 At 10 seconds you will have 1.000 ongoing calls using g711 (64kbps). You 
 will have around 64Mbps bandwidth being used.
 At 1 minute you get 6.000 ongoing calls and will use 390Mbps bandwidth!
 Near the 10th minute you will be using almost 4Gbps bandwidth and 60.000 
 ongoing calls!!

 Maybe the issue is not within Kamailio and/or the media server, but within 
 your network capacity ...

 On my side, on a 4 vCPU and 4GB Ram, Kamailio 5.2 gets me around 400cps 
 with calls up to 30seconds length, and RTPEngine goes OK too. I am sure I 
 could do more, but I don't bother much, this is more than enough!
 But I have an enormous amount of bandwidth and 3 NICs on the server. NICs 
 are the key . Remember that Kamailio only processes SIP messages.
 At 5 minutes, using the above call details, you've already sent 30.000 SIP 
 INVITES minimum and many more SIP messages during that time. You need a 
 very good network interface to do that kind of job!
 Add 30.000 channels / RTP ports to your media server and you get a whole 
 lot of data going on in your network. I bet even the UTP5 cables won't 
 handle the heat   =:o)

 Also, check the RTP port range your media server was configured with.
 On Asterisk, usually ports 10.000 to 20.000 are set, which is about 10.000 
 calls. In the above example, you would stop receiving calls at 2minutes 
 because Asterisk has all RTP ports busy/in use!
 I don't know about other media servers, but I would bet this is pretty 
 much the same...

 Hope this helps!


 Sérgio Charrua


 www.voip.pt
 Tel.: +351 21 130 71 77

 Email : sergio.char...@voip.pt

 This message and any files or documents attached are strictly confidential 
 or otherwise legally protected.

 It is intended only for the individual or entity named. If you are not the 
 named addressee or have received this email in error, please inform the 
 sender immediately, delete it from your system and do not copy or disclose 
 it or its contents or use it for any purpose. Please also note that 
 transmission cannot be guaranteed to be secure or error-free.









 On Tue, Dec 21, 2021 at 11:54 AM pwerspire  wrote:
>
> Hi,
>
> I have 

Re: [SR-Users] JSON Error

[Ovidiu Sas]

Another option is to enhance the error log by printing out the string and
recompile. This will give you the string, but not the location in your
script.
Troubleshooting is always *fun*.

-ovidiu

On Thu, Nov 25, 2021 at 21:00 Daniel W. Graham  wrote:

> Thats what I was hoping to avoid unless there was an alternate option.
>
> -dan
>
> --
> *From:* sr-users  on behalf of
> Ovidiu Sas 
> *Sent:* Wednesday, November 24, 2021 10:51:33 PM
> *To:* Kamailio (SER) - Users Mailing List 
>
> *Subject:* Re: [SR-Users] JSON Error
>
> Add a log in the config on each location and correlate with the error log.
>
> -ovidiu
>
> On Wed, Nov 24, 2021 at 22:37 Daniel W. Graham  wrote:
>
> That’s what I’m looking to do, but there are lots of locations in the
> config file json is used and the error doesn’t give any indication what
> call to jansson_get is causing the error.
>
>
>
> -dan
>
>
>
> *From: *sr-users  on behalf of Fred
> Posner 
> *Date: *Wednesday, November 24, 2021 at 10:11 PM
> *To: *sr-users@lists.kamailio.org 
> *Subject: *Re: [SR-Users] JSON Error
>
> Are you verifying the document is valid JSON?
>
> Fred Posner | palner.com
> Matrix: @fred:matrix.lod.com
> o: +1 (212) 937-7844
>
> On 11/24/21 7:47 PM, Daniel W. Graham wrote:
> > My log is filled with this and have been unsuccessful locating
> > additional information by increasing debug level.
> >
> >
> >
> > Any thoughts on how to quickly isolate?
> >
> >
> >
> > /usr/local/sbin/kamailio[7678]: ERROR: jansson [jansson_funcs.c:48]:
> > janssonmod_get_helper(): json error at line 1, col 0: '[' or '{'
> > expected near end of file
> >
> > /usr/local/sbin/kamailio[7677]: ERROR: jansson [jansson_funcs.c:46]:
> > janssonmod_get_helper(): failed to parse json:
> >
> > /usr/local/sbin/kamailio[7677]: ERROR: jansson [jansson_funcs.c:48]:
> > janssonmod_get_helper(): json error at line 1, col 0: '[' or '{'
> > expected near end of file
> >
> > /usr/local/sbin/kamailio[7675]: ERROR: jansson [jansson_funcs.c:46]:
> > janssonmod_get_helper(): failed to parse json:
> >
> > /usr/local/sbin/kamailio[7675]: ERROR: jansson [jansson_funcs.c:48]:
> > janssonmod_get_helper(): json error at line 1, col 0: '[' or '{'
> > expected near end of file
> >
> >
> >
> > -dan
> >
> >
> >
> >
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> >   * sr-users@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
> >
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] JSON Error

[Ovidiu Sas]

Add a log in the config on each location and correlate with the error log.

-ovidiu

On Wed, Nov 24, 2021 at 22:37 Daniel W. Graham  wrote:

> That’s what I’m looking to do, but there are lots of locations in the
> config file json is used and the error doesn’t give any indication what
> call to jansson_get is causing the error.
>
>
>
> -dan
>
>
>
> *From: *sr-users  on behalf of Fred
> Posner 
> *Date: *Wednesday, November 24, 2021 at 10:11 PM
> *To: *sr-users@lists.kamailio.org 
> *Subject: *Re: [SR-Users] JSON Error
>
> Are you verifying the document is valid JSON?
>
> Fred Posner | palner.com
> Matrix: @fred:matrix.lod.com
> o: +1 (212) 937-7844
>
> On 11/24/21 7:47 PM, Daniel W. Graham wrote:
> > My log is filled with this and have been unsuccessful locating
> > additional information by increasing debug level.
> >
> >
> >
> > Any thoughts on how to quickly isolate?
> >
> >
> >
> > /usr/local/sbin/kamailio[7678]: ERROR: jansson [jansson_funcs.c:48]:
> > janssonmod_get_helper(): json error at line 1, col 0: '[' or '{'
> > expected near end of file
> >
> > /usr/local/sbin/kamailio[7677]: ERROR: jansson [jansson_funcs.c:46]:
> > janssonmod_get_helper(): failed to parse json:
> >
> > /usr/local/sbin/kamailio[7677]: ERROR: jansson [jansson_funcs.c:48]:
> > janssonmod_get_helper(): json error at line 1, col 0: '[' or '{'
> > expected near end of file
> >
> > /usr/local/sbin/kamailio[7675]: ERROR: jansson [jansson_funcs.c:46]:
> > janssonmod_get_helper(): failed to parse json:
> >
> > /usr/local/sbin/kamailio[7675]: ERROR: jansson [jansson_funcs.c:48]:
> > janssonmod_get_helper(): json error at line 1, col 0: '[' or '{'
> > expected near end of file
> >
> >
> >
> > -dan
> >
> >
> >
> >
> > __
> > Kamailio - Users Mailing List - Non Commercial Discussions
> >   * sr-users@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
> >
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] LCR Module not loading all rules from DB

[Ovidiu Sas]

Did you also check the kamailio logs (not the console)?

Regards,
Ovidiu Sas

On Sun, Nov 21, 2021 at 03:36 M Arqum CH  wrote:

> No didn't get any error message in  console.
>
>
> On Fri, Nov 19, 2021, 10:39 PM Juha Heinanen  wrote:
>
>> Do you get any error messages when you start kamailio or give
>> lcr.dump_rules command?  If not, then most likely all the rules are
>> loaded.
>>
>> If you have 73K rules, then
>>
>> modparam("lcr", "lcr_rule_hash_size", 1024)
>>
>> is way too small value if you want efficient hash table lookup, but it
>> does not affect the number of rules.
>>
>> lcr.dump_rules only printing 4096 rules may be rpc limitation.
>>
>> -- Juha
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@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
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] upgrade kamailio 4.4.x-to-5.0.0 - PostgreSQL migrations

[Ovidiu Sas]

Hello Giovanni,

You can check the postgres db scripts for each kamailio version under
utils/kamctl/postgres.
There you have the scripts for creating the postgress db tables.
You can see the exact differences between versions by comparing the
relevant files.
This is how I double check the db changes between upgrades :)

Hope this helps,
Ovidiu

On Thu, Sep 30, 2021 at 2:00 PM Henning Westerholt  wrote:
>
> Hello,
>
>
>
> have a look to the docs e.g., here, and replace mysql with postgres:
>
>
>
> https://kamailio.org/docs/tutorials/5.4.x/kamailio-install-guide-git/#create-mysql-database
>
>
>
> There is a tool “kamdbctl” for it, you can also just use the plain scheme 
> files in the kamailio source.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> From: Giovanni Tommasini - timenet srl 
> Sent: Thursday, September 30, 2021 4:46 PM
> To: Kamailio (SER) - Users Mailing List 
> Cc: Henning Westerholt 
> Subject: Re: [SR-Users] upgrade kamailio 4.4.x-to-5.0.0 - PostgreSQL 
> migrations
>
>
>
> Hi Henning,
>
>
>
> thank you for your reply.
> Interesting approach.
> Can you tell me where I can find information on how to "Install the new 5.4.x 
> kamailio postgres DB"?
>
>
>
> Cheers,
>
> Giovanni
>
>
>
> Il giorno gio 30 set 2021 alle ore 09:03 Henning Westerholt 
>  ha scritto:
>
> Hello Giovanni,
>
>
>
> You are doing a bigger step in one upgrade. I would suggest the following 
> approach to get the DB differences:
>
>
>
> · Do a pg_dump -s for the database schema on the existing 4.4.x DB
>
> · Install the new 5.4.x kamailio postgres DB on a test server etc..
>
> · Do a pg_dump -s for the new database schema on the test server
>
> · Compare the two schemas e.g. with diff or similar tool
>
> · Use this to create an ALTER TABLE to (a copy) of the old database on a test 
> server and test
>
> · Alternatively you can of course also use other SQL techniques to insert the 
> old data into the new one
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> From: sr-users  On Behalf Of Giovanni 
> Tommasini - timenet srl
> Sent: Wednesday, September 29, 2021 10:06 AM
> To: sr-users@lists.kamailio.org
> Subject: [SR-Users] upgrade kamailio 4.4.x-to-5.0.0 - PostgreSQL migrations
>
>
>
> Hi Dears,
>
>
>
> I'm working on upgrading Kamailio from 4.4.6 to 5.4.0 in an installation 
> where I use PostgreSQL
>
>
>
> I understand that I have to upgrade in steps by following these links:
> - http://www.kamailio.org/wiki/install/upgrade/4.4.x-to-5.0.0
>
> - http://www.kamailio.org/wiki/install/upgrade/5.0.x-to-5.1.0
>
> - https://www.kamailio.org/wiki/install/upgrade/5.1.x-to-5.2.0
>
> - https://www.kamailio.org/wiki/install/upgrade/5.2.x-to-5.3.0
>
> - https://www.kamailio.org/wiki/install/upgrade/5.3.x-to-5.4.0
>
>
>
> in most of these links, in the section "Database", I find only the subsection 
> "MySQL Database Structure", but I don't find the indications for DB 
> migrations for PostgreSQL Database.
>
> Only here https://www.kamailio.org/wiki/install/upgrade/5.2.x-to-5.3.0 I 
> found both the subsection "MySQL Database Structure" and "PostgreSQL Database 
> Structure".
>
>
>
> What does this mean?
>
> - that I'm getting lost in a glass of water?
> - or that I don't have to make any changes to PostgreSQL?
> - or that the queries to be launched on PostgreSQL are the same as those for 
> MySQL? I would discard this hypothesis
> - or that the wiki sections for PostgreSQL are missing? If this were the 
> case, I could proceed with the update and then share the queries I launched 
> to update the wiki.
>
>
>
> thanks a lot
>
> Giovanni Tommasini
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] [VoLTE] 401 unauthorized error

[Ovidiu Sas]

Probably the 401 didn’t make it to the client and what you are seeing are
retransmission.

-ovidiu

On Tue, Aug 24, 2021 at 11:54 오택경  wrote:

> I tried to use all of the algorithms which fhoss can support, but they did
> not work.
>
> Fortunately, I found that my UE did not send the digest response for the
> received nonce to the server after 401 unauthorized.
> (digest response content is empty in the 2nd register packet.)
>
> I think this is the cause of the authentication problem. So I changed to
> another smartphone, but the same problem has occurred.
>
>
>
> -Original Message-
> From: "Yuriy Gorlichenko" 
> To: "오택경" ;
> Cc: "Kamailio (SER) - Users Mailing List" ;
> Sent: 2021-08-24 (화) 21:37:36 (UTC+09:00)
> Subject: Re: Re: [SR-Users] [VoLTE] 401 unauthorized error
>
> I do not remember, to be honest, if IMS supports basic md5 auth
> algorithms. You need to go through specs about algo supported. Also try to
> look into docs of kamailio ims modules which algorithms it implements. If
> you find one which satisfies your device for negotiation then just use it.
> If no - try to update your client to have support of one of the proper
> algorithms.
>
> On Tue, 24 Aug 2021, 10:45 오택경,  wrote:
>
> Thank you for your help!
>
> I looked into the UE's  IMS register request as you told me. (the content
> of request is shown below)
>
> As my thinking, my UE can support only two algorithms: hmac-sha1-96 and
> hmac-md5-96.
>
> But fhoss cannot support above auth algorithms (fhoss can support
> digest-akav1-md5, digest-akav2-md5, digest, http_digest_md5,
> early-ims-security, nass-bundled and sip digest).
>
> What algorithm should I switch to for authentication in fhoss? Or do I
> have to change the UE device (smartphone) for auth?
>
> Very thanks,
> Taekkyung Oh.
>
> **
> *Frame 4153: 840 bytes on wire (6720 bits), 840 bytes captured (6720 bits)
> on interface 0*
> *Ethernet II, Src: 02:42:ac:16:00:16 (02:42:ac:16:00:16), Dst:
> 02:42:ac:16:00:06 (02:42:ac:16:00:06)*
> *Internet Protocol Version 4, Src: 172.22.0.22, Dst: 172.22.0.6*
> *User Datagram Protocol, Src Port: 2152, Dst Port: 2152*
> *GPRS Tunneling Protocol*
> *Internet Protocol Version 4, Src: 192.168.101.3, Dst: 172.22.0.21*
> *Transmission Control Protocol, Src Port: 5060, Dst Port: 5060, Seq: 1021,
> Ack: 1, Len: 750*
> *[2 Reassembled TCP Segments (1770 bytes): #4147(1020), #4153(750)]*
> *Session Initiation Protocol (REGISTER)*
> *Request-Line: REGISTER sip:ims.mnc001.mcc001.3gppnetwork.org
>  SIP/2.0*
> *Method: REGISTER*
> *Request-URI: sip:ims.mnc001.mcc001.3gppnetwork.org
> *
> *Request-URI Host Part: ims.mnc001.mcc001.3gppnetwork.org
> *
> *[Resent Packet: False]*
> *Message Header*
> *To:  >*
> *SIP to address:
> sip:00101031...@ims.mnc001.mcc001.3gppnetwork.org
> *
> *SIP to address User Part: 00101031094*
> *SIP to address Host Part:
> ims.mnc001.mcc001.3gppnetwork.org
> *
> *From:  >;tag=qyecbkJ*
> *SIP from address:
> sip:00101031...@ims.mnc001.mcc001.3gppnetwork.org
> *
> *SIP from address User Part: 00101031094*
> *SIP from address Host Part:
> ims.mnc001.mcc001.3gppnetwork.org
> *
> *SIP from tag: qyecbkJ*
> *Contact:  >;+sip.instance="";+g.3gpp.accesstype="cellular2";audio;video;+g.3gpp.smsip;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"*
> *Contact URI: sip:00101031094@192.168.101.3:5060
> *
> *Contact URI User Part: 00101031094*
> *Contact URI Host Part: 192.168.101.3*
> *Contact URI Host Port: 5060*
> *Contact parameter:
> +sip.instance=""*
> *Contact parameter: +g.3gpp.accesstype="cellular2"*
> *Contact parameter: audio*
> *Contact parameter: video*
> *Contact parameter: +g.3gpp.smsip*
> *Contact parameter:
> +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n*
> *Expires: 60*
> *P-Access-Network-Info:
> 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0010100010019B01*
> *access-type: 3GPP-E-UTRAN-FDD*
> *utran-cell-id-3gpp: 0010100010019B01*
> *Supported: path,sec-agree*
> *Allow:
> INVITE,ACK,OPTIONS,BYE,CANCEL,UPDATE,PRACK,NOTIFY,MESSAGE,REFER*
> *Require: sec-agree*
> *Proxy-Require: sec-agree*
> * [truncated]Security-Client:
> 

Re: [SR-Users] Password for pi_framework.xml - Xhttp_pi module

[Ovidiu Sas]

Hello Abdirahman,

There’s no support for “defines” for the xhttp_pi file.

Regards,
Ovidiu Sas

On Tue, Jul 27, 2021 at 11:34 Abdirahman Osman 
wrote:

> Hello everyone,
>
> In the xhttp_pi file of pi_framework.xml,is there a way I can pass the
> password to the xhttp_pi module as a pre-processing define?
>
>   postgres://kamailiorw:kamailiorw@localhost
> /kamailiorw
>
> Thank you!
>
> Abdirahman
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Unable to establish TCP connection with Kamailio

[Ovidiu Sas]

Please check the links:
https://www.kamailio.org/wiki/cookbooks/devel/core#fork
https://www.kamailio.org/wiki/cookbooks/devel/core#log_stderror

Your issue was related to fork. The stderr setting was just for
convenience (log via syslog instead of polluting the terminal).
If the documentation is not clear, let us know and we will improve it.

-ovidiu

On Thu, Jun 17, 2021 at 6:02 PM Peter Manley  wrote:
>
> Hello Ovidiu,
>
>
>
> Interestingly, that fixed the problem. I can now continue to make progress.
>
>
>
> Why does not forking and/or logging to stderr cause this to happen?
>
>
>
> Thank you!
>
>
>
> Regards,
>
>
>
> Peter Manley
>
>
>
>
>
> Ovidiu Sas osas at voipembedded.com
> Thu Jun 17 23:05:14 CEST 2021
>
> Previous message (by thread): [SR-Users] Unable to establish TCP connection 
> with Kamailio
> Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>
> 
>
> It seems that you have fork set to no,
>
> Let kamailio fork and collect logs via syslog (not via stderror).
>
>
>
> -ovidiu
>
>
>
>
>
> On Thu, Jun 17, 2021 at 16:26 Peter Manley  wrote:
>
>
>
> > Hello,
>
> >
>
> >
>
> >
>
> > I’m running Kamailio Version 5.3.2 on Ubuntu 20.04. Here my build
>
> > information:
>
> >
>
> >
>
> >
>
> > version: kamailio 5.3.2 (x86_64/linux)
>
> >
>
> > flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>
> > DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
>
> > F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
>
> > USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
>
> > HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED
>
> >
>
> > ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024,
>
> > BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>
> >
>
> > poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>
> >
>
> > id: unknown
>
> >
>
> > compiled with gcc 9.2.1
>
> >
>
> >
>
> >
>
> > I have the following configuration set in my kamalio.cfg file:
>
> >
>
> >
>
> >
>
> > ##!define WITH_MYSQL
>
> >
>
> > ##!define WITH_AUTH
>
> >
>
> > ##!define WITH_USRLOCDB
>
> >
>
> > ##!define WITH_TLS
>
> >
>
> > ##!define WITH_HOMER
>
> >
>
> > ##!define WITH_WEBSOCKETS
>
> >
>
> > ##!define WITH_ANTIFLOOD
>
> >
>
> > ##!define WITH_IPV6
>
> >
>
> > ##!define WITH_BRIDGE_ON_FAIL
>
> >
>
> > ##!define WITH_LOCALHOST_WS
>
> >
>
> > ##!define WITH_LOCALHOST_SIP
>
> >
>
> >
>
> >
>
> > #!substdef "!MY_SIP_PORT!5060!g"
>
> >
>
> > #!substdef "!MY_SIPS_PORT!5061!g"
>
> >
>
> > #!substdef "!MY_WS_PORT!8088!g"
>
> >
>
> > #!substdef "!MY_WSS_PORT!8089!g"
>
> >
>
> >
>
> >
>
> > #!substdef "!MY_LOG_FACILITY!LOG_DAEMON!g"
>
> >
>
> >
>
> >
>
> > #!substdef "!MY_IP4_ADDR!172.16.0.57!g"
>
> >
>
> > #!substdef "!IP4_LOCALHOST!127.0.0.1!g"
>
> >
>
> > #!substdef "!MY_WS4_ADDR!tcp:MY_IP4_ADDR:MY_WS_PORT!g"
>
> >
>
> > #!substdef "!MY_WSS4_ADDR!tls:MY_IP4_ADDR:MY_WSS_PORT!g"
>
> >
>
> > #!substdef "!LOCALHOST_WS4_ADDR!tcp:IP4_LOCALHOST:MY_WS_PORT!g"
>
> >
>
> > #!substdef "!LOCALHOST_WSS4_ADDR!tls:IP4_LOCALHOST:MY_WSS_PORT!g"
>
> >
>
> >
>
> >
>
> > #!ifdef WITH_IPV6
>
> >
>
> > #!substdef "!MY_IP6_ADDR![fe80::d6e4:2f5f:e5b7:7dff]!g"
>
> >
>
> > #!substdef "!IP6_LOCALHOST![::1]!g"
>
> >
>
> > #!substdef "!MY_WS6_ADDR!tcp:MY_IP6_ADDR:MY_WS_PORT!g"
>
> >
>
> > #!substdef "!MY_WSS6_ADDR!tls:MY_IP6_ADDR:MY_WSS_PORT!g"
>
> >
>
> > #!substdef "!LOCALHOST_WS6_ADDR!tcp:IP6_LOCALHOST:MY_WS_PORT!g"
>
> >
>
> > #!substdef "!LOCALHOST_WSS6_ADDR!tls:IP6_LOCALHOST:MY_WSS_PORT!g"
>
> >
>
> > #!endif
>
> >
>
> >
>
> >
>
> > #!substdef "!MY_DOMAIN!rtpengine.kombea.io!g"
>
> >
>
> > debug=10 // debug level (cmd line: -dd)
>
> >
>
> > children=

Re: [SR-Users] handle_ruri_alias() and multiple aliases

[Ovidiu Sas]

You can adjust your script to use aliases only when needed. We want clean
and simple signalling.

-ovidiu

On Mon, May 31, 2021 at 15:05 Denys Pozniak  wrote:

> Thanks, Alex and Ovidiu,
>
> Yes, I agree that *set_contact_alias ()* should only be used once.
> The essence of the problem is that all external connections are processed
> as for NAT by default in my script.
>
> Is there any reason for improving the *handle_ruri_alias ()* function so
> that we can specify the ordinal number of the alias parameter?
>
>
> пн, 31 мая 2021 г. в 21:10, Ovidiu Sas :
>
>> If there are two proxies involved, only one should handle aliases (the
>> one that is communicating directly with the endpoint).
>> If a Contact has a private IP, but the request is coming from a proxy
>> that is in charge of NAT, then the Contact should not be altered. When
>> you route back in dialog requests, it is ok to have a private IP in
>> RURI and proper Route headers, The next SIP hop (the other proxy) will
>> take care of properly routing the request.
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Mon, May 31, 2021 at 1:53 PM Denys Pozniak 
>> wrote:
>> >
>> > Hello!
>> >
>> > I need help understanding how the handle_ruri_alias() function works.
>> > Call-flow: Upstream operator -> Kamailio Proxy -> Edpoint.
>> >
>> > The upstream operator in the initial SIP INVITE in the Contact field
>> sends us an alias parameter, in turn, our Kamailio Proxy adds its own too.
>> > The Contact after the Proxy looks something like this:
>> >
>> > Contact: > ;alias=10.0.0.115~5060~1;alias=3.3.3.3~5060~1>
>> >
>> > When the Endpoint sends us a SIP BYE, then the handle_ruri_alias()
>> absorbs not the last alias, but the first one, and this leads to the
>> incorrect formation of a $du.
>> > The RURI after the Proxy looks something like this:
>> >
>> > Request-Line: BYE sip:10.0.0.115:5060;alias=3.3.3.3~5060~1 SIP/2.0
>> >
>> > The first thing that comes to mind is a modification of the original
>> Contact field with storing it's within a dialogue ...
>> >
>> > Is it possible to elegantly solve this problem?
>> >
>> > --
>> >
>> > BR,
>> > Denys Pozniak
>> >
>> >
>> > __
>> > Kamailio - Users Mailing List - Non Commercial Discussions
>> >   * sr-users@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
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@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
>>
>
>
> --
>
> BR,
> Denys Pozniak
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] handle_ruri_alias() and multiple aliases

[Ovidiu Sas]

If there are two proxies involved, only one should handle aliases (the
one that is communicating directly with the endpoint).
If a Contact has a private IP, but the request is coming from a proxy
that is in charge of NAT, then the Contact should not be altered. When
you route back in dialog requests, it is ok to have a private IP in
RURI and proper Route headers, The next SIP hop (the other proxy) will
take care of properly routing the request.

Regards,
Ovidiu Sas

On Mon, May 31, 2021 at 1:53 PM Denys Pozniak  wrote:
>
> Hello!
>
> I need help understanding how the handle_ruri_alias() function works.
> Call-flow: Upstream operator -> Kamailio Proxy -> Edpoint.
>
> The upstream operator in the initial SIP INVITE in the Contact field sends us 
> an alias parameter, in turn, our Kamailio Proxy adds its own too.
> The Contact after the Proxy looks something like this:
>
> Contact: 
>
> When the Endpoint sends us a SIP BYE, then the handle_ruri_alias() absorbs 
> not the last alias, but the first one, and this leads to the incorrect 
> formation of a $du.
> The RURI after the Proxy looks something like this:
>
> Request-Line: BYE sip:10.0.0.115:5060;alias=3.3.3.3~5060~1 SIP/2.0
>
> The first thing that comes to mind is a modification of the original Contact 
> field with storing it's within a dialogue ...
>
> Is it possible to elegantly solve this problem?
>
> --
>
> BR,
> Denys Pozniak
>
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Collecting stats from Kamailio.cfg using Kamailio_exporter Prometheus

[Ovidiu Sas]

Hello Hisham,

Yes, you can. Here are the steps:
 1. load the jsonrpcs and jansson module,
 2. collect your data using the jsonrpc_exec() function,
 3. handle the data using the jansson methods,
 4. store the data in a new metric(s) using the prom_gauge_set() function.

Then let the prometheus scrape the metrics and use grafana to plot them.
Enjoy!

https://kamailio.org/docs/modules/devel/modules/jsonrpcs.html
https://kamailio.org/docs/modules/devel/modules/jansson.html

Regards,
Ovidiu Sas


On Wed, May 26, 2021 at 9:00 AM Hisham Ahmad Jan
 wrote:
>
> Hi Arsen,
> Thank you for the reply.
>
> Just a quick little question.
>
> Previously, I had installed NodeRed on my Kamamilio to show total calls. For 
> that, I also enabled a JSON RPC module which used to collect data and show it 
> on NodeRed. My question is, can I use kamailio_exporter to scrape data onto 
> Prometheus from the same JSON RPC script running for NodeRed? Or, do I need 
> to rewrite a new script/code for Kamailio_exporter to scrape data?
>
>
> Regards,
> Hisham Jan
> VoIP Engineer
>
> 0322-6398775
>
>
> On Tue, May 25, 2021 at 7:30 PM Arsen Semenov  wrote:
>>
>> Hi Hisham,
>>
>> Yes you can use it for monitoring total calls handled by kamailio.
>>
>> In kamailio you need to configure dialog module and make sure you run 
>> kamailio_exporter with dlg.stats_active enabled.
>>
>> On Tue, 25 May 2021 at 6:57 PM, Hisham Ahmad Jan 
>>  wrote:
>>>
>>> Hi,
>>>
>>> I'm using Kamailio version 5.3.7 with DISPATCHER module and I would like to 
>>> integrate my kamailio with a kamailio_exporter for monitoring using 
>>> Prometheus server.
>>>
>>> Is it possible to collect data such as the number of total calls (inbound, 
>>> outbound) and plot time-graphs using those stats?
>>> If so, what modules/functions would I need apart from the Dispatcher module 
>>> to be able to have efficient results?
>>>
>>> Any degree of help will be appreciated.
>>>
>>> Hisham Jan
>>> VoIP Engineer
>>>
>>> 0322-6398775
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>>   * sr-users@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
>>
>> --
>> Sent from Gmail Mobile
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@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
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@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



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@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

Re: [SR-Users] Can't make tcp_conid_alive work with $var

[Ovidiu Sas]

Try to convert to int using the {s.int} transformation.

Regards,
Ovidiu Sas

On Mon, May 3, 2021 at 5:41 PM David Villasmil
 wrote:
>
> Hello guys,
>
> I'm trying to do the following:
>
> On INVITE, i add a param to RR "wsconnid" which is the connection id of the 
> WS socket.
> Afterwards, i get an OPTIONS including said param.
>
> Next I want to retrieve the param and check if the connection is alive.
>
> NOTE: using simply "$(hdr(Route){param.value,wsconnid})" returns an extra ">" 
> from the end of the string, and i haven't been able to remove that any other 
> way but with "striptail", it works fine.
>
> ***
> $var(conid) = $(hdr(Route){param.value,wsconnid});
> $var(conid) = $(var(conid){s.striptail,1});
> xlog("L_ERR", "Connection ID parameter: [$var(conid)]");
> if (tcp_conid_alive("$var(conid)")) {
> xlog("L_ERR", "WS Connection ID $var(conid) is alive");
> } else {
> xlog("L_ERR", "WS Connection ID $var(conid) is NOT alive");
> }
> ***
>
> With that, "$var(conid)" contains the connection id properly:
> ***
> ERROR: 

Re: [SR-Users] possible bug on {param.value,name}

[Ovidiu Sas]

You should try something like this:
$var(wsconnid) = $(hdr(Route){nameaddr.uri}{uri.param,wsconnid})
First you need to extract the URI, and then the URI parameter.

The param.value transformation is expecting a true param list, not uri
or nameaddress.

Regards,
Ovidiu Sas

On Mon, May 3, 2021 at 3:29 PM David Villasmil
 wrote:
>
> Hello guys,
>
> I'm possible using this wrong, but here it is;
> I need to get a previously set parameter to rr, named "wsconnid":
>
> $var(wsconnid) = $(hdr(Route){param.value,wsconnid})
> xlog("L_ERR", "Connection ID parameter: $var(wsconnid)");
>
> And i'm getting:
>
> May  3 19:24:45 ip-10-231-32-37 /usr/sbin/kamailio[10015]: ERROR: 

Re: [SR-Users] Using sngrep for visualising encrypted SIP traffic

[Ovidiu Sas]

That's great!

Thank you,
Ovidiu

On Wed, Mar 24, 2021 at 10:09 AM Daniel-Constantin Mierla
 wrote:
>
> Hello,
>
> I also posted a news about it on kamailio website:
>
>   *
> https://www.kamailio.org/w/2021/03/troubleshooting-kamailio-encrypted-sip-traffic/
>
> Thanks for sharing,
> Daniel
>
> On 24.03.21 13:39, Ovidiu Sas wrote:
> > Hello Sergey,
> >
> > Glad that you find it interesting!
> >
> > -ovidiu
> >
> > On Wed, Mar 24, 2021 at 4:42 AM Sergey Safarov  wrote:
> >> Thanks, Ovidiu for link
> >> very interesting for me.
> >>
> >> On Wed, Mar 24, 2021 at 4:40 AM Ovidiu Sas  wrote:
> >>> Hello all,
> >>>
> >>> Here's a quick recipe to ease the troubleshooting of encrypted SIP 
> >>> traffic:
> >>> https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encrypted-sip-traffic/
> >>>
> >>> Regards,
> >>> Ovidiu Sas
> >>>
> >>> --
> >>> VoIP Embedded, Inc.
> >>> http://www.voipembedded.com
> >>>
> >>> ___
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users@lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >> ___
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>


-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Using sngrep for visualising encrypted SIP traffic

[Ovidiu Sas]

Hello Sergey,

Glad that you find it interesting!

-ovidiu

On Wed, Mar 24, 2021 at 4:42 AM Sergey Safarov  wrote:
>
> Thanks, Ovidiu for link
> very interesting for me.
>
> On Wed, Mar 24, 2021 at 4:40 AM Ovidiu Sas  wrote:
>>
>> Hello all,
>>
>> Here's a quick recipe to ease the troubleshooting of encrypted SIP traffic:
>> https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encrypted-sip-traffic/
>>
>> Regards,
>> Ovidiu Sas
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Using sngrep for visualising encrypted SIP traffic

[Ovidiu Sas]

Hello all,

Here's a quick recipe to ease the troubleshooting of encrypted SIP traffic:
https://voipembedded.wordpress.com/2021/03/22/troubleshooting-kamailio-encrypted-sip-traffic/

Regards,
Ovidiu Sas

-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Segmentation fault on debian 10

[Ovidiu Sas]

Follow the tutorial:
https://kamailio.org/wiki/tutorials/troubleshooting/coredumpfile

Regards,
Ovidiu Sas

On Wed, Mar 3, 2021 at 11:47 AM Bugaian A. Vitalie  wrote:
>
> Hello,
>
> fresh install on debian 10:
>
> Mar  3 11:42:16 teams01 kernel: [ 5771.292626] kamailio[1518]: segfault at 0 
> ip 7f102bb5c206 sp 7ffec00096e8 error 4 in 
> libc-2.28.so[7f102bae6000+148000]
> Mar  3 11:42:16 teams01 kernel: [ 5771.292677] Code: 0f 1f 40 00 66 0f ef c0 
> 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 
> 81 f9 cf 0f 00 00 77 6a  0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f 
> bc c2 c3 48 83
>
> Any things to try?
>
> Thanks.
>
> Vitalie.
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Profile name as variable in set_dlg_profile

[Ovidiu Sas]

Hello Alex,

More or less, the same thing would apply to "profiles_no_value" with
variable support.
There is a need for a dynamic way to store those dynamic profiles.
Maybe we need to add a parameter to control the size of the profile hash table.

-ovidiu

On Mon, Jan 11, 2021 at 2:03 PM Alex Balashov  wrote:
>
> Ovidiu,
>
> See my previously expressed concern about data structures underneath.
>
> —
> Sent from my iPad
>
> > On Jan 11, 2021, at 1:57 PM, Ovidiu Sas  wrote:
> >
> > Having support for variables for "profiles_no_value" would be more or
> > less the same thing as having a "profiles_with_value" with a key
> > "general" or "default".
> > The gain for adding this functionality would be minimal.
> >
> > Regards,
> > Ovidiu Sas
> >
> >> On Mon, Jan 11, 2021 at 1:45 PM Muhammad Sohaib  
> >> wrote:
> >>
> >> Thank you Daniel for the explanation.
> >>
> >> I managed to achieve the goal by "profiles_with_value" parameter and 
> >> passed "$rU" but each user might have multiple numbers so I had to  
> >> get_profile_size for each number.
> >>
> >> However, adding support for variables would be a great help.
> >>
> >> I will give a try to the KSA module later.
> >>
> >>> On Mon, 11 Jan 2021 at 14:56, Daniel-Constantin Mierla 
> >>>  wrote:
> >>>
> >>> Hello,
> >>>
> >>> I haven't checked the code, but I think that the function was designed 
> >>> with static parameter to be able to lookup the profile structure at 
> >>> startup and keep the pointer to it in order to be faster at runtime.
> >>>
> >>> Adding support for variables is possible of course, it would require a 
> >>> bit of c development.
> >>>
> >>> At this moment you can use embedded scripting (e.g., Lua, Python, 
> >>> JavaScript, ... see app_lua, ...) and execute functions via KSR module, 
> >>> i.e.,:
> >>>
> >>>  - 
> >>> http://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/modules/#ksrdialogset_dlg_profile
> >>>
> >>> Cheers,
> >>> Daniel
> >>>
> >>>> On 08.01.21 07:44, Muhammad Sohaib wrote:
> >>>
> >>> Is it possible to insert the current dialog into the profile by using the 
> >>> following way?
> >>>
> >>> modparam("dialog", "profiles_no_value", "mytest;xyz")
> >>>
> >>> $var(profilename)="xyz";
> >>> set_dlg_profile(" $var(profilename) ");
> >>>
> >>> Currently it is giving errors and not allowing to use variable instead of 
> >>> static profile name.
> >>>
> >>> Or is there any alternative to pass profile name as variable?
> >>>
> >>> ---
> >>> Thanks,
> >>>
> >>> ___
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users@lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>>
> >>> --
> >>> Daniel-Constantin Mierla -- www.asipto.com
> >>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> >>> Funding: https://www.paypal.me/dcmierla
> >>
> >>
> >>
> >> --
> >> Thanks,
> >> ___
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> >
> > --
> > VoIP Embedded, Inc.
> > http://www.voipembedded.com
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Profile name as variable in set_dlg_profile

[Ovidiu Sas]

Having support for variables for "profiles_no_value" would be more or
less the same thing as having a "profiles_with_value" with a key
"general" or "default".
The gain for adding this functionality would be minimal.

Regards,
Ovidiu Sas

On Mon, Jan 11, 2021 at 1:45 PM Muhammad Sohaib  wrote:
>
> Thank you Daniel for the explanation.
>
> I managed to achieve the goal by "profiles_with_value" parameter and passed 
> "$rU" but each user might have multiple numbers so I had to  get_profile_size 
> for each number.
>
> However, adding support for variables would be a great help.
>
> I will give a try to the KSA module later.
>
> On Mon, 11 Jan 2021 at 14:56, Daniel-Constantin Mierla  
> wrote:
>>
>> Hello,
>>
>> I haven't checked the code, but I think that the function was designed with 
>> static parameter to be able to lookup the profile structure at startup and 
>> keep the pointer to it in order to be faster at runtime.
>>
>> Adding support for variables is possible of course, it would require a bit 
>> of c development.
>>
>> At this moment you can use embedded scripting (e.g., Lua, Python, 
>> JavaScript, ... see app_lua, ...) and execute functions via KSR module, 
>> i.e.,:
>>
>>   - 
>> http://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/modules/#ksrdialogset_dlg_profile
>>
>> Cheers,
>> Daniel
>>
>> On 08.01.21 07:44, Muhammad Sohaib wrote:
>>
>> Is it possible to insert the current dialog into the profile by using the 
>> following way?
>>
>> modparam("dialog", "profiles_no_value", "mytest;xyz")
>>
>> $var(profilename)="xyz";
>> set_dlg_profile(" $var(profilename) ");
>>
>> Currently it is giving errors and not allowing to use variable instead of 
>> static profile name.
>>
>> Or is there any alternative to pass profile name as variable?
>>
>> ---
>> Thanks,
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Funding: https://www.paypal.me/dcmierla
>
>
>
> --
> Thanks,
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] loose_route() - Local Proxy

[Ovidiu Sas]

That parameter shouldn't really exist. It should be enabled by default
in the code.
This issue came a few times on the mailing list.

Regards,
Ovidiu

On Thu, Jan 7, 2021 at 11:15 AM Duarte Rocha  wrote:
>
> Hi,
>
> Thank you for your answers.
>
> The domain parameter "register_myself" solved this issue immediately.
>
> Cheers
>
> Duarte Rocha  escreveu no dia segunda, 4/01/2021 
> à(s) 14:46:
>>
>> Greetings,
>>
>> I'm using loose_route() from the RR module and i'm having troubles making it 
>> use the following exception from the code : "There is only one exception: If 
>> the request is out-of-dialog (no to-tag) and there is only one Route: header 
>> indicating the local proxy, then the Route: header is removed and the 
>> function returns FALSE."
>>
>> My example is a REGISTER without To-TAG which has a Route header with 
>> kamailio address. If i use proxy IP on Route header , loose_route() returns 
>> false as it should. However, if i use an hostname belonging to the proxy  in 
>> the route, loose_route() returns true.
>>
>> I have hostnames and local ips defined in the "DOMAIN" table but it doesn't 
>> seem to be working. Which other places can local hostnames and ips be 
>> configured in order to be seen as local to loose_route() ?
>>
>> Best Regards
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problems establishing SIP signaling between MsTeams and Kamailio

[Ovidiu Sas]

That certificate should already be present under the OS's trusted
certificates directory (debian and ubuntu certs are stored under
/etc/ssl/certs), maybe under a different name, and is required for
remote endpoint's certificate validation.
One can load a particular certificate or a list of certificates.
Multiple certificates can be concatenated into one single file as
stated in the documentation:
https://kamailio.org/docs/modules/devel/modules/tls.html#tls.p.ca_list
Hope this helps a little bit in understanding of the ca_list param.

Regards,
Ovidiu Sas

On Thu, Jan 7, 2021 at 8:10 AM  wrote:
>
> I Used this tls.cfg
>
>
>
> Use bc2025.pem as extra, Microsoft needs this…
>
>
>
> And works fine on different Kamailio-msteams sbcs
>
>
>
>
>
> [server:default]
>
> method = TLSv1.2+
>
> verify_certificate = yes
>
> require_certificate = yes
>
> private_key = /etc/letsencrypt/live/sbc.combivoipdom.nl-0001/privkey.pem
>
> certificate = /etc/letsencrypt/live/sbc.combivoipdom.nl-0001/fullchain.pem
>
> ca_list = /etc/letsencrypt/live/sbc.combivoipdom.nl-0001/bc2025.pem
>
> server_name = sbc.combivoipdom.nl
>
>
>
> [client:default]
>
> method = TLSv1.2+
>
> verify_certificate = yes
>
> require_certificate = yes
>
> private_key = /etc/letsencrypt/live/sbc.combivoipdom.nl-0001/privkey.pem
>
> certificate = /etc/letsencrypt/live/sbc.combivoipdom.nl-0001/fullchain.pem
>
> ca_list = /etc/letsencrypt/live/sbc.combivoipdom.nl-0001/bc2025.pem
>
>
>
>
>
>
>
> Cheers Rob
>
>
>
> Van: sr-users  Namens Daniel-Constantin 
> Mierla
> Verzonden: donderdag 7 januari 2021 08:53
> Aan: Kamailio (SER) - Users Mailing List ; Willy 
> Valles Rios 
> CC: Carlos Mestanza T. 
> Onderwerp: Re: [SR-Users] Problems establishing SIP signaling between MsTeams 
> and Kamailio
>
>
>
> Does this happen when Kamailio connects to MS Teams? The logs indicate the 
> received TLS certificate is not trusted:
>
> Jan 6 15:13:55 Kamailio-Server /usr/sbin/kamailio[32425]: ERROR: tls 
> [tls_util.h:42]: tls_err_ret(): TLS write:error:14090086:SSL 
> routines:ssl3_get_server_certificate:certificate verify failed
>
>
>
> You can set debug=3 in kamailio.cfg and see if the DEBUG messages provide 
> more hints. For me it worked fine with Letsencrypt certs in Kamailio and 
> accepting what ever MS sent back. I used Debian 10 and libssl 1.1.
>
>
>
> Cheers,
> Daniel
>
>
>
> On 06.01.21 21:47, Willy Valles Rios wrote:
>
> Hello community,
>
>
>
> I am having trouble establishing SIP signaling between MsTeams and Kamailio. 
> I currently have this configuration in my tls.cfg file
>
>
>
> [server: default]
>
> method = TLSv1.2 +
>
> verify_certificate = yes
>
> require_certificate = yes
>
> private_key = /etc/kamailio/certificates/private-key.pem
>
> certificate = /etc/kamailio/certificates/certificate.pem
>
>
>
> [client: default]
>
> method = TLSv1.2 +
>
> verify_certificate = yes
>
> require_certificate = yes
>
> private_key = /etc/kamailio/certificates/private-key.pem
>
> certificate = /etc/kamailio/certificates/certificate.pem
>
>
>
> My domain was certified with ssl through an authoritative certifier 
> (GoDaddy), however I see these errors in the / var / log / messages of the 
> Kamailio server.
>
>
>
> Jan 6 15:13:45 Kamailio-Server /usr/sbin/kamailio[32409]: INFO: tls 
> [tls_mod.c:389]: mod_init(): With ECDH-Support!
>
> Jan 6 15:13:45 Kamailio-Server /usr/sbin/kamailio[32409]: INFO: tls 
> [tls_mod.c:392]: mod_init(): With Diffie Hellman
>
> Jan 6 15:13:45 Kamailio-Server /usr/sbin/kamailio[32409]: INFO: tls 
> [tls_init.c:722]: tls_h_mod_init_f(): compiled with openssl version "OpenSSL 
> 1.0.2k-fips 26 Jan 2017" (0x100020bf), kerberos support: on, compression: on
>
> Jan 6 15:13:45 Kamailio-Server /usr/sbin/kamailio[32409]: INFO: tls 
> [tls_init.c:730]: tls_h_mod_init_f(): installed openssl library version 
> "OpenSSL 1.0.2k-fips 26 Jan 2017" (0x100020bf), kerberos support: on, zlib 
> compression: on#012 compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC 
> -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT 
> -m64 -DL_ENDIAN -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 
> -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM 
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM 
> -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
>

Re: [SR-Users] NAT problem with recvonly calls

[Ovidiu Sas]

The doorbell is the caller. ICE support would be required on the
callee side (between NATed callee and asterisk).
There's no need for ICE support on the doorbell/caller side.

-ovidiu

On Wed, Dec 9, 2020 at 2:42 AM Alex Balashov  wrote:
>
> ICE support just doesn't seem to me to be something a SIP doorbell would
> have.
>
> On 12/9/20 2:39 AM, Olle E. Johansson wrote:
> >
> >
> >> On 8 Dec 2020, at 18:55, Richard Fuchs  >> > wrote:
> >>
> >> Use IPv6
> >
> > While I like that proposal, assuming that IPv6 will not have a stateful
> > firewall is propably not a good assumption.
> > So I suspect that an IPv6 firewall would not let the packets in if there
> > is not outbound traffic first. I do like Ovidius
> > ICE-based solution and would like to add RTCP - if muxed it would open
> > the port, but the likelyhood that it’s
> > implemented is propably low.
> >
> > IPv6 greetings!
> > /O :-)
> >>
> >> Cheers
> >>
> >> On 07/12/2020 23.01, David Cunningham wrote:
> >>> Hello,
> >>>
> >>> We have a problem with a SIP doorbell device which sends media one
> >>> way only, and NAT at the receiving device.
> >>>
> >>> When the doorbell button is pressed it makes a call to a configured
> >>> destination. Since the doorbell only sends and doesn't receive it
> >>> sends the INVITE with sendonly in the SDP, and the destination then
> >>> replies with a 200 OK with recvonly in the SDP. The problem is that
> >>> the destination is behind NAT, and its reply contains a private
> >>> network IP in the SDP.
> >>>
> >>> Normally Asterisk when nat=yes works around that by adjusting the
> >>> destination for RTP to be the address it actually receives audio
> >>> from, however because this device is recvonly Asterisk never receives
> >>> audio from it. This means Asterisk keeps trying to send the
> >>> doorbell's RTP to the private network IP which of course fails, and
> >>> the destination never gets the RTP from the doorbell.
> >>>
> >>> We haven't found a solution in Asterisk to this, so are now looking
> >>> to Kamailio which acts as a load-balancing proxy in front of Asterisk
> >>> for one. For example, maybe we could use fix_nated_sdp, but only on
> >>> 200 OK's with recvonly.
> >>>
> >>> Has anyone else encountered this, and are there any recommended
> >>> solutions?
> >>>
> >>> Thank you in advance!
> >>>
> >>> --
> >>> David Cunningham, Voisonics Limited
> >>> http://voisonics.com/ 
> >>> USA: +1 213 221 1092
> >>> New Zealand: +64 (0)28 2558 3782
> >>>
> >>> ___
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users@lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >> ___
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org 
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

[Ovidiu Sas]

Hello David,

If the receiving NATed device has support for ICE, you can enable ICE
support on the asterisk server and then the media should flow through
(NAT pinholes are opened during ICE candidates negotiation).

Regards,
Ovidiu Sas

On Mon, Dec 7, 2020 at 11:02 PM David Cunningham
 wrote:
>
> Hello,
>
> We have a problem with a SIP doorbell device which sends media one way only, 
> and NAT at the receiving device.
>
> When the doorbell button is pressed it makes a call to a configured 
> destination. Since the doorbell only sends and doesn't receive it sends the 
> INVITE with sendonly in the SDP, and the destination then replies with a 200 
> OK with recvonly in the SDP. The problem is that the destination is behind 
> NAT, and its reply contains a private network IP in the SDP.
>
> Normally Asterisk when nat=yes works around that by adjusting the destination 
> for RTP to be the address it actually receives audio from, however because 
> this device is recvonly Asterisk never receives audio from it. This means 
> Asterisk keeps trying to send the doorbell's RTP to the private network IP 
> which of course fails, and the destination never gets the RTP from the 
> doorbell.
>
> We haven't found a solution in Asterisk to this, so are now looking to 
> Kamailio which acts as a load-balancing proxy in front of Asterisk for one. 
> For example, maybe we could use fix_nated_sdp, but only on 200 OK's with 
> recvonly.
>
> Has anyone else encountered this, and are there any recommended solutions?
>
> Thank you in advance!
>
> --
> David Cunningham, Voisonics Limited
> http://voisonics.com/
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] ERROR: [core/socket_info.c:2225]: parse_protohostport():

[Ovidiu Sas]

It could be! It is for anything that is using proto:ip:port format.
It is used by "listen" and by "alias".
Also, there are some module params that require this format.

-ovidiu

On Tue, Oct 20, 2020 at 12:24 PM Andy Kama  wrote:
>
> Is this for listen:
>
> ?
>
> On Tuesday, October 20, 2020, Ovidiu Sas  wrote:
>>
>> You should use yourproto:yourip:yourport
>> yourproto could be udp|tcp|tls
>>
>> -ovidiu
>>
>> On Tue, Oct 20, 2020 at 12:07 PM Andy Kama  wrote:
>> >
>> > I am seeing this error in the logs
>> >
>> > i am using kamailio 5.4.1
>> > any idea what the cause is?
>> >
>> >
>> > ERROR:  [core/socket_info.c:2225]: parse_protohostport(): bad 
>> > protocol in sip:myp:5060
>> > ___
>> > Kamailio (SER) - Users Mailing List
>> > sr-users@lists.kamailio.org
>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] ERROR: [core/socket_info.c:2225]: parse_protohostport():

[Ovidiu Sas]

You should use yourproto:yourip:yourport
yourproto could be udp|tcp|tls

-ovidiu

On Tue, Oct 20, 2020 at 12:07 PM Andy Kama  wrote:
>
> I am seeing this error in the logs
>
> i am using kamailio 5.4.1
> any idea what the cause is?
>
>
> ERROR:  [core/socket_info.c:2225]: parse_protohostport(): bad protocol 
> in sip:myp:5060
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] usrloc_dmq - Suddenly stopped usrloc replication

[Ovidiu Sas]

Maybe you restarted with a different config file?

-ovidiu

On Fri, Oct 16, 2020 at 04:54 José Seabra  wrote:

> Hi Ovidiu,
>
> I compared both logs and when kamailio didn't started all processes, there
> is missing the log msg from usrloc_dmq:
>
> INFO: dmq_usrloc [dmq_usrloc.c:77]: mod_init(): dmq usrloc replication mode = 
> 1
>
>
> But I still have doubts why it happened, do you guys know any possible
> reason that could make this happening?
>
> Thank you
>
> Best regards
> José
>
> Ovidiu Sas  escreveu no dia quinta, 15/10/2020
> à(s) 23:18:
>
>> Compare the logs for the two cases. Also, check if there are any error
>> logs for the case with missing processes.
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Thu, Oct 15, 2020 at 5:51 PM José Seabra 
>> wrote:
>> >
>> > Hi there,
>> > so, I guess that I found the reason why it's not working, I noticed
>> that it stopped working at the same time that kamailio restarted, then I
>> went check the number of processes and workers and I realised that we were
>> missing a few processes and workers, restarted kamailio and it started
>> working again, all processes and workers were created.
>> > Anyway I still don't know why the restart didn't start all the
>> processes.
>> >
>> > Regards
>> >
>> > José Seabra  escreveu no dia quinta, 15/10/2020
>> à(s) 22:12:
>> >>
>> >> Hello there,
>> >> I forgot to mention that I'm running kamailio 5.3.4
>> >>
>> >> Best Regards
>> >>
>> >> José Seabra  escreveu no dia quinta,
>> 15/10/2020 à(s) 22:11:
>> >>>
>> >>> Hello there,
>> >>>
>> >>> Suddenly the usrloc replication through DMQ stopped, but the
>> interesting thing is that DMQ cluster status is OK, htable replication
>> still working only usrloc_dmq stopped working.
>> >>>
>> >>> I increased the kamailio loglevel to 3 in order to see if there was
>> some log related and then registered a peer, but the only DMQ logs that I
>> see are related with notification_peer and htable replication, nothing
>> related with usrloc_dmq.
>> >>>
>> >>> What I can do more here to try to understand what went wrong?
>> >>>
>> >>> I haven't restarted the cluster yet, because I would like to try to
>> understand the root cause of this issue.
>> >>>
>> >>> Any advice would be appreciated
>> >>>
>> >>> Thank you
>> >>>
>> >>> --
>> >>> Cumprimentos
>> >>> José Seabra
>> >>
>> >>
>> >>
>> >> --
>> >> Cumprimentos
>> >> José Seabra
>> >
>> >
>> >
>> > --
>> > Cumprimentos
>> > José Seabra
>> > ___
>> > Kamailio (SER) - Users Mailing List
>> > sr-users@lists.kamailio.org
>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Cumprimentos
> José Seabra
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] usrloc_dmq - Suddenly stopped usrloc replication

[Ovidiu Sas]

Compare the logs for the two cases. Also, check if there are any error
logs for the case with missing processes.

Regards,
Ovidiu Sas

On Thu, Oct 15, 2020 at 5:51 PM José Seabra  wrote:
>
> Hi there,
> so, I guess that I found the reason why it's not working, I noticed that it 
> stopped working at the same time that kamailio restarted, then I went check 
> the number of processes and workers and I realised that we were missing a few 
> processes and workers, restarted kamailio and it started working again, all 
> processes and workers were created.
> Anyway I still don't know why the restart didn't start all the processes.
>
> Regards
>
> José Seabra  escreveu no dia quinta, 15/10/2020 à(s) 
> 22:12:
>>
>> Hello there,
>> I forgot to mention that I'm running kamailio 5.3.4
>>
>> Best Regards
>>
>> José Seabra  escreveu no dia quinta, 15/10/2020 à(s) 
>> 22:11:
>>>
>>> Hello there,
>>>
>>> Suddenly the usrloc replication through DMQ stopped, but the interesting 
>>> thing is that DMQ cluster status is OK, htable replication still working 
>>> only usrloc_dmq stopped working.
>>>
>>> I increased the kamailio loglevel to 3 in order to see if there was some 
>>> log related and then registered a peer, but the only DMQ logs that I see 
>>> are related with notification_peer and htable replication, nothing related 
>>> with usrloc_dmq.
>>>
>>> What I can do more here to try to understand what went wrong?
>>>
>>> I haven't restarted the cluster yet, because I would like to try to 
>>> understand the root cause of this issue.
>>>
>>> Any advice would be appreciated
>>>
>>> Thank you
>>>
>>> --
>>> Cumprimentos
>>> José Seabra
>>
>>
>>
>> --
>> Cumprimentos
>> José Seabra
>
>
>
> --
> Cumprimentos
> José Seabra
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Setting up Kamailio IMS

[Ovidiu Sas]

Hello Luke,

A simple web search on "kamailio ms teams" will lead you to this link:
https://www.kamailio.org/w/2019/10/using-kamailio-as-sbc-for-microsoft-teams/
>From which you can navigate to this link:
https://skalatan.de/en/blog/kamailio-sbc-teams

Regards,
Ovidiu Sas

On Sun, Sep 27, 2020 at 5:54 AM luke devon  wrote:
>
> Hi Team,
>
> Can somebody share a guide to setup Kamailio IMS in ubuntu or centos, please?
>
> Thanks
> Luke
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio Buildroot

[Ovidiu Sas]

I haven't cross compiled in a long time ...
For proper cross-compilation, the CROSS_COMPILE flag must be set to
something, then the LOCALBASE and SYSBASE should point to the staging
directory where the toolchain and all the libraries and include files
for the target platform are present.
Extra compile and link options can be passed via CC_EXTRA_OPTS and
LD_EXTRA_OPTS.

An old example for optware can be found here:
https://raw.githubusercontent.com/nslu2-linux/Optware/master/make/kamailio.mk

Some modules have a proper Makefile that will use the pkg-config from
staging directory and detect proper compile and link flags while other
modules require manual tinkering with the Makefile.
It's good to enable the noisy build (Q=0) and check that proper
include files and libs are used (from the staging directory and not
from the build machine).

Regards,
Ovidiu Sas

On Wed, Jun 24, 2020 at 4:52 AM Daniel-Constantin Mierla
 wrote:
>
> Hello,
>
> I haven't cross compiled myself, but there is a makefile flag CROSS_COMPILE 
> that you can set in such cases -- the Makefile of the modules sets the path 
> to includes and libs based on it. You may need to set other Makefile 
> variables to get it done, look in the src/Makefile.defs to see most of them.
>
> Ovidiu Sas seemed to be active in this space some time ago, maybe he can give 
> further guidelines.
>
> Cheers,
> Daniel
>
> On 19.06.20 14:11, Benjamin Marty wrote:
>
> Hello
>
> I would like to ask if someone already tried to build Kamailio for the 
> Embedded Distribution Buildroot. I tried it myself but it looks like Kamailio 
> is not that easy to cross compile.
>
> Thanks
>
> Benjamin
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] how to use get my domain name in VIA header (INVITE) instead of IP address.

[Ovidiu Sas]

There’s no need for FQDNs in Via headers for MS. IPs work just fine!
You need FQDNs only in Route/Record-Route headers.

Regards,
Ovidiu Sas

On Sat, Apr 25, 2020 at 13:08 Yuriy Nasida  wrote:

> Comrade :)
>
> Thanks for the advices! I will try them.
>
> And yes, that is for inbound calls to MS teams. We just got outbound calls
> working by the way (had to do a lot of kamailio tweaks honestly).
> As for inbound calls to MS - I just looking at their docs
> (picute attached). Looks like MS expect domain name in VIA.
> I have all other sip headers like they want, but MS still ignore our
> INVITEs. That is why I think how to change VIA.
>
> If you have example of INVITE to MS teams that is working - that can help
> a lot.
>
>
> [image: image_2020-04-24_08-26-25.png]
>
> On Sat, 25 Apr 2020 at 18:37, Sergiu Pojoga  wrote:
>
>> Yuriy,
>>
>> The 'advertise' parameter doesn't support vars. (
>> https://github.com/kamailio/kamailio/issues/2137)
>>
>> As an alternative, you could use a combination of xavps and corex module
>> function via_use_xavp_fields() -- see:
>>
>> https://www.kamailio.org/wiki/cookbooks/5.3.x/core#xavp_via_fields
>>
>> If you're building this for what I think you are, most likely you think
>> you need this - but you actually don't. Or may be I'm wrong and your
>> specifics do require it.
>>
>> Good luck comrade.
>>
>> On Sat, Apr 25, 2020 at 9:41 AM Nasida Yuriy  wrote:
>>
>>> Thanks for the answer Sergiu, but this shoud not be static domain name.
>>> I need to have different domains in Via for different calls.
>>> Is it possible ?
>>> --
>>> *От:* sr-users  от имени Sergiu
>>> Pojoga 
>>> *Отправлено:* 24 апреля 2020 г. 21:35
>>> *Кому:* Kamailio (SER) - Users Mailing List >> >
>>> *Тема:* Re: [SR-Users] how to use get my domain name in VIA header
>>> (INVITE) instead of IP address.
>>>
>>> Most common way is by using `advertise`  in the `listen` directive.
>>>
>>> https://www.kamailio.org/wiki/cookbooks/5.3.x/core#listen
>>>
>>> On Fri, Apr 24, 2020 at 2:19 PM Nasida Yuriy  wrote:
>>>
>>>
>>> Hi guys,
>>>
>>> It sounds simple but I can not get  domain name in VIA header (INVITE)
>>> instead of IP address.
>>>
>>> It is just
>>>
>>> FS ---INVITE --> Kamailio --INVITE--> endpoint
>>>
>>> Kamailio gets INVITE, and adds one more VIA with it's IP address. How to
>>> get domain name instead ?
>>>
>>> Please advice.
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio like SBC with Teams

[Ovidiu Sas]

The tutorial is pretty clear:
You need to add the Contact header only for OPTIONS pings.
You need to use the proper Record-Route headers based on the direction
of the call.
There's no out of the box solution because each setup is different.

If you understand how loose routing works in SIP, then you know how to
adjust the config to use record_route_preset(), just as explained in
the tutorial. There is also an example of an INVITE that has the right
Record-Route headers in the tutorial.

You can choose to use the FQDN for the Record-Route header facing MS
and the IP for the Record-Route header facing the carrier or use the
FQDN for both Record-Route headers (just like in the tutorialexample).
Alternatively, one can try to advertise the FQDN in the listen
directive in the config and then the Record-Route headers should be
populated automatically.

Regards,
Ovidiu Sas

On Thu, Apr 16, 2020 at 10:50 AM sip user  wrote:
>
> Hi Nasida.. Thanks for answerd to me...
>
> I've activarted the debugger module, and I see the same:
>
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [ip_addr.c:243]: print_ip(): tcpconn_new: new tcp connection: 52.114.7.24
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [tcp_main.c:1073]: tcpconn_new(): tcpconn_new: on port 4160, type 3
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [tcp_main.c:1382]: tcpconn_add(): tcpconn_add: hashes: 171:1857:1187, 30
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa1f240, 23, 2, 
> 0x7f90f2438f80), fd_no=17
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0xa1f240, 23, -1, 0x0) 
> fd_no=18 called
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [tcp_main.c:4219]: handle_tcpconn_ev(): tcp: DBG: sending to child, events 1
> Apr 15 11:11:41 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [tcp_main.c:3902]: send2child(): selected tcp worker 1 10(23159) for activity 
> on [tls:SBC_IP:5061], 0x7f90f2438f80
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_read.c:1507]: handle_io(): received n=8 con=0x7f90f2438f80, fd=9
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls 
> [tls_server.c:184]: tls_complete_init(): Using TLS domain TLSs
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG: tls 
> [tls_domain.c:700]: sr_ssl_ctx_info_callback(): SSL handshake started
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending...
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 
> 0x7f90f2438f80 n=1468 fd=9
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=
> Apr 15 11:11:41 vps793907 kamailio[23122]: #026#003#003
> Apr 15 11:11:41 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0x9c1700, 9, 2, 
> 0x7f90f2438f80), fd_no=1
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_read.c:296]: tcp_read_data(): EOF on 0x7f90f2438f80, FD 9
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_read.c:1291]: tcp_read_req(): tcp_read_req: EOF
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [io_wait.h:610]: io_watch_del(): DBG: io_watch_del (0x9c1700, 9, -1, 0x10) 
> fd_no=2 called
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_read.c:1434]: release_tcpconn(): releasing con 0x7f90f2438f80, state -1, 
> fd=9, id=30
> Apr 15 11:11:42 vps793907 kamailio[23122]: 10(23159) DEBUG:  
> [tcp_read.c:1435]: release_tcpconn():  extra_data 0x7f90f2432b40
> Apr 15 11:11:42 vps793907 kamailio[23122]: 13(23167) DEBUG:  
> [tcp_main.c:3331]: handle_tcp_child(): handle_tcp_child: reader response= 
> 7f90f2438f80, -1 from 1
> Apr 15 11:11:42 vps793907 kamailio[23122]: 13(23167) DEBUG: tls 
> [tls_server.c:604]: tls_h_close(): Closing SSL connection 0x7f90f2432b40
>
> I don't see any different.
>
> I know that the module is loaded because I see:
>
> exec: *** cfgtrace:request_route=[DEFAULT_ROUTE] 
> c=[/etc/kamailio/kamailio.cfg] l=486 a=5 n=route
>
> When I restart kamailio, but when I "launch" a call from Teams to my Kamailio 
> I only see that.
>
> To configure it, I follow https://skalatan.de/en/blog/kamailio-sbc-teams.. 
> But I cannot make it works..
>
> Any more thing that i can test or do??
>
> Thanks
>
> El jue., 16 abr. 2020 a las 14:20, Nasida Yuriy () escribió:
>>
>> Wow, so many people want to configure kamailio with MS. First of all i think 
>>

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

[Ovidiu Sas]

Nice hack! :)

-ovidiu

On Tue, Apr 14, 2020 at 5:27 PM Alex Balashov  wrote:
>
> Hi Luis,
>
> Rather confusingly, there is an 'async_workers' parameter in the core as
> well, which needs to be set:
>
> https://www.kamailio.org/wiki/cookbooks/5.3.x/core#async_workers
>
> There is some relationship between 'async_workers' in the core and the
> 'workers' modparam in the 'async' module which is explained by Daniel
> somewhere in a past mailing list thread, but I do not remember it
> offhand. I really should dig it out and update the documentation with
> this nuance.
>
> Having said that, I did not use the 'async' framework for my fix, but
> rather 'mqueue' and 'rtimer'. I have no real justification for that;
> just custom, habit and comfort with those mechanisms. I grew accustomed
> to them at a time when I had some issues with 100% CPU utilisation in a
> virtualised (Xen) environment when using early versions of the 'async'
> concepts.
>
> 1) The first thing is to create a reinvite queue; a single one will do,
> since it's specifically designed to be multiprocess-safe:
>
> loadmodule "mqueue"
> modparam("mqueue", "mqueue", "name=reinvite_q");
>
> 2) Then I create 12 'rtimer' processes to consume this queue, each
> having a 10,000 usec re-invocation delay:
>
> loadmodule "rtimer"
> modparam("rtimer", "timer", "name=reinvite_q1;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q1;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q2;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q2;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q3;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q3;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q4;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q4;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q5;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q5;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q6;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q6;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q7;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q7;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q8;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q8;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q9;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q9;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q10;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q10;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q11;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q11;route=REINVITE_DEQUEUE")
> modparam("rtimer", "timer", "name=reinvite_q12;interval=1u;mode=1;")
> modparam("rtimer", "exec", "timer=reinvite_q12;route=REINVITE_DEQUEUE")
>
> 3) I then add this handling for reinvites to the loose_route() block in
> the main request route -- logging and other extraneous matter omitted:
>
> ---
>if(has_totag()) {
>   if(loose_route()) {
>  if(is_method("INVITE")) {
>   if(!t_suspend()) {
>  sl_send_reply("500", "Internal Server Error");
>  exit;
>   }
>
>   mq_add("reinvite_q", "$T(id_index):$T(id_label)", "");
>   } else {
>  # Normal in-dialog request handling, t_relay() and that.
>
>  route(IN_DLG_REQ);
>   }
>}
>}
> ---
>
> And the handler on the other side, when the transaction is reanimated,
> as it were:
>
> ---
> route[REINVITE_DEQUEUE] {
>while(mq_fetch("reinvite_q")) {
>   xlog("L_INFO", "[R-REINVITE-DEQUEUE:$ci] -> Resuming re-invite handling 
> ($TV(Sn)) in PID $pp\n");
>
>   $var(id) = $(mqk(reinvite_q){s.select,0,:}{s.int});
>   $var(label) = $(mqk(reinvite_q){s.select,1,:}{s.int});
>
>   xlog("L_INFO", "[R-REINVITE-DEQUEUE:$ci] -> Resuming re-invite handling 
> ($TV(Sn)) in PID $pp\n");
>
>   # Call route[IN_DLG_REQ] to do what we otherwise would have done
>   # immediately, were it any other kind of in-dialog request.
>
>   t_continue("$var(id)", "$var(label)", "IN_DLG_REQ");
>   return;
>}
> }
> ---
>
> The idea behind 12 whole 'rtimer' processes is to massively
> overprovision the amount of reinvite handlers available relative to the
> actual number of reinvites passing through the system, even at high
> volumes.
>
> The danger with too few processes is that the intended 10 ms delay may
> not apply, because while(mq_fetch(...)) will just spin, always
> dequeueing new reinvites and never allowing the execution route to
> return control to 'rtimer'.
>
> As a practical matter, the system is not extremely high-volume and this
> is a very academic 

Re: [SR-Users] kamailio integration with MS teams.

[Ovidiu Sas]

The instructions are pretty clear in the sense that you need to fix
the Record-Route header.
You don't need to touch the Contact header for in-dialog requests/replies.

Regards,
Ovidiu Sas


On Tue, Apr 14, 2020 at 12:19 PM Nasida Yuriy  wrote:
>
> Hi guys,
>
>
> Do you have some expirience with kamailio integration with MS teams ?
>
>
> I follow the instructon from here
> https://skalatan.de/en/blog/kamailio-sbc-teams
>
> TLS part is configured correctly. I also got OPTIONS pings working between MS 
> teams and kamailio by following of  this instruction. That is very good.
>
>  But... There is issues with outbound calls from MS teams to kamailo.
>
>
> MS side send INVITE, kamailio responds with 180 and 200 OK, but looks like MS 
> ignores us. I know that I probably should use record_route_preset function 
> here to modify Record-Route headers to satisfy MS wishes.
>
> But nothing helps. I also tried to modify contact header in 200 OK like it 
> was done for OPTIONS - no luck.
>
> Anyone has a working example of kamailio files for MS team ?
> Or at least sucessful pcap with them.
>
> I can be wrong but looks like MS doesn't respect RFC at all.
>
>
> Thanks.
>
>
>
>
> Regards,
> Team lead
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio as SBC for Teams

[Ovidiu Sas]

The FQDN must be in the Contact of the OPTIONS request that is used for the
trunk keep alive. No need to mess up with the Contact header for in dialog
requests/replies.
However, the FQDN must be in the Record-Route header facing MS for in
dialog requests/replies.

Regards,
Ovidiu Sas

On Fri, Apr 10, 2020 at 12:59 Karsten Horsmann  wrote:

> Hi,
>
> Like in Hennings howto described if the front facing Kamailio used the
> FQDN names in contact and so one it works.
>
> And the "must be an certified sbc" is an marketing foo and for support
> cases they can say "go-to your sbc vendor" imho.
>
> I had this setup up and running.
>
> Kind regards
> Karsten Horsmann
>
> Sergiu Pojoga  schrieb am Fr., 10. Apr. 2020, 18:27:
>
>> Contact:
>> 
>>
>> Again, MS says it expects FQDN in Contact.
>>
>> If you are re-writing the Contact received from
>> ENDPOINT_BEHIND_KAMAILIO_IP, then I suggest you don't, it's sufficient to
>> have FQDN in RR. This isn't a "[certified] SBC", if it was like MS says -
>> it shouldn't work at all with a proxy like Kamailio.
>>
>> On Fri, Apr 10, 2020 at 12:00 PM Sergiu Pojoga  wrote:
>>
>>> You're likely referring to this:
>>>
>>> *Priority 1. Top-level Record-Route. If the top-level Record-Route
>>> contains the FQDN name or IP, the FQDN name or IP is used to make the
>>> outbound in-dialog connection.*
>>>
>>> Like with many Microsoft products, nobody knows precisely what they
>>> expect. To make matters worse - they don't reply back suggesting what's
>>> wrong, no tools on their side to troubleshoot.
>>>
>>> Regardless, why do you have 3 RRs of Kamailio? Fix the RRs, try again,
>>> or don't, it's up to you.
>>>
>>> Good luck.
>>>
>>> --Sergiu
>>>
>>>
>>> On Fri, Apr 10, 2020 at 11:42 AM Aidar Kamalov 
>>> wrote:
>>>
>>>> I thought they look only at first RR field?
>>>>
>>>> пт, 10 апр. 2020 г. в 17:03, Sergiu Pojoga :
>>>>
>>>>> You have too many RR of Kamailio, x1 FQDN, x3 IP. Why?
>>>>>
>>>>> IMO, you should have only 2 of Kamailio, if you're doing transport
>>>>> conversion. Both FQDNs + ";r2=on". MS clearly says FQDN everywhere, no IP,
>>>>> especially RR
>>>>>
>>>>> On Fri, Apr 10, 2020 at 7:06 AM Aidar Kamalov 
>>>>> wrote:
>>>>>
>>>>>> Thanks for the answer, I have disabled forse_rport() for Teams side,
>>>>>> responses now going to address in Via header, but it is not resolved my
>>>>>> issue, no ACK from Teams :(
>>>>>>
>>>>>> чт, 9 апр. 2020 г. в 18:22, Sergiu Pojoga :
>>>>>>
>>>>>>> Hi Aydar,
>>>>>>>
>>>>>>> Request from MS proxy has  VIA: SIP/2.0/TLS 52.114.7.24:5061,
>>>>>>> that's where your reply should go. You're sending to
>>>>>>> 52.114.7.24:1024 instead?
>>>>>>>
>>>>>>> Also, looks like you're missing "r2=on" on the other RR, only one
>>>>>>> has it.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov <
>>>>>>> aidar.kama...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying
>>>>>>>> to use kamailio for teams.
>>>>>>>> But I faced that MS not responding ACK to my 200OK. Somethin is
>>>>>>>> wrong, but I don't know what. I call from teams to kamailio.
>>>>>>>> Can you help me please
>>>>>>>>
>>>>>>>> This is initial INVITE from Teams:
>>>>>>>> 2020/04/09 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
>>>>>>>> INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
>>>>>>>> SIP/2.0
>>>>>>>> FROM: Aidar Kamalov>>>>>>> ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
>>>>>>>> TO: 
>>>>>>>> CSEQ: 1 INVITE
>>>>>>>> CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
>>>>>>>> MAX-FORWARDS: 70
>>&g

Re: [SR-Users] Printing xavp

[Ovidiu Sas]

Here's something that works:
$xavp(x=>a) = "1";
$xavp(x[0]=>b) = "2";
$xavp(x=>a) = "10";
$xavp(x[0]=>b) = "20";
$xavp(x=>a) = "100";
$xavp(x[0]=>b) = "200";


$var(i) = 0;
while (pv_isset("$xavp(x[$var(i)])")) {
xlog("L_INFO", "[$mi] xavp_copy $var(i)\n");
xavp_copy("x", "$var(i)", "y");
$var(i) = $var(i) + 1;
}
xlog("L_INFO", "[$mi] x is duplicated to y\n");

$var(i) = 0;
while (pv_isset("$xavp(y[0])")) {
xavp_params_implode("y", "$var(out)");
xlog("L_INFO", "[$mi] xavp(y[$var(i)])=$var(out)\n");
pv_unset("$xavp(y[0)");
$var(i) = $var(i) + 1;
}


The output:
Jan 21 10:18:12 asrock k[29060]: INFO: 

Re: [SR-Users] Printing xavp

[Ovidiu Sas]

This is to verbose and hard to read.
I was looking for something more configurable from the script.

-ovidiu

On Tue, Jan 21, 2020 at 7:34 AM Daniel-Constantin Mierla
 wrote:
>
> Hello,
>
> if you are looking to print the content to syslog for troubleshooting,
> then there is pv_xapv_print().
>
> Cheers,
> Daniel
>
> On 20.01.20 23:07, Ovidiu Sas wrote:
> > What's the best way to print the entire content of an xavp?
> > The xavp_params_implode() doesn't print the entire stack of an xavp,
> > only the top layer:
> >
> > The following code produces "c=d;e=f;"
> > $xavp(x=>e) = "f";
> > $xavp(x[0]=>c) = "d";
> > $xavp(x[1]=>e) = "z";
> > $xavp(x[1]=>c) = "y";
> > xavp_params_implode("x", "$var(out)");
> >
> > Is there a way to print everything inside $xavp(x)?
> >
> > Thanks,
> > Ovidiu
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com
> Kamailio World Conference - April 27-29, 2020, in Berlin -- 
> www.kamailioworld.com
>


-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Printing xavp

[Ovidiu Sas]

xavp_copy() is available only in dev.
How can you copy an entire xavp, not just an element, without knowing
the size of the stack?
This doesn't work:
$var(i) = 0;
while (pv_isset("$xavp(x[$var(i)])")) {
xavp_copy("x", "$var(i)", "y");
$var(i) = $var(i) + 1;
}


-ovidiu

On Mon, Jan 20, 2020 at 6:34 PM Julien Chavanton  wrote:
>
> Hi,
>
> To print all the elements in the stack, you will have to do a while loop.
> (You can make a copy using xavp_copy, it may come in handy in some cases)
> while (pv_unset("$xavp(name)")) {
>  // xavp_params_implode
> if(!defined $xavp(name)) {
> break;
> }
> }
>
>
> Or if you know how many elements are present in the stack or you could use
> while ($var(i) < x) {
> xavp_params_implode($xavp(route_set[$var(i)]))
> $var(i) = $var(i) + 1;
> }
>
> Quick answer ...
>
>
> On Mon, Jan 20, 2020 at 2:08 PM Ovidiu Sas  wrote:
>>
>> What's the best way to print the entire content of an xavp?
>> The xavp_params_implode() doesn't print the entire stack of an xavp,
>> only the top layer:
>>
>> The following code produces "c=d;e=f;"
>> $xavp(x=>e) = "f";
>> $xavp(x[0]=>c) = "d";
>> $xavp(x[1]=>e) = "z";
>> $xavp(x[1]=>c) = "y";
>> xavp_params_implode("x", "$var(out)");
>>
>> Is there a way to print everything inside $xavp(x)?
>>
>> Thanks,
>> Ovidiu
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Printing xavp

[Ovidiu Sas]

What's the best way to print the entire content of an xavp?
The xavp_params_implode() doesn't print the entire stack of an xavp,
only the top layer:

The following code produces "c=d;e=f;"
$xavp(x=>e) = "f";
$xavp(x[0]=>c) = "d";
$xavp(x[1]=>e) = "z";
$xavp(x[1]=>c) = "y";
xavp_params_implode("x", "$var(out)");

Is there a way to print everything inside $xavp(x)?

Thanks,
Ovidiu

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Changing name of the 'versions' table

[Ovidiu Sas]

Here's the link:
https://www.kamailio.org/wiki/cookbooks/devel/core#version_table

-ovidiu

On Tue, Dec 31, 2019 at 12:58 PM Alex Balashov
 wrote:
>
> Yes, there is a core config parameter that does just this and it exists for 
> the very reasons you mention. Check the core cookbook.
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
> > On Dec 31, 2019, at 12:55 PM, Ben Kaufman  wrote:
> >
> > Is it possible to use a table other than 'version' a the version table? 
> > i.e. if I'm in a shared DB, and there's an existing table named 'version' 
> > with completely different schema, is there a way I can create a table like 
> > 'kamailio_version' with the correct schema and data and use it instead?
> >
> > -- Ben Kaufman
> >
> > STATEMENT OF CONFIDENTIALITY:
> > The information contained in this electronic message and any attachments
> > to this message are intended for the exclusive use of the addressee(s)
> > and may contain confidential or privileged information. If you are not
> > the intended recipient, or the person responsible for delivering the
> > e-mail to the intended recipient, be advised you have received this
> > message in error and that any use, dissemination, forwarding, printing,
> > or copying is strictly prohibited. Please notify AltiGen Communications
> > immediately at either (888)258-4436 or via email to
> > administra...@altigen.com, and destroy all copies of this message and any
> > attachments.
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Saving REGISTER status in kamailio database while REGSITER packets are forwarded.

[Ovidiu Sas]

Did it work calling save() on the reply route?

-ovidiu

On Thu, Nov 14, 2019 at 6:20 PM Voip support  wrote:
>
>   I am using kamailio 5.3.
>
> Ovidiu Sas, i will try this tomorrow today is bit late. Maybe it could work.
>
> David Villasmil , i know i can use SQLOPS but i was thinking of easier method 
> of doing this.
> By successful REGISTER i mean save only REGISTER attempt that authenticated 
> correctly at SIP server and in 200 OK a binding was returned.
> Same if the binding is later removed i would like remove it from database. I 
> need this because when i run REGISTER over kamailio to destination SIP server 
> i see all register from same IP.
> I need to be able to check what was the real source IP of client REGISTER.
>
> Regards,
> Tomasz
>
>
>
> pt., 15 lis 2019 o 00:16 Mike from ApoloCore  napisał(a):
>>
>> I am using kamailio 5.3.
>>
>> Ovidiu Sas, i will try this tomorrow today is bit late. Maybe it could work.
>>
>> David Villasmil , i know i can use SQLOPS but i was thinking of easier 
>> method of doing this.
>> By successful REGISTER i mean save only REGISTER attempt that authenticated 
>> correctly at SIP server and in 200 OK a binding was returned.
>> Same if the binding is later removed i would like remove it from database. I 
>> need this because when i run REGISTER over kamailio to destination SIP 
>> server i see all register from same IP.
>> I need to be able to check what was the real source IP of client REGISTER.
>>
>> Regards,
>> Tomasz
>>
>>
>>
>>
>> czw., 14 lis 2019 o 23:33 Ovidiu Sas  napisał(a):
>>>
>>> Try to use save() when you process the 200 ok reply for REGISTER in
>>> the reply route.
>>>
>>> Regards,
>>> Ovidiu Sas
>>>
>>> On Thu, Nov 14, 2019 at 3:40 PM Voip support  wrote:
>>> >
>>> > I setup kamailio to forward REGISTER packets using dispatcher to two 
>>> > servers main and backup.
>>> >
>>> > The routing logic is quite simple i use the dispatcher probing mechanism 
>>> > to detect if my main dispatcher set id (one server) is active or inactive 
>>> > once it detect a failure all packets are sent to secondary SIP server to 
>>> > achieve High Availability.
>>> >
>>> > I am looking for module or a way to save into kamailio database client 
>>> > information such as IP address, register username (from FROM header), 
>>> > digest username (authorization username), call-id for successful 
>>> > registration.
>>> >
>>> > I tried to use registrar module but once i used function save("location") 
>>> > the client was registered on kamailio and packets was not forwarded to 
>>> > main/secondary SIP server (like dispatcher stopped working, the 
>>> > destination did not override).
>>> >
>>> > REGISTER is sent to SIP URI of kamailio.
>>> >
>>> > Please let me know if you have any idea how to make this data update in 
>>> > database (insert an entry on fresh successfull REGISTER, delete on 
>>> > expired or removed binding).
>>> >
>>> > Best regards,
>>> > Tomasz
>>> >
>>> > ___
>>> > Kamailio (SER) - Users Mailing List
>>> > sr-users@lists.kamailio.org
>>> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>>
>>> --
>>> VoIP Embedded, Inc.
>>> http://www.voipembedded.com
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Saving REGISTER status in kamailio database while REGSITER packets are forwarded.

[Ovidiu Sas]

Try to use save() when you process the 200 ok reply for REGISTER in
the reply route.

Regards,
Ovidiu Sas

On Thu, Nov 14, 2019 at 3:40 PM Voip support  wrote:
>
> I setup kamailio to forward REGISTER packets using dispatcher to two servers 
> main and backup.
>
> The routing logic is quite simple i use the dispatcher probing mechanism to 
> detect if my main dispatcher set id (one server) is active or inactive once 
> it detect a failure all packets are sent to secondary SIP server to achieve 
> High Availability.
>
> I am looking for module or a way to save into kamailio database client 
> information such as IP address, register username (from FROM header), digest 
> username (authorization username), call-id for successful registration.
>
> I tried to use registrar module but once i used function save("location") the 
> client was registered on kamailio and packets was not forwarded to 
> main/secondary SIP server (like dispatcher stopped working, the destination 
> did not override).
>
> REGISTER is sent to SIP URI of kamailio.
>
> Please let me know if you have any idea how to make this data update in 
> database (insert an entry on fresh successfull REGISTER, delete on expired or 
> removed binding).
>
> Best regards,
> Tomasz
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SQlite in memory

[Ovidiu Sas]

Do you use a lot of logging?
Have you enabled asynchronous logging?

If you are using the DB only for dispatcher, then you have other
issues then the db. The dispatcher module is caching the data on
memory.

You can do hundreds of CPS with only two workers and the CPU will be
at 3% utilization on very old hardware.
There's something else in your config creating issues.

Regards,
Ovidiu Sas


On Wed, Feb 27, 2019 at 1:36 PM Duarte Rocha  wrote:
>
> Ok, i reduced the number of processes and tried a few different values, but 
> the performance hasn't changed a lot.
>
> How can i debug this and find the bottleneck in my system?
>
> A quarta, 27/02/2019, 17:56, Duarte Rocha  escreveu:
>>
>> Greetings Alex,
>>
>> At the moment i'm trying to debug some issues with the server and try some 
>> solutions to see the impact.
>> With little load i'm getting some percentage of "503 Server Unavaliable" 
>> errors from Kamailio. I made some testing without using database for 
>> anything but Dispatcher and Accounting and the performance got way better.
>>
>> Right now, on this server, under as little as 20CPS Kamailio is returning 
>> "503" on 1-2% of all calls. However, my CPU and Memory look like this:
>>
>> %Cpu(s): 20.3 us, 6.1 sy, 0.0 ni, 73.3 id, 0.0 wa, 0.0 hi, 0.2 si, 0.2 st
>>
>>
>> Memory :
>>
>>   total used free shared buff/cache available
>> Mem: 1830 1172 382 109 274 375
>> Swap: 819 49 770
>>
>> I have around 100 processes for Kamailio.
>>
>> Cheers
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio with oracle database

[Ovidiu Sas]

You need to use:
sqlquery("connection_name","function Syntax ,"result variable")

Please see the example in the docs:
http://kamailio.org/docs/modules/5.2.x/modules/sqlops.html#idm1027846556

Regards,
Ovidiu Sas

On Mon, Feb 25, 2019 at 9:13 AM eyas barhouk  wrote:
>
> Dear Henning thanks for kind reply,
>
> yes i already tried to use SQLOPS module and the connection was up, but when 
> i'm trying to to call oracle function by using 
> sqlquery(connection_name,"function Syntax ,"result variable")
> kamailio gives execution Errors , so does kamailio sqlops module support 
> Oracle function calling and if yes what is the correct syntax ??.
>
> Best regards
> Eyas Barhok
>
> 
> From: Henning Westerholt 
> Sent: Monday, February 25, 2019 1:59 PM
> To: sr-users@lists.kamailio.org
> Cc: eyas barhouk
> Subject: Re: [SR-Users] Kamailio with oracle database
>
> Am Montag, 25. Februar 2019, 12:01:57 CET schrieb eyas barhouk:
> > I'm trying to run kamailio with oracle 11g database and applying the needed
> > querys by using Sqlops modules after applying the needed configuration i
> > didn't find any Syntex to execute Oracle function from kamailio sqlops
> > module . So is there any way to execute oracle function from kamailio ??
>
> Hello Eyas,
>
> have you tried to just call the function with sqlops? Do you get an error
> message?
>
> I found some discussion from years ago related to postgres, people use it
> there.
>
> https://lists.kamailio.org/pipermail/sr-users/2014-March/081856.html
>
> Best regards,
>
> Henning
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Mysql to hastable conversion

[Ovidiu Sas]

Hello Duarte,

Create a view for each htable that you want to use.
Like this you can keep you existing table and config tools.

Regards,
Ovidiu Sas

On Wed, Feb 13, 2019 at 12:14 PM Duarte Rocha  wrote:
>
> Greetings,
>
> I have Kamailio has an SBC and i'm using a MySQL database to store all the 
> relevant configurations and settings regarding the NAP's, Users, Numbers, etc.
>
> That being said, i'm having lots of of performance issues originated by the 
> queries. In order to solve that i think the best way to proceed would be to 
> implement hashtables. However, i would like to keep Sql DB's for easier 
> configuration and having them automatically transformed into hashtables.
>
> Is there a simple way to do this? As i see, the htable module is able to load 
> from a DB, but i understand it, the table should be already in "hashtable 
> form".
>
> Does kamailio has any way to solve this or should i use external tools?
>
> Best Regards,
>
> Duarte Rocha
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] kamailio with oracle data base

[Ovidiu Sas]

Take a look at the oracle instaclient:
https://www.oracle.com/technetwork/database/database-technologies/instant-client/overview/index.html
Go to the download section and install the packages related to your
architecture.

The makefile for the module works out of the box for oracle
instaclient 12.2.0.1.0.
For instaclient 18.3, the path for DEFS and LIBS most likely will need
to be updated.

Regards,
Ovidiu Sas

On Wed, Feb 13, 2019 at 5:35 AM eyas barhouk  wrote:
>
> hello dears ,
>
> is there any simple way to compile and add db_oracle module to kamailio 5.1.X 
> ???
>
> regards
> Eyas
>
> 
> From: eyas barhouk 
> Sent: Friday, January 25, 2019 9:18 AM
> To: Henning Westerholt
> Cc: sr-users@lists.kamailio.org
> Subject: Re: [SR-Users] kamailio with oracle data base
>
> Many thanks for your kind feedback dears.
>
> I will try it and feedback.
>
> Thanks again
> Regards
> Eyas
>
> Get Outlook for Android
>
> 
> From: Henning Westerholt 
> Sent: Friday, January 25, 2019 10:54:07 AM
> To: eyas barhouk
> Cc: sr-users@lists.kamailio.org
> Subject: Re: [SR-Users] kamailio with oracle data base
>
> Am Donnerstag, 24. Januar 2019, 14:34:15 CET schrieb eyas barhouk:
> > i already read it, but i didn't find any function on it or any configuration
> > to setup the connection between  kamailio and oracle database. if there is
> > any document or tutorial about how to configure kamailio with oracle D.B
> > and request a function from database it will be great & i will be thankful.
>
> Hello Eyas,
>
> another option would be to use the db_unixodbc module, as already mentioned.
>
> If you load a database module (e.g. db_oracle) you just need to specify the
> correct db URL in the modules that needs a database connection. The modules
> then created a connection to the database. This is documented in the
> respective module documentation.
>
> If you want to execute arbitrary queries on your database you can do this with
> the sqlops module. Not sure about the exact details related to oracle, but it
> should be somehow possible.
>
> Best regards,
>
> Henning
>
> > 
> > From: Henning Westerholt 
> > Sent: Thursday, January 24, 2019 12:59 PM
> > To: sr-users@lists.kamailio.org
> > Cc: eyas barhouk
> > Subject: Re: [SR-Users] kamailio with oracle data base
> >
> > Am Donnerstag, 24. Januar 2019, 13:25:30 CET schrieb eyas barhouk:
> > > i'm trying to build kamailio on top of oracle D.B so is there any way to
> > > configure kamailio to deal with Oracle D.B and call functions from it ?
> >
> > Hello Eyas,
> >
> > have a look to the db_oracle module:
> >
> > https://kamailio.org/docs/modules/5.2.x/modules/db_oracle.html
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] cfg script 101

[Ovidiu Sas]

1. Here's the documentation for while loop:
http://www.kamailio.org/wiki/cookbooks/devel/core#while

2. Here are some string helper functions:
http://www.kamailio.org/wiki/cookbooks/devel/transformations#ssubstr_offset_length
http://www.kamailio.org/wiki/cookbooks/devel/transformations#sselect_index_separator

3. You can browse documentation here:
http://www.kamailio.org/wiki/#cookbooks


Regards,
Ovidiu Sas

On Wed, May 16, 2018 at 5:59 PM, KamDev Essa <kamdeve...@yahoo.com> wrote:
> I have decided to do Hunting DIY. I needed some help with the cfg script
> part and using a database dip.
>
> Say I do the db dip
>
> sql_xquery("ca", "call usp_GetHuntBranches( '$rU', '$rd');", "ra");
>
> that will return the uri/q pairs and I will add using append_branch
> dynamically.
>
> How do I do the looping in the script?
>
> I have 2 ways to deliver the list via the sp.
>
> Rows with uri and q values. easiest
> Single row with variable paired fields like say ur1,q1,ur2,q2 etc etc
>
> Questions :
>
> Can the script handle  sql_xquery with multiple rows. If so, can I get a
> code snippet or example that show me how to iterate through. Is there a
> "while" loop capability in the script?
> Is there a "substring" or "split" function in the script that could allow me
> to get the data as a single text with uri and q separated by a \ or |.
> Or is there a document that explains the various generic functions I can use
> the cfg script area.
>
> KD
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] is_audio_on_hold() doesn't support rfc3264

[Ovidiu Sas]

According to the code, both rfc2543 and rfc3264 are handled.
Just tested this out with jitsi and it's working fine.
Can you provide a sample of your tests?

Regards,
Ovidiu Sas

On Tue, Oct 24, 2017 at 9:52 AM, Julia Boudniatsky <juli...@gmail.com> wrote:
> FYI,
>
> After some tests found, that function "is_audio_on_hold()" (textops)
> supports only rfc 2543,
> where "hold"  is indicated by setting  the "c" destination  addresses for
> the media streams to zero  (0.0.0.0).
> The newest rfc3264, where "hold" is indicated by a=sendonly/inactive, is not
> supported.
> Kamailio version 4.4.6.
>
> Best regards,
> Julia
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] is_audio_on_hold() doesn't support rfc3264

[Ovidiu Sas]

I updated the documentation to reflect this.
If you need support for RFC3264, please open a ticket.

Regards,
Ovidiu Sas

On Tue, Oct 24, 2017 at 9:52 AM, Julia Boudniatsky <juli...@gmail.com> wrote:
> FYI,
>
> After some tests found, that function "is_audio_on_hold()" (textops)
> supports only rfc 2543,
> where "hold"  is indicated by setting  the "c" destination  addresses for
> the media streams to zero  (0.0.0.0).
> The newest rfc3264, where "hold" is indicated by a=sendonly/inactive, is not
> supported.
> Kamailio version 4.4.6.
>
> Best regards,
> Julia
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users