- VoiceOps - lists.voiceops.org

Acme SBC geographic redundancy
by jnesheim＠cytek.biz Sept. 6, 2009

Sept. 6, 2009

Right, that would impact existing established calls and subscriptions. However, larger problem is that in a failover condition endpoints would begin sending SIP Invites to a SBC (pair) that does not have a valid registration cached, and depending on the configuration, SIP port map. Depending on the re-registration interval, this could result in outbound call failures for anywhere for a couple minutes to an hour or more. In the reverse direction the inside SBC IP would be unique at each site. This would render the metaswitch unable to contact the endpoint for PSTN -> VoIP calls for the period of re-registration as well. -- Jason Nesheim ----- Original Message ----- From: "Alex Balashov" <abalashov at evaristesys.com> To: "Jason L. Nesheim" <jnesheim at cytek.biz> Cc: "Brad Anouar" <Brad at broadcore.com>, voiceops at voiceops.org Sent: Sunday, September 6, 2009 5:39:46 PM Subject: Re: [VoiceOps] Acme SBC geographic redundancy Jason L. Nesheim wrote: > If you're going to use SRV records in an Access deployment with > registration caching on the Acme SBC one thing to keep in mind is that > non-HA SBCs (or two separate pairs) will not share their registration > and NAT databases. I would imagine they don't share transaction and dialog state either. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775

3 2

SIP traffic modeling
by jnesheim＠cytek.biz Sept. 6, 2009

Sept. 6, 2009

Ixia (IxLoad, IxVoice at limited volumes), Spirent (Abacus), and Hammer (G5, not the Edge) all make test platforms that can be scripted to perform various SIP and RTP operations and analyze the results at high volumes. Based on what you're describing it sounds like you might want to give one of these platforms an eval, just be prepared for some sticker shock. -- Jason Nesheim ----- Original Message ----- From: "Joe Bell" <Joe_Bell at adp.com> To: voiceops at voiceops.org Sent: Thursday, September 3, 2009 9:52:23 AM Subject: [VoiceOps] SIP traffic modeling Hey Guys, I was wondering what everyone uses for modeling SIP traffic, associated media sessions, and various call movement operations like Hold, Park, transfer, etc.. I know of Hammer, and that?s cool for throughput, but I was trying to find a tool that can send and measure large amounts of SIP signaling along with the associated media. We are looking at SIPp and lots of scripts, but I wanted to hear from the forum what other tools have been investigated. Thanks, Joe Bell CCIE 6722, R&S, Voice 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

1 0

Acme SBC geographic redundancy
by jnesheim＠cytek.biz Sept. 6, 2009

Sept. 6, 2009

