date:20191125

Re: [SR-Users] call not going to end point

2019-11-25 Thread Gaurav Bmotra

hi every one

route[DISPATCH] {


# round robin dispatching on gateways group '1'


if(!ds_select_dst("1", "4")) {


send_reply("404", "No destination");


exit;


}


xdbg("--- SCRIPT: going to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");

t_on_failure("RTF_DISPATCH");


$var(rcv_addr)="sip:"+$si+":"+$sp;


if(starts_with("$var(rcv_addr)","$du"))


{


route(LOCATION);


}


else


{


route(RELAY);


}


exit;


}





hi
i use following logic in config file but still it fail to send call to end
poing which comes form Freeswitch
---*LOGIC*---
# Try next destionations in failure route


failure_route[RTF_DISPATCH] {


xnotice("RTF_DISPATCH: $rm $rU [$ci]");


if (t_is_canceled()) {


exit;


}


# next DST - only for 500 or local timeout


if (t_check_status("(^5)")


or (t_branch_timeout() and !t_branch_replied())) {


xnotice("RTF_DISPATCH: WARNING $du is broken and marked as
inactive");

# ds_mark_dst("ip");


if(ds_next_dst()) {


xdbg("--- SCRIPT: retrying to <$ru> via <$du> (attrs:
$xavp(_dsdst_=>attrs))\n");

t_on_failure("RTF_DISPATCH");


route(RELAY);


exit;


}


}


}
-*logs*
---
Nov 26 04:09:57 ip-172-20-61-37 local0.err rtpproxy[6]:
ERR:create_twinlistener:GENERAL: can't bind to the IPv4 port 36924: Address
not available
Nov 26 04:09:57 ip-172-20-61-37 local0.err rtpproxy[6]:
ERR:rtpp_command_ul_handle:GLOBAL: can't create listener
Nov 26 04:09:57 ip-172-20-61-37 local0.debug rtpproxy[6]:
DBUG:rtpc_doreply:GLOBAL: sending reply "E72 "
Nov 26 04:09:57 ip-172-20-61-37 local0.err kamailio[77]: ERROR: {1 2 INVITE
mzewGszYzkq-UnXdAKNmTg..} rtpproxy [rtpproxy.c:2586]: force_rtp_proxy():
incorrect port 0 in reply from rtp proxy
Nov 26 04:09:57 ip-172-20-61-37 local0.notice kamailio[76]: NOTICE: {1
12816906 INVITE 731e779f-8aa5-1238-4f81-12590b724429}

[SR-Users] Encode host ip in Contact header for semi-stateless setup

2019-11-25 Thread Daniel Greenwald

At kamailio world 2017, Jan Lorenz of Pascom explained how they use
kamailio in a semi-stateless manner and encode the asterisk's IP into the
contact header on the way out so that it can be decoded and used to route
properly on the way back without Record-Routing. I would like to create
such a setup.

I'm looking for pointers if there is a particular module/method that would
be ideal to to use for this. Any other gotcha's to consider in such a
setup. My plan is to keep the transaction on the same kamailio by not
altering the VIA but allow the subsequent in-dialog transactions to
potentially hit another kamailio by changing the contact to a shared SRV
record (and encoding the freeswitch box's IP into it for later retrieval.)

Thanks in advance.

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

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

2019-11-25 Thread Joel Serrano

Done!

https://github.com/kamailio/kamailio/issues/2149

Cheers,
Joel.

On Mon, Nov 25, 2019 at 10:58 AM Henning Westerholt  wrote:

> Yes, makes sense.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* Joel Serrano 
> *Sent:* Monday, November 25, 2019 7:39 PM
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Avoid full table scan for dispatcher table on
> db_redis using ds_reload() from config script
>
>
>
> Should I open a GH issue and move the conversation to there?
>
>
>
> Thanks Henning.
>
>
>
> On Mon, Nov 25, 2019 at 10:36 AM Henning Westerholt 
> wrote:
>
> Hi Joel,
>
>
>
> strange. One reason might be the simple query that the dispatcher module
> is doing, it is basically doing a full table load. Maybe it makes sense to
> disable the warning in this particular case.
>
>
>
> I can’t dig into it right now more, let’s see if somebody of the
> developers of this module might be able to comment here.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
> Kamailio Merchandising – https://skalatan.de/merchandising
>
>
>
> *From:* Joel Serrano 
> *Sent:* Monday, November 25, 2019 7:19 PM
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Avoid full table scan for dispatcher table on
> db_redis using ds_reload() from config script
>
>
>
> Hi Henning,
>
>
>
> I did read the lengthy explanation.. I also tried your suggestion for the
> dispatcher keys modparam but still same problem:
>
>
>
> Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1761]:
> db_redis_query(): querying prefix (table) 'dispatcher'
> Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1811]:
> db_redis_query(): no columns given to build query keys, falling back to
> full table scan
> Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:119]:
> db_new_result(): allocate 56 bytes for result set at 0x7efe768040b0
> Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:156]:
> db_allocate_columns(): allocate 40 bytes for result names at 0x7efe76804150
> Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:167]:
> db_allocate_columns(): allocate 20 bytes for result types at 0x7efe768041e0
> Nov 25 18:01:13 test COPS[17825]: WARNING: db_redis [redis_dbase.c:1098]:
> db_redis_perform_query(): performing full table scan on table 'dispatcher'
> while performing query
>
>
>
> I've tried:
>
>
>
> modparam("db_redis", "keys",
> "version=entry:table_name;dispatcher=entry:id")
>
>
>
> And also separated in different declarations:
>
>
>
> modparam("db_redis", "keys", "version=entry:table_name")
>
> modparam("db_redis", "keys", "dispatcher=entry:id")
>
>
>
> In both cases it's still doing a full table scan and I continue getting
> the warning in the logfile.
>
>
>
> For the sake of testing I did one more attempt with :
>
>
>
> modparam("db_redis", "keys", "version=entry:table_name")
>
> modparam("db_redis", "keys", "dispatcher=entry:destination")
>
>
>
> But same results...
>
>
>
> I do see in the logs that the modparam is applied correctly:
>
>
>
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:200]:
> db_redis_print_all_tables():   table dispatcher
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:203]:
> db_redis_print_all_tables(): schema:
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   description: 3
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   attrs: 3
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   flags: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   destination: 3
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   priority: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   setid: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   id: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:214]:
> db_redis_print_all_tables(): entry keys:
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:217]:
> db_redis_print_all_tables():   id
>
>
>
> But it seems not to change the full table scan behavior...
>
>
>
> Any other suggestions I can try?
>
>
>
> I appreciate your help on this.
>
>
>
> Thanks,
>
> Joel.
>
>
>
>
>
>
>
> On Mon, Nov 25, 2019 at 12:21 AM Henning Westerholt 
> wrote:
>
> Hello Joel,
>
>
>
> You probably read already the lengthy explanation at the module overview
> docs:
>
>
>
>
> https://kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.sec.overview
>
>
>
> A small correction about my previous comment – as the dispat

