sr-users January 2011

sr-users@lists.kamailio.org

66 participants
111 discussions

by Pan B. Christensen

Hello, We are using kamailio 1.5 and we have the following problem with ldap_search: A call comes in. If it is to a VOIP user, it will be routed to kamailio, and eventually go to the ldap lookup route: route[10] to look up the user. This is always successful (LDAP can connect). It will then look up user preferences (call forwarding etc.) from SQL in route[12] and route based on this result in route[13]. If the result is "CFU (call forward unconditional) = on", the URI is changed and route[10] (LDAP lookup) is called again. This is always successful (LDAP can connect). If the result is "CFB (call forward busy) = on" and the user is busy, the URI is changed and route[10] (LDAP lookup) is called again. This is also always successful (LDAP can connect). If the result is "CFNR (call forward no reply) = on", the timeout is changed and the call is delivered to the phone through route[14] (location) and route[15] (relay). If the user does not answer, the URI is changed in failure_route[1] and route[10] is called. For some unknown reason, ldap_search always fails in this scenario with the messages: "ldap_session not found", "couldn't get ldap session" and then "no LDAP entry found". Why? And why does this result in the -1 return code and not the -2 return code for ldap_search? The only differences I can think of is that the unsuccessful scenario comes from FAILURE_ROUTE instead of REQUEST_ROUTE, and that longer time has passed since the original invite. Here's a sample log: NOTE the three ERROR lines, the INFO line and the ROUTE 10 line. Dec 27 13:31:55 [3373]: INVITE received from sip:<CALLER>@<SBC_IP> <source IP: <SBC_IP>> to sip:<CALLEE>@<KAM_IP>: Dec 27 13:31:55 [3373]: ERROR:ldap:ldap_reconnect: [ldapprod]: LDAP reconnect successful Dec 27 13:31:55 [3373]: ROUTE 10: LDAP returned: UID = <UID>, voipSipPrimaryUri = <PRIMARY_URI>, voipExtensionUri = sip:<CALLEE>@<DOMAIN> Dec 27 13:31:55 [3373]: ROUTE 12: Effective user properties for UID <UID>: CFU: off <FORWARDTO>, CFB: off <FORWARDTO>, CFNR: on:25 <FORWARDTO>, CFNC: off <FORWARDTO>, VM: <CALLEE>, busy_level: 1, DBrows: 1 Dec 27 13:31:55 [3373]: -------------------- Calling sip:<CALLEE>@<DOMAIN> for 25 seconds. -------------------- Dec 27 13:31:55 [3373]: ROUTE 15: Sending 105 INVITE from sip:<CALLER>@<SBC_IP> to sip:<CALLEE>@<CALLEE_IP> (via <<null>>) Dec 27 13:31:55 [3383]: Response 100 Trying to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Dec 27 13:31:55 [3385]: Response 180 Ringing to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Dec 27 13:32:20 [3388]: FAILURE_ROUTE 1: Timeout for: 104 INVITE from <CALLER> -> <CALLEE> Dec 27 13:32:20 [3388]: -------------------- Forwarding on no reply to <FORWARDTO> -------------------- Dec 27 13:32:20 [3388]: ERROR:ldap:get_connected_ldap_session: [ldapprod]: ldap_session not found Dec 27 13:32:20 [3388]: ERROR:ldap:lds_search: [ldapprod]: couldn't get ldap session Dec 27 13:32:20 [3388]: INFO:ldap:ldap_search_impl: no LDAP entry found Dec 27 13:32:20 [3388]: ROUTE 11: Number lookup results for <FORWARDTO>: Node: VOIP. Dec 27 13:32:20 [3388]: CONFIG ERROR: VOIP number not found in LDAP. Hanging up. Dec 27 13:32:20 [3373]: Response 487 Request Cancelled to Cseq 102 INVITE received from <PROTO>:<CALLEE_IP>:<PORT> Here's the ldap config file: [ldapprod] ldap_server_url = "ldap://ldap.<DOMAIN>" ldap_network_timeout = 500 ldap_client_bind_timeout = 500 kamailio config snippets (in case you need them): # LDAP lookup for UID and primary URI route[10] { ... ldap_search("ldap://ldapprod/<DN>?uid,voipSipPrimaryUri,voipExtensionUri?one?(&(objectClass=voipAddress)(|(voipSipUri=sip:$rU@uio.no)(|(voipSipUri=$var(uri))(voipSipUri=$var(e164uri)))))"); if ($retcode < 1) { switch ($retcode) { case -1: # no LDAP entry found route(11); return(1); case -2: # internal error sl_send_reply("500", "Internal server error"); exit; } } ldap_result("uid/$avp(s:uid)"); $avp(s:exten) = null; if (!ldap_result("voipExtensionUri/$avp(s:exten)")) { xlog("L_INFO", "voipExtensionUri not found.\n"); } if (!ldap_result("voipSipPrimaryUri/$avp(s:p-uri)")) { xlog("L_WARN", "voipSipPrimaryUri not found.\n"); #exit here? } if (isflagset(1)) { xlog("L_INFO", "ROUTE 10: LDAP returned: UID = $avp(s:uid), voipSipPrimaryUri = $avp(s:p-uri), voipExtensionUri = $avp(s:exten)\n"); } if $avp(s:exten) != null { $ru=$avp(s:exten); } else { $ru=$avp(s:p-uri); } route(12); } } # Number lookup. Non-VoIP URI's go here. route[11] { ... } # Database lookup for call forwarding. route[12] { ... } # Call forwarding logic route[13] { if (is_method("INVITE")) { $avp(s:uio_timer_avp) = "300"; if ($avp(s:cfu_status) == "on") { # Forward immediately xlog("L_INFO", "-------------------- $rU forwarded unconditionally to $avp(s:cfu_number). --------------------\n"); $rU = $avp(s:cfu_number); route(10); } ... if ( $var(dlg_busy) >= $avp(s:busy_level) ) { if ($avp(s:cfb_status) == "on") { xlog("L_INFO", "-------------------- $rU has $var(dlg_busy) active calls. Treshold $avp(s:busy_level). Forwarding on busy to $avp(s:cfb_number) --------------------\n"); $rU = $avp(s:cfb_number); route(10); } ... else if ($avp(s:cfnr_status) == "on") { # Forward to phone with timeout then to $avp(s:cfnr_number). # t_set_fr($avp(s:cfnr_timeout) + "000"); # Recommended method in 3.1. Function does not exist in 1.5. Using old method (avp). $avp(s:uio_timer_avp) = $avp(s:cfnr_timeout); xlog("L_INFO", "-------------------- Calling $ru for $avp(s:uio_timer_avp) seconds. --------------------\n"); route(14); } ... } failure_route[1] { ... if $avp(s:cfnr_status) == "on" { if (isflagset(1)) { xlog("L_INFO", "FAILURE_ROUTE 1: Timeout for: $mi $rm from $fU -> $rU\n"); } revert_uri(); $rU = $avp(s:cfnr_number); xlog("L_INFO", "-------------------- Forwarding on no reply to $rU --------------------\n"); route(10); } ... } With kind regards, Pan