If you're going to use SRV records in an Access deployment with registration caching on the Acme SBC one thing to keep in mind is that non-HA SBCs (or two separate pairs) will not share their registration and NAT databases. -- Jason Nesheim ----- Original Message ----- From: "Brad Anouar" <Brad at broadcore.com> To: voiceops at voiceops.org Sent: Thursday, September 3, 2009 4:25:10 PM Subject: Re: [VoiceOps] Acme SBC geographic redundancy I agree with Alex, SRV records could be a more realistic solution for the access side given that you are willing to accept some post dial delay in failover mode. If you plan on using ACME for peering, since most providers don't support SRV records, you will have to provide them with multiple IPs and the order in which you would like them to be used. Brad Anouar Director - Systems Engineering P: 310-360-2028 F: 310-360-2029 brad at broadcore.com -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov Sent: Thursday, September 03, 2009 4:03 PM To: Brandon Buckner Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Acme SBC geographic redundancy As with any HA setup of IP nodes, the main problems boil down to: 1. Adequate network bandwidth and network availability between the primary and standby unit (or silo) for reliable and sufficiently low-latency synchronisation of various information (config changes, standby status, any call state information shared among them in Acme's HA setup, etc.); 2. The more common way to make them effectively redundant from a user perspective is to have them share an IP address, in which case it is necessary to ensure that the traffic destined for that IP network can pass into the other POP in the event of a failure, which requires complicated integration with your BGP and/or IP connectivity arrangements and any interior routing protocols you may be running. A more realistic approach is to have all the clients use an SRV record - if all your clients are capable of SRV lookups - and specify the secondary with lower priority, avoiding the complexities of IP sharing across disparate geographic sites altogether. -- Alex Brandon Buckner wrote: > Is anyone doing geographic redundancy with their Acme Packet SBCs? We've > got an HA pair of nn4250s right now and are installing a new Metaswitch > system that is geographically redundant at two locations with external > call agents, TDM links, etc. We'd like to get SIP to be the same. I'm > still waiting on a response from our Acme SE about it but wanted to see > what others had done, if anything. I figure some discussion will spark > questions I can bring up with Acme as well. -- Alex Balashov - Principal 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 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

2 1

Acme SBC geographic redundancy
by carlos＠race.com Sept. 4, 2009

Sept. 4, 2009

Brandon, Have you talked to your Metaswitch se they are now fully supporting the acme with the Metaswitch so you don't have to be dealing with 2 different groups pointing the finger at each other saying it's there fault. We purchased the acme directly thru meta so we didn't have to deal with so many parties. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 F: 650.649.3551 From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brandon Buckner Sent: Thursday, September 03, 2009 3:57 PM To: voiceops at voiceops.org Subject: [VoiceOps] Acme SBC geographic redundancy Is anyone doing geographic redundancy with their Acme Packet SBCs? We've got an HA pair of nn4250s right now and are installing a new Metaswitch system that is geographically redundant at two locations with external call agents, TDM links, etc. We'd like to get SIP to be the same. I'm still waiting on a response from our Acme SE about it but wanted to see what others had done, if anything. I figure some discussion will spark questions I can bring up with Acme as well. Thanks, ---- Brandon Buckner Switching Technician / VoIP Admin Iowa Network Services brandonb at netins.com

2 1

Acme SBC geographic redundancy
by BrandonB＠netins.com Sept. 3, 2009

Sept. 3, 2009

Is anyone doing geographic redundancy with their Acme Packet SBCs? We've got an HA pair of nn4250s right now and are installing a new Metaswitch system that is geographically redundant at two locations with external call agents, TDM links, etc. We'd like to get SIP to be the same. I'm still waiting on a response from our Acme SE about it but wanted to see what others had done, if anything. I figure some discussion will spark questions I can bring up with Acme as well. Thanks, ---- Brandon Buckner Switching Technician / VoIP Admin Iowa Network Services brandonb at netins.com<mailto:brandonb at netins.com>

4 3

Mobile phone location info
by james.q.haney＠gmail.com Sept. 3, 2009

Sept. 3, 2009

Is there any way to find the physical location of a mobile phone to within 15 or so miles? We're a basic SIP shop, but I was wondering if something like SS7 would get me some of that info. I don't want to rely on GPS or wi-fi, and it doesn't have to be precise. Mostly just trying to find out what city the phone is in.

2 1

SIP traffic modeling
by Joe_Bell＠adp.com Sept. 3, 2009

Sept. 3, 2009

Hey Guys, I was wondering what everyone uses for modeling SIP traffic, associated media sessions, and various call movement operations like Hold, Park, transfer, etc.. I know of Hammer, and that's cool for throughput, but I was trying to find a tool that can send and measure large amounts of SIP signaling along with the associated media. We are looking at SIPp and lots of scripts, but I wanted to hear from the forum what other tools have been investigated. Thanks, Joe Bell CCIE 6722, R&S, Voice 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.

1 0

Offtopic (SBC recommendations)
by carlos＠race.com Sept. 2, 2009

Sept. 2, 2009

I?m on the acme bandwagon as well just got it in monday sitting here next to my desk installing it next week. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of anorexicpoodle Sent: Wednesday, September 02, 2009 2:37 PM To: Junaid Hattia Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Offtopic (SBC recommendations) I'll jump in on the Acme bandwagon. Very happy with them. On Wed, 2009-09-02 at 23:13 +0200, Junaid Hattia wrote: Another for acme! We running 4250's and soon 4500's with no problems...*touch wood* On 2009/09/02 9:46 PM, "Mike Callahan" <mcallahan at bullseyetelecom.com> wrote: > +1 for Acme. Wish I was running them instead of NexTone's crap. > > -----Original Message----- > From: voiceops-bounces at voiceops.org > [mailto:voiceops-bounces at voiceops.org]On Behalf Of J. Oquendo > Sent: Wednesday, September 02, 2009 2:42 PM > To: voiceops at voiceops.org > Subject: [VoiceOps] Offtopic (SBC recommendations) > > > > Hey all, (I'm sure for those who I criss-cross lists with - you've seen > it before)... > > We're definitely looking to replace our outgoing Nutrakes > (pre-audiocodes assimilation) and we've been looking at a few. While I > will say I'm impressed with Acme and Covergence (which is now Acme > anyway), anyone care to either off or on list comment about others > you've had success with. Any particular one with perhaps a pre-paid > system/spinoff/module/compartment/* (don't ask) is a plus. > > Keep in mind, the less interops (big 4, VZ, GLBX, L3, AT&T) we can do, > the better! (hooray for less work on the plates). > > So far, as stated, I personally liked Covergence's offering as have I > Acme, haven't looked at Sonus yet, but was wondering what else are we > (myself and colleagues) missing. Newport Networks is pretty much gone > the puppets.com, socks.com, VirtualAvenue, Xoom route of the dinosaur. > So without further a rambling... Suggestions. > > > -- > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > J. Oquendo > SGFA, SGFE, C|EH, CNDA, CHFI, OSCP > > "It takes 20 years to build a reputation and five minutes to > ruin it. If you think about that, you'll do things > differently." - Warren Buffett > > 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E > > _______________________________________________ > 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 Please note: This email and its content are subject to the disclaimer as displayed at the following link http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm. Should you not have Web access, send a mail to disclaimers at is.co.za and a copy will be emailed to you. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

2 1

LRN for VoIP
by jarrod＠fed-com.com Sept. 2, 2009

Sept. 2, 2009

Does anyone here have any recommendation for a reliable VoIP LRN provider other than Neustar and or Synniverse or some other solution other than routing SIP calls to someone's proxy where they inject a SIP header with the LRN? For the past year we have been using a certain provider in Clevland who is having issues and seems to not be reliable.. I have heard of some using SS7 to get the LRN for a DNIS but haven't seen it work in a all VoIP environment. Is there a cost effective way to get this information or do you have to go the Neustar route? -- Jarrod Lash, <jarrod at fed-com.com> Federated Communications Office: +1-412-357-2127 Mobile: +1-412-999-0049 Fax: +1-412-545-8368

4 6

Defect rate
by hiersd＠gmail.com Sept. 2, 2009

Sept. 2, 2009

Hi, Do you ever feel like you're part of your vendor's QA department? Sometimes it seems that the number and severity of the patched defects seems to be pretty high in our field, and that most of the patched defects should have never made it out of QA and into GR in the first place. Thanks, David

1 0