Re: [SR-Users] How to get the audio codec used for each established call.

2019-11-25 Thread Henning Westerholt

Hello Abdoul,

this line looks like a bug in Kamailio:

 0(18567) CRITICAL:  [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing 
already freed pointer (0x7fb9a0606010), called from core: core/pvapi.c: 
tr_param_free(1833), first free pv: pv_trans.c: tr_parse_string(2425) – ignoring

Please open an issue in our github tracker about it, with the cfg to reproduce 
it would be best.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: sr-users  On Behalf Of Abdoul Osséni
Sent: Friday, November 22, 2019 3:14 PM
To: Daniel-Constantin Mierla 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] How to get the audio codec used for each established 
call.

Hello Daniel-Constantin,

Thank you for your response.

When I try that:

if (is_method("INVITE") && status == 200) {
$var(s) = " ";
$var(codec) = $(rb{line.sw,a=rtpmap}{s.select,1,$var(s)});
}


 0(18567) CRITICAL:  [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing 
already freed pointer (0x7fb9a0606010), called from core: core/pvapi.c: 
tr_param_free(1833), first free pv: pv_trans.c: tr_parse_string(2425) - ignoring
 0(18567) ERROR:  [core/pvapi.c:1105]: pv_parse_spec2(): bad tr in pvar 
name "rb"
 0(18567) ERROR:  [core/pvapi.c:1131]: pv_parse_spec2(): invalid parsing 
in [$(rb{line.sw,a=rtpmap}{s.select,1,$var(s)})] at (4)
 0(18567) CRITICAL:  [core/cfg.y:3537]: yyerror_at(): parse error in 
config file /usr/local/etc/kamailio/kamailio.cfg, line 840, column 17-59: Can't 
get from cache: $(rb{line.sw,a=rtpmap}{s.select,1,$var(s)})
ERROR: bad config file (1 errors)
 0(18567) INFO:  [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not 
initialized

But with the following code, I have no issue
if (is_method("INVITE") && status == 200) {
$var(codec) = $(rb{line.sw,a=rtpmap}{s.select,1, });
}

Abdoul OSSENI


Le ven. 22 nov. 2019 à 11:56, Daniel-Constantin Mierla 
mailto:mico...@gmail.com>> a écrit :

Hello,

there can be many codecs that are selected/offered via SDP, the one actually 
used can be seen in the RTP headers, but Kamailio doesn't relay RTP itself.

If you know that in your deployment there is going to be only one codec 
selected via sdp, then the right place is to take it from the SDP of 200ok, 
when the INVITE request has SDP, or from ACK SDP if the 200ok was the first 
with SDP. It is in the media (m=) line, which has the format:

m=   

For example

m=audio 11424 RTP/AVP 8 101

The the next line should give the first codec id:

$(rb{line.sw,m=}{s.select,3, })

Note that there is a space after '3,'. If doesnt work, try:

$var(s) = " ";

$(rb{line.sw,m=}{s.select,3,$var(s)})

Read more about used transformations at:

  * https://www.kamailio.org/wiki/cookbooks/5.3.x/transformations

However, you may need to do further processing if you want the name of the 
codec, specially for those that have dynamic id, so you need to find the 
mapping in the a=rtpmap line.

You can use embedded scripting (lua, python, javascript, ... see the app_NAME 
modules) to parse the body ($rb variable) and extract what you want from there, 
then set back in an variable (recommended $avp() or $xavp()) that you set to 
extra accounting parameter of acc module.

Cheers,
Daniel
On 22.11.19 11:12, Abdoul Osséni wrote:
Hello all,

I try to save in the CDR the audio codec used for each established call.

Can you help me?

Regards

Abdoul.I


___

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 - April 27-29, 2020, in Berlin -- 
www.kamailioworld.com
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

2019-11-25 Thread Henning Westerholt

Hello George,

as already mentioned, you do dlg_manage() for initial requests. About the 
corner cases – I can only think about some failures in the dialog tracking due 
to user agent issues right now. In normal operation the module should track all 
in-dialog messages due to the internal callbacks. Daniel might be able to add 
something as well.

Cheers,

Henning


--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: sr-users  On Behalf Of George 
Diamantopoulos
Sent: Monday, November 25, 2019 3:57 PM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] dialog module: Does dlg_manage() have to be called for all 
requests?

Hello all,

I've been reading through the dialog module docs again, and there seems to be a 
discrepancy in what's suggested in the docs. In the intro, it is stated that 
'To create the dialog associated with an initial INVITE request, execute the 
function “dlg_manage()"'. Later on, in section "7.10" the following example 
code is provided:
request_route {
...
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = "DLGTIMEOUT";
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
...
}
In this example code, dlg_manage seems to be called for all requests, as it is 
not dependent on the conditional that only requests with no to-tag are to be 
handled.

Previously, Daniel had suggested to me in person that one also run dlg_manage() 
for CANCELs, and in-dialog reINVITEs, BYEs and ACKs to mitigate some buggy 
corner cases. Is this still the case?

What do you guys and gals do in production? Have you had to revise how you use 
dlg_manage in terms of calling it for initial INVITEs only vs all requests? 
Thanks!

BR,
George

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

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

2019-11-25 Thread Henning Westerholt

Yes, makes sense.

Cheers,

Henning

From: Joel Serrano 
Sent: Monday, November 25, 2019 7:39 PM
To: Henning Westerholt 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis 
using ds_reload() from config script

Should I open a GH issue and move the conversation to there?

Thanks Henning.

On Mon, Nov 25, 2019 at 10:36 AM Henning Westerholt 
mailto:h...@skalatan.de>> wrote:
Hi Joel,

strange. One reason might be the simple query that the dispatcher module is 
doing, it is basically doing a full table load. Maybe it makes sense to disable 
the warning in this particular case.

I can’t dig into it right now more, let’s see if somebody of the developers of 
this module might be able to comment here.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: Joel Serrano mailto:j...@textplus.com>>
Sent: Monday, November 25, 2019 7:19 PM
To: Henning Westerholt mailto:h...@skalatan.de>>
Cc: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis 
using ds_reload() from config script

Hi Henning,

I did read the lengthy explanation.. I also tried your suggestion for the 
dispatcher keys modparam but still same problem:

Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1761]: 
db_redis_query(): querying prefix (table) 'dispatcher'
Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1811]: 
db_redis_query(): no columns given to build query keys, falling back to full 
table scan
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:119]: 
db_new_result(): allocate 56 bytes for result set at 0x7efe768040b0
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:156]: 
db_allocate_columns(): allocate 40 bytes for result names at 0x7efe76804150
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:167]: 
db_allocate_columns(): allocate 20 bytes for result types at 0x7efe768041e0
Nov 25 18:01:13 test COPS[17825]: WARNING: db_redis [redis_dbase.c:1098]: 
db_redis_perform_query(): performing full table scan on table 'dispatcher' 
while performing query

