Re: [SR-Users] Dispatcher with parameter use_default=1

[Daniel-Constantin Mierla]

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:
> 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
> mailto:mico...@gmail.com>>:
>
> 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 priority field is the one that
> matter here.
>
> Cheers,
> Daniel
>
> On 26.02.19 16:40, Denys Pozniak wrote:
>>
>> 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: {
>>                                         URI: sip:10.6.3.5:5060
>> 
>>                                         FLAGS: AX
>>                                         PRIORITY: 0
>>                                 }
>>                                 DEST: {
>>                                         URI: sip:10.6.3.4:5060
>> 
>>                                         FLAGS: AX
>>                                         PRIORITY: 0
>>                                 }
>>                                 DEST: {
>>                                         URI: sip:10.6.3.3:5060
>> 
>>                                         FLAGS: AX
>>                                         PRIORITY: 0
>>                                 }
>>                                 DEST: {
>>                                         URI: sip:10.6.3.2:5060
>> 
>>                                         FLAGS: AX
>>                                         PRIORITY: 0
>>                                 }
>>                                 DEST: {
>>                                         URI: sip:10.6.3.1:5060
>> 
>>                                         FLAGS: AX
>>                                         PRIORITY: 0
>>                                 }
>>                                 DEST: {
>>                                         URI: sip:10.6.3.122:5060
>> 
>>                                         FLAGS: AX
>>                                         PRIORITY: 0
>>                                 }
>>                         }
>>                 }
>>
>>
>>
>> вт, 26 февр. 2019 г. в 17:24, Denys Pozniak
>> mailto:denys.pozn...@gmail.com>>:
>>
>> 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 
>> 4 sip:10.6.3.3:5060 
>> 4 sip:10.6.3.4:5060 
>> 4 sip:10.6.3.5:5060 
>>
>> But as I see from logs dispatcher module takes first string
>> as the "last hope":
>>
>> xlog("L_WARN", "TEST-- $(avp(AVP_DST)[0]) $(avp(AVP_DST)[1])
>> $(avp(AVP_DST)[2]) $(avp(AVP_DST)[3]) $(avp(AVP_DST)[4]) 
>> $(avp(AVP_DST)[5])  $(avp(AVP_DST)[6]) \n");
>>
>> Feb 26 16:11:39 kamailio-2 /usr/sbin/kamailio[28156]:
>> WARNING: 

Re: [SR-Users] tm.so --> segfault at 3135352e36 ip 00007f761bb57ed1 sp 00007fff9db8b1c0 error 4 in tm.so

[Abdoul Osséni]

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 default version).

[image: image.png]
Regards

Abdoul


Le lun. 25 févr. 2019 à 18:34, Daniel-Constantin Mierla 
a écrit :

