date:20190326

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

2019-03-26 Thread Alex Balashov

I use named flags very extensively, but only in the uncontroversial contexts 
Daniel mentions.

--
Sent from my iPad

> On Mar 26, 2019, at 9:46 PM, Joel Serrano  wrote:
> 
> I was just about to ask exactly about that as I didn't understand the 
> differences... :)
> 
> I guess I'll take the #!define way to do it!
> 
> Thanks Daniel!! 
> 
>> On Tue, Mar 26, 2019 at 6:21 PM Daniel-Constantin Mierla  
>> wrote:
>> Bringing in few more details ...
>> 
>> The named flags feature was added by SER developer during 2005-2008, when 
>> Kamailio (well, openser at that time) and SER were different projects. In 
>> 2008, as we started merging the source trees of Kamailio and SER back in one 
>> repo (which became what is not Kamailio project), named flags were 
>> propagated.
>> 
>> However, as for a personal experience, I never took the time to play with 
>> them to see if they can be used "everywhere" -- for sure you can use then in 
>> setflag/resetflag/isflagset functions, but I am not sure if they work for 
>> branch flags and module parameters, or other places where a flag index is 
>> expected.
>> 
>> In Kamailio we had the #!define feature that allowed to give a "name" for a 
>> flag and that's how we have in default kamailio.cfg -- somewhere at the top 
>> you can see #!define for FLT_* and FLB_* flags.
>> 
>> Cheers,
>> Daniel
>> 
>>> On 27.03.19 00:22, Joel Serrano wrote:
>>> Wonderful!!!
>>> 
>>> This is perfect: 
>>> http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#names_for_route_blocks_and_flags
>>> 
>>> 
>>> Thanks Alex :)
>>> 
 On Tue, Mar 26, 2019 at 4:15 PM Alex Balashov  
 wrote:
 Hi Joel,
 
 Yes, this is a gap in the core cookbook documentation. 
 
 I learned about named flags back in the day:
 
 http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x
 
 -- Alex
 
 On Tue, Mar 26, 2019 at 04:04:29PM -0700, Joel Serrano wrote:
 
 > Hi,
 > 
 > I saw in the Kazoo default.cfg this:
 > 
 > ...
 > ### Flags ###
 > flags
 > FLAG_INTERNALLY_SOURCED:  1,
 > FLAG_ASSOCIATE_SERVER:2,
 > FLAG_SKIP_NAT_CORRECTION: 3,
 > FLAG_ASSOCIATE_USER:  4,
 > FLAG_TRUSTED_SOURCE:  5,
 > FLAG_SESSION_PROGRESS:6,
 > FLAG_IS_REPLY:7,
 > FLAG_SIP_TRACE:   8;
 > ...
 > 
 > 
 > So then I went here to read about it:
 > https://www.kamailio.org/wiki/cookbooks/5.2.x/core#flags
 > 
 > I found out it's not documented... is this a drop-in alternative for a:
 > #!define FLAG_NAME FLAG_BIT?
 > 
 > Sorry, first time I see this if not I would update the docs myself... :(
 > 
 > Thanks,
 > Joel.
 
 > ___
 > 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
>>> 
>>> 
>>> ___
>>> 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 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
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

2019-03-26 Thread Joel Serrano

I was just about to ask exactly about that as I didn't understand the
differences... :)

I guess I'll take the #!define way to do it!

Thanks Daniel!!

On Tue, Mar 26, 2019 at 6:21 PM Daniel-Constantin Mierla 
wrote:

> Bringing in few more details ...
>
> The named flags feature was added by SER developer during 2005-2008, when
> Kamailio (well, openser at that time) and SER were different projects. In
> 2008, as we started merging the source trees of Kamailio and SER back in
> one repo (which became what is not Kamailio project), named flags were
> propagated.
>
> However, as for a personal experience, I never took the time to play with
> them to see if they can be used "everywhere" -- for sure you can use then
> in setflag/resetflag/isflagset functions, but I am not sure if they work
> for branch flags and module parameters, or other places where a flag index
> is expected.
>
> In Kamailio we had the #!define feature that allowed to give a "name" for
> a flag and that's how we have in default kamailio.cfg -- somewhere at the
> top you can see #!define for FLT_* and FLB_* flags.
>
> Cheers,
> Daniel
> On 27.03.19 00:22, Joel Serrano wrote:
>
> Wonderful!!!
>
> This is perfect:
> http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#names_for_route_blocks_and_flags
>
>
> Thanks Alex :)
>
> On Tue, Mar 26, 2019 at 4:15 PM Alex Balashov 
> wrote:
>
>> Hi Joel,
>>
>> Yes, this is a gap in the core cookbook documentation.
>>
>> I learned about named flags back in the day:
>>
>> http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x
>>
>> -- Alex
>>
>> On Tue, Mar 26, 2019 at 04:04:29PM -0700, Joel Serrano wrote:
>>
>> > Hi,
>> >
>> > I saw in the Kazoo default.cfg this:
>> >
>> > ...
>> > ### Flags ###
>> > flags
>> > FLAG_INTERNALLY_SOURCED:  1,
>> > FLAG_ASSOCIATE_SERVER:2,
>> > FLAG_SKIP_NAT_CORRECTION: 3,
>> > FLAG_ASSOCIATE_USER:  4,
>> > FLAG_TRUSTED_SOURCE:  5,
>> > FLAG_SESSION_PROGRESS:6,
>> > FLAG_IS_REPLY:7,
>> > FLAG_SIP_TRACE:   8;
>> > ...
>> >
>> >
>> > So then I went here to read about it:
>> > https://www.kamailio.org/wiki/cookbooks/5.2.x/core#flags
>> >
>> > I found out it's not documented... is this a drop-in alternative for a:
>> > #!define FLAG_NAME FLAG_BIT?
>> >
>> > Sorry, first time I see this if not I would update the docs myself... :(
>> >
>> > Thanks,
>> > Joel.
>>
>> > ___
>> > 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
>>
>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - 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] flags definition in kamailio.cfg + 5.2 documentation

2019-03-26 Thread Daniel-Constantin Mierla

Bringing in few more details ...

The named flags feature was added by SER developer during 2005-2008,
when Kamailio (well, openser at that time) and SER were different
projects. In 2008, as we started merging the source trees of Kamailio
and SER back in one repo (which became what is not Kamailio project),
named flags were propagated.

However, as for a personal experience, I never took the time to play
with them to see if they can be used "everywhere" -- for sure you can
use then in setflag/resetflag/isflagset functions, but I am not sure if
they work for branch flags and module parameters, or other places where
a flag index is expected.

In Kamailio we had the #!define feature that allowed to give a "name"
for a flag and that's how we have in default kamailio.cfg -- somewhere
at the top you can see #!define for FLT_* and FLB_* flags.

Cheers,
Daniel

On 27.03.19 00:22, Joel Serrano wrote:
> Wonderful!!!
>
> This is perfect:
> http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#names_for_route_blocks_and_flags
>
>
> Thanks Alex :)
>
> On Tue, Mar 26, 2019 at 4:15 PM Alex Balashov
> mailto:abalas...@evaristesys.com>> wrote:
>
> Hi Joel,
>
> Yes, this is a gap in the core cookbook documentation.
>
> I learned about named flags back in the day:
>
> http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x
>
> -- Alex
>
> On Tue, Mar 26, 2019 at 04:04:29PM -0700, Joel Serrano wrote:
>
> > Hi,
> >
> > I saw in the Kazoo default.cfg this:
> >
> > ...
> > ### Flags ###
> > flags
> >     FLAG_INTERNALLY_SOURCED:  1,
> >     FLAG_ASSOCIATE_SERVER:    2,
> >     FLAG_SKIP_NAT_CORRECTION: 3,
> >     FLAG_ASSOCIATE_USER:      4,
> >     FLAG_TRUSTED_SOURCE:      5,
> >     FLAG_SESSION_PROGRESS:    6,
> >     FLAG_IS_REPLY:            7,
> >     FLAG_SIP_TRACE:           8;
> > ...
> >
> >
> > So then I went here to read about it:
> > https://www.kamailio.org/wiki/cookbooks/5.2.x/core#flags
> >
> > I found out it's not documented... is this a drop-in alternative
> for a:
> > #!define FLAG_NAME FLAG_BIT?
> >
> > Sorry, first time I see this if not I would update the docs
> myself... :(
> >
> > Thanks,
> > Joel.
>
> > ___
> > 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
>
>
> ___
> 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 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] flags definition in kamailio.cfg + 5.2 documentation

2019-03-26 Thread Joel Serrano

Wonderful!!!

This is perfect:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x#names_for_route_blocks_and_flags


Thanks Alex :)

On Tue, Mar 26, 2019 at 4:15 PM Alex Balashov 
wrote:

> Hi Joel,
>
> Yes, this is a gap in the core cookbook documentation.
>
> I learned about named flags back in the day:
>
> http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x
>
> -- Alex
>
> On Tue, Mar 26, 2019 at 04:04:29PM -0700, Joel Serrano wrote:
>
> > Hi,
> >
> > I saw in the Kazoo default.cfg this:
> >
> > ...
> > ### Flags ###
> > flags
> > FLAG_INTERNALLY_SOURCED:  1,
> > FLAG_ASSOCIATE_SERVER:2,
> > FLAG_SKIP_NAT_CORRECTION: 3,
> > FLAG_ASSOCIATE_USER:  4,
> > FLAG_TRUSTED_SOURCE:  5,
> > FLAG_SESSION_PROGRESS:6,
> > FLAG_IS_REPLY:7,
> > FLAG_SIP_TRACE:   8;
> > ...
> >
> >
> > So then I went here to read about it:
> > https://www.kamailio.org/wiki/cookbooks/5.2.x/core#flags
> >
> > I found out it's not documented... is this a drop-in alternative for a:
> > #!define FLAG_NAME FLAG_BIT?
> >
> > Sorry, first time I see this if not I would update the docs myself... :(
> >
> > Thanks,
> > Joel.
>
> > ___
> > 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
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

2019-03-26 Thread Alex Balashov

Hi Joel,

Yes, this is a gap in the core cookbook documentation. 

I learned about named flags back in the day:

http://www.kamailio.org/dokuwiki/doku.php/features:new-in-3.0.x

-- Alex

On Tue, Mar 26, 2019 at 04:04:29PM -0700, Joel Serrano wrote:

> Hi,
> 
> I saw in the Kazoo default.cfg this:
> 
> ...
> ### Flags ###
> flags
> FLAG_INTERNALLY_SOURCED:  1,
> FLAG_ASSOCIATE_SERVER:2,
> FLAG_SKIP_NAT_CORRECTION: 3,
> FLAG_ASSOCIATE_USER:  4,
> FLAG_TRUSTED_SOURCE:  5,
> FLAG_SESSION_PROGRESS:6,
> FLAG_IS_REPLY:7,
> FLAG_SIP_TRACE:   8;
> ...
> 
> 
> So then I went here to read about it:
> https://www.kamailio.org/wiki/cookbooks/5.2.x/core#flags
> 
> I found out it's not documented... is this a drop-in alternative for a:
> #!define FLAG_NAME FLAG_BIT?
> 
> Sorry, first time I see this if not I would update the docs myself... :(
> 
> Thanks,
> Joel.

> ___
> 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] Disable Dispatcher GW from DB

2019-03-26 Thread Patrick Wakano

Great Daniel! I will create a ticket for that then!
Cheers,
Patrick Wakano


On Tue, 26 Mar. 2019, 00:30 Daniel-Constantin Mierla, 
wrote:

> Hello,
>
> that could be a good option indeed, probably a function parameter to
> control this kind of behaviour.
>
> Cheers,
> Daniel
> On 25.03.19 02:03, Patrick Wakano wrote:
>
> Hello list,
> Hope you are all well!
>
> I just saw a related situation regarding a disabled GW in dispatcher
> module.
> In case I have a disabled GW the function ds_is_from_list() still matches
> and returns true.
> Is that expected? If so, maybe it could have an option to match only the
> non-disabled GWs. Would that be reasonable?
>
> Cheers,
> Patrick Wakano
>
> On Wed, 6 Mar 2019 at 10:01, Patrick Wakano  wrote:
>
>> Thanks Dmitri!
>> It worked like a charm!
>> Cheers,
>> Patrick Wakano
>>
>> On Tue, 5 Mar. 2019, 18:42 Dmitri Savolainen, 
>> wrote:
>>
>>> hi Patrick
>>> You may set flag=4 in "dispatcher" table for appropriate GW
>>>
>>> On Tue, 5 Mar 2019 at 04:57, Patrick Wakano  wrote:
>>>
 Hello list,
 Hope you are all doing well!

 I am looking for a way to disable a Dispatcher GW from the DB. I know I
 can disable it using the "kamcmd dispatcher.set_state d ..."command, but in
 case I do a reload or restart after that, the disabled GW will be back as
 active.
 Of course I could also delete the GW from DB, but for CDR purposes I
 want to keep the entry but mark as permanently disabled, so Kamailio won't
 try to use it nor ping it anymore. Does anyone how can I do that in the DB?
 I am looking for the exact same behavior the "kamcmd dispatcher.set_state
 d" does but from some change in the DB.

 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

>>>
>>>
>>> --
>>> Savolainen Dmitri
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
> ___
> Kamailio (SER) - Users Mailing 
> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - 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

[SR-Users] flags definition in kamailio.cfg + 5.2 documentation

2019-03-26 Thread Joel Serrano

Hi,

I saw in the Kazoo default.cfg this:

...
### Flags ###
flags
FLAG_INTERNALLY_SOURCED:  1,
FLAG_ASSOCIATE_SERVER:2,
FLAG_SKIP_NAT_CORRECTION: 3,
FLAG_ASSOCIATE_USER:  4,
FLAG_TRUSTED_SOURCE:  5,
FLAG_SESSION_PROGRESS:6,
FLAG_IS_REPLY:7,
FLAG_SIP_TRACE:   8;
...


So then I went here to read about it:
https://www.kamailio.org/wiki/cookbooks/5.2.x/core#flags

I found out it's not documented... is this a drop-in alternative for a:
#!define FLAG_NAME FLAG_BIT?

Sorry, first time I see this if not I would update the docs myself... :(

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

Re: [SR-Users] DBText does not exists!

2019-03-26 Thread Henning Westerholt

Am Dienstag, 26. März 2019, 15:23:05 CET schrieb Andrew White:
> I’ve done a completely fresh machine using the config from the GitHub issues
> using Amazon Linux 2 and registration is sending. I’m unsure what is
> varying, but I think I’ll rebuild this whole thing as an Ansible playbook
> anyway so I can redeploy quickly.

Hello Andrew,

the error below is from the config, that it can't resolve the sip.example.com 
domain. You need to replace this domain with a domain that you own, or use IP 
addresses.

Best regards,

Henning

 
> Here’s the bash history for anyone curious:
> 
> 1  yum install -y gcc gcc-c++ bison flex make ruby-devel git
> 2  git clone https://github.com/kamailio/kamailio.git
> 3  cd kamailio/
> 4  make include_modules="app_ruby" cfg
> 5  make all &&  make install
> 6  cd /usr/local/etc/kamailio/
> 7  ls
> 8  vim kamailio.cfg
> 9  vim /etc/systemd/system/multi-user.target.wants/kamailio.service
>10  systemctl daemon-reload
>11  systemctl start kamailio
>12  tail  -f /var/log/messages
>13  ls
>14  mkdir /usr/local/etc/kamailio/dbtext
>15  cd /usr/local/etc/kamailio/dbtext
>16  ls
>17  vim uacreg
>18  systemctl restart kamailio
>19  tail  -f /var/log/messages
> 
> Mar 26 14:18:00 ip-10-0-0-3 /usr/local/sbin/kamailio[17873]: ERROR: 
> [core/resolve.c:1698]: sip_hostport2su(): could not resolve hostname:
> "sip.example.org" Mar 26 14:18:00 ip-10-0-0-3
> /usr/local/sbin/kamailio[17873]: ERROR: tm [ut.h:309]: uri2dst2(): failed
> to resolve "sip.example.org" Mar 26 14:18:00 ip-10-0-0-3
> /usr/local/sbin/kamailio[17873]: ERROR: tm [uac.c:452]: t_uac_prepare(): no
> socket found Mar 26 14:18:00 ip-10-0-0-3 /usr/local/sbin/kamailio[17873]:
> ERROR: uac [uac_reg.c:1181]: uac_reg_update(): failed to send request for
> [12345678]
> 
> If anyone can help find the issue I’d be very interested, however it looks
> like issue is package/config somewhere rather than kamailio.
> 
> Thanks
> 
> 
> 
> Andrew White - Director
> uConnected
> Email: and...@uconnected.com.au
> Web: www.uConnected.com.au
> 
> > On 27 Mar 2019, at 12:23 am, Andrew White 
> > wrote:
> > 
> > Update:
> > 
> > I’ve just tried the config from the GitHub issue on another server (CentOS
> > 7) and get the following console output:
> > 
> > Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: 
> > [core/resolve.c:1699]: sip_hostport2su(): could not resolve hostname:
> > "sip.example.org " Mar 26 13:08:48 voice-test2
> > /usr/local/sbin/kamailio[29762]: ERROR: tm [ut.h:309]: uri2dst2(): failed
> > to resolve "sip.example.org " Mar 26 13:08:48
> > voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: tm [uac.c:452]:
> > t_uac_prepare(): no socket found Mar 26 13:08:48 voice-test2
> > /usr/local/sbin/kamailio[29762]: ERROR: uac [uac_reg.c:1181]:
> > uac_reg_update(): failed to send request for [12345678]
> > 
> > This looks to me like it is attempting registration and failing.
> > 
> > I’ve tried this same config on my main server (Amazon Linux 2) and am not
> > getting any such messages.
> > 
> > Both are built from the same master commit:
> > 
> > AL2:
> > 
> > version: kamailio 5.3.0-dev4 (x86_64/linux) 97189d
> > flags: STATS: Off, 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 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: 97189d
> > compiled on 13:18:22 Mar 26 2019 with gcc 7.3.1
> > 
> > CentOS 7:
> > 
> > version: kamailio 5.3.0-dev4 (x86_64/linux) 97189d
> > flags: STATS: Off, 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 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: 97189d
> > compiled on 13:52:08 Mar 23 2019 with gcc 4.8.5
> > 
> > I’m assuming we’re missing a package, a socket definition varies,
> > something like that. How can I further debug this?
> > 
> > Thanks!
> > 
> > Andrew
> > 
> >> On 27 Mar 2019, at 12:01 am, Andrew White  >> > wrote:
> >> 
> >> Thanks so much Miko!
> >> 
> >> You’re completely right. This is also in the docs for the module, it
> >> appears I’ve skimmed over that part!
> >> 
> >> It appears the DB is now loading without error,

[SR-Users] TCP connection lifetime

2019-03-26 Thread Aymeric Moizard

Hi Again,

Here is an issue with TCP connection being kept for more:

Yesterday, I have discovered that a User-Agent ( tried to register a lot. It was sending REGISTER
over new established TCP socket *every 2 seconds*.

All the REGISTER was rejected with 401. (may be the device was
misconfigured? or not receiving any of my answer? I can't tell)

NOTE: You can see the expires header was very large: 86400, ie: 24 hours...

I was checking the TCP/TLS connections on my server and discovered more
than 1000 TCP established connection to that user/ip, and thus, I have
tried to understand what happened.

Checking the logs, I received 4855 REGISTER from this device from "Mar 25
03:47:09" to "Mar 25 07:56:13" which is a rate of approx one new TCP
connection every 2.5 seconds...

Today, I decided to check it again around 11am.

jack@sip:~$ sudo kamctl stats tcp
{
  "jsonrpc":  "2.0",
  "result": [
"tcp:con_reset = 1857",
"tcp:con_timeout = 35927",
"tcp:connect_failed = 25",
"tcp:connect_success = 2",
"tcp:current_opened_connections = 2291",
"tcp:current_write_queue_size = 0",
"tcp:established = 80778",
"tcp:local_reject = 0",
"tcp:passive_open = 80776",
"tcp:send_timeout = 2",
"tcp:sendq_full = 0"
  ],
  "id": 7305
}

There was still A LOT of established connections. And the connections have
been established more than 24 hours ago.

At 11H16:
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
1161
At 11H22:
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
1018
At 11H35:
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
655
At 13H
$> lsof -n -l | grep kamailio | grep TCP | grep 41.234.242.69 | grep ESTA |
wc -l
0

So the established connections are all gone now.

Between 11h16 and 11H35, I was seeing the server regularly sending [FIN,
ACK] over each TCP established connection, with retransmissions for all of
them. (no incoming trafic)

I do not have numbers/capture/stats, but I think that kamailio was already
closing some
connection yesterday. I don't know when kamailio started to try closing
those connections.

I'm now back with this status:

At 13pm:
jack@sip:~$ sudo kamctl stats tcp
{
  "jsonrpc":  "2.0",
  "result": [
"tcp:con_reset = 1896",
"tcp:con_timeout = 38042",
"tcp:connect_failed = 26",
"tcp:connect_success = 2",
"tcp:current_opened_connections = 939",
"tcp:current_write_queue_size = 0",
"tcp:established = 81950",
"tcp:local_reject = 0",
"tcp:passive_open = 81948",
"tcp:send_timeout = 2",
"tcp:sendq_full = 0"
  ],
  "id": 12734
}

With around 155 registration entries using TCP and TLS in my location
database.

As you can see, tcp:current_opened_connections = 939 is still pretty high
compared to
my currently registred users.

I have "modparam("registrar", "max_expires", 86400)", because I'm keeping
contact entries (even with TCP connection down) for push notifications.

I have "tcp_connection_lifetime=3600" configured.

Question 1

With "tcp_connection_lifetime=3600", I would expect kamailio to close the
established connection after 3600 seconds without traffic. It is pretty
obvious that no data has been exchanged over the 4855 established
connection during a day.

Despite the issue with the Avaya phones is solved automatically after a
day, I guess similar stuff or happening, at a different rate, for other
users as well. (because  current_opened_connections is way higher than
registred TCP/TLS users)

Question 2

I can list TLS connection with "kamctl rpc tls.list"
Can I get a similar list for TCP? (lsof returns a lot of duplicates...)

Tks
Aymeric

-- 
Antisip - http://www.antisip.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 stop to process incoming SIP traffic via TCP.

2019-03-26 Thread Daniel-Constantin Mierla

Hello,

yep, locking there is expected, as listing the tls connections wait for
no other processes to change the content of internal tls connection
structures. So it is a side effect of libssl/libcrypto getting stuck and
the other processing waiting for it to move one. I have the Kamailio
training in USA these days, so the trip and schedule of the day didn't
allow me to look more at the libsll/libcrypto code in order to find a
solution here. It is a high priority in my list, as I get time during
the next days.

Cheers,
Daniel

On 26.03.19 15:55, Aymeric Moizard wrote:
> Hi All,
>
> I was debugging a TCP issue (most probably, I may start a thread for
> this question).
>
> I was trying to get some info for TCP and TLS.
>
> I typed:
> $> sudo kamctl rpc tls.list
>
> And waited for a while until... I realized that my User-Agent,
> connected with TCP was not able to register any more. I think the rpc
> command has introduced something wrong.
>
> The device can successfully "connect", send the REGISTER over the
> established TCP connection. The REGISTER do not appear in the logs any
> more, I don't see any traffic for TCP any more. So the behavior is the
> same as I had before: TCP and TLS are both not working and UDP is
> still working fine.
>
> kamctl do not work any more... so kamctl trap do not work...
>
> I have been able to type.. manually... for (all?) kamailio threads:
>
> gdb /usr/sbin/kamailio 16500 -batch --eval-command="bt full" >>
> kamailio-trap-tcp-down.txt
>
> I'm temporarly puting the backtrace I have here:
> https://sip.antisip.com/kamailio-trap-tcp-down.txt
>
> You can see a thread stuck on the json command line: "tls_list"
> And many other waiting on CRYPTO_THREAD_write_lock
> ? might be related to: https://github.com/openssl/openssl/issues/5376
> SIDE NOTE:
> Right before I was typing the last gdb command for the last thread,
> kamailio
> has crashed: This was around 5 minutes after the dead lock started.
>
> Mar 26 14:47:11 sip kamailio[16493]: ERROR: 
> [core/tcp_main.c:2561]: tcpconn_do_send(): failed to send on
> 0x7ff8dfc2fdc8 (91.121.30.149:5061->62.210.97.21:49351
> ): Broken pipe (32)
> Mar 26 14:47:11 sip kamailio[16493]: ERROR: 
> [core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req: error
> reading - c: 0x7ff8dfc2fdc8 r: 0x7ff8dfc2fe48 (-1)
> Mar 26 14:47:11 sip kamailio[16493]: WARNING: 
> [core/tcp_read.c:1848]: handle_io(): F_TCPCONN connection marked as
> bad: 0x7ff8dfa6a408 id 846 refcnt 3
> Mar 26 14:47:11 sip kamailio[16371]: ALERT:  [main.c:755]:
> handle_sigs(): child process 16374 exited by a signal 11
> Mar 26 14:47:11 sip kamailio[16371]: ALERT:  [main.c:758]:
> handle_sigs(): core was not generated
> Mar 26 14:47:11 sip kamailio[16371]: INFO:  [main.c:781]:
> handle_sigs(): terminating due to SIGCHLD
> Mar 26 14:47:11 sip kamailio[16493]: INFO:  [main.c:836]:
> sig_usr(): signal 15 received
> Mar 26 14:47:11 sip kamailio[16500]: INFO:  [main.c:836]:
> sig_usr(): signal 15 received
> Mar 26 14:47:11 sip kamailio[16479]: INFO:  [main.c:836]:
> sig_usr(): signal 15 received
>
>
> Unfortunalty, even if I did my best to setup my service to generate a
> core on crash, I still have "core was not generated" (debian stretch)
>
> Tks for reading!
> Regards
> Aymeric
>
>
>
> Le mar. 26 mars 2019 à 14:11, Kristijan Vrban  > a écrit :
>
> And again one more kamctl trap file where
>
> set_reply_no_connect was set.
>
> Am Di., 26. März 2019 um 08:53 Uhr schrieb Kristijan Vrban
> mailto:vrban.l...@gmail.com>>:
> >
> > Attached also the output of kamctl trap
> >
> > Am Di., 26. März 2019 um 08:42 Uhr schrieb Kristijan Vrban
> > mailto:vrban.l...@gmail.com>>:
> > >
> > > > Have you done a test with tools such as sipp, or was this
> happening
> > > > after a while, with usual phones registering?
> > >
> > > Usual variety of devices registering via TLS. But i can not
> exclude
> > > that some devices displaying behavioural problems.
> > >
> > > > Can you list the tcp connections and see if they are listed?
> > > > kamctl tcp core.tcp_list
> > >
> > > Need Kex module for that? So i can deliver next time. But when
> i do
> > > "lsof -u kamailio |grep TCP"
> > > i get a long list of more then 2000 lines with:
> > >
> > > ...
> > > kamailio 37561 kamailio 2105u     sock                0,9      0t0
> > > 27856287 protocol: TCP
> > > kamailio 37561 kamailio 2106u     sock                0,9      0t0
> > > 27856305 protocol: TCP
> > > kamailio 37561 kamailio 2107u     sock                0,9      0t0
> > > 27856306 protocol: TCP
> > > kamailio 37561 kamailio 2108u     sock                0,9      0t0
> > > 27856914 protocol: TCP
> > > ...
> > >
> > > So about the time Kamailio created a lot of socket in the TCP
> domain,
> > > but which are not bound to any port (eg

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

2019-03-26 Thread Aymeric Moizard

Hi All,

I was debugging a TCP issue (most probably, I may start a thread for this
question).

I was trying to get some info for TCP and TLS.

I typed:
$> sudo kamctl rpc tls.list

And waited for a while until... I realized that my User-Agent,
connected with TCP was not able to register any more. I think the rpc
command has introduced something wrong.

The device can successfully "connect", send the REGISTER over the
established TCP connection. The REGISTER do not appear in the logs any
more, I don't see any traffic for TCP any more. So the behavior is the same
as I had before: TCP and TLS are both not working and UDP is still working
fine.

kamctl do not work any more... so kamctl trap do not work...

I have been able to type.. manually... for (all?) kamailio threads:

gdb /usr/sbin/kamailio 16500 -batch --eval-command="bt full" >>
kamailio-trap-tcp-down.txt

I'm temporarly puting the backtrace I have here:
https://sip.antisip.com/kamailio-trap-tcp-down.txt

You can see a thread stuck on the json command line: "tls_list"
And many other waiting on CRYPTO_THREAD_write_lock

? might be related to: https://github.com/openssl/openssl/issues/5376

SIDE NOTE:
Right before I was typing the last gdb command for the last thread, kamailio
has crashed: This was around 5 minutes after the dead lock started.

Mar 26 14:47:11 sip kamailio[16493]: ERROR:  [core/tcp_main.c:2561]:
tcpconn_do_send(): failed to send on 0x7ff8dfc2fdc8 (91.121.30.149:5061->
62.210.97.21:49351): Broken pipe (32)
Mar 26 14:47:11 sip kamailio[16493]: ERROR:  [core/tcp_read.c:1505]:
tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7ff8dfc2fdc8 r:
0x7ff8dfc2fe48 (-1)
Mar 26 14:47:11 sip kamailio[16493]: WARNING: 
[core/tcp_read.c:1848]: handle_io(): F_TCPCONN connection marked as bad:
0x7ff8dfa6a408 id 846 refcnt 3
Mar 26 14:47:11 sip kamailio[16371]: ALERT:  [main.c:755]:
handle_sigs(): child process 16374 exited by a signal 11
Mar 26 14:47:11 sip kamailio[16371]: ALERT:  [main.c:758]:
handle_sigs(): core was not generated
Mar 26 14:47:11 sip kamailio[16371]: INFO:  [main.c:781]:
handle_sigs(): terminating due to SIGCHLD
Mar 26 14:47:11 sip kamailio[16493]: INFO:  [main.c:836]: sig_usr():
signal 15 received
Mar 26 14:47:11 sip kamailio[16500]: INFO:  [main.c:836]: sig_usr():
signal 15 received
Mar 26 14:47:11 sip kamailio[16479]: INFO:  [main.c:836]: sig_usr():
signal 15 received


Unfortunalty, even if I did my best to setup my service to generate a core
on crash, I still have "core was not generated" (debian stretch)

Tks for reading!
Regards
Aymeric



Le mar. 26 mars 2019 à 14:11, Kristijan Vrban  a
écrit :

> And again one more kamctl trap file where
>
> set_reply_no_connect was set.
>
> Am Di., 26. März 2019 um 08:53 Uhr schrieb Kristijan Vrban
> :
> >
> > Attached also the output of kamctl trap
> >
> > Am Di., 26. März 2019 um 08:42 Uhr schrieb Kristijan Vrban
> > :
> > >
> > > > Have you done a test with tools such as sipp, or was this happening
> > > > after a while, with usual phones registering?
> > >
> > > Usual variety of devices registering via TLS. But i can not exclude
> > > that some devices displaying behavioural problems.
> > >
> > > > Can you list the tcp connections and see if they are listed?
> > > > kamctl tcp core.tcp_list
> > >
> > > Need Kex module for that? So i can deliver next time. But when i do
> > > "lsof -u kamailio |grep TCP"
> > > i get a long list of more then 2000 lines with:
> > >
> > > ...
> > > kamailio 37561 kamailio 2105u sock0,9  0t0
> > > 27856287 protocol: TCP
> > > kamailio 37561 kamailio 2106u sock0,9  0t0
> > > 27856305 protocol: TCP
> > > kamailio 37561 kamailio 2107u sock0,9  0t0
> > > 27856306 protocol: TCP
> > > kamailio 37561 kamailio 2108u sock0,9  0t0
> > > 27856914 protocol: TCP
> > > ...
> > >
> > > So about the time Kamailio created a lot of socket in the TCP domain,
> > > but which are not bound to any port (eg via connect(2) or listen(2) or
> > > bind(2))
> > > Until we get to the maximum number of 2048 connections.
> > >
> > > Best
> > > Kristijan
> > >
> > > Am Mo., 25. März 2019 um 14:27 Uhr schrieb Daniel-Constantin Mierla
> > > :
> > > >
> > > > Have you done a test with tools such as sipp, or was this happening
> > > > after a while, with usual phones registering?
> > > >
> > > > Can you list the tcp connections and see if they are listed?
> > > >
> > > > kamctl tcp core.tcp_list
> > > >
> > > > Cheers,
> > > > Daniel
> > > >
> > > > On 25.03.19 08:03, Kristijan Vrban wrote:
> > > > >> The solution here is to use set_reply_no_connect()
> > > > > implemented it. Now the issue has shifted to:
> > > > >
> > > > > ERROR:  [core/tcp_main.c:3959]: handle_new_connect(): maximum
> > > > > number of connections exceeded: 2048/2048
> > > > >
> > > > > But not a single TCP connection is active between Kamailio and any
> > > > > device. Seems this counter for maximum number of

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

2019-03-26 Thread Kristijan Vrban

> Just curious, did you get to compile with OpenSSL 1.0 and test?

Just compiled with OpenSSL 1.0 . Gone test now.

Am Di., 26. März 2019 um 15:40 Uhr schrieb Joel Serrano :
>
> Just curious, did you get to compile with OpenSSL 1.0 and test?
>
> On Tue, Mar 26, 2019 at 06:12 Kristijan Vrban  wrote:
>>
>> And again one more kamctl trap file where
>>
>> set_reply_no_connect was set.
>>
>> Am Di., 26. März 2019 um 08:53 Uhr schrieb Kristijan Vrban
>> :
>> >
>> > Attached also the output of kamctl trap
>> >
>> > Am Di., 26. März 2019 um 08:42 Uhr schrieb Kristijan Vrban
>> > :
>> > >
>> > > > Have you done a test with tools such as sipp, or was this happening
>> > > > after a while, with usual phones registering?
>> > >
>> > > Usual variety of devices registering via TLS. But i can not exclude
>> > > that some devices displaying behavioural problems.
>> > >
>> > > > Can you list the tcp connections and see if they are listed?
>> > > > kamctl tcp core.tcp_list
>> > >
>> > > Need Kex module for that? So i can deliver next time. But when i do
>> > > "lsof -u kamailio |grep TCP"
>> > > i get a long list of more then 2000 lines with:
>> > >
>> > > ...
>> > > kamailio 37561 kamailio 2105u sock0,9  0t0
>> > > 27856287 protocol: TCP
>> > > kamailio 37561 kamailio 2106u sock0,9  0t0
>> > > 27856305 protocol: TCP
>> > > kamailio 37561 kamailio 2107u sock0,9  0t0
>> > > 27856306 protocol: TCP
>> > > kamailio 37561 kamailio 2108u sock0,9  0t0
>> > > 27856914 protocol: TCP
>> > > ...
>> > >
>> > > So about the time Kamailio created a lot of socket in the TCP domain,
>> > > but which are not bound to any port (eg via connect(2) or listen(2) or
>> > > bind(2))
>> > > Until we get to the maximum number of 2048 connections.
>> > >
>> > > Best
>> > > Kristijan
>> > >
>> > > Am Mo., 25. März 2019 um 14:27 Uhr schrieb Daniel-Constantin Mierla
>> > > :
>> > > >
>> > > > Have you done a test with tools such as sipp, or was this happening
>> > > > after a while, with usual phones registering?
>> > > >
>> > > > Can you list the tcp connections and see if they are listed?
>> > > >
>> > > > kamctl tcp core.tcp_list
>> > > >
>> > > > Cheers,
>> > > > Daniel
>> > > >
>> > > > On 25.03.19 08:03, Kristijan Vrban wrote:
>> > > > >> The solution here is to use set_reply_no_connect()
>> > > > > implemented it. Now the issue has shifted to:
>> > > > >
>> > > > > ERROR:  [core/tcp_main.c:3959]: handle_new_connect(): maximum
>> > > > > number of connections exceeded: 2048/2048
>> > > > >
>> > > > > But not a single TCP connection is active between Kamailio and any
>> > > > > device. Seems this counter for maximum number of connections
>> > > > > now has an issue?
>> > > > >
>> > > > > Kristijan
>> > > > >
>> > > > > Am Mi., 20. März 2019 um 15:07 Uhr schrieb Daniel-Constantin Mierla
>> > > > > :
>> > > > >> Hello,
>> > > > >>
>> > > > >> based on the trap output I think I could figure out what happened 
>> > > > >> there.
>> > > > >>
>> > > > >> You have tcp_children to very low value (1 or so), the problem is 
>> > > > >> not
>> > > > >> actually that one, but the fact that the connection to upstream (the
>> > > > >> device/app sending the request) was closed after receiving the 
>> > > > >> request
>> > > > >> and routing of the reply gets stuck in the way of:
>> > > > >>
>> > > > >>   - a reply is received and has to be forwarded
>> > > > >>   - connection was lost, so Kamailio tries to establish a new one, 
>> > > > >> but
>> > > > >> takes time till fails because the upstream is behind nat or so 
>> > > > >> based on
>> > > > >> the via header:
>> > > > >>
>> > > > >> Via: SIP/2.0/TLS
>> > > > >> 10.1.0.4:10002;rport=55229;received=13.94.188.218;branch=z9hG4bK-3336-7f2927bfd703ae907348edff3611bfc9
>> > > > >>
>> > > > >>   - the reply is retransmitted and gets to another worker, which 
>> > > > >> tries
>> > > > >> to forward it again, but discovers a connection structure for that
>> > > > >> destination exists (created by previous reply worker) and now waits 
>> > > > >> for
>> > > > >> the connection to be released (or better said, for the mutex on 
>> > > > >> writing
>> > > > >> buffer to be unlocked)
>> > > > >>
>> > > > >>   - as the second reply waits, there can be other retransmissions 
>> > > > >> of the
>> > > > >> reply ending up in other workers stuck on waiting for the mutex of 
>> > > > >> the
>> > > > >> connection write buffer
>> > > > >>
>> > > > >> The solution here is to use set_reply_no_connect() -- you can put it
>> > > > >> first in request_route block. I think this would be a good addition 
>> > > > >> to
>> > > > >> the default configuration file as well, IMO, the sip server should 
>> > > > >> not
>> > > > >> connect for sending replies and should do it also for requests that 
>> > > > >> go
>> > > > >> behind nat.
>> > > > >>
>> > > > >> Cheers,
>> > > > >> Daniel
>> > > > >>
>> > > > >> On 19.03.19 10:53, Kristijan

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

2019-03-26 Thread Joel Serrano

Just curious, did you get to compile with OpenSSL 1.0 and test?

On Tue, Mar 26, 2019 at 06:12 Kristijan Vrban  wrote:

> And again one more kamctl trap file where
>
> set_reply_no_connect was set.
>
> Am Di., 26. März 2019 um 08:53 Uhr schrieb Kristijan Vrban
> :
> >
> > Attached also the output of kamctl trap
> >
> > Am Di., 26. März 2019 um 08:42 Uhr schrieb Kristijan Vrban
> > :
> > >
> > > > Have you done a test with tools such as sipp, or was this happening
> > > > after a while, with usual phones registering?
> > >
> > > Usual variety of devices registering via TLS. But i can not exclude
> > > that some devices displaying behavioural problems.
> > >
> > > > Can you list the tcp connections and see if they are listed?
> > > > kamctl tcp core.tcp_list
> > >
> > > Need Kex module for that? So i can deliver next time. But when i do
> > > "lsof -u kamailio |grep TCP"
> > > i get a long list of more then 2000 lines with:
> > >
> > > ...
> > > kamailio 37561 kamailio 2105u sock0,9  0t0
> > > 27856287 protocol: TCP
> > > kamailio 37561 kamailio 2106u sock0,9  0t0
> > > 27856305 protocol: TCP
> > > kamailio 37561 kamailio 2107u sock0,9  0t0
> > > 27856306 protocol: TCP
> > > kamailio 37561 kamailio 2108u sock0,9  0t0
> > > 27856914 protocol: TCP
> > > ...
> > >
> > > So about the time Kamailio created a lot of socket in the TCP domain,
> > > but which are not bound to any port (eg via connect(2) or listen(2) or
> > > bind(2))
> > > Until we get to the maximum number of 2048 connections.
> > >
> > > Best
> > > Kristijan
> > >
> > > Am Mo., 25. März 2019 um 14:27 Uhr schrieb Daniel-Constantin Mierla
> > > :
> > > >
> > > > Have you done a test with tools such as sipp, or was this happening
> > > > after a while, with usual phones registering?
> > > >
> > > > Can you list the tcp connections and see if they are listed?
> > > >
> > > > kamctl tcp core.tcp_list
> > > >
> > > > Cheers,
> > > > Daniel
> > > >
> > > > On 25.03.19 08:03, Kristijan Vrban wrote:
> > > > >> The solution here is to use set_reply_no_connect()
> > > > > implemented it. Now the issue has shifted to:
> > > > >
> > > > > ERROR:  [core/tcp_main.c:3959]: handle_new_connect(): maximum
> > > > > number of connections exceeded: 2048/2048
> > > > >
> > > > > But not a single TCP connection is active between Kamailio and any
> > > > > device. Seems this counter for maximum number of connections
> > > > > now has an issue?
> > > > >
> > > > > Kristijan
> > > > >
> > > > > Am Mi., 20. März 2019 um 15:07 Uhr schrieb Daniel-Constantin Mierla
> > > > > :
> > > > >> Hello,
> > > > >>
> > > > >> based on the trap output I think I could figure out what happened
> there.
> > > > >>
> > > > >> You have tcp_children to very low value (1 or so), the problem is
> not
> > > > >> actually that one, but the fact that the connection to upstream
> (the
> > > > >> device/app sending the request) was closed after receiving the
> request
> > > > >> and routing of the reply gets stuck in the way of:
> > > > >>
> > > > >>   - a reply is received and has to be forwarded
> > > > >>   - connection was lost, so Kamailio tries to establish a new
> one, but
> > > > >> takes time till fails because the upstream is behind nat or so
> based on
> > > > >> the via header:
> > > > >>
> > > > >> Via: SIP/2.0/TLS
> > > > >> 10.1.0.4:10002
> ;rport=55229;received=13.94.188.218;branch=z9hG4bK-3336-7f2927bfd703ae907348edff3611bfc9
> > > > >>
> > > > >>   - the reply is retransmitted and gets to another worker, which
> tries
> > > > >> to forward it again, but discovers a connection structure for that
> > > > >> destination exists (created by previous reply worker) and now
> waits for
> > > > >> the connection to be released (or better said, for the mutex on
> writing
> > > > >> buffer to be unlocked)
> > > > >>
> > > > >>   - as the second reply waits, there can be other retransmissions
> of the
> > > > >> reply ending up in other workers stuck on waiting for the mutex
> of the
> > > > >> connection write buffer
> > > > >>
> > > > >> The solution here is to use set_reply_no_connect() -- you can put
> it
> > > > >> first in request_route block. I think this would be a good
> addition to
> > > > >> the default configuration file as well, IMO, the sip server
> should not
> > > > >> connect for sending replies and should do it also for requests
> that go
> > > > >> behind nat.
> > > > >>
> > > > >> Cheers,
> > > > >> Daniel
> > > > >>
> > > > >> On 19.03.19 10:53, Kristijan Vrban wrote:
> > > > >>> So i had again the situation. But this time, incoming udp was
> > > > >>> affected. Kamailio was sending out OPTIONS (via dispatcher
> module) to
> > > > >>> a group of asterisk machines
> > > > >>> but the 200 OK reply to the OPTIONS where not processed, so the
> > > > >>> dispatcher module set all asterisk to inactive, even though they
> > > > >>> replied 200 OK
> > > > >>>
> > > > >>> Attached the

Re: [SR-Users] DBText does not exists!

2019-03-26 Thread Andrew White

Hi all,

I’ve done a completely fresh machine using the config from the GitHub issues 
using Amazon Linux 2 and registration is sending. I’m unsure what is varying, 
but I think I’ll rebuild this whole thing as an Ansible playbook anyway so I 
can redeploy quickly.

Here’s the bash history for anyone curious:

1  yum install -y gcc gcc-c++ bison flex make ruby-devel git
2  git clone https://github.com/kamailio/kamailio.git
3  cd kamailio/
4  make include_modules="app_ruby" cfg
5  make all &&  make install
6  cd /usr/local/etc/kamailio/
7  ls
8  vim kamailio.cfg
9  vim /etc/systemd/system/multi-user.target.wants/kamailio.service
   10  systemctl daemon-reload
   11  systemctl start kamailio
   12  tail  -f /var/log/messages
   13  ls
   14  mkdir /usr/local/etc/kamailio/dbtext
   15  cd /usr/local/etc/kamailio/dbtext
   16  ls
   17  vim uacreg
   18  systemctl restart kamailio
   19  tail  -f /var/log/messages

Mar 26 14:18:00 ip-10-0-0-3 /usr/local/sbin/kamailio[17873]: ERROR:  
[core/resolve.c:1698]: sip_hostport2su(): could not resolve hostname: 
"sip.example.org"
Mar 26 14:18:00 ip-10-0-0-3 /usr/local/sbin/kamailio[17873]: ERROR: tm 
[ut.h:309]: uri2dst2(): failed to resolve "sip.example.org"
Mar 26 14:18:00 ip-10-0-0-3 /usr/local/sbin/kamailio[17873]: ERROR: tm 
[uac.c:452]: t_uac_prepare(): no socket found
Mar 26 14:18:00 ip-10-0-0-3 /usr/local/sbin/kamailio[17873]: ERROR: uac 
[uac_reg.c:1181]: uac_reg_update(): failed to send request for [12345678]

If anyone can help find the issue I’d be very interested, however it looks like 
issue is package/config somewhere rather than kamailio.

Thanks



Andrew White - Director
uConnected
Email: and...@uconnected.com.au
Web: www.uConnected.com.au

> On 27 Mar 2019, at 12:23 am, Andrew White  wrote:
> 
> Update:
> 
> I’ve just tried the config from the GitHub issue on another server (CentOS 7) 
> and get the following console output:
> 
> Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR:  
> [core/resolve.c:1699]: sip_hostport2su(): could not resolve hostname: 
> "sip.example.org "
> Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: tm 
> [ut.h:309]: uri2dst2(): failed to resolve "sip.example.org 
> "
> Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: tm 
> [uac.c:452]: t_uac_prepare(): no socket found
> Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: uac 
> [uac_reg.c:1181]: uac_reg_update(): failed to send request for [12345678]
> 
> This looks to me like it is attempting registration and failing.
> 
> I’ve tried this same config on my main server (Amazon Linux 2) and am not 
> getting any such messages.
> 
> Both are built from the same master commit:
> 
> AL2:
> 
> version: kamailio 5.3.0-dev4 (x86_64/linux) 97189d
> flags: STATS: Off, 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
> 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: 97189d
> compiled on 13:18:22 Mar 26 2019 with gcc 7.3.1
> 
> CentOS 7:
> 
> version: kamailio 5.3.0-dev4 (x86_64/linux) 97189d
> flags: STATS: Off, 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
> 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: 97189d
> compiled on 13:52:08 Mar 23 2019 with gcc 4.8.5
> 
> I’m assuming we’re missing a package, a socket definition varies, something 
> like that. How can I further debug this?
> 
> Thanks!
> 
> Andrew
> 
>> On 27 Mar 2019, at 12:01 am, Andrew White > > wrote:
>> 
>> Thanks so much Miko!
>> 
>> You’re completely right. This is also in the docs for the module, it appears 
>> I’ve skimmed over that part!
>> 
>> It appears the DB is now loading without error, however I don’t see any 
>> attempting for registration in Wireshark. A kamcmd uac.reg_dump doesn’t 
>> return any result.
>> 
>> I’ve copied config shown to be working from a GitHub issue on an unrelated 
>> problem (https://github.com/kamailio/kamailio/issues/936 
>> ). Relevant lines below:
>> 
>> #!define DBURL "text:///etc/kamailio/dbtext "
>> 
>> modparam("rr", "append_fromtag", 1)
>> modparam("dialog",

Re: [SR-Users] DBText does not exists!

2019-03-26 Thread Andrew White

Update:

I’ve just tried the config from the GitHub issue on another server (CentOS 7) 
and get the following console output:

Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR:  
[core/resolve.c:1699]: sip_hostport2su(): could not resolve hostname: 
"sip.example.org"
Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: tm 
[ut.h:309]: uri2dst2(): failed to resolve "sip.example.org"
Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: tm 
[uac.c:452]: t_uac_prepare(): no socket found
Mar 26 13:08:48 voice-test2 /usr/local/sbin/kamailio[29762]: ERROR: uac 
[uac_reg.c:1181]: uac_reg_update(): failed to send request for [12345678]

This looks to me like it is attempting registration and failing.

I’ve tried this same config on my main server (Amazon Linux 2) and am not 
getting any such messages.

Both are built from the same master commit:

AL2:

version: kamailio 5.3.0-dev4 (x86_64/linux) 97189d
flags: STATS: Off, 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
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: 97189d
compiled on 13:18:22 Mar 26 2019 with gcc 7.3.1

CentOS 7:

version: kamailio 5.3.0-dev4 (x86_64/linux) 97189d
flags: STATS: Off, 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
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: 97189d
compiled on 13:52:08 Mar 23 2019 with gcc 4.8.5

I’m assuming we’re missing a package, a socket definition varies, something 
like that. How can I further debug this?

Thanks!

Andrew

> On 27 Mar 2019, at 12:01 am, Andrew White  wrote:
> 
> Thanks so much Miko!
> 
> You’re completely right. This is also in the docs for the module, it appears 
> I’ve skimmed over that part!
> 
> It appears the DB is now loading without error, however I don’t see any 
> attempting for registration in Wireshark. A kamcmd uac.reg_dump doesn’t 
> return any result.
> 
> I’ve copied config shown to be working from a GitHub issue on an unrelated 
> problem (https://github.com/kamailio/kamailio/issues/936 
> ). Relevant lines below:
> 
> #!define DBURL "text:///etc/kamailio/dbtext "
> 
> modparam("rr", "append_fromtag", 1)
> modparam("dialog", "dlg_flag", 4)
> modparam("dialog", "track_cseq_updates", 1)
> modparam("uac", "restore_dlg", 1)
> modparam("uac", "reg_db_url", DBURL)
> modparam("uac", "reg_timer_interval", 60)
> modparam("uac", "reg_retry_interval", 60)
> modparam("uac", "reg_contact_addr", "1.2.3.4:5060")
> 
> And /etc/kamailio/dbtext/uacreg:
> 
> l_uuid(string) l_username(string) l_domain(string) r_username(string) 
> r_domain(string) realm(string) auth_username(string) auth_password(string) 
> auth_proxy(string) expires(int) flags(int) reg_delay(int) 
> 12345678:user:domain.local::sip.example.org 
> :sip.example.org 
> :::sip\:sip.example.org:600 
> :0:0
> 
> Both an lsof and a WITH_DEBUG show uac.so is being loaded without issue, 
> however no messages relevant to registration are showing, and no REGISTER 
> messages appear in Wireshark.
> 
> A kamcmd to query the record shows it does not appear loaded:
> 
> [root@ip-10-0-0-2 kamailio]# kamcmd uac.reg_info l_uuid 12345678
> error: 404 - Record not found
> 
> I feel like I’m missing something obvious here!
> 
> 
> Andrew White - Director
> uConnected
> Email: and...@uconnected.com.au 
> Web: www.uConnected.com.au
> 
>> On 26 Mar 2019, at 8:06 pm, Mikko Lehto > > wrote:
>> 
>> Andrew White mailto:and...@uconnected.com.au>>:
>> 
>>> I’m currently playing with the UAC module to hand off remote registrations 
>>> with trunks to Kamailio.
>>> 
>>> I want to keep Kamailio’s external connections low, so I’m planning to use 
>>> db_text to load the UAC info, and populate the flat file via other methods.
>>> 
>>> When attempting to load my UAC DB via db_text however, I get the following:
>>> 
>>> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31904]: ERROR: db_text 
>>> [dbt_lib.c:143]: dbt_cache_get_db(): database [/etc/kamailio/uac.db] does 
>>> not exists!
>>> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31902]:

Re: [SR-Users] DBText does not exists!

2019-03-26 Thread Andrew White

Thanks so much Miko!

You’re completely right. This is also in the docs for the module, it appears 
I’ve skimmed over that part!

It appears the DB is now loading without error, however I don’t see any 
attempting for registration in Wireshark. A kamcmd uac.reg_dump doesn’t return 
any result.

I’ve copied config shown to be working from a GitHub issue on an unrelated 
problem (https://github.com/kamailio/kamailio/issues/936 
). Relevant lines below:

#!define DBURL "text:///etc/kamailio/dbtext"

modparam("rr", "append_fromtag", 1)
modparam("dialog", "dlg_flag", 4)
modparam("dialog", "track_cseq_updates", 1)
modparam("uac", "restore_dlg", 1)
modparam("uac", "reg_db_url", DBURL)
modparam("uac", "reg_timer_interval", 60)
modparam("uac", "reg_retry_interval", 60)
modparam("uac", "reg_contact_addr", "1.2.3.4:5060")

And /etc/kamailio/dbtext/uacreg:

l_uuid(string) l_username(string) l_domain(string) r_username(string) 
r_domain(string) realm(string) auth_username(string) auth_password(string) 
auth_proxy(string) expires(int) flags(int) reg_delay(int) 
12345678:user:domain.local::sip.example.org:sip.example.org:::sip\:sip.example.org:600:0:0

Both an lsof and a WITH_DEBUG show uac.so is being loaded without issue, 
however no messages relevant to registration are showing, and no REGISTER 
messages appear in Wireshark.

A kamcmd to query the record shows it does not appear loaded:

[root@ip-10-0-0-2 kamailio]# kamcmd uac.reg_info l_uuid 12345678
error: 404 - Record not found

I feel like I’m missing something obvious here!


Andrew White - Director
uConnected
Email: and...@uconnected.com.au
Web: www.uConnected.com.au

> On 26 Mar 2019, at 8:06 pm, Mikko Lehto  wrote:
> 
> Andrew White :
> 
>> I’m currently playing with the UAC module to hand off remote registrations 
>> with trunks to Kamailio.
>> 
>> I want to keep Kamailio’s external connections low, so I’m planning to use 
>> db_text to load the UAC info, and populate the flat file via other methods.
>> 
>> When attempting to load my UAC DB via db_text however, I get the following:
>> 
>> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31904]: ERROR: db_text 
>> [dbt_lib.c:143]: dbt_cache_get_db(): database [/etc/kamailio/uac.db] does 
>> not exists!
>> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31902]: INFO: jsonrpcs 
>> [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/31902
>> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31904]: ERROR: db_text 
>> [dbt_base.c:102]: dbt_init(): cannot get the link to database
>> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31904]: ERROR: uac 
>> [uac_reg.c:1318]: uac_reg_load_db(): failed to connect to the database
>> .
>> .
>> .
>> 2) Why is my db_text failing to load the file?
> 
> 
> Hi
> 
> I think your db_url should point to directory instead of file.
> 
> 
> Here is one working example using other modules:
> ---
> modparam("mtree", "db_url", "text:///opt/stuff/cfg/db_text")
> modparam("htable", "db_url", "text:///opt/stuff/cfg/db_text")
> ---
> 
> In directory /opt/stuff/cfg/db_text I have files "htable", "mtrees" and 
> "version":
> 
> ---
> $ cat version 
> htable:2
> mtrees:2
> $ cat mtrees
> id(int,auto) tname(string) tprefix(string) tvalue(string)
> 1:uni:3581234567:24
> $ cat htable
> id(int,auto) key_name(string) key_type(int) value_type(int)
> key_value(string)
> 0:3581234567\:\:timerc:0:1:30
> ---
> 
> -- 
> Mikko
> 
> ___
> 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] kamcmd error

