[asterisk-users] sdsl

[adebayo omo-dare]

I was just thinking of a recent discussion on this list on SDSL and realised that unlike in Europe where SDSL lines are deployed in accordance with the G.shdsl standard, in North America it is/ maynot (be)the same. As such the above difference would tend to obscure an understanding of points raised in relation to the deployement of * within this environment.Would anybody be able to tell me howthe G.shdsl standard is currently distributed in NA, and indeed if there are deep cost differences between G.shdslbased solutionsand SDSL. Also if you can, perhaps,give any information interms of regional coverage it would be greatly appreciated.Best regards  Bayo 
		 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail.___
--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

Re: [asterisk-users] t1 voip to failover pri

[adebayo omo-dare]

Yes SDSL lines do hook up to the DSLAM. I do not know if the DSLAM itselfis a fear for you, but if it is, you can look at it in this way -All it does is aggregate signals for transmission through a switch and on to a high speed backbone. This, invariably, at some point or another, is the same backbone used to transfer all traffic. With the way things are/are going, at some point, everything, in anyway related to the loop,hooks up toa common point, in some way or another. Possibly you could be more specific about your concern.With telecom companies current strategies, (and here I am thinking most especially of MPLS, Metro Ethernet, etc), each technology is being hardened in order to meet common requirements all based aroundthedelivery of tripple play over a common format (IP).So the fears you may have, may not necessarily be those that I see. 
 As I am sure you already know, this is an extremely wide and complex environment when you want to get things right. It is also very difficult to speak about without knowing exactly what it is you are seeking to get right in an environment where there is always a solution to every problem and always a problem in every solution.I hope the above does in some manner help and all the best.Bayo  stan ford [EMAIL PROTECTED] wrote:if i went with an SDSL line, don't those lines hook up to a common point, the DSLAM?i do like this idea of faling over not to a pri but another cheaper high speed line.adebayo omo-dare [EMAIL PROTECTED] wrote:I wouldn't first presume that there is any law that states you have to run VoIP over a PRI. Other technologies exist such as SDSL - with some providers speaking of crazy prices such as £65pcm for2Mbs5:1 contention ration and £100 for 1:1 (U.K) - should be even less in the states if that's where you are. One option, but not the only one, would be to drop your pri when your contract ends and take up SDSL - and voila an initial saving, inyour case,of a 000 or more in the year.You could also have two SDSL lines for a little less than the price of the PRI. Both lineswould not only serve for High Availability -possibly even better availabilitythan single PRI- but could also, actively, both switch traffic, giving you 4Mbps of
 bandwidth for your VoIP, or if you choose, some other requirement while not required as failover- all for the price of less than one PRI.Then there is compression - 64k non negotiable, per channel forPRI, and flexible -i.e., less the 64k- for VoIP (International high quality Calls are transported at 16k),giving you the capacity to potentially service more traffic with less initial outlay.Other real cost efficiencies come in the form of the fact that IP-to-IP (local/national/international) calls are free. So if you have a lot of inter-branch communications, or communications you can switch on to IP,you can totally erradicate this cost - unlike with the PRI where you will still be subject to payment.  Think like this - say I have two offices - one in london and the other New York. How much will I save by moving my calls on to VoIP with no per-time or call setup
 charges.Features related to OAMP,can also be faster and cheaper with you having a lot more power in your hands.In real senses, and with regards to reliability, you should take in to consideration the great moves currently being made by telecom companies (incumbents most especially), with regards to a complete shift to NGNs, which have a strong focus on ToIP. With new fiber (FTTP), new technology, etc, a lot of networks are highly reliable at the present moment - I guess this would also depend on where you are.The thing about it is that complete IP networks in terms of telecom now look inevitable. And whether you do it yourself or it is done for you - it is the way things, many expect, are going to be in the next 5 or so years.  stan ford [EMAIL PROTECTED] wrote:I'm confused with something, maybe someone can explain to me. if your currently on a pri and are considering moving over to VOIP, that means you would have to purchase a t1 or fractional t1 for a your voip connections. but then, voip connections aren't as reliable as PRI. so then you would probbaly have to get a PRI failover. but then having a PRI failover means that you now have to pay 400 for a T1, then another 400 for your PRI line. wouldn't have you have just defeated the cause of savig money by now having to havea PRI on standby? now costing you 800 a month? wouldn't it almost be the same price to stick with the PRI only?is anyone out there, using a VOIP only with no failover? 
 __Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options 