I've tried:

modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")

And also separated in different declarations:

modparam("db_redis", "keys", "version=entry:table_name")
modparam("db_redis", "keys", "dispatcher=entry:id")

In both cases it's still doing a full table scan and I continue getting the 
warning in the logfile.

For the sake of testing I did one more attempt with :

modparam("db_redis", "keys", "version=entry:table_name")
modparam("db_redis", "keys", "dispatcher=entry:destination")

But same results...

I do see in the logs that the modparam is applied correctly:

Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:200]: 
db_redis_print_all_tables():   table dispatcher
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:203]: 
db_redis_print_all_tables(): schema:
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   description: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   attrs: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   flags: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   destination: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   priority: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   setid: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   id: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:214]: 
db_redis_print_all_tables(): entry keys:
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:217]: 
db_redis_print_all_tables():   id

But it seems not to change the full table scan behavior...

Any other suggestions I can try?

I appreciate your help on this.

Thanks,
Joel.



On Mon, Nov 25, 2019 at 12:21 AM Henning Westerholt 
mailto:h...@skalatan.de>> wrote:
Hello Joel,

You probably read already the lengthy explanation at the module overview docs:

https://kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.sec.overview

A small correction about my previous comment – as the dispatcher module does a 
full table load anyway during start/re-load, the warning is indeed harmless, 
the number of records in the table does not matter here.

Haven’t tried it myself right now, but what about simply:


modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")

Cheers,

Henning

--
Henning Westerholt – https://s

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

2019-11-25 Thread Joel Serrano

Should I open a GH issue and move the conversation to there?

Thanks Henning.

On Mon, Nov 25, 2019 at 10:36 AM Henning Westerholt  wrote:

> Hi Joel,
>
>
>
> strange. One reason might be the simple query that the dispatcher module
> is doing, it is basically doing a full table load. Maybe it makes sense to
> disable the warning in this particular case.
>
>
>
> I can’t dig into it right now more, let’s see if somebody of the
> developers of this module might be able to comment here.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
> Kamailio Merchandising – https://skalatan.de/merchandising
>
>
>
> *From:* Joel Serrano 
> *Sent:* Monday, November 25, 2019 7:19 PM
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Avoid full table scan for dispatcher table on
> db_redis using ds_reload() from config script
>
>
>
> Hi Henning,
>
>
>
> I did read the lengthy explanation.. I also tried your suggestion for the
> dispatcher keys modparam but still same problem:
>
>
>
> Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1761]:
> db_redis_query(): querying prefix (table) 'dispatcher'
> Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1811]:
> db_redis_query(): no columns given to build query keys, falling back to
> full table scan
> Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:119]:
> db_new_result(): allocate 56 bytes for result set at 0x7efe768040b0
> Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:156]:
> db_allocate_columns(): allocate 40 bytes for result names at 0x7efe76804150
> Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:167]:
> db_allocate_columns(): allocate 20 bytes for result types at 0x7efe768041e0
> Nov 25 18:01:13 test COPS[17825]: WARNING: db_redis [redis_dbase.c:1098]:
> db_redis_perform_query(): performing full table scan on table 'dispatcher'
> while performing query
>
>
>
> I've tried:
>
>
>
> modparam("db_redis", "keys",
> "version=entry:table_name;dispatcher=entry:id")
>
>
>
> And also separated in different declarations:
>
>
>
> modparam("db_redis", "keys", "version=entry:table_name")
>
> modparam("db_redis", "keys", "dispatcher=entry:id")
>
>
>
> In both cases it's still doing a full table scan and I continue getting
> the warning in the logfile.
>
>
>
> For the sake of testing I did one more attempt with :
>
>
>
> modparam("db_redis", "keys", "version=entry:table_name")
>
> modparam("db_redis", "keys", "dispatcher=entry:destination")
>
>
>
> But same results...
>
>
>
> I do see in the logs that the modparam is applied correctly:
>
>
>
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:200]:
> db_redis_print_all_tables():   table dispatcher
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:203]:
> db_redis_print_all_tables(): schema:
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   description: 3
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   attrs: 3
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   flags: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   destination: 3
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   priority: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   setid: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
> db_redis_print_all_tables():   id: 0
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:214]:
> db_redis_print_all_tables(): entry keys:
> Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:217]:
> db_redis_print_all_tables():   id
>
>
>
> But it seems not to change the full table scan behavior...
>
>
>
> Any other suggestions I can try?
>
>
>
> I appreciate your help on this.
>
>
>
> Thanks,
>
> Joel.
>
>
>
>
>
>
>
> On Mon, Nov 25, 2019 at 12:21 AM Henning Westerholt 
> wrote:
>
> Hello Joel,
>
>
>
> You probably read already the lengthy explanation at the module overview
> docs:
>
>
>
>
> https://kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.sec.overview
>
>
>
> A small correction about my previous comment – as the dispatcher module
> does a full table load anyway during start/re-load, the warning is indeed
> harmless, the number of records in the table does not matter here.
>
>
>
> Haven’t tried it myself right now, but what about simply:
>
>
>
> modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
> Kamailio Merchandising – https

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