13 years, 6 months

tcp hangup

by Juha Heinanen

i have two sr proxies talking with each other over tcp. one is running 3.0 and the other 3.1. sometimes i notice that no sip requests or any other tcp packets get through from 3.0 sr host to 3.1 sr host. netstat on 3.0 sr host shows that tcp connection to 3.1 sr host is in ESTABLISHED state whereas netstat on 3.1 sr shows that the same tcp connection is in FIN_WAIT1 state. it takes several minutes before the hanging tcp connection is replaced by a new working one. there is no ip level connectivity problem between the two sr hosts. any suggestions on what might be going on? is there some known bug in 3.0 tcp implementation that could explain this? -- juha

13 years, 7 months

How to access additional xavp's

by Alex Hermann

Hello, I'm currently toying with xavp's and have some trouble accessing the values. I want to have access to the xavp that isn't the last added one. From the wiki page on http://sip-router.org/wiki/devel/xavp I got the impression that indices are supported, but that doesn't seem to work. In the following fragment i want access to the values 1A & 1B, how to do that? $xavp(test=>a) = "1A"; $xavp(test[0]=>b) = "1B"; $xavp(test=>a) = "2A"; $xavp(test[0]=>b) = "2B"; xlog("$xavp(test[0]=>a)"); xlog("$xavp(test[0]=>b)"); xlog("$xavp(test[1]=>a)"); xlog("$xavp(test[1]=>b)"); pv_xavp_print(); Which gives the following result: Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: <null> Dec 21 14:30:35 veyron wsproxy1[10398]: ERROR: <script>: <null> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a38770 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:496]: XAVP value: <xavp:0xb3a387c4> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a387c4 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 2B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 2A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: test Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 2063405720 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 6 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:496]: XAVP value: <xavp:0xb3a386c8> Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:470]: +++++ XAVP list: 0xb3a386c8 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: b Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 110 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 1B Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:473]: *** XAVP name: a Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:474]: XAVP id: 109 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:475]: XAVP value type: 2 Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:484]: XAVP value: 1A Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list Dec 21 14:30:35 veyron wsproxy1[10398]: INFO: <core> [xavp.c:505]: ----- XAVP list -- Greetings, Alex Hermann