2019-03-26 Thread Zhong, Alec (NSB - CN/Qingdao)

Hello

Could you please help check below error?

I encountered below error when to use kamcmd to get the value of one 
script_counter.
[cid:image001.png@01D4E3EB.98F9BB70]

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

[SR-Users] FW: add script counter.

2019-03-26 Thread Zhong, Alec (NSB - CN/Qingdao)

Hello,

Could you please help check below error for counters module?

BR,
Alec

From: Zhong, Alec (NSB - CN/Qingdao)
Sent: 2019年3月26日 10:56
To: 'sr-...@lists.kamailio.org' 
Subject: add script counter.

Hello,

Could you please help check below error?

I would like to add a script counter to count the number of received message by 
kamailio.
Anything wrong to use counters module?
Should counters.so be loaded?

Thank you in advance.

Kamailio.cfg change
[cid:image001.png@01D4E3C2.32E8DFB0]

Kamailo log
[cid:image002.png@01D4E3C2.8237E9D0]
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Presence module. How to update contact DB record after re-SUBSCRIBE ?

2019-03-26 Thread Denys Pozniak

Hello!

We are using Presence module with MySQL with parameters below. And looks
like module does not update contact DB record in case of re-SUBSCRIBE.
So we have a case when NAT router periodically changes the outgoing port,
but NOTIFY from Kamailio goes to port from initial SUBSCRIBE.