2019-11-25 Thread Henning Westerholt

Hi Joel,

strange. One reason might be the simple query that the dispatcher module is 
doing, it is basically doing a full table load. Maybe it makes sense to disable 
the warning in this particular case.

I can’t dig into it right now more, let’s see if somebody of the developers of 
this module might be able to comment here.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: Joel Serrano 
Sent: Monday, November 25, 2019 7:19 PM
To: Henning Westerholt 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis 
using ds_reload() from config script

Hi Henning,

I did read the lengthy explanation.. I also tried your suggestion for the 
dispatcher keys modparam but still same problem:

Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1761]: 
db_redis_query(): querying prefix (table) 'dispatcher'
Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1811]: 
db_redis_query(): no columns given to build query keys, falling back to full 
table scan
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:119]: 
db_new_result(): allocate 56 bytes for result set at 0x7efe768040b0
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:156]: 
db_allocate_columns(): allocate 40 bytes for result names at 0x7efe76804150
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:167]: 
db_allocate_columns(): allocate 20 bytes for result types at 0x7efe768041e0
Nov 25 18:01:13 test COPS[17825]: WARNING: db_redis [redis_dbase.c:1098]: 
db_redis_perform_query(): performing full table scan on table 'dispatcher' 
while performing query

I've tried:

modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")

And also separated in different declarations:

modparam("db_redis", "keys", "version=entry:table_name")
modparam("db_redis", "keys", "dispatcher=entry:id")

In both cases it's still doing a full table scan and I continue getting the 
warning in the logfile.

For the sake of testing I did one more attempt with :

modparam("db_redis", "keys", "version=entry:table_name")
modparam("db_redis", "keys", "dispatcher=entry:destination")

But same results...

I do see in the logs that the modparam is applied correctly:

Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:200]: 
db_redis_print_all_tables():   table dispatcher
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:203]: 
db_redis_print_all_tables(): schema:
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   description: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   attrs: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   flags: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   destination: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   priority: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   setid: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]: 
db_redis_print_all_tables():   id: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:214]: 
db_redis_print_all_tables(): entry keys:
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:217]: 
db_redis_print_all_tables():   id

But it seems not to change the full table scan behavior...

Any other suggestions I can try?

I appreciate your help on this.

Thanks,
Joel.



On Mon, Nov 25, 2019 at 12:21 AM Henning Westerholt 
mailto:h...@skalatan.de>> wrote:
Hello Joel,

You probably read already the lengthy explanation at the module overview docs:

https://kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.sec.overview

A small correction about my previous comment – as the dispatcher module does a 
full table load anyway during start/re-load, the warning is indeed harmless, 
the number of records in the table does not matter here.

Haven’t tried it myself right now, but what about simply:


modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: Joel Serrano mailto:j...@textplus.com>>
Sent: Monday, November 25, 2019 12:39 AM
To: Henning Westerholt mailto:h...@skalatan.de>>
Cc: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis 
using ds_reload() from config script

Hi Henning,

That’s the thing, I don’t really understand the doc

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

2019-11-25 Thread Joel Serrano

Hi Henning,

I did read the lengthy explanation.. I also tried your suggestion for the
dispatcher keys modparam but still same problem:

Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1761]:
db_redis_query(): querying prefix (table) 'dispatcher'
Nov 25 18:01:13 test COPS[17825]: DEBUG: db_redis [redis_dbase.c:1811]:
db_redis_query(): no columns given to build query keys, falling back to
full table scan
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:119]:
db_new_result(): allocate 56 bytes for result set at 0x7efe768040b0
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:156]:
db_allocate_columns(): allocate 40 bytes for result names at 0x7efe76804150
Nov 25 18:01:13 test COPS[17825]: DEBUG:  [db_res.c:167]:
db_allocate_columns(): allocate 20 bytes for result types at 0x7efe768041e0
Nov 25 18:01:13 test COPS[17825]: WARNING: db_redis [redis_dbase.c:1098]:
db_redis_perform_query(): performing full table scan on table 'dispatcher'
while performing query

I've tried:

modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")

And also separated in different declarations:

modparam("db_redis", "keys", "version=entry:table_name")
modparam("db_redis", "keys", "dispatcher=entry:id")

In both cases it's still doing a full table scan and I continue getting the
warning in the logfile.

For the sake of testing I did one more attempt with :