Re: [asterisk-users] Building the Perfect Box

[adebayo omo-dare]

We were also looking at this telecomproblem as well. A major complication,with regards to recovery planning,lies in the manner in which Local Loop Unbundling occurs. Even though communication companies may carry different logos, and profess to be independent orgs, they are all/mostly, invariably, in one form or another, dependent on the incumbent. In most, if not all cases, they share the incumbent's exchanges - whichusually are individually central tolarge areas.If a problem occurs in the Handover Distribution Frame (HDF)- this is where copper pairs are made available to CLECs in an exchange- non-discriminatory multihoming between providers would seem to be the best remedy. However, if the problem - as in the case of a major fire -is in the Main Distribution Frame (MDF) - where all the pre-unbundled wires are held-all providers, bar none,within
 that exchange will go down.Strategies such as Dual Parenting (connecting to two processors within the exchange), which is usually offered as a HA option, do little in such extreme cases -and whether you have one or two separate providers, under such circumstances,would matter little.However, there are other possibilities, such as multihoming with two different technologies - such as connecting to a Cable company, which, indeed, can provide you with an entirely different route - but, though there are ways around what I say next,you may be screwed on the DID issue. Even when the Cable companies Switching Center connects to the PSTN (SS7 ntwk), it does so with with very high availability as its aim- i.e., it is connectedto more than one, so if one, say, blows up, switching continues on another route - and the thing you then have to worry about is your building not catching fire, or being flooded
 in the middle of winter. You can also ask providers for information about their networks - with regards to location mapping+coverage. You may be - a big may be -lucky, and be in an area within an areawhere two or more exchangesdeliver services thereby allowing you to connect to two different centers. If both centers are run by the same incumbent, then potential DID issues are easily negated.Usually you can ask your providers for availability+performance figures (regional/local)-backdated for several years (they should have them on hand)- and mark such figures against your potential losses as tallied against particular frequencies relevant to your org.If you can do away with not having an SLA, it would usually indicate that your losses in relation to your revenue for the duration of, say, the fault, or, indeed, performance depreciation, are
 inconsequential. Some may say,in the case of business orgs,it could mean that they are not being assessed, or if they are, they are important enough not to let go. However, requirement usually preceeds the SLA, with the latter being mapped to an assessment of the former.You should alsobe very careful of what carriers tell you, as the information you gather is usually only as good as your point of reference. I.e., in many cases, their representative, who may or may not be keyed up, and may, or may not, be very polar with regards to the information she/he is prepared to/can deliver.This of course is an extremely interesting, as well as being a very wide and complex subject. And I do hope the above in some manner helps.Bayo"Jay R. Ashworth" [EMAIL PROTECTED] wrote:  On Sat, Sep 30, 2006 at 11:14:08AM -0500, Brandon Galbraith wrote: On 9/30/06, Tim Panton [EMAIL PROTECTED] wrote:  Just to amplify this point. I've tried to claim on an SLA. Our internet connection was down for a week due to a fire in BT's exchange. My provider refused to do anything (despite the premium SLA) on the basis that fires weren't covered. I switched providers to a cheaper one who didn't pretend to offer uptime :-)  While an SLA is nice on paper, if your connection is business/mission-critical, always always always do redundancy yourself. Just having two connections from seperate providers is nice, multi-homing with two providers and having automatic failover is better (although this mostly applies to larger shops where having the phones/internet out per minute
 costs thousands of dollars/euros/etc.).But see also my earlier comments about the practical impossibility ofguaranteeing physical route diversity for multiple services in the sameformat (copper, fiber), even if from different putative carriers.This is *really* hard to make work; even the carriers themselves willoften *tell* you that you have PRD, and then you'll get backhoe fadedon all circuits anyway.Cheers,-- jra-- Jay R. Ashworth [EMAIL PROTECTED]Designer Baylink RFC 2100Ashworth  Associates The Things I Think '87 e24St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274"That's women for you; you divorce them, and 10 years later,they stop having sex with you." -- Jennifer Crusie; _Fast_Women--Bandwidth and Colocation 

