I need to send re-invite after pacemaker fails over on new rtpengine
server. Because new rtpengine dont participate in DTLS handshake and i hear
nothing, but silence. I think, may me its would be work. Do you have any
idea on this issue?
Hi List,
I try to register to Deutsche Telekom and there product Deutschland Lan
siptrunk.
Thats works find but i see an intressting behaviour on selecting the right
outgoing interface.
Kamailio is sending out with tcp the REQUEST via first private ip
configured on that server (172.20.120.53).
There is no listen directive for that.
I forced NAPTR to use tcp or udp and i assume that kamailio got the right
dns answers.
On the list i read also that i can use force_send_socket to force the
outgoing request.
Now my idea - hey i use the $rP for the outgoing to select the right
outgoing listen directive.
$rP - reference to transport protocol of R-URI
But to my surprise the logfile told me thats "UDP" - it sends out via TCP
(thats okay).
Whats an good transport selector variable from kamailio that works?
event_route[tm:local-request] {
if(!is_method("OPTIONS")) {
xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to
[$ru] [$rP]\n");
}
}
INFO: <script>: [tm:local-request] request [REGISTER] from [
sip:+49XXXXXXXX@sip-trunk.telekom.de] to [sip:sip-trunk.telekom.de] [UDP]
listen=tcp:2xx.xx.xx.xx:5060
listen=udp:2xx.xx.xx.xx:5060
listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061
listen=udp:172.20.120.55:5060
listen=udp:172.20.120.56:5060
listen=udp:172.20.120.57:5060
listen=udp:172.20.120.58:5060
listen=tcp:172.20.120.58:5060
use_dns_cache=on # use internal DNS cache
use_dns_failover=on # depends on internal DNS cache
dns_srv_loadbalancing=on
dns_try_naptr=on
dns_retr_time=1 # seconds before retrying a DNS request
dns_retr_no=3 # number of DNS retransmissions
dns_naptr_ignore_rfc=yes # ignore target NAPTR priority
dns_tcp_pref=30 # TCP has second-highest priority
dns_udp_pref=10 # use UDP with least priority
tcp_connection_lifetime=3605 # set higher than registration expires
#dont' restore
modparam("uac","restore_mode","none")
modparam("uac","restore_dlg",0)
## UAC REGISTER
#!ifdef WITH_UAC_REGISTER
modparam("uac", "reg_contact_addr", "CFG_PROD_IP")
modparam("uac", "reg_timer_interval", 10)
modparam("uac", "reg_retry_interval", 10)
modparam("uac", "reg_db_url", DBURL)
modparam("uac", "restore_mode", "none")
modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)")
modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)")
modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)")
#!endif
ip a l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff
inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192
valid_lft forever preferred_lft forever
inet 2xx.xx.xx.xx/29 scope global ens192
valid_lft forever preferred_lft forever
inet 172.20.120.56/24 scope global secondary ens192
valid_lft forever preferred_lft forever
inet 172.20.120.57/24 scope global secondary ens192
valid_lft forever preferred_lft forever
inet 172.20.120.58/24 scope global secondary ens192
valid_lft forever preferred_lft forever
inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary ens192
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:feb5:c148/64 scope link
valid_lft forever preferred_lft forever
default via 172.20.120.253 dev ens192
172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53
2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx
--
Kind Regards
Mit freundlichen Grüßen
*Karsten Horsmann*
Hi!
I detected strange problem that sip.linphone.org refuse to accept
presence information re-transmitted by kamailio 4.4.4 server.
I debug this problem with tcpdump and I found out that problem is in
kamailio which fills IPv6 address into UDP datagram and that datagram is
sent via IPv4 socket to IPv4 address, to sip.linphone.org server. And
sip.linphone.org server does not have IPv6 connectivity, so correctly
return over IPv4 to sender just "400 Bad Contact Header" error.
On my server is running kamailio 4.4.4 from Debian Stretch and I can
100% reproduce this problem against public sip.linphone.org server.
My server has both IPv4 and IPv6 connectivity and kamailio is listening
for both IPv4 and IPv6 connections.
So why is kamailio sending IPv6 address over IPv4 and therefore makes it
impossible to communicate with non-IPv6 enabled servers? Looks like a
problem with choosing default/correct socket for Contact header.
And how to fix this problem? Can you help me? I would like to have
working interconnection with linphone servers.
Just to note I'm seeing this problem only for presence information
packets. Other requests, like INVITE or MESSAGE seems to work.
Below is relevant tcpdump output. Some parts were replaced by {VAR}.
PS: I'm not subscribed to list, so please CC my address when sending
reply. Thank you!
17:22:58.121719 IP (tos 0x10, ttl 64, id 21629, offset 0, flags [none], proto UDP (17), length 1266)
{MY_IPV4_ADDRESS}.5060 > 91.121.209.194.5060: [bad udp cksum 0xa099 -> 0x9825!] SIP, length: 1238
NOTIFY sip:{REMOTE_NAME}@{REMOTE_USER_IPV4_ADDRESS}:5060;registering_acc=sip_linphone_org SIP/2.0
Via: SIP/2.0/UDP {MY_IPV4_ADDRESS};branch=z9hG4bK2b55.88f93c20000000000000000000000000.0
To: <sip:{REMOTE_NAME}@sip.linphone.org>;tag=75559182
From: <sip:{MY_SIP_URI}>;tag=97d8e785fdf42bf9622a64c13c504961-2708
CSeq: 2 NOTIFY
Call-ID: 26cf9d5c019af2dc3302b770887bcc2e@0:0:0:0:0:0:0:0
Route: <sip:91.121.209.194:5060;lr>
Content-Length: 597
User-Agent: kamailio (4.4.4 (x86_64/linux))
Max-Forwards: 70
Event: presence
Contact: <sip:{MY_IPV6_ADDRESS}:5060;transport=udp>
Subscription-State: active;expires=3600
Content-Type: application/pidf+xml
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" entity="Pali <sip:{MY_SIP_URI}>">
<tuple id="sg89ae">
<status><basic>open</basic></status>
<contact priority="0.8">Pali <sip:{MY_SIP_URI}></contact>
</tuple>
<tuple xmlns="urn:ietf:params:xml:ns:pidf" id="TA0C538B2">
<status>
<basic>closed</basic>
</status>
<contact priority="1">sip:{MY_SIP_URI}</contact>
<timestamp>2019-04-19T17:20:36+02:00</timestamp>
</tuple>
</presence>
17:22:58.151188 IP (tos 0x0, ttl 52, id 22949, offset 0, flags [none], proto UDP (17), length 373)
91.121.209.194.5060 > {MY_IPV4_ADDRESS}.5060: [udp sum ok] SIP, length: 345
SIP/2.0 400 Bad Contact Header
Via: SIP/2.0/UDP {MY_IPV4_ADDRESS};branch=z9hG4bK2b55.88f93c20000000000000000000000000.0;rport=5060
From: <sip:{MY_SIP_URI}>;tag=97d8e785fdf42bf9622a64c13c504961-2708
To: <sip:{REMOTE_NAME}@sip.linphone.org>;tag=75559182
Call-ID: 26cf9d5c019af2dc3302b770887bcc2e@0:0:0:0:0:0:0:0
CSeq: 2 NOTIFY
Content-Length: 0
--
Pali Rohár
pali.rohar(a)gmail.com
Hi,
I have setup Kamailio on Centos 7 as a proxy in front of Asterisk in the same datacenter, using the dispatcher module. I have noted that large INVITEs sent by Kamailio do not arrive at the Asterisk box. It seems the network is dropping fragmented UDP traffic. This does not happen however when I contact the Asterisk box directly from outside the datacenter. Then large INVITES are arriving are Asterisk. So the problem is either in Kamailio or in the datacenter.
I have analysed the problem with ngrep and tcpdump/wireshark. In normal mode (udp4_raw=no setting) Kamailio is producing UDP packets above 1500 bytes and leaves all fragmentation to the operating system. Enabling raw udp in Kamailio and lowering the MTU in the server didnt help. I even disabled offloading of UDP fragmentation to the NIC to get to the bottom of this. However nothing helps. Only forcing TCP in the dispatcher works when having large INVITES going to Asterisk.
In any case, it appears that there is no guarantee that fragmented UDP arrives at all. As far as I am aware, the recommendation is to use TCP if messages are bigger than 1400 bytes. If so, how can I force Kamailio to send messages over 1400 bytes only in TCP mode?
Or is there some other way how to deal with this?
Thanks for any hints.
Gerry
Hi,
I am trying to replicate a REGISTER request between several nodes.
When I am using dmq_t_replicate(), it ends the execution of the script.
It this correct or I have missed anything?
I can not find anything in the documentation of the DMQ module the says that it will end the script execution.
Is it recommended to use the DMQ module or should I simply forward the request instead as described in https://medium.com/@tumalevich/kamailio-registration-replication-without-dm…
Best Regards,
Lars
Hello,
I have a question about record route and via headers. My scenario is
the following:
[asterisk] ---- [kam] -------- [trunk]
10.142.0.27 10.142.0.6 200.x.x.x
I have an asterisk an a kamailio in a private ip network
(10.142.0.0/24). Kamailio has the address 10.142.0.6 but is also
natted 1:1 to a public ip (35.0.0.6).
My problem is that when the invite are replied the asterisk replies to
the external ip (35.0.0.6) instead of the internal ip (even though
the kamailio replies goes through the internal network) . I tried
adding a reply route to change the advertised address to no avail.
any advice would be appreciated.
this is my conf:
LISTEN="listen=udp:0.0.0.0:5060 advertise 35.0.0.6:5060"
disable_tcp=yes
loadmodule "jsonrpcs.so"
loadmodule "kex.so"
loadmodule "corex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "textops.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "cfg_rpc.so"
loadmodule "acc.so"
loadmodule "counters.so"
loadmodule "permissions.so"
loadmodule "ipops.so"
modparam("jsonrpcs", "pretty_format", 1)
modparam("tm", "failure_reply_mode", 3)
modparam("tm", "fr_timer", 30000)
modparam("tm", "fr_inv_timer", 120000)
modparam("rr", "enable_full_lr", 0)
modparam("rr", "append_fromtag", 0)
reply_route {
xinfo("source $si");
if(!is_in_subnet($si, "10.0.0.0/8")) {
set_advertised_address("10.142.0.6");
}
else {
xinfo("not in subnet");
}
}
request_route {
# per request initial checks
route(REQINIT);
# CANCEL processing
if (is_method("CANCEL")) {
if (t_check_trans()) {
route(RELAY);
}
exit;
}
# handle retransmissions
if (!is_method("ACK")) {
if(t_precheck_trans()) {
t_check_trans();
exit;
}
t_check_trans();
}
# handle requests within SIP dialogs
route(WITHINDLG);
### only initial requests (no To tag)
# authentication
#route(AUTH);
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE|SUBSCRIBE")) {
record_route();
}
# dispatch requests to foreign domains
route(SIPOUT);
if ($rU==$null) {
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
}
# Wrapper for relaying requests
route[RELAY] {
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Per SIP request initial checks
route[REQINIT] {
if($ua =~ "friendly-scanner|sipcli|VaxSIPUserAgent") {
# silent drop for scanners - uncomment next line if want to reply
# sl_send_reply("200", "OK");
exit;
}
if (!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");
exit;
}
if(!sanity_check("1511", "7")) {
xlog("Malformed SIP message from $si:$sp\n");
exit;
}
}
# Handle requests within SIP dialogs
route[WITHINDLG] {
if (!has_totag()) return;
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
if ( is_method("NOTIFY") ) {
record_route();
}
route(RELAY);
exit;
}
if (is_method("SUBSCRIBE") && uri == myself) {
send_reply("405", "Method Not Allowed");
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;
}
route[SIPOUT] {
if (uri==myself) return;
append_hf("P-hint: outbound\r\n");
route(RELAY);
exit;
}
--
Iván Aponte
Office: +58(212)9923193
Mobile: +58(412)2774713
Hi, I'm encountering an issue when relaying late offer ACKs, before
relaying I set the branch_route with t_on_branch() but kamailio never
enters that route after calling t_relay
I'm keeping the rtpengine module calls inside branch_routes to avoid issues
when re-routing in failure routes
I suppose it's something related to ACK packets but I'm not sure what the
issue is.
Any hints?
Thanks,
Enrico.
Hello,
Is it possible to add ATCF/ATGW functionality in kamailio as P-cscf ?
I have IMS network with kamailio as P-cscf, icscf, scscf and FHoss .
ATCF/ATGW is necessary for handovers between 2G/3G and LTE networks.
