I am attempting to put together code which will allow us to redirect a
call to a different tn if the route failed.
Example:
User dials 11235551234
Kamailio uses LCR to route to 192.168.0.100 (404 error)
Change $rU to 11235550000 in failure_route
The only way I can get $rU to show up in the SIP message is to call
append_branch() which is not a solution because I now end up with two
SIP messages one that is correct and one that is incorrect.
Here is the failure_route I am using. Any input would be appreciated.
failure_route[ECRC] {
if (t_is_canceled()) {
xlog("L_INFO", "Call has been canceled in 'ECRC'.");
exit;
}
xlog("L_INFO", "SIP Response Code: $T_reply_code");
# We should fail over if we received one of these response codes.
if (!t_check_status("[45][0-9][0-9]")) {
xlog("L_INFO", "Not a failover error.");
exit;
}
# Translate the dialed number into the ECRC DID.
dp_translate("1", "$rU/$rU");
# Load the gateways for normal dialing.
xlog("L_INFO", "Trying to find LCR route for $rU");
if (! load_gws("1", "$rU")) {
xlog("Unable to load routing");
t_reply("503", "Unable to load routing");
exit;
}
xlog("L_INFO", "Trying gateway '$avp(i:709)'");
if (!next_gw()) {
xlog("L_INFO", "No LCR route for $rU");
t_reply("404", "No available gateways");
exit;
}
$rd=$dd;
$rp=$dp;
$du=$ru;
xlog("L_INFO", "ru: $ru");
xlog("L_INFO", "du: $du");
#at this point $ru and $du contain the correct uri.
append_branch();
# Send out the request.
xlog("L_INFO", "Now we're sending the request out.");
if (!t_relay()) {
xlog("L_INFO" "Relay failed!");
t_reply("502", "Bad Gateway");
exit;
}
}
Now I have two SIP messages one containing the correct phone number:
INVITE sip:11235550000@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:xxx.xxx.xxx.xxx;lr=on>
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bK2e2f.4145be65.2
Via: SIP/2.0/UDP
xxx.xxx.xxx.xxx:5060;branch=z9hG4bK28aa7440;rport=5060
Max-Forwards: 69
From: "Steven Wheeler"
<sip:6124243265@xxx.xxx.xxx.xxx>;tag=as30b3d6f5
To: <sip:11235551234@xxx.xxx.xxx.xxx:5060>
...
And one containing the wrong phone number:
INVITE sip:11235551234@xxx.xxx.xxx.xxx SIP/2.0
Record-Route: <sip:xxx.xxx.xxx.xxx;lr=on>
Via: SIP/2.0/UDP xxx.xxx.xxx.xxx;branch=z9hG4bK2e2f.4145be65.3
Via: SIP/2.0/UDP
xxx.xxx.xxx.xxx:5060;branch=z9hG4bK28aa7440;rport=5060
Max-Forwards: 69
From: "Steven Wheeler"
<sip:6124243265@xxx.xxx.xxx.xxx>;tag=as30b3d6f5
To: <sip:11235551234@xxx.xxx.xxx.xxx:5060>
...
Steven Wheeler
swheeler(a)usinternet.com
952-253-3252
LinkedIn
------------Andrey Kuprianov requested to add you as a connection on LinkedIn:
------------------------------------------
Luis,
I'd like to add you to my professional network on LinkedIn.
- Andrey
Accept invitation from Andrey Kuprianov
http://www.linkedin.com/e/-y8k3ym-gljdl3wf-1g/XkppUi8mK5TI9VJsZIpnfBovln4Su…
View invitation from Andrey Kuprianov
http://www.linkedin.com/e/-y8k3ym-gljdl3wf-1g/XkppUi8mK5TI9VJsZIpnfBovln4Su…
------------------------------------------
Why might connecting with Andrey Kuprianov be a good idea?
Have a question? Andrey Kuprianov's network will probably have an answer:
You can use LinkedIn Answers to distribute your professional questions to Andrey Kuprianov and your extended network. You can get high-quality answers from experienced professionals.
http://www.linkedin.com/e/-y8k3ym-gljdl3wf-1g/ash/inv19_ayn/
--
(c) 2011, LinkedIn Corporation
All,
I am a long time lurker but never posted. I am running ser 0.9.6 for many years with no problems. Just recently none of my users can register. Well - they register once then expire out. I noticed that several ser processes are cpu- bound consuming all available cycles.
Once they drop register they can never reregister.
I restored the ser DB to an older one that was saved when the system was working properly. Any ideas why the ser processes would be CPU bound?
Nothing has been changed on the ser proxy in years and the system has been super stable for 2 years. Has anyone seen this behavior in the past?
This is from top:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4466 root 25 0 39960 1948 1368 R 35.8 0.0 1:43.97 ser
4477 root 25 0 39960 2028 1448 R 34.5 0.1 0:21.85 ser
4471 root 25 0 39960 2040 1456 R 32.8 0.1 0:47.63 ser
4475 root 25 0 39960 1940 1360 R 32.5 0.0 2:08.90 ser
4470 root 25 0 39960 1916 1336 R 32.2 0.0 1:09.92 ser
4480 root 25 0 39960 1828 1248 R 30.5 0.0 4:45.16 ser
Any ideas would be greatly apreciated.
Michael
See what's next from IPC
www.UnigyfromIPC.com<http://www.UnigyfromIPC.com>
[cid:unigy-logo-compr64b7.png]<http://www.unigyfromipc.com/>
Join the Conversation: LinkedIn<http://www.linkedin.com/groups?mostPopular=&gid=3808474> * Twitter<http://twitter.com/IPC_Systems_Inc>
[cid:tree5326.png]Please consider the environment before printing this email.
________________________________
DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.
Thanks for the quick response, I actually just ended up moving to a
newer version of Kamailio (v3.1.2) and that fixed my problem.
Steven Wheeler
swheeler(a)usinternet.com
952-253-3252
-----Original Message-----
From: sr-users-bounces(a)lists.sip-router.org
[mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Klaus
Darilion
Sent: Friday, March 18, 2011 1:00 PM
To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
UsersMailing List
Cc: Steven Wheeler
Subject: Re: [SR-Users] $rU isn't used in t_relay() in failure_route
Am 16.03.2011 21:09, schrieb Steven Wheeler:
> $rd=$dd;
> $rp=$dp;
> $du=$ru;
This one I do not understand. Also I do not see the code where you
change $dU?
Anyway, it seems that 2 branches are added: maybe one by lcr module
internally via next_gw and one manually? You can try to change $dU
before calling next_gw and omit the append_branch() call.
regards
klaus
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Did any one had any problem with this?
I have a test setup where I have the following directives for dns caching:
use_dns_cache=yes #enabling DNS caching
dns_cache_del_nonexp=yes # deletes entries if the memory is
becoming full
dns_cache_flags=0
dns_cache_gc_interval=120
dns_cache_init=on
dns_cache_max_ttl=3600
dns_try_ipv6=no # yes if you want the lookup to be
for IPv6 also
dns_try_naptr=yes
despite the fact that I have *dns_try_ipv6=no* kamailio sends a AAAA
request to the DNS server.
This is an extra request in a case where it seems not to be needed.
Also, it seems that a NAPTR request is not sent - I need to investigate
more, being just a hunch for now.
All the best
Radu Costin
Hi all,
we are running Kamailio 3.1.2 in a production environment, using the dialog
module, and it crashed two hours ago.
Here you have the logs we got (addtional log fragments with the acc records
involved in this call are appended at the end of the mail):
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: CRITICAL: dialog
[dlg_hash.c:599]: bogus ref -1 with cnt 1 for dlg 0x7f23f472db30
[2490:1070436595] with clid 'e0a20cb844d211e0acd8001422093865@<CLIENT IP>'
and tags '1577886432-3759264324-335599788-1698171170' ''
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28927]: : <core>
[mem/q_malloc.c:446]: BUG: qm_free: freeing already freed pointer, first
free: dialog: dlg_cb.c: destroy_dlg_callbacks_list(80) - aborting
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: <core>
[main.c:741]: child process 28927 exited by a signal 6
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: ALERT: <core>
[main.c:744]: core was not generated
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28896]: INFO: <core>
[main.c:756]: INFO: terminating due to SIGCHLD
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28948]: INFO: <core>
[main.c:807]: INFO: signal 15 received
Mar 2 14:43:05 kamailio2 /usr/local/sbin/kamailio[28942]: INFO: <core>
[main.c:807]: INFO: signal 15 received
We get the kamailio code from git last week:
sercmd> core.info
{
version: kamailio 3.1.2
id: 4ace86
compiler: gcc 4.3.2
compiled: 09:12:36 Feb 23 2011
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
}
The problem looks like this other one already fixed:
http://lists.sip-router.org/pipermail/sr-users/2009-November/027351.html
We set the Kamailio to debug level in case it happens again.
On the other side, I need to know why the core is not been generated. I have
already checked the points mentioned in
http://www.kamailio.org/dokuwiki/doku.php/troubleshooting:corefiles
1. disable_core_dump is not set in the config file.
2. From /etc/default/kamailio:
...
DUMP_CORE=yes
...
2. From /etc/init.d/kamailio:
...
if test "$DUMP_CORE" = "yes" ; then
# set proper ulimit
ulimit -c unlimited
# directory for the core dump files
COREDIR=/home/corefiles
[ -d $COREDIR ] || mkdir $COREDIR
chmod 777 $COREDIR
echo "$COREDIR/core.%e.sig%s.%p" > /proc/sys/kernel/core_pattern
fi
...
4. Writting permissions of $COREDIR
ls -hall /home
...
drwxrwxrwx 2 root root 4.0K 2010-12-21 09:15 corefiles
...
What else should I check?
Thanks in advance,
regards
Antón
*Acc records related to the dialog whose destruction causes the problem:*
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28902]: NOTICE: acc
[acc.c:275]: ACC: transaction answered:
timestamp=1299073364;method=INVITE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client
IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client
IP>;dst_ouser=<called
number>;dst_user=<called number>;dst_domain=10.90.1.251;src_ip=<client IP>
...
Mar 2 14:42:44 kamailio2 /usr/local/sbin/kamailio[28920]: NOTICE: acc
[acc.c:275]: ACC: request acknowledged:
timestamp=1299073364;method=ACK;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client
IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client
IP>;dst_ouser=<called number>;dst_user=<called
number>;dst_domain=10.90.1.251;src_ip=<client IP>
...
Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28903]: ERROR: <script>:
ACK WITHOUT MATCHING TRANSACTION in e0a20cb844d211e0acd8001422093865@<client
IP> call... ignore and discard.
...
Mar 2 14:43:00 kamailio2 /usr/local/sbin/kamailio[28904]: NOTICE: acc
[acc.c:275]: ACC: transaction answered:
timestamp=1299073380;method=BYE;from_tag=1577886432-3759264324-335599788-1698171170;to_tag=5FFAEA34-6A;call_id=e0a20cb844d211e0acd8001422093865@<client
IP>;code=200;reason=OK;src_user=<caller number>;src_domain=<client
IP>;dst_ouser=<called number>;dst_user=<called
number>;dst_domain=10.90.1.251;src_ip=<client IP>
May be I miss some important details? No suggestions?
Thank you.
> Hello, all.
> Using nathelper + rtpproxy for subj. Kamailio has public and private
> network interfaces. Asterisk is only private. RTP Proxy is working in
> bridge mode and relaying traffic from UAC to Asterisks.
> Everything is working fine, except one configuration. When the client is
> behind router ( a specific one, I do not have an access there to
> check ), and this UAC is making a call to other public extension, which
> is behind router, then RTP Proxy is relaying traffic to the caller,
> using another UDP port, then the packets arrive.
> For instance:
> UAC 1 -> UAC 2
> PUBLIC_IP:10 > KAMAILIO_IP:5555
> KAMAILIO_IP:5678 > PUBLIC_IP:12
> While for the UAC 2 it looks like:
> PUBLIC_IP:20 > KAMAILIO_IP:6767
> KAMAILIO_IP:4564 > PUBLIC_IP:20
> The source and destination UDP ports are the same. As result, I can hear
> UAC 1 and he cannot hear me.
> In case of we have UAC 3, which is behind other router, call is working
> fine with same configuration.
> "It's routers fault" you can say, but in the same configuration ( I mean
> network, not kamailio ) it worked, but when RTPProxy was not in bridge
> mode and Kamailio and Asterisks were in public network. Reinvites are
> not allowed in both cases.
> The question is, why the source and destination UDP ports are different?
> Using STUN in first case, cause without it, private IP written in
> contacts and as result, traffic relayed from Kamailio is incorrect,
> cause heading to private network which is unreachable.
> Any ideas where to dig?
Hello,
I am just curious because I have seen a couple of references to the fr_timer
being in SECONDS and some look like they are in MILLISECONDS. In 1.5.X,
what is this value?
Also - will fr_timer control the retransmission of an INVITE if no 100
Trying is received? Right now it appears my configuration is waiting 500ms
to retransmit the INVITE when I don't get a 100 trying.
This is what my config looks like right now and this is the behavior I'm
seeing.
modparam("tm","fr_timer",15)
modparam("tm","fr_inv_timer",120)
modparam("tm","fr_inv_timer_avp", "$avp(i:704)")
INITIAL INVITE
[No response in 500ms]
RETRANS INVITE
[NO response in 1000ms]
RETRANS INVITE
I'm having a hard time correlating that what I have in my config.
Thanks,
Geoff
Hi,
Is it possible to use kamailio with module_s/domain.so modul?
Could be any known problem occur if i want to use kamailio deb packages
with module_s/domain.so?
Kamailio has an up2date debian packages unlike ser, but i need
modul_s/domain.so modul functionality to manage multiple domain.
Thanks,
Misi
