sr-users February 2011

sr-users@lists.kamailio.org

72 participants
133 discussions

503 Server error response for REGISTER request (Asterisk v1.6.0.5)

by Vikram Ragukumar

Hello, I had posted this question earlier on asterisk-users, but didn't receive any reply, so I'm posting on sr-users in the hope that someone can provide guidance on how to debug this problem. Our setup involves a Sip softphone registering with a fresh install of Asterisk v1.6.0.5 through an outbound proxy (Kamailio v3.1.1). We observe that about 80% of the time, immediately after startup of the softphone, when the softphone sends a REGISTER message, Asterisk replies with a "503 Server error". However, subsequent REGISTER messages are replied to appropriately (with a 401 Unauthorized). There are very few devices (under 5) registered with Asterisk, so this is not an overload issue. Please find attached a SIP trace for device registration. - What might cause this behavior in Asterisk ? - Are there any config file parameters that require to be changed ? - Would it help to see any other specific logs, if so which ones ? Thanks and Regards, Vikram.

13 years, 9 months

SIP Router 3.03 topoh

by dotnetdub

Hi All, Kamailio had just started to get SIP attacked and it looked like they were sending a bad header and Kamailio died.. Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [R-MAIN =>] Request method OPTIONS is to our domain (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3378]: INFO: <script>: [ROUTE-1] Received registration from sip:1368250498@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3378]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3381]: INFO: <script>: [ROUTE-1] Received registration from sip:100@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3381]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3374]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.401446] kamailio[3374]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3373]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.636774] kamailio[3373]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3388]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.680305] kamailio[3388]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3390]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.710444] kamailio[3390]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [ROUTE-1] Received registration from sip:2478223614@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3383]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3378]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.753334] kamailio[3378]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3379]: INFO: <script>: [ROUTE-1] Received registration from sip:noauth@sipproxy (212.124.123.170) Nov 20 19:48:51 sipproxy sip[3379]: INFO: <script>: [ROUTE-1 !] Credentials invalid; issuing challenge Nov 20 19:48:51 sipproxy sip[3375]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.768137] kamailio[3375]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3383]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.775628] kamailio[3383]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3386]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.790925] kamailio[3386]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3379]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.798926] kamailio[3379]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:51 sipproxy sip[3381]: INFO: <core> [parser/msg_parser.c:339]: ERROR: bad header field [CSeq: 1 REGISTER ACK] Nov 20 19:48:51 sipproxy kernel: [1033573.815493] kamailio[3381]: segfault at 18 ip b70070d9 sp bf916118 error 4 in topoh.so[b7004000+c000] Nov 20 19:48:54 sipproxy sip[3344]: INFO: <core> [main.c:737]: INFO: terminating due to SIGCHLD Nov 20 19:48:54 sipproxy sip[3399]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3396]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3400]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3392]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3401]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3394]: INFO: <core> [main.c:788]: INFO: signal 15 received Nov 20 19:48:54 sipproxy sip[3402]: INFO: <core> [main.c:788]: INFO: signal 15 received Thanks Brian

13 years, 9 months

dispatcher - ds_mark_dst("i"); is inactive only few seconds

by Thomas Baumann

