Hello,
I followed the documentation from http://kamailio.org/docs/modules/4.2.x/modules/debugger.html#idp84752. I have the global debug flag at 9.
modparam("debugger", "cfgtrace", 1)
modparam("debugger", "mod_level_mode", 1)
modparam("debugger", "mod_level", "core=3")
My Kamailio complains with a parsing error of some sort and fails to start. - "dbg_mod_level_param(): cannot store parameter: core=3"
My intention is to turn off/reduce the "core" module tracing while keeping the "script" module at debug. Any suggestions ? I am running version 4.1.4.
thanks
Sharath
We experience strange networking issue, not exactly specific to
kamailio, but still related to it.
Rtpengine's "ng" interface uses UDP. Protocol messages contains SDP,
and for encrypted video call those messages exceed 1500 bytes.
Everything works fine within localhost, but when rtpengine and
Kamailio are on different hosts, and when hosts are Amazon-hosted, we
have trouble.
This is experienced with l3.large, t2.micro with Ubuntu 14. I believe
we don't have any special settings over system defaults.
We send a large datagram from remote host, e.g. with such trivial app in python:
import socket
UDP_IP = "123.123.123.123" # remote host IP
UDP_PORT = 33333
MESSAGE = """
.....0010......0020......0030......0040......0050......0060......0070......0080......0090......0100
.....0110......0120......0130......0140......0150......0160......0170......0180......0190......0200
.....0210......0220......0230......0240......0250......0260......0270......0280......0290......0300
.....0310......0320......0330......0340......0350......0360......0370......0380......0390......0400
.....0410......0420......0430......0440......0450......0460......0470......0480......0490......0500
.....0510......0520......0530......0540......0550......0560......0570......0580......0590......0600
.....0610......0620......0630......0640......0650......0660......0670......0680......0690......0700
.....0710......0720......0730......0740......0750......0760......0770......0780......0790......0800
.....0810......0820......0830......0840......0850......0860......0870......0880......0890......0900
.....0910......0920......0930......0940......0950......0960......0970......0980......0990......1000
.....1010......1020......1030......1040......1050......1060......1070......1080......1090......1100
.....1110......1120......1130......1140......1150......1160......1170......1180......1190......1200
.....1210......1220......1230......1240......1250......1260......1270......1280......1290......1300
.....1310......1320......1330......1340......1350......1360......1370......1380......1390......1400
.....1410......1420......1430......1440......1450......1460......1470......1480......1490......1500
.....1510......1520......1530......1540......1550......1560......1570......1580......1590......1600
.....1610......1620......1630......1640......1650......1660......1670......1680......1690......1700
.....1710......1720......1730......1740......1750......1760......1770......1780......1790......1800
.....1810......1820......1830......1840......1850......1860......1870......1880......1890......1900
.....1910......1920......1930......1940......1950......1960......1970......1980......1990......2000"""
print "UDP target IP:", UDP_IP
print "UDP target port:", UDP_PORT
print "message:", MESSAGE
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.sendto(MESSAGE, (UDP_IP, UDP_PORT))
Then we listen on that port with such trivial python app:
import socket
UDP_IP = "172.31.4.102" # local ip
UDP_PORT = 33333
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((UDP_IP, UDP_PORT))
while True:
data, addr = sock.recvfrom(0x10000)
print "received message:", data
Meanwhile, we monitor the traffic with e.g. ngrep:
ngrep -t -e -d any -W byline -O large_udp.pcap port 33333 or
'(ip[6:2]' '&' '0x1fff)' '!=' '0'
(the part after "or" catches segments of segmented packets)
About the host:
# uname -a
Linux hostname 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15
17:43:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Also linux-image-3.13.0-36-generic and linux-image-3.13.0-45-generic
behave in same way.
What we see:
- ngrep shows the packets with correct contents. All segments are delivered.
- application doesn't get any data at all
Rarely dmesg shows such messages:
[ 102.161679] UDP: bad checksum. From 123.123.123.124:56439 to
172.31.4.102:33333 ulen 2008
but it is logged really rarely, so this is surely not what happens on
every packet transmission.
This test works fine on e.g. cheapest DigitalOcean VPS.
I am concerned with this issue because rtpengine software has UDP
interface. So on Amazon hosts this interface works only within
localhost, and I cannot distribute software to different nodes.
Any thoughts? What's wrong, how to fix?
--
Andrey Utkin
I made a test configuration for trying the pua_regEvent module.
There were two things I want to ask about.
First - when the SUBSCRIBE to event 'reg' following a UEs registration to the Kamailio is responded with a NOTIFY - there was no body in the NOTIFY. I expected a XML body with registration status.
Second - When the UE re-registers to Kamailio - I expected a NOTIFY to be send on the existing 'reg' subscription, but nothing happened.
Or am I missing some configuration ?
Here's some of the conf script:
####### Modules Section ########
loadmodule "db_mysql.so"
loadmodule "mi_fifo.so"
loadmodule "kex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "mi_rpc.so"
loadmodule "xcap_client.so"
loadmodule "pua.so"
loadmodule "pua_reginfo.so"
loadmodule "presence.so"
loadmodule "presence_reginfo.so"
loadmodule "presence_xml.so"
# ----------------- setting module-specific parameters ---------------
#!define DBURL "mysql://kamailio:kamailiorw@localhost/kamailio"
# ----- xlog params -----
modparam("xlog", "prefix", "-xlog: ")
# ----- mi_fifo params -----
modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo")
# ----- tm params -----
# auto-discard branches from previous serial forking leg
modparam("tm", "failure_reply_mode", 3)
# default retransmission timeout: 30sec
modparam("tm", "fr_timer", 30000)
# default invite retransmission timeout after 1xx: 120sec
modparam("tm", "fr_inv_timer", 120000)
# ----- rr params -----
# add value to ;lr param to cope with most of the UAs
modparam("rr", "enable_full_lr", 1)
# do not append from tag to the RR (no need for this script)
modparam("rr", "append_fromtag", 0)
# ----- registrar params -----
modparam("registrar", "method_filtering", 1)
modparam("registrar", "max_expires", 86400)
# ----- pua_reginfo params -----
modparam("pua_reginfo", "default_domain", "system.test")
modparam("pua_reginfo", "server_address", "sip:reginfo@10.171.0.4")
modparam("pua_reginfo", "publish_reginfo", 0)
modparam("pua_reginfo", "default_domain", "system.test")
# ----- presence_xml params -----
modparam("presence_xml", "integrated_xcap_server", 1)
# ----- presence params -----
modparam("presence", "db_url", DBURL)
Hi,
I am trying to use dlg_refer. I set the side to refer and the final
destination.
But, the contact header of the refer stays "controler(a)kamailio.org". So,
the refer fails.
Is it a bug or should i change the contact header by myself before doing
the dlg_refer?
same with the dlg_bridge.....
Cheers,
Uri
Hi all,
I think the lack of response to my previous thread is probably because it was too complicated. I have now narrowed my problem down after further archive readings .
I am trying to use the dialog_ng module along with the ims_charging_module. Upon reception of an INVITE, a call to the Ro_CCR() from the request_route script is made. That function does a check that the dialog record exists (binds to dialog module and does a "get_dlg(msg)" call) - this fails i.e. dialog is not found.
Running kamailio 4.2.2 and relevant sections of kamailio.cfg are:
modparam("dialog_ng", "dlg_flag", FLT_DIALOG)
modparam("dialog_ng", "timeout_avp", "$avp(DLG_TIMEOUT_AVP)")
modparam("dialog_ng", "detect_spirals", 1)
modparam("dialog_ng", "profiles_no_value", "orig ; term")
request_route {
# NAT detection
route(NATDETECT);
# Set DLG flag to track dialogs using dialog2
if (!is_method("REGISTER|SUBSCRIBE"))
setflag(FLT_DIALOG);
# handle requests within SIP dialogs
route(WITHINDLG);
### only initial requests (no To tag)
# CANCEL processing
if (is_method("CANCEL"))
{
if (t_check_trans())
t_relay();
exit;
}
t_check_trans();
if (is_method("INVITE"))
{
set_dlg_profile("orig");
Ro_CCR("CHARGING_CCR_REPLY", "orig", "SCUR", "", "30","CCR_location");
}
So my question is, "should the above logic create a dialog record on the initial INVITE?" and if yes then "what possible reasons might there be for the Ro_CCR() function not be able to detect it exists?"
Cheers
Shane Harrison
How does Kamailio load balance traffic to rtpengine? Is it load based,
round robin, etc? The module makes mention of this but I don't see how it
works. Also, it talks about weighting the proxies. How is that
accomplished?
Thanks,
Marc
Hello gents,
I was trying my hands on getting a successful RTCweb call (JSsip, since
Peter Dunkley mentioned that he's been using JSsip for most of the testing
scenarios..) to PSTN, making my kamailio as proxy + protocol converter (sip
over web-sockets to sip over udp).
And yes, I've referred Carlos' config; the main problem is I get 'Bad Media
Description' error in Google Chromium (Version 40.0.2214.111 m) & my SIP
server even sends 200 OK, but my phone doesn't ring. To make it worse, I
can see rtpengine throwing this error -
"SRTCP output wanted, but no crypto suite was negotiated"
BTW, I have -
[root@localhost log]# openssl version
OpenSSL 1.0.1j 15 Oct 2014
I even tried building kamailio & rtpengine using this openssl but in-vain.
One thing that baffles me is that, apparently kamailio has started
receiving RTP packets (perhaps early media) but the mobile phone hasn't
ringed :-(
I am attaching all possible logs & seek some guidance from the array of
experts in this list.
Files attached:
a) tcpdump on ext. interface
b) tcpdump on loopback
c) syslogs
d) Chromium JS logs
UAC (14.98.55.38), Kamailio (125.99.186.126), SIP Server (157.238.178.153),
Media Server (199.27.244.6)
--
Warm Regds.
MathuRahul
>* Is the SIP signaling still going fine via websocket? Do you get callee
*>* ringing?
*>>* Cheers,
*>* Daniel*
Hello Daniel
Actually SIP signalling goes perfect, and i can see in RTP asterisk
log that RTP packets are being sent, so I suppose there is something
stuck somewhere in RTP maybe related with RTP Engine
>Hi,
>
>If you are using rtpengine for the rtp you might have to upgrade to a
>newer version.
>
>On my system crypto negotiation in rtpengine started failing after a
>openssl update in January. Recompiling a newer version from git fixed that.
>
>regards
>
>M
I updated to latest version through git but still stuck there. Now I
can see that the config file (ngcp-rtpengine in etc default) has
changed so I'm not sure how should this impact (not ADDRESS neither
ADV ADDRESS now I see an Interfaces parameter)
I also find for some reason very possible that somehow rtp traffic is
not getting through. ICE candidates are being negotiated, so I feel
that the route is clear, so maybe there might be some crypto issues as
you point out, but update has not been enough :(
Any other ideas?
*Manuel Camargo*
Teléfono: 638000836
eMail: sir.louen(a)gmail.com
<https://twitter.com/SirLouen>
[image: Ver el perfil de Manuel Camargo Lominchar en LinkedIn]
<http://es.linkedin.com/in/louen>
