Re: [cisco-voip] SBC/SIP Trunk Design queries
Thanks Roger and everyone for the replies, its been very helpful. Terry Sent from my iPhone On 14 Mar 2015, at 11:27 pm, Roger Wiklund roger.wikl...@gmail.com wrote: We use Acme 3820 with our UCaas platform. Behind it we serve Cisco, Mitel, Avaya and Lync PBX:es. You can't go wrong with Acme, especially when it comes to SIP manipulation, there's nothing you can't do. For me that's the number one selling point. HA is awesome with hitless failover. You can upgrade outside of service windows if you have to. Flow through/flow around is more flexible in Acme with media release based on same-IP for example. If you run Enterprise version or Service Provider version 7.2 you get a web GUI which is very helpful when troubleshooting. http://www.markholloway.com/blog/wp-content/uploads/2012/08/Screen-Shot-2012-08-08-at-3.00.55-PM.png The only downside with Acme for me is Oracle. I miss the days when it was just Acme Packet, the support was awesome. Now, not so much. It feels like all the talented engineers jumped ship. With that said we do use CUBE but for smaller on-prem solutions. It does the job and it's easy to configure. Sonus is another player that i've heard some buzz about. On Thu, Mar 12, 2015 at 1:34 AM, David Lin david@msn.com wrote: I think one of important things is the capacity you are looking for. ACME does give you better scalability and better troubleshooting capability, but if you are only looking for couple hundreds of concurrent calls, you probably can live with CUBE to keep your cost lower. D. From: tim.sm...@enject.com.au To: terry.che...@gmail.com; cisco-voip@puck.nether.net Date: Wed, 11 Mar 2015 04:19:22 + Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries Hi Terry, I do quite a bit of CUBE, and have done a bit of Acme as well. There were some recent partner sessions that talk about some interesting things coming for CUBE, so it’s worth making sure you are getting latest roadmap info. My main comparison points.. # HA In enterprise there was HA on CUBE, and it was improving in each release (but there are caveats with it) Have found Acme HA to be seamless and rock solid. # Deployment Cisco has some great interop guides – if you go with a carrier that has spent the money, a lot of the hard work has been done for you in terms of testing (as you know SIP can be implemented and configured in many different ways – if someone hasn’t done a lot of testing up front, you do sometimes end up adding SIP profiles and tweaks as you discover issues) Acme has some very thorough guides – I’m not sure if they have interop testing with carriers – given they are in SP’s a lot, there is a good chance they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their testing, and supported SBC’s. # Ops CUBE enterprise is great, IOS, most people are familiar. You will most likely need to train people on Acme I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, copy to file, or packet captures. Wireshark with ladders or TranslatorX are great, but it’s getting the files there that bugs me. Alternatively, there did seem to be a few 3rd party tools out there, but you are probably looking at $$$ Acme has web interface, list of calls and then ability to drill down with ladder diagrams, messaging capture etc. You should see this before making decision. Some good knowledge on Acme forums Acme has very flexible manipulation – CUBE is quite good too (and they have great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk # On your other notes Centralised – this is great for flexibility DR etc, standard stuff be aware of the call volumes over the WAN, caller ID considerations for emergency and local pizza shop type services WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this is most flexible.. you have a very flexible set up in Acme in regard to networking, lots of zones, interface options etc. Transcoding – I think you could still utilise CUCM registered transcoders for the ASR scenario.. Virtual - We use virtual Acme, it had some teething problems in very first versions (and a clunky license on USB stick thing going on) but it seems to be good now We don’t have transcoding / media resources in the virtual edition Flow through / around – a lot of designs the carrier doesn’t have connectivity into the rest of the network, so flow through is quite typical. However, we do have carriers here that have SBC’s on your WAN, so flow through can be nice here – it also then makes CUBE HA less important, i.e. if call is set up, media is from end point to carrier SBC already (if no xcoding involved) So I won’t say one way or the other, just my
Re: [cisco-voip] SBC/SIP Trunk Design queries
We use Acme 3820 with our UCaas platform. Behind it we serve Cisco, Mitel, Avaya and Lync PBX:es. You can't go wrong with Acme, especially when it comes to SIP manipulation, there's nothing you can't do. For me that's the number one selling point. HA is awesome with hitless failover. You can upgrade outside of service windows if you have to. Flow through/flow around is more flexible in Acme with media release based on same-IP for example. If you run Enterprise version or Service Provider version 7.2 you get a web GUI which is very helpful when troubleshooting. http://www.markholloway.com/blog/wp-content/uploads/2012/08/Screen-Shot-2012-08-08-at-3.00.55-PM.png The only downside with Acme for me is Oracle. I miss the days when it was just Acme Packet, the support was awesome. Now, not so much. It feels like all the talented engineers jumped ship. With that said we do use CUBE but for smaller on-prem solutions. It does the job and it's easy to configure. Sonus is another player that i've heard some buzz about. On Thu, Mar 12, 2015 at 1:34 AM, David Lin david@msn.com wrote: I think one of important things is the capacity you are looking for. ACME does give you better scalability and better troubleshooting capability, but if you are only looking for couple hundreds of concurrent calls, you probably can live with CUBE to keep your cost lower. D. From: tim.sm...@enject.com.au To: terry.che...@gmail.com; cisco-voip@puck.nether.net Date: Wed, 11 Mar 2015 04:19:22 + Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries Hi Terry, I do quite a bit of CUBE, and have done a bit of Acme as well. There were some recent partner sessions that talk about some interesting things coming for CUBE, so it’s worth making sure you are getting latest roadmap info. My main comparison points.. # HA In enterprise there was HA on CUBE, and it was improving in each release (but there are caveats with it) Have found Acme HA to be seamless and rock solid. # Deployment Cisco has some great interop guides – if you go with a carrier that has spent the money, a lot of the hard work has been done for you in terms of testing (as you know SIP can be implemented and configured in many different ways – if someone hasn’t done a lot of testing up front, you do sometimes end up adding SIP profiles and tweaks as you discover issues) Acme has some very thorough guides – I’m not sure if they have interop testing with carriers – given they are in SP’s a lot, there is a good chance they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their testing, and supported SBC’s. # Ops CUBE enterprise is great, IOS, most people are familiar. You will most likely need to train people on Acme I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, copy to file, or packet captures. Wireshark with ladders or TranslatorX are great, but it’s getting the files there that bugs me. Alternatively, there did seem to be a few 3rd party tools out there, but you are probably looking at $$$ Acme has web interface, list of calls and then ability to drill down with ladder diagrams, messaging capture etc. You should see this before making decision. Some good knowledge on Acme forums Acme has very flexible manipulation – CUBE is quite good too (and they have great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk # On your other notes Centralised – this is great for flexibility DR etc, standard stuff be aware of the call volumes over the WAN, caller ID considerations for emergency and local pizza shop type services WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this is most flexible.. you have a very flexible set up in Acme in regard to networking, lots of zones, interface options etc. Transcoding – I think you could still utilise CUCM registered transcoders for the ASR scenario.. Virtual - We use virtual Acme, it had some teething problems in very first versions (and a clunky license on USB stick thing going on) but it seems to be good now We don’t have transcoding / media resources in the virtual edition Flow through / around – a lot of designs the carrier doesn’t have connectivity into the rest of the network, so flow through is quite typical. However, we do have carriers here that have SBC’s on your WAN, so flow through can be nice here – it also then makes CUBE HA less important, i.e. if call is set up, media is from end point to carrier SBC already (if no xcoding involved) So I won’t say one way or the other, just my thoughts on things you can consider. I like both, and will continue to work on both! Cheers, Tim From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Terry Cheema Sent: Wednesday, 11 March 2015 1:10 PM To: cisco-voip voyp
Re: [cisco-voip] SBC/SIP Trunk Design queries - Acme Packet vs CUBE
Yes - definitely will like to have views from the community where things are heading these days. I have updated the title slightly, lets see if it gets further response. -Terry Sent from my iPhone On 11 Mar 2015, at 5:17 pm, Tim Smith tim.sm...@enject.com.au wrote: No problems, I'm also keen to hear other peoples experience too. It's an interesting topic! Cheers, Tim. From: Terry Cheema terry.che...@gmail.com Sent: Wednesday, 11 March 2015 5:09 PM To: Tim Smith Cc: cisco-voip voyp list Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries Tim, Thanks for your detailed and a quick response, much appreciated. Thanks, Terry On Wed, Mar 11, 2015 at 3:19 PM, Tim Smith tim.sm...@enject.com.au wrote: Hi Terry, I do quite a bit of CUBE, and have done a bit of Acme as well. There were some recent partner sessions that talk about some interesting things coming for CUBE, so it’s worth making sure you are getting latest roadmap info. My main comparison points.. # HA In enterprise there was HA on CUBE, and it was improving in each release (but there are caveats with it) Have found Acme HA to be seamless and rock solid. # Deployment Cisco has some great interop guides – if you go with a carrier that has spent the money, a lot of the hard work has been done for you in terms of testing (as you know SIP can be implemented and configured in many different ways – if someone hasn’t done a lot of testing up front, you do sometimes end up adding SIP profiles and tweaks as you discover issues) Acme has some very thorough guides – I’m not sure if they have interop testing with carriers – given they are in SP’s a lot, there is a good chance they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their testing, and supported SBC’s. # Ops CUBE enterprise is great, IOS, most people are familiar. You will most likely need to train people on Acme I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, copy to file, or packet captures. Wireshark with ladders or TranslatorX are great, but it’s getting the files there that bugs me. Alternatively, there did seem to be a few 3rd party tools out there, but you are probably looking at $$$ Acme has web interface, list of calls and then ability to drill down with ladder diagrams, messaging capture etc. You should see this before making decision. Some good knowledge on Acme forums Acme has very flexible manipulation – CUBE is quite good too (and they have great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk # On your other notes Centralised – this is great for flexibility DR etc, standard stuff be aware of the call volumes over the WAN, caller ID considerations for emergency and local pizza shop type services WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this is most flexible.. you have a very flexible set up in Acme in regard to networking, lots of zones, interface options etc. Transcoding – I think you could still utilise CUCM registered transcoders for the ASR scenario.. Virtual - We use virtual Acme, it had some teething problems in very first versions (and a clunky license on USB stick thing going on) but it seems to be good now We don’t have transcoding / media resources in the virtual edition Flow through / around – a lot of designs the carrier doesn’t have connectivity into the rest of the network, so flow through is quite typical. However, we do have carriers here that have SBC’s on your WAN, so flow through can be nice here – it also then makes CUBE HA less important, i.e. if call is set up, media is from end point to carrier SBC already (if no xcoding involved) So I won’t say one way or the other, just my thoughts on things you can consider. I like both, and will continue to work on both! Cheers, Tim From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Terry Cheema Sent: Wednesday, 11 March 2015 1:10 PM To: cisco-voip voyp list Subject: [cisco-voip] SBC/SIP Trunk Design queries Hi List, I am working on to finalize the SBC vendor for one of our environments. I have a couple of queries related to the SIP Trunk design and SBC vendor choices(basically CUBE vs Acme Packet). I would really appreciate if anyone with SIP Trunking/SBC expertise (Cisco/Acme Packet) can provide some input on the below queries: 1) CUBE vs Acme Packet: First of all Cisco has marked the CUBE SP Edition product line for EoL, exiting the SBC Service Provider segment, so leaving only SBC Enterprise as the option. Although at this stage we are looking for an enterprise grade SBC
Re: [cisco-voip] SBC/SIP Trunk Design queries
I think one of important things is the capacity you are looking for.ACME does give you better scalability and better troubleshooting capability, but if you are only looking for couple hundreds of concurrent calls, you probably can live with CUBE to keep your cost lower. D. From: tim.sm...@enject.com.au To: terry.che...@gmail.com; cisco-voip@puck.nether.net Date: Wed, 11 Mar 2015 04:19:22 + Subject: Re: [cisco-voip] SBC/SIP Trunk Design queries Hi Terry, I do quite a bit of CUBE, and have done a bit of Acme as well. There were some recent partner sessions that talk about some interesting things coming for CUBE, so it’s worth making sure you are getting latest roadmap info. My main comparison points.. # HA In enterprise there was HA on CUBE, and it was improving in each release (but there are caveats with it) Have found Acme HA to be seamless and rock solid. # Deployment Cisco has some great interop guides – if you go with a carrier that has spent the money, a lot of the hard work has been done for you in terms of testing (as you know SIP can be implemented and configured in many different ways – if someone hasn’t done a lot of testing up front, you do sometimes end up adding SIP profiles and tweaks as you discover issues) Acme has some very thorough guides – I’m not sure if they have interop testing with carriers – given they are in SP’s a lot, there is a good chance they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their testing, and supported SBC’s. # Ops CUBE enterprise is great, IOS, most people are familiar. You will most likely need to train people on Acme I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, copy to file, or packet captures. Wireshark with ladders or TranslatorX are great, but it’s getting the files there that bugs me. Alternatively, there did seem to be a few 3rd party tools out there, but you are probably looking at $$$ Acme has web interface, list of calls and then ability to drill down with ladder diagrams, messaging capture etc. You should see this before making decision. Some good knowledge on Acme forums Acme has very flexible manipulation – CUBE is quite good too (and they have great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk # On your other notes Centralised – this is great for flexibility DR etc, standard stuff be aware of the call volumes over the WAN, caller ID considerations for emergency and local pizza shop type services WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this is most flexible.. you have a very flexible set up in Acme in regard to networking, lots of zones, interface options etc. Transcoding – I think you could still utilise CUCM registered transcoders for the ASR scenario.. Virtual - We use virtual Acme, it had some teething problems in very first versions (and a clunky license on USB stick thing going on) but it seems to be good now We don’t have transcoding / media resources in the virtual edition Flow through / around – a lot of designs the carrier doesn’t have connectivity into the rest of the network, so flow through is quite typical. However, we do have carriers here that have SBC’s on your WAN, so flow through can be nice here – it also then makes CUBE HA less important, i.e. if call is set up, media is from end point to carrier SBC already (if no xcoding involved) So I won’t say one way or the other, just my thoughts on things you can consider. I like both, and will continue to work on both! Cheers, Tim From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Terry Cheema Sent: Wednesday, 11 March 2015 1:10 PM To: cisco-voip voyp list Subject: [cisco-voip] SBC/SIP Trunk Design queries Hi List, I am working on to finalize the SBC vendor for one of our environments. I have a couple of queries related to the SIP Trunk design and SBC vendor choices(basically CUBE vs Acme Packet). I would really appreciate if anyone with SIP Trunking/SBC expertise (Cisco/Acme Packet) can provide some input on the below queries: 1) CUBE vs Acme Packet: First of all Cisco has marked the CUBE SP Edition product line for EoL, exiting the SBC Service Provider segment, so leaving only SBC Enterprise as the option. Although at this stage we are looking for an enterprise grade SBC but it will be a plus if it has the potential to step up into a SP SBC in a multi-tenanted environment. I was comparing AP 3820 with the CUBE Ent ASR1k-x: CUBE provides no HA (though in some documents it says, came out from a meeting with the Cisco SME informing HA is not available), No transcoding (due to lack of DSP on ASR1K), No Multi-tenancy support with all of these features supported in a 3820 SBC Any feature better in CUBE that I may have overlooked? I am aware that CUBE configuration etc. can be easy
Re: [cisco-voip] SBC/SIP Trunk Design queries
Tim, Thanks for your detailed and a quick response, much appreciated. Thanks, Terry On Wed, Mar 11, 2015 at 3:19 PM, Tim Smith tim.sm...@enject.com.au wrote: Hi Terry, I do quite a bit of CUBE, and have done a bit of Acme as well. There were some recent partner sessions that talk about some interesting things coming for CUBE, so it’s worth making sure you are getting latest roadmap info. My main comparison points.. # HA In enterprise there was HA on CUBE, and it was improving in each release (but there are caveats with it) Have found Acme HA to be seamless and rock solid. # Deployment Cisco has some great interop guides – if you go with a carrier that has spent the money, a lot of the hard work has been done for you in terms of testing (as you know SIP can be implemented and configured in many different ways – if someone hasn’t done a lot of testing up front, you do sometimes end up adding SIP profiles and tweaks as you discover issues) Acme has some very thorough guides – I’m not sure if they have interop testing with carriers – given they are in SP’s a lot, there is a good chance they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their testing, and supported SBC’s. # Ops CUBE enterprise is great, IOS, most people are familiar. You will most likely need to train people on Acme I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, copy to file, or packet captures. Wireshark with ladders or TranslatorX are great, but it’s getting the files there that bugs me. Alternatively, there did seem to be a few 3rd party tools out there, but you are probably looking at $$$ Acme has web interface, list of calls and then ability to drill down with ladder diagrams, messaging capture etc. You should see this before making decision. Some good knowledge on Acme forums Acme has very flexible manipulation – CUBE is quite good too (and they have great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk # On your other notes Centralised – this is great for flexibility DR etc, standard stuff be aware of the call volumes over the WAN, caller ID considerations for emergency and local pizza shop type services WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this is most flexible.. you have a very flexible set up in Acme in regard to networking, lots of zones, interface options etc. Transcoding – I think you could still utilise CUCM registered transcoders for the ASR scenario.. Virtual - We use virtual Acme, it had some teething problems in very first versions (and a clunky license on USB stick thing going on) but it seems to be good now We don’t have transcoding / media resources in the virtual edition Flow through / around – a lot of designs the carrier doesn’t have connectivity into the rest of the network, so flow through is quite typical. However, we do have carriers here that have SBC’s on your WAN, so flow through can be nice here – it also then makes CUBE HA less important, i.e. if call is set up, media is from end point to carrier SBC already (if no xcoding involved) So I won’t say one way or the other, just my thoughts on things you can consider. I like both, and will continue to work on both! Cheers, Tim *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf Of *Terry Cheema *Sent:* Wednesday, 11 March 2015 1:10 PM *To:* cisco-voip voyp list *Subject:* [cisco-voip] SBC/SIP Trunk Design queries Hi List, I am working on to finalize the SBC vendor for one of our environments. I have a couple of queries related to the SIP Trunk design and SBC vendor choices(basically CUBE vs Acme Packet). I would really appreciate if anyone with SIP Trunking/SBC expertise (Cisco/Acme Packet) can provide some input on the below queries: 1) *CUBE vs Acme Packet*: First of all Cisco has marked the CUBE SP Edition product line for EoL, exiting the SBC Service Provider segment, so leaving only SBC Enterprise as the option. Although at this stage we are looking for an enterprise grade SBC but it will be a plus if it has the potential to step up into a SP SBC in a multi-tenanted environment. I was comparing AP 3820 with the CUBE Ent ASR1k-x: CUBE provides no HA (though in some documents it says, came out from a meeting with the Cisco SME informing HA is not available), No transcoding (due to lack of DSP on ASR1K), No Multi-tenancy support with all of these features supported in a 3820 SBC Any feature better in CUBE that I may have overlooked? I am aware that CUBE configuration etc. can be easy compared to Acme Packet but apart from that any solid reason to choose CUBE over AP? 2) *HA vs Non-HA*: HA is obviously the preferred approach and looks like only possible with AP. Can anyone confirm the HA works as
Re: [cisco-voip] SBC/SIP Trunk Design queries
Hi Terry, I do quite a bit of CUBE, and have done a bit of Acme as well. There were some recent partner sessions that talk about some interesting things coming for CUBE, so it’s worth making sure you are getting latest roadmap info. My main comparison points.. # HA In enterprise there was HA on CUBE, and it was improving in each release (but there are caveats with it) Have found Acme HA to be seamless and rock solid. # Deployment Cisco has some great interop guides – if you go with a carrier that has spent the money, a lot of the hard work has been done for you in terms of testing (as you know SIP can be implemented and configured in many different ways – if someone hasn’t done a lot of testing up front, you do sometimes end up adding SIP profiles and tweaks as you discover issues) Acme has some very thorough guides – I’m not sure if they have interop testing with carriers – given they are in SP’s a lot, there is a good chance they do. I’d look into it that with the Acme SE. Talk to prospective ITSP’s about their testing, and supported SBC’s. # Ops CUBE enterprise is great, IOS, most people are familiar. You will most likely need to train people on Acme I find troubleshooting a bit of a let down with CUBE. Basically log to buffer, copy to file, or packet captures. Wireshark with ladders or TranslatorX are great, but it’s getting the files there that bugs me. Alternatively, there did seem to be a few 3rd party tools out there, but you are probably looking at $$$ Acme has web interface, list of calls and then ability to drill down with ladder diagrams, messaging capture etc. You should see this before making decision. Some good knowledge on Acme forums Acme has very flexible manipulation – CUBE is quite good too (and they have great profile testing tool) – plus you can also use CUCM LUA on the SIP trunk # On your other notes Centralised – this is great for flexibility DR etc, standard stuff be aware of the call volumes over the WAN, caller ID considerations for emergency and local pizza shop type services WAN – we terminate on existing equipment, and Acme is in a VLAN, I think this is most flexible.. you have a very flexible set up in Acme in regard to networking, lots of zones, interface options etc. Transcoding – I think you could still utilise CUCM registered transcoders for the ASR scenario.. Virtual - We use virtual Acme, it had some teething problems in very first versions (and a clunky license on USB stick thing going on) but it seems to be good now We don’t have transcoding / media resources in the virtual edition Flow through / around – a lot of designs the carrier doesn’t have connectivity into the rest of the network, so flow through is quite typical. However, we do have carriers here that have SBC’s on your WAN, so flow through can be nice here – it also then makes CUBE HA less important, i.e. if call is set up, media is from end point to carrier SBC already (if no xcoding involved) So I won’t say one way or the other, just my thoughts on things you can consider. I like both, and will continue to work on both! Cheers, Tim From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Terry Cheema Sent: Wednesday, 11 March 2015 1:10 PM To: cisco-voip voyp list Subject: [cisco-voip] SBC/SIP Trunk Design queries Hi List, I am working on to finalize the SBC vendor for one of our environments. I have a couple of queries related to the SIP Trunk design and SBC vendor choices(basically CUBE vs Acme Packet). I would really appreciate if anyone with SIP Trunking/SBC expertise (Cisco/Acme Packet) can provide some input on the below queries: 1) CUBE vs Acme Packet: First of all Cisco has marked the CUBE SP Edition product line for EoL, exiting the SBC Service Provider segment, so leaving only SBC Enterprise as the option. Although at this stage we are looking for an enterprise grade SBC but it will be a plus if it has the potential to step up into a SP SBC in a multi-tenanted environment. I was comparing AP 3820 with the CUBE Ent ASR1k-x: CUBE provides no HA (though in some documents it says, came out from a meeting with the Cisco SME informing HA is not available), No transcoding (due to lack of DSP on ASR1K), No Multi-tenancy support with all of these features supported in a 3820 SBC Any feature better in CUBE that I may have overlooked? I am aware that CUBE configuration etc. can be easy compared to Acme Packet but apart from that any solid reason to choose CUBE over AP? 2) HA vs Non-HA: HA is obviously the preferred approach and looks like only possible with AP. Can anyone confirm the HA works as claimed by AP? Due to the costs involved in double the equipment – whats the common approach followed here HA or non-HA? 3) Centralised Design: We are planning on a centralised SIP solution (with SBCs at both the DCs), anything to be careful of? 4) Transcoding: CUBE ASR1K