Re: [asterisk-users] t1 voip to failover pri

[adebayo omo-dare]

I wouldn't first presume that there is any law that states you have to run VoIP over a PRI. Other technologies exist such as SDSL - with some providers speaking of crazy prices such as £65pcm for2Mbs5:1 contention ration and £100 for 1:1 (U.K) - should be even less in the states if that's where you are. One option, but not the only one, would be to drop your pri when your contract ends and take up SDSL - and voila an initial saving, inyour case,of a 000 or more in the year.You could also have two SDSL lines for a little less than the price of the PRI. Both lineswould not only serve for High Availability -possibly even better availabilitythan single PRI- but could also, actively, both switch traffic, giving you 4Mbps of bandwidth for your VoIP, or if you choose, some
 other requirement while not required as failover- all for the price of less than one PRI.Then there is compression - 64k non negotiable, per channel forPRI, and flexible -i.e., less the 64k- for VoIP (International high quality Calls are transported at 16k),giving you the capacity to potentially service more traffic with less initial outlay.Other real cost efficiencies come in the form of the fact that IP-to-IP (local/national/international) calls are free. So if you have a lot of inter-branch communications, or communications you can switch on to IP,you can totally erradicate this cost - unlike with the PRI where you will still be subject to payment.  Think like this - say I have two offices - one in london and the other New York. How much will I save by moving my calls on to VoIP with no per-time or call setup charges.Features related
 to OAMP,can also be faster and cheaper with you having a lot more power in your hands.In real senses, and with regards to reliability, you should take in to consideration the great moves currently being made by telecom companies (incumbents most especially), with regards to a complete shift to NGNs, which have a strong focus on ToIP. With new fiber (FTTP), new technology, etc, a lot of networks are highly reliable at the present moment - I guess this would also depend on where you are.The thing about it is that complete IP networks in terms of telecom now look inevitable. And whether you do it yourself or it is done for you - it is the way things, many expect, are going to be in the next 5 or so years.  stan ford [EMAIL PROTECTED] wrote:I'm confused with something, maybe someone can explain to me. if your currently on a pri and are considering moving over to VOIP, that means you would have to purchase a t1 or fractional t1 for a your voip connections. but then, voip connections aren't as reliable as PRI. so then you would probbaly have to get a PRI failover. but then having a PRI failover means that you now have to pay 400 for a T1, then another 400 for your PRI line. wouldn't have you have just defeated the cause of savig money by now having to havea PRI on standby? now costing you 800 a month? wouldn't it almost be the same price to stick with the PRI only?is anyone out there, using a VOIP only with no failover?  __Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam
 protection around http://mail.yahoo.com ___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:http://lists.digium.com/mailman/listinfo/asterisk-users 
		 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail.___
--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

[asterisk-users] Sangoma a301

[adebayo omo-dare]

I am currently looking at designing a testsystem that incorporates Sangoma's a301 with either Tyan or Supermicro,and AMD combinations.I was wondering if anyone here has any experience of running a301s with*.In addition, if they would possibly have any experience specifically with the above type of setup.I am most interested in problems I may face, all/any conflicts involving the above,performance shortfalls, etc.Any and all information/help would be most appreciated.Thank youBayo. 
		 
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail.___
--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

Re: [asterisk-users] PRI Backup

[adebayo omo-dare]

