sr-users March 2011

sr-users@lists.kamailio.org

83 participants
123 discussions

$rU isn't used in t_relay() in failure_route

by Steven Wheeler

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

13 years, 9 months

Invitation to connect on LinkedIn

by Andrey Kuprianov via LinkedIn

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

13 years, 9 months

problem with ser 0.9.6

by Sabatella, Michael

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.

13 years, 9 months

Re: [SR-Users] $rU isn't used in t_relay() in failure_route

by Steven Wheeler

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

13 years, 9 months

problem with AAAA request when dns query for ipv6 is disabled

by CT Radu

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

13 years, 9 months

SPCE beyond 50 000 subscribers and 2000 concurrent calls

by Deon Vermeulen

Hi Guys Can the SPCE platform scale beyond 50 000 subscribers and 2000 concurrent calls when adding more hardware, i.e CPU and RAM? rgds Deon

13 years, 9 months

problem unreferencing dialog in dialog module

by Anton Roman

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>

13 years, 9 months

NAT Traversal

by Spinov Evgeniy

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?

13 years, 9 months

TM module fr_timer

by Geoffrey Mina

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

13 years, 9 months

kamailio with module_s/domain modul

by MÉSZÁROS Mihály

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

13 years, 9 months

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users March 2011