[SR-Users] Re: Why do htable Keys have two colons?

[Noah Mehl]

Daniel and Alex,

Thank you both for the prompt and enlightening responses :)

Happy new year!

~Noah

> On Jan 9, 2023, at 4:15 AM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> indeed, as Alex said, it is just a stylistic choice, the main purpose
> would be to use a character that is not allowed in variable names to
> mark the end of the variable (to avoid the use of ( ) to surround the
> name of the variable). Anyhow, it is not needed to use any static string
> as part of the key, can be only a variable, like $sht(x=>$ru); or can be
> only a static string, like $sht(x=>abc); or many variables and static
> strings: $sht(x=>$si::$rU::count). The :: is not seen as a special
> delimiter or anything similar, is pure static string from htable key
> point of view.
> 
> The choice of :: has probably relation with its usage in other languages
> like C++ to refer to (static) fields/methods. For me is also more
> friendly from human reading point of view, quite (white-)spacious,
> allowing to spot quickly the tokens composing the key.
> 
> Cheers,
> Daniel
> 
> On 09.01.23 01:45, Alex Balashov wrote:
>> Hi,
>> 
>> This is an arbitrary stylistic choice that is just consistently followed in 
>> the documentation examples, likely because it was written by the same 
>> person, or imitated by others. The colons are not required. 
>> 
>> -- Alex
>> 
>>> On Jan 8, 2023, at 1:57 PM, Noah Mehl  wrote:
>>> 
>>> Hey everyone,
>>> 
>>> Whenever I read documentation for htable usage, and other examples of other 
>>> scripts in Kamailio, htable keys are typically named:
>>> 
>>> something::something
>>> 
>>> Examples are: $au::auth_count, $ci::srcip, join::$rU
>>> 
>>> Why are there two colons (as opposed to a | )?  Is this just a standard 
>>> semantic thing in Kamailio?  Is there something about that double character 
>>> that’s unusual and easy to parse with SIP values?  Or is it just what 
>>> people do, and that’s a good choice to continue for all other Kamailio 
>>> script writers to have understanding?
>>> 
>>> Any insight would be appreciated.
>>> 
>>> Thanks!
>>> 
>>> ~Noah
>>> __
>>> Kamailio - Users Mailing List - Non Commercial Discussions
>>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>>> Important: keep the mailing list in the recipients, do not reply only to 
>>> the sender!
>>> Edit mailing list options or unsubscribe:
>> -- 
>> Alex Balashov
>> Principal Consultant
>> Evariste Systems LLC
>> Web: https://evaristesys.com
>> Tel: +1-706-510-6800
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - June 5-7, 2023 - www.kamailioworld.com
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:

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

[SR-Users] Why do htable Keys have two colons?

[Noah Mehl]

Hey everyone,

Whenever I read documentation for htable usage, and other examples of other 
scripts in Kamailio, htable keys are typically named:

something::something

Examples are: $au::auth_count, $ci::srcip, join::$rU

Why are there two colons (as opposed to a | )?  Is this just a standard 
semantic thing in Kamailio?  Is there something about that double character 
that’s unusual and easy to parse with SIP values?  Or is it just what people 
do, and that’s a good choice to continue for all other Kamailio script writers 
to have understanding?

Any insight would be appreciated.

Thanks!

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

Re: [SR-Users] Features of Kamailio as SBC

[Noah Mehl]

*for

Thanks!

~Noah

> On Dec 25, 2021, at 1:33 PM, Noah Mehl  wrote:
> 
> Just from my understanding, what feature/s does SEMS have that Freeswitch 
> does not?
> 
> Thanks!
> 
> ~Noah
> 
>> On Dec 25, 2021, at 1:30 PM, Juha Heinanen  wrote:
>> 
>> Alex Balashov writes:
>> 
>>> I still believe it’s fair to say that there exists no significant
>>> commitment to the future of the open-source version, not as a matter
>>> of critical mass.
>> 
>> You wrote about SEMS not being maintained.  Maintaining and significant
>> contributions are two different things.
>> 
>> It would be great if there would be more contributions to SEMS.  I use
>> SEMS because there is nothing else open source (or perhaps not even
>> commercial) that even close could serve as a replacement.
>> 
>> -- Juha
>> 
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>> * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Features of Kamailio as SBC

[Noah Mehl]

Just from my understanding, what feature/s does SEMS have that Freeswitch does 
not?

Thanks!

~Noah

> On Dec 25, 2021, at 1:30 PM, Juha Heinanen  wrote:
> 
> Alex Balashov writes:
> 
>> I still believe it’s fair to say that there exists no significant
>> commitment to the future of the open-source version, not as a matter
>> of critical mass.
> 
> You wrote about SEMS not being maintained.  Maintaining and significant
> contributions are two different things.
> 
> It would be great if there would be more contributions to SEMS.  I use
> SEMS because there is nothing else open source (or perhaps not even
> commercial) that even close could serve as a replacement.
> 
> -- Juha
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Problem with kamalio.

[Noah Mehl]

Henning,

This is starting to make a lot more sense!  Thanks for sending.

I have one other question, why is there a srdb1 and a srdb2 library?  Are all 
SQL dbs expected to be supported in both?

Thanks!

~Noah

> On Feb 22, 2021, at 2:32 AM, Henning Westerholt  wrote:
> 
> Hi Noah,
>  
> sure – let me give you some pointers. So basically, the SQL files are 
> generated from the XSL infrastructure in the quoted directory. This file e.g. 
> is for postgres:
> https://github.com/kamailio/kamailio/blob/5.4/doc/stylesheets/dbschema/xsl/postgres.xsl
>  
> <https://github.com/kamailio/kamailio/blob/5.4/doc/stylesheets/dbschema/xsl/postgres.xsl>
>  
> You basically need to copy it to a new file and adapt the types in it to the 
> cockroachdb types. If you execute “make dbschema” in the kamailio source 
> tree, it will generate all the SQL files. Then you could generate the 
> appropriate SQL files also for your database and it will stay in sync after 
> future changes. There might be also a small extension necessary in the 
> Makefile, but we can have a look to this later on.
>  
> About the questions why the SQL files are then also checked in after creation 
> – because otherwise everybody needs to install the xstl dependencies just for 
> installing Kamailio.
>  
> About the rand()/random() topic – I did not find anything in the LCR module 
> as well. It might be obsolete. I would consider dropping this, maybe after 
> asking on the sr-dev list for this again.
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/ <https://skalatan.de/blog/>
> Kamailio services – https://gilawa.com <https://gilawa.com/>
>  
> From: Noah Mehl mailto:noahm...@gmail.com>> 
> Sent: Sunday, February 21, 2021 8:47 PM
> To: Jonathan Hunter mailto:hunter...@hotmail.com>>
> Cc: Henning Westerholt mailto:h...@skalatan.de>>; Kamailio 
> (SER) - Users Mailing List  <mailto:sr-users@lists.kamailio.org>>
> Subject: Re: Cockroachdb and kamailio 5.4
>  
> Jon,
>  
> I’m not sure what would get my branch accepted.  Henning mentioned on 
> 9/16/2020 that the .sql files are generated from XML/XLST scripts, I have 
> found: https://github.com/kamailio/kamailio/tree/5.4/doc/stylesheets/dbschema 
> <https://github.com/kamailio/kamailio/tree/5.4/doc/stylesheets/dbschema> 
> which was updated just 3 days ago.  However, I don’t understand how this is 
> used to generate the .sql files for Postgres. I’m also confused as to why the 
> .sql files are checked into the repository if they’re generated?  Henning, 
> can you point me in the right direction?
>  
> That being said, this is what’s changed in the branch 
> <https://github.com/kamailio/kamailio/compare/5.4...reperio:cockroachdb-compat?expand=1>:
>  
> kamdbctl.pgsql
>  
> - I’ve updated the psql command for my preferences regarding output
> - I’ve made the function checking more verbose
> - I’ve added the gen_random_uuid() function (by adding pgcrypto to Postgres, 
> it’s native in CockroachDB), this isn’t required, but we are using UUID for 
> usrloc in production
> - I’ve updated the GRANT commands so they’re compatible with both Postgres 
> and CockroachDB
>  
> Some things to note:
>  
> - concat() is native to CockroachDB, so the CREATE FUNCTION is only necessary 
> for Postgres
> - rand() is the native function name in MySQL, but random() is the function 
> name in Postgres and CockroachDB.  This is where I’m most concerned because 
> the file says it’s used in the lcr module, but I cannot find where it is 
> used.  Does anyone know how to ascertain this?  Anyways, they’re the same 
> function, so it’s a little silly to require a CREATE FUNCTION duplicating the 
> exact functionality of an existing native function.
>  
> The rest of the changes have to do with modifying the create statements to 
> not use SERIAL, but use the more verbose SEQUENCE + nextval().  It’s 
> identical in practice, so there’s 0 risk there.
>  
> I think overall risk is low for the branch, as the branch only changes the 
> utility that creates the DBs.  As for production use, it’s worked great for 
> us, there have been no issues.
>  
> ~Noah
>  
> On Feb 18, 2021, at 2:45 PM, Jonathan Hunter  <mailto:hunter...@hotmail.com>> wrote:
>  
> Hi Noah,
>  
> Hope you are well?
>  
> I work as a consultant for a company in the UK, and I am building a new 
> hosted telephony platform for them in docker initially, and as we are 
> deploying across multiple servers they want to use cockroachdb to allow easy 
> management of a cluster environment.
>  
> I could see from your posts you got it working using your own branch, and I 
> won