Dear sr-users, I use this straight forward dispatcher config. In the failure route I am calling this function: ds_mark_dst("i"); Also this action is logged: Feb 2 17:20:31 node5 /openser/sbin/kamailio[15945]: INFO: : FAIL_ONE:time [Wed Feb 2 17:20:31 2011] destination sip:10.12.19.31:5060 marked as inactive The gateway is inactive: [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=I priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Few seconds later the gateway is active again (there is still now response to SIP-OPTIONS) [root@node5 ~]# kamctl 'fifo' ds_list URI:: sip:10.12.19.31:5060 flag=A priority=0 attrs=test1=123;test2=456 URI:: sip:10.12.19.21:5060 flag=A priority=0 attrs=test1=123;test2=456 Does anybody have a idea why ? regards, Thomas DB: mysql> select * from dispatcher -> ; +----+-------+----------------------+-------+----------+---------------------+-------------+ | id | setid | destination | flags | priority | attrs | description | +----+-------+----------------------+-------+----------+---------------------+-------------+ | 1 | 1 | sip:10.12.19.21:5060 | 0 | 0 | test1=123;test2=456 | AS 1 | | 2 | 1 | sip:10.12.19.31:5060 | 0 | 0 | test1=123;test2=456 | AS 2 | +----+-------+----------------------+-------+----------+---------------------+-------------+ CONFIG: #!KAMAILIO ####### Defined Values ######### #!define WITH_MYSQL #!define WITH_IPAUTH # *** Value defines - IDs used later in config #!ifdef WITH_MYSQL # - database URL - used to connect to database server by modules such # as: auth_db, acc, usrloc, a.s.o. #!define DBURL "mysql://openser:openserrw@10.12.18.51/openser" #!endif debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to disable the auto discovery of local aliases based on reverse DNS on IPs (default on) */ auto_aliases=no /* add local domain aliases */ alias="m-lab-ca805-sig.kd-lab.de:5060" alias="m-lab-ca805-sig.kd-lab.de" alias="10.12.19.51" /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:10.12.19.51:5060 listen=tcp:10.12.19.51:5060 /* port to listen to * - can be specified more than once if needed to listen on many ports */ port=5060 ####### Modules Section ######## # set paths to location of modules mpath="/usr/local/kamailio-3.1/lib/kamailio/modules_k/:/usr/local/kamailio-3.1/lib/kamailio/modules/" # ------------------ module loading ---------------------------------- loadmodule "mi_fifo.so" loadmodule "kex.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "rr.so" loadmodule "pv.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "siputils.so" loadmodule "xlog.so" loadmodule "sanity.so" loadmodule "ctl.so" loadmodule "mi_rpc.so" loadmodule "acc.so" loadmodule "dialplan.so" loadmodule "avpops.so" loadmodule "dispatcher.so" #!ifdef WITH_IPAUTH loadmodule "permissions.so" #!endif #!ifdef WITH_MYSQL loadmodule "db_mysql.so" #!endif # ----------------- setting module-specific parameters --------------- # ----- tm params ----- # auto-discard branches from previous serial forking leg modparam("tm", "failure_reply_mode", 3) # default retransmission timeout: 30sec modparam("tm", "fr_timer", 30000) # default invite retransmission timeout after 1xx: 120sec modparam("tm", "fr_inv_timer", 120000) # ----- dispatcher params ----- #modparam("dispatcher", "list_file", "/openser/etc/kamailio/dispatcher.list") modparam("dispatcher", "db_url", DBURL) modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "ds_ping_interval", 30) modparam("dispatcher", "ds_probing_threshhold", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=4") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_from", "sip:lb1@m-lab-ca805-sig.kd-lab.de") modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(dsdst)") modparam("dispatcher", "grp_avp", "$avp(dsgrp)") modparam("dispatcher", "cnt_avp", "$avp(dscnt)") modparam("dispatcher", "attrs_avp", "$avp(dsattrs)") # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- permissions params ----- #!ifdef WITH_IPAUTH modparam("permissions", "db_url", DBURL) modparam("permissions", "db_mode", 1) #!endif route{ if ( !mf_process_maxfwd_header("10") ) { sl_send_reply("483","To Many Hops"); drop(); }; #!ifdef WITH_IPAUTH if (!allow_source_address()) { sl_send_reply("403", "Forbidden"); exit; } #!endif # Send to application servers for number evaluation if ($rU=~"^0[1-9][0-9]{5,20}$") { ds_select_dst("1","0"); if (method=="INVITE") { t_on_failure("FAIL_ONE"); } t_relay(); exit(); } sl_send_reply("403", "Forbidden"); exit; } # Sample failure route failure_route[FAIL_ONE] { if (t_check_status("408")) { xlog("L_INFO", "FAIL_ONE:time [$Tf] destination $avp(dsdst) marked as inactive \n"); ds_mark_dst("i"); } exit; } ___________________________________________________________ NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://produkte.web.de/go/webdefreephone

13 years, 9 months

Reloading a module without restart

by Stagg Shelton

Is it possible to reload a module such as siptrace without requiring a full restart of kamailio. I have changed my db_url modparam for the siptrace module and would like to avoid restarting kamailio if possible. Thanks Stagg

13 years, 9 months

Problem with ser

by Asuncion Merino Rodriguez

Hello, i have insalled a ser server sucessfully. To try it, we was registered by a softphone, but when i am calling to the another registered user, he hang the phone but we cant ear anything. Can somebody help me? Thanks

13 years, 9 months

Redundancy between 2 Kamailio servers

by Danny Dias

Hello my friends, I wonder if someone has done this before? i would like to implement 2 Kamailio servers with redundancy, something like the following: SERVER_A is working as the primary sip proxy (virtual IP as the sip signaling), if it fails, the other server (sleeping) should UP the virtual IP and takes all the traffic....i guess there is many Linux implementations thah can do this, but i would like to know if there is someone that has done this before and hear some recomendations... I've read some difficulty in the synchronisation of registrations because Kamailio works best when it stores registrations in memory and registrations are constantly changing - they expire and are renewed, as well as new ones joining and old ones leaving. To make the failover solution function seamlessly, it is necessary to synchronise the in-memory registrations between the primary and the backup server . This can be done by forking a copy of the registration request to the backup server, but there are some practical problems in doing this, has anyone do something with this? Thanks in advance!

13 years, 9 months

Weird IPv6 Registration Issue

by Jon Farmer

Hi I am experimenting with a dual homed (IPv4 and IPv6) Openser 1.1.0-tls server. If I register using a IPv6 address then the initial registration works and the details are saved in the location table. However when the UA trys to re-register on expiry the SIP returns a 200 OK but the location data is not updated in the table. Looking at the syslog it is reporting that it didn't save the data as there was an existing entry on index with key 1. This is referring I presume to the primary index on "username, domain, contact) on the location table. So what happens is the first location entry expires and gets deleted from the table and thus there is no record for the subsequent register and thus openser thinks the UA has dropped off until the next re-register when because there is no longer a location record the data gets saved correctly. This doesn't happen if I register the same UA on IPv4 on the same openser server. Anyone got any ideas why this is happening? Regards Jon -- Jon Farmer Tel: 07795 118140 Email: viperdudeuk(a)gmail.com Twitter: @viperdudeuk

13 years, 9 months

ACC error | failed to insert into database

by alex pappas

Hi all, Hve anyone seen before the following error? *Kamailio acc [acc.c:398]: failed to insert into database* After a Kamailio restart it is ok but it start again afetr x time. Thank you Alex

13 years, 9 months

Re: [SR-Users] t_local_replied() ?

by Bernhard Suttner

argh. I just mixed up the true/false return values in the eMail but you still got it :-) Thanks a lot! ----- Original Message ----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] To: Bernhard Suttner [mailto:bernhard.suttner@winet.ch] Cc: sr-users(a)lists.sip-router.org Sent: Tue, 01 Feb 2011 20:31:17 +0100 Subject: Re: [SR-Users] t_local_replied() ? > Hello, > > not sure if you ask about the options, or you tried them and don't give > you the needed feature, since there are some improper true/false return > codes in your email. t_branch_replied() will return false if the 408 is > generated locally. > > Cheers, > Daniel > > On 2/1/11 8:25 PM, Bernhard Suttner wrote: > > Hi, > > > > just to be sure: > > > > - If the gateway does send back a 100 Trying and then a 408 is detected > within failure_route the method t_branch_replied does return false (means: > gateway is up and running) - dont go to next gateway (dispatcher) > > > > - If the gateway does not respond and a 408 is detected within > failure_route (= 408 was generated from kamailio) t_branch_replied does > return true (means: gateway is down) - go to the next gateway (dispatcher) > > > > Is that correct or am I wrong? > > > > Best regards, > > Bernhard > > > > > > > > ----- Original Message ----- > > From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] > > To: Bernhard Suttner [mailto:bernhard.suttner@winet.ch] > > Cc: sr-users(a)lists.sip-router.org > > Sent: Tue, 01 Feb 2011 13:30:54 +0100 > > Subject: Re: [SR-Users] t_local_replied() ? > > > > > >> Hello, > >> > >> On 2/1/11 12:08 PM, Bernhard Suttner wrote: > >>> Hi, > >>> > >>> I am using the dispatcher module and want to check within the > >> failure_route if the 408 was internally generated from kamailio or it was > >> received from the dispatcher gateway. > >>> There was previously a function called t_local_replied() in the > TM-module > >> but I could not find this function in the current documentation. Was it > >> removed? > >>> Is there a alternative to check if the 408 was local generated or if it > >> was received from the peer (= from the dispatcher gateway)? > >> see the example of: > >> http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_replied > >> > >> Cheers, > >> Daniel > >> > >> -- > >> Daniel-Constantin Mierla > >> http://www.asipto.com > >> > >> > > _______________________________________________ > > 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 > > -- > Daniel-Constantin Mierla > http://www.asipto.com > >

