Hi all, I have read a lot about * server redundancy, however I still don't know how to do it. Can any of you give me any advise? For example, I've read about ranchnetworks appliances but don't know if it will solve my problems. As you may guess, I need to have two servers with the same information (including configuration, cdrs and logs). Of course, If a server fells down I would like the IP Phone to register with the other server. Can I do that?, do I need a third server?, other appliances? Alejandro Acosta,
Alejandro, doesn't sound like you've read up or done research on ARA (Asterisk Realtime Architecture)? That's what allows you to build asterisk server clusters which draw upon configs either for individual config files OR entire family of processes froma common database (which can then be made redundant/clustered). All examples on the net are based on using MySQL But it's possible to use other drivers in conjunction with the ODBC engine that Asterisk uses to integrate oracle and/or MSSQL to store CDRs and Voicemail. These two can also be stored on a common clustered file system such as GFS or PVFS etc. So all in all, you can deploy ARA along with RedHat CSGFS (built from source, of course) and come up with a fully redundant realtime asterisk cluster. Hope this helps, Cheers \R
Asterisk realtime hardly provides redundancy. 1. There's no support for realtime SIP where multiple Asterisk systems can reference the same MySQL database for SIP peers. Ask Kevin Fleming about this. It's known not to work. 2. The IP address of the MySQL server is hard coded into the Asterisk config files. In the event of a database failure, Asterisk fails as well. You need to build redundancy into MySQL with a primary and seconday server, and something that can monitor MySQL system, network, and application and then transparently (to Asterisk, because it can't do it itself) switch IP's in the event of failure. 3. Other stuff I can't recollect right now because I am tired. -----Original Message----- From: RR [mailto:ranjtech@gmail.com] Sent: Mon 7/10/2006 9:16 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: Subject: Re: [asterisk-users] Server redundancy Alejandro, doesn't sound like you've read up or done research on ARA (Asterisk Realtime Architecture)? That's what allows you to build asterisk server clusters which draw upon configs either for individual config files OR entire family of processes froma common database (which can then be made redundant/clustered). All examples on the net are based on using MySQL But it's possible to use other drivers in conjunction with the ODBC engine that Asterisk uses to integrate oracle and/or MSSQL to store CDRs and Voicemail. These two can also be stored on a common clustered file system such as GFS or PVFS etc. So all in all, you can deploy ARA along with RedHat CSGFS (built from source, of course) and come up with a fully redundant realtime asterisk cluster. Hope this helps, Cheers \R _______________________________________________ --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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 5082 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20060710/5c5a2874/attachment.bin
DUNDi doesn't provide good redundancy for phone registrations. Each phone is only registered on a single, primary Asterisk system. In the event that the primary system for a given phone becomes available, the phone will not re-register until it's registraiton expirey period, on it's secondary Asterisk system. During this time, the phone cannot be reached. You can cut the phone registration period right down, to some small period of time, say 5min, but is that acceptible? Also, keep in mind that the lower the registration period, the greater the number of registrations, and therefore the greater the network traffic, and hence, the load on each Asterisk system. Doug. -----Original Message----- From: RR [mailto:ranjtech@gmail.com] Sent: Mon 7/10/2006 10:09 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: Subject: Re: [asterisk-users] Server redundancy unplug, thanks for pointing that out as well as opposed to or in complement with ARA where you can either implement DUNDi between clusters of Asterisk servers or have a redundant pair of DUNDi lookup servers (just like DNS) somewhere remote to the local asterisk servers. DUNDi is a p2p IAX based protocol to allow for looking up contact information for a particular registered extension. So in ARA you can really store all extension based information in the common database for servers that are local to your network i.e. perhaps on the same private network or even the same VLAN. Then implement DUNDi between asterisk servers that are remote to your location and in their own private network using their own database. Not sure the level of reliability one can expect using the public internet for DUNDi look-ups from a server on the other end of the world but in theory it might be do-able. So if you can't find an extension within your local database, you perform the DUNDi lookup and find it in your remote servers. I'm sure the gurus on the list might have plenty to say on this :) _______________________________________________ --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
> -----Original Message----- > From: RR [mailto:ranjtech@gmail.com] > Sent: Tuesday, July 11, 2006 12:45 AM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Server redundancy > > > Interesting points on both messages > > 1) as far as multiple asterisk servers talking to the same database is > concerned, I will have to test this out. I know nothing about the > database side of things, and a newbie on asterisk and linux so I have > no idea what and where the development of either of these are. From > your message it sounds like it's just how ARA is designed because I > doubt it's to do with the ODBC driver itself. This will cause me a lot > of grief if you're right about this for multiple * servers to not be > able to access the same database for peer lookup.Be prepared for some grief then! :)> > 2) Clustering of DB isn't an issue, not for me at least. Haven't > tested this either but my DBs are clustered A/P providing a single > entity to the internal systems. Might further look into a local DNS > lookup to add to this. I believe it's possible to do this in the MySQL > world with MySQL grid etc? > > 3) I don't believe frequent registration is that big of an issue for > the network load it generates. Most providers out there set devices > for a 30-40secs Reg. Refresh to support NAT'ed endpoints and the a reg > refresh is hardly about 300-400Byte pkts (I think). The math doesn't > add up for a major load esp. if you've got a load balancing mechanism > in front of your * boxes.OMG. 30-40seconds? That's insane. We're planning on provisioning 16,000 users on our system. With a registration period of 40s, that's an average of over 400 registrations per second. Actually, it could be over 800 per second, as I think phones re-reregister at half their expirey period.> > 4) I don't know enough about DUNDi to get into this discussion but > DUNDi just lookup extensions? or it also have any part to play in > registrations? If they just do extension lookup, then If DUNDi is > implemented on an A/P pair of dedicated DUNDi lookup servers which > access a clustered database, then barring #1 being true, each * server > accesses the same database and pool of registrations. If registrations > are refreshed frequently enough, the contact info in the database will > always be current and one server dying won't affect anything. At the > same time, they just consult the DUNDi lookup server for extension > lookups instead of asking the database directly.DUNDi can only lookup the extensions (ie phones) if they are registered. If they aren't registered on any system in the DUNDi peering arrangement, then DUNDi wouldn't return a path to their location... until the phones re-reregister.> > 5) If you really want to improve on this, supplement your network with > SER as proxies and have them deal with Registrations and load-balance > feature requests to * servers etc. Once * has done whatever it needs > to do (e.g. provide PBX features, voicemail, conference, IVR etc.) it > passes the call back to the Proxy to deal with the endpoints.Not as simple as it sounds. So, if the SER boxes handle registrations, how do they propogate this information back to Asterisk? If you don't propogate the information back to Asterisk, then you have to route all dialling from Asterisk back to SER. This causes problems withn certain applications like the Queue command, that as far as I know, can't work with this. There's probably more too. You also have to keep call transfer and call forward in mind. When transferring a call, if you pass the call from Asterisk over to SER for some reason, it has to come back to the same Asterisk box to handle the transfer, Asterisk will puke.> > All depends on your scope and budget. If you want to have a SP grade > service then you need to breakout your functions. > > I just hope #1 isn't true though. The only alternative then would be > to have /etc/asterisk reside on an NFS share or a CFS for all servers > to read massively huge conf files if you're catering for large number > of endpoints. > > Dunno if it helps anyone or I'm just shooting sh*t ;) > _______________________________________________ > --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 >
I think it can listen either on a specific address, or on ALL addresses, not on a subset of available addresses.> -----Original Message----- > From: Aaron Daniel [mailto:amdtech@shsu.edu] > Sent: Tuesday, July 11, 2006 2:38 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Server redundancy > > > On Tue, 2006-07-11 at 14:34 -0400, Mike Lynchfield wrote: > > #3b.. we need multiple listening addies.. since asterisk can only > > listen to one ip its sucks for now > > Incorrect. > > Asterisk most definitely listens on multiple interfaces. We've got > several asterisk boxes that are multi-homed... one public and one > private interface, so that we can have external phones and internal > phones. Works fine. > > I'm thinking this is a misconception. We even have heartbeat > set up to > switch ip's around. The server actually listens on the fly to the new > ip address that comes up under it. > > -- > Aaron Daniel > Computer Systems Technician > Sam Houston State University > amdtech@shsu.edu > (936) 294-4198 > _______________________________________________ > --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 >
Assuming a standard usage rate of 10-15%, that's 2,400 concurrent users. If you divide that by 120, that's about 20 Asterisk systems. We're no where near that yet, and we only have three systems up right now. Gotta start somewhere! -----Original Message----- From: unplug [mailto:maillisting@gmail.com] Sent: Tue 7/11/2006 7:23 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: Subject: Re: [asterisk-users] Server redundancy I feel interested about you can support 16,000 users of your system. As I have tested using sipp in a dual CPU Xeon with 2G Ram, the maximum number of current call is about 160. In some forums, most of ppl claim the maximum current call is about 100-200. What do you expect the number of current call to handle in 16,000 users? On 7/11/06, Douglas Garstang <dgarstang@oneeighty.com> wrote: > > -----Original Message----- > > From: RR [mailto:ranjtech@gmail.com] > > Sent: Tuesday, July 11, 2006 12:45 AM > > To: Asterisk Users Mailing List - Non-Commercial Discussion > > Subject: Re: [asterisk-users] Server redundancy > > > > > > Interesting points on both messages > > > > 1) as far as multiple asterisk servers talking to the same database is > > concerned, I will have to test this out. I know nothing about the > > database side of things, and a newbie on asterisk and linux so I have > > no idea what and where the development of either of these are. From > > your message it sounds like it's just how ARA is designed because I > > doubt it's to do with the ODBC driver itself. This will cause me a lot > > of grief if you're right about this for multiple * servers to not be > > able to access the same database for peer lookup. > Be prepared for some grief then! :) > > > > > 2) Clustering of DB isn't an issue, not for me at least. Haven't > > tested this either but my DBs are clustered A/P providing a single > > entity to the internal systems. Might further look into a local DNS > > lookup to add to this. I believe it's possible to do this in the MySQL > > world with MySQL grid etc? > > > > 3) I don't believe frequent registration is that big of an issue for > > the network load it generates. Most providers out there set devices > > for a 30-40secs Reg. Refresh to support NAT'ed endpoints and the a reg > > refresh is hardly about 300-400Byte pkts (I think). The math doesn't > > add up for a major load esp. if you've got a load balancing mechanism > > in front of your * boxes. > OMG. 30-40seconds? That's insane. We're planning on provisioning 16,000 users on our system. With a registration period of 40s, that's an average of over 400 registrations per second. Actually, it could be over 800 per second, as I think phones re-reregister at half their expirey period. > > > > > 4) I don't know enough about DUNDi to get into this discussion but > > DUNDi just lookup extensions? or it also have any part to play in > > registrations? If they just do extension lookup, then If DUNDi is > > implemented on an A/P pair of dedicated DUNDi lookup servers which > > access a clustered database, then barring #1 being true, each * server > > accesses the same database and pool of registrations. If registrations > > are refreshed frequently enough, the contact info in the database will > > always be current and one server dying won't affect anything. At the > > same time, they just consult the DUNDi lookup server for extension > > lookups instead of asking the database directly. > DUNDi can only lookup the extensions (ie phones) if they are registered. If they aren't registered on any system in the DUNDi peering arrangement, then DUNDi wouldn't return a path to their location... until the phones re-reregister. > > > > > 5) If you really want to improve on this, supplement your network with > > SER as proxies and have them deal with Registrations and load-balance > > feature requests to * servers etc. Once * has done whatever it needs > > to do (e.g. provide PBX features, voicemail, conference, IVR etc.) it > > passes the call back to the Proxy to deal with the endpoints. > Not as simple as it sounds. So, if the SER boxes handle registrations, how do they propogate this information back to Asterisk? If you don't propogate the information back to Asterisk, then you have to route all dialling from Asterisk back to SER. This causes problems withn certain applications like the Queue command, that as far as I know, can't work with this. There's probably more too. You also have to keep call transfer and call forward in mind. When transferring a call, if you pass the call from Asterisk over to SER for some reason, it has to come back to the same Asterisk box to handle the transfer, Asterisk will puke. > > > > > All depends on your scope and budget. If you want to have a SP grade > > service then you need to breakout your functions. > > > > I just hope #1 isn't true though. The only alternative then would be > > to have /etc/asterisk reside on an NFS share or a CFS for all servers > > to read massively huge conf files if you're catering for large number > > of endpoints. > > > > Dunno if it helps anyone or I'm just shooting sh*t ;) > > _______________________________________________ > > --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 > > > _______________________________________________ > --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 > _______________________________________________ --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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 8862 bytes Desc: not available Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20060711/825e02f7/attachment.bin
For redundancy on the PRI side, we plug our PRIs into Redfone Networks' foneBRIDGE boxes. They've worked quite well for us. As others have stated, use short registration periods combined with some HA software to handle your SIP redundancy. You might also look into load-balancing SER proxies. On 7/10/06, Alejandro Acosta <alejandro.acosta@comsat.com.ve> wrote:> Hi all, > I have read a lot about * server redundancy, however I still don't know > how to do it. Can any of you give me any advise? > For example, I've read about ranchnetworks appliances but don't know if it > will solve my problems. > As you may guess, I need to have two servers with the same information > (including configuration, cdrs and logs). Of course, If a server fells down > I would like the IP Phone to register with the other server. > > Can I do that?, do I need a third server?, other appliances? > > Alejandro Acosta, > > > > > _______________________________________________ > --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 >
On Jul 11, 2006, at 2:27 AM, Olivier Saulnier wrote:> Hello, > > Sometimes, when i call an outside people, he said me that the > communication is bad: > The voice is low, far, bad poor quality. > How can i know where is the problem, which tests can i make? >Make sure the string is tight between the two tin cans. But seriously you might try actually giving us some info if you want help?