Re: [SR-Users] Cockroachdb and kamailio 5.4

[Noah Mehl]

Jon,

Realistically, this is alpha functionality, at best.  If you, and/or your 
organization, do not have the expertise, resources, and/or risk tolerance for 
this, I couldn’t in good faith recommend that you do it.

There are many other clustering technologies for MySQL and PostgreSQL that are 
mature, and *should* be compatible with the existing implementation.  Perhaps 
someone on the list can let us know if they’re using one of the following:

- MySQL Galera
- PostgreSQL replication (either using Pacemaker/Corosync or Zookeeper to 
provide automated failover and/or Master/Master)
- Vitess: https://github.com/vitessio/vitess 
<https://github.com/vitessio/vitess>
- Some other solution not listed here?

That being said, I’ve spend as much time on this as I can.  I solved the 
permissions module issue in this way:

diff --git a/utils/kamctl/postgres/permissions-create.sql 
b/utils/kamctl/postgres/permissions-create.sql
index f397ca22f4..66de10ddcb 100644
--- a/utils/kamctl/postgres/permissions-create.sql
+++ b/utils/kamctl/postgres/permissions-create.sql
@@ -20,10 +20,10 @@ CREATE SEQUENCE address_id_seq;
 
 CREATE TABLE address (
 id integer PRIMARY KEY NOT NULL DEFAULT nextval('address_id_seq'),
-grp INTEGER DEFAULT 1 NOT NULL,
+grp INT4 DEFAULT 1 NOT NULL,
 ip_addr VARCHAR(50) NOT NULL,
-mask INTEGER DEFAULT 32 NOT NULL,
-port SMALLINT DEFAULT 0 NOT NULL,
+mask INT4 DEFAULT 32 NOT NULL,
+port INT2 DEFAULT 0 NOT NULL,
 tag VARCHAR(64)
 );

diff --git a/src/modules/db_postgres/km_res.c b/src/modules/db_postgres/km_res.c
index 13ac138c1a..f4813cafcc 100644
--- a/src/modules/db_postgres/km_res.c
+++ b/src/modules/db_postgres/km_res.c
@@ -151,11 +151,11 @@ int db_postgres_get_columns(const db1_con_t *_h, 
db1_res_t *_r)
case VARCHAROID:
case NAMEOID:
case BPCHAROID:
+   case TEXTOID:
LM_DBG("use DB1_STRING result type\n");
RES_TYPES(_r)[col] = DB1_STRING;
break;
 
-   case TEXTOID:
case BYTEAOID:
LM_DBG("use DB1_BLOB result type\n");
RES_TYPES(_r)[col] = DB1_BLOB;
 
For the schema update, it becomes CockroachDB specific, hence the need to start 
creating CockroachDB specific migration files.  For the  km_res.c change, this 
is where things are probably not ideal.  I’m hoping that Henning and/or Daniel 
can respond.  Essentially, CockroachDB stores all character/string datatypes 
the same way, and then presents this as a TEXTOID datatype.  I think the 
problem with moving this to the DB1_STRING type is that we *could* have memory 
overruns?  That’s just my guess.  Maybe it’s completely safe?

Thanks!

~Noah

> On Feb 26, 2021, at 5:15 AM, Jonathan Hunter  wrote:
> 
> Hi Noah,
>  
> Hope you are well? 
>  
> Realistically do you think you will be able to spend some time on this or do 
> you think I need to look at other options in the short term?
>  
> I guess the primary requirements for me are being able to use these modules 
> which require database interaction (mainly Permissions,userloc,dispatcher).
>  
> I have started to work through it but I am pondering if in the short term I 
> need to focus on a support database and look to migrate when available.
>  
> Thanks!
>  
> Jon
>  
>  
>  
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Jonathan Hunter <mailto:hunter...@hotmail.com>
> Sent: 22 February 2021 11:20
> To: Henning Westerholt <mailto:h...@skalatan.de>; Noah Mehl 
> <mailto:noahm...@gmail.com>
> Cc: Kamailio (SER) - Users Mailing List <mailto:sr-users@lists.kamailio.org>
> Subject: Re: [SR-Users] Cockroachdb and kamailio 5.4
>  
> Hi Noah and Henning,
>  
> Thank you for your responses, I am currently digesting them!
>  
> If I can be of any help testing/working on this please let me know as Im very 
> keen to implement it so will review and also happy to take direction as I 
> will be testing this week on it.
>  
> Thanks again
>  
> Jon
>  
> Sent from Mail 
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.microsoft.com%2Ffwlink%2F%3FLinkId%3D550986=04%7C01%7C%7Cfd34312b504a4723068008d8d723ebe4%7C84df9e7fe9f640afb435%7C1%7C0%7C637495896580748983%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=wfJ2SNI115vi8gpeFb1bs%2BYTLSGCc6BMCZjG9AzMXNk%3D=0>
>  for Windows 10
>  
> From: Henning Westerholt <mailto:h...@skalatan.de>
> Sent: 22 February 2021 07:44
> To: Noah Mehl <mailto:noahm...@gmail.com>; Jonathan Hunter 
> &

Re: [SR-Users] Cockroachdb and kamailio 5.4

[Noah Mehl]

Welp!

Looks like I’ve hit another issue, and I don’t think this is solvable by 
updating the Postgres configs.  For instance, the permissions module is doing a 
validation on the address rows, and the group has to be a DB1_INT (INT4).  
However, the default value for INTEGER in Postgres is INT4, and the default 
value for CockroachDB is INT8, resulting in a DB1_BIGINT type during the check. 
 There is no singular datatype we can use for both at the same time.

