I have lost the colour coding when i log into Asterisk, everything is in Black and whist, where as before DeadAGI was in Blue, notices where is Yellow and Warning were in Read, ans something else was in Purple, now it is all just white, what did i do wrong? What did i break to make this happen?
How do i find out what version of LIBPRI i have, is there a command i can type in the console and see what version i have and if i need to update it? And if i have too will it wipe out any current settings i have or this nothing more then a software update or driver update and all should be smooth?
[quote=âanglerâ]1. Are you specifying -n when connecting to Asterisk? As this will supress colors.
2. I donât think there is a way to tell what version of libpri you are running easily. If you do upgrade you wonât lose any of your configuration.[/quote]
Hey Angler,
NO i use asterisk -r to connect to asterisk, it only started to happen after i stopped asterisk and restarted it a couple of times during some diagnostics taking place last night with the Sangoma crew.
I have no idea how to get the colour coding back, it was very usefull and handy to have to be honest.
As for the LIBPRI i guess i just find the latest one on line and do an install, no harm in it i guess.
I might be confusing myself here a little, but does one react differently to the other?
I am trying to find out if the Dial Plan is causing the gradual loss of the channels or how the dial plan interacts with the scripts, man there are so many things to diagnose just to resolve such an annoying problem.
[quote=âTeleFoneâ]NO i use asterisk -r to connect to asterisk, it only started to happen after i stopped asterisk and restarted it a couple of times during some diagnostics taking place last night with the Sangoma crew.
[/quote]
Either you posted this to asterisk-users list or someone happened to have asked exactly the same question during the same days. For the sake of archive in this forum, the answer is that ârestart nowâ and safe_asterisk script donât go together - I didnât offer this answer. If you use safe_asterisk in, say, RC script, always start fresh.
I might be confusing myself here a little, but does one react differently to the other?
[/quote]
David,
You may be confusing yourself a little, but are confusing others a lot If I state âthey represent two different extensions at possibly two different prioritiesâ (a la apples and oranges), does this answer the question? You must tell us what kind of difference are you looking for? In what context (not in the sense of dial plan context) do these two statement appear, and why you want to compare them?
Sorry Yuan, i might not have explained myself properly
I just noticed in the Asterisk demoâs they use the ânâ where as we just have it as a number, so i was just wondering if the reaction is different, or they are one in the same thats all.
Of course the other problem is am buried knee deep in diagnosing this problem we are having, i am digging deep and leaving no stone unturned, but so far everything comes up as clean, sometimes small triggers get me to look at things i have not looked at yet, but i guess that is just me reaching for something.
Did you compile it yourself? If not, look for a file libpri.a (probably /usr/lib/), and do
$ strings libpri.a|grep libpri
Itâll give you a hint.
I am under the impression that this is just a dynamic loadable library. No âdriverâ update. (But then there is a mkdep script in the source directoryâŚ)
the ânâ convention was introduced to help dialplan development ⌠it stops you having to renumber your dialplan just because youâve added something else in.
ânâ is for ânextâ and they are exactly the same as a numbered priority. In fact, Asterisk convert them to numbers when extensions.conf is loaded. show dialplan - or dialplan show if 1.4 - in CLI, and youâll see. BTW, this is a very useful diagnostic tool because it shows you stuff you may not expect by reading the file. Also, if you have trouble with number matching, a good trick is to show dialplan 1234@mycontext with â1234â be a real number that you think should be handled differently. I found some silly mistakes in my own dial plan this way.
I look at the faintest hint myself when something goes wrong and Iâm clueless so I understand your feeling But other people canât help without proper context.
Whilst i think now i am barking up the wrong tree since using the show Dial plan command, i am very greatfull though for that info, your right Valley that command shows some mistakes, or bad designing anyway, so i can correct them now, but once again came up clean towards the problem i am having.