modparam("db_redis", "keys", "version=entry:table_name")
modparam("db_redis", "keys", "dispatcher=entry:destination")

But same results...

I do see in the logs that the modparam is applied correctly:

Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:200]:
db_redis_print_all_tables():   table dispatcher
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:203]:
db_redis_print_all_tables(): schema:
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
db_redis_print_all_tables():   description: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
db_redis_print_all_tables():   attrs: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
db_redis_print_all_tables():   flags: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
db_redis_print_all_tables():   destination: 3
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
db_redis_print_all_tables():   priority: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
db_redis_print_all_tables():   setid: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:208]:
db_redis_print_all_tables():   id: 0
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:214]:
db_redis_print_all_tables(): entry keys:
Nov 25 18:16:09 test COPS[18195]: DEBUG: db_redis [redis_table.c:217]:
db_redis_print_all_tables():   id

But it seems not to change the full table scan behavior...

Any other suggestions I can try?

I appreciate your help on this.

Thanks,
Joel.



On Mon, Nov 25, 2019 at 12:21 AM Henning Westerholt  wrote:

> Hello Joel,
>
>
>
> You probably read already the lengthy explanation at the module overview
> docs:
>
>
>
>
> https://kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.sec.overview
>
>
>
> A small correction about my previous comment – as the dispatcher module
> does a full table load anyway during start/re-load, the warning is indeed
> harmless, the number of records in the table does not matter here.
>
>
>
> Haven’t tried it myself right now, but what about simply:
>
>
>
> modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
> Kamailio Merchandising – https://skalatan.de/merchandising
>
>
>
> *From:* Joel Serrano 
> *Sent:* Monday, November 25, 2019 12:39 AM
> *To:* Henning Westerholt 
> *Cc:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Avoid full table scan for dispatcher table on
> db_redis using ds_reload() from config script
>
>
>
> Hi Henning,
>
>
>
> That’s the thing, I don’t really understand the docs, thus way opened this
> thread.
>
>
>
> Can you give me an example of what the keys modparam for dispatcher table
> would look like? I would really appreciate it as I don’t get it after
> reading the docs.
>
>
>
> I don’t have many gateways as this is a test env but still I want to do
> things the correct way. Otherwise every time I reload I get a warning in
> the logs and I rather avoid that warning if I can.
>
>
>
> Thanks,
>
> Joel.
>
>
>
> On Sat, Nov 23, 2019 at 00:34 Henning Westerholt  wrote:
>
> Hello Joel,
>
>
>
> you already quoted the keys modparam docs. 😊 You need to add an entry
> for the dispatcher table to keys as well.
>
>
>
> How many records do you actually have in the dispatcher table? If it is a
> low number (like < 100) or so, it should work also fine without it. IMHO

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

2019-11-25 Thread Sergiu Pojoga

Hi George,

Not sure what 'buggy corner cases' you are referring to, but involving
dlg_manage() makes sense only for initial INVITEs.
IMO in that snippet, dlg_manage() should placed one row higher, within the
curly brackets condition.

Regards,
--Sergiu

On Mon, Nov 25, 2019 at 9:58 AM George Diamantopoulos 
wrote:

> Hello all,
>
> I've been reading through the dialog module docs again, and there seems to
> be a discrepancy in what's suggested in the docs. In the intro, it is
> stated that 'To create the dialog associated with an initial INVITE
> request, execute the function “dlg_manage()"'. Later on, in section
> "7.10" the following example code is provided:
> request_route {
> ...
> if(is_method("INVITE") && !has_totag())
> {
> $dlg_ctx(timeout_route) = "DLGTIMEOUT";
> $dlg_ctx(timeout_bye) = 1;
> }
> dlg_manage();
> ...
> }
> In this example code, dlg_manage seems to be called for all requests, as
> it is not dependent on the conditional that only requests with no to-tag
> are to be handled.
>
> Previously, Daniel had suggested to me in person that one also run
> dlg_manage() for CANCELs, and in-dialog reINVITEs, BYEs and ACKs to
> mitigate some buggy corner cases. Is this still the case?
>
> What do you guys and gals do in production? Have you had to revise how you
> use dlg_manage in terms of calling it for initial INVITEs only vs all
> requests? Thanks!
>
> BR,
> George
>
> ___
> 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] dialog module: Does dlg_manage() have to be called for all requests?

2019-11-25 Thread George Diamantopoulos

Hello all,

I've been reading through the dialog module docs again, and there seems to
be a discrepancy in what's suggested in the docs. In the intro, it is
stated that 'To create the dialog associated with an initial INVITE
request, execute the function “dlg_manage()"'. Later on, in section "7.10"
the following example code is provided:
request_route {
...
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = "DLGTIMEOUT";
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
...
}
In this example code, dlg_manage seems to be called for all requests, as it
is not dependent on the conditional that only requests with no to-tag are
to be handled.

Previously, Daniel had suggested to me in person that one also run
dlg_manage() for CANCELs, and in-dialog reINVITEs, BYEs and ACKs to
mitigate some buggy corner cases. Is this still the case?

What do you guys and gals do in production? Have you had to revise how you
use dlg_manage in terms of calling it for initial INVITEs only vs all
requests? Thanks!

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

Re: [SR-Users] Kamailio developers meeting - follow up remarks

2019-11-25 Thread Daniel-Constantin Mierla

Hello,

one addition to section 8):

  * it was discussed if internal libraries still have a good purpose,
given low activity there and some of the libs there are used in a few
modules, which case also use intermodule API, while some are becoming
more like general purpose scope (json lib, with use in rpc control
interface, or uuid). There is also some complexity added to packaging
dependencies, as many packages we do with modules depend on same
internal lib. As a result, code from internal libs may be relocated over
time.

Cheers,
Daniel