Is this normal module behavior or we missed something?

modparam("presence", "db_url", DBURL)
modparam("presence", "subs_db_mode", 3)
modparam("presence", "timeout_rm_subs", 0)
modparam("presence", "expires_offset", 0)
modparam("presence", "max_expires", 1800)
modparam("presence", "db_update_period", 30)
modparam("presence", "clean_period", 180)
modparam("presence", "send_fast_notify", 1)
modparam("presence", "pres_htable_size", 32)
modparam("presence", "subs_htable_size", 32)
modparam("presence", "publ_cache", 0)
modparam("presence", "notifier_processes", 0)

# kamailio -v
version: kamailio 4.4.2 (x86_64/linux) 892ad6
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_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: 892ad6
compiled on 14:45:42 Sep 26 2017 with gcc 4.8.5

-- 

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

[SR-Users] Adding presentity_uri prefix for multi-tenanted presence/dialoginfo configuration

2019-03-26 Thread Rhys Hanrahan

Hi Everyone,

I’ve recently just started working with Kamailio – thanks everyone for this 
amazing software.

Like many people, I’m in the process of trying to put Kamailio in-front of 
Asterisk to allow it to scale out, and my plan is for Kamailio to take over 
registrations, usrloc and presence/dialoginfo, as we’ve had issues where 
handsets are failing to get BLF updates/notifys, so I am hoping a couple of 
Kamailio boxes can scale better in this regard. DMQ is particularly exciting in 
how it will allow me to build a truly distributed platform. But I’m struggling 
to get presence to work the way I need it to.