13 years, 8 months

Re: [SR-Users] [sr-dev] planning release of v3.1.2

by Bernhard Suttner

Hi, whats about: http://sip-router.org/tracker/index.php?do=details&task_id=108 I think that some users are trying to register to an asterisk system. Or does somebody have a solution for that? A new release would be nice!!! Thanks in advance. Best regards, Bernhard ----- Original Message ----- From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] To: kamailio [mailto:sr-users@lists.sip-router.org], sr-dev [mailto:sr-dev@lists.sip-router.org] Sent: Fri, 28 Jan 2011 20:15:50 +0100 Subject: [sr-dev] planning release of v3.1.2 > Hello, > > I think it is time to release v3.1.2, first date that comes in my mind > is next Thursday if everyone feels it is enough time to take care of > backporting any fix he/she did and it is not yet there. That will > provide us a fresh release for the FOSDEM event. If not, then maybe the > other week, Tuesday, so the participants at the Kamailio Devel training > in Barcelona can practice on it. > > Soon after we should plan also a release for previous stable, branch 3.0. > > Anyone having other options? > > Thanks, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >

13 years, 8 months

Merging nathelper modules

by Ovidiu Sas

Hello all, The nathelper module in modules_k was split in two: - nathelper (dealing with signaling); - rtpproxy (dealing with rtpproxy protocol). I would like to move the rtpproxy module from "modules_k" into "modules" and remove rtpproxy functionality from nathelper (s). This will give to (s) and (k) users: - rtpproxy: a single module for dealing with rtpproxy servers; - nathelper: two variants for dealing with NAT signaling. Next step, will be to merge the two nathelper modules into a single one. Thoughts? Regards, Ovidiu Sas

13 years, 9 months

[OpenSER-Users] uaCSTA support in openser

by Hugo Koblmueller

high.all! i'm wondering if there is any support of uaCSTA in openser (planned)? i'm just working on the integration of asterisk (*) environment to OCS 2007 environment, having openSER in the middle (mainly for TCP/UDP translation and smoothing out the protocol deficienes on both sides). in this setup the * having the openSER in front is talking to the OCS (and vice versa) via the OCS mediation server, which is moreorless sending standard SIP messages, which enables normal softphone (integration to *) of the office communicator. this configuration is already working... now i'm planning to go for the CTI integration, where there is no OCS mediation server in between OCS and openSER, doing the translation of SIP/CSTA to SIP. i'm thinking about using openSER for this task, that's why i'm looking for a CSTA module or perl programm, which is capable of this functionality. afaik for the CTI communication there isn't the full complexity of CSTA needed, just a subset mainly for call setup and call clearing. anyone having experience on this topic? thx & cheers -hugo Great Ideas for Small Devices Hugo Koblmueller Senior Staff Engineer Software Development COMNEON electronic technology GmbH & Co. OHG Freistaedter Strasse 400 4040 Linz Austria hugo.koblmueller(a)comneon.com tel: fax: mobile: Skype ID: +43 (5) 1777 - 15730 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%285%2 9+1777+%2D+15730&Email=hugo(a)koblmueller.com> +43 (5) 1777 - 15810 +43 (676) 82051280 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%28676 %29+82051280&Email=hugo(a)koblmueller.com> drhookson Want to always have my latest info? <https://www.plaxo.com/add_me?u=21475050628&src=client_sig_212_1_banner_join &invite=1&lang=en> Want a signature like <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en> this?

13 years, 9 months

planning release of v3.1.2

by Daniel-Constantin Mierla

Hello, I think it is time to release v3.1.2, first date that comes in my mind is next Thursday if everyone feels it is enough time to take care of backporting any fix he/she did and it is not yet there. That will provide us a fresh release for the FOSDEM event. If not, then maybe the other week, Tuesday, so the participants at the Kamailio Devel training in Barcelona can practice on it. Soon after we should plan also a release for previous stable, branch 3.0. Anyone having other options? Thanks, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

13 years, 9 months

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

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

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