> Hello,
>
> that's strange, but a while ago someone else reported an issue with same
> backtrace.
>
> So the crash happens at the last line in the next snippet from
> reply_received() function in the tm module:
>
> uac=>uac[branch];
> LM_DBG("org. status uas=%d, uac[%d]=%d local=%d is_invite=%d)\n",
> t->uas.status, branch, uac->last_received,
> is_local(t), is_invite(t));
> last_uac_status=uac->last_received;
>
> The backtrace and info locals say that uac is null (0x0). According to my
> knowledge, the address of a field in a structure cannot be null and uac is
> set to >uac[branch]. Moreover, uac->last_received is printed in the
> LM_DBG() above the line of crash, if uac was 0x0, the crash should have
> happened there.
>
> Then uac is a local variable, so it is on the stack of the process, in its
> private memory. There is no other assign or copy operation between the line
> of code where the uac is set and the crash. So overall, should be no race
> condition there. Either the kernel was doing something wrong, or maybe the
> coredump was somehow corrupted.
>
> What was the value of debug level you had during the crash (debug
> parameter in kamailio.cfg)?
>
> Could there have been any freeze of the operating system for long time and
> then a resume?
>
> Can you give the output of command:
>
> uname -a
>
> What kind of linux distro and version you are running?
>
> Cheers,
> Daniel
> On 25.02.19 15:27, Abdoul Osséni wrote:
>
> Hello,
>
> Please see attached the output of the gdb commands.
>
> Can you check with all core files and see if the backtrace is the same?
>
> --> Yes the backtrace is the same.
>
> Sorry, I use kamailio v5.2
>
> root@sbc:/var/cores# kamailio -V
> version: kamailio 5.2.1 (x86_64/linux) cd2583
> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, 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
> 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: cd2583
> compiled on 07:33:25 Jan 31 2019 with gcc 4.9.2
>
>
> Kamailio is running on a bare metal server.
>
>
> Thanks
>
> Abdoul
>
>
> Le lun. 25 févr. 2019 à 14:40, Daniel-Constantin Mierla 
> a écrit :
>
>> Hello,
>>
>> can you give the output for next gdb commands:
>>
>> bt full
>>
>> info locals
>>
>> list
>>
>> Can you check with all core files and see if the backtrace is the same?
>>
>> What is the version of Kamailio? Is it running on a bare metal server or
>> a virtual machine/container?
>>
>> Cheers,
>> Daniel
>> On 25.02.19 14:21, Abdoul Osséni wrote:
>>
>> Hello,
>>
>> Hello dear list,
>>
>> Today, I have had mutiples crashes. It seems it linked to tm.so module.
>>
>> -rw--- 1 root kamailio 4299702272 Feb 25 13:08
>> core.kamailio.sig11.29204
>> -rw--- 1 root kamailio 1453023232 Feb 25 13:12
>> core.kamailio.sig11.29203
>> -rw--- 1 root kamailio 1416065024 Feb 25 13:12
>> core.kamailio.sig11.29207
>> -rw--- 1 root kamailio 4299681792 Feb 25 13:16
>> core.kamailio.sig11.19047
>> -rw--- 1 root kamailio 2108506112 Feb 25 13:20
>> core.kamailio.sig11.19043
>> -rw--- 1 root kamailio 4299689984 Feb 25 13:34
>> core.kamailio.sig11.19247
>> -rw--- 1 root kamailio 4299681792 Feb 25 13:34
>> core.kamailio.sig11.19246
>> -rw--- 1 root kamailio 4299698176 Feb 25 13:35
>> core.kamailio.sig11.19248
>> -rw--- 1 root kamailio 4299689984 Feb 25 13:35
>> core.kamailio.sig11.19243
>> -rw--- 1 root kamailio 4299685888 Feb 25 13:35
>> core.kamailio.sig11.19244
>> -rw--- 1 root kamailio 4299689984 Feb 25 13:36
>> core.kamailio.sig11.19242
>>
>> root@sbc:/var/cores# gdb /usr/local/sbin/kamailio
>> core.kamailio.sig11.29204
>> GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources 

Re: [SR-Users] Kamailio behind NAT or With Public IP - Which one is highly recommended

[YASIN CANER]

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 example;
1 - Load balancer like F5  that balancing your connection active-active 
Kamailios


UAC > F5 --> Kamailio -1 (advertises public IP)
   |
--->  Kamailio -2 (advertises public IP)

2- Use kamailio as MultiHomed that convert transport layer to tcp/udp

UAC -> Kamailio(TLS-PUBLIC IP-mhomed) --->  Kamailio-1(TCP/UDP)

  |

   -> Kamailio-2(TCP/UDP)


Good luck

Yasin CANER


From: sr-users  on behalf of Pintu Lohar 

Sent: Tuesday, February 26, 2019 8:09 AM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Kamailio behind NAT or With Public IP - Which one is highly 
recommended

Hi Everyone,

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 behind NAT and use advertise 
option in listen parameters?

We have tested both the options, and both the options work great for us( a. 
Kamailio behind NAT with advertising in listen parameters b.Kamailio setup with 
public IP).  So wondering which one is best and highly recommended?

Some extra info :
1. We use TLS
2. Using coturn for media

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

Re: [SR-Users] Kamailio behind NAT or With Public IP - Which one is highly recommended

[Pintu Lohar]

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 switch)--

-->Centralized database
  \ -->
Kamailio (passive node, as of now private)  /


In the future, we have a plan to add another domain and allow calls between
different domain.

Thanks & Regards
Pintu

On Wed, Feb 27, 2019 at 6:47 AM Joel Serrano  wrote:

> 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 that kamailio will have the IP replaced by
> whatever the advertise says and that can mess up your internal routing.
>
> Not an issue, as I said you can configure a second port, but just
> something to know depending on what your setup is gong to look like.
>
> Good luck!
> Joel.
>
> On Tue, Feb 26, 2019 at 1:28 PM Henning Westerholt 
> wrote:
>
>> 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 behind NAT and use
>> > advertise option in listen parameters?
>> >
>> > We have tested both the options, and both the options work great for
>> us( a.
>> > Kamailio behind NAT with advertising in listen parameters b.Kamailio
>> setup
>> > with public IP).  So wondering which one is best and highly recommended?
>> >
>> > Some extra info :
>> > 1. We use TLS
>> > 2. Using coturn for media
>>
>> Hello Pintu,
>>
>> generally speaking, if you have the choice between a network setup with
>> NAT
>> and without NAT (everything else equal) - my recommendation would to
>> choose
>> the one without NAT. It will be easier to debug in case of problems on
>> your
>> side or the client side.
>>
>> 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
>>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] TLS reload

[Patrick Wakano]

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 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 (
>> 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 in 2013 there was some
>> discussion about it but wthout anything conclusive
>> What I would like to know if this is still the case. Is anyone running
>> the TLS reload for certificate renovation for example, or is it better to
>> restart Kamailio?
>>
>> Thanks,
>> Kind regards,
>> Patrick Wakano
>> ___
>> 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

Re: [SR-Users] TLS reload

[Sergiu Pojoga]

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 (
> 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 in 2013 there was some discussion
> about it but wthout anything conclusive
> What I would like to know if this is still the case. Is anyone running the
> TLS reload for certificate renovation for example, or is it better to
> restart Kamailio?
>
> Thanks,
> Kind regards,
> Patrick Wakano
> ___
> 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

[SR-Users] TLS reload

[Patrick Wakano]

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 in 2013 there was some discussion
about it but wthout anything conclusive
What I would like to know if this is still the case. Is anyone running the
TLS reload for certificate renovation for example, or is it better to
restart Kamailio?

Thanks,
Kind regards,
Patrick Wakano
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio behind NAT or With Public IP - Which one is highly recommended

[Alex Balashov]

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 accommodate that type of deployment, given how common it
is nowadays to deploy Kamailio in NAT-only environments such as AWS.

On Tue, Feb 26, 2019 at 01:47:36PM -0800, Joel Serrano wrote:

> 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 that kamailio will have the IP replaced by
> whatever the advertise says and that can mess up your internal routing.
> 
> Not an issue, as I said you can configure a second port, but just something
> to know depending on what your setup is gong to look like.
> 
> Good luck!
> Joel.
> 
> On Tue, Feb 26, 2019 at 1:28 PM Henning Westerholt  wrote:
> 
> > 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 behind NAT and use
> > > advertise option in listen parameters?
> > >
> > > We have tested both the options, and both the options work great for us(
> > a.
> > > Kamailio behind NAT with advertising in listen parameters b.Kamailio
> > setup
> > > with public IP).  So wondering which one is best and highly recommended?
> > >
> > > Some extra info :
> > > 1. We use TLS
> > > 2. Using coturn for media
> >
> > Hello Pintu,
> >
> > generally speaking, if you have the choice between a network setup with
> > NAT
> > and without NAT (everything else equal) - my recommendation would to
> > choose
> > the one without NAT. It will be easier to debug in case of problems on
> > your
> > side or the client side.
> >
> > 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
> >

> ___
> 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

Re: [SR-Users] Kamailio behind NAT or With Public IP - Which one is highly recommended

[Joel Serrano]

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 that kamailio will have the IP replaced by
whatever the advertise says and that can mess up your internal routing.

Not an issue, as I said you can configure a second port, but just something
to know depending on what your setup is gong to look like.

Good luck!
Joel.

On Tue, Feb 26, 2019 at 1:28 PM Henning Westerholt  wrote:

> 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 behind NAT and use
> > advertise option in listen parameters?
> >
> > We have tested both the options, and both the options work great for us(
> a.
> > Kamailio behind NAT with advertising in listen parameters b.Kamailio
> setup
> > with public IP).  So wondering which one is best and highly recommended?
> >
> > Some extra info :
> > 1. We use TLS
> > 2. Using coturn for media
>
> Hello Pintu,
>
> generally speaking, if you have the choice between a network setup with
> NAT
> and without NAT (everything else equal) - my recommendation would to
> choose
> the one without NAT. It will be easier to debug in case of problems on
> your
> side or the client side.
>
> 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
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio behind NAT or With Public IP - Which one is highly recommended

[Henning Westerholt]

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 behind NAT and use
> advertise option in listen parameters?
> 
> We have tested both the options, and both the options work great for us( a.
> Kamailio behind NAT with advertising in listen parameters b.Kamailio setup
> with public IP).  So wondering which one is best and highly recommended?
> 
> Some extra info :
> 1. We use TLS
> 2. Using coturn for media

Hello Pintu,

generally speaking, if you have the choice between a network setup with NAT 
and without NAT (everything else equal) - my recommendation would to choose 
the one without NAT. It will be easier to debug in case of problems on your 
side or the client side.

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

Re: [SR-Users] Dispatcher with parameter use_default=1

[Denys Pozniak]

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,
>
> 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
> priority field is the one that matter here.
>
> Cheers,
> Daniel
> On 26.02.19 16:40, Denys Pozniak wrote:
>
>
> 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: {
> URI: sip:10.6.3.5:5060
> FLAGS: AX
> PRIORITY: 0
> }
> DEST: {
> URI: sip:10.6.3.4:5060
> FLAGS: AX
> PRIORITY: 0
> }
> DEST: {
> URI: sip:10.6.3.3:5060
> FLAGS: AX
> PRIORITY: 0
> }
> DEST: {
> URI: sip:10.6.3.2:5060
> FLAGS: AX
> PRIORITY: 0
> }
> DEST: {
> URI: sip:10.6.3.1:5060
> FLAGS: AX
> PRIORITY: 0
> }
> DEST: {
> URI: sip:10.6.3.122:5060
> FLAGS: AX
> PRIORITY: 0
> }
> }
> }
>
>
>
> вт, 26 февр. 2019 г. в 17:24, Denys Pozniak :
>
>> 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
>> 4 sip:10.6.3.3:5060
>> 4 sip:10.6.3.4:5060
>> 4 sip:10.6.3.5:5060
>>
>> But as I see from logs dispatcher module takes first string as the "last
>> hope":
>>
>> xlog("L_WARN", "TEST-- $(avp(AVP_DST)[0]) $(avp(AVP_DST)[1])
>> $(avp(AVP_DST)[2]) $(avp(AVP_DST)[3]) $(avp(AVP_DST)[4])
>> $(avp(AVP_DST)[5])  $(avp(AVP_DST)[6]) \n");
>>
>> Feb 26 16:11:39 kamailio-2 /usr/sbin/kamailio[28156]: WARNING: 

[SR-Users] Using the avp [*] index with jansson module functions

[Enrico Bandiera]

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 file expected near ','

I suppose this is unsupported but maybe I'm doing something wrong, any
suggestions?

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

Re: [SR-Users] Dispatcher with parameter use_default=1

[Daniel-Constantin Mierla]

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 priority field is the one that matter here.

Cheers,
Daniel

On 26.02.19 16:40, Denys Pozniak wrote:
>
> 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: {
>                                         URI: sip:10.6.3.5:5060
> 
>                                         FLAGS: AX
>                                         PRIORITY: 0
>                                 }
>                                 DEST: {
>                                         URI: sip:10.6.3.4:5060
> 
>                                         FLAGS: AX
>                                         PRIORITY: 0
>                                 }
>                                 DEST: {
>                                         URI: sip:10.6.3.3:5060
> 
>                                         FLAGS: AX
>                                         PRIORITY: 0
>                                 }
>                                 DEST: {
>                                         URI: sip:10.6.3.2:5060
> 
>                                         FLAGS: AX
>                                         PRIORITY: 0
>                                 }
>                                 DEST: {
>                                         URI: sip:10.6.3.1:5060
> 
>                                         FLAGS: AX
>                                         PRIORITY: 0
>                                 }
>                                 DEST: {
>                                         URI: sip:10.6.3.122:5060
> 
>                                         FLAGS: AX
>                                         PRIORITY: 0
>                                 }
>                         }
>                 }
>
>
>
> вт, 26 февр. 2019 г. в 17:24, Denys Pozniak  >:
>
> 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 
> 4 sip:10.6.3.3:5060 
> 4 sip:10.6.3.4:5060 
> 4 sip:10.6.3.5:5060 
>
> But as I see from logs dispatcher module takes first string as the
> "last hope":
>
> xlog("L_WARN", "TEST-- $(avp(AVP_DST)[0]) $(avp(AVP_DST)[1])
> $(avp(AVP_DST)[2]) $(avp(AVP_DST)[3]) $(avp(AVP_DST)[4]) 
> $(avp(AVP_DST)[5])  $(avp(AVP_DST)[6]) \n");
>
> Feb 26 16:11:39 kamailio-2 /usr/sbin/kamailio[28156]: WARNING:
> 

Re: [SR-Users] Dispatcher with parameter use_default=1

[Denys Pozniak]

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: {
URI: sip:10.6.3.5:5060
FLAGS: AX
PRIORITY: 0
}
DEST: {
URI: sip:10.6.3.4:5060
FLAGS: AX
PRIORITY: 0
}
DEST: {
URI: sip:10.6.3.3:5060
FLAGS: AX
PRIORITY: 0
}
DEST: {
URI: sip:10.6.3.2:5060
FLAGS: AX
PRIORITY: 0
}
DEST: {
URI: sip:10.6.3.1:5060
FLAGS: AX
PRIORITY: 0
}
DEST: {
URI: sip:10.6.3.122:5060
FLAGS: AX
PRIORITY: 0
}
}
}