So, looks like many things may be broken with my branch :(

~Noah

> On Feb 21, 2021, at 2:46 PM, Noah Mehl  wrote:
> 
> Jon,
> 
> I’m not sure what would get my branch accepted.  Henning mentioned on 
> 9/16/2020 that the .sql files are generated from XML/XLST scripts, I have 
> found: https://github.com/kamailio/kamailio/tree/5.4/doc/stylesheets/dbschema 
> <https://github.com/kamailio/kamailio/tree/5.4/doc/stylesheets/dbschema> 
> which was updated just 3 days ago.  However, I don’t understand how this is 
> used to generate the .sql files for Postgres. I’m also confused as to why the 
> .sql files are checked into the repository if they’re generated?  Henning, 
> can you point me in the right direction?
> 
> That being said, this is what’s changed in the branch 
> <https://github.com/kamailio/kamailio/compare/5.4...reperio:cockroachdb-compat?expand=1>:
> 
> kamdbctl.pgsql
> 
> - I’ve updated the psql command for my preferences regarding output
> - I’ve made the function checking more verbose
> - I’ve added the gen_random_uuid() function (by adding pgcrypto to Postgres, 
> it’s native in CockroachDB), this isn’t required, but we are using UUID for 
> usrloc in production
> - I’ve updated the GRANT commands so they’re compatible with both Postgres 
> and CockroachDB
> 
> Some things to note:
> 
> - concat() is native to CockroachDB, so the CREATE FUNCTION is only necessary 
> for Postgres
> - rand() is the native function name in MySQL, but random() is the function 
> name in Postgres and CockroachDB.  This is where I’m most concerned because 
> the file says it’s used in the lcr module, but I cannot find where it is 
> used.  Does anyone know how to ascertain this?  Anyways, they’re the same 
> function, so it’s a little silly to require a CREATE FUNCTION duplicating the 
> exact functionality of an existing native function.
> 
> The rest of the changes have to do with modifying the create statements to 
> not use SERIAL, but use the more verbose SEQUENCE + nextval().  It’s 
> identical in practice, so there’s 0 risk there.
> 
> I think overall risk is low for the branch, as the branch only changes the 
> utility that creates the DBs.  As for production use, it’s worked great for 
> us, there have been no issues.
> 
> ~Noah
> 
>> On Feb 18, 2021, at 2:45 PM, Jonathan Hunter > <mailto:hunter...@hotmail.com>> wrote:
>> 
>> Hi Noah,
>>  
>> Hope you are well?
>>  
>> I work as a consultant for a company in the UK, and I am building a new 
>> hosted telephony platform for them in docker initially, and as we are 
>> deploying across multiple servers they want to use cockroachdb to allow easy 
>> management of a cluster environment.
>>  
>> I could see from your posts you got it working using your own branch, and I 
>> wondered what changes you made to make things work correctly and what would 
>> be needed to get the kamailio dev’s to accept it into the main stream of 
>> code? (Happy to help here where I can).
>>  
>> Unless you will maintain your branch forever  Or are the changes small so 
>> its not too much of a concern? I just want to assess the risk really, and 
>> like you I think mainly we will just be using userloc and dispatcher for DB 
>> interaction so its positive to hear they work fine.  We would also be using 
>> rtpengine, routing data will be done via API so that should be fine. FYI Id 
>> like to run kamailio 5.4 initially.
>>  
>> I see your comments about table creation (in previous posts), that is the 
>> initial problem I am seeing when trying to use postgres based commands 
>> direct from a pgdump to create the kamailio database structure, does your 
>> branch contain all the creation scripts for the db/tables that I can use for 
>> testing?
>>  
>> Thanks again in advance  for the response!
>>  
>> Jon
>>  
>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 
>> 10
>>  
>> From: Henning Westerholt <mailto:h...@skalatan.de>
>> Sent: 17 February 2021 16:18
>> To: Kamailio (SER) - Users Mailing List <mailto:sr-users@lists.kamailio.org>
>> Cc: Jonathan Hunter <mailto:hunter...@hotmai

Re: [SR-Users] Cockroachdb and kamailio 5.4

[Noah Mehl]

Jon,

I’m not sure what would get my branch accepted.  Henning mentioned on 9/16/2020 
that the .sql files are generated from XML/XLST scripts, I have found: 
https://github.com/kamailio/kamailio/tree/5.4/doc/stylesheets/dbschema 
<https://github.com/kamailio/kamailio/tree/5.4/doc/stylesheets/dbschema> which 
was updated just 3 days ago.  However, I don’t understand how this is used to 
generate the .sql files for Postgres. I’m also confused as to why the .sql 
files are checked into the repository if they’re generated?  Henning, can you 
point me in the right direction?

That being said, this is what’s changed in the branch 
<https://github.com/kamailio/kamailio/compare/5.4...reperio:cockroachdb-compat?expand=1>:

kamdbctl.pgsql

- I’ve updated the psql command for my preferences regarding output
- I’ve made the function checking more verbose
- I’ve added the gen_random_uuid() function (by adding pgcrypto to Postgres, 
it’s native in CockroachDB), this isn’t required, but we are using UUID for 
usrloc in production
- I’ve updated the GRANT commands so they’re compatible with both Postgres and 
CockroachDB

Some things to note:

- concat() is native to CockroachDB, so the CREATE FUNCTION is only necessary 
for Postgres
- rand() is the native function name in MySQL, but random() is the function 
name in Postgres and CockroachDB.  This is where I’m most concerned because the 
file says it’s used in the lcr module, but I cannot find where it is used.  
Does anyone know how to ascertain this?  Anyways, they’re the same function, so 
it’s a little silly to require a CREATE FUNCTION duplicating the exact 
functionality of an existing native function.

The rest of the changes have to do with modifying the create statements to not 
use SERIAL, but use the more verbose SEQUENCE + nextval().  It’s identical in 
practice, so there’s 0 risk there.

I think overall risk is low for the branch, as the branch only changes the 
utility that creates the DBs.  As for production use, it’s worked great for us, 
there have been no issues.

~Noah

> On Feb 18, 2021, at 2:45 PM, Jonathan Hunter  wrote:
> 
> Hi Noah,
>  
> Hope you are well?
>  
> I work as a consultant for a company in the UK, and I am building a new 
> hosted telephony platform for them in docker initially, and as we are 
> deploying across multiple servers they want to use cockroachdb to allow easy 
> management of a cluster environment.
>  
> I could see from your posts you got it working using your own branch, and I 
> wondered what changes you made to make things work correctly and what would 
> be needed to get the kamailio dev’s to accept it into the main stream of 
> code? (Happy to help here where I can).
>  
> Unless you will maintain your branch forever  Or are the changes small so 
> its not too much of a concern? I just want to assess the risk really, and 
> like you I think mainly we will just be using userloc and dispatcher for DB 
> interaction so its positive to hear they work fine.  We would also be using 
> rtpengine, routing data will be done via API so that should be fine. FYI Id 
> like to run kamailio 5.4 initially.
>  
> I see your comments about table creation (in previous posts), that is the 
> initial problem I am seeing when trying to use postgres based commands direct 
> from a pgdump to create the kamailio database structure, does your branch 
> contain all the creation scripts for the db/tables that I can use for testing?
>  
> Thanks again in advance  for the response!
>  
> Jon
>  
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>  
> From: Henning Westerholt <mailto:h...@skalatan.de>
> Sent: 17 February 2021 16:18
> To: Kamailio (SER) - Users Mailing List <mailto:sr-users@lists.kamailio.org>
> Cc: Jonathan Hunter <mailto:hunter...@hotmail.com>; Noah Mehl 
> <mailto:noahm...@gmail.com>
> Subject: RE: Cockroachdb and kamailio 5.4
>  
> Hi Jonathan,
>  
> no – I do not think that there has been more work done so far, apart from the 
> discussion that you referenced below.
> If you are also interested in getting this forward, why not reaching out to 
> the other guy starting this discussion earlier? Just to see if you can maybe 
> join forces to get something of this work into a pull request for review and 
> later a possible merge into our code base.
>  
> Cheers,
>  
> Henning
>  
> -- 
> Henning Westerholt – https://skalatan.de/blog/ 
> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F=04%7C01%7C%7C548d23e7d9544667296a08d8d35fb5d3%7C84df9e7fe9f640afb435%7C1%7C0%7C637491755307382972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=WVL5vzihg1kUYxeDwnDwHPksVaf0EaM6ANXuBBBthZE%3D=0

Re: [SR-Users] Double port in TO header

[Noah Mehl]

Daniel,

Thank you for the writeup.  I tried the following:

tcp_reuse_port=yes

It did not seem to make any difference, in terms of using port 5060.  I built 
and am running on kernel: 4.19.0-12.  Do I need to do something special when I 
build kamailio for this feature?

It’s definitely my preference that Kamailio send requests from tcp port 5060 if 
that’s a listen port (I am also looking into the issue with Freeswitch 
separately).

I’m not entirely sure how Kamailio is supposed to *pick* 5060, as I have 3 tcp 
ports in my config (TCP on 5060, TLS on 5061, and TLS on 443).

Thanks!

~Noah

> On Oct 29, 2020, at 6:22 PM, Alex Balashov  wrote:
> 
> Hello,
> 
> confirming what Henning said that dispatcher is not using uac module,
> not to be any doubt about that. Actually, uac modules uses some of the
> TM-UAC functions as dispatcher module, but between dispatcher and uac
> module is no relation, no dependency. Sockets can be enforced in
> dispatcher via socket attribute (I think is also a modparam for a global
> need), however see next remarks about what can happen.
> 
> Besides that, I am writing to add on the original topic related to tcp
> local ports. Tipically they have nothing to do with the listen port
> (5060), the force socket for TCP is mainly a best-effort to use at least
> the same network interface, but the OS/kernel may use a different one,
> based on IP routing rules and priorities. The local ports are selected
> from ephemeral ports range, searching the web should reveal more details
> about, for example:
> 
>   *
> https://superuser.com/questions/1118735/how-are-source-ports-determined-and-how-can-i-force-it-to-use-a-specific-port
> 
> On newer kernels there is an option to try to reuse ports even for tcp
> (which was possible for UDP before, but not for TCP), kamailio has a
> core parameter to enable it. See if enabling that gives what is wanted.
> But if one thinks of firewall rules, for tcp it should allow based on IP
> and eventually the ephemeral ports range of the source (which is hard to
> figure out if it is not another fully managed system).
> 
> Olle added relevant details, adding a bit more: the port in Via header
> is for "connect back here if the connection of the request is no longer
> available", otherwise the connection is reused and Via address is more
> for aesthetic purposes (e.g., think also about a device behind nat that
> has via with private ip address, in such case is not possible to connect
> back at all).
> 
> Cheers,
> Daniel
> 
> On 30.10.20 09:05, Henning Westerholt wrote:
>> Hi Alex,
>> 
>> this is not correct. The dispatcher module uses the uac function from TM 
>> module for the generation and sending out of OPTIONS requests.
>> 
>> So setting the mentioned function from the uac module will probably not help.
>> 
>> Cheers,
>> 
>> Henning
>> 
>> -- 
>> Henning Westerholt – https://skalatan.de/blog/
>> Kamailio services – https://gilawa.com 
>> 
>> -Original Message-----
>> From: sr-users  On Behalf Of Alex 
>> Balashov
>> Sent: Thursday, October 29, 2020 9:11 PM
>> To: sr-users@lists.kamailio.org
>> Subject: Re: [SR-Users] Confusion about TCP worker ports
>> 
>> On 10/29/20 3:57 PM, Noah Mehl wrote:
>> 
>>> Is there no way to send the requests from the listen port?
>> The OPTIONS pinging dispatcher does internally is opaque, so I'm not sure.
>> 
>> However, the source shows that dispatcher uses the UAC module for its 
>> internally generated OPTIONS pings, which is sensible:
>> 
>> https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c#L3445
>> 
>> If so, it stands to reason that loading 'uac' and setting this modparam may 
>> have some effect:
>> 
>> https://kamailio.org/docs/modules/5.4.x/modules/uac.html#uac.p.default_socket
>> 
>> I am not sure if it applies only to requests synthesised within the config 
>> script and sent using uac_req_send(), or to any requests constructed by the 
>> UAC module, though.
>> 
>>> And if they’re not going to come from the listen port, can you please 
>>> help me with the a way to update the message for the worker chosen 
>>> rport?
>> Try the above and see if it does anything.
>> 
>> -- Alex
>> 
>> --
>> 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:/

Re: [SR-Users] Confusion about TCP worker ports

[Noah Mehl]

Alex,

In the original example:

recv 1481 bytes from tcp/[1.1.1.1]:33940 at 16:56:47.920698:
   
   INVITE sip:991...@sip.domain.com SIP/2.0
   Record-Route: 
   Record-Route: 
   Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
   Via: SIP/2.0/TLS 
172.22.199.110:55304;received=5.5.5.5;rport=39518;branch=z9hG4bKPj5Css6JomCt9Cli2cCINbXi4FbPM5wewG;alias
   Max-Forwards: 69
   From: "Noah Mehl" 
;tag=s3i3y2tiOCgnUId5TD4Vp0UChf9GyEy9
   To: 
   Contact: 

   Call-ID: 5aoRBMBHahxqSLzrIpFnlfRz.UcGsmfq
   CSeq: 27271 INVITE
   Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
   Supported: replaces, norefersub, gruu
   User-Agent: Blink Pro 4.6.0 (MacOSX)
   Content-Type: application/sdp
   Content-Length:   528

The top Via header is not identifying port 33940 which is where the request is 
coming from. Or the expectation is that the receiving side will send replies to 
port 5060 (which I guess is broken in Freeswitch sometimes?)

I guess I would like to update that existing Via header with the source port 
(since it’s not 5060)?

~Noah

> On Oct 29, 2020, at 4:45 PM, Alex Balashov  wrote:
> 
> There's not really a reasonable way for you to add your own Via header to 
> this outgoing request. If Kamailio is doing something wrong or inconsistent 
> in this context, it should be fixed there.
> 
> On 10/29/20 4:42 PM, Noah Mehl wrote:
>> Alex,
>> No dice.
>> So now my question is what is the correct way to fix the Via?
>> If this is the original:
>> Via: SIP/2.0/TCP 
>> 1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
>> Then do I update the port like this:
>> Via: SIP/2.0/TCP 
>> 1.1.1.1:33940;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
>> Or should I use an rport tag:
>> Via: SIP/2.0/TCP 
>> 1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1;rport=33940
>> Thanks!
>> ~Noah
>>> On Oct 29, 2020, at 4:12 PM, Alex Balashov  
>>> wrote:
>>> 
>>> Noah,
>>> 
>>> It is also possible that this core config parameter will in and of itself 
>>> cure your problem:
>>> 
>>> https://www.kamailio.org/wiki/cookbooks/5.4.x/core#tcp_reuse_port
>>> 
>>> Not sure whether it helps only in tandem with the previous UAC 
>>> default_socket modparam suggestion, or is sufficient in and of itself.
>>> 
>>> -- Alex
>>> 
>>> -- 
>>> 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
> 
> -- 
> 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] Confusion about TCP worker ports

