Hello all,
I can't seem to get either RTPProxy or RTPEngine to work correctly. I have decided to concentrate on RTPEngine because I have read that it works the best. I am using Asterisk with Kamailio in front. When I make calls, I see RTPEngine being hit but I continually get the error "Call-ID not found", calls work but media traffic doesn't go through RTPEngine. I have tried many combination of the flags but I seem to always get the same error. When I look at the tcpdump log, I see that the media offer is not on the RTPEngine port. Is there a common mis-configuration error that can cause this?
I know I can send all my logs and configurations but I really want to try and resolve this as a learning experience.
Thanks all,
-Steve
Hi Everyone,
I am trying to start kamailio 5.1.4 with two own modules. After
/etc/init.d/kamailio start , I am getting one error of the dispatcher
module and bunch of warrnings because of missed reply and failure routes.
The first error before crashing is:
ERROR: dispatcher [dispatcher.c:814]: ds_warn_fixup(): failover functions
used, but required AVP parameters are NULL -- feature disabled
Later on, when I am trying to register a user (from a soft phone) i am
getting the following:
ERROR: sl [sl_funcs.c:362]: sl_reply_error(): stateless error reply used:
I'm terribly sorry, server error occurred (1/SL)
Aug 22 10:02:52 sgw1a /sbin/kamailio[6960]: CRITICAL: <core>
[core/pass_fd.c:277]: receive_fd(): EOF on 20
Aug 22 10:02:52 sgw1a /sbin/kamailio[6935]: ALERT: <core> [main.c:746]:
handle_sigs(): child process 6942 exited by a signal 11
Aug 22 10:02:52 sgw1a /sbin/kamailio[6935]: ALERT: <core> [main.c:749]:
handle_sigs(): core was not generated
Aug 22 10:02:52 sgw1a /sbin/kamailio[6935]: INFO: <core> [main.c:771]:
handle_sigs(): terminating due to SIGCHLD
Aug 22 10:02:52 sgw1a /sbin/kamailio[6959]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6958]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6957]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6956]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6955]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6954]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6953]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6950]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6941]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6944]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6948]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6951]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6946]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6952]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6943]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6949]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6947]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6938]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6937]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6940]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6939]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a kernel: [296301.271457] kamailio[6942]: segfault at 0
ip (null) sp 00007fffb3ddf368 error 14 in kamailio[400000+442000]
Aug 22 10:02:52 sgw1a /sbin/kamailio[6945]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6960]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6936]: INFO: <core> [main.c:826]:
sig_usr(): signal 15 received
Aug 22 10:02:52 sgw1a /sbin/kamailio[6935]: ERROR: jsonrpcs
[jsonrpcs_fifo.c:594]: jsonrpc_fifo_destroy(): cannot delete the fifo
(/tmp/kamailio_jsonrpc.fifo): Operation not permitted
Aug 22 10:02:52 sgw1a /sbin/kamailio[6935]: ERROR: jsonrpcs
[jsonrpcs_sock.c:511]: jsonrpc_dgram_destroy(): cannot delete the socket
(/tmp/kamailio_rpc.sock): Operation not permitted
Aug 22 10:02:52 sgw1a /sbin/kamailio[6935]: INFO: <core>
[core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
Regarding to the first error of the dispatcher module i could not find out
which calibration i can follow with its parameters to get rid of this error.
Regarding the jasonrpcs and the last two erros, here are my configuration
in kamailio.cfg:
#/* set the path to RPC fifo control file */
modparam("jsonrpcs", "fifo_name", "/tmp/kamailio_jsonrpc.fifo")
modparam("jsonrpcs", "fifo_mode", 0755)
modparam("jsonrpcs", "fifo_group", "kamailio")
modparam("jsonrpcs", "fifo_user", "kamailio")
#/* set the path to RPC unix socket control file */
modparam("jsonrpcs", "dgram_socket", "/tmp/kamailio_rpc.sock")
modparam("jsonrpcs", "dgram_mode", 0755)
modparam("jsonrpcs", "dgram_user", "kamailio")
modparam("jsonrpcs", "dgram_group", "kamailio")
I think the root cause is even beyond the dispatcher and jsonrpcs modules
setting.
Please check the attached where you can find my complete log file after
starting Kamailio.
Best regards
Abdulaziz
Hi,
We are currently using the dispatcher module and probing end points with
OPTIONS, and making them active / inactive depending on the response:
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=3;code=404")
modparam("dispatcher", "ds_ping_from", "[REDACTED]")
modparam("dispatcher", "ds_ping_interval", 20)
modparam("dispatcher", "ds_probing_threshold", 1)
modparam("dispatcher", "ds_probing_mode", 1)
One of our suppliers endpoints doesn't respond to SIP OPTIONS, is it
possible to force a single endpoint as active, but continue probing the
rest?
I've tried various settings - both globally and flags for the individual
end point, but I couldn't seem to find the correct combination.
Thanks
Matthew
Am Montag, 20. August 2018, 20:58:43 CEST schrieb Soltanici Ilie:
> In the logs, I see these errors:
>
> ERROR: <core> [db.c:463]: db_use_table(): invalid parameter value
> Aug 20 19:56:41 kamailio[12716]: ERROR: <core> [db.c:463]: db_use_table():
> invalid parameter value Aug 20 19:56:41 kamailio[12716]: ERROR: htable
> [ht_db.c:211]: ht_db_load_table(): failed to use_table
Hi,
please keep the list in CC.
This error is related to a database issue. Please double check if there are
any issues during startup in the log. Do you see any other error there?
A similar (not 100% identical) issue was discussed recently here:
https://lists.kamailio.org/pipermail/sr-users/2018-August/102393.html
Maybe this helps you as well.
Best regards,
Henning
--
Henning Westerholt
https://skalatan.de/blog/
Good morning Daniel,
If RTPEngine is on the same server as Kamailio (Asterisk being on another server), and RTP traffic is sent to and from RTPEngine, then the provider only needs to whitelist one IP-Address. I thought with RTPEngine that all RTP traffic would go through it and then it would pass it on to the correct destination. Is this correct?
Thank you
-----Original Message-----
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Daniel Tryba
Sent: Thursday, August 23, 2018 4:36 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Struggling with RTPProxy and RTPEngine
MITRE WARNING: Do not open unexpected password-protected attachments.
>>>Email originates from a non-MITRE system. Use caution.<<<
On Wed, Aug 22, 2018 at 05:05:02PM +0000, Wilkins, Steve wrote:
> The SIP traffic is working this way for me but I still see RTP traffic going directly from Asterisk to the UAC, which means they need to whitelist asterisk IP. Am I missing something?
In what sense do they need whitelisting? In a common NATed solution where is no white/blacklist needed. UA gets RTP endpoints from SDP, starts sending packets to ip/port and the destination will send back packets to the source ip/port, the router/firewall will just send this to the actual UA. I have yet to find an UA that cares about where the RTP stream is coming from with regards to the SIP traffic.
Im very new to kamailio,
we have some ptime issues which causes one way audio due to varies PBX
vendors connecting to our class 5 softswitches
I would like to use Kamailio as the SIP/RTP proxy in front of our class 5
soft switches
I followed the example of freeswitch and kamailio. However the config is
still hard for me
below setup works, however RTP not being proxied, Looks like its its not,
because im not using NAT, so RTP goes direct
https://freeswitch.org/confluence/display/FREESWITCH/Kamailio+basic+setup+a…
I would like to to ensure RTP proxy is always used(possible re-framing
ptime) and we have multiple soft switches
Is it possible to setup kamailio.cfg so my customers can point the endpoint
to kamailio and domain names contains the server we want to use to register
with?
eg, softswitch 1 = 1.1.1.2
softswitch 2 = 1.1.1.3
softswitch 3 = 1.1.1.4
etc etc
my current config
#!KAMAILIO
#!define IPADDRESS "1.1.1.1"
#!define SWITCH_IPADDRESS "1.1.1.2"
#!define FLAG_FROM_SWITCH 1
#!define FLAG_FROM_USER 2
# ------------------ module loading ----------------------------------
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "sl.so"
loadmodule "maxfwd.so"
loadmodule "nathelper.so"
loadmodule "textops.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "path.so"
loadmodule "rtpproxy.so"
# ----------------- setting module-specific parameters ---------------
modparam("nathelper|registrar", "received_avp", "$avp(s:rcv)")
# ------------------------- request routing logic -------------------
#!ifdef WITH_NAT
# ----- rtpproxy params -----
modparam("rtpproxy", "rtpproxy_sock", "udp:127.0.0.1:7722")
# ----- nathelper params -----
modparam("nathelper", "natping_interval", 30)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_bflag", FLB_NATSIPPING)
modparam("nathelper", "sipping_from", "sip:pinger@kamailio.org")
# params needed for NAT traversal in other modules
modparam("nathelper|registrar", "received_avp", "$avp(RECEIVED)")
modparam("usrloc", "nat_bflag", FLB_NATB)
#!endif
# main routing logic
route {
# per request initial checks
route(SANITY_CHECK);
# CANCEL processing
if (is_method("CANCEL")) {
if (t_check_trans()) {
t_relay();
}
exit;
}
route(CHECK_SOURCE_IP);
##################################
### HANDLE SEQUENTIAL REQUESTS ###
route(WITHINDLG);
###############################
### HANDLE INITIAL REQUESTS ###
t_check_trans();
if (is_method("INVITE|REFER")) {
record_route();
}
if (is_method("REGISTER")) {
add_path();
}
if (isflagset(FLAG_FROM_SWITCH)) {
# don't send INVITE from SWITCH back to SWITCH, set reply
route to handle NAT and forward them along
t_on_reply("EXTERNAL_REPLY");
} else {
# set destination to your SWITCH
$du = "sip:1.1.1.2:5060";
}
route(RELAY);
}
route[SANITY_CHECK]
{
if (!sanity_check()) {
#xlog("L_WARN", "$ci|end|message is insane");
exit;
}
if (!mf_process_maxfwd_header("10")) {
#xlog("L_WARN", "$ci|end|too much hops, not enough barley");
send_reply("483", "Too Many Hops");
exit;
}
if ($ua == "friendly-scanner" ||
$ua == "sundayddr" ||
$ua =~ "sipcli" ) {
#xlog("L_WARN", "$ci|end|dropping message with user-agent
$ua");
exit;
}
if ($si == IPADDRESS) {
#xlog("L_WARN", "$ci|end|dropping message");
exit;
}
}
route[CHECK_SOURCE_IP]
{
if ($si == SWITCH_IPADDRESS) {
setflag(FLAG_FROM_SWITCH);
} else {
setflag(FLAG_FROM_USER);
}
}
# Handle requests within SIP dialogs
route[WITHINDLG]
{
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
route(RELAY);
} else {
if (is_method("NOTIFY")) {
route(RELAY);
}
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe requests
exit;
}
if (is_method("ACK")) {
if (t_check_trans()) {
# no 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
#xlog("ACK without matching
transaction ... ignore and discard");
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
}
onreply_route[EXTERNAL_REPLY]
{
route(NAT_TEST_AND_CORRECT);
}
route[NAT_TEST_AND_CORRECT]
{
if (nat_uac_test("3")) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
fix_nated_contact();
}
force_rport();
}
if (has_body("application/sdp") && nat_uac_test("8")) {
fix_nated_sdp("10");
}
}
route[RELAY]
{
#!ifdef WITH_NAT
if (check_route_param("nat=yes")) {
#setbflag(FLB_NATB);
route(RTPPROXY);
}
if (isflagset(FLT_NATS) || isbflagset(FLB_NATB)) {
route(RTPPROXY);
}
#!endif
route(RTPPROXY);
/* example how to enable some additional event routes */
if (is_method("INVITE")) {
#t_on_branch("BRANCH_ONE");
t_on_reply("REPLY_ONE");
t_on_failure("FAIL_ONE");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
# if (!t_relay()) {
# sl_reply_error();
# }
# exit;
}
# RTPProxy control
route[RTPPROXY] {
#!ifdef WITH_NAT
if (is_method("BYE")) {
#unforce_rtp_proxy();
force_rtp_proxy();
} else if (is_method("INVITE")){
force_rtp_proxy();
}
if (!has_totag()) add_rr_param(";nat=yes");
#!endif
return;
}
Hello all,
I am still trying to get RTPEngine to work. At this point, when I make a call, I do see the offer in the rtpengine log, I also see the update of the SDP (c) changing it to 20.20.20.20. However, after that, there are no logs other than a bunch of "timer run time = 0.nnnnnnn sec", and the delete when I hang up the call. There is no RTP traffic what so ever in the rtpengine log (however, the call is completely successful, other than the RTP traffic not going through RTPEngine).
Here is a breakdown of my configs (I borrowed this format from Maxim Fedorov because I thought it was very concise)
Starting rtpengine =>
rtpengine --interface=internal/21.21.21.21--interface=external/21.21.21.21\!20.20.20.20 --listen-ng=127.0.0.1:12221 --dtls-passive -f -m 10000 -M 20000 -E -L 7 --log-facility=local1
RTPEngine Public IP: 20.20.20.20
RTPEngine Private IP: 21.21.21.21
kamailio.cfg
modparam("rtpengine", "rtpengine_sock", "udp:127.0.0.1:12221")
listen=tcp: 21.21.21.21:5060 advertise 20.20.20.20:5060
listen=udp: 21.21.21.21:5060 advertise 20.20.20.20:5060
rtpengine_manage call
rtpengine_manage("trust-address replace-origin replace-session-connection external external media-address=20.20.20.20"); (I have placed this rtpengine_manage call at the beginning of all routes).
I have tried many variations of rtpengine_manage parameters, and placement of the call itself, but I never see RTP traffic in the rtpengine log.
Thank you to all who have looked at this,
-Steve
Hello,
How can i clear this error ?
Aug 22 13:05:56 proxy1 kamailio: ERROR: <core> [core/pvapi.c:228]: pv_table_add(): pvar [rtpstat] already exists
Aug 22 13:05:56 proxy1 kamailio: ERROR: <core> [core/pvapi.c:513]: register_pvars_mod(): failed to register pseudo-variable <rtpstat> for module rtpproxy
Hello,
with the summer holidays in the northern hemisphere approaching the end,
I am considering to release v5.1.5 out of Kamailio git branch 5.1 --
there were several fixes done since 5.1.4 and it is time to package
another minor release.
The propose date is next week on Wednesday, August 22, or slightly after
in case there are unexpected events delays it.
Should there be any issues you are aware of and not yet reported on the
bug tracker, do it asap in order to have a chance to be fixed:
- https://github.com/kamailio/kamailio/issues
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
