Re: [asterisk-dev] zaptel, menuselect and autoconf
It turns out that that I only submitted one bug report http://bugs.digium.com/view.php?id=7876 originally on 9/3/06 for the v1.2 build issues which was then extended to the v1.4 build issues and was left in my court on 3/26/07. I haven't responded because the fixes would have been ugly band aids. Proper fixes required a re-design of the entire build process and I didn't have the time or resources to do it. After performing the work on the original v1.2 Makefiles and having them 'perfect' for both Solaris as well as other OS builds I was not prepared to try and re-engineer the new build process in v1.4 to be portable across all operating systems using autoconf alone. I didn't agree with the menuselect process in the v1.4 and I didn't want to spend any time engineering it out of the build process only to start a big controversy and have the work rejected. We just needed the build process for v1.4 to work on Solaris and I was completely blown away by the introduction of menuselect and its inherent problems. We couldn't even get menuselect to compile on Solaris so that pretty much ended its use here and we just got the machete out and hacked it out of the build process until we could get a v1.4 build to work. The resulting Makefiles are ugly and very Solaris specific - something that I would not want to post as a potential patch. I really wish that I could spend the time and resources to engineer a solid autoconf build process for asterisk but we are all tapped out. All of the 'options' that menuselect handles could easily be incorporated into an autoconf process as various build options. Has anyone looked at what it takes to build PHP lately? There are a large number of options that are handled very well by the autoconf process and make it very easily to automate the build process. We use build scripts here that wrap the entire build process into a single script that any junior admin to could safely run to build most open source packages and even create the Solaris specific installation packages. The result is consistent and predictable software builds. Michiel van Baak wrote: On 10:01, Tue 31 Jul 07, Bob Atkins wrote: The issues you bring up with menuselect in terms of automating the build process is why we ripped it out completely from the v1.4 build process. We just replace the Makefile with our own which is actually a derivative of the v1.2 Makefile that we corrected quite some time ago to support building properly on Solaris systems but the corrections were never accepted when we submitted them. A 'standard' autoconf build process would make life for everyone much simpler however, we found that autoconf was not implemented in a portable manner in v1.4 either - important compile options were not being passed down to subordinate builds so everything would break during the build process. We also reported this problem in another bug report with suggested fixes but that report also died quietly as well. What are the bugnumbers on bugs.digium.com ? begin:vcard fn:Bob Atkins n:Atkins;Bob org:DigiLink, Inc. adr;dom:Suite 408;;4676 Admiralty Way;Marina Del Rey;CA;90292 email;internet:[EMAIL PROTECTED] title:President/CEO tel;work:310-577-9450 tel;fax:310-577-3360 url:http://www.digilink.net version:2.1 end:vcard ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] zaptel, menuselect and autoconf
On 7/31/07, Bob Atkins <[EMAIL PROTECTED]> wrote: > > The issues you bring up with menuselect in terms of automating the build > process is why we ripped it out completely from the v1.4 build process. We > just replace the Makefile with our own which is actually a derivative of the > v1.2 Makefile that we corrected quite some time ago to support building > properly on Solaris systems but the corrections were never accepted when we > submitted them. > > A 'standard' autoconf build process would make life for everyone much > simpler however, we found that autoconf was not implemented in a portable > manner in v1.4 either - important compile options were not being passed down > to subordinate builds so everything would break during the build process. We > also reported this problem in another bug report with suggested fixes but > that report also died quietly as well. > > Basically, we just end up doing our own thing. > > I have had the same issues building with AstLinux. As has been pointed out before menuselect is not friendly for scripts or Makefiles. I don't understand why we need it at all. There are already several different ways to build complicated software on *NIX systems. IMHO if "straight" autoconf/automake is good enough for something like Apache it should be good enough for Asterisk too. Just looking at the output from configure in Apache2 shows a build system that is much more capable, flexible, and scriptable (some might also say simpler) than the current combination in Asterisk - with many, many more modules and options available to the user. All of this with no build time dependencies on mxml, etc. Tzafrir's --with-modules is very Apache-like (--enable-modules) :). Granted his is for zaptel, but I'd like to see it in everything. Even Kconfig as used with the Linux kernel would be better than menuselect. -- Kristian Kielhofner ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [svn-commits] tilghman: trunk r77834 - in /trunk: UPGRADE.txt funcs/func_lock.c
SVN commits to the Digium repositories wrote: > Author: tilghman > Date: Tue Jul 31 11:44:25 2007 > New Revision: 77834 > > URL: http://svn.digium.com/view/asterisk?view=rev&rev=77834 > Log: > Add func_lock, which creates dialplan mutexes, and note that the Macro apps > are now deprecated. > (Closes issue #10264) This should be added to CHANGES, as well. Also, it is probably worth noting in the documentation for the functions that you don't need to have any special handling in the case that a channel hangs up in the middle of a critical section of the dialplan. It is important to know that the lock will get automatically unlocked when the channel goes away instead of trying to handle it in the 'h' extension. -- Russell Bryant Software Engineer Digium, Inc. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] zaptel, menuselect and autoconf
On 10:01, Tue 31 Jul 07, Bob Atkins wrote: > The issues you bring up with menuselect in terms of automating the build > process is why we ripped it out completely from the v1.4 build process. > We just replace the Makefile with our own which is actually a derivative > of the v1.2 Makefile that we corrected quite some time ago to support > building properly on Solaris systems but the corrections were never > accepted when we submitted them. > > A 'standard' autoconf build process would make life for everyone much > simpler however, we found that autoconf was not implemented in a > portable manner in v1.4 either - important compile options were not > being passed down to subordinate builds so everything would break during > the build process. We also reported this problem in another bug report > with suggested fixes but that report also died quietly as well. What are the bugnumbers on bugs.digium.com ? -- Michiel van Baak [EMAIL PROTECTED] http://michiel.vanbaak.eu GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x71C946BD "Why is it drug addicts and computer afficionados are both called users?" ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] AstriCon -- Last chance to speak!
We're getting close to wrapping up the final list of speakers for AstriCon, but wanted to give the Asterisk community one more chance to speak up and be heard. If you're interested in presenting at AstriCon, please go to http://www.astricon.net/ and click on the "Speak at AstriCon" link on the right-hand side of the page. If you know of someone who we should invite to speak, we're open to suggestions as well. Feel free to email me (off the list, please!) with your recommendations. I'm looking forward to a great conference, and hope to see you all there! -- Jared Smith Community Relations Manager Digium, Inc. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] zaptel, menuselect and autoconf
On Tuesday 31 July 2007 11:20, Tzafrir Cohen wrote: > On Tue, Jul 31, 2007 at 10:46:15AM -0500, Tilghman Lesher wrote: > > On Tuesday 31 July 2007 08:13, Tzafrir Cohen wrote: > > > On Tue, Jul 31, 2007 at 07:34:54AM -0500, Tilghman Lesher wrote: > > > > On Tuesday 31 July 2007, Tzafrir Cohen wrote: > > > > > > Asterisk is really the application menuselect was designed > > > > > > for. However, is there really a point for the common user > > > > > > to disable building modules? Again: "make the common task > > > > > > simple, make everything possible". One problem with > > > > > > menuselect of today is that it makes it all too easy to > > > > > > accidentally building a module. > > > > > > > > > > So again: what usage scenarios are there where there is a > > > > > benefit from using menuselect with asterisk? > > > > > > > > > > (This is not a rhethorical question. Please provide examples) > > > > > > > > I think the main benefit is persistance. If you really only > > > > need to build two modules for a particular installation, then > > > > it is easier simply to do (on update): "svn update ; > > > > ./configure ; make ; make install" (and remember, it is EXACTLY > > > > the same sequence as Asterisk, which, on an update, you are > > > > going to build as well). And the persistance saves you both > > > > thought time (what does this box actually have installed in > > > > it?) and compile time (why am I compiling a module that this > > > > box will never use?). > > > > > > Is this supposed to be quoted as an atvantage of menuselect? > > > > > > Menuselect breaks persistance: it starts a user interface. It > > > must be interactive. Thus does not allow simple automation the > > > way configure (autoconf) is. You can't "save" the choices you > > > made there in your command-line history. > > > > Not in your command-line history, but your choices are saved and > > will persist across an upgrade (assuming you're still in the same > > release branch). > > > > > How do you automate the action of "disabling chan_zap"? How do > > > you automate the action of "enabling only ztdummy" (of the zaptel > > > kernel modules)? > > > > Please understand the difference between automation and > > persistance. I simply meant that you only need to interact with > > menuselect once, at the point of installation. Thereafter, you > > need only run the sequence. Furthermore, the sequence that you run > > to upgrade your entire install base is the same, regardless of the > > difference in cards installed in each machine. > > > > I do understand that as a package maintainer, your needs are > > different, in that you would prefer to have automation over > > persistence, but for those of us who install Asterisk from source, > > the persistence is preferred. > > If you didn't change anything, why run configure? Because sometimes the developers change what is autodetected, even during a release, because a distribution changes what is required. > If you just want to regenerate all of the config files created by > ./configure without needing to remember the command-line parameters > you used, run: > > ./config.status That would work, assuming the base configure script didn't change. > You can always have ./myconfigure with all of your switches and > enviornment settings for configure. This will also help > cross-builders. > > Would it help if I add to configure.ac an extra --with switch to > generate a ./myconfigure script with all the command-line options > (except the --with, of course) ? > > Or is this too much of a bloat? I don't see the necessity of it, over what we have now. > And my original question still stands: why is a custom configuration > actually needed? Besides being cool, how useful is it? > > Again: use cases, please. I already provided one such use case above. Why is your way better? Use cases, please (since you insist upon them). -- Tilghman ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] zaptel, menuselect and autoconf
The issues you bring up with menuselect in terms of automating the build process is why we ripped it out completely from the v1.4 build process. We just replace the Makefile with our own which is actually a derivative of the v1.2 Makefile that we corrected quite some time ago to support building properly on Solaris systems but the corrections were never accepted when we submitted them. A 'standard' autoconf build process would make life for everyone much simpler however, we found that autoconf was not implemented in a portable manner in v1.4 either - important compile options were not being passed down to subordinate builds so everything would break during the build process. We also reported this problem in another bug report with suggested fixes but that report also died quietly as well. Basically, we just end up doing our own thing. Tzafrir Cohen wrote: On Tue, Jul 31, 2007 at 07:34:54AM -0500, Tilghman Lesher wrote: On Tuesday 31 July 2007, Tzafrir Cohen wrote: Asterisk is really the application menuselect was designed for. However, is there really a point for the common user to disable building modules? Again: "make the common task simple, make everything possible". One problem with menuselect of today is that it makes it all too easy to accidentally building a module. So again: what usage scenarios are there where there is a benefit from using menuselect with asterisk? (This is not a rhethorical question. Please provide examples) I think the main benefit is persistance. If you really only need to build two modules for a particular installation, then it is easier simply to do (on update): "svn update ; ./configure ; make ; make install" (and remember, it is EXACTLY the same sequence as Asterisk, which, on an update, you are going to build as well). And the persistance saves you both thought time (what does this box actually have installed in it?) and compile time (why am I compiling a module that this box will never use?). Is this supposed to be quoted as an atvantage of menuselect? Menuselect breaks persistance: it starts a user interface. It must be interactive. Thus does not allow simple automation the way configure (autoconf) is. You can't "save" the choices you made there in your command-line history. How do you automate the action of "disabling chan_zap"? How do you automate the action of "enabling only ztdummy" (of the zaptel kernel modules)? The first is supposed to be rather easy, but in fact not well-documented, and took me quite some time to understand (and with non-intuitive variable names). The second is practically impossible. -- Untitled Document Bob Atkins President/CEO Business Inter-net-working The Cure for the Common ISP! Phone: (310) 577-9450 Fax: (310) 577-3360 eMail: [EMAIL PROTECTED] begin:vcard fn:Bob Atkins n:Atkins;Bob org:DigiLink, Inc. adr;dom:Suite 408;;4676 Admiralty Way;Marina Del Rey;CA;90292 email;internet:[EMAIL PROTECTED] title:President/CEO tel;work:310-577-9450 tel;fax:310-577-3360 url:http://www.DigiLink.Net version:2.1 end:vcard ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] zaptel, menuselect and autoconf
On Tue, Jul 31, 2007 at 07:34:54AM -0500, Tilghman Lesher wrote: > On Tuesday 31 July 2007, Tzafrir Cohen wrote: > > So again: what usage scenarios are there where there is a benefit > > from using menuselect with asterisk? > > > > (This is not a rhethorical question. Please provide examples) > > I think the main benefit is persistance. If you really only need > to build two modules for a particular installation, then it is > easier simply to do (on update): "svn update ; ./configure ; make > ; make install" (and remember, it is EXACTLY the same sequence as > Asterisk, which, on an update, you are going to build as well). > And the persistance saves you both thought time (what does this box > actually have installed in it?) and compile time (why am I > compiling a module that this box will never use?). Persistence is an easy one for autoconf. Let's put in our toplevel Makefile the following bit from autoconf docs: Makefile: Makefile.in config.status ./config.status config.status: configure ./config.status --recheck Explanation: 1. Every run of configure create config.status Running ./config.status regenerate configure outputs without wasting time on re-running configure. 2. However, if configure itself changes, we need to re-run it with the *same options* to regenerate config.status That's what ./config.status --recheck does. So your use-case would be a bit shorter: svn update; make ; make install This is valid for asterisk as well (or any autoconf based system). [BTW: of course if asterisk would use automake as well, it would build this magic into your makefiles and the discussion would have been moot from the beginning] Anything I missed? -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 ... Complex problems have simple, easy to understand wrong answers. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] zaptel, menuselect and autoconf
On Tue, Jul 31, 2007 at 10:46:15AM -0500, Tilghman Lesher wrote: > On Tuesday 31 July 2007 08:13, Tzafrir Cohen wrote: > > On Tue, Jul 31, 2007 at 07:34:54AM -0500, Tilghman Lesher wrote: > > > On Tuesday 31 July 2007, Tzafrir Cohen wrote: > > > > > Asterisk is really the application menuselect was designed for. > > > > > However, is there really a point for the common user to disable > > > > > building modules? Again: "make the common task simple, make > > > > > everything possible". One problem with menuselect of today is > > > > > that it makes it all too easy to accidentally building a > > > > > module. > > > > > > > > So again: what usage scenarios are there where there is a benefit > > > > from using menuselect with asterisk? > > > > > > > > (This is not a rhethorical question. Please provide examples) > > > > > > I think the main benefit is persistance. If you really only need > > > to build two modules for a particular installation, then it is > > > easier simply to do (on update): "svn update ; ./configure ; make > > > ; make install" (and remember, it is EXACTLY the same sequence as > > > Asterisk, which, on an update, you are going to build as well). > > > And the persistance saves you both thought time (what does this box > > > actually have installed in it?) and compile time (why am I > > > compiling a module that this box will never use?). > > > > Is this supposed to be quoted as an atvantage of menuselect? > > > > Menuselect breaks persistance: it starts a user interface. It > > must be interactive. Thus does not allow simple automation the way > > configure (autoconf) is. You can't "save" the choices you made there > > in your command-line history. > > Not in your command-line history, but your choices are saved and will > persist across an upgrade (assuming you're still in the same release > branch). > > > How do you automate the action of "disabling chan_zap"? How do you > > automate the action of "enabling only ztdummy" (of the zaptel kernel > > modules)? > > Please understand the difference between automation and persistance. I > simply meant that you only need to interact with menuselect once, at the > point of installation. Thereafter, you need only run the sequence. > Furthermore, the sequence that you run to upgrade your entire install > base is the same, regardless of the difference in cards installed in > each machine. > > I do understand that as a package maintainer, your needs are different, > in that you would prefer to have automation over persistence, but for > those of us who install Asterisk from source, the persistence is > preferred. If you didn't change anything, why run configure? If you just want to regenerate all of the config files created by ./configure without needing to remember the command-line parameters you used, run: ./config.status You can always have ./myconfigure with all of your switches and enviornment settings for configure. This will also help cross-builders. Would it help if I add to configure.ac an extra --with switch to generate a ./myconfigure script with all the command-line options (except the --with, of course) ? Or is this too much of a bloat? And my original question still stands: why is a custom configuration actually needed? Besides being cool, how useful is it? Again: use cases, please. -- Tzafrir Cohen icq#16849755jabber:[EMAIL PROTECTED] +972-50-7952406 mailto:[EMAIL PROTECTED] http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] behavior of 'nat=yes' with 'directrtpsetup=yes'
I always had the impression that 'nat=yes' is a bit of a legacy parameter that carries back to a time when SIP signaling was not assumed to be symmetrical, which was done later as a concession to the ubiquity of NAT. In other words, a SIP UA was not necessarily justified in concluding that the proper place to send a response to a client in dialogue was on the exact same UDP port that the SIP request originated from. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: +1-678-954-0670 Direct : +1-678-954-0671 ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] behavior of 'nat=yes' with 'directrtpsetup=yes'
You can make things even complicater - e.g. if you Answer() before Dialing out to the other client (e.g. for some announcements) - then directrtp wont work without reINVITE. regards klaus Adam Gundy wrote: > following on from a suggestion that a bug report I raised (10335) is at > least partly a feature request and should be discussed on -dev, I have a > question about the meaning of 'nat=yes', and a feature request... > > basically, I have some NAT-blind SIP clients (OpenWengo) which do not > support SIP reinvites, and I was hoping the directrtpsetup option in > asterisk 1.4.x would help with this. > > the problem is that it doesn't work, basically because of the way > 'nat=yes' deals with RTP - asterisk waits for an incoming packet, then > sends all RTP to the IP/port that it came from. this works around the > fact that the NAT-blind SIP client put LAN IP/ports in the SIP packet. > > so, when we get to directrtpsetup=yes, asterisk ends up sending the LAN > IP/ports of the two clients to each other, which obviously doesn't work > (unless they both happen to be behind the same NAT!), because asterisk > *never receives any RTP from the clients to fix its idea of the IP/ports*. > > now here's the real question: what does 'nat=yes' mean? if it implies > 'symmetric NAT' or 'router with ports forwarded', then we can actually > fix up this situation; we DO know the IP address that the SIP packet > came from, and if (as in my case) the SIP IP address is the same as the > RTP IP address, we could fix our idea of the RTP address without any > packets arriving, and the direct connection should work. > > alternatively, if 'nat=yes' means 'dumb SIP client with no clue what its > IP/ports are', then we basically have to ban directrtp for this case, > and either use reinvites (if enabled), or proxy. > > if that IS the case, can we have a 'nat=symmetric' which means > 'symmetric NAT/router with ports forwarded' please? I'm sure there are > many SIP clients or hardware widgets out there which have no idea about > STUN and basically come with instructions to forward a range of ports > (I'm looking at the Polycom phone on my desk here as one example) > > thanks.. > > > ___ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Jitterbuffer and FAXes with E1
The main problem was in sangoma hardware echocanceler which has some noise filter. Sangoma today announced new drivers, which this filter turns off. I've tested it and fax are now going well. Martin Vít wrote: > Hello, > > I'm testing 1.4.5 (no modifications) with E1 card and i've found problem. > > I've this scenaro > > FAX -> SIP - ATA -> asterisk -> E1 port A --loopback--> E1 port B --> > iaxmodem. > > > When jbenabled is off FAX is delivred OK. But when jbenable = on FAX are > failing in almost every line. I've compared WAV extracted from network > with WAV recorded (app monitor) before it gets to iaxmodem and there is > small differences. Network jitter is about 2ms (lab environment). > > Where could jitterbuffer modifies frames? I've tried to disable plc in > plc.c but without success. Any idea? > > thanks in advance > > ___ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > > -- Martin Vít LAM plus s.r.o. http://www.lam.cz/ Tel.: 605 267 610 ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] zaptel, menuselect and autoconf
On Tuesday 31 July 2007 08:13, Tzafrir Cohen wrote: > On Tue, Jul 31, 2007 at 07:34:54AM -0500, Tilghman Lesher wrote: > > On Tuesday 31 July 2007, Tzafrir Cohen wrote: > > > > Asterisk is really the application menuselect was designed for. > > > > However, is there really a point for the common user to disable > > > > building modules? Again: "make the common task simple, make > > > > everything possible". One problem with menuselect of today is > > > > that it makes it all too easy to accidentally building a > > > > module. > > > > > > So again: what usage scenarios are there where there is a benefit > > > from using menuselect with asterisk? > > > > > > (This is not a rhethorical question. Please provide examples) > > > > I think the main benefit is persistance. If you really only need > > to build two modules for a particular installation, then it is > > easier simply to do (on update): "svn update ; ./configure ; make > > ; make install" (and remember, it is EXACTLY the same sequence as > > Asterisk, which, on an update, you are going to build as well). > > And the persistance saves you both thought time (what does this box > > actually have installed in it?) and compile time (why am I > > compiling a module that this box will never use?). > > Is this supposed to be quoted as an atvantage of menuselect? > > Menuselect breaks persistance: it starts a user interface. It > must be interactive. Thus does not allow simple automation the way > configure (autoconf) is. You can't "save" the choices you made there > in your command-line history. Not in your command-line history, but your choices are saved and will persist across an upgrade (assuming you're still in the same release branch). > How do you automate the action of "disabling chan_zap"? How do you > automate the action of "enabling only ztdummy" (of the zaptel kernel > modules)? Please understand the difference between automation and persistance. I simply meant that you only need to interact with menuselect once, at the point of installation. Thereafter, you need only run the sequence. Furthermore, the sequence that you run to upgrade your entire install base is the same, regardless of the difference in cards installed in each machine. I do understand that as a package maintainer, your needs are different, in that you would prefer to have automation over persistence, but for those of us who install Asterisk from source, the persistence is preferred. -- Tilghman ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-commits] murf: trunk r77810 - /trunk/channels/chan_sip.c
SVN commits to the Asterisk project wrote:
> URL: http://svn.digium.com/view/asterisk?view=rev&rev=77810
> Log:
> Discovered in experiments on core files: if you wrap the lock and unlock
> calls with sip_pvt_lock and sip_pvt_unlock, you lose the tracing info you
> would normally get via DETECT_DEADLOCKS; so I turn these two functions into
> macros when DETECT_DEADLOCKS is called. This way, you get meaningful stuff in
> the file and func slots in the lock_info struct.
Two comments:
1) It was DEBUG_THREADS, not DETECT_DEADLOCKS, that was the real issue here.
2) I've removed this entirely and switched to macros in all cases; there
is no need for the inline function version, as any debugging code that
is needed can be put into the macros using the 'do { } while(0)' trick.
--
Kevin P. Fleming
Director of Software Technologies
Digium, Inc. - "The Genuine Asterisk Experience" (TM)
___
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-commits] rizzo: trunk r77739 - /trunk/channels/chan_sip.c
Luigi Rizzo wrote: > As for "noticeable amount" :) > struct sip_pvt is now 5528 bytes (plus 512 bytes of stringfields). > I hope we can live for a few days with the extra 5-10 bytes i am > temporarily introducing... OK, none of your commit messages said anything about this being temporary... in that case, never mind :-) -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - "The Genuine Asterisk Experience" (TM) ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] 1.4 spanish sounds
I am a spanish speaker and I agree that Asterisk spanish sound files have a bad accent that sounds no spanish at all. Fortunately there are spanish packages of sound files for asterisk around the net. A quick search in google gives this page: http://www.voip-info.org/wiki/view/Asterisk+sound+files+international There are several spanish sound files, some of them are free. Perssy Llamosas Original Message Subject: Re:[asterisk-dev] 1.4 spanish sounds From: Ivo Zivkov <[EMAIL PROTECTED]> To: Asterisk Developers Mailing List Date: 30/07/2007 11:01 p.m. > Don Morrison wrote: >> I had my wife (native Spanish speaker - argentina) listen to the 1.4 >> spanish .wav files and she agreed with German. The problem, for her, was >> not the choice of words nor the syntax, but the strong american (gringa) >> accent. Even I could tell that it does not sound natural at all. I have a >> neighbor who grew up in Colombia and he insists that Colombians speak the >> purest form of spanish - maybe having a Colombian do the recordings is the >> solution? >> >> Germán Aracil Boned wrote: >> >>> Hi >>> >>> In 1.4 version, the spanish sounds, are a very very very bad spanish. >>> This is not a correct spanish. >>> >>> Can change it ? >>> >>> thank you >>> >> ___ >> --Bandwidth and Colocation provided by Easynews.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >>http://lists.digium.com/mailman/listinfo/asterisk-dev >> >> > No offense to the Columbian, they it's not the purity of their > _language_ they are known for. > > > > ___ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] behavior of 'nat=yes' with 'directrtpsetup=yes'
following on from a suggestion that a bug report I raised (10335) is at least partly a feature request and should be discussed on -dev, I have a question about the meaning of 'nat=yes', and a feature request... basically, I have some NAT-blind SIP clients (OpenWengo) which do not support SIP reinvites, and I was hoping the directrtpsetup option in asterisk 1.4.x would help with this. the problem is that it doesn't work, basically because of the way 'nat=yes' deals with RTP - asterisk waits for an incoming packet, then sends all RTP to the IP/port that it came from. this works around the fact that the NAT-blind SIP client put LAN IP/ports in the SIP packet. so, when we get to directrtpsetup=yes, asterisk ends up sending the LAN IP/ports of the two clients to each other, which obviously doesn't work (unless they both happen to be behind the same NAT!), because asterisk *never receives any RTP from the clients to fix its idea of the IP/ports*. now here's the real question: what does 'nat=yes' mean? if it implies 'symmetric NAT' or 'router with ports forwarded', then we can actually fix up this situation; we DO know the IP address that the SIP packet came from, and if (as in my case) the SIP IP address is the same as the RTP IP address, we could fix our idea of the RTP address without any packets arriving, and the direct connection should work. alternatively, if 'nat=yes' means 'dumb SIP client with no clue what its IP/ports are', then we basically have to ban directrtp for this case, and either use reinvites (if enabled), or proxy. if that IS the case, can we have a 'nat=symmetric' which means 'symmetric NAT/router with ports forwarded' please? I'm sure there are many SIP clients or hardware widgets out there which have no idea about STUN and basically come with instructions to forward a range of ports (I'm looking at the Polycom phone on my desk here as one example) thanks.. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