There is the very greatpossibility that employing TDMoE in this environment will introduce new levels of complexity in to the network.And though TDMoE,initself, isfantastic, IMHO- long haultechnology,it may also be considered to be out of scope and limiting/expensive, most especially considering he already employs the type of network many dream of.In terms of distributing inward boundPRI calls acrossthe two sites, your telecom company takes care of those details and forwards calls to the other when the former is seen to be busy. [They possibly call this something like Diversion/Forwarding on Busy] - speak to your provider.In terms of distributing outgoing VoIP-PRI-PSTN calls - Off the top of my head, and there may/should be much better ways,you may/should be able to introduce a global count variable and a GotoIf(...) in the
 dial plan.Hope this, in some manner, helps  BayoMassimiliano Stucchi [EMAIL PROTECTED] wrote:On 200906, 16:00, Forrest Beck wrote:  I am looking to see if anyone has a dial plan setup to use a secondary PRI. We have two campuses, each with it's own PRI (for telco going to a single span digium card) and a 10MB fiber link between the two for data. All calls are transfered between the two campuses via the 10MB data line and outgoing calls are made on the campus'es PRI. I am loking to see if there is a way to tell the server if one PRI is full (all 23 channels are in use) or not available to try routing the call through the other campus and it's PRI. Anyone doing this already? I am not sure how to
 have asterisk check to see if a PRI is down for making the call. I guess I could just add the call route to the other campus just below the my default call route. So if the primary call route fails, it will just go to the next line being the other campus.I would try using TDMoE, and duplicating the PRIs over the two machines,so that:Machine 1 handles PRI A and has B as, say group2Machine 2 handles PRI B and has A as, say group2I don't know if you can run TDMoE over your fiber connection, but I wasjust here for a suggestion.Ciao-- Massimiliano Stucchi, CTO  Director of OperationsWillyStudios.com - IT Consulting, Web and VoIP Services[EMAIL PROTECTED] | Tel (+39) 0244417203 | Fax (+39) 0244417204IT-20040, Carnate (Milano), via Carducci 9___--Bandwidth and Colocation provided by
 Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:http://lists.digium.com/mailman/listinfo/asterisk-users 
		 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine___
--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

Re: [asterisk-users] PRI Backup

[adebayo omo-dare]

Ps. Mr Beck, if you do decide to, at sometime, try totake the TDMoE route - these pages give good pointers:  http://www.asteriskdocs.org/modules/tinycontent/content/docbook/current/docs-html/x1320.html  http://www.voip-info.org/tiki-index.php?page=Asterisk+TDMoE  Yet, IMHO, TDMoE is used to encapsulate raw TDM (say ISDN) traffic in Ethernet for transportation,andis best suited for bridging/backhauling. An example would be,PSTN-PRI-(TDMoE)-IPNetwork-(TDMoE)-PRI-PSTNflows as is currently used by many telcommunication companies.  I am, however,very greatful to Massimiliano for bringing this up, as I did not know that Asterisk could take care of the mux/demux + stringenttiming
 requirements related to TDM transfer in this manner. I would however like to know how Asterisk "generally" performs when compared to other TDMoE provisions such as those sold by RAD or indeed CESoP - if anyone has any answers, your input would be more than welcome.Regards  Bayo  adebayo omo-dare [EMAIL PROTECTED] wrote:There is the very greatpossibility that employing TDMoE in this environment will introduce new levels of complexity in to the network.And though TDMoE,initself, isfantastic, IMHO- long haultechnology,it may also be considered to be out of scope and limiting/expensive, most especially considering he already employs the type of network many dream of.In terms of distributing inward
 boundPRI calls acrossthe two sites, your telecom company takes care of those details and forwards calls to the other when the former is seen to be busy. [They possibly call this something like Diversion/Forwarding on Busy] - speak to your provider.In terms of distributing outgoing VoIP-PRI-PSTN calls - Off the top of my head, and there may/should be much better ways,you may/should be able to introduce a global count variable and a GotoIf(...) in the dial plan.Hope this, in some manner, helps  BayoMassimiliano Stucchi [EMAIL PROTECTED] wrote:On 200906, 16:00, Forrest Beck wrote:  I am looking to see if anyone has a dial plan setup to use a secondary PRI. We have two campuses, each with it's own
 PRI (for telco going to a single span digium card) and a 10MB fiber link between the two for data. All calls are transfered between the two campuses via the 10MB data line and outgoing calls are made on the campus'es PRI. I am loking to see if there is a way to tell the server if one PRI is full (all 23 channels are in use) or not available to try routing the call through the other campus and it's PRI. Anyone doing this already? I am not sure how to have asterisk check to see if a PRI is down for making the call. I guess I could just add the call route to the other campus just below the my default call route. So if the primary call route fails, it will just go to the next line being the other campus.I would try using TDMoE, and duplicating the PRIs over the two machines,so that:Machine 1 handles PRI A and has B as, say group2Machine 2 handles PRI B and has A as, say
 group2I don't know if you can run TDMoE over your fiber connection, but I wasjust here for a suggestion.Ciao-- Massimiliano Stucchi, CTO  Director of OperationsWillyStudios.com - IT Consulting, Web and VoIP Services[EMAIL PROTECTED] | Tel (+39) 0244417203 | Fax (+39) 0244417204IT-20040, Carnate (Milano), via Carducci 9___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:http://lists.digium.com/mailman/listinfo/asterisk-users  All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC
 Magazine___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:http://lists.digium.com/mailman/listinfo/asterisk-users 
		 
