- VoiceOps - lists.voiceops.org

Issue with Adtran TA9xx/Broadworks/Session Audit Timers
by RDawson＠alliedtelecom.net Jan. 7, 2013

Jan. 7, 2013

Having an issue where occasionally a TA9xx doesn?t see an ack for a session audit timer invite event and will then reply with a 500 "re-invite inside a re-invite" error on the next invite. I am investigating the possibility of a network side issue now but wondering if anyone else has dealt with this? Thanks, Rob

1 0

VoIP on 10mb Cat 3 switched network
by carlos＠televolve.com Jan. 6, 2013

Jan. 6, 2013

Has anyone had experience successfully running VoIP over 10mb Cat 3 cabling? A new customer has asked, because that's what they have in place. I'm not interested in an unreliable solution just to save a few bucks, but in theory it should work reliably to have a dedicated 10mb to each phone and then gigabit out of the main switches. -- Carlos Alvarez TelEvolve 602-889-3003

12 14

IAD and SIP PBX Hardening Guidelines
by lindsey＠e-c-group.com Jan. 5, 2013

Jan. 5, 2013

Are there any published hardening guidelines or howtos on IADs, SIP PBXs, or and any other SIP devices on the public Internet? If not, we should put some together. For IADs, the list might start with some of the same rules you'd use on any other router. But for IADs or SIP PBXs, it seems like these two are pretty important: Restricting remote login; Restricting SIP. (1) Restrict telnet, ssh, snmp to only Administrator locations, by IP. Many of the recent attacks happening at service providers are IAD or SIP PBX compromises. These devices are often on the public Internet, and they have poor passwords. BadGuy just scans for telnet-accessible devices, logs in, and then sets up the IAD to route calls. Or he may just simply steal the SIP credentials. I can't think of good reasons that these IADs should allow telnet, ssh, or snmp from the public Internet at large. Of course, the administrators of the device (often the voice SP itself) needs to be able to login. As an alternative, you might just ensure that strong passwords are used. Lots of folks are moving to RADIUS authentication for IADs, on the hopes that they'll use better usernames and passwords. (2) Restrict SIP & RTP to only the Service Provider's SBCs, by IP. On some IADs, you can send SIP to the device's SIP stack just by sending it SIP to port UDP/5060. A lot of IADs are CPU-poor anyway, so giving them extra SIP parsing isn't going to help. In fact, just sending in bogus SIP can be enough to DoS the device. But in our world of (a) buffer overflows and code injection and (b) complex parsing of SIP, it seems intrinsically risky to allow BadGuy to send SIP in to a CPE. It seems very likely that a determined attacker could use specially-crafted SIP messages to cause a SIP IAD or phone to do anything they want: -- Make fraudulent calls -- Play advertisements -- Send a copy of the RTP to a mysterious destination on the Internet Some of the same risks are present with RTP. But fortunately, RTP is simple enough that hardening the implementation may be easier. And often RTP is handed directly to a DSP, where (I would guess) the opportunities for code injection are less interesting. But there's a real downside here: What if you need to manage SIP traffic, and allow IADs to register to some other location? If you're doing it RFC3263 style, then you might just be using DNS to route IADs and PBXs to the appropriate SBC. If you need to add additional SBCs, then you have to be sure the IAD will have ACLs that allow traffic from those other SBCs in advance. Finally: What about the poor souls who put SIP phones directly on the Public Internet? Maybe you can change the administrator password, and make it harder to login and extract the SIP authentication credentials. But beyond that, SIP phones don't typically have firewall-type features. I think the better bet here is to put them behind a stateful firewall/NAT device. Any other opinions? >>> mark at ecg.co +12293160013 http://ecg.co/lindsey

2 1

Real-time single stream RTP monitoring
by rkusler＠intermedia.net Dec. 18, 2012

Dec. 18, 2012

Hey all, I am wondering if anyone knows about a simple UAC-like tool that can establish a single concurrent long-running call to another SIP endpoint and monitor the incoming RTP. If, in real-time, it detects a significant drop in RTP (or other audio degradation), it could run a command line tool. I'm not looking for software that captures lots of calls or does advanced analytics.. I'm really just hoping for something that alerts us to an issue in real-time while a call is still active. Does anyone know of anything like this? Or will I have to roll it myself? I appreciate any suggestions that you can offer! =) Ross Kusler VoIP Systems Engineer Intermedia

4 3

MSX / Genband S3
by EWieling＠nyigc.com Dec. 12, 2012

Dec. 12, 2012

We are in the process of moving our MSX aka Genband S3 out of service over the following months and are wondering if there is anyone out there which does per-incident support for this platform. We are very unhappy with Genband and Voiplogic support and they only provide support via a yearly contract.

3 2

CSR Request?
by david＠ringfree.biz Dec. 11, 2012

Dec. 11, 2012

Hi All, A question for you that I've never been able to get an answer too. We are a small hosted VOIP shop. And we port numbers through various aggregators (example vitelity) When we are porting phone numbers I am occasionally asked for a CSR by the gaining carrier (Or the aggregator that we are using). Sometimes they are able to get the CSR and sometimes they are not. However, when I call the losing carrier they always state that they don't give out CSR's. And that the winning carrier needs to request the CSR. One of the two parties is giving bad information , and I can't ever tell which one. Are there rules that govern the CSR requests? If there a way that we can ever do a CSR request without going through the consumer channels? Thanks David

4 10

CSR Request?
by nick＠flhsi.com Dec. 11, 2012

Dec. 11, 2012

