Hi,
I am using dialog time_avp() parameter to limit the call duration to a
configured number of seconds but unfortunately when the number is
reached, i get a warning but the call is not torn down. Here is the
output from the log file
3(3711) DEBUG: <script>: return value = 30 -----> $avp(i:10)
5(3713) WARNING: dialog [dlg_handlers.c:1426]: dlg_ontimeout(): timeout
for dlg with CallID '1-3743(a)192.168.1.100' and tags '37431' '37401'
5(3713) DEBUG: dialog [dlg_hash.c:832]: dlg_unref(): unref dlg
0x7f32ee941140 with 2 -> 0
5(3713) DEBUG: dialog [dlg_hash.c:832]: dlg_unref(): ref <=0 for dialog
0x7f32ee941140
5(3713) DEBUG: dialog [dlg_hash.c:320]: destroy_dlg(): destroying dialog
0x7f32ee941140 (ref 0)
5(3713) DEBUG: dialog [dlg_hash.c:336]: destroy_dlg(): removed timer for
dlg 0x7f32ee941140 [773:2813] with clid '1-3743(a)192.168.1.100' and tags
'37431' '37401'
Here is my config. file related to dialog module:
#!define DLG_FLAG 4
loadmodule "dialog.so"
modparam("dialog", "dlg_match_mode", 2)
modparam("dialog", "default_timeout", 3600) # 1 hour timeout
modparam("dialog", "db_mode", 0)
modparam("dialog", "hash_size", 2048)
modparam("dialog", "dlg_flag", DLG_FLAG)
modparam("dialog", "default_timeout", 3600) # 1 hour timeout
modparam("dialog", "timeout_avp", "$avp(i:10)")
if (is_method("INVITE")) {
#$var(rv) = perl_exec("max_allowed_time");
$var(rv) = 30;
$avp(i:10) = $var(rv);
xlog("L_DBG", "return value = $var(rv)\n");
setflag(FLT_ACC); # do accounting
setflag(DLG_FLAG);
}
Maybe i am missing some configuration related to the dialog module.
Any help is very much appreciated.
Thanks.
Hi,
This is a question for the sake of comprehension, as I actually solved
the problem with a workaround.
I am trying to get Kamailio working with a third party SIP provider. The
SIP server of this provider pings my Kamailio with OPTIONS messages.
Being located in a sub-network, the SIP messages are relayed to a router
(not a SIP router, just a gateway to the Internet) which is not
listening/sending on port 5060 but on 13377. When Kamailio answer to
OPTIONS, it send back the message to the router on the port 5060 which
is wrong. Here is the topology:
*Kamailio* *Router* *SIP Server*
/my.sip.domain 174.37.217.1 197.17.144.4/
| | ? <-------------------- 5060 |
| 5060 <---------------- 13377 | |
| 5060 ----------------−> 5060 | |
| | X |
You can see that, Kamailio answers to the wrong port, but I think this
is somewhat coherent since the SIP message says that the port 5060 is in
use. But still, I would have liked that the correct port was used:
*Kamailio* *Router* *SIP Server*
/my.sip.domain 174.37.217.1 197.17.144.4
/ | | ? <-------------------- 5060 |
| 5060 <---------------- 13377 | |
| 5060 ---------------−> 13377 | |
| | ? --------------------> 5060 |
But I do not understand where Kamailio is supposed to find the correct
port. Below are the transport frames, and SIP frames.
Kamailio receives:
Internet Protocol Version 4, Src: 174.37.217.1 (174.37.217.1), Dst:
172.16.8.61 (172.16.8.61)
Source: 174.37.217.1 (174.37.217.1)
Destination: 172.16.8.61 (172.16.8.61)
User Datagram Protocol, Src Port: 13377 (13377), Dst Port: sip (5060)
Source port: 13377 (13377)
Destination port: sip (5060)
OPTIONS sip:my.sip.domain:5060 SIP/2.0
Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bKb9340cb29ba
From: <sip:197.17.144.4>;tag=1797904074
To: <sip:my.sip.domain>
Date: Mon, 10 Aug 2015 10:01:51 GMT
Call-ID: c7f38580-5c817680-b94-38512c6(a)197.17.144.4
User-Agent: Cisco-CUCM10.5
CSeq: 101 OPTIONS
Contact: <sip:197.17.144.4:5060>
Max-Forwards: 0
Content-Length: 0
...and then sends:
Internet Protocol Version 4, Src: 172.16.8.61 (172.16.8.61), Dst:
174.37.217.1 (174.37.217.1)
Source: 172.16.8.61 (172.16.8.61)
Destination: 174.37.217.1 (174.37.217.1)
User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060)
Source port: sip (5060)
Destination port: sip (5060)
SIP/2.0 200 OK
Via: SIP/2.0/UDP
197.17.144.4:5060;branch=z9hG4bKb9340cb29ba;received=174.37.217.1
From: <sip:197.17.144.4>;tag=1797904074
To: <sip:my.sip.domain>;tag=b27e1a1d33761e85846fc98f5f3a7e58.de7a
Call-ID: c7f38580-5c817680-b94-38512c6(a)197.17.144.4
CSeq: 101 OPTIONS
Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY
Accept: */*
Accept-Encoding:
Accept-Language: en
Supported:
Server: kamailio (4.3.1 (x86_64/linux))
Content-Length: 0
We see clearly that the port is wrong here. But in the received SIP
frame, everything suggests that the correct port is 5060, and I do not
think Kamailio will look at the transport frame to send the response
back to the correct port. Am I correct stating this ? Maybe the Via
header should contain a port along with the IP address ?
I solved the problem by using TCP instead of UDP, as I know that since
the TCP connection is maintained, the port would be correct (because
imposed by the gateway).
I am sorry if the question does not directly relates to Kamailio, but
any explanation here would be appreciated, as I am a student trying to
learn how all this is working :)
Cheers,
Jean-Marie.
Maybe a bit offtopic, but I can't find a rtpengine mailinglist and know the
Sipwise guys are reading this list.
Since upgrading to 4.2.x and rtpengine instead of rtpproxy I'm seeing problems
with calls being terminated by upstream provider after a bit more than 5m. The
INVITE process looks okay, the only difference with before as far as I can see
is the rtcp attribute in the SDP body.
According to
http://kamailio.org/docs/modules/4.2.x/modules/rtpengine.html#rtpengine.f.r…
and https://github.com/sipwise/rtpengine
rtcp offering can be disabled. But neither rtcp-mux-demux nor rtcp-mux-accept
have any impact on the adding of the a=rtcp:port attribute in SDP.
rtpengine_manage("trust-address replace-origin replace-session-connection
rtcp-mux-accept ICE=remove");
or
rtpengine_manage("trust-address replace-origin replace-session-connection
rtcp-mux-demux ICE=remove");
have no effect op the INVITE to the upstream.
kamailio: 4.2.5
rtpengine: 4.1.0.0+0~mr4.1.0.0
It looks like the compile defaults of the ctl and mi_fifo module and the
default kamailio.conf/kamctlrc conflict.
kamailio tries to open:
/tmp/buildd/kamailio-4.3.1+jessie/debian/kamailio/var/run/kamailio//kamailio_ctl
/tmp/buildd/kamailio-4.3.1+jessie/debian/kamailio/var/run/kamailio/kamailio_fifo
and will fail to run, unless explicitly set to conf paths are set to
/var/run/kamailio/kamailio_(ctl|fifo)
Hello,
I just installed the latest stable release of Kamailio (I believe 4.3.1) on a debian 8.1 system using the install guide (http://www.kamailio.org/wiki/install/4.3.x/git).
Starting kamailio didn't work using /etc/init.d/kamailio start.
I got the following error:
# /etc/init.d/kamailio start
[....] Starting kamailio (via systemctl): kamailio.serviceFailed to start kamailio.service: Unit kamailio.service failed to load: No such file or directory.
failed!
After some googling I found out I have to add a new file named kamailio.service to the /etc/systemd/system/ directory.
Kamailio.service:
[Unit]
Description=Kamailio SIP Server
[Service]
Type=forking
PIDFile=/var/run/kamailio.pid
ExecStart=/usr/local/sbin/kamctl start
ExecRestart=/usr/local/sbin/kamctl restart
ExecStop=/usr/local/sbin/kamctl stop
[Install]
WantedBy=multi-user.target
Now I can start kamailio using the command: service kamailio start
Is this the correct way of doing this? Does the file need any changes?
Regards,
Grant
Hi,
I am trying to get Kamailio working with a third party SIP provider.
This provider pings Kamailio with OPTIONS messages, but Kamailio does
not answer correctly: the Call-ID and the tags change where they should
not. Here is an example:
Third party SIP server:
OPTIONS sip:false.sip.provider:5060 SIP/2.0
Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK8e45ac1463a
From: <sip:197.17.144.4>;tag=1669836943
To: <sip:false.sip.provider>
Date: Fri, 07 Aug 2015 12:34:37 GMT
Call-ID: a012e080-5c41a5ce-8e5-38512c6(a)197.17.144.4
User-Agent: Cisco-CUCM10.5
CSeq: 101 OPTIONS
Contact: <sip:197.17.144.4:5060>
Max-Forwards: 0
Content-Length: 0
Kamailio's answer:
SIP/2.0 200 OK
Via: SIP/2.0/UDP
197.17.144.4:5060;branch=z9hG4bK93e5f072f5f;received=174.37.217.1
From: <sip:197.17.144.4>;tag=298911055
To: <sip:false.sip.provider>;tag=b27e1a1d33761e85846fc98f5f3a7e58.8c24
Call-ID: 2defcb00-5c41aa17-93f-38512c6(a)197.17.144.4
CSeq: 101 OPTIONS
Server: kamailio (4.3.1 (x86_64/linux))
Content-Length: 0
You can see that the Call-ID change from "a012e080-5c41a5ce-8e5-38512c6"
to "2defcb00-5c41aa17-93f-38512c6". Likewise, the From tag change
("1669836943" to "298911055"). What could be the reason for this ?
Moreover I think Kamailio should add the field Allow (with
INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY), but it does not.
I should mention that I had to modify /kamailio.cfg/ to have Kamailio
answer to OPTIONS messages (I added *the code in bold*):
if (*!is_method("OPTIONS") && *!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
}
if(is_method("OPTIONS") && uri==myself && $rU==$null) {
*#* sl_send_reply("200","Keepalive");
*options_reply();*
exit;
}
Maybe this hack replaces an expected behavior that I failed to
see/configure ?
Thanks,
Jean-Marie.
Hello sir/mam
How can i configure xcap with kamailio 4.3.
I am finding difficulties in routing logic of xcap_server module amd
xcap_client module.
Will you please share proper documentation of these two technology together.
Hi
is there any way to achive following usecase using carrier route / LCR
/ droude module
i have 10 different termination gateways, each gateways will have more than
10000 destinations and each gateways will have different rate, for example
91 Destination ( there will be 10000 entries like 91 )
gw1 gw2 gw3 gw4 gw5
0.001 0.007 0.003 0.002 0.003
now need to logic to load the these destination with cost and sort gateways
in order of longest match of dialled number,cost, priority for the dialled
destination, which will not use too much CPU and memory
Regards
Arun
Hi,
I'm working with IMC module and noticed that when I execute fifo command
"imc_list_rooms" it crashes.
[root@kamailio75 ]# kamctl fifo imc_list_rooms
my Kamailio version is 4.2.1
Right now the way IMC module works is that a SIP UA has to send a chat room
command to create a new room, get participants added etc. If I try to add
users directly from DB the kamailio don't recognize the room or
participants unless restart. Would it be possible to reload the DB tables
for IMC via MI command, a big plus if we can do room creation, user
addition via MI as well !
Thanks,
Sammy