[Noah Mehl]

Alex,

No dice.

So now my question is what is the correct way to fix the Via?

If this is the original:

Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1

Then do I update the port like this:

Via: SIP/2.0/TCP 
1.1.1.1:33940;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1

Or should I use an rport tag:

Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1;rport=33940

Thanks!

~Noah

> On Oct 29, 2020, at 4:12 PM, Alex Balashov  wrote:
> 
> Noah,
> 
> It is also possible that this core config parameter will in and of itself 
> cure your problem:
> 
> https://www.kamailio.org/wiki/cookbooks/5.4.x/core#tcp_reuse_port
> 
> Not sure whether it helps only in tandem with the previous UAC default_socket 
> modparam suggestion, or is sufficient in and of itself.
> 
> -- Alex
> 
> -- 
> 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] Confusion about TCP worker ports

[Noah Mehl]

Alex,

Is there no way to send the requests from the listen port?

And if they’re not going to come from the listen port, can you please help me 
with the a way to update the message for the worker chosen rport?

~Noah

> On Oct 29, 2020, at 3:37 PM, Alex Balashov  <mailto:abalas...@evaristesys.com>> wrote:
> 
> Sorry to have missed your other question: 
> 
> The “resource temporarily unavailable” is a normal occurrence in a 
> nonblocking connect(), and nothing to worry about. 
> 
> Unless the socket literally connects instantaneously, EAGAIN is what it’ll 
> throw out when polled until connection is established.
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>> On Oct 29, 2020, at 3:27 PM, Alex Balashov > <mailto:abalas...@evaristesys.com>> wrote:
>> 
>> Internally generated requests are a little quirky in that they’re generated 
>> by outside timer processes or tasks in core timers — activity that takes 
>> place outside the SIP worker pool. However, the expectation is that any 
>> replies will be processed (in this case, absorbed) by the SIP workers. 
>> 
>> Asymmetric signalling is permitted in SIP, so sending from source port X 
>> while specifying a return port of Y in the top Via hop is perfectly 
>> acceptable.
>> 
>> — Alex
>> 
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>> 
>>> On Oct 29, 2020, at 3:21 PM, Noah Mehl >> <mailto:noahm...@gmail.com>> wrote:
>>> 
>>> Hey all,
>>> 
>>> I’m a little stuck on an implementation of a set of dispatchers via TCP.  
>>> There are some oddities about the behavior of the TCP source port of the 
>>> Kamailio tcp worker/s, and maybe this is expected, but it doesn’t seem 
>>> valid.  For instance, I have a dispatcher:
>>> 
>>> "RECORDS":  [{
>>> "SET":  {
>>> "ID":   1,
>>> "TARGETS":  [{
>>> "DEST": {
>>> "URI":  
>>> “sip:2.2.2.2:5060;transport=tcp ",
>>> "FLAGS":
>>> "AP",
>>> "PRIORITY": 
>>> 5
>>> }
>>> }]
>>> }
>>> }]
>>> 
>>> But when Kamailio sends an OPTIONS keep alive, the source port for the 
>>> worker is 33940, and not 5060 (which is the TCP listen port), as received 
>>> by Freeswitch:
>>> 
>>> recv 447 bytes from tcp/[1.1.1.1]:33940 at 18:58:24.958720:
>>>
>>>OPTIONS sip:2.2.2.2:5060;transport=tcp  
>>> SIP/2.0
>>>Via: SIP/2.0/TCP 
>>> 1.1.1.1;branch=z9hG4bK1525.80a9e442.0
>>>To: >
>>>From: >> >;tag=3c52ba62ee4c4621b9660728159919d3-cda8066f
>>>CSeq: 10 OPTIONS
>>>Call-ID: 3aa18693487268dc-2790@1.1.1.1 
>>> <mailto:3aa18693487268dc-2790@1.1.1.1>
>>>Max-Forwards: 70
>>>Content-Length: 0
>>>User-Agent: kamailio (5.4.2 (x86_64/linux))
>>>
>>>
>>> 
>>> Also, I get weird debug messages when this tcp worker is spun up 
>>> (specifically about Resource temporarily unavailable):
>>> 
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3340]: ds_ping_result_helper(): 
>>> probe all, mode DS_PROBE_ALL
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3383]: ds_ping_set(): probing set 
>>> #1, URI sip:2.2.2.2:5060;transport=tcp 
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3414]: ds_ping_set(): Default 
>>> ping_from: sip:inbound-kamailio-01 
>>> 11(2790) DEBUG: dispatcher [dispatch.c:3424]: ds_ping_set(): Default 
>>> outbound proxy: 
>>> 11(2790) DEBUG: tm [uac.c:450]: t_uac_prepare(): 
>>> next_hop=>
>>> 11(2790) DEBUG: tm [uac.c:158]: dlg2hash(): hashid 21073
>>> 11(2790) DEBUG:  [core/tcp_main.c:1993]: tcp_send(): no open tcp 
>>> connection found, opening new one
>>>