On 22.11.19 09:59, Daniel-Constantin Mierla wrote:
> Hello,
>
> last week we had the 2nd annual Kamailio Developers Meeting hosted by
> Sipgate in Dusseldorf, Germany:
>
>   * https://www.kamailio.org/w/developers-meeting/
>
> 16 people were at the event in various roles.
>
> Giacomo Vacca published on his blog a good summary of what happened there:
>
>   *
> https://www.giacomovacca.com/2019/11/my-notes-on-kamailio-developer-meeting.html
>
> This year we had a lot of discussions, as well as work done on multiple
> planes, not only Kamailio code. So I am trying to list here some of the
> conclusions for future development, the technical aspects of the
> meeting, so everyone is aware and can provide feedback.
>
> 1) Effective work was done on:
>
>   * kamailio code
>   * kamailio rpm packaging
>   * kamailio tools (kamctl)
>   * kamailio release process
>   * kamailio project keys (to be used to sign the packages)
>
> 2) Documentation
>
> 2.a) Wiki
>
>   * it was somehow a rough consensus to move the wiki content to github,
> along with changing the format from dokuwiki markdown to the
> standard/github markdown. This should enable people to make pull
> requests so developers or community members can review and aprove new
> content. It also makes it easier to contribute using existing github
> account, now the kamailio.org/wiki is requiring to make a dedicated
> account, which many prefer not to do it.
>
>   * the presentation can be done either by using mkdocs to generate html
> files hosted on kamailio.org or using the github provided wiki portal.
>
>  2.b) Docs for variables and transformations
>
>   * there was a proposal to move them in the documentation the modules
> that export them, there are pros and cons, needs more discussions. Now
> they are in the wiki, so this probably has to resume after deciding on 2.a).
>
> 3) Kamailio Modules
>
> 3.a) replication (dmq) - several participants discussed about
> negotiations between nodes to take active role on some cases (e.g.,
> active dialogs)
>
> 3.b) api integration - quite some interest in JSON-based API routing,
> concluding in extending rtjson to cover more use cases
>
> 3.c) security - have options to restrict the use of TLS1.3 or newer
>
> 4) Kamailio Releases
>
>   * v5.3.2 was released during the event, allowing to document the process
>   * work to automatize the process is planned, then eventually assing
> teams for takeing cares of releases from specific branches
>
> 5) Kamailio Testing
>
>   * existing docker-based testing framework should be extended and
> integrated in CD/CI pipeline
>
> 6) Kamailio packages
>
> 6.a) rpms
>
>   * rpm.kamailio.org has been prepared and is expected to take over the
> opensuse build service for building rpms and hosting them. Expected to
> provide support for hosting many kamailio versions in the same release
> series so one can do downgrade to older releases. Also, there is work in
> progress to provide nightly builds.
>
> 6.b) debs
>
>   * work is planned to offer many kamailio versions in the same release
> series
>
> 7) Kamailio tools
>
>   * kamctl/kamdbctl should be obsoleted in favor of kamcli, which offers
> a better framework for input validation and output formatting, as well
> as better portability, no longer depending on shell interpreter
>
> 8) Various discussions
>
>   * kemi exports from C point of view and how to combine the
> documentation for modules and their kemi exports
>   * how to make kamaiio friendlier in virtualized environments (ended up
> in the need of making the use of advertised address a bit more dynamic)
>   * project organizatoric topics - to be approached separately
>   * next events - Fosdem - someone should submit a proposal to present
> about Kamailio
>
> 9) Long term goals
>
> We speak here more or less about Kamailio 6.0 ...
>
>   * change the behaviour of the native config interpreter to be
> consistent with the other programming languages in terms of handling the
> response code (change what is now: the evaluation of negative value to
> false and positive value to true and the hidden return 0 to exit)
>
>   * make the pool of processes more generic, so they can handle traffic
> from more sockets (being sip traffic or something else) -- this should
> make better use of resources, as some sockets might be less busy that others
>
> I hope I covered the important topics, if I remember something else, I
> will reply on this thread. Or maybe

Re: [SR-Users] SDP Modification

2019-11-25 Thread Daniel Tryba

On Sun, Nov 24, 2019 at 07:35:47PM +0600, Sujit Roy wrote:
> How can i change  c= and o= in SDP  using RTPProxy ?

You must have read over it in the documentation:
https://www.kamailio.org/docs/modules/stable/modules/rtpproxy.html#rtpproxy.f.rtpproxy_ofrer

Thus by using the c and/or o flags your question might be answered.

If you need a complete example searching for "kamailio rtpproxy example
config" found this for me:
https://github.com/sipwise/kamailio/blob/master/etc/kamailio.cfg
(and many more).


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

Re: [SR-Users] Passing media thru RTP Proxy

2019-11-25 Thread Daniel-Constantin Mierla

Hello,

a quick hint is to call rtpproxy_manage(...) for all the SIP requests
and replies with SDP body, plus CANCEL and BYE (to close the rtp relay
session).

Cheers,
Daniel

On 25.11.19 10:16, Sujit Roy wrote:
> Hello
>
> I have installed and configured both Kamailio and RTP Proxy and calls
> are going. But i m unable to force media to go thru RTP Proxy.
>
> How can i enforce media to go thru RTP Proxy ? 
>
> Thanks
>
> -- 
> Regards
> ===
> Sujit Roy
>
>
> ___
> 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 - April 27-29, 2020, in Berlin -- 
www.kamailioworld.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 stopped relaying SIP text message from asterisk

2019-11-25 Thread Daniel-Constantin Mierla

Hello,

if you don't see the INFO log message (and you have at least debug=2),
then the MESSAGE didn't get to Kamailio. Check to see if you have a
firewall rule or other system limits that can drop the traffic.

sngrep/ngrep should show if the traffic was on the network, they use
hooks before the firewall, ...

Then, as alternative to siptrace, you can look at sipdump if you want to
avoid using a database to catch the traffic processed by kamailio for
troubleshooting reasons.