вт, 26 февр. 2019 г. в 17:24, Denys Pozniak :

> 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
> 4 sip:10.6.3.3:5060
> 4 sip:10.6.3.4:5060
> 4 sip:10.6.3.5:5060
>
> But as I see from logs dispatcher module takes first string as the "last
> hope":
>
> xlog("L_WARN", "TEST-- $(avp(AVP_DST)[0]) $(avp(AVP_DST)[1])
> $(avp(AVP_DST)[2]) $(avp(AVP_DST)[3]) $(avp(AVP_DST)[4])
> $(avp(AVP_DST)[5])  $(avp(AVP_DST)[6]) \n");
>
> Feb 26 16:11:39 kamailio-2 /usr/sbin/kamailio[28156]: WARNING: 

[SR-Users] Dispatcher with parameter use_default=1

[Denys Pozniak]

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
4 sip:10.6.3.3:5060
4 sip:10.6.3.4:5060
4 sip:10.6.3.5:5060

But as I see from logs dispatcher module takes first string as the "last
hope":

xlog("L_WARN", "TEST-- $(avp(AVP_DST)[0]) $(avp(AVP_DST)[1])
$(avp(AVP_DST)[2]) $(avp(AVP_DST)[3]) $(avp(AVP_DST)[4])
$(avp(AVP_DST)[5])  $(avp(AVP_DST)[6]) \n");

Feb 26 16:11:39 kamailio-2 /usr/sbin/kamailio[28156]: WARNING: 

Re: [SR-Users] Planning next IRC devel meeting

[Daniel-Constantin Mierla]

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 kamailio.cfg, which, for easier usage, could
require packaging it for debian/ubuntu distros in our repo and
eventually for rpms distros.

Cheers,
Daniel

On 22.02.19 11:50, Daniel-Constantin Mierla wrote:
> Hello,
>
> wondering if we we should do a new IRC devel meeting in the near future
> to sync on development plans.
>
> One of the decisions we should take is whether we should target to
> release the new major version (5.3) before the summer holidays or we
> leave it for the autumn.
>
> If many wants to do it, then a first proposal for a date would be: March
> 07, 2019, at 15:00 UTC (16:00 Berlin time).
>
> As usual, I created a wiki page to track the availability and the topics
> that should be approched:
>
>   * https://www.kamailio.org/wiki/devel/irc-meetings/2019a
>
> Feel free to add yourself there, propose topics, etc...
>
> Cheers,
> Daniel
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
Washington, DC, USA -- www.asipto.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 can I put updated sdp body to message in kemi

[Daniel-Constantin Mierla]

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
> 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 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 World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
Washington, DC, USA -- www.asipto.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 can I put updated sdp body to message in kemi

[Yuriy Gorlichenko]

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 case of using kemi
> Is There is some additional way to do this?
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] How can I put updated sdp body to message in kemi

[Yuriy Gorlichenko]

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 Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] bad transport for sips uri?

