Hello guys,
I'm testing the dispatcher with the dialog module.
After making several test calls, which are properly routed, the number of
dialogs stay there for a while, preventing new calls from going to those
destinations:
"SET": {
"ID": 101,
"TARGETS": [{
"DEST": {
"URI": "sip:1.2.3.4:5080",
"FLAGS": "AP",
"PRIORITY": 0,
"ATTRS": {
"BODY":
"weight=100;maxload=10;duid=bedd39c7-6c73-4477-ae7d-77f8cdc96797",
"DUID": "bedd39c7-6c73-4477-ae7d-77f8cdc96797",
"MAXLOAD": 10,
"WEIGHT": 100,
"RWEIGHT": 0,
"SOCKET": ""
},
"RUNTIME": {
"DLGLOAD": 10
}
}
}]
The calls have been down for several seconds, but the "DLGLOAD" parameter
doesn't go down, even though
/usr/local/kamailio5/sbin/kamctl', 'dialog', 'show
Output the correct amount of dialogs.
I set the dialog handler just before relaying out:
t_on_failure("RTF_DISPATCH");
set_dlg_profile("gateways","$du");
route(RELAY);
And the module is supposed to remove them automatically.
Am i doing something wrong?
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
ᐧ
Hello guys,
is there any way of printing out the selected gw current calls? i.e.:
if(ds_select_dst("1", "4"))
{
xlog("L_ERR", "[DISPATCH] $ci: ds_select_routes was succesful (du:
<$du>)\n");
****** PRINT GWs CALLS *******
} else {
xlog("L_ERR", "[DISPATCH] $ci: did NOT find a gateway to use!\n");
send_reply("404", "No destination");
exit;
}
xlog("L_DBG", "[DISPATCH] $ci: going to <$ru> via <$du>\n");
t_on_failure("RTF_DISPATCH");
route(RELAY);
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
ᐧ
I just had the same thing happen to me. I installed Kamailio via Apt, and I'm using a dedicated MySQL server, with non-root admin credentials.
Previously today I installed it using a local MySQL 5.7 database with no issues.
Kamailio Host: Kamailio 5.1.2 (Ubuntu 18.04)
MySQL Host: MySQL 8.0.13 (Windows Server 2012 R2)
It creates the database, then fails at granting permissions. Accounts were created and privileges flushed before executing.
> root@kamailio:~# kamdbctl create
> INFO: creating database kamailio ...
> mysql: [Warning] Using a password on the command line interface can be insecure.
> INFO: granting privileges to database kamailio ...
> mysql: [Warning] Using a password on the command line interface can be insecure.
> ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'IDENTIFIED BY '<password>'' at line 1
I turned on query logging on the database host but didn't see any errors there, or in the error log itself.
> 2018-11-21T01:58:15.045586Z 8 Connect <user>@kamailio on using SSL/TLS
> 2018-11-21T01:58:15.046239Z 8 Query select @@version_comment limit 1
> 2018-11-21T01:58:15.046764Z 8 Query CREATE DATABASE kamailio CHARACTER SET utf8mb4
> 2018-11-21T01:58:15.189109Z 8 Quit
> 2018-11-21T01:58:15.208476Z 9 Connect <user>@kamailio on using SSL/TLS
> 2018-11-21T01:58:15.209019Z 9 Query select @@version_comment limit 1
> 2018-11-21T01:58:15.210114Z 9 Quit
I've tried with the default MySQL 5.7 Client on Ubuntu, and upgrading it to 8.0.13, but got the same result.
Unfortunately I don't know how to see the output of the SQL Statement being sent (without installing 5.7), or I'd try to run it manually.
- Jonathan
hello all
using version 5.2.0-rc0 of kamailio, we are trying to track the dialogs of dialog module using db_redis module with this setup
#!define DBURL_DIALOG "redis://127.0.0.1:6390/7"
# ----- dialog params -----
modparam("dialog", "db_url", DBURL_DIALOG)
modparam("dialog", "enable_stats", 1)
modparam("dialog", "hash_size", 16384)
modparam("dialog", "dlg_flag", 31)
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "db_mode", 1)
modparam("dialog", "timer_procs", 1)
modparam("dialog", "db_update_period", 1)
# ----- db_redis params -----
modparam("db_redis", "schema_path", "/usr/local/kamailio/share/kamailio/db_redis/kamailio")
modparam("db_redis", "keys", "dialog=entry:hash_entry,hash_id,callid")
modparam("db_redis", "keys", "dialog_vars=entry:hash_entry,hash_id,dialog_key,dialog_value")
and we see it works and if a kamailio instance resets in the middle of a dialog it recovers all the dlg_vars and values because we have the db_skip_load to 0 in dialog module.
But we have noticed that the redis is being written with the information of the dlg_var assigned until that moment when we get a provisional response with SDP, and we dom see a set on the redis with the dialog entry and id untill call is connected.
Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: INFO: Call-ID 1-1511(a)9.7.8.1: Status 180
Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update
Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry'
Nov 16 13:22:55 proxy-1 /usr/local/kamailio/sbin/kamailio[22424]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id'
on the redis (we only see hmset for dialog_vars key)
1542374575.721816 [7 127.0.0.1:56858] "HMSET" "dialog_vars:entry::13725:16494:_uac_funew:sip:1231215423@voda.interconnect.manxtelecom.im" "hash_entry" "13725" "hash_id" "16494" "dialog_key" "_uac_funew" "dialog_value" "sip:1231215423@voda.interconnect.manxtelecom.im"
1542374575.722001 [7 127.0.0.1:56858] "HMSET" "dialog_vars:entry::13725:16494:_uac_fu:sip:anonymous@voda.interconnect.manxtelecom.im" "hash_entry" "13725" "hash_id" "16494" "dialog_key" "_uac_fu" "dialog_value" "sip:anonymous@voda.interconnect.manxtelecom.im"
....
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: INFO: Call-ID 1-1511(a)9.7.8.1: Status 200
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog_vars' while performing update
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry'
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id'
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22425]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 2 is 'dialog_key'
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry'
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id'
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1489]: db_redis_perform_update(): performing full table scan on table 'dialog' while performing update
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 0 is 'hash_entry'
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: WARNING: db_redis [redis_dbase.c:1492]: db_redis_perform_update(): scan key 1 is 'hash_id'
Nov 16 13:23:05 proxy-1 /usr/local/kamailio/sbin/kamailio[22426]: INFO: Call-ID 1-1511(a)9.7.8.1: ACK received in A-Leg
on the redis
1542374585.810520 [7 127.0.0.1:56882] "SCAN" "0" "MATCH" "dialog:entry::*" "COUNT" "1000"
1542374585.810672 [7 127.0.0.1:56882] "EXISTS" "dialog:entry::13725:16494:1-1511@9.7.8.1"
1542374585.810683 [7 127.0.0.1:56882] "HMGET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "hash_entry" "hash_id"
1542374585.810776 [7 127.0.0.1:56882] "HMSET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "state" "4" "timeout" "1542377585" "caller_cseq" "1" "callee_cseq" "0" "caller_contact" "sip:0000123456@9.7.8.1:5084" "callee_contact" "sip:50622959898@9.70.1.52:5060;transport=udp"
1542374585.810899 [7 127.0.0.1:56882] "SCAN" "0" "MATCH" "dialog:entry::*" "COUNT" "1000"
1542374585.810969 [7 127.0.0.1:56882] "EXISTS" "dialog:entry::13725:16494:1-1511@9.7.8.1"
1542374585.810977 [7 127.0.0.1:56882] "HMGET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "hash_entry" "hash_id"
1542374585.811059 [7 127.0.0.1:56882] "HMSET" "dialog:entry::13725:16494:1-1511@9.7.8.1" "state" "4" "timeout" "1542377585" "caller_cseq" "1" "callee_cseq" "0" "caller_contact" "sip:0000123456@9.7.8.1:5084" "callee_contact" "sip:50622959898@9.70.1.52:5060;transport=udp"
i don't see a redis set order to update the dialog entry key before the 200OK is received, to create and update state 1, etc. when created with dlg_manage command
could you please check if we might be missing something?
thanks a lot and regards
david
Hello,
I'm trying to configure Kamailio to be "Presence Server". Simple scheme:
two phones (one "hard phone" Grandstream GXP1620 and "Soft phone"
MicroSIP) and Kamailio server with default configuration. So when
"MicroSIP" send SIP SUBSCRIBE to Kamailio, server response with SIP NOTIFY
but without XML part. Then when hard phone change his status from "Ready"
to "Ringing" and then "On-The-Phone" Kamailio is not sending any SIP
NOTIFY messages. Is this normal behavior or I missed something? (In DB I
have records in "active_watchers" and "watchers" tables but not in
"presentity" table)
======================================================================
====================== Module configuration: =============================
======================================================================
#!ifdef WITH_PRESENCE
loadmodule "presence.so"
loadmodule "presence_xml.so"
#!endif
#!ifdef WITH_PRESENCE
# ----- presence params -----
modparam("presence", "db_url", DBURL)
modparam("presence", "server_address", "sip:10.0.6.123:5060")
# ----- presence_xml params -----
modparam("presence_xml", "db_url", DBURL)
modparam("presence_xml", "force_active", 1)
#!endif
======================================================================
==============================================================
======================== Route: ================================
==============================================================
route[PRESENCE] {
if(!is_method("PUBLISH|SUBSCRIBE"))
return;
#!ifdef WITH_PRESENCE
if (!t_newtran()) {
sl_reply_error();
exit;
}
if(is_method("PUBLISH")) {
handle_publish();
t_release();
} else if(is_method("SUBSCRIBE")) {
handle_subscribe();
t_release();
}
exit;
#!endif
# if presence enabled, this part will not be executed
if (is_method("PUBLISH") || $rU==$null) {
sl_send_reply("404", "Not here");
exit;
}
return;
}
================================================================
Thanks in advance
Denislav Raychev Tsonev | Integration and Infrastructure Engineer |
Musala Soft JSC
www.musala.com | t: +359 2 969 58 21 | m: +359 878 270 965 | f:
+359 2 969 58 22
World Trade Center, 36 Dragan Tsankov blvd., Sofia 1057, Bulgaria
Hi!
Am I missing something or it’s a bug?
Idea is following. I’m using dispatcher to load-balance calls. Using same weight destinations, order like in a file.
So, dispatcher.list looks like
1 sip:172.28.11.6:5060
1 sip:172.28.11.4:5060
I’m using round-robin algo with
ds_select_dst(«1», «4»)
But when it selects 172.28.11.4 and it for a reason not working, it will never come back to 172.28.11.6.
Log:
… Relaying packet du: sip:172.28.11.4:5060
… BYE/INVITE timeout with no reply
… 49(59) WARNING: dispatcher [dispatch.c:2314]: ds_update_dst(): no xavp uri field in next destination record ((nil))
modparam("dispatcher", "list_file", "/tmp/kamailio/dispatcher.list")
modparam("dispatcher", "flags", 2)
modparam("dispatcher", "force_dst", 1)
modparam("dispatcher", "ds_hash_size", 9)
Kamailio: version: kamailio 5.2.0-pre0
Regards, Igor
Hello,
Is there a formula/algorithm that determines how many TCP connections are
made per child process to a database server defined by sqlops' sqlcon
parameter?
ex: if i have 1 database on a database server defined by sqlcon, and i have
1 UDP child process, i notice that the child process has made 2 TCP
connections to the database server.
ex: if i have 3 databases on the same database server defined by 3 sqlcon
statements (1 pertaining to each database) and i have 4 UDP child
processes, i notice that each child process makes 4 TCP connections to the
database server.
ex: if i have 3 databases on the same database server defined by 3 sqlcon
statements (1 pertaining to each database) and i have 6 TCP child
processes, i notice that each child process makes 4 TCP connections to the
database server.
Basically wanting to know what governs the number of tcp connections a
child process makes to a particular database server.
Thank you,
Karthik
I am working on a VoLTE/IMS scenario to transfer text messages as SMS over
IP (+g.3gpp.smsip feature) between UE's. This is a high-level view of the
message flows between the endpoints (not showing CSCFs):
UE1 IP-SM-GW
|---- MESSAGE (SUBMIT) --------------->|
|<------------------- 202 ACCEPTED ----|
| |
|<-------- MESSAGE (SUBMIT_REPORT) ----|
|---- 200 OK ------------------------->|
|
UE2 |
| |
|<-------------- MESSAGE (DELIVER) ----|
|---- 200 OK ------------------------->|
The messages does get transferred from UE1 to UE2 successfully. Since this
is GSM-style SMS, the OA (originating address) and DA (destination address)
are specified using telephone numbers, not sip addresses. This is not a
problem for the DA, since it is specified in the SUBMIT TPDU from the
originating handset, but when the IP-SM-GW sends the DELIVER TPDU it needs
to specify the OA so that the recipient knows who sent the SMS, and this was
not provided in the MESSAGE with the SMS-SUBMIT.
According to 3GPP TS 24.341 (http://www.qtc.jp/3GPP/Specs/24341-b20.pdf):
"The IP-SM-GW will have to use an address of the SM-over-IP sender that the
SC can process (i.e. an E.164 number). This address will come from a tel
URI in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in
the SIP MESSAGE request by the P-CSCF or S-CSCF."
Looking at the MESSAGE request sent from the S-CSCF to the IP-SM-GW, it
looks like neither the P-CSCF nor the S-CSCF is providing the tel address in
a P-Asserted-Identity header:
MESSAGE tel:+3108012345680 SIP/2.0
Route: <sip:defaultapp@tas.core.ims1.test;lr>,
<sip:iscmark@scscf.core.ims1.test:6060;lr;s=1;h=0;d=0;a=7369703a303031303330
31323334353637383940696d732e6d6e633030332e6d63633030312e336770706e6574776f72
6b2e6f7267>
P-Served-User:
<sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;sescase=orig;regstat
e=reg
f: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>;tag=2703358633
t: <tel:+3108012345680>
CSeq: 555874977 MESSAGE
i: 2703358625_2324045032@2001:470:eb88:b021:27f:9507:589d:c201
Via: SIP/2.0/UDP
[2001:470:EB88:150:0:0:0:22]:6060;branch=z9hG4bKb857.bd3345ba81ec10b1d11639d
9c7414606.0;i=a
Via: SIP/2.0/TCP
[2001:470:EB88:150:5054:FF:FE44:BFC9];branch=z9hG4bKb857.be53cc1c583b9c5f9dc
ebf3306f2b7c1.0
v: SIP/2.0/UDP
[2001:470:eb88:b021:27f:9507:589d:c201]:8906;rport=8013;branch=z9hG4bK355262
2488
Max-Forwards: 68
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=0010300030000001
c: application/vnd.3gpp.sms
Allow: MESSAGE
d: no-fork
User-Agent: Xiaomi_Redmi 3S_Android6.0.1_9
l: 27
P-Charging-Vector: icid-value=49565300000000511100004B01000000;
icid-generated-at=2001:470:EB88:150:5054:FF:FE44:BFC9
P-Asserted-Identity: <sip:001030123456789@ims.mnc003.mcc001.3gppnetwork.org>
P-Visited-Network-ID: core.ims1.test
Message Body
GSM A-I/F RP - RP-DATA (MS to Network)
Message Type RP-DATA (MS to Network)
RP-Message Reference
RP-Message Reference: 0x05 (5)
RP-Originator Address
RP-Destination Address - (3108012345680)
RP-User Data
Length: 14
TPDU (not displayed)
GSM SMS TPDU (GSM 03.40) SMS-SUBMIT
0... .... = TP-RP: TP Reply Path parameter is not set in this SMS
SUBMIT/DELIVER
.0.. .... = TP-UDHI: The TP UD field contains only the short
message
..1. .... = TP-SRR: A status report is requested
...0 0... = TP-VPF: TP-VP field not present (0)
.... .0.. = TP-RD: Instruct SC to accept duplicates
.... ..01 = TP-MTI: SMS-SUBMIT (1)
TP-MR: 92
TP-Destination-Address - (8000)
TP-PID: 0
TP-DCS: 0
TP-User-Data-Length: (5) depends on Data-Coding-Scheme
TP-User-Data
SMS text: HELLO
Is this something that in configurable at the P-CSCF or the S-CSCF, or would
it require now development?
Thanks,
Ron
Hi, list!
I have a tricky problem, need advise from the community.
The problem I need to solve:
- have a SIP device, with a big number of BLFs configured, in some moment of
time the device is slow to handle incoming SIP messages (a lot of NOTIFYs
received), kamailio start retransmitting NOTIFYs, and the device get stuck.
My idea is to change retransmits timeout for NOTIFYs that are sent out after
handle_publish, so if get stuck, not to make "DoS" I have.
What I tried:
- t_set_retr(5000, 10000); before handle_publish => does not work
- my tm is compiled with DTM_DIFF_RT_TIMEOUT, and t_set_retr works for e.g.
INVITEs
I have read the mailing list and also studied sources of presence and tm
modules. I see that at the moment there is no way to solve what I want from
config.
My next steps are going to make some hacks in C code... at least to
understand the code better and find some new insights
Any other ideas?
Comments/ideas are highly welcomed!
cheers
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