We've had Vitelity tell us the same thing tons of times. To the point that as soon as they ask I don't even attempt to get them from ATT. I just remind them that ATT doesn't give CSR's to us. And they just some how deal with it. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "David Wessell" <david at ringfree.biz> Sent: Tuesday, December 11, 2012 2:19 PM To: "Carlos Alvarez" <carlos at televolve.com> Subject: Re: [VoiceOps] CSR Request? Carlos! Nice to see you on this list too! In this particular case we are porting numbers from AT&T (bellsouth) into vitelity whom I am sure is using bandwidth.com. Vitelity states that only the losing carrier can get the csr, and AT&T of course tells me that only the gaining carrier can request it. And the port sits in limbo. I'll go back and hammer at vitelity and see what I can get out of them. Thanks to everyone that confirmed there aren't standards on csr requests! :) ---- David Wessell 828-575-0030 http://ringfree.biz On Dec 11, 2012, at 2:04 PM, "Carlos Alvarez" <carlos at televolve.com> wrote: On Tue, Dec 11, 2012 at 11:16 AM, David Wessell <david at ringfree.biz> wrote: However, when I call the losing carrier they always state that they don't give out CSR's. And that the winning carrier needs to request the CSR. One of the two parties is giving bad information , and I can't ever tell which one. Are there rules that govern the CSR requests? If there a way that we can ever do a CSR request without going through the consumer channels? This whole process is a mess and everybody is wrong except a few of the biggest carriers. We are the same type of company as you and we've heard the same things. We have been asking a customer for a copy of their bill to make it easy, but believe it or not, sometimes the important CSR info is different from the bill. We tried telling customers to request CSR from their own carrier, and about half of them refuse. We've tried sending LOAs to the losing carrier and about half just ignore us. Qwest/CenturyLink oddly has been the easiest to work with (didn't expect that) and Cox the absolute worst of all the majors. -- Carlos Alvarez TelEvolve 602-889-3003

2 1

Are 911 stickers a joke?
by carlos＠televolve.com Dec. 10, 2012

Dec. 10, 2012

How are the rest of you dealing with this? The amount of required or suggested info is too large for something small and discreet. Or you end up with super-fine print...does that meet the requirements? Do any of your customers actually use them if you hand them a pile? The whole thing seems like an ignored joke. I'm thinking about it as we cut over a medium-size new customer from a major national provider, and I don't see stickers or warnings anywhere in the building. -- Carlos Alvarez TelEvolve 602-889-3003

2 1

MD/DE/PA VZ Terrortory
by joquendo＠e-fensive.net Dec. 7, 2012

Dec. 7, 2012

Apologies for the typo on subject line (territory). Anyone else have issues with calls terminated on Verizon switches down in the MD/DE/PA areas? (Greenbelt, Cumberland, etc) I have something of a travel card like set up going on with a huge portion of callers in that area (MD/PA/DE) and have found one commonality: 90+% of the terminations are on VZ switches. I have re-routed calls through who knows how many carriers at this point (Paetec, Level3, Global), etc yet calls with a duration of about 20-40 minutes cut off for no rhyme or reason. My end of the call simply sees a normal hangup... My client? They believe we are the ones disconnecting the call. While I could open up a call with either one of my carriers, (and I have) the outcome is and has been pretty much the same... So again, is it me? Feel free to offline a response if needed. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT, RWSP, GREM "Where ignorance is our master, there is no possibility of real peace" - Dalai Lama 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF

2 1

Ambiguous dial plan pattern matching
by nathana＠fsr.com Dec. 6, 2012

Dec. 6, 2012

Sorry for what probably will end up sounding like a rather noob-ish question, but I still consider myself a relative greenhorn... We are a VoSP. With the advent here in the U.S. of area code overlays, 10-digit dialing, and even carriers/vendors (VoIP and wireless, mostly) continuing to blur the distinction between local and toll calls (at least from the end-user's perspective), it is not an uncommon thing to run into service platforms where both 7- and 10-digit dialing is supported, but the 7-digit support feels (again, from the customer's perspective) half-assed, at least compared to the ILEC's implementation. But if the customer still lives in an area where 10-digit dialing is not mandatory, he/she expects it to work, so we "have" to provide it. It feels inferior because back when when local destinations were always within the same NPA as the caller, the number pattern rules were simple, at least for domestic calls: if it starts with a 1, it will be an 11-digit number, and if it starts with 2-9, it will be a 7-digit number; but now, if it starts with 2-9, it could be either 7 or 10 digits, and you won't know for sure which one it is unless the caller has entered more than 7 digits. And in these ambiguous scenarios where two destination patterns partially overlap, it's the "did the caller stop dialing" part that's hard to measure, right? So now you have CPE gear generating dialtone (whether PBX or ATA) which either feels to the caller like it is extremely slow at putting the call through, or which requires the caller to remember to do something special at the end of a 7-digit destination (like dial # or something to signal they're done) if they don't want to wait. (There's also been a similar phenomenon for a while with PBX systems that use outbound routing prefixes like '9' in order to make it unambiguous whether you are dialing an internal extension or an external destination.) Now obviously the CO switch can't read minds either, so in areas without mandatory 10-digit dialing, it seems inescapable that it would have to determine whether the user is done dialing via some kind of timeout mechanism as well. But it sure seems like most Class 5 switches must have a much more intelligent ambiguous number pattern matching algorithm than most CPE gear does since, as a general rule, people that still have an analog loop to the CO these days and regularly dial 7 digits don't experience (e.g.) upwards of a 5-second delay between when they've finished dialing and when they hear their first ringback. The question is, what's the secret sauce, and why can't that same algorithm be implemented in CPE gear? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

6 6