[SR-Users] Confusion about TCP worker ports

[Noah Mehl]

ZBFc
19(2798) DEBUG:  [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): 
end of header reached, state=29
19(2798) DEBUG:  [core/parser/msg_parser.c:171]: get_hdr_field():  
[59]; uri=[sip:2.2.2.2:5060;transport=tcp]
19(2798) DEBUG:  [core/parser/msg_parser.c:174]: get_hdr_field(): to body 
(39)[], to tag (13)[1mB9HryQ8ZBFc]
19(2798) DEBUG:  [core/parser/msg_parser.c:152]: get_hdr_field(): cseq 
: <10> 
19(2798) DEBUG:  [core/receive.c:319]: receive_msg(): --- received sip 
message - reply - call-id: [3aa18693487268dc-2790@1.1.1.1] - cseq: [10 OPTIONS]
19(2798) DEBUG:  [core/parser/msg_parser.c:185]: get_hdr_field(): 
content_length=0
19(2798) DEBUG:  [core/parser/msg_parser.c:89]: get_hdr_field(): found 
end of header

Are these SIP messages expected to come from other ports than the listen port 
(5060 in this case)? Also, if the worker source port is not 5060, shouldn’t the 
SIP message get updated with the correct port?

In the case of OPTIONS, Freeswitch is replying correctly to the source port: 
33940.

However, in the case of an in dialog BYE, Freeswitch is NOT replying to the 
source port of the Kamailio messages, but only to port 5060.  Here is an 
example (relayed from web sockets to freeswitch over TCP) INVITE (as received 
from Freeswitch):

recv 1481 bytes from tcp/[1.1.1.1]:33940 at 16:56:47.920698:
   
   INVITE sip:991012@sip.domain .com SIP/2.0
   Record-Route: 
   Record-Route: 
   Via: SIP/2.0/TCP 
1.1.1.1;branch=z9hG4bKd408.3f53e940ccb20c1033df4b3a8ebd8a34.0;i=1
   Via: SIP/2.0/TLS 
172.22.199.110:55304;received=5.5.5.5;rport=39518;branch=z9hG4bKPj5Css6JomCt9Cli2cCINbXi4FbPM5wewG;alias
   Max-Forwards: 69
   From: "Noah Mehl" 
;tag=s3i3y2tiOCgnUId5TD4Vp0UChf9GyEy9
   To: 
   Contact: 

   Call-ID: 5aoRBMBHahxqSLzrIpFnlfRz.UcGsmfq
   CSeq: 27271 INVITE
   Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER
   Supported: replaces, norefersub, gruu
   User-Agent: Blink Pro 4.6.0 (MacOSX)
   Content-Type: application/sdp
   Content-Length:   528
   
   v=0
   o=- 3812979407 3812979407 IN IP4 5.5.5.5
   s=Blink Pro 4.6.0 (MacOSX)
   t=0 0
   m=audio 50016 RTP/SAVP 113 0 101
   c=IN IP4 5.5.5.5
   a=rtcp:50017
   a=rtpmap:113 opus/48000/2
   a=fmtp:113 useinbandfec=1
   a=rtpmap:0 PCMU/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:UhHq6hth9HqALmiJ3AEeoGkixObBzkLURG60wJKT
   a=crypto:2 AES_CM_128_HMAC_SHA1_32 
inline:VKYaSCVwgvXCPaRvudTrgLORhWmOA7wyDJVeGjcu
   a=sendrecv
   a=oldmediaip:172.22.199.110
   a=oldmediaip:172.22.199.110
   

This doesn’t seem valid, as the top Via doesn’t have a port specified?

For reference, just rebuilt form the 5.4 branch today:

commit 62dff5b8b157236cae7defe64291a6e4a8ae27b5 (upstream/5.4)
Author: Kamailio Dev 
Date:   Wed Oct 28 20:16:28 2020 +0100

modules: readme files regenerated - modules ... [skip ci]

Thanks!

~Noah

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

Re: [SR-Users] CockroachDB and Kamailio

[Noah Mehl]

Daniel,

Yes, sorry, there are two issues at discussion here.

1. Use of UUID’s instead of INT.  This is kinda moot for us right now.  We 
switched subscriber to autogenerate UUID, and it’s working great for us.  We 
don’t really *need* to do this anywhere else currently.  I don’t know when I 
would have time to test all of the other modules/use cases.
2. I’d love to PR back the kamdbctl updates that make CockroachDB work out of 
the box with the existing PGSQL scripts.  I have a branch that has some small 
updates that works for both PostgreSQL and CockroachDB: 
https://github.com/reperio/kamailio/tree/cockroachdb-compat 
<https://github.com/reperio/kamailio/tree/cockroachdb-compat>.  However, there 
is one thing that I don’t really know if it can be fixed.  The kamdbctl scripts 
for PostgreSQL creates a function in the kamailio (created) db called “rand()”. 
 The comment in the script seems to point to something in the lcr module.  But 
I can’t seem to find where the lcr module is using rand().  Basically, I’m 
wondering if this is still needed?  Or, if this could be abstracted so that 
rand() is used for MySQL and random() is used for PostgreSQL?

Thanks!

~Noah

> On Aug 25, 2020, at 9:28 AM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> somehow I understood that you want to replace id filed in tables from integer 
> (auto increment) to some sort of string uid. Some modules expect that field 
> to be integer, so changing its type can break them. If you change to use 
> random unique values instead of auto-increment, then I expect to work.
> 
> Cheers,
> Daniel
> 
> On 21.08.20 23:47, Noah Mehl wrote:
>> Daniel/Henning,
>> 
>> I have created a new branch that is much more CockroachDB compatible: 
>> https://github.com/reperio/kamailio/tree/cockroachdb-compat 
>> <https://github.com/reperio/kamailio/tree/cockroachdb-compat>
>> 
>> So far, the only thing I’ve noticed that isn’t compatible is: 
>> https://github.com/reperio/kamailio/blob/62aad6591423e1f693397d33ddefd234938d1293/utils/kamctl/kamdbctl.pgsql#L137
>>  
>> <https://github.com/reperio/kamailio/blob/62aad6591423e1f693397d33ddefd234938d1293/utils/kamctl/kamdbctl.pgsql#L137>,
>>  as the concat() function actually exists in PostgreSQL > 9ish and 
>> CockroachDB.  That being said, the only difference I can find between MySQL 
>> rand() and PostgreSQL random() is just the name.  Is this still an issue 
>> with the lcr module?  If so, can you point me to where it’s being used?
>> 
>> Otherwise, I have tested this update with PostgreSQL and CockroachDB.
>> 
>> Thanks!
>> 
>> ~Noah
>> 
>>> On Aug 21, 2020, at 2:38 PM, Noah Mehl >> <mailto:noahm...@gmail.com>> wrote:
>>> 
>>> Daniel,
>>> 
>>> Thanks for the thoughtful reply.  I can, at the very least, try and work on 
>>> the stock pgsql scripts to work OOTB with CockroachDB (minus the create 
>>> functions).
>>> 
>>> The only table we really care about UUID right now is subscriber, and we 
>>> can just track that ourselves.
>>> 
>>> I will give kamcli a try, and hopefully will be able to help in the future.
>>> 
>>> Thanks!
>>> 
>>> ~Noah
>>> 
>>>> On Aug 21, 2020, at 4:34 AM, Daniel-Constantin Mierla >>> <mailto:mico...@gmail.com>> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> the default kamailio.cfg is aiming to offer a starting point for building 
>>>> more complex configuration/SIP routing policies, not to offer all the 
>>>> options we support in Kamailio. MySQL is provided there to show how to 
>>>> connect to database, being chosen because it was the first database 
>>>> connect module that was developed and it is kept because it is still very 
>>>> popular. You are more than welcome to add a sample config of using 
>>>> postgress, which can be placed somewhere in the misc/examples/. Making the 
>>>> default config too complex may result in "scaring" the people trying to 
>>>> use Kamailio for first time.
>>>> 
>>>> Using string UUID instead of the auto-increment integer id it will break 
>>>> at least lcr and msilo, iirc. Most of the modules do not use id column, 
>>>> but some do it. Siremis, the web management interface is also using the id 
>>>> field, but it doesn't support Postgres at this moment.
>>>> 
>>>> If you have some Python knowledge (and spare time), maybe you can help 
>>>> adding support for it in kamcli:
>>>> 
>>>>   * https://git

