[asterisk-users] Unicall stack, right versions?

[Barzilai Spinak]

Thank you Steve.
About the configs in Asterisk... I confess that I'm new to the code so I 
still need to read more. I didn't know about ast_config()

About the hardcodedness of the countries... that seems to be the 
"problem". Everything is too oriented to "my country works like this 
with this telephone company".
When in fact, what I'm using is not even to connect it to a the 
telephone company of my country but to some other machine which has an 
old Call Center implementation with some other modification of the MF R2 
sequence.
It doesn't relate specifically to any country. Yes, they are all 
similar, and being able to specify the number of ANI and DNIS/DID is 
sometimes all you need, that's why I could make it work.

There's some truth in your statement that opening the configuration to 
external files may get some people into trouble.
On the other hand, what I see is a strange mix of:
a) If you're doing telephony stuff you should know what you're doing
b) Most people using Unicall (Asterisk for that matter) have very little 
idea of what they are doing and why (copying and pasting configs from 
here and there).

So, where's the sweet spot? :-)

I can spend 1 hour reading the source code and finally knowing how to 
change it to my needs. (For example, adding a new "country")
Should I need to? Can people from the (b) set do it?
Is it scalable?  What is more of a support nightmare?

Please take all this as constructive comments. I really appreciate your 
work and if I had to do it from the start it would take me months longer!!!


A real question that should go in a different mail, but what the check:

Let's say I have two E1 spans, but one needs to talk CountryFooVersion, 
and the other needs CountryBarVersion (yes, both on the same machine and 
in the same "country", maybe different number of digits for ANI).
How would I go about configing that?  

Thanks

BarZ


Steve Underwood wrote:
> Barzilai wrote:
>
>> Last night I started compiling all the components of the Unicall stack.
>> So far I've been able to successfully do a "testcall".
>>
>> A couple of questions:
>>
>> 1) If you download the "snapshot" libraries, a funcion that used to 
>> be called "dtmf_put" now has been changed to "dtmf_tx_put", however 
>> the client code from the other library (I forget which one atm) still 
>> uses the old name so I had to fix it.
>
> Don't use the snapshots. If you use the latest releases this won't 
> happen.
>
>> 2) the Makefile patch for the Asterisk channel seems to be for the 
>> 1.1.x versions of Asterisk.
>> In the snapshots there's a patch that seems to be for the 1.2.x 
>> versions but I haven't tried it yet.
>> Does it work as is or do I have to "patch the patch"? for Asterisk 
>> 1.2.9?
>
> There hasn't been a need to update the software for some time. The 
> 1.1.x directory works fine with 1.2.x. I should have changed that. Sorry.
>
>>
>> In sum, what is the most up-to-date AND stable combination of 
>> libraries for the Unicall stack?
>
> The latest release is, well, the latest release.
>
>>
>> P.S. 1: A lot of Unicall seems to be hardcoded in the .h and .c 
>> files, like the countries and how they behave... I *might* attempt to 
>> do something more flexible if I have time *and* brush up my C which I 
>> haven't used much in the last 4 years.
>
> Bad idea. Its like that for a reason. The present arrangements make 
> support much much simpler. Things like Dialogic, where R2 is alsmost 
> completely configured in config files still end up hard coding a few 
> things. Those config files cause support trouble, though. In my code 
> the variations needed within countries are already allowed for.
>
> The whole Unicall scheme is being heavily reworked right now, to 
> separate out the hardware specific elements into their own modules. 
> Hard coded support for countries is something I won't be changing, 
> though.
>
>>
>> P.S. 2:  A lot of behavior in the Asterisk ecosystem seems to be 
>> replicated over and over in the different parts of the code, for 
>> example the reading of configuration files, which each programmer 
>> does in their own way.  How about some generalized configuration code 
>> module?  Maybe this question is better for the dev list.
>
> Chaos seems to be the Asterisk way. :-)
>
> Steve
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users