What with the NANOG list being flooded with news about the flood (http://www.datacenterknowledge.com/archives/2009/08/07/water-main-break-at-k...), I figured it'd be a good time to ask.... Has anyone really solved the whole config sync and operational failover issues to provide full geographic redundancy for a hosted voip network? Failing over TDM DS3s, SS7, IP, SIP, voicemail, IVR programming, etc, such that there is no user-observable indication that failover occured between two calls is the big goal. Thanks, David This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
Silence? Yeah, that's about what I thought I'd get. It's probably on everyone's list, but it's a pretty tough nut to crack... I wonder if this topic isn't big enough to merit some sort of focus group. Is kind of planning on anyone's plate now? Thanks, David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Hiers, David Sent: Friday, August 07, 2009 8:14 AM To: voiceops at voiceops.org Subject: [VoiceOps] Geographic redundancy What with the NANOG list being flooded with news about the flood (http://www.datacenterknowledge.com/archives/2009/08/07/water-main-break-at-k...), I figured it'd be a good time to ask.... Has anyone really solved the whole config sync and operational failover issues to provide full geographic redundancy for a hosted voip network? Failing over TDM DS3s, SS7, IP, SIP, voicemail, IVR programming, etc, such that there is no user-observable indication that failover occured between two calls is the big goal. Thanks, David ________________________________ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
On Tue, 11 Aug 2009, Hiers, David wrote:
Silence? Yeah, that's about what I thought I'd get. It's probably on everyone's list, but it's a pretty tough nut to crack...
We are doing it today with our setup, we have east and west coast with our BroadWorks cluster, OSS systems, Video Conference Systems, voicemail, data shares are split. Not all of our NOC systems are fully redundant yet, but as far as our services we are redundant.
<> Nathan Stratton CTO, BlinkMind, Inc. nathan at robotics.net nathan at blinkmind.com http://www.robotics.net http://www.blinkmind.com
Failing over SS7 and TDM switches as you know is pretty nontrivial. Maybe it's easy if you just gate TDM to IP, but if you have TDM switches you're probably doing other things with them that require a certain proximity to your customer, and the more longhaul you depend on, the higher the risk of backhoe fade between you and your customer. I've got some ideas for how to crack the nut of keeping an SS7 voice network up, but they're expensive and require a 1:1 overlay on capacity and the actual cutover is likely to distract our technicians from restoring the actual production site, which is also our offices. Likewise with the data networks, I'd have a lot of idle gear I can't monetize, and capacity I have to overbuild and not use. I've been gravitating toward the ILEC model of just spreading the equipment out so it's closer to the end users, so any failure only affects a small segment, that depending on what caused the failure, may not care that you're down (tornados, severe wind damage, flooding, nuclear strike). Unless there's something obvious I'm missing here, of course. -Paul Hiers, David wrote:
Silence? Yeah, that?s about what I thought I?d get. It?s probably on everyone?s list, but it?s a pretty tough nut to crack?
I wonder if this topic isn?t big enough to merit some sort of focus group. Is kind of planning on anyone?s plate now?
Thanks,
David Hiers
CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277
*From:* voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Hiers, David *Sent:* Friday, August 07, 2009 8:14 AM *To:* voiceops at voiceops.org *Subject:* [VoiceOps] Geographic redundancy
What with the NANOG list being flooded with news about the flood (http://www.datacenterknowledge.com/archives/2009/08/07/water-main-break-at-k...), I figured it'd be a good time to ask....
Has anyone really solved the whole config sync and operational failover issues to provide full geographic redundancy for a hosted voip network? Failing over TDM DS3s, SS7, IP, SIP, voicemail, IVR programming, etc, such that there is no user-observable indication that failover occured between two calls is the big goal.
Thanks,
David
------------------------------------------------------------------------
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
------------------------------------------------------------------------ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Seems to me like one of the main arguments for moving to IP infrastructure - alongside the numerous arguments telco people have against it - is that it makes this type of redundancy a lot more achievable and cost-effective. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
Yes IP makes it easier but you still have to 'plugin' to the PSTN somewhere and in some fashion correct? Unless you have nothing but SIP peering it does get a little more complicated (although I'm new to the VoIP world and do not know SS7). Then you still have to worry about your call processing platform: can it live with being greater than x ms apart from it's redundant pair? What about CDR's and reporting - how do you merge those coming from multiple sources? I would think there's also rate center and latency issues as well with outbound routing of calls (send calls out the cheapest carrier that will allow it). I don't think any of it's impossible, but the presence of IP doesn't remove all complexity. I like David's idea of a VoiceOps working group to help define options. Sounds like fun Kenny On Tue, Aug 11, 2009 at 7:23 AM, Alex Balashov <abalashov at evaristesys.com>wrote:
Seems to me like one of the main arguments for moving to IP infrastructure - alongside the numerous arguments telco people have against it - is that it makes this type of redundancy a lot more achievable and cost-effective.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I didn't say that the presence of IP removes all the complexity, nor that interconnection without TDM and/or SS7 is possible--at least, for CLECs, but also many ITSPs that buy TDM in order to do access that is actually reliable and interoperable. My intended point, which should have perhaps been made clearer, was only that the use of more IP - where feasible and practical - in the place of a circuit-switched alternative can add fluidity to the network that can change the CAPEX formula for redundancy in a more favourable direction. It's not magic and it certainly won't solve all the problems that motivate the original question. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
My 'tone' in email is somtimes misinterpreted (so sorry about that) - I was just 'thinking out loud' as I like to put it. One thing you did mention is that telco's don't like the move to IP - what are their arguments against it? On Tue, Aug 11, 2009 at 7:39 AM, Alex Balashov <abalashov at evaristesys.com>wrote:
I didn't say that the presence of IP removes all the complexity, nor that interconnection without TDM and/or SS7 is possible--at least, for CLECs, but also many ITSPs that buy TDM in order to do access that is actually reliable and interoperable.
My intended point, which should have perhaps been made clearer, was only that the use of more IP - where feasible and practical - in the place of a circuit-switched alternative can add fluidity to the network that can change the CAPEX formula for redundancy in a more favourable direction.
It's not magic and it certainly won't solve all the problems that motivate the original question.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
Kenny Sallee wrote:
One thing you did mention is that telco's don't like the move to IP - what are their arguments against it?
The first argument from the ILECs is a generic one, but possibly the most important: They have very significant revenue streams, capital investments, institutional knowledge and training, business processes, technology stacks, etc. associated with TDM infrastructure that they want to protect. They already paid (a lot) for them, so they want to squeeze every last bit of ROI possible from them. Nobody likes expensive stuff to become obsolete, especially on a large scale. The second big argument generally has to do with the lack of reliability of IP gear and IP networks compared to their older, single-purpose synchronous cousins. This is generally justifiable; they've had a lot longer to get TDM right, and the vendors that do TDM well have done so for a while. The ecosystem of commercial IP gear is inherently a lot more 'open' and heterogenous, even though it may not seem like that in the enterprise network hardware segment. Without proper steps to mitigate it, which are the sorts of steps younger people have more time for, a rogue PC on the network can impact your voice service. The argument I usually hear is, "And if the Ethernet goes down, our (IP-based) softswitch service is down too. But if I keep it TDM for as long as possible and drag it into the core that way, phone will still be up." Probably, but I'm not sure it's Paereto-optimal solution. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
If the PSTN could overnight switch from TDM to IP, everyone would be much happier for it; there's a lot of pain and expense going back and forth between SS7, IP, wireless, and even older stuff like FG-D. Unfortunately, we have a long, painful transition to undergo: * On the technology side, carriers have to update, upgrade, replace, and some time just trash existing (expensive) hardware infrastructure of all different flavors. There's a lot of money involved there. * On the business side, carriers have to figure out how to convert their inter-carrier billing and revenue agreements that are all based on channel and CPM models into...whatever exactly it is that's going to replace it. And like it or not, all of the upstarts are leveraging (or just taking advantage of) a model that allows them to exist at the expense of the incumbents so those who stand to lose their revenue base are understandably dragging their feet. * On the regulatory side, the regulations have to be adapted to account for new forms of telephony and distribution, and these things change very slowly because politics is involved. To add injury to the process, states and localities derive revenue from the taxable transactions. So if those taxes go away...something has to replace it. We all know how easy it is to raise taxes in this current environment so you can figure on some real pain there. * New carrier technology (cable and FIOS) which is not currently open to competition is creating an interestingly skewed playing field as some areas get a ton of new investment (most suburban and some urban areas) while others (largely poor and rural) get skipped. Nobody really knows how these things are going to change, but there's a lot of really nervous people all across the incumbent and mature CLEC space as they try to adapt their technology, processes, workforces, and other stuff to meet the perceived demand. Cheers, David. ------------------------------------------------------------------------ Kenny Sallee wrote:
My 'tone' in email is somtimes misinterpreted (so sorry about that) - I was just 'thinking out loud' as I like to put it.
One thing you did mention is that telco's don't like the move to IP - what are their arguments against it?
On Tue, Aug 11, 2009 at 7:39 AM, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote:
I didn't say that the presence of IP removes all the complexity, nor that interconnection without TDM and/or SS7 is possible--at least, for CLECs, but also many ITSPs that buy TDM in order to do access that is actually reliable and interoperable.
My intended point, which should have perhaps been made clearer, was only that the use of more IP - where feasible and practical - in the place of a circuit-switched alternative can add fluidity to the network that can change the CAPEX formula for redundancy in a more favourable direction.
It's not magic and it certainly won't solve all the problems that motivate the original question.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Kenny, A number of different options exist for redundancy, but they all depend on your underlying network architecture and connectivity options. The newest switches tend to have call agents and media gateways that are separate, so you can have redundancy across your hardware and call control geographically. Some older switches are more monolithic, so you have more redundancy in your network since that has to survive more. You also find the world changes pretty dramatically when you go from Asterisk (which I use generically to refer to any small-scale solution of under 2k endpoints or so) to Big Iron - you pay a lot more money for all sorts of redundancy and scalability, and as a result you solve problems very differently (and have different options to solve problems). Right now Asterisk can't exist without the big iron (5E, MetaSwitch, Broadsoft, etc.) because it can't handle the call routing, SS7 interop, etc. One can think of the smaller VoIP providers as basic class 5 switches providing the traditional end-user connectivity and not worrying about the bigger issues that will bedevil people as they head into the interconnection world. If you can split your call control and media between geographical locations, then you can set up as a CLEC in two colocations, and interconnect to the necessary tandems to exchange traffic with two unrelated circuits, and then have lots of room to lose one half of your network without affecting core call control (how you get to your customers is a different problem, of course). Switches can also function in an emergency-standalone world as well. SS7 already has all of the redundancy options via multiple A-links to the outside world. I don't believe it's possible to interconnect with IP anywhere as a CLEC since the PSTN infrastructure doesn't exist outside of the SS7 environment for all practical purposes. (Obviously, you can peer with IP but that's not the same as interconnection from a PSTN perspective). If you can't split your call control, then you use SONET and other self-healing architecture to buttress your network as much as possible against fiber cuts, MUX outages, and other crashes with the hope that you never lose both ends of your ring at the same time. Cheers, David. ------------------------------------------------------------------------ Kenny Sallee wrote:
Yes IP makes it easier but you still have to 'plugin' to the PSTN somewhere and in some fashion correct? Unless you have nothing but SIP peering it does get a little more complicated (although I'm new to the VoIP world and do not know SS7). Then you still have to worry about your call processing platform: can it live with being greater than x ms apart from it's redundant pair? What about CDR's and reporting - how do you merge those coming from multiple sources? I would think there's also rate center and latency issues as well with outbound routing of calls (send calls out the cheapest carrier that will allow it). I don't think any of it's impossible, but the presence of IP doesn't remove all complexity.
I like David's idea of a VoiceOps working group to help define options. Sounds like fun Kenny
On Tue, Aug 11, 2009 at 7:23 AM, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote:
Seems to me like one of the main arguments for moving to IP infrastructure - alongside the numerous arguments telco people have against it - is that it makes this type of redundancy a lot more achievable and cost-effective.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
David Birnbaum wrote:
I don't believe it's possible to interconnect with IP anywhere as a CLEC since the PSTN infrastructure doesn't exist outside of the SS7 environment for all practical purposes. (Obviously, you can peer with IP but that's not the same as interconnection from a PSTN perspective).
Sure it is. That's basically what SIGTRAN is; SS7 mapped onto IP. I don't know if VeriSign still offers their interconnection product (forget what it was called), but it used to be until very recently that you could get them to take your point codes and send you the signaling out the back side as SIGTRAN, over Internet VPN. I've seen many DIY switches built that way, usually for cheap CLECs created to support the back side of some VoIP product who don't want to shell out for a real switch. Common technique there is to purchase a SIGTRAN to H.248/MEGACO and/or MGCP signaling gateway and drive media gateways with that controller. So, your physical bearer IMTs can come from the local ILEC to your MGWs but your SS7 can come from somewhere else over the Internet indirectly. Squire makes a product that does this (http://www.squire-technologies.co.uk/), and I'm sure there are others. Last I heard none of them do TCAP/LNP yet, though, which is obviously going to be something of a crippling factor if you're interconnecting in a pooling area (most markets at this point). And I understand them to have other problems, as well. Nevertheless, it is possible. Level3 famously built their own signaling gateway for the Lucent TNT Max via H.248 in their pre-Viper platform, although I do not know whether the other side of that was SS7 or ISDN Q.931 or whatnot. But it did work. -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
I think perhaps we're using "interconnection" differently. Obviously, you can SIP peer and "interconnect" via various IP<->SS7 gateways for the purposes of exchanging signaling traffic. As you point out, there's a whole pile of technologies available with various pros and cons. However, if you want to connect directly to the tandems for the purposes of owning number blocks, registering an LRN, porting numbers natively, etc. there is no way to do that with IP. If you buy media gateways to do the TDM -> IP conversion, then you are now in the TDM world with all that implies; I don't prejudice against running an "IP backplane" with distributed media gateways vs. a more traditional DMS or 5E. That's how I run my network, after all, but that's semantics from the PSTN perspective. One man's "media gateway" is another man's switch. The SS7 call control and the PSTN interconnection are already separate. If you peer with another carrier who does the IP/TDM interconnection at the tandems on your behalf, you are still beholden to the actual CLEC that owns your numbers. To me, that's the true difference (which is both technical as well as regulatory) between a CLEC and a facilities-based reseller. This may change at some point (actually, I'm sure it WILL change at some point) but that's at least a couple of years out, I'm guessing. Cheers, David. ----- On Wed, 12 Aug 2009, Alex Balashov wrote:
David Birnbaum wrote:
I don't believe it's possible to interconnect with IP anywhere as a CLEC since the PSTN infrastructure doesn't exist outside of the SS7 environment for all practical purposes. (Obviously, you can peer with IP but that's not the same as interconnection from a PSTN perspective).
Sure it is. That's basically what SIGTRAN is; SS7 mapped onto IP.
I don't know if VeriSign still offers their interconnection product (forget what it was called), but it used to be until very recently that you could get them to take your point codes and send you the signaling out the back side as SIGTRAN, over Internet VPN.
I've seen many DIY switches built that way, usually for cheap CLECs created to support the back side of some VoIP product who don't want to shell out for a real switch. Common technique there is to purchase a SIGTRAN to H.248/MEGACO and/or MGCP signaling gateway and drive media gateways with that controller. So, your physical bearer IMTs can come from the local ILEC to your MGWs but your SS7 can come from somewhere else over the Internet indirectly.
Squire makes a product that does this (http://www.squire-technologies.co.uk/), and I'm sure there are others. Last I heard none of them do TCAP/LNP yet, though, which is obviously going to be something of a crippling factor if you're interconnecting in a pooling area (most markets at this point). And I understand them to have other problems, as well. Nevertheless, it is possible.
Level3 famously built their own signaling gateway for the Lucent TNT Max via H.248 in their pre-Viper platform, although I do not know whether the other side of that was SS7 or ISDN Q.931 or whatnot. But it did work.
-- Alex
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
David Birnbaum wrote:
I think perhaps we're using "interconnection" differently.
Yeah; perhaps connection to ILEC tandems should be deemed Interconnection with a capital I. :-) A lot of ITSPs that don't actually touch the LEC side of things don't know this, so, you're absolutely right. Peering is exchanging traffic with another carrier in some sort of bidirectional settlement arrangement explicitly for that purpose (analogous to settlement-free IP peering, but not necessarily settlement-free as we know - recip. comp. and all that), and access is buying origination or termination from another carrier. Access is really what ITSPs as well as CLECs buying inter-LATA LD from IXCs do. If you're a VoIP provider and buy VoIP or TDM trunks from a CLEC, you're buying access; you're not on horizontal footing with them, you're not a "peer" - you're a customer. Peering, I think, should be reserved for CLECs that connect to each other for the purpose of passing traffic directly and getting around the Bell tandems.
However, if you want to connect directly to the tandems for the purposes of owning number blocks, registering an LRN, porting numbers natively, etc. there is no way to do that with IP.
Well, it depends on what is meant by "directly." One could argue that there's nothing "indirect" about taking SIGTRAN from a third party. You still signal ISUP and/or TCAP, just over IP. The only difference is that the physical A-links aren't coming to you and that your point codes are physically homed somewhere else. The switch CLLI and the accompanying LRNs and number blocks and so on are still pointing to your equipment; you can port numbers natively, do LNP dips natively, etc. It's just that there's a network element in the middle doing some protocol conversion.
If you peer with another carrier who does the IP/TDM interconnection at the tandems on your behalf, you are still beholden to the actual CLEC that owns your numbers. To me, that's the true difference (which is both technical as well as regulatory) between a CLEC and a facilities-based reseller.
I agree. There is a whole pile of things you have to do and facilities you have to own and operate as a CLEC that you do not have to as an ITSP/reseller of an underlying carrier. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Or just tell your clients that cool technology comes at a cost - that cost is more downtime due to other problems mentioned earlier in this thread and the inherint problems of sharing voice and data on the same medium....Actually, it's an interesting problem to solve from both the core and cpe perspectives that all revolve around which vendors you use, business requirements, and cash (with cash being the first variable)... On a curiosity note - why would you even need to interconnect with SS7 to the PSTN when you can SIP peer to all the major carriers? There can be an argument for backup to SIP peering that makes sense. Maybe it's cheaper? But outside of those what other benefits are there (don't misread my tone here - I'm really asking)? Kenny On Tue, Aug 11, 2009 at 6:45 PM, David Birnbaum <davidb at pins.net> wrote:
Kenny,
A number of different options exist for redundancy, but they all depend on your underlying network architecture and connectivity options. The newest switches tend to have call agents and media gateways that are separate, so you can have redundancy across your hardware and call control geographically. Some older switches are more monolithic, so you have more redundancy in your network since that has to survive more.
You also find the world changes pretty dramatically when you go from Asterisk (which I use generically to refer to any small-scale solution of under 2k endpoints or so) to Big Iron - you pay a lot more money for all sorts of redundancy and scalability, and as a result you solve problems very differently (and have different options to solve problems). Right now Asterisk can't exist without the big iron (5E, MetaSwitch, Broadsoft, etc.) because it can't handle the call routing, SS7 interop, etc. One can think of the smaller VoIP providers as basic class 5 switches providing the traditional end-user connectivity and not worrying about the bigger issues that will bedevil people as they head into the interconnection world.
If you can split your call control and media between geographical locations, then you can set up as a CLEC in two colocations, and interconnect to the necessary tandems to exchange traffic with two unrelated circuits, and then have lots of room to lose one half of your network without affecting core call control (how you get to your customers is a different problem, of course). Switches can also function in an emergency-standalone world as well. SS7 already has all of the redundancy options via multiple A-links to the outside world. I don't believe it's possible to interconnect with IP anywhere as a CLEC since the PSTN infrastructure doesn't exist outside of the SS7 environment for all practical purposes. (Obviously, you can peer with IP but that's not the same as interconnection from a PSTN perspective).
If you can't split your call control, then you use SONET and other self-healing architecture to buttress your network as much as possible against fiber cuts, MUX outages, and other crashes with the hope that you never lose both ends of your ring at the same time.
Cheers,
David.
------------------------------
Kenny Sallee wrote:
Yes IP makes it easier but you still have to 'plugin' to the PSTN somewhere and in some fashion correct? Unless you have nothing but SIP peering it does get a little more complicated (although I'm new to the VoIP world and do not know SS7). Then you still have to worry about your call processing platform: can it live with being greater than x ms apart from it's redundant pair? What about CDR's and reporting - how do you merge those coming from multiple sources? I would think there's also rate center and latency issues as well with outbound routing of calls (send calls out the cheapest carrier that will allow it). I don't think any of it's impossible, but the presence of IP doesn't remove all complexity.
I like David's idea of a VoiceOps working group to help define options. Sounds like fun Kenny
On Tue, Aug 11, 2009 at 7:23 AM, Alex Balashov <abalashov at evaristesys.com>wrote:
Seems to me like one of the main arguments for moving to IP infrastructure - alongside the numerous arguments telco people have against it - is that it makes this type of redundancy a lot more achievable and cost-effective.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
------------------------------
_______________________________________________ VoiceOps mailing listVoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops
Kenny Sallee wrote:
On a curiosity note - why would you even need to interconnect with SS7 to the PSTN when you can SIP peer to all the major carriers? There can be an argument for backup to SIP peering that makes sense. Maybe it's cheaper? But outside of those what other benefits are there (don't misread my tone here - I'm really asking)?
If you're just an ITSP, you may not need to, strictly speaking. But if you're a CLEC, you do, and the original question seemed to be heavily concerned with making CLEC facilities redundant. Beyond that, it's a matter of opinion. My experience has been that SIP peering isn't terribly mature; reliability and interop issues abound. I've had a number of high-volume customers that gave up and went to TDM access circuits after they realised that their top tech people spend 90% of all days dealing with SIP issues from their O/T providers. It's the usual litany of crap. formatting differences (E.164 vs. ten-digit), buggy in-band DTMF, very buggy RFC2833 (out-of-band) DTMF, caller ID and CNAM (From vs. Remote-Party-ID vs. P-Asserted-Identity), QoS, one-way audio, dropped calls, DSP bugs in ISDN<->VoIP gateways, etc. When they move to TDM these problems seem to magically go away. But I have other customers that just don't seem to have a lot of these problems, either. It's a coin toss. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
OK I see - from a CLEC perspective - is it a legal requirement to do so? I've read some of this tonight: http://www.voip-info.org/wiki/view/How+to+start+a+Clec and although it's mentioned a bit I'm not clear on if it's a legal requirement of a CLEC (or just implied because in 1996 that's just the way it was) ITSP vs CLEC redundancy sounds like it's quite different then - if you must have SS7 links.
From an ITSP perspective - redundancy sounds like it comes down to IP latency between signalling entities and their capabilities, hardware, and cash (like mentioned below).
Along those lines - I'm reading up on BW and geographical HA... http://www.broadsoft.com/products/broadworks/platform/#network-geographic -- anyone out there actually who has actually implemented it - if so what's your experiences if you can share on list? On Tue, Aug 11, 2009 at 11:14 PM, Alex Balashov <abalashov at evaristesys.com>wrote:
Kenny Sallee wrote:
On a curiosity note - why would you even need to interconnect with SS7 to
the PSTN when you can SIP peer to all the major carriers? There can be an argument for backup to SIP peering that makes sense. Maybe it's cheaper? But outside of those what other benefits are there (don't misread my tone here - I'm really asking)?
If you're just an ITSP, you may not need to, strictly speaking. But if you're a CLEC, you do, and the original question seemed to be heavily concerned with making CLEC facilities redundant.
Beyond that, it's a matter of opinion. My experience has been that SIP peering isn't terribly mature; reliability and interop issues abound. I've had a number of high-volume customers that gave up and went to TDM access circuits after they realised that their top tech people spend 90% of all days dealing with SIP issues from their O/T providers.
It's the usual litany of crap. formatting differences (E.164 vs. ten-digit), buggy in-band DTMF, very buggy RFC2833 (out-of-band) DTMF, caller ID and CNAM (From vs. Remote-Party-ID vs. P-Asserted-Identity), QoS, one-way audio, dropped calls, DSP bugs in ISDN<->VoIP gateways, etc. When they move to TDM these problems seem to magically go away.
But I have other customers that just don't seem to have a lot of these problems, either. It's a coin toss.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
On Aug 12, 2009, at 1:37 AM, Kenny Sallee wrote:
OK I see - from a CLEC perspective - is it a legal requirement to do so? I've read some of this tonight: http://www.voip-info.org/wiki/view/How+to+start+a+Clec and although it's mentioned a bit I'm not clear on if it's a legal requirement of a CLEC (or just implied because in 1996 that's just the way it was)
ITSP vs CLEC redundancy sounds like it's quite different then - if you must have SS7 links.
No, not sure how you got this idea, you think every mid-sized ISP in the '90s had connections to the service control points? For a CLEC to get a lot of the O/T benefits SS7 interconnection would be desirable, but not required.
From an ITSP perspective - redundancy sounds like it comes down to IP latency between signalling entities and their capabilities, hardware, and cash (like mentioned below).
What you are describing is QoS from an ITSP perspective, redundancy from an ITSP perspective would entail things like anycast, service records, bgp announcements across diverse circuits, and geographic diversity of POPs
Along those lines - I'm reading up on BW and geographical HA...http://www.broadsoft.com/products/broadworks/platform/#network-geographic -- anyone out there actually who has actually implemented it - if so what's your experiences if you can share on list?
Sounds like linux-HA style workings to me, but I have no exposure to broadsoft products.
On Tue, Aug 11, 2009 at 11:14 PM, Alex Balashov <abalashov at evaristesys.com
wrote: Kenny Sallee wrote:
On a curiosity note - why would you even need to interconnect with SS7 to the PSTN when you can SIP peer to all the major carriers? There can be an argument for backup to SIP peering that makes sense. Maybe it's cheaper? But outside of those what other benefits are there (don't misread my tone here - I'm really asking)?
If you're just an ITSP, you may not need to, strictly speaking. But if you're a CLEC, you do, and the original question seemed to be heavily concerned with making CLEC facilities redundant.
Beyond that, it's a matter of opinion. My experience has been that SIP peering isn't terribly mature; reliability and interop issues abound. I've had a number of high-volume customers that gave up and went to TDM access circuits after they realised that their top tech people spend 90% of all days dealing with SIP issues from their O/T providers.
It's the usual litany of crap. formatting differences (E.164 vs. ten-digit), buggy in-band DTMF, very buggy RFC2833 (out-of-band) DTMF, caller ID and CNAM (From vs. Remote-Party-ID vs. P-Asserted- Identity), QoS, one-way audio, dropped calls, DSP bugs in ISDN<-
VoIP gateways, etc. When they move to TDM these problems seem to magically go away.
But I have other customers that just don't seem to have a lot of these problems, either. It's a coin toss.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Robin D. Rodriguez rrodriguez at ifbyphone.com
On Aug 12, 2009, at 1:37 AM, Kenny Sallee wrote:
OK I see - from a CLEC perspective - is it a legal requirement to do so? I've read some of this tonight: http://www.voip-info.org/wiki/view/How+to+start+a+Clec and although it's mentioned a bit I'm not clear on if it's a legal requirement of a CLEC (or just implied because in 1996 that's just the way it was)
ITSP vs CLEC redundancy sounds like it's quite different then - if you must have SS7 links.
No, not sure how you got this idea, you think every mid-sized ISP in the '90s had connections to the service control points? For a CLEC to get a lot of the O/T benefits SS7 interconnection would be desirable, but not required.
From an ITSP perspective - redundancy sounds like it comes down to IP latency between signalling entities and their capabilities, hardware, and cash (like mentioned below).
What you are describing is QoS from an ITSP perspective, redundancy from an ITSP perspective would entail things like anycast, service records, bgp announcements across diverse circuits, and geographic diversity of POPs
Along those lines - I'm reading up on BW and geographical HA...http://www.broadsoft.com/products/broadworks/platform/#network-geographic -- anyone out there actually who has actually implemented it - if so what's your experiences if you can share on list?
Sounds like linux-HA style workings to me, but I have no exposure to broadsoft products.
On Tue, Aug 11, 2009 at 11:14 PM, Alex Balashov <abalashov at evaristesys.com
wrote: Kenny Sallee wrote:
On a curiosity note - why would you even need to interconnect with SS7 to the PSTN when you can SIP peer to all the major carriers? There can be an argument for backup to SIP peering that makes sense. Maybe it's cheaper? But outside of those what other benefits are there (don't misread my tone here - I'm really asking)?
If you're just an ITSP, you may not need to, strictly speaking. But if you're a CLEC, you do, and the original question seemed to be heavily concerned with making CLEC facilities redundant.
Beyond that, it's a matter of opinion. My experience has been that SIP peering isn't terribly mature; reliability and interop issues abound. I've had a number of high-volume customers that gave up and went to TDM access circuits after they realised that their top tech people spend 90% of all days dealing with SIP issues from their O/T providers.
It's the usual litany of crap. formatting differences (E.164 vs. ten-digit), buggy in-band DTMF, very buggy RFC2833 (out-of-band) DTMF, caller ID and CNAM (From vs. Remote-Party-ID vs. P-Asserted- Identity), QoS, one-way audio, dropped calls, DSP bugs in ISDN<-
VoIP gateways, etc. When they move to TDM these problems seem to magically go away.
But I have other customers that just don't seem to have a lot of these problems, either. It's a coin toss.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Robin D. Rodriguez rrodriguez at ifbyphone.com
Robin Rodriguez wrote:
On Aug 12, 2009, at 1:37 AM, Kenny Sallee wrote:
OK I see - from a CLEC perspective - is it a legal requirement to do so? I've read some of this tonight: http://www.voip-info.org/wiki/view/How+to+start+a+Clec and although it's mentioned a bit I'm not clear on if it's a legal requirement of a CLEC (or just implied because in 1996 that's just the way it was)
ITSP vs CLEC redundancy sounds like it's quite different then - if you must have SS7 links.
No, not sure how you got this idea, you think every mid-sized ISP in the '90s had connections to the service control points? For a CLEC to get a lot of the O/T benefits SS7 interconnection would be desirable, but not required.
That's true. I was assuming we were talking about telephony here strictly. There are a few uses ISPs have for CLEC licenses that have nothing to do with phone. One is rights-of-way for network build-out, pole attachment, etc. Another is getting UNE rates on leased circuits instead of wholesale access rates. That still required interconnection and/or CO colocation for aggregation, but not SS7.
Along those lines - I'm reading up on BW and geographical HA...http://www.broadsoft.com/products/broadworks/platform/#network-geographic -- anyone out there actually who has actually implemented it - if so what's your experiences if you can share on list?
Sounds like linux-HA style workings to me, but I have no exposure to broadsoft products.
Yep. All these devices pretty much work on the same principle, although even the Linux-based ones have proprietary failover technologies and don't use Linux-HA. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
No, not sure how you got this idea, you think every mid-sized ISP in the '90s had connections to the service control points? For a CLEC to get a lot of the O/T benefits SS7 interconnection would be desirable, but not required.
That's true. I was assuming we were talking about telephony here strictly.
There are a few uses ISPs have for CLEC licenses that have nothing to do with phone. One is rights-of-way for network build-out, pole attachment, etc. Another is getting UNE rates on leased circuits instead of wholesale access rates. That still required interconnection and/or CO colocation for aggregation, but not SS7.
There were 2 other good reasons to have a clec license, at least in the rate-center type latas... (Chicago/Lata 358 comes to mind)... 1. was to play the reciprocal comp game with the ILEC... At least one CLEC's entire business model was nearly completely based on this early on (Focal Communications) 2. was to have a folded modem pool where all the rate centers terminated into one large modem pool. It was easy to turn up a few ds3s to a few tandem switches to receive inbound calls from a large portion of the lata. After you got up and running and found the 'hot spots' you'd then turn up end-office trunks to each of those rate centers to take advantage of the more favorable termination rates for #1. Ah the good 'ol days of the Dial-up isp biz... I remember 20+ Ascend Max TNT's each humming along with 16 inbound PRI's of dial-up... If I remember correctly tho, in order to connect to the tandems you had to be able to provide ss7 services. We got all of our ports out of a DMS500, but I do remember people using something from cisco to emulate a switch (SCC maybe?) and back end all the dial traffic into 5800's.... -J
Jason Vanick wrote:
No, not sure how you got this idea, you think every mid-sized ISP in the '90s had connections to the service control points? For a CLEC to get a lot of the O/T benefits SS7 interconnection would be desirable, but not required. That's true. I was assuming we were talking about telephony here strictly.
There are a few uses ISPs have for CLEC licenses that have nothing to do with phone. One is rights-of-way for network build-out, pole attachment, etc. Another is getting UNE rates on leased circuits instead of wholesale access rates. That still required interconnection and/or CO colocation for aggregation, but not SS7.
There were 2 other good reasons to have a clec license, at least in the rate-center type latas... (Chicago/Lata 358 comes to mind)...
1. was to play the reciprocal comp game with the ILEC... At least one CLEC's entire business model was nearly completely based on this early on (Focal Communications)
Ha! Oh, yes, the good ol' reciprocal comp. arbitrage. :-) Some of them were practically giving away bulk PRIs to ISPs... didn't matter, it's the reciprocal compensation that counts.
2. was to have a folded modem pool where all the rate centers terminated into one large modem pool. It was easy to turn up a few ds3s to a few tandem switches to receive inbound calls from a large portion of the lata. After you got up and running and found the 'hot spots' you'd then turn up end-office trunks to each of those rate centers to take advantage of the more favorable termination rates for #1.
Yes, but these require SS7 interconnection. The discussion was about applications for a CLEC license by an ISP that isn't connected to the ILEC tandems and, therefore, doesn't take phone calls per se. :-)
Ah the good 'ol days of the Dial-up isp biz... I remember 20+ Ascend Max TNT's each humming along with 16 inbound PRI's of dial-up...
If I remember correctly tho, in order to connect to the tandems you had to be able to provide ss7 services. We got all of our ports out of a DMS500, but I do remember people using something from cisco to emulate a switch (SCC maybe?) and back end all the dial traffic into 5800's....
There were lots of switch-lite solutions (signaling gateways) that were popular during the dialup boom. The Cisco PGW was very popular among them. All of these could control media gateways via H.248/MEGACO or MGCP, and the TNTs did H.248. Just very basic SS7 ISUP->media gateway control was needed to get modem pools going. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Alex Balashov wrote:
If I remember correctly tho, in order to connect to the tandems you had to be able to provide ss7 services. We got all of our ports out of a DMS500, but I do remember people using something from cisco to emulate a switch (SCC maybe?) and back end all the dial traffic into 5800's....
There were lots of switch-lite solutions (signaling gateways) that were popular during the dialup boom. The Cisco PGW was very popular among them. All of these could control media gateways via H.248/MEGACO or MGCP, and the TNTs did H.248. Just very basic SS7 ISUP->media gateway control was needed to get modem pools going.
And the Cisco AS-series stuff is MGCP, I believe. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
All - wanted to say thanks for enlightening me. Been a very interesting thread. Seems like there's a lot of legacy technology, regulations, and thinking that we have to take into account in planning. The original thread was on geographical redundancy - guess it should have been more specific: * redundancy for an ITSP only provider that's facilities based reseller * redundancy for CLEC * On Wed, Aug 12, 2009 at 7:15 AM, Alex Balashov <abalashov at evaristesys.com>wrote:
Alex Balashov wrote:
If I remember correctly tho, in order to connect to the tandems you had to
be able to provide ss7 services. We got all of our ports out of a DMS500, but I do remember people using something from cisco to emulate a switch (SCC maybe?) and back end all the dial traffic into 5800's....
There were lots of switch-lite solutions (signaling gateways) that were popular during the dialup boom. The Cisco PGW was very popular among them. All of these could control media gateways via H.248/MEGACO or MGCP, and the TNTs did H.248. Just very basic SS7 ISUP->media gateway control was needed to get modem pools going.
And the Cisco AS-series stuff is MGCP, I believe.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Kenny Sallee wrote:
All - wanted to say thanks for enlightening me. Been a very interesting thread. Seems like there's a lot of legacy technology, regulations, and thinking that we have to take into account in planning. The original thread was on geographical redundancy - guess it should have been more specific:
* redundancy for an ITSP only provider that's facilities based reseller
What do you mean by "facilities-based reseller?" Meaning, an ITSP that operates some sort of significant equipment as opposed to renting partitions on someone's Broadsoft or other wholesale-oriented service delivery platform that's somewhere else? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Sorry for double post - google shortcut and botched up keystrokes made me send premature All - wanted to say thanks for enlightening me. Been a very interesting thread. Seems like there's a lot of legacy technology, regulations, and thinking that we have to take into account in planning. The original thread was on geographical redundancy - guess it should have been more specific: * redundancy for an ITSP only provider that's facilities based reseller (that being someone who is not a true CLEC but uses CLEC(s) for IP <-> TDM conversion to get on the PSTN) - SIP peering redundancy via IP - local call processing and media gateway redundancy as well as geographical - IP reachability to CPE and CPE redundancy * redundancy for CLEC/Carrier - some or all of the above and - sounds a bit more complicated when you add on SS7 requirements - what else? Alex - to answer you directly - ITSP with either I guess would be relevant. Although if I use a wholesale provider I'd expect that they are both locally and geographically redundant (or I wouldn't use them unless business requirements or financial situation dictated outage time is OK or worth the risk).
On Wed, Aug 12, 2009 at 7:15 AM, Alex Balashov <abalashov at evaristesys.com>wrote:
Alex Balashov wrote:
If I remember correctly tho, in order to connect to the tandems you had
to be able to provide ss7 services. We got all of our ports out of a DMS500, but I do remember people using something from cisco to emulate a switch (SCC maybe?) and back end all the dial traffic into 5800's....
There were lots of switch-lite solutions (signaling gateways) that were popular during the dialup boom. The Cisco PGW was very popular among them. All of these could control media gateways via H.248/MEGACO or MGCP, and the TNTs did H.248. Just very basic SS7 ISUP->media gateway control was needed to get modem pools going.
And the Cisco AS-series stuff is MGCP, I believe.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Aug 13, 2009, at 12:46 PM, Kenny Sallee wrote:
* redundancy for CLEC
You earlier mentioned BroadSoft BroadWorks geographic redundancy. We've done it for several carriers, and it works. Supporting all the fault-tolerance scenarios can be extremely complex, but it's definitely achievable. It introduces a set of requirements on the network, and especially on your connectivity to subscribers. But on to CLECs: The technical problem involves termination and origination, of course. Termination (sending calls to the PSTN from your subscribers) through different gateways, for a CLEC, is easy. You just dump your calls outbound wherever you'd like to; unless you have a screen list, it shouldn't be a problem. Origination -- receiving calls from the PSTN to subscribers -- is the challenge. But it can be done. A minimal design achievable with popular equipment, such as MetaSwitch. It includes splitting your SS7 Linkset, sending one member of the linkset to site A, and the other to site B. This type of system doesn't require any special tricks with ISUP routes or point-code proxy. In addition, you need to build your ISUP trunk groups to two locations. Suppose your local inbound trunk groups go to the Atlanta tandem. You'd have some trunks go from the tandem to site A, and some go to site B. Suppose you have four ISUP-controlled T1s in this trunk group. T1-1 with TCICs 1-24 T1-2 with TCICs 25-48 T1-3 with TCICs 25-72 T1-4 with TCICs 73-96 T1-1 and T1-2 could connect to site A, while T1-3 and T1-4 connect to site B. At Site A, you'd need a media gateway and signaling interface to connect the two ISUP trunk groups, there. At Site B, you'd need a matched set. You'd have a Call-Control server at both Site A and Site B; these boxes would handle the SS7/ISUP signaling received at both of the sites. In a Sunny-Day Situation (all is normal), the Call Control server at Site A could be the master, and control signaling through both of the SS7 A-links. The two call-control servers would should an SS7 point code, but only one of those two would be activate at any one time. Some of your calls would be transported to Site A, while others are transported to Site B. In the case of a site fault, the remaining site would detect the fault and assume full control. It's critically important in these designs that the two call control servers have connectivity that's the most reliable part; i.e., if anything at all is working, then the two call control servers should be able to communicate: If I'm a call control server, it is impossible for me to determine whether the other call- control server is dead, or if it's just not able to communicate with me. If it's alive, but the two call control servers cannot communicate, then both can become active and try to assume control of the linkset. Bad stuff ensues. But none of that particularly relates to BroadWorks. While the SS7- connected call-control servers need to be call-state synchronized, BroadWorks doesn't have to be. It's actually quite forgiving in failover scenarios where Site A's Application Server cannot communicate with Site B's Application Server. Mark R Lindsey lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013
When you say "it works" - what is the impact to the customer? On Aug 13, 2009, at 10:18 AM, Mark R Lindsey wrote:
We've done it for several carriers, and it works. Supporting all the fault-tolerance scenarios can be extremely complex, but it's definitely achievable. It introduces a set of requirements on the network, and especially on your connectivity to subscribers.
On Thu, 13 Aug 2009, Mark Holloway wrote:
When you say "it works" - what is the impact to the customer?
Zero -Nathan
On Aug 13, 2009, at 10:18 AM, Mark R Lindsey wrote:
We've done it for several carriers, and it works. Supporting all the fault-tolerance scenarios can be extremely complex, but it's definitely achievable. It introduces a set of requirements on the network, and especially on your connectivity to subscribers.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
How do you gracefully handle a route flapping? On Aug 13, 2009, at 12:19 PM, Nathan Stratton wrote:
On Thu, 13 Aug 2009, Mark Holloway wrote:
When you say "it works" - what is the impact to the customer?
Zero
-Nathan
On Aug 13, 2009, at 10:18 AM, Mark R Lindsey wrote:
We've done it for several carriers, and it works. Supporting all the fault-tolerance scenarios can be extremely complex, but it's definitely achievable. It introduces a set of requirements on the network, and especially on your connectivity to subscribers.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Zero is nice, but may not be feasible. I would say "it works" means that your failure scenario may run from "zero", in which case the customer doesn't notice that you've lost half your trunking, to what I would consider "minor", which means that most of your calls stay up and perhaps dialtone/call setups fail for 10-20 seconds. Any outage longer than that I would not consider acceptable (as part of the five-nines we all aim for). David. ----- On Thu, 13 Aug 2009, Nathan Stratton wrote:
On Thu, 13 Aug 2009, Mark Holloway wrote:
When you say "it works" - what is the impact to the customer?
Zero
-Nathan
On Aug 13, 2009, at 10:18 AM, Mark R Lindsey wrote:
We've done it for several carriers, and it works. Supporting all the fault-tolerance scenarios can be extremely complex, but it's definitely achievable. It introduces a set of requirements on the network, and especially on your connectivity to subscribers.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
That's exactly what I was getting at. Thanks.. On Aug 13, 2009, at 12:40 PM, David Birnbaum wrote:
Zero is nice, but may not be feasible.
I would say "it works" means that your failure scenario may run from "zero", in which case the customer doesn't notice that you've lost half your trunking, to what I would consider "minor", which means that most of your calls stay up and perhaps dialtone/call setups fail for 10-20 seconds.
Any outage longer than that I would not consider acceptable (as part of the five-nines we all aim for).
David.
-----
On Thu, 13 Aug 2009, Nathan Stratton wrote:
On Thu, 13 Aug 2009, Mark Holloway wrote:
When you say "it works" - what is the impact to the customer?
Zero
-Nathan
On Aug 13, 2009, at 10:18 AM, Mark R Lindsey wrote:
We've done it for several carriers, and it works. Supporting all the fault-tolerance scenarios can be extremely complex, but it's definitely achievable. It introduces a set of requirements on the network, and especially on your connectivity to subscribers.
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On Thu, 13 Aug 2009, David Birnbaum wrote:
Zero is nice, but may not be feasible.
I would say "it works" means that your failure scenario may run from "zero", in which case the customer doesn't notice that you've lost half your trunking, to what I would consider "minor", which means that most of your calls stay up and perhaps dialtone/call setups fail for 10-20 seconds.
We can shutdown our NYC cluster and calls will stay up. The question was in response to geographic redundancy and BroadWorks. Yes, there are events outside the network that can cause issues. However this is greatly reduced with geographic redundancy on your appserver/softswitch. We wrote our own SIP video conferencing system from scratch, we have the inhouse programming resources to add in memory distributed database to one of the open source platforms, however we found that using something like BroadSoft saved us a lot of time and money. -Nathan
It works in that (a) BroadWorks can synchronize between servers at different sites. (b) When either of the sites fails, service is restored automatically and quickly after the fault. (c) When the fault is corrected, BroadWorks servers re-synchronize gracefully without interruption to subscribers. But the hard part is not the BroadWorks servers -- it's the access network. In most cases, the geographic distribution the voip servers (BroadWorks application servers, in this discussion) means that you have geographically-distributed SBCs. And such SBCs are usually not call-state synchronized. And typically that means that each SBC has a separate IP address facing subscribers. And most subscribers only have a single link to the access network. The customer's device has to handle this properly, and the SBC has to handle this properly. For example, when a failure of one site occurs, you want all of your devices to re-register through the secondary site. How long will it take before they re-register? How will they detect that one site has failed? What happens to calls headed toward the subscriber during the period until the customer re-registers? For the SBC, how will it handle the mass re-registration from subscribers moving over from the other SBC? How will it protect the core registrar (BroadWorks AS in our example) against attack? Nathan, "Zero" impact on customers is incredibly expensive to achieve. You can, in fact, engineer capacity to make this switching (and even route flapping) graceful, but it means you have orders-of-magnitude more expense in your access network. An SBC that can handle 10,000 subscribers today might be able to handle 100 subscribers if we need to ensure zero new calls are lost, because each those subscribers has to hammer away at the SBC doing polling. It's probably less costly to bring each subscriber to each of your two sites, then to put more failover at the customer premise (like a smart ALG). Nevertheless, without call state synchronization in the SBCs, it may not be possible to achieve full site-to-site failover with Nathan's Zero affect on customers. For example: If a call started on SBC-site-A and then fails to SBC-site-B, SBC-site-B would normally reject re- INVITES for that dialog; therefore session audits, call hold/resume, etc. can cause the standing call to drop. Application Server / Call Server redundancy is great, and there's much more to consider in fault-tolerant voip network designs. On Aug 13, 2009, at 3:19 PM, Nathan Stratton wrote:
On Thu, 13 Aug 2009, Mark Holloway wrote:
When you say "it works" - what is the impact to the customer?
Zero
Mark R Lindsey lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013
Mark R Lindsey wrote:
On Aug 13, 2009, at 12:46 PM, Kenny Sallee wrote:
* redundancy for CLEC
In the case of a site fault, the remaining site would detect the fault and assume full control. It's critically important in these designs that the two call control servers have connectivity that's the most reliable part; i.e., if anything at all is working, then the two call control servers should be able to communicate: If I'm a call control server, it is impossible for me to determine whether the other call-control server is dead, or if it's just not able to communicate with me. If it's alive, but the two call control servers cannot communicate, then both can become active and try to assume control of the linkset. Bad stuff ensues.
It sounds like for the entire effort and cost of this, there's still a SPOF, not to mention it requires you always augment at 45% or lower so if you lose one server, you don't block. -Paul
On Aug 13, 2009, at 3:41 PM, Paul Timmins wrote:
Mark R Lindsey wrote:
On Aug 13, 2009, at 12:46 PM, Kenny Sallee wrote:
* redundancy for CLEC In the case of a site fault, the remaining site would detect the fault and assume full control. It's critically important in these designs that the two call control servers have connectivity that's the most reliable part;...
It sounds like for the entire effort and cost of this, there's still a SPOF, not to mention it requires you always augment at 45% or lower so if you lose one server, you don't block.
Good point; I was imprecise. You must certainly have redundant paths between your two SS7-attached call control servers. And there are voip platforms that support this fully. This "dual brain" fault occurs when BOTH of your redundant links between your SS7-attached call control servers are dead. You are also correct that you you engineer so that any one component in a fault-tolerance pair can support all of the load. But that's a familiar refrain in systems design: we do that with SS7 link members (neither link may exceed 50% utilization) and with our RAID-1 arrays (two disks, filled to 50% the cumulative capacity). Mark R Lindsey lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013
Kenny Sallee wrote:
OK I see - from a CLEC perspective - is it a legal requirement to do so? I've read some of this tonight: http://www.voip-info.org/wiki/view/How+to+start+a+Clec and although it's mentioned a bit I'm not clear on if it's a legal requirement of a CLEC (or just implied because in 1996 that's just the way it was)
First, that document is a bit simplistic and dated. There's no such thing as a "pure-resale" CLEC any longer; that's what UNE-P was, and it went away in 2003. You can resell things from the ILEC (albeit, not especially profitably), but you still have to have facilities. It is no longer possible to rent and resell ports on an ILEC switch. There were a lot of arbitrage/resale plays that died when that ruling came down. Otherwise, in your question, are you referring to SS7 interconnection with the incumbent? I don't believe it's necessary to have any physical interconnection active in order to have a CLEC license and do nothing with it. Interconnection is just a practical requirement of operating as a CLEC; it's part of the definition of a facilities-based CLEC that it connects to the ILEC, because the CLEC is entitled to take advantage of some of the ILEC's physical plant, network, and various other facilities. CLECs lease copper services in order to build circuits to customers that the ILEC's plant can reach, to colocate in ILEC central offices, are eligible for certain types of special rates for access products, etc. But even if you're not colocating in COs or generating UNE circuits, you still have to pass traffic to the ILEC because a majority of intra-LATA subscribers are going to be ILEC customers in your local rate center, or reachable via the ILEC's one or more tandem offices. IXCs also traditionally land at the tandem, although it is possible to connect to some of them directly with access circuits or VoIP peering. Other competitive carriers operating in the same LATA are also met at the ILEC tandem, and so on. There are some alternatives to ILEC tandem access such as Neutral Tandem, but these aren't substitutes for the ILEC tandem - they just get you a cheaper way to meet the same players in your LATA and bypass some tandem access charges. The other thing you have to keep in mind is regulatory obligations faced by CLECs. For example, as a CLEC you're required to provide equal access to any IXC (long-distance/inter-LATA carrier) the customer wants to use via 1010 dial-around or PIC. How are you going to allow them to use *any* CAC if you're only directly connected to two IXCs? You can only hit up the rest at the Bell tandem. Same for emergency calls: hitting PSAPs requires going through special 911 trunk groups on your SS7 IMT to special 911 tandems run by the ILEC. Add number portability, directory services, number pooling, and a bunch of other good things, and, there's not really a way to participate without connecting to the ILEC. So, yes, in practice, you have to interconnect with the ILEC if you are a competitive carrier, and SS7 is the only way to do that. Using some ILEC facilities is part of what it means to be a competitive carrier. If you have a free and clear monopoly on a small town of a few thousand people in rural Minnesota, plant and all, that may be small-town telco, but that's not "competitive," as conceived by TRA96. If you don't want to connect via physical SS7 link circuits, see my most about SIGTRAN. But you still need physical TDM trunks for the bearer portion of the interconnect. You can get away with having someone else convert those trunks into VoIP and do the signaling to the ILEC for you, but, someone's gotta do it.
ITSP vs CLEC redundancy sounds like it's quite different then - if you must have SS7 links.
It is. But, beyond the SS7 stuff, it can be remarkably similar depending on how "soft" and/or IP-oriented the core equipment in use is.
From an ITSP perspective - redundancy sounds like it comes down to IP latency between signalling entities and their capabilities, hardware, and cash (like mentioned below).
Latency actually isn't that big of a deal unless you're talking halfway around the world. It's reliability, really. -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
This type of redundancy isn't the biggest risk point here, however. We lost a large chunk of connectivity to another region of the state because of what was either a single threaded fiber, or a collapsed ring on a handoff between AT&T and Verizon not too long ago. It was the only route available into the area, and it was the sort of traffic you don't want to carry on the public internet (IE: Running IP here wouldn't have done any good, because it would have had to be private anyway). Verizon experiences serious fiber cuts every day in some portion of their network, it seems. The biggest risk factor, from my customer's point of view, is still the connections between them and us. (And an overwhelming majority of those are IP) -Paul Alex Balashov wrote:
Seems to me like one of the main arguments for moving to IP infrastructure - alongside the numerous arguments telco people have against it - is that it makes this type of redundancy a lot more achievable and cost-effective.
It's probably too banal to be worth mentioning and has already been contemplated extensively vis-a-vis this subject, but I'd say the first question about any clever ultra-ultra-redundancy should be whether it's Pareto-optimal. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775
participants (10)
-
abalashov＠evaristesys.com -
David_Hiers＠adp.com -
davidb＠pins.net -
jvanick＠spruce.oaknet.com -
kenny.sallee＠gmail.com -
lindsey＠e-c-group.com -
mh＠markholloway.com -
nathan＠robotics.net -
paul＠timmins.net -
rrodriguez＠ifbyphone.com