Hello. I have Kamailio running behind NAT. It lesten eth0 with ip
192.168.0.3 and
I have external IP that have domain name (for example sip.myserver.com).
Register packets from clients comes from external IP.
If I write at kamailio.cfg:
alias=sip.myserver.com
I see error at log - bad_uri sip.myserver.com
I think it happens because kamailio does not know atything about external
ip pecause kamamiliol working with server interfaces (eth0, eth1, etc.)
So my question - how to listen external IP with domain name on kamailio
that running behind NAT?
P.S. I do not have any access to router, that present NAT for me.
I am trying to follow the guide shown here:http://www.kamailio.org/docs/openser-performance-tests/ to load test my kamailio system.I am a little unclear as to how many instances of sipp are running. For the first part i see the command ./sipp -sf uac_msg.xml -rsa 192.168.2.102:5060 192.168.2.102:5070 -m 200000 -r 10000 -d 1 -l 70for generating the UAC part but is there another instance of sipp running on the kamailio computer acting as a UAS? I have seen come sites use for example: sipp 192.168.1.100:5060 -sn uas -p 5060 but is this not necessary?
thanks for any help
I have managed to install Kamailio and Siremis 4.x, but I have noticed that neither Kamaliio or Siremis come with a sample config that makes sense for Siremis (as far as I can tell). For instance, if I want to use LCR with dispatchers, the sample Kamilio configs don’t have the dispatcher module loaded or configured. Am I missing something? Can someone please share theirs?
Thanks!
~Noah
Hi list
i've been working with t_suspend, t_continue and async sleep, now the
problem it's with register users, the softphones are frozen when try to
establish a session with kamailio, now my users can't register and the only
error i got is this:
ERROR: registrar [save.c:598]: test_max_contacts(): invalid cseq for aor
<rene>
my kamailio config:
# ----- registrar params -----
modparam("registrar", "method_filtering", 1)
/* uncomment the next line to disable parallel forking via location */
# modparam("registrar", "append_branches", 0)
/* uncomment the next line not to allow more than 10 contacts per AOR */
modparam("registrar", "max_contacts", 30)
# max value for expires of registrations
#modparam("registrar", "max_expires", 3600)
# set it to 1 to enable GRUU
modparam("registrar", "gruu_enabled", 0)
#!ifdef WITH_USRLOCDB
modparam("usrloc", "db_url", DBURL)
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "use_domain", MULTIDOMAIN)
modparam("usrloc", "hash_size", 15)
#!endif
I am currently handling a system that runs kamailio and asterisk in the same machine. The kamailio instances are being used to emulate multiple SIP domains, by means of From/To mangling of incoming packets, which are then routed to Asterisk. The attached
kamailio.cfg does this work.
There is an problem when handling SUBSCRIBE requests (as required for BLF and voicemail indications). My configuration is written so that these SUBSCRIBE requests are not handled by kamailio, but instead routed to asterisk. There is a failure to check
From/To headers to see whether NOTIFY packets generated as part of a subscription can be restored using the information in Record-Route. The end result is that kamailio ends up sending packets with garbled tags that are (rightly) rejected by the SIP endpoint.
The following is an example that demonstrates the issue (using Jitsi as endpoint):
After registration, Jitsi sends a SUBSCRIBE request:
SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
From: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=bf427f4a
To: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>
Max-Forwards: 70
Contact: "avillacisIM" <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>
User-Agent: Jitsi2.5.5255Linux
Event: message-summary
Accept: application/simple-message-summary
Expires: 3600
Via: SIP/2.0/UDP 192.168.3.2:5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Proxy-Authorization: Digest username="avillacisIM",realm="pbx.villacis.com",nonce="U9lZJlPZV/r06Xep/ukc1UzAIO0V3TbS",uri="sip:avillacisIM@pbx.villacis.com",response="0e18f4913c2693f6154c91f158fb17fe"
Content-Length: 0
This packet is mangled by the configuration, and is sent to asterisk like this:
SUBSCRIBE sip:avillacisIM@pbx.villacis.com SIP/2.0
Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
From: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=bf427f4a
To: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>
Max-Forwards: 69
Contact: "avillacisIM" <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>
User-Agent: Jitsi2.5.5255Linux
Event: message-summary
Accept: application/simple-message-summary
Expires: 3600
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0
Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Content-Length: 0
The asterisk response for the SUBSCRIBE:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bKd941.2ab9cf36e41dc48855ae2cbe9a309d0a.0;received=127.0.0.1;rport=5060
Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
From: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=bf427f4a
To: "avillacisIM" <sip:avillacisIM_pbx.villacis.com@127.0.0.1:5080>;tag=as5562e95e
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
Server: Asterisk PBX 11.11.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: <sip:avillacisIM@127.0.0.1:5080>;expires=3600
Content-Length: 0
This is in turn transformed back by kamailio, and sent to Jitsi like this:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.3.2:5060;rport=5060;branch=z9hG4bK-343638-bd3ea073eb8920481b32962f3221eb6f
Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
From: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=bf427f4a
To: "avillacisIM" <sip:avillacisIM@pbx.villacis.com>;tag=as5562e95e
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 2 SUBSCRIBE
Server: Asterisk PBX 11.11.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Expires: 3600
Contact: <sip:avillacisIM@127.0.0.1:5080;alias=127.0.0.1~5080~1>;expires=3600
Content-Length: 0
Now asterisk wants to send a NOTIFY to the endpoint for the subscription. The NOTIFY looks like this:
NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport
Max-Forwards: 70
Route:
<sip:127.0.0.1;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>,<sip:192.168.2.18;r2=on;lr=on;ftag=bf427f4a;vsf=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;vst=AAAAAAAAAAAAAAAAAAAAHwAAAAAAAAAAAAAAAAAAAABAMTI3LjAuMC4xOjUwODA-;nat=yes>
From: "asterisk" <sip:asterisk@127.0.0.1:5080>;tag=as5562e95e
To: <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>;tag=bf427f4a
Contact: <sip:asterisk@127.0.0.1:5080>
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX 11.11.0
Event: message-summary
Content-Type: application/simple-message-summary
Subscription-State: active
Content-Length: 89
Messages-Waiting: no
Message-Account: sip:*97@127.0.0.1:5080
Voice-Message: 0/0 (0/0)
Here is where the bug appears. The autoprocessing does not recognize that the From header (From: "asterisk" <sip:asterisk@127.0.0.1:5080>;tag=as5562e95e) from the above request has nothing to do with the saved information (vsf parameter). Instead, it
blindly mangles the From header, and does not even run a sanity check on the result before routing it. The end result is shown below.
NOTIFY sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com SIP/2.0
Record-Route: <sip:192.168.2.18;r2=on;lr=on;ftag=as5562e95e>
Record-Route: <sip:127.0.0.1;r2=on;lr=on;ftag=as5562e95e>
Via: SIP/2.0/UDP 192.168.2.18;branch=z9hG4bK8333.8bfe7bc2bd554a8631f0d00d463b28ee.0
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bK658fa5fc;rport=5080
Max-Forwards: 69
From: "asterisk" <sip:asterisk@12(.0.0.1:5080.....@127.0.0.1:5080>;tag=as5562e95e
To: <sip:avillacisIM@192.168.3.2:5060;transport=udp;registering_acc=pbx_villacis_com>;tag=bf427f4a
Contact: <sip:asterisk@127.0.0.1:5080>
Call-ID: 87ff107c2665316f4e257b358c54b3d4@0:0:0:0:0:0:0:0
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX 11.11.0
Event: message-summary
Content-Type: application/simple-message-summary
Subscription-State: active
Content-Length: 89
Messages-Waiting: no
Message-Account: sip:*97@127.0.0.1:5080
Voice-Message: 0/0 (0/0)
From examination of the source code, the vsf and vst strings are base64 encodings of the result of XORing the byte strings of the old and new tags. For this to work, the headers of future packets should match. However, here kamailio does not realize that
the header does not match (by the ftag), and also does not check that the resulting "restored" header is a valid header.
Hello all,
I've had proposed a fix to SCA module in the tracker (
https://sip-router.org/tracker/index.php?do=details&task_id=446) but did´t
hear anything about it until now.
I would appreciate some comments on that to see if its feasible to be
committed or even hear for anyone else using SCA module with Polycom phones
to see if they have the same issue described.
Thanks,
João Vitor Arruda
Hello;
i am trying to limit call duration with dialog module. So i use
*timeout_avp *for limiting it. there is no problem to close calls but
when it happens i got some errors and kamailio can not write Bye result
in DB. There is code sample and result in below.
2. question : is there a big difference between dialog_ng and dialog?
Which one is more stable?
3. question : After restarting kamailio , Dialog hash vanish so timeout
isn't working. Can DB mode solve this problem?
PS: event_route[dialog:end] isn't working in Kamailio V 4.1.4. I got
some error like t_w_relay.
Thanks for helps.
------------------------------------------------------------------------
#---------------- dialog params -------------
#!ifdef WITH_DIALOG
modparam("dialog", "enable_stats", 1)
modparam("dialog", "hash_size", 8192)
modparam("dialog", "rr_param", "did")
modparam("dialog", "dlg_flag",4)
modparam("dialog", "timeout_avp", "$avp(i:10)")
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "default_timeout", 3600)
modparam("dialog", "detect_spirals", 1)
modparam("dialog", "profiles_with_value", "userid ; opkodu")
modparam("dialog", "dlg_extra_hdrs", "Hint: Hell Yeah\r\n")
modparam("dialog", "send_bye", 1)
#endif
------------------------------------------------------------------------
route[SW]{
xlog("L_INFO","Dialog:h_id:$dlg(h_id):h_entry:$dlg(h_entry):timeout:$dlg_ctx(timeout_route):bye:$dlg_ctx(timeout_bye):$avp(i:10)");
$dlg_ctx(timeout_bye)=1;
$avp(i:10)=15;
$dlg_ctx(timeout_route)=33;
dlg_manage();
set_dlg_profile("userid","$avp(userid)");
if(get_profile_size("userid","$avp(s_userid)")){
xlog("L_INFO","Userid_Size:$avp(s_userid)");
}
xlog("L_INFO","Dialog:h_id:$dlg(h_id):h_entry:$dlg(h_entry):timeout:$dlg_ctx(timeout_route):bye:$dlg_ctx(timeout_bye):$avp(i:10)");
if(!t_relay()) {
send_reply("408", "Servis Disi");
}else{
exit;
}
return;
}
event_route[dialog:start]{
xlog("L_ALERT","START:ci:$ci:method:$rm:start");
}
event_route[dialog:end]{
xlog("L_ALERT","END");
xlog("L_ALERT","END:$fU:$fd:$si:$rU:$rd:$avp(poparty):$avp(networkdatetime):$avp(ptparty):$avp(pprovider):$avp(maliyet_id):$avp(tibtip)");
xlog("L_ALERT","END:$rm:$rr:$rs:");
}
event_route[dialog:failed]{
xlog("L_INFO","FAILED:ci:$ci:method:$rm:end");
}
route[33]{
xlog("L_INFO","route:33:$fU:$fd:$si:$rU:$rd:$avp(poparty):$avp(networkdatetime):$avp(ptparty):$avp(pprovider):$avp(maliyet_id):$avp(tibtip)");
xlog("L_INFO","route:33:$rm:$rr:$rs:");
}
# 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(DLGURI);
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if
the transaction fails
}
else if ( is_method("ACK") ) {
# ACK is forwarded statelessy
route(NATMANAGE);
}
else if ( is_method("NOTIFY") ) {
# Add Record-Route for in-dialog NOTIFY
as per RFC 6665.
record_route();
}
route(RELAY);
} else {
if (is_method("SUBSCRIBE") && uri == myself) {
# in-dialog subscribe requests
route(PRESENCE);
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
route(RELAY);
exit;
} else {
# ACK without matching
transaction ... ignore and discard
exit;
}
}
sl_send_reply("404","Not here");
}
exit;
}
}
------------------------------------------------------------------------
Aug 1 16:51:52 host-91-93-189-136 /usr/local/sbin/kamailio[6111]:
ALERT: <script>: USERID:456123
Aug 1 16:51:52 host-91-93-189-136 /usr/local/sbin/kamailio[6111]:
ALERT: <script>: arayan:XXXX:aranan:XXXXX
Aug 1 16:51:52 host-91-93-189-136 /usr/local/sbin/kamailio[6111]: INFO:
carrierroute [cr_func.c:710]: cr_do_route(): uri XXXX was rewritten to
sip:YYYYYYYYYYYYYYY@XXXXXXX5:5060, carrier 3, domain 1
Aug 1 16:51:52 host-91-93-189-136 /usr/local/sbin/kamailio[6111]: INFO:
<script>: vardesc: 40
Aug 1 16:51:52 host-91-93-189-136 /usr/local/sbin/kamailio[6111]: INFO:
<script>: Dialog:h_id:<null>:h_entry:<null>:timeout:0:bye:0:<null>
Aug 1 16:51:52 host-91-93-189-136 /usr/local/sbin/kamailio[6111]: INFO:
<script>: Userid_Size:1
Aug 1 16:51:52 host-91-93-189-136 /usr/local/sbin/kamailio[6111]: INFO:
<script>: Dialog:h_id:3953:h_entry:3170:timeout:14:bye:1:15
Aug 1 16:51:55 host-91-93-189-136 /usr/local/sbin/kamailio[6114]:
ALERT: <script>:
START:ci:2c5695c1644fa2b135f57ea72c590cc7@XXXXXXX:5060:method:INVITE:start
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to
parse From uri
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: pv [pv_core.c:397]: pv_get_xto_attr(): cannot parse From URI
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to
parse From uri
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: pv [pv_core.c:397]: pv_get_xto_attr(): cannot parse From URI
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]: INFO:
<script>:
route:33:<null>:<null>:1.0.0.127:you:kamailio.org:<null>:<null>:<null>:<null>:<null>:<null>
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]: INFO:
<script>: route:33:OPTIONS:<null>:<null>:
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ALERT: <script>: END
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to
parse From uri
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: pv [pv_core.c:397]: pv_get_xto_attr(): cannot parse From URI
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: <core> [parser/parse_from.c:113]: parse_from_uri(): failed to
parse From uri
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ERROR: pv [pv_core.c:397]: pv_get_xto_attr(): cannot parse From URI
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ALERT: <script>:
END:<null>:<null>:1.0.0.127:you:kamailio.org:<null>:<null>:<null>:<null>:<null>:<null>
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6145]:
ALERT: <script>: END:OPTIONS:<null>:<null>:
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6121]:
WARNING: dialog [dlg_req_within.c:212]: bye_reply_cb(): inconsitent dlg
timer data on dlg 0x7feb2115d918 [3170:3953] with clid
'2c5695c1644fa2b135f57ea72c590cc7@95.0.154.92:5060' and tags
'as3c7c5aa4' 'as0b640624'
Aug 1 16:52:11 host-91-93-189-136 /usr/local/sbin/kamailio[6121]:
ERROR: acc [acc_cdr.c:574]: cdr_on_end(): invalid values#012!
Hi, I am developing a social application where I want to enable voice & video calling function and still I don't know what to use in server side, do you have any product that I can use to develop the server side(for 10.000+ users)?
Thank you in advance.
I am trying to track down a memory leak that was triggered by a patch I wrote for my local copy of kamailio 4.1.4 . For this, I am following the documentation at http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:memory . This page claims that once
memlog is set in the configuration file, a kamailio process will dump a report of the allocation map when shutting down, or when receiving a SIGUSR1. I have configured my kamailio.cfg with memlog=1 and no other change, and I see the memory report on
shutdown for all processes. However, when I send a SIGUSR1 to a kamailio process, the process does absolutely nothing, with the exception of the first kamailio process (the one reported as Type=attendant by "kamctl ps"). All of the other processes just
ignore SIGUSR1. What is going on? It is inconvenient to force a shutdown of all the kamailio processes just to get the memory report.