Re: [SR-Users] Weird config parsing issues - 5.4

[Noah Mehl]

Daniel,

I have done this, but that’s why I’m confused, because sometimes it works, and 
sometimes it doesn’t (with no changes to the configs).

I ran a quick grep on the config:

root@inbound-kamailio-test-02:/usr/local/etc/kamailio# grep -i '#!if' 
kamailio.cfg | wc -l
61
root@inbound-kamailio-test-02:/usr/local/etc/kamailio# grep -i '#!end' 
kamailio.cfg | wc -l
61

But again, it fails randomly.  If it really was that the #if[n]def’s didn’t 
match up with the #!endif’s, it would fail consistently?

~Noah


> On Aug 25, 2020, at 9:30 AM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> in such cases, check the config file content and be sure you have 
> corresponding "#!endif" for each #!ifdef or #!ifndef.
> 
> Cheers,
> Daniel
> 
> On 20.08.20 17:46, Noah Mehl wrote:
>> All,
>> 
>> I have built branch 5.4 from source, and I’m working with the default 
>> config.  However, from time to time I get this error when launching kamailio:
>> 
>> root@inbound-kamailio-test-02:~# /usr/local/sbin/kamailio -P 
>> /run/kamailio/kamailio.pid -f /usr/local/etc/kamailio/kamailio.cfg -m 128 -M 
>> 64 -E
>>  0(1296) CRITICAL:  [core/cfg.y:3588]: yyerror_at(): parse error in 
>> config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 30-34: 
>> syntax error
>>  0(1296) CRITICAL:  [core/cfg.y:3588]: yyerror_at(): parse error in 
>> config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 30-34: 
>> Invalid arguments
>>  0(1296) CRITICAL:  [core/cfg.y:3591]: yyerror_at(): parse error in 
>> config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 35: 
>> ERROR: bad config file (3 errors)
>>  0(1296) ERROR:  [core/ppcfg.c:234]: pp_ifdef_level_error(): different 
>> number of preprocessor directives: 1 more #!if[n]def as #!endif
>> 
>> However, if I run a “make install” from the source directory, this error 
>> goes away.  Has anyone run into this issue before?
>> 
>> Configs attached.
>> 
>> Thanks!
>> 
>> ~Noah
>> 
>> 
>> 
>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- 
> www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] CockroachDB and Kamailio

[Noah Mehl]

Daniel/Henning,

I have created a new branch that is much more CockroachDB compatible: 
https://github.com/reperio/kamailio/tree/cockroachdb-compat 
<https://github.com/reperio/kamailio/tree/cockroachdb-compat>

So far, the only thing I’ve noticed that isn’t compatible is: 
https://github.com/reperio/kamailio/blob/62aad6591423e1f693397d33ddefd234938d1293/utils/kamctl/kamdbctl.pgsql#L137
 
<https://github.com/reperio/kamailio/blob/62aad6591423e1f693397d33ddefd234938d1293/utils/kamctl/kamdbctl.pgsql#L137>,
 as the concat() function actually exists in PostgreSQL > 9ish and CockroachDB. 
 That being said, the only difference I can find between MySQL rand() and 
PostgreSQL random() is just the name.  Is this still an issue with the lcr 
module?  If so, can you point me to where it’s being used?

Otherwise, I have tested this update with PostgreSQL and CockroachDB.

Thanks!

~Noah

> On Aug 21, 2020, at 2:38 PM, Noah Mehl  wrote:
> 
> Daniel,
> 
> Thanks for the thoughtful reply.  I can, at the very least, try and work on 
> the stock pgsql scripts to work OOTB with CockroachDB (minus the create 
> functions).
> 
> The only table we really care about UUID right now is subscriber, and we can 
> just track that ourselves.
> 
> I will give kamcli a try, and hopefully will be able to help in the future.
> 
> Thanks!
> 
> ~Noah
> 
>> On Aug 21, 2020, at 4:34 AM, Daniel-Constantin Mierla > <mailto:mico...@gmail.com>> wrote:
>> 
>> Hello,
>> 
>> the default kamailio.cfg is aiming to offer a starting point for building 
>> more complex configuration/SIP routing policies, not to offer all the 
>> options we support in Kamailio. MySQL is provided there to show how to 
>> connect to database, being chosen because it was the first database connect 
>> module that was developed and it is kept because it is still very popular. 
>> You are more than welcome to add a sample config of using postgress, which 
>> can be placed somewhere in the misc/examples/. Making the default config too 
>> complex may result in "scaring" the people trying to use Kamailio for first 
>> time.
>> 
>> Using string UUID instead of the auto-increment integer id it will break at 
>> least lcr and msilo, iirc. Most of the modules do not use id column, but 
>> some do it. Siremis, the web management interface is also using the id 
>> field, but it doesn't support Postgres at this moment.
>> 
>> If you have some Python knowledge (and spare time), maybe you can help 
>> adding support for it in kamcli:
>> 
>>   * https://github.com/kamailio/kamcli <https://github.com/kamailio/kamcli>
>> kamcli aims to be a more modern alternative to kamctl/kamdbctl (e.g., better 
>> input validation, flexibility in output formatting, internal interactive 
>> shell with auto-completion, ...), eventually replacing them in the future. 
>> So far I was focusing on MySQL, being the database type I use. Most of the 
>> commands should just work for Postgres, because db operations are done using 
>> SqlAlchemy package, but a few commands (from the kamcli db ... subcommand) 
>> use the cli tool of the database system. At the end these can be skipped, 
>> iirc, also for kamctl, some of the corresponding subcommands are only for 
>> mysql (like kamctl db connect), but testing and seeing if it works or not 
>> with Postgres or CockroachDB would be appreciated.
>> 
>> Cheers,
>> Daniel
>> 
>> On 20.08.20 22:42, Noah Mehl wrote:
>>> Henning,
>>> 
>>> So, for the default config, it only has the option for: WITH_MYSQL.  I was 
>>> wondering if a WITH_PGSQL would be accepted.
>>> 
>>> As for the kamdbctl scripts, there are a few things I’ve noticed:
>>> 
>>> I would prefer UUID vs SERIAL.  This actually is a little more annoying 
>>> when dealing with the SEQUENCE entity in Postgres.  The only change 
>>> required, is to load the pgcrypto extension and switch to uuid instead of 
>>> SERIAL.  I have a tracking branch here:
>>> 
>>> https://github.com/reperio/kamailio/tree/postgres_uuid 
>>> <https://github.com/reperio/kamailio/tree/postgres_uuid>
>>> 
>>> The other reason is that for cockroachdb, using gen_random_uuid() is 
>>> documented to be more efficient 
>>> <https://www.cockroachlabs.com/docs/stable/create-sequence.html> (in 
>>> addition to being a preference).
>>> 
>>> As for cockroachdb, I have a tracking branch (based on the uuid branch) 
>>> that seems to be working well:
>>> 
>>> https://github.com/reperio/kamailio/tree/cockroach 
>

Re: [SR-Users] CockroachDB and Kamailio

[Noah Mehl]

Daniel,

Thanks for the thoughtful reply.  I can, at the very least, try and work on the 
stock pgsql scripts to work OOTB with CockroachDB (minus the create functions).

