[Pkg-voip-commits] r847 - in asterisk/trunk/debian: . patches

[Tzafrir Cohen]

On Thu, Oct 13, 2005 at 09:31:01PM +0100, Mark Purcell wrote:
> Tzafrir,
> 
> Excellent. Thanks for this...
> 
> A couple of queries.
> 
> On Thursday 13 October 2005 19:21, Tzafrir Cohen wrote:
> > * fixed libpri build-dep. What about gtk 1.2, libtonezone?
> 
> Why gtk?  Why did you disable the gtk console.  Granted it isn't very useful, 
> but if there isn't a problem building it, then we should proably include it.

That was a misunderstanding, then. I thought it was removed from latest
1.0.9 and didn't bother checking it. Anybody had a chance to check the
kde console?

> 
> > * rewrote the patch for using a system copy of gsm. Submitted to the Mantis
> 
> excellent.  I guess we should proably look at encorporating most our patches 
> upstream.
> 
> > * postgresql supports still not working 
> 
> :-(
> 
> > * Makefile_install_no1234.dpatch: don't create mailbox 1234 by default
> 
> As we are installing the demo files, perhaps we should install mailbox1234.  
> Should we consider generating a asterisk-config-demo package and maybe an 
> asterisk-config-basic package???  

But the mailbox will be generated automatically as soon as it will be
needed, right? Or is it a non-default mailbox?

> 
> Or could we take your autoconfig from xorcom to autosetup a couple of SIP/ 
> Zaptel hardware options??
> 

autosetup of Zaptel is mostly at install time. The code for that is also in the
Debian Zaptel package (though Debian doesn't include a built
zaptel-modules) .

We've aranged sip.conf, iax.conf and extensions.conf a bit differently.

extensions.conf #include-s "extensions.d/*.conf" . This makes it more 
modular, IMO. You can easily add extensions.conf snippets.

I'm pretty happy with this part and would like to consider adding it
into Debian.

There is also sip-phones.d/*.conf which is complete sections of sip.conf
and ditto iax-phones.d/*.conf for iax.conf . There is sip-reg.d/*.conf
which is for register=> directives in the [general] section of sip.conf
(and iax-reg.d for iax.conf), but those should eventually go away, as
1.2 should support setting 'register=yes' from the peer settings.

I think those are good ideas, but they're probably not good for
everybody. Anyway, I figure that starting with an empty config file and
letting automatic editors edit just the included files is not such a bad
idea.


There are extra 3 .d directories where each file is not a complete
section, but rather one entry or simply one line:

meetme-rooms.d , voicemail-phones.d (voicemail boxes in the default
context) and extensions-phones.d (dialplan for the context 'phones'.

meetme-rooms.d seems like a good idea. voicemail-phone.d would probably
have been a good idea if Asterisk's usave of voicemail.conf wouldn't
been that backward. extensions-phones.d is rather handy, but maybe it
enforces a dialplan that is not modular enough.

> > * default_debian.dpatch: hopefully now works
> 
> Great!  Should we submit this one upstream..  I think this would be a great 
> bonus upstream, but given the shift from the way upstream places files, this 
> might be a bit of a stuggle for them to accept.  But it is the FHS way of 
> doing things and seems to make sense to me. 

One issue I see with that: what if you want to record sound files?

On Rapid the the "record" extension records to a specific file in the
voicemail directory. But this seems like an ugly hack.



One thing I do want to change in the default configuration:

manager.conf should be enabled by default and listen on 127.0.0.1 only.

It will #include "manager.d/*.conf"

Any package PACKAGE that wishes to configure itself to connect to the 
Asterisk manager interface should create the file
/etc/asterisk/manager.d/PACKAGE.conf that defines access for user
PACKAGE . 

I suppose, though, that it is still not safe enough to use default
passwords from the files in the package. Thus the password will have to
be set on postinst . I used:

  head -c 20 /dev/urandom |md5sum | cut -d' ' -f1

to generate a password that is resonably random and can be handled as a
string. Not something you'd like to type, though.


> 
> Do you want two releases?  
> 1:1.1.9.0beta1.dfsg.1-2 & 1:1.1.9.0beta1.dfsg.1-1
> 
> > +asterisk (1:1.1.9.0beta1.dfsg.1-2) experimental; urgency=low
> 
> > +asterisk (1:1.1.9.0beta1.dfsg.1-1) experimental; urgency=low
> [...]
> >    * What about h323?
> 
> Unsure if the native asterisk H323 support is going to work, as it has been 
> broken for a while.

Broken in 1.0, works in HEAD, I believe. Anyway, I tried to avoid the
need to build openh323 again (build dependencies conflict with Asterisk.
You know the drill). I was also not sure openh323 in Sarge (which I use)
is the same as the one in Sid and I figured it should be resolved in Sid
first.

-- 
Tzafrir Cohen     icq#16849755  +972-50-7952406
tzafrir.cohen at xorcom.com  http://www.xorcom.com