13 years, 9 months

Re: [SR-Users] t_local_replied() ?

by Bernhard Suttner

Hi, just to be sure: - If the gateway does send back a 100 Trying and then a 408 is detected within failure_route the method t_branch_replied does return false (means: gateway is up and running) - dont go to next gateway (dispatcher) - If the gateway does not respond and a 408 is detected within failure_route (= 408 was generated from kamailio) t_branch_replied does return true (means: gateway is down) - go to the next gateway (dispatcher) Is that correct or am I wrong? Best regards, Bernhard ----- Original Message ----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] To: Bernhard Suttner [mailto:bernhard.suttner@winet.ch] Cc: sr-users(a)lists.sip-router.org Sent: Tue, 01 Feb 2011 13:30:54 +0100 Subject: Re: [SR-Users] t_local_replied() ? > Hello, > > On 2/1/11 12:08 PM, Bernhard Suttner wrote: > > Hi, > > > > I am using the dispatcher module and want to check within the > failure_route if the 408 was internally generated from kamailio or it was > received from the dispatcher gateway. > > > > There was previously a function called t_local_replied() in the TM-module > but I could not find this function in the current documentation. Was it > removed? > > > > Is there a alternative to check if the 408 was local generated or if it > was received from the peer (= from the dispatcher gateway)? > see the example of: > http://kamailio.org/docs/modules/stable/modules/tm.html#t_branch_replied > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > >

13 years, 9 months

Jump to page:

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 February 2011