The only table we really care about UUID right now is subscriber, and we can 
just track that ourselves.

I will give kamcli a try, and hopefully will be able to help in the future.

Thanks!

~Noah

> On Aug 21, 2020, at 4:34 AM, Daniel-Constantin Mierla  
> wrote:
> 
> Hello,
> 
> the default kamailio.cfg is aiming to offer a starting point for building 
> more complex configuration/SIP routing policies, not to offer all the options 
> we support in Kamailio. MySQL is provided there to show how to connect to 
> database, being chosen because it was the first database connect module that 
> was developed and it is kept because it is still very popular. You are more 
> than welcome to add a sample config of using postgress, which can be placed 
> somewhere in the misc/examples/. Making the default config too complex may 
> result in "scaring" the people trying to use Kamailio for first time.
> 
> Using string UUID instead of the auto-increment integer id it will break at 
> least lcr and msilo, iirc. Most of the modules do not use id column, but some 
> do it. Siremis, the web management interface is also using the id field, but 
> it doesn't support Postgres at this moment.
> 
> If you have some Python knowledge (and spare time), maybe you can help adding 
> support for it in kamcli:
> 
>   * https://github.com/kamailio/kamcli <https://github.com/kamailio/kamcli>
> kamcli aims to be a more modern alternative to kamctl/kamdbctl (e.g., better 
> input validation, flexibility in output formatting, internal interactive 
> shell with auto-completion, ...), eventually replacing them in the future. So 
> far I was focusing on MySQL, being the database type I use. Most of the 
> commands should just work for Postgres, because db operations are done using 
> SqlAlchemy package, but a few commands (from the kamcli db ... subcommand) 
> use the cli tool of the database system. At the end these can be skipped, 
> iirc, also for kamctl, some of the corresponding subcommands are only for 
> mysql (like kamctl db connect), but testing and seeing if it works or not 
> with Postgres or CockroachDB would be appreciated.
> 
> Cheers,
> Daniel
> 
> On 20.08.20 22:42, Noah Mehl wrote:
>> Henning,
>> 
>> So, for the default config, it only has the option for: WITH_MYSQL.  I was 
>> wondering if a WITH_PGSQL would be accepted.
>> 
>> As for the kamdbctl scripts, there are a few things I’ve noticed:
>> 
>> I would prefer UUID vs SERIAL.  This actually is a little more annoying when 
>> dealing with the SEQUENCE entity in Postgres.  The only change required, is 
>> to load the pgcrypto extension and switch to uuid instead of SERIAL.  I have 
>> a tracking branch here:
>> 
>> https://github.com/reperio/kamailio/tree/postgres_uuid 
>> <https://github.com/reperio/kamailio/tree/postgres_uuid>
>> 
>> The other reason is that for cockroachdb, using gen_random_uuid() is 
>> documented to be more efficient 
>> <https://www.cockroachlabs.com/docs/stable/create-sequence.html> (in 
>> addition to being a preference).
>> 
>> As for cockroachdb, I have a tracking branch (based on the uuid branch) that 
>> seems to be working well:
>> 
>> https://github.com/reperio/kamailio/tree/cockroach 
>> <https://github.com/reperio/kamailio/tree/cockroach>
>> 
>> So far, the only issue in the creation/managment of the schema is: CREATE 
>> FUNCTION.  But it looks like maybe concat() and random() are already 
>> supported by cockroackdb: 
>> https://www.cockroachlabs.com/docs/stable/functions-and-operators.html 
>> <https://www.cockroachlabs.com/docs/stable/functions-and-operators.html>.  I 
>> will have to dig deeper into the lcr module to see where/if this is an issue.
>> 
>> Thanks!
>> 
>> ~Noah
>> 
>>> On Aug 20, 2020, at 2:23 PM, Henning Westerholt >> <mailto:h...@skalatan.de>> wrote:
>>> 
>>> Hi Noah,
>>> 
>>> if you find something that does not work with the default PostgreSQL schema 
>>> from kamdbctl, create an issue. It some cases it is just a matter of 
>>> formatting and it can work for PostgreSQL and CockroachDB. This is probably 
>>> the easier path, from an maintenance point of view.
>>> 
>>> What do you mean by default configuration?
>>> 
>>> Cheers,
>>> 
>>> Henning
>>> 
>>> -- 
>>> Henning Westerholt - https://skalatan.de/blog/ <https

Re: [SR-Users] Weird config parsing issues - 5.4

[Noah Mehl]

Adding a new line did not resolve this.

~Noah

> On Aug 20, 2020, at 12:33 PM, Cindy Leung  wrote:
> 
> Try adding a newline at the end of your cfg files.
> 
> On Thu, Aug 20, 2020 at 11:48 AM Noah Mehl  <mailto:noahm...@gmail.com>> wrote:
> All,
> 
> I have built branch 5.4 from source, and I’m working with the default config. 
>  However, from time to time I get this error when launching kamailio:
> 
> root@inbound-kamailio-test-02:~# /usr/local/sbin/kamailio -P 
> /run/kamailio/kamailio.pid -f /usr/local/etc/kamailio/kamailio.cfg -m 128 -M 
> 64 -E
>  0(1296) CRITICAL:  [core/cfg.y:3588]: yyerror_at(): parse error in 
> config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 30-34: 
> syntax error
>  0(1296) CRITICAL:  [core/cfg.y:3588]: yyerror_at(): parse error in 
> config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 30-34: 
> Invalid arguments
>  0(1296) CRITICAL:  [core/cfg.y:3591]: yyerror_at(): parse error in 
> config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 35: 
> ERROR: bad config file (3 errors)
>  0(1296) ERROR:  [core/ppcfg.c:234]: pp_ifdef_level_error(): different 
> number of preprocessor directives: 1 more #!if[n]def as #!endif
> 
> However, if I run a “make install” from the source directory, this error goes 
> away.  Has anyone run into this issue before?
> 
> Configs attached.
> 
> Thanks!
> 
> ~Noah
> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
> <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] CockroachDB and Kamailio

[Noah Mehl]

Henning,

So, for the default config, it only has the option for: WITH_MYSQL.  I was 
wondering if a WITH_PGSQL would be accepted.

As for the kamdbctl scripts, there are a few things I’ve noticed:

I would prefer UUID vs SERIAL.  This actually is a little more annoying when 
dealing with the SEQUENCE entity in Postgres.  The only change required, is to 
load the pgcrypto extension and switch to uuid instead of SERIAL.  I have a 
tracking branch here:

https://github.com/reperio/kamailio/tree/postgres_uuid 
<https://github.com/reperio/kamailio/tree/postgres_uuid>

The other reason is that for cockroachdb, using gen_random_uuid() is documented 
to be more efficient 
<https://www.cockroachlabs.com/docs/stable/create-sequence.html> (in addition 
to being a preference).

As for cockroachdb, I have a tracking branch (based on the uuid branch) that 
seems to be working well:

https://github.com/reperio/kamailio/tree/cockroach 
<https://github.com/reperio/kamailio/tree/cockroach>

So far, the only issue in the creation/managment of the schema is: CREATE 
FUNCTION.  But it looks like maybe concat() and random() are already supported 
by cockroackdb: 
https://www.cockroachlabs.com/docs/stable/functions-and-operators.html 
<https://www.cockroachlabs.com/docs/stable/functions-and-operators.html>.  I 
will have to dig deeper into the lcr module to see where/if this is an issue.

Thanks!

~Noah

