|Summary:||ASTERISK-18322: ooh323 , alternate gatekeeper|
|Reporter:||Dmitry Melekhov (slesru)||Labels:|
|Date Opened:||2011-08-22 22:59:40||Date Closed:|
|Status:||In Progress/In Progress||Components:||Addons/chan_ooh323|
|Environment:||Attachments:||( 0) ASTERISK-18322-2.patch|
( 1) change_gk_on_reload-1.patch
( 2) change_gk_on_reload-1-ast10.patch
( 3) change_gk_on_reload-2.patch
( 4) get_ast_gk.sh
( 5) gk_ha.pl
( 6) set_ast_gk.sh
It will be good for me if oooh323 will have alternate gatekeeper support, so if one gatekeeper is down it can register in another one, as many h323 devices do.
|Comments:||By: Alexander Anikin (may213) 2011-08-25 03:15:26.585-0500|
Ok, i'll implement this feature but have one question here:
endpoint must register on both gatekeepers simultaneously or register on second only when primary fail?
By: Dmitry Melekhov (slesru) 2011-09-09 01:16:43.983-0500
Sorry for late reply, I were on vacations.
In my configuration secondary (backup) gatekeeper starts only if primary gatekeeper fail.
But when primary gateekeper becomes available again, secondary gatekeeper will be shutted down.
So in my configuration asterisk have to register on secondary gatekeeper if primary fail, but if secondary fail it have to try reregister on primary, etc...
By: Dmitry Melekhov (slesru) 2012-02-16 03:37:25.321-0600
Is there any progress on this?
Or I can to at least change gatekeeper manually (really by external script).
Bit if I change it in config file and then do ooh323 reload , ooh323 do not tries to change gatekeeper.
Only way is to module unload chan_ooh323 , module load chan_ooh323.
This is acceptable, but...
Could you, please, change ooh323 reload behaviour? Or I have to open another issue ?
By: Alexander Anikin (may213) 2012-02-18 08:10:57.256-0600
Ok, I will implement change of GK IP as fist step,
then full support of many GKs as next step.
By: Alexander Anikin (may213) 2012-02-18 18:28:06.863-0600
Attached patches (for trunk and asterisk 10) allow change gatekeeper mode or IP on 'ooh323 reload'.
Please test it.
By: Dmitry Melekhov (slesru) 2012-02-19 21:47:05.528-0600
Patch works (tested with 10.2rc) , thank you very much!
By: Dmitry Melekhov (slesru) 2012-02-19 23:31:21.396-0600
By: Dmitry Melekhov (slesru) 2012-02-19 23:31:33.680-0600
By: Dmitry Melekhov (slesru) 2012-02-19 23:31:45.788-0600
By: Dmitry Melekhov (slesru) 2012-02-19 23:32:44.053-0600
I uploaded quick dirty scripts which I'm going to use to switch gatekeeper.
Hope they'll help to understand what I want :-)
By: Dmitry Melekhov (slesru) 2012-03-07 04:07:17.770-0600
Just found that ooh323 will not reregister in gatekeeper if it was restarted, even ooh323 reload with this patch doesn't help (may be because there were calls).
Have no debug log sorry and need time to reproduce on production system :-)
By: Dmitry Melekhov (slesru) 2012-03-13 11:25:04.070-0500
Still can't reproduce :-) Looks like I need data link failure again ;-)
Is it possible to include this patch into next asterisk release?
By: Alexander Anikin (may213) 2012-03-13 17:14:13.270-0500
I will do more testing this tomorrow.
Patch is already in trunk, rev 356848 (I was wrong in commit message,
refer to another issue - 19298).
By: Dmitry Melekhov (slesru) 2012-03-16 04:31:09.287-0500
I reproduced problem once.
Unfortunately, ooh323 reload turns debug off, so I have no debug output.
What I did to reproduce:
1. started backup gnugk gatekeeper
2. killed with kill -9 main gatekeeper
3. changed gatekeeper to backup in ooh323.conf
4. called ooh323 reload, all is OK
5. stopped gnugk with killall gnugk
6. changed back gatekeeper to main in ooh323.conf
7. called ooh323 reload, on gnugk console I see only
(10.1.1.17 is address of this asterisk)
and there is no registration attempt .
tried several times with the same result.
So restarted asterisk and got normal registarition:
I hope you will find difference between reload and ooh323 load...
By: Dmitry Melekhov (slesru) 2012-03-16 04:31:44.191-0500
btw, this is not 100% reproduceable :-(
By: Alexander Anikin (may213) 2012-03-21 12:47:15.594-0500
pls test with change_gk_on_reload-2.patch.
I'm not sure but may be it can help if there are new calls during reload.
By: Alexander Anikin (may213) 2012-03-21 12:57:35.173-0500
I can't reproduce your trouble, all reloads did ok in any cases (change from one to second gk and back or reload with same gk).
btw, Gnugk report RCF with some delay after GCF (above 1.5 second).
For further analysis there is need the ooh323_log with tracevelel=6 then we will see what happens in ooh323 internally.
By: Dmitry Melekhov (slesru) 2012-03-21 22:42:07.463-0500
I just installed patch, but, I guess, I'll be able to test not before next week. :-(
I'll report about results or provide debug logs :-)
By: Dmitry Melekhov (slesru) 2012-03-28 04:19:33.234-0500
I found this problem very hard to reproduce with last patch.
I only got it once and this was without tracelevel=6 (I forgot to set it on first attempt).
All I got is
[Mar 28 13:00:40] ERROR: utils.c:571 lock_info_destroy: Thread 'ooh323c_call_thread started at [ 169] ooh323cDriver.c ooh323c_start_call_thread()' still has a lock! - '&callListLock' (0x129b5c0) from 'ooRemoveCallFromList' in ooh323c/src/ooCalls.c:271!
Anyway, next week I'm going to reboot gnugk server, so I'll have another chance ;-)
By: Alexander Anikin (may213) 2012-03-29 08:24:58.135-0500
it's interesting bug but i can't understand when this can be happen ;)
It suggest it cause by this code:
OOTRACEINFO3("Removing call %lx: %s\n", call, call->callToken);
if (!gH323ep.callList) return OO_OK;
when callList is empty ooCleanCall returned without unlock (but when callList is empty
there must be no any calls)
I will commit workaround and will try to understand about this problem.
By: Alexander Anikin (may213) 2012-03-29 08:52:07.593-0500
Patch for correction lock issue in ooCleanCall uploaded.
Dmitry, you can try reload with this patch.
By: Dmitry Melekhov (slesru) 2012-04-02 04:15:09.362-0500
just tried with latest patch.
can't reproduce problem :-)
By: Dmitry Melekhov (slesru) 2012-05-29 04:20:15.214-0500
I'd like to add that I just rebooted my gnugk server and all works OK.
So, if patches are not included yet , please include them in main branch.
By: Alexander Anikin (may213) 2012-06-01 15:08:21.930-0500
I will commit lock issue patch but i'm need to understand before about when this happen ;)
Unfortunatelly I'm very busy on another projects last two months and don't have too much time for ooh323 ;(
But i think we will close this issue at neat week.
By: Dmitry Melekhov (slesru) 2012-08-06 10:28:16.315-0500
Today I configured new server and found that some patches from here are applied in 10.7.0 , but patch-1 can be applied.
Could you tell me should I apply it or change gatekeeper on reload is implemented in another way?
By: Alexander Anikin (may213) 2012-08-06 17:00:25.809-0500
change_gk_on_reload-2.patch is already in 10 codes due to this is bug fix,
change_gk_on_reload-1.patch is in trunk but applied to 10.7.0 without any problem.
So you can apply -1.patch to the asterisk 10 and use it as previously.
By: Dmitry Melekhov (slesru) 2012-08-06 22:55:06.680-0500
It works :-)
By: Dmitry Melekhov (slesru) 2012-09-13 00:44:47.372-0500
btw, just found that if I deregister asterisk in gnugk it doesn't try to reregister.
all other gateways I know reregister...