Cheers,
Daniel

On 25.11.19 10:34, Adesh Pandey wrote:
> Hi Karsten,
> I have added the if block inside my request_route block but message
> method was not detected.
>
> On Mon, Nov 25, 2019 at 2:35 PM Karsten Horsmann  > wrote:
>
> Hi Adesh,
>
> sngrep is an great debugging tool for that purpose.
>
> You can use the siptrace module for recording your sip-messages in
> a database.
>
> route[MESSAGE] {
>     if (is_method("MESSAGE")) {
>         xlog("L_INFO", "[MESSAGE] this is an MSG from <$fU> to
> <$rU>\n");
>         sip_trace();
>     }
>     return;
> }
>
> Example playaround config from me:
> 
> https://github.com/khorsmann/kamailio-keepalived/blob/master/roles/kamailio/templates/etc/kamailio/kamailio.cfg.j2#L596
>
> Cheers
> Karsten
>
> Am Mo., 25. Nov. 2019 um 08:37 Uhr schrieb Adesh Pandey
> mailto:adesh.pan...@myoperator.co>>:
>
> Hi,
> I have been working on kamailio with following scenario:
>
> 1. Webrtc SIP Users register to Kamailio
> 2. Users initiate outgoing calls to some other numbers 
> 3. Kamailio dispatches outgoing calls to Asterisk 
> 4. Asterisk answers the call and then send a text message to
> the caller using SendText, which was working fine a few days
> back but all of sudden it has stopped working
> 5. At Asterisk end it is showing that message was delivered
> successfully but when I check SIP user logs, there is no
> message event.
>
> Please review my config file at following URL:
> https://gist.github.com/adeshpandey/2c338db7f5d992267f7415de0325e0b4
>
> Developers, I also want to know if there is any way to log
> *text message* in kamailio server. 
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> -- 
> Mit freundlichen Grüßen
> *Karsten Horsmann*
> ___
> 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 - April 27-29, 2020, in Berlin -- 
www.kamailioworld.com

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

Re: [SR-Users] Passing media thru RTP Proxy

2019-11-25 Thread Henning Westerholt

Hello Sujit,

Have a look to the docs:

https://kamailio.org/docs/modules/stable/modules/rtpproxy.html#rtpproxy.f.rtpproxy_ofrer

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: sr-users  On Behalf Of Sujit Roy
Sent: Monday, November 25, 2019 10:17 AM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Passing media thru RTP Proxy

Hello

I have installed and configured both Kamailio and RTP Proxy and calls are 
going. But i m unable to force media to go thru RTP Proxy.

How can i enforce media to go thru RTP Proxy ?

Thanks

--
Regards
===
Sujit Roy

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

Re: [SR-Users] Kamailio stopped relaying SIP text message from asterisk

2019-11-25 Thread Adesh Pandey

Hi Karsten,
I have added the if block inside my request_route block but message method
was not detected.

On Mon, Nov 25, 2019 at 2:35 PM Karsten Horsmann 
wrote:

> Hi Adesh,
>
> sngrep is an great debugging tool for that purpose.
>
> You can use the siptrace module for recording your sip-messages in a
> database.
>
> route[MESSAGE] {
> if (is_method("MESSAGE")) {
> xlog("L_INFO", "[MESSAGE] this is an MSG from <$fU> to <$rU>\n");
> sip_trace();
> }
> return;
> }
>
> Example playaround config from me:
>
> https://github.com/khorsmann/kamailio-keepalived/blob/master/roles/kamailio/templates/etc/kamailio/kamailio.cfg.j2#L596
>
> Cheers
> Karsten
>
> Am Mo., 25. Nov. 2019 um 08:37 Uhr schrieb Adesh Pandey <
> adesh.pan...@myoperator.co>:
>
>> Hi,
>> I have been working on kamailio with following scenario:
>>
>> 1. Webrtc SIP Users register to Kamailio
>> 2. Users initiate outgoing calls to some other numbers
>> 3. Kamailio dispatches outgoing calls to Asterisk
>> 4. Asterisk answers the call and then send a text message to the caller
>> using SendText, which was working fine a few days back but all of sudden it
>> has stopped working
>> 5. At Asterisk end it is showing that message was delivered successfully
>> but when I check SIP user logs, there is no message event.
>>
>> Please review my config file at following URL:
>> https://gist.github.com/adeshpandey/2c338db7f5d992267f7415de0325e0b4
>>
>> Developers, I also want to know if there is any way to log *text message*
>> in kamailio server.
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Mit freundlichen Grüßen
> *Karsten Horsmann*
> ___
> 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] Passing media thru RTP Proxy

2019-11-25 Thread Sujit Roy

Hello

I have installed and configured both Kamailio and RTP Proxy and calls are
going. But i m unable to force media to go thru RTP Proxy.

How can i enforce media to go thru RTP Proxy ?

Thanks

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

Re: [SR-Users] Kamailio stopped relaying SIP text message from asterisk

2019-11-25 Thread Karsten Horsmann

Hi Adesh,

sngrep is an great debugging tool for that purpose.

You can use the siptrace module for recording your sip-messages in a
database.

route[MESSAGE] {
if (is_method("MESSAGE")) {
xlog("L_INFO", "[MESSAGE] this is an MSG from <$fU> to <$rU>\n");
sip_trace();
}
return;
}

Example playaround config from me:
https://github.com/khorsmann/kamailio-keepalived/blob/master/roles/kamailio/templates/etc/kamailio/kamailio.cfg.j2#L596

Cheers
Karsten

Am Mo., 25. Nov. 2019 um 08:37 Uhr schrieb Adesh Pandey <
adesh.pan...@myoperator.co>:

> Hi,
> I have been working on kamailio with following scenario:
>
> 1. Webrtc SIP Users register to Kamailio
> 2. Users initiate outgoing calls to some other numbers
> 3. Kamailio dispatches outgoing calls to Asterisk
> 4. Asterisk answers the call and then send a text message to the caller
> using SendText, which was working fine a few days back but all of sudden it
> has stopped working
> 5. At Asterisk end it is showing that message was delivered successfully
> but when I check SIP user logs, there is no message event.
>
> Please review my config file at following URL:
> https://gist.github.com/adeshpandey/2c338db7f5d992267f7415de0325e0b4
>
> Developers, I also want to know if there is any way to log *text message*
> in kamailio server.
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Mit freundlichen Grüßen
*Karsten Horsmann*
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

2019-11-25 Thread Henning Westerholt

Hello Joel,

You probably read already the lengthy explanation at the module overview docs:

https://kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.sec.overview

A small correction about my previous comment – as the dispatcher module does a 
full table load anyway during start/re-load, the warning is indeed harmless, 
the number of records in the table does not matter here.

Haven’t tried it myself right now, but what about simply:


modparam("db_redis", "keys", "version=entry:table_name;dispatcher=entry:id")

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: Joel Serrano 
Sent: Monday, November 25, 2019 12:39 AM
To: Henning Westerholt 
Cc: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis 
using ds_reload() from config script

Hi Henning,

That’s the thing, I don’t really understand the docs, thus way opened this 
thread.

Can you give me an example of what the keys modparam for dispatcher table would 
look like? I would really appreciate it as I don’t get it after reading the 
docs.

I don’t have many gateways as this is a test env but still I want to do things 
the correct way. Otherwise every time I reload I get a warning in the logs and 
I rather avoid that warning if I can.

Thanks,
Joel.

On Sat, Nov 23, 2019 at 00:34 Henning Westerholt 
mailto:h...@skalatan.de>> wrote:
Hello Joel,

you already quoted the keys modparam docs. 😊 You need to add an entry for the 
dispatcher table to keys as well.

How many records do you actually have in the dispatcher table? If it is a low 
number (like < 100) or so, it should work also fine without it. IMHO the 
warning is there in case people forget to add it on huge tables. And of course, 
it is “the right thing to do” from an implementation point of view.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com
Kamailio Merchandising – https://skalatan.de/merchandising

From: sr-users 
mailto:sr-users-boun...@lists.kamailio.org>>
 On Behalf Of Joel Serrano
Sent: Saturday, November 23, 2019 1:18 AM
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>
Subject: Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis 
using ds_reload() from config script

Just in case:

Kam version - latest nightly deb (5.4.0~dev1+0~20191122005600.1540+buster)

Redis config:

loadmodule "db_redis.so"
modparam("db_redis", "keys", "version=entry:table_name")
...
modparam("dispatcher", "db_url", "redis://X.X.X.X:6379/2")


Thanks!
Joel.

On Fri, Nov 22, 2019 at 1:48 PM Joel Serrano 
mailto:j...@textplus.com>> wrote:
Hello,

I'm trying out redis as db backend, and right now I only have dispatcher 
records there... Every so often, I do a ds_reload() from within Kam config 
script, and I see in logs:

Nov 22 20:36:35 test COPS[25531]: WARNING: db_redis [redis_dbase.c:1098]: 
db_redis_perform_query(): performing full table scan on table 'dispatcher' 
while performing query
After enabling debug logs:

Nov 22 21:15:35 test COPS[26661]: DEBUG: db_redis [redis_dbase.c:1761]: 
db_redis_query(): querying prefix (table) 'dispatcher'
Nov 22 21:15:35 test COPS[26661]: DEBUG: db_redis [redis_dbase.c:1811]: 
db_redis_query(): no columns given to build query keys, falling back to full 
table scan
Nov 22 21:15:35 test COPS[26661]: DEBUG:  [db_res.c:119]: 
db_new_result(): allocate 56 bytes for result set at 0x7f0be4273898
Nov 22 21:15:35 test COPS[26661]: DEBUG:  [db_res.c:156]: 
db_allocate_columns(): allocate 40 bytes for result names at 0x7f0be4273938
Nov 22 21:15:35 test COPS[26661]: DEBUG:  [db_res.c:167]: 
db_allocate_columns(): allocate 20 bytes for result types at 0x7f0be42739c8
Nov 22 21:15:35 test COPS[26661]: WARNING: db_redis [redis_dbase.c:1098]: 
db_redis_perform_query(): performing full table scan on table 'dispatcher' 
while performing query
Given the msg... "no columns given to build query keys, falling back to full 
table scan", I assume I'm missing a keys modparam.. but I don't know how to 
build it, and the docs (to me) seem confusing?

https://kamailio.org/docs/modules/devel/modules/db_redis.html#db_redis.p.keys

Can anyone help me understand how to build the keys modparam for dispatcher 
table? Or if the reason for this is different, what do I need to do to avoid 
the full table scan and the warning in the log?

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] call not going to end point

[SR-Users] Encode host ip in Contact header for semi-stateless setup

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

Re: [SR-Users] How to get the audio codec used for each established call.

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

Re: [SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

[SR-Users] dialog module: Does dlg_manage() have to be called for all requests?

Re: [SR-Users] Kamailio developers meeting - follow up remarks

Re: [SR-Users] SDP Modification

Re: [SR-Users] Passing media thru RTP Proxy

Re: [SR-Users] Kamailio stopped relaying SIP text message from asterisk

Re: [SR-Users] Passing media thru RTP Proxy

Re: [SR-Users] Kamailio stopped relaying SIP text message from asterisk

[SR-Users] Passing media thru RTP Proxy

Re: [SR-Users] Kamailio stopped relaying SIP text message from asterisk

Re: [SR-Users] Avoid full table scan for dispatcher table on db_redis using ds_reload() from config script

20 matches

Site Navigation

Mail list logo

Footer information