[asterisk-users] Unicall stack, right versions?

[Steve Underwood]

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