> On Aug 20, 2020, at 2:23 PM, Henning Westerholt  wrote:
> 
> Hi Noah,
> 
> if you find something that does not work with the default PostgreSQL schema 
> from kamdbctl, create an issue. It some cases it is just a matter of 
> formatting and it can work for PostgreSQL and CockroachDB. This is probably 
> the easier path, from an maintenance point of view.
> 
> What do you mean by default configuration?
> 
> Cheers,
> 
> Henning
> 
> -- 
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://gilawa.com 
> 
> -Original Message-
> From: Noah Mehl  
> Sent: Thursday, August 20, 2020 6:35 PM
> To: Henning Westerholt 
> Cc: Kamailio (SER) - Users Mailing List 
> Subject: Re: [SR-Users] CockroachDB and Kamailio
> 
> Henning,
> 
> Thanks for the reply!  I am testing away.  I will update with my findings.
> 
> That being said, some things might be slightly different.  Should I add a 
> cockroachdb option to the kamdbctl and default configs as a PR?
> 
> ~Noah
> 
>> On Aug 20, 2020, at 2:35 AM, Henning Westerholt  wrote:
>> 
>> Dear Noah,
>> 
>> it was probably not discussed on the public list, at least I don't remember 
>> it. Cockroachdb claims to be compatible with PostgreSQL, so it should work 
>> with this DB Kamailio module.
>> 
>> If you encounter issues, report on this list, or open a bug report if its 
>> something related to problems in the Kamailio db_postgres module.
>> 
>> Cheers,
>> 
>> Henning
>> 
>> --
>> Henning Westerholt - https://skalatan.de/blog/ Kamailio services - 
>> https://gilawa.com
>> 
>> -Original Message-
>> From: sr-users  On Behalf Of Noah 
>> Mehl
>> Sent: Wednesday, August 19, 2020 10:13 PM
>> To: sr-users@lists.kamailio.org
>> Subject: [SR-Users] CockroachDB and Kamailio
>> 
>> Has anyone been down this path before?  We are trying to test this out and 
>> the results are pretty promising so far.
>> 
>> I realize the lack of Stored Procedures and Triggers make this untenable for 
>> many Postgres based implementations.
>> 
>> Thanks!
>> 
>> ~Noah
>> ___
>> 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] Bug in Postgres SQL Script?

[Noah Mehl]

Ah, I see now.

Thanks!

~Noah

> On Aug 20, 2020, at 2:50 PM, Alex Balashov  wrote:
> 
> On 8/20/20 2:45 PM, Noah Mehl wrote:
> 
>> Basically, there are no tables created for Postgres that end in _id_seq.
> 
> No tables, or no entities?
> 
> https://www.postgresql.org/docs/current/sql-createsequence.html
> 
> https://www.postgresqltutorial.com/postgresql-serial/
> https://www.postgresqltutorial.com/postgresql-identity-column/
> 
> -- Alex
> 
> -- 
> 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

[SR-Users] Bug in Postgres SQL Script?

[Noah Mehl]

Hey all,

I’m trying to understand the following lines in the kamdbctl.pgsql script:

https://github.com/kamailio/kamailio/blob/bf38c7b04171e6f410ff885f10abe0f815d27de9/utils/kamctl/kamdbctl.pgsql#L150-L153
 

https://github.com/kamailio/kamailio/blob/bf38c7b04171e6f410ff885f10abe0f815d27de9/utils/kamctl/kamdbctl.pgsql#L211
 

https://github.com/kamailio/kamailio/blob/bf38c7b04171e6f410ff885f10abe0f815d27de9/utils/kamctl/kamdbctl.pgsql#L245-L246
 


Basically, there are no tables created for Postgres that end in _id_seq.

Am I missing something here?

Thanks!

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

[SR-Users] Weird config parsing issues - 5.4

[Noah Mehl]

All,

I have built branch 5.4 from source, and I’m working with the default config.  
However, from time to time I get this error when launching kamailio:

root@inbound-kamailio-test-02:~# /usr/local/sbin/kamailio -P 
/run/kamailio/kamailio.pid -f /usr/local/etc/kamailio/kamailio.cfg -m 128 -M 64 
-E
 0(1296) CRITICAL:  [core/cfg.y:3588]: yyerror_at(): parse error in 
config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 30-34: 
syntax error
 0(1296) CRITICAL:  [core/cfg.y:3588]: yyerror_at(): parse error in 
config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 30-34: 
Invalid arguments
 0(1296) CRITICAL:  [core/cfg.y:3591]: yyerror_at(): parse error in 
config file /usr/local/etc/kamailio/kamailio.cfg, line 410, column 35: 
ERROR: bad config file (3 errors)
 0(1296) ERROR:  [core/ppcfg.c:234]: pp_ifdef_level_error(): different 
number of preprocessor directives: 1 more #!if[n]def as #!endif

However, if I run a “make install” from the source directory, this error goes 
away.  Has anyone run into this issue before?

Configs attached.

Thanks!

~Noah




kamailio.cfg
Description: Binary data


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

Re: [SR-Users] CockroachDB and Kamailio

[Noah Mehl]

Henning,

Thanks for the reply!  I am testing away.  I will update with my findings.

That being said, some things might be slightly different.  Should I add a 
cockroachdb option to the kamdbctl and default configs as a PR?

~Noah

> On Aug 20, 2020, at 2:35 AM, Henning Westerholt  wrote:
> 
> Dear Noah,
> 
> it was probably not discussed on the public list, at least I don't remember 
> it. Cockroachdb claims to be compatible with PostgreSQL, so it should work 
> with this DB Kamailio module.
> 
> If you encounter issues, report on this list, or open a bug report if its 
> something related to problems in the Kamailio db_postgres module.
> 
> Cheers,
> 
> Henning
> 
> -- 
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://gilawa.com 
> 
> -----Original Message-
> From: sr-users  On Behalf Of Noah Mehl
> Sent: Wednesday, August 19, 2020 10:13 PM
> To: sr-users@lists.kamailio.org
> Subject: [SR-Users] CockroachDB and Kamailio
> 
> Has anyone been down this path before?  We are trying to test this out and 
> the results are pretty promising so far.
> 
> I realize the lack of Stored Procedures and Triggers make this untenable for 
> many Postgres based implementations.
> 
> Thanks!
> 
> ~Noah
> ___
> 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] CockroachDB and Kamailio

[Noah Mehl]

Has anyone been down this path before?  We are trying to test this out and the 
results are pretty promising so far.

I realize the lack of Stored Procedures and Triggers make this untenable for 
many Postgres based implementations.

Thanks!

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

Re: [SR-Users] Kamctl Stats Update

[Noah Mehl]

Alex,

We are using this for time series monitoring (e.g. Zabbix).  It doesn’t make 
sense, at least to me, to implement jsonrpc-s just to get the kamctl stats 
output.  I mean, currently I’m just chaining the output with cut and tr, and 
that’s fine.  I just suggest utilizing JSON a bit better here.

Thanks!

~Noah

> On Sep 20, 2017, at 1:17 PM, Alex Balashov <abalas...@evaristesys.com> wrote:
> 
> You may want to consider an alternate and more streamlined method of pulling 
> these. 
> 
> On September 20, 2017 1:16:49 PM EDT, Noah Mehl <noahm...@gmail.com> wrote:
>> Alex,
>> 
>> This is how that output was generated:
>> 
>> # kamctl stats shmem | jq .
>> 
>> Thanks!
>> 
>> ~Noah
>> 
>>> On Sep 20, 2017, at 1:14 PM, Alex Balashov
>> <abalas...@evaristesys.com> wrote:
>>> 
>>> Hello,
>>> 
>>> The jsonrpc-s module has a pretty_print option. Or is that not where
>> you're dispatching this JSON output from?
>>> 
>>> 
>>> -- Alex
>>> 
>>> --
>>> Sent via mobile, please forgive typos and brevity. 
>>> 
>>> ___
>>> 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
> 
> --
> Sent via mobile, please forgive typos and brevity. 
> 
> ___
> 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] Kamctl Stats Update

[Noah Mehl]

Alex,

This is how that output was generated:

# kamctl stats shmem | jq .

Thanks!

~Noah

> On Sep 20, 2017, at 1:14 PM, Alex Balashov  wrote:
> 
> Hello,
> 
> The jsonrpc-s module has a pretty_print option. Or is that not where you're 
> dispatching this JSON output from?
> 
> 
> -- Alex
> 
> --
> Sent via mobile, please forgive typos and brevity. 
> 
> ___
> 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] Kamctl Stats Update

[Noah Mehl]

Hey all,

I was wondering if the kamctl stats output could be updated to provide a bit 
more parseable JSON?  For instance:

# kamctl stats shmem | jq .
{
  "jsonrpc": "2.0",
  "result": [
"shmem:fragments = 18",
"shmem:free_size = 467187808",
"shmem:max_used_size = 69694104",
"shmem:real_used_size = 69683104",
"shmem:total_size = 536870912",
"shmem:used_size = 41048984"
  ],
  "id": 4300
}

I would hope would be more like this:

{
   "jsonrpc":"2.0",
   "result":[
  {
 "shmem":[
{
   "fragments":18,
   "free_size":467187808,
   "max_used_size":69694104,
   "real_used_size":69683104,
   "total_size":536870912,
   "used_size":41048984
}
 ]
  }
   ],
   "id":4300
}

I apologize in advanced because I don’t have the skillset to contribute such a 
feature.

Thanks!

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