[David Cunningham]

 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 older version, just before use of record_route inside
> kamailio.cfg, do:
>
> if (uri=~"^sips:") {
>
>$ru = "sip:" + $(ru{s.substr,5,0});
>
> }
>
> The presence of sips in r-uri of invite forces rr to set record-route with
> sips, but this results in some UAs just clone the uri scheme, not really
> understanding its purpose, anyhow, as already mentioned here, sips is a
> mess over all, so disabling it is safer. That's why I started to add
> options to kamailio to just ignore it.
>
> Cheers,
> Daniel
> On 24.02.19 23:31, David Cunningham wrote:
>
> Hi Daniel,
>
> Certainly, here is the sequence including INVITE and 200 OK. I note that
> the Contact on the 200 OK doesn't mention TLS, but the Record-Route header
> does.
> Thank you.
>
> Session Initiation Protocol (INVITE)
> Request-Line: INVITE sips:1...@es8.example.com:5061 SIP/2.0
> Message Header
> Via: SIP/2.0/TLS 50.78.xx.xx:5061;branch=z9hG4bK1836763299
> Route: 
> From: ES8 Test 102  >;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b
> To: 
> Call-ID: 222...@50.78.xx.xx
> CSeq: 94679 INVITE
> Contact: 
> 
> Supported: 100rel
> Proxy-Authorization: Digest username="11", realm="
> es8.example.com", nonce="XG71VFxu9CjpZnZTIQhhf5V1KmKWmQes", uri="
> sip:105@192.168.3.1;user=phone",
> response="60059b561416f1a184d556d5cf116014", algorithm=MD5
> Max-Forwards: 70
> User-Agent: ewb2bua/15.3.0
> Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO,
> PRACK, UPDATE, MESSAGE
> Content-Type: application/sdp
> Content-Length:   387
> Message Body
>
>
> Session Initiation Protocol (200)
> Status-Line: SIP/2.0 200 OK
> Message Header
> Via: SIP/2.0/TLS
> 50.78.xx.xx:5061;rport=43290;branch=z9hG4bK1836763299
> Record-Route: 
> Record-Route: 
> From: ES8 Test 102  >;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b
> To: ;tag=as7a72b209
> Call-ID: 222...@50.78.xx.xx
> CSeq: 94679 INVITE
> Server: ES8
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
> NOTIFY, INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Contact:  
> Content-Type: application/sdp
> Content-Length: 337
> Message Body
>
>
> Session Initiation Protocol (ACK)
> Request-Line: ACK sips:1...@70.42.xx.xx:5070 SIP/2.0
> Message Header
> Via: SIP/2.0/TLS 50.78.yy.yy:5061;branch=z9hG4bK741961203
> Route: 
> Route: 
> From: ES8 Test 102  >;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b
> To: ;tag=as7a72b209
> Call-ID: 222...@50.78.yy.yy
> CSeq: 94679 ACK
> Contact: 
> 
> Max-Forwards: 70
> User-Agent: ewb2bua/15.3.0
> Content-Length: 0
>
>
> On Fri, 22 Feb 2019 at 20:16, Daniel-Constantin Mierla 
> wrote:
>
>> Hello,
>>
>> do you have the INVITE and the 200ok corresponding to this ACK? I need to
>> see the R-URI of INVITE as well as the contact in 200ok in order to analyze
>> why sips appears in ACK.
>>
>> SIPS requirements are sort of a mess, probably the best would be to let
>> it for config to decide when to allow forwarding or not in case of sips URI.
>>
>> Cheers,
>> Daniel
>> On 22.02.19 02:58, David Cunningham wrote:
>>
>> Hello all,
>>
>> We're having an issue with Kamailio not processing an ACK and hope
>> someone can help. A PCAP shows that Kamailio is receiving the ACK, and we
>> believe these log messages are directly related to it:
>>
>> Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: tm [ut.h:279]:
>> uri2dst2(): ERROR: uri2dst: bad transport for sips uri: 1
>> Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: tm [t_fwd.c:1777]:
>> t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches
>> Feb 21 10:54:01 hostname /sbin/kamailio[15854]: ERROR: sl
>> [sl_funcs.c:387]: sl_reply_error(): ERROR: sl_reply_error used:
>> Unresolvable destination (478/SL)
>>
>> The ACK is as follows. It's from telephone 11 which is using TLS,
>> which Kamailio listens for on port 5061.
>> Does anyone know which URI has the bad transport as per the error above?
>> Might it be the From URI "sips:111...@es8.example.com" because it
>> doesn't specify port 5061?
>> Thank you in advance.
>>
>> Session Initiation Protocol (ACK)
>> Request-Line: ACK sips:1...@70.42.xx.xx:5070 SIP/2.0
>> Message Header
>> Via: SIP/2.0/TLS 50.78.yy.yy:5061;branch=z9hG4bK741961203
>> Route: 
>> Route: 
>> From: ES8 Test 102 > >;tag=Nf5GG!Orq!MSmGfeu66F03F2114df82b
>> To: ;tag=as7a72b209
>> Call-ID: 222...@50.78.yy.yy
>> CSeq: 94679