This info is in the readme of the module, not wiki, iirc. You can make a
pull request with more details there, by adding the text to
src/modules/dispatcher/doc/dispatcher_admin.xml -- any contribution to
documentation is more than welcome.
Cheers,
Daniel
On 26.02.19 17:24, Denys Pozniak wrote:
>
Hello,
The value of debug level I had during the crash is 2.
---
debug=2
---
I checked from my monitoring tools and system logs if the server has
encounter any issue (freeze, network lost, database issues, ...) but I
found nothing.
[image: image.png]
[image: image.png]
I use Debian (8.6
Hello,
My suggestion is that stay away from NAT if you dont have to. various sip
client/Firewalls make out troubles for registration and invites, even if
Kamailio can handle it. If you have a high load TLS connection / subscriber ,
I think you should use load balancer and NAT options.
For
Hi Henning, Joel,
Thanks for your valuable input.
One of our setup for production looks like below for around 1 million
users initially :
/ -->
Kamailio (active node, as of now private) \
Client -- > LB(public IP- l4
Thanks Sergiu for your reply!
That's exactly what I am planning to do. But I just want to make sure the
reload would not cause me some problem in production
Cheers,
Patrick Wakano
On Wed, 27 Feb 2019 at 12:44, Sergiu Pojoga wrote:
> Using TLS reload every few months when let's encrypt cert
Using TLS reload every few months when let's encrypt cert renews, works
fine all the time without doing full restart.
Cheers,
On Tue, Feb 26, 2019, 8:29 PM Patrick Wakano, wrote:
> Hi list,
> I've seen the TLS documentation (
>
Hi list,
I've seen the TLS documentation (
https://www.kamailio.org/docs/modules/5.2.x/modules/tls.html#tls.known_limitations)
where it states that
TLS specific config reloading is not safe, so for now better don't use it,
especially under heavy traffic.
This note is there since version 3.0 and
I third that. NAT by definition adds complications and overhead, even if
they are not significant from a modern economic perspective. If you have
the luxury to take NAT out of the equation, you definitely should. But
if you can't, Kamailio copes with this very well and has an ample
feature set to
I second that. And to add to Henning's suggestion...
We recently tested that same setup, and we found one "thing": Using
advertise, you will need a second port (listen transport:ip:port) to talk
to internal servers that require you to *keep* the private IP. Otherwise
all outgoing request from
Am Dienstag, 26. Februar 2019, 06:09:08 CET schrieb Pintu Lohar:
> Which one among the below option is highly recommended for setting up
> Kamailio (for production)
> 1. Kamailio behind NAT *or*
>2. Setting up Kamailio using public IP?
>
> are there any disadvantages if we setup Kamailio
Thanks!
I set in the way below, looks working. Maybe wiki needs to be updated?
4 sip:10.6.3.122:5060 0 5
4 sip:10.6.3.1:5060 0 5
4 sip:10.6.3.2:5060 0 5
4 sip:10.6.3.3:5060 0 5
4 sip:10.6.3.4:5060 0 5
4 sip:10.6.3.5:5060 0 1
вт, 26 февр. 2019 г. в 17:48, Daniel-Constantin Mierla :
> Hello,
>
Hello, I would like to use the [*] index for the avps (to overwrite instead
of adding to the stack) when passing the variable to jansson module
functions.
When trying to do so I get this error:
9(35) ERROR: jansson [jansson_funcs.c:219]: janssonmod_set(): result has
json error at line 1: end of
Hello,
you have to set the priority field for each destination to ensure a
particular order there. While with text file one can consider the order
of appearance, this is no longer valid for database -- the order in a
table can be different that what is returned by "select * ...",
therefore the
kamcmd dispatcher.list shows gateways in reverse order (comparing to the
file) and "last hope" gw is the last one here (URI: sip:10.6.3.122:5060).
SET: {
ID: 4
TARGETS: {
DEST: {
Hello!
I use dispatcher with algorithm=1 (hashing over from URI) with module
parameter use_default=1.
So I am expecting that last string in dispatcher.list for specific set will
be the "last hope" for call routing.
dispatcher.list
..
4 sip:10.6.3.122:5060
4 sip:10.6.3.1:5060
4 sip:10.6.3.2:5060
Hello,
short note to say that I moved the first option for the date of the IRC
meeting to be the 11th of March, Monday, at 15:00UTC.
Victor Seva mentioned he cannot attend during the previously proposed
first option and one of the topics I want to approach is use of
rtpengine in default
Hello,
set_body() is exported by textops and should be available in Kemi:
-
http://kamailio.org/docs/tutorials/devel/kamailio-kemi-framework/modules/#ksrtextopsset_body
Cheers,
Daniel
On 26.02.19 12:10, Yuriy Gorlichenko wrote:
> Hi. On the original config to set body with New data I used
>
Sorry. Searched in a wrong module. Textops offcourse...
Question closed
On Tue, 26 Feb 2019, 12:10 Yuriy Gorlichenko, wrote:
> Hi. On the original config to set body with New data I used
> set_body() function, exported from sdpops module.
> But for kamailio 5.1 I can't find something same in
Hi. On the original config to set body with New data I used
set_body() function, exported from sdpops module.
But for kamailio 5.1 I can't find something same in case of using kemi
Is There is some additional way to do this?
___
Kamailio (SER) - Users
Thank you very much, Daniel! We'll try that.
On Tue, 26 Feb 2019 at 20:25, Daniel-Constantin Mierla
wrote:
> Hello,
>
> if you have kamailio 5.2, you should enable ignore of sips in rr:
>
> -
> https://www.kamailio.org/docs/modules/stable/modules/rr.html#rr.p.ignore_sips
>
> If you have an
20 matches
Mail list logo