Try the all-new Yahoo! Mail . "The New Version is radically easier to use" – The Wall Street Journal___
--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

Re: [asterisk-users] PRI Backup

[adebayo omo-dare]

I don't know if this may at sometime help mr Wood, but BT, with their ISDN30* actually offer something called Site Assurance - the problem is that it does not automatically fail over, and according to the last memo I read - failover takes about 1 hr.A problem is that,due to outsourcing, product ranges, size issues, etc, a lot of people on BT's frontline are not really keyed up to their product offerings. Who knowns, maybe the failover process has been automated at this point in time.  Conrad Wood [EMAIL PROTECTED] wrote:  making the call. I guess I could just add the call route to the other campus just below the my default call route. So if the primary call route fails, it will just go to the next line being the other
 campus.That's precisely what I do with the main route out on ISDN, if that fails, it switches over to various voip providers and even down to a bluetooth enabled mobile ;).it works quite allright for outgoing calls.I believe for incoming calls you need to persuade your isdn supplier do forward the call to ISDN-B if ISDN-A is hosed.Here in UK I couldn't persuade BT to do so yet ;(Conrad___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:http://lists.digium.com/mailman/listinfo/asterisk-users 
		 
All New Yahoo! Mail – Tired of [EMAIL PROTECTED]@! come-ons? Let our SpamGuard protect you.___
--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

Re: [asterisk-users] When does Scalability requests Asterisk to U se SER ?

[adebayo omo-dare]

Hi Sheerwood,   I unfortunately saw a bit of what I percieve to be an error in what you said. BerkeleyDB does in fact support replication across nodes - see: http://www.sleepycat.com/docs/ref/rep/intro.html- possibly you meant to say the version implemented in * does not support replication. If so, I do appoligise for beinga little pedantic.I have only just started to look at *'s code - so what I say further is with a great deal of hesitation when directly referenced to *. However, I work with both Berkely (on a programming level)and MySQL in a telecom (soft-switch) environment.In terms of performance (judged as speed), a comparison between MySQL and Berkeley would be like comparing a top of the range Mercedes to an F1 racing car. Overheads from MySQL come in the form of SQL translation, use of Sockets, etc... This
 is in addition to its size.Yet, the choice between the two, is a lot more complex, IMHO, than mereley thinking in terms of performance. And possible High Availability solutions, in their own rights, taking in to consideration that * will be workingin concert with numerous otherenvironments,programmes and requirments,are diverse enough to make each deployment a little unique - thereby making each option a potential liability.One rule of thumb for us has always been - if you need raw speed, and intend to deal with the data in a very restricted/rigid/"well defined"manner - opt for Berkeley. But if you want a great deal of fluidity, and intend, or may at some time intend,for that data to interact with other applications and potential requirements -Opt MySQL.It is possibly also best to work with what you feel most comfortable with first and
 then experiment to see if you may require the services of the other.ps. In terms of querying a DB for every call, I would presume that a DB is an active and fragilething and the provision of ACID ensures that everything that occurs with it does sowith a certain measure of safety. In fact, due to the random manner of requests, you will find it, in complete terms,actually performs a lot better than any other form of retrieval.Hope this, in some manner,helps  Bayo  Rushowr [EMAIL PROTECTED] wrote:   good stuff mate.  a few clarifications: you had static "extensions.conf", realtime "sipusers", etc, right?  Also, abt features like call fwding, etc, which one is better, performance
 wise, using a mysql db, or use Asterisk's internal DB(berkeley db, isnt it?using those DBput n DBget ops)??Anyone's got any figures for these?  This somewot spoils the fun in Asterisk, when talking of performance, to query the DB for every call . Sort of pulls things down. Any comments or observations guys?  - Ben.Ben,Yes, static extensions.conf, realtime everything else. A realtimedialplan never made much sense to me, as the dialplan shouldn't (in myhumble opinion) be that fluid anyway, it should be fairly static.In terms of spoiling the fun and/or performance issues, let me note thatin my current implementation we not only have options being queried butalso realtime billing, permissions, limits, and carrier/trunkperformance data, all being pulled and calculated via the database. Ialso have handy little timers returning the length of time it takes todo the
 processing from request receipt to dial, and I'm still currentlyunder 1-2 seconds for entire call preparation including all the logicthat goes along with checking all features, the current account'saccount status, balance and limits, AND all parent accounts in it's"billing chain". I haven't done a head to head with the berkley DB, butI think part of the reason it's so fast is due to the highly normalizeddatabase structure, which allows for efficient query design. It's notall third form, but almost there :D.I'm in the last days of ALPHA now with my current project. Once welaunch BETA, which will be a semi-public testing by invitation (Murph,you still going to participate?), I should be able to find a few minutesto outline the design.One other quick thing, the berkley DB doesn't allow for clusteringeither, MySQL does. Very nice to have your database distributed acrossmultiple nodes, makes for an easier time
 designing the failovers :DCheers,Sherwood___--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:http://lists.digium.com/mailman/listinfo/asterisk-users 
		 
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail.___
--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

Re: [asterisk-users] Max Size of Conf Files

[adebayo omo-dare]

Think of BerkeleyDB as abarebones embedded RDBMS. It carries the much the same functionality (such as ACID) as most Relational DBs but without overhead (such as SQL translation) - for many years it formed (possibly still forms - not sure of present) the core of MySQL.Steve Totaro [EMAIL PROTECTED] wrote:  I guess I will give it a try. The numbers are pretty much static in the way they are routed.I just did not know if Asterisk would choke on a conf file with a couple thousand lines.Thanks,StevepicciuX wrote: don't know for conf size limitation (but i guess it won't be a problem  with a well-sized machine). About asking on the fly vs writing on change: if your "routing  information" varies very often, on the fly should make more sense. 
 Otherwise, it's not useful to retrieve continually same data: better  to write it down everytime it changes. Think 1000 numbers are not so  much, though i've no experience about that. HopeThisHelps 2006/9/11, Steve Totaro <[EMAIL PROTECTED]  : I have almost 1,000 800 numbers that are routed any number of ways. Currently I call on fastagi which checks a database and returns the extension or route that DID is supposed to take. The DIDs are all over the place as far as sequence, so pattern matching is out of the question. My question is, is there a max file size for a conf file? Will defining the routing for each of the 1,000 DIDs in extensions.conf effect performance or eat up huge amounts of RAM? I assume these numbers get inserted into the
 BerkleyDB at startup and reload, can it handle it? Any other pros or cons to still having a database, but instead of fastagi asking for an exten on the fly, the database writes the conf file only when routing is changed or toll free numbers are added? Thanks, Steve Totaro __--Bandwidth and Colocation provided by Easynews.com --asterisk-users mailing listTo UNSUBSCRIBE or update options visit:http://lists.digium.com/mailman/listinfo/asterisk-users 
		 
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.___
--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