Is it normal for Kamailio to segfault on a duplicate key in the usrloc DB?
Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: db_mysql
[km_dbase.c:122]: db_mysql_submit_query(): driver error on query: Duplicate
entry 'uloc-557a96c1-3577-4e5f1' for key 'ruid_idx'
Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: <core>
[db_query.c:337]: db_do_update(): error while submitting query
Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: usrloc
[ucontact.c:800]: db_update_ucontact_addr(): updating database failed
Jun 15 18:15:23 vproxy2 /usr/sbin/kamailio[13646]: ERROR: usrloc
[urecord.c:368]: wb_timer(): updating contact in db failed (aor:
sip305_isibmp)
I believe that there should never be a duplicate key. I'm not sure how
that's happening either. I have 3 Kamailio boxes in a cluster replicating
registrations to each other and using a MySQL Galara cluster for the usrloc
DB. This is Kamailio 4.0.6.
Thanks,
Marc
We are using Kamailio 4.2.5 as a registrar and proxy between many dispersed
end-users of a soft phone app and our calling platform / switch.
Until now we have used udp exclusively but are trying to introduce tcp
between end-users and Kamailio, leaving udp between Kam and our
switch...while maintaining the ability for some end-users to use udp to Kam.
With some simple address checks I am able to always send to our switch over
udp. If all end-users used tcp I could send everything else tcp, but I need
to maintain udp support.
The specific problem I am having is on a reINVITE such as this one from our
platform to the a-leg:
INVITE sip:xxxxxx@xxxxxxxxxxxxx:42679;user=phone SIP/2.0
Via: SIP/2.0/UDP
xxxxxxxxxxxxx:5060;branch=z9hG4bK218cc8e12ll5035f67INV6a67885312aad
Max-Forwards: 35
Route: <sip:xxxxxxxxxxx;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes>
Route:
<sip:xxxxxxxxxxx:5070;transport=tcp;lr;r2=on;ftag=daba971c;did=b57.4872;nat=yes>
Contact: <sip:xxxxxxxxxx@xxxxxxxxxxxxx:5060>
To: "xxxxxx"<sip:xxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx:5070>;tag=daba971c
From: <sip:xxxxxxxxxx@xxxxxxxxxxxxxxxxxxxxxxxxxxx
:5070>;tag=6a678853-co76461-INS002
Call-ID: MDI4ZmFjNmZhN2Y1NWE2ZTViNTkyZGUwNWE2YzUzYmU
CSeq: 7646101 INVITE
Allow:
INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,INFO,UPDATE
Content-Type: application/sdp
Date: Mon, 15 Jun 2015 20:10:18 GMT
User-Agent: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Length: 262
As you might notice, we have rr:enable_double_rr set:
*There are some situations when the server needs to insert two Record-Route
header fields instead of one. For example when using two disconnected
networks or doing cross-protocol forwarding from UDP->TCP. This parameter
enables inserting of 2 Record-Routes. The server will later remove both of
them. *
and I believe it is necessary to keep this way. Without it Kamailio doesn't
even see the reINVITE...the switch probably tries tcp and that's not setup
between the two.
The invite above is sent to the a-leg over udp but I would expect and need
it to be tcp in this case. The reINVITE is part of an existing dialog. We
call loose_route() followed by some simple bflag setting and flag checking,
t_on_reply(), ... then t_relay().
I do have a functional workaround but would prefer to avoid such manual
handling by utilizing built-in functionality properly.
#
# relay the message
#
if(route(TEST_TOGW)) {
if (!t_relay_to_udp()) {
sl_reply_error();
}
}
else {
if ($(hdr(Route)[-1]) =~ "tcp") {
if(!t_relay_to_tcp()) {
sl_reply_error();
}
}
else if (!t_relay()) {
sl_reply_error();
}
}
I'm not 100% sure how reliable or fast this will be, but it does work so
far in my simple tests.
Is loose_route supposed to see and use the transport=tcp but isn't for some
reason? It seems like the right thing to do to me. If not, is there
anything else I can/should be doing in the tm and/or rr modules to make
Kamailio realize it needs to send this message over TCP? If not in those
two modules is there some recommended way perhaps via registrar or usrloc
etc. to make Kamailio remember/store when a user is connected via TCP and
be able to do a quick lookup before sending to them? Anything else I'm
missing or not thinking of?
Please let me know if I can further explain and rest assured any assistance
will be much appreciated!!!
Hi,
(Kamailio 4.2.3)
Working to get dialogs closed and cleaned up nicely I'm looking into the
ka_interval and ka_timer parameter of the dialog module. The following
is now happening.
Scenario:
1. Call gets setup
2. Callee's internet connection drops
3. Call gets terminated (nicely) due to ka_timer/ka_interval
4. Log fills with "freeing a free fragment" after about 10 seconds
Digging into this I saw that the dialog is being closed and cleaned
properly in step 3. But it fails to remove/clean the timers used for the
keep-alive. That's what triggers step 4, which in turn tries to clean
the (or some of the) dialog space again. Is this expected behaviour when
using the keep-alive options, or am I running into somekind of (known) bug?
Thanks in advance for any help.
--
Cheers,
Dirk Teurlings
Hi,
I'm creating a configuration is for a SIP <> HTTP gateway (performing protocol conversion) and thus all SIP messages and responses needs to be generated from the kamailio config file.
I'm failing to create the case where the calling user abandons the session, and thus, following the reception of a CANCEL a 200 "OK" needs to be sent to this transaction and later the 487 "Request Terminated" to the SIP INVITE original session.
On the traces I see:
SIP INVITE (Cseq 1 INVITE) -->
100 Trying (Cseq 1 INVITE) <--
180 Ringing (Cseq 1 INVITE) <--
SIP CANCEL (Cseq 1 CANCEL) -->
200 Ok (CSeq 1 CANCEL) <--
487 Request Terminated (CSeq 1 CANCEL)
Have then tried several options, trying to force the CSeq 1 INVITE but without success.
t_reply_callid("$ci", "$cs", "487", " Request Terminated ");
t_reply_callid("$ci", "$rm", "487", "Request Terminated");
t_reply_callid("$ci", "1", "487", "Request Terminated");
For instance, for the last I get the following log.
6(60226) exec: *** cfgtrace:request_route=[REQINIT] c=[/etc/kamailio/kamailio.cfg] l=705 a=28 n=t_reply_callid
6(60226) DEBUG: tm [t_lookup.c:1715]: t_lookup_callid(): created comparable call_id header field: >Call-ID: 76589ZTJmNTAwZDhlOTZiM2I3MjhhYzllNjgyOWVjZGZmMzk
<
6(60226) DEBUG: tm [t_lookup.c:1719]: t_lookup_callid(): created comparable cseq header field: >CSeq: 1 INVITE<
6(60226) DEBUG: tm [t_lookup.c:1722]: t_lookup_callid(): just locked hash index 18668, looking for transactions there:
6(60226) DEBUG: tm [t_lookup.c:1749]: t_lookup_callid(): DEBUG: t_lookup_callid: transaction not found.
6(60226) DEBUG: tmx [tmx_mod.c:500]: t_reply_callid(): Lookup failed - no transaction
Could you assist here?
Thanks,
Joao
Joao Alves
Solution Architect, Unified Communications
+351 214094660 (desk)
+351 912783702 (mobile)
AMDOCS | EMBRACE CHALLENGE EXPERIENCE SUCCESS
This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp
Maybe it may be an offtopic, but I'm not really into legal issues - so I'm
sorry if this message is not fully related to this mailing list.
Can I use Kamailio to provide VoIP backend for kind of CRM system in case
of SaaS?
---
Alexandru Covalschi
ABRISS-Solutions
VoIP engineer and system administrator
phone: +37367398493
web: http://abs-telecom.com/
Henry Fernandes writes:
> But we didn¹t want to add hundreds of thousands or millions of extra rules
> just to deal with this problem. We didn¹t consider that a good
> workaround.
OK, I got it. Now priorities choose from equally long prefixes instead
of all matching prefixes. I'll take a look at the code to check if the
latter could be easily added as an option.
-- Juha
Henry Fernandes writes:
> Let’s say you have the following info in your LCR.
>
> Prefix, Carrier/Route, Rate
> 1306, A, 1.5
> 1306343, A, 1.7
> 1306, B, 1.4
>
> If you have phone number 13063431111, the LCR module matches it to the
> longest prefix (1306343) and routes the call to Carrier A. However, that
> is incorrect. It should match it to Carrier B which is the cheapest.
> Carrier B has provided a rate of 1.4 for all calls with prefix 1306.
why can't you add rule
1306343, B, 1.4
to solve the problem?
-- juha
Hello,
I'm testing LCR module in Kamailio and everything works as expected so far.
Before going further , I just want to ask about how much rule in LCR_rule
table and target in LCR_rule_target can Kamailio support .
We are dealing with hundreds of millions of rules and targets.
Kindly advise if Kamailio can support this number of rules.
Thanks
Ali
Hi,
If I have an RURI like this:
INVITE sip:4045551212;param=xyz@domain:port SIP/2.0
which transformations can I best string together in order to remove the
';param=xyz' bit and extract just the core user part value (4045551212)?
{uri.user} returns '4045551212;param=xyz'. There are numerous
transformations to help one access the parameters. What if I want to
exclude the parameters?
I've already scoured the available transformations, just hoping a second
pair of eyes can tell me I've missed something useful.
Cheers,
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
