Hi people,
Someone know tell me if in the kamailio the bind_dbmod() function doesn't
exist anymore? If doesn't, exist other similar function?
Cherrs,
Bruno
Currently i have a setup kamailio/asterisk. Is this possible in opensips to
pass standard asterisk feature codes to asterisk from openips so the users
of asterisk can use of message center, call forwarding, call transfer, 3
way calling, return call, and other standard calling features available at
the dial prompt.
(1) Opensips ALL ENPOINTS REGISTER WITH OPENSIPS
(2) Asterisk Media Server
For now i can register and make calls but have no features at the dial
prompt. i want to use the features below of asterisk.
- 69 - Last Number Called
- 70 - Activate Call Waiting
- 71 - Deactivate Call Waiting
- 72 - Call Forwarding
- 73 - Deactivate Call Forwarding
- 78 - Enable Do not disturb
- 79 - Disable Do not disturb
- 90 - Call Forward Busy
- 91 - Disable call forward busy
- 97 - Message Center
- 98 - Enter Message Center
Please help me if there is any possibility.
Any help will highly appreciated.
--
Toqeer Ali Syed
Red Hat Certified Engineer
mob: +92 321 9059916
Hi
I need to trust a subnet and was wondering if something like
src_ip = x.x.x.x/27
where x.x.x.x is the network address of the subnet
is valid in the config.
I am using OpenSER 1.1.0 in this instance.
--
Jon Farmer
Tel: 07795 118140
Email: viperdudeuk(a)gmail.com
Twitter: @viperdudeuk
How to insert modules in kamailio?
Hi people, I worked with ser but now I'm migrating to kamailio... I'd like
to know how to insert a ser module in the kamailio? Example: In the ser
modules exist the route module and I want to use it in the kamailio. It's
possible?
Cheers,
Bruno
"kamailio" <users(a)lists.kamailio.org>,
Hi
I am sorry to ask again about this topic but I don't understand yet how the
TCP keep-alive are sent.
With Kamailio 3.0.1 and the following configuration:
tcp_keepalive=yes
tcp_keepidle=10
tcp_connection_lifetime=3600
The TCP connection is kept alive and TCP Keep-Alive packets are sent when
the TCP connection is idle.
But I don't understand why the time between KA is not linear:
first KA is sent 10 seconds after last last TCP message. This is logical and
connected with the tcp_keepidle=10 configuration.
then 2nd KA is sent 75 seconds after first KA
Then my client sends some traffic and 23 seconds after last message, a new
KA is sent. Another time it was 54 seconds. etc. etc.
Could you explain me where do come from these values of 75 seconds, 23, 54 ?
Everything works well: my client behind NAT is kept connected but I'd like
to understand why it does work :-)
Thanks in advance,
Pascal
Why is it an UNIQUE key? It makes things complex when I want to create
another gateway with same IP and port (but belonging to a different
grp_id). I still want to name it with the same name (an internal
domain for example).
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Hi, i have a problem about the handling of the "cancel" message.
The call flow is this:
A -----------------> (Invite) Proxy (P)
B
(100 Tryng) <---------------------------
----------------->(Invite) B
(100 Tryng) <---------------------------
(183 Progress) <---------------------------
(183 Progress) <---------------------------
(200 OK) <---------------------------
(200 OK) <---------------------------
--------------------------------->(CANCEL)
(200 canceling) <---------------------------
(200 OK) <---------------------------
(200 OK) <---------------------------
----------------->(ACK)
----------------->(ACK)
(BYE) <---------------------------
(BYE) <---------------------------
----------------->(481 Call Leg/Transaction Does Not Exist)
----------------->(481 Call Leg/Transaction Does Not Exist)
The B side answer with OK, after a while , a send a CANCEL. I don't know why
Kamailio don't forward this message to the B side.
B retry to send the OK message, then A send the ACK.
At the end , B send BYE , but A don't have the transactin.
In this situation, kamailio should deliver the "CANCEL" to the B side ?
(even if, before B send the OK )
Or the proxy should not consider the CANCEL because B has answered with
"OK" ?
Where is the error on my configuration ?
Thanks
I have Kamailio 1.5.3 and my configuration is this:
modparam("siptrace", "trace_on", 0)
modparam("carrierroute", "config_source", "db")
modparam("auth_db", "password_column", "ha1")
modparam("auth_db", "use_domain", 1)
modparam("usrloc", "db_mode", 2)
#modparam("usrloc","nat_bflag", 8)
modparam("permissions", "trusted_table", "trusted")
modparam("permissions", "db_mode", 1)
modparam("permissions", "peer_tag_avp", "$avp(i:707)")
modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")
modparam("avpops","avp_table","usr_preferences")
modparam("avpops","attribute_column","attribute")
modparam("avpops","value_column","value")
modparam("uac","from_restore_mode","auto")
modparam("tm", "fr_timer", 12)
modparam("tm", "wt_timer", 32)
modparam("rr", "append_fromtag", 1)
#modparam("rr", "enable_full_lr", 1)
modparam("userblacklist", "use_domain", 0)
#modparam("dialog", "dlg_flag", 2)
modparam("registrar|nathelper", "received_avp", "$avp(i:42)")
#modparam("registrar", "min_expires", 17000)
modparam("acc", "db_flag", 2)
modparam("acc", "db_missed_flag", 3)
modparam("acc", "db_table_acc", "acc")
modparam("acc", "db_table_missed_calls", "missed_calls")
modparam("acc", "detect_direction", 1)
route{
# -----------------------------------------------------------------
# Sanity Check Section
# -----------------------------------------------------------------
if (!mf_process_maxfwd_header("10"))
{
sl_send_reply("483", "Too Many Hops");
exit;
};
if (msg:len > max_len)
{
sl_send_reply("513", "Message Overflow");
exit;
};
# -----------------------------------------------------------------
# Preprocessing
# -----------------------------------------------------------------
if (!method=="REGISTER") record_route();
# -----------------------------------------------------------------
# NAT Detection
# -----------------------------------------------------------------
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
}
setflag(7);
}
# -----------------------------------------------------------------
#
# -----------------------------------------------------------------
sip_trace();
##Loose_route packets
if (has_totag()) {
if (loose_route()) {
if(method=="BYE") {
#Account BYE
transactions
setflag(2);
};
route(2);
} else {
if ( is_method("ACK") ) {
if ( t_check_trans() ) {
# non
loose-route, but stateful ACK;
# must be an ACK
after a 487 or e.g. 404 from upstream server
t_relay();
exit;
} else {
# ACK without matching
transaction ... ignore and discard.\n");
exit;
}
}
sl_send_reply("404","Not
here");
}
exit;
}
# -----------------------------------------------------------------
# CANCEL processing
# -----------------------------------------------------------------
if (is_method("CANCEL")) {
if (t_check_trans()) t_relay();
exit;
};
t_check_trans();
# -----------------------------------------------------------------
#
# -----------------------------------------------------------------
if (method =="OPTIONS" || method=="SUBSCRIBE") {exit;};
if (method =="REGISTER") {route(3);};
route(1);
}
route[2]
{
t_on_reply("1");
if (!t_relay()) {
sl_reply_error();
};
exit;
}
..
failure_route[2] {
if (t_was_cancelled()) {
# xlog("INFO:cancelled transaction--\n");
exit;
}
revert_uri();
..
t_on_failure("2");
append_branch();
if (!t_relay()) {
exit;
};
}
There is a peculiar and confusing aspect to the documented
significance of the "realm" argument to www_authorize(), and
presumably proxy_authorize() as well.
The documentation says that if this value is empty, the digest realm
will be generated from the domain part of the To or From URI,
whichever is applicable to the given situation (REGISTER vs. any other
request). This is the way *_authorize() is invoked in most cases, and
works fine.
However, we recently ran into a situation where www_authorize() would
always fail and claim that it could not find the user in 'subscriber'
despite being provided correct username and domain, with the
appropriate options -- return value -1. We were sending the public
host IP as the domain of the To URI, using it as the realm, and
setting it in the domain column of the 'subscriber' table. The
problem was, the public IP of the host was not in /etc/hosts --
/etc/hosts consisted solely of:
127.0.0.1 localhost.localdomain localhost
For some reason, it wasn't until I added the public IP into it that
www_authorize() started working properly:
127.0.0.1 localhost.localdomain
xxx.xxx.xxx.xxx public_host.domain.tld public_host
I don't see anything different in the anatomy of the 401 Unauthorized
challenges; the realm is still xxx.xxx.xxx.xxx in both cases. It
just seems that unless Kamailio detects a DNS reverse alias for the
domain, it won't properly authenticate requests.
This aspect of the behaviour is not documented, and I am also confused
as to why it happens this way. Any clarification would be appreciated.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Hi all
I have experienced segfaults when using avp_copy in Kamailio 3.01. This happens
when using the "g" flag and the avp is not null (no problem if it has no
content)
avp_copy("$avp(s:block_out_list)", "$avp(s:caller_block_out_list)/gd");
Removing the "g" flags works ok (but does not copy all the content of course):
avp_copy("$avp(s:block_out_list)", "$avp(s:caller_block_out_list)/d");
Directly copying the avp works fine:
$avp(s:caller_block_out_list) = $avp(s:block_out_list);
Logs:
kernel: [1503237.523015] kamailio[8156]: segfault at 1008eb91c ip 505344 sp
7fffffffad10 error 4 in kamailio[400000+1c9000]
WARNING: <core> [usr_avp.c:483]:AVP specified with index, but not used for search
ALERT: <core> [main.c:722]: child process 8156 exited by a signal 11
ALERT: <core> [main.c:725]: core was not generated
INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD
INFO: <core> [main.c:788]: INFO: signal 15 received