Our environment is multi-tenanted, but we do not (and can’t really) use 
multi-domains. Instead, we prefix the SIP usernames with the “tenant name” such 
as tenanta101 and tenantb101. My problem is that all the BLFs are configured 
for 101@PBX with no tenant name in the User part of the URI so that internal 
dialing and call pickup will work. Because in Asterisk we use 
“subscribecontext” this hasn’t been a problem in the past – Asterisk knows for 
subscriptions coming from that handset that it belongs to that tenant’s context 
in the dialplan and they are “isolated”, so having handsets subscribe as 101@ 
in their request URI was never a problem. Of course, with Kamailio I don’t have 
subscribecontext, and my main issue is that the “presentity_uri” being stored 
is 101@ while each of the SIP accounts of the handsets are registered as 
tenenata101@, and as such, no NOTIFYs are sent by Kamailio because it thinks 
that there are no watchers for the presentity_uri.

If I change the SIP account username to 101 to match the BLF key, NOTIFYs are 
sent as expected. But then this breaks call pickup and internal dialing using 
the BLF keys. I would rather handle this in Kamailio than in Asterisk and 
having to re-configure the BLF keys for hundreds of handsets.

I need to do something like:


  *   When a SUBSCRIBE comes in, I need to prefix presentity_uri with the 
tenant name so the subscription changes from 101@ to tenanta101@ in the 
active_watchers table.
  *   When Kamailio generates a NOTIFY, the notify would be built based on 
presentity_uri and would come out as tenanta101@, but the phone’s BLFs are 
configured for 101@ so I would need to *remove* the tenant prefix before 
sending out the notify.

Is there a good, or recommended way to handle this scenario? Maybe something 
entirely different to changing the presentity_uri?

I’ve written the following config to re-write the request URI and To field in 
any incoming subscribe requests, and successfully got the active_watchers table 
to store a presentity_uri containing my tenant prefix. But the problem I am 
having is that I can’t figure out how to modify the NOTIFY packets before they 
are sent – and looking at cfgtrace, it seems I might not be able to?

My “standard” presence + dialoginfo configuration was taken from here as a 
starting point: https://kb.asipto.com/kamailio:presence:k43-blf

Here is what I have so far in terms of trying to make my modifications – any 
guidance would be greatly appreciated. It feels like there’s probably a better 
way to do this than re-writing critical headers like To and Request URI?

@@ -466,6 +467,8 @@ request_route {
# authentication
route(AUTH);

+   route(REWRITE_PRESENCE);
+
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");

# Presence server processing
route[PRESENCE] {
if(!is_method("PUBLISH|SUBSCRIBE")) return;

if(is_method("SUBSCRIBE") && $hdr(Event)=="message-summary") {
# Asterisk is our voicemail
route(TOASTERISK);
# returns here if no voicemail server is configured
sl_send_reply("404", "No voicemail service");
exit;
}

#!ifdef WITH_PRESENCE
if (!t_newtran()) {
sl_reply_error();
exit;
}

if(is_method("PUBLISH")) {
handle_publish();
t_release();
} else if(is_method("SUBSCRIBE")) {
# See REWRITE_PRESENCE - this should have been executed before 
we get here.
handle_subscribe();
t_release();
}
exit;
#!endif

+route[REWRITE_PRESENCE] {
+   if (is_method("SUBSCRIBE")) {
+   xlog("Re-writing subscribe to include tenant prefix\n");
+# The default presentity_uri needs to be prefixed with
+# the tenant name
+   # So re-write the To header
+route(TENANTINFO);
+# Now grab the tenant name.
+$var(subscribe_ru) = "sip:" + $var(tenant_name) + $rU + "@" + 
$rd;
+   xlog("Re-writing SUBSCRIBE To header as: $var(subscribe_ru)\n");
+insert_hf("To: $var(subscribe_ru)\r\n", "From");
+   $ru =

Re: [SR-Users] DBText does not exists!

2019-03-26 Thread Mikko Lehto

Andrew White :

> I’m currently playing with the UAC module to hand off remote registrations 
> with trunks to Kamailio.
> 
> I want to keep Kamailio’s external connections low, so I’m planning to use 
> db_text to load the UAC info, and populate the flat file via other methods.
> 
> When attempting to load my UAC DB via db_text however, I get the following:
> 
> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31904]: ERROR: db_text 
> [dbt_lib.c:143]: dbt_cache_get_db(): database [/etc/kamailio/uac.db] does not 
> exists!
> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31902]: INFO: jsonrpcs 
> [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/31902
> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31904]: ERROR: db_text 
> [dbt_base.c:102]: dbt_init(): cannot get the link to database
> Mar 26 04:59:30 ip-10-0-0-2 /usr/local/sbin/kamailio[31904]: ERROR: uac 
> [uac_reg.c:1318]: uac_reg_load_db(): failed to connect to the database
> .
> .
> .
> 2) Why is my db_text failing to load the file?


Hi

I think your db_url should point to directory instead of file.


Here is one working example using other modules:
---
modparam("mtree", "db_url", "text:///opt/stuff/cfg/db_text")
modparam("htable", "db_url", "text:///opt/stuff/cfg/db_text")
---

In directory /opt/stuff/cfg/db_text I have files "htable", "mtrees" and 
"version":

---
$ cat version 
htable:2
mtrees:2
$ cat mtrees
id(int,auto) tname(string) tprefix(string) tvalue(string)
1:uni:3581234567:24
$ cat htable
id(int,auto) key_name(string) key_type(int) value_type(int)
key_value(string)
0:3581234567\:\:timerc:0:1:30
---

-- 
Mikko

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

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

2019-03-26 Thread Kristijan Vrban

> Have you done a test with tools such as sipp, or was this happening
> after a while, with usual phones registering?

Usual variety of devices registering via TLS. But i can not exclude
that some devices displaying behavioural problems.

> Can you list the tcp connections and see if they are listed?
> kamctl tcp core.tcp_list

Need Kex module for that? So i can deliver next time. But when i do
"lsof -u kamailio |grep TCP"
i get a long list of more then 2000 lines with:

...
kamailio 37561 kamailio 2105u sock0,9  0t0
27856287 protocol: TCP
kamailio 37561 kamailio 2106u sock0,9  0t0
27856305 protocol: TCP
kamailio 37561 kamailio 2107u sock0,9  0t0
27856306 protocol: TCP
kamailio 37561 kamailio 2108u sock0,9  0t0
27856914 protocol: TCP
...

So about the time Kamailio created a lot of socket in the TCP domain,
but which are not bound to any port (eg via connect(2) or listen(2) or
bind(2))
Until we get to the maximum number of 2048 connections.

Best
Kristijan

Am Mo., 25. März 2019 um 14:27 Uhr schrieb Daniel-Constantin Mierla
:
>
> Have you done a test with tools such as sipp, or was this happening
> after a while, with usual phones registering?
>
> Can you list the tcp connections and see if they are listed?
>
> kamctl tcp core.tcp_list
>
> Cheers,
> Daniel
>
> On 25.03.19 08:03, Kristijan Vrban wrote:
> >> The solution here is to use set_reply_no_connect()
> > implemented it. Now the issue has shifted to:
> >
> > ERROR:  [core/tcp_main.c:3959]: handle_new_connect(): maximum
> > number of connections exceeded: 2048/2048
> >
> > But not a single TCP connection is active between Kamailio and any
> > device. Seems this counter for maximum number of connections
> > now has an issue?
> >
> > Kristijan
> >
> > Am Mi., 20. März 2019 um 15:07 Uhr schrieb Daniel-Constantin Mierla
> > :
> >> Hello,
> >>
> >> based on the trap output I think I could figure out what happened there.
> >>
> >> You have tcp_children to very low value (1 or so), the problem is not
> >> actually that one, but the fact that the connection to upstream (the
> >> device/app sending the request) was closed after receiving the request
> >> and routing of the reply gets stuck in the way of:
> >>
> >>   - a reply is received and has to be forwarded
> >>   - connection was lost, so Kamailio tries to establish a new one, but
> >> takes time till fails because the upstream is behind nat or so based on
> >> the via header:
> >>
> >> Via: SIP/2.0/TLS
> >> 10.1.0.4:10002;rport=55229;received=13.94.188.218;branch=z9hG4bK-3336-7f2927bfd703ae907348edff3611bfc9
> >>
> >>   - the reply is retransmitted and gets to another worker, which tries
> >> to forward it again, but discovers a connection structure for that
> >> destination exists (created by previous reply worker) and now waits for
> >> the connection to be released (or better said, for the mutex on writing
> >> buffer to be unlocked)
> >>
> >>   - as the second reply waits, there can be other retransmissions of the
> >> reply ending up in other workers stuck on waiting for the mutex of the
> >> connection write buffer
> >>
> >> The solution here is to use set_reply_no_connect() -- you can put it
> >> first in request_route block. I think this would be a good addition to
> >> the default configuration file as well, IMO, the sip server should not
> >> connect for sending replies and should do it also for requests that go
> >> behind nat.
> >>
> >> Cheers,
> >> Daniel
> >>
> >> On 19.03.19 10:53, Kristijan Vrban wrote:
> >>> So i had again the situation. But this time, incoming udp was
> >>> affected. Kamailio was sending out OPTIONS (via dispatcher module) to
> >>> a group of asterisk machines
> >>> but the 200 OK reply to the OPTIONS where not processed, so the
> >>> dispatcher module set all asterisk to inactive, even though they
> >>> replied 200 OK
> >>>
> >>> Attached the output of kamctl trap during the situation. Hope there is
> >>> any useful in it. Because after "kamctl trap" it was working again
> >>> without kamailio restart.
> >>>
> >>> Best
> >>> Kristijan
> >>>
> >>> Am Mo., 18. März 2019 um 12:27 Uhr schrieb Daniel-Constantin Mierla
> >>> :
>  Hello,
> 
>  setting tcp_children=1 is not a god option for scallability, practically
>  you set kamailio to process a single tcp message at one time, on high
>  traffic, that won't work well.
> 
>  Maybe try to set tcp_children to 2 or 4, that should make an eventual
>  race appear faster.
> 
>  Regarding the pid, if it is an outgoing connection, then it can be
>  created by any worker process, including a UDP worker, if that was the
>  one receiving the sip message over udp and sends it out via tcp.
> 
>  Cheers,
>  Daniel
> 
>  On 18.03.19 10:09, Kristijan Vrban wrote:
> > Hi Daniel,
> >
> > for testing, i now had set: "tcp_children=1" and so far this issue did 
> > not

Re: [SR-Users] uac_replace_from/to, msg_apply_changes and Re-INVITE

2019-03-26 Thread Henning Westerholt

Am Dienstag, 26. März 2019, 02:27:17 CET schrieb Daniel-Constantin Mierla:
> > I am currently debugging a strange issue related to the usage of
> > uac_replace_from/to() after msg_apply_changes(). It works all fine, but in
> > a Re-INVITE case it inserts the wrong headers for the 100 - Trying case.
> > The calle
> 
> did you mean caller or callee? What side is sending the re-INVITE with
> the troubles?
> 
> Is uac using the record-route param to store the info about From/To? Or
> is via dialog variables?

Hi Daniel,

storage is with dialog variables, but in the 100 - Trying case this is 
internally done with the uac TM callbacks (If I understood the code 
correctly). If I remove the msg_apply_changes() in the Re-INVITE case, all 
works fine.

Call flow (A is a SIP client, B a PSTN destination):

A -> B INVITE, 100, 18x, 200, ACK: all fine
A -> B first Re-INVITE, 100: the 100 - Trying is broken
A -> B second Re-INVINTE, 100: the 100 - Trying is broken
... more Re-INVINTEs 
A -> B BYE: all fine

I have attached a trace, see below the 100 - Trying examples:

This is ok:

Kamailio-IP.sip > A-SIDE-IP.na-localise: SIP, length: 405
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP A-SIDE-IP:
5062;rport=5062;branch=z9hG4bKPjh2a4HyDf1ApI7kWK5ShgL7I7w9.LvoeI;received=A-
SIDE-IP
From: sip:A-Number@Kamailio-IP;tag=Ho4cXwV4Q-LBW0n4guPOQwvi6GbiylqO
To: sip:B-Number@Kamailio-IP
Call-ID: po-DL6LvwksnKK56D3lF8HB4wwo6F.GS
CSeq: 6764 INVITE
Server: Carrier-Name SIP Voice Gateway
Content-Length: 0

This is not OK:

12:42:59.336930 IP (tos 0x10, ttl 64, id 61398, offset 0, flags [none], proto 
UDP (17), length 461)
Kamailio-IP.sip > A-SIDE-IP.na-localise: SIP, length: 433
SIP/2.0 100 trying -- your call is important to us
Via: SIP/2.0/UDP A-SIDE-IP:5062;rport=5062;branch=z9hG4bKPj3jfO6Fuk5-
SJQ2EXOIEeYJk1amH.xKvp;received=A-SIDE-IP
From: sip:+rewritten-num...@sip.voice.carrier-name.net;tag=Ho4cXwV4Q-
LBW0n4guPOQwvi6GbiylqO
To: sip:+B-Number@Carrier-IP:5060;tag=7N2BS4K70tZ9Q
Call-ID: po-DL6LvwksnKK56D3lF8HB4wwo6F.GS
CSeq: 6765 INVITE
Server: Carrier-Name SIP Voice Gateway
Content-Length: 0

Cheers,

Henning


-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
<>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

Re: [SR-Users] flags definition in kamailio.cfg + 5.2 documentation

Re: [SR-Users] Disable Dispatcher GW from DB

[SR-Users] flags definition in kamailio.cfg + 5.2 documentation

Re: [SR-Users] DBText does not exists!

[SR-Users] TCP connection lifetime

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

Re: [SR-Users] DBText does not exists!

Re: [SR-Users] DBText does not exists!

Re: [SR-Users] DBText does not exists!

[SR-Users] kamcmd error

[SR-Users] FW: add script counter.

[SR-Users] Presence module. How to update contact DB record after re-SUBSCRIBE ?

[SR-Users] Adding presentity_uri prefix for multi-tenanted presence/dialoginfo configuration

Re: [SR-Users] DBText does not exists!

Re: [SR-Users] Kamailio stop to process incoming SIP traffic via TCP.

Re: [SR-Users] uac_replace_from/to, msg_apply_changes and Re-INVITE

23 matches

Site Navigation

Mail list logo

Footer information