January 2013 - VoiceOps - lists.voiceops.org

Broadview contact
by matthew＠corp.crocker.com Jan. 23, 2013

Jan. 23, 2013

Does anyone have a contact at Broadview as a carrier interface? I'm running into a brick wall when trying to port numbers away from them. Thanks -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matthew at crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com

1 0

Level 3 On the west coast
by mjacobs76＠gmail.com Jan. 22, 2013

Jan. 22, 2013

Any one seeing packet loss or other issue on the west coast with Level 3?

2 1

Pre-deployment/upgrade and Constant Quality Monitoring
by ghenry＠suretec.co.uk Jan. 21, 2013

Jan. 21, 2013

Hi all, I was wondering what commercial product folks are using for an automated test suite pre deployment and before upgrade roll outs I'm also looking for constant monitoring of things like call setup delays, RTP issues, Jitter, MOS,PESQ Echo etc. other than service status checking, for us and to go on our public service status pages. Had a call about IxLoad already and interested in what others do. Cheers. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry at suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk

6 6

IPSec VPN server
by EWieling＠nyigc.com Jan. 21, 2013

Jan. 21, 2013

We currently have SIP service with VZB, they require signaling go over an IPSec VPN tunnel. Our current VPN box (which is somewhat old) crashes about once per year and we would like to replace it with something which is more reliable. Can anyone recommend rock solid boxes which can handle 10Mbps of IPSec traffic? Our current usage is about 1/2 of that, but I want room to grow.

10 13

911 address policy for company phones at home
by carlos＠televolve.com Jan. 21, 2013

Jan. 21, 2013

Great answer, thanks. This really covers what the customer is asking for, which is basically the stationary option (all phones show one CLID/ANI/location). I will advise them that it's legal, just not advised, and get a written signature for liability. We do use a 911 service provider, we're not a CLEC. We currently provide the ability for a customer to have an address for each individual phone if they choose. On Fri, Jan 18, 2013 at 10:48 AM, Mary Lou Carey <marylou at backuptelecom.com>wrote: > Legally VOIP providers have the option to offer roaming VOIP services or > stationary VOIP services. If you offer roaming VOIP you are required to > provide your customers with a way to update their address information > whenever they move their phone. It can either be a website they log into to > change their address or a 24 hour phone number they call, but either way > you MUST provide it if you allow them to roam. If you do allow them to roam > you have to get your 911 service from a VOIP 911 provider (who has > connections to every PSAP in the country) or be connected to every PSAP in > the country yourself because a connection to the LEC network will only > cover you for the counties or parishes that you establish trunks for. > **** > > ** ** > > Most VOIP providers I know sign up with a VOIP 911 provider because they > cover a large area so it's cheaper to do that then have a multitude of > connections through the LEC. If you decide to go with a stationary VOIP > product, you must have the customer sign a waiver stating that they are > aware that if they move their phone they will not receive 911 service. I > believe the FCC ruled in the last year or so that if you also have to place > some type of sticker on the phone so that the end user who uses the phone > knows 911 is not available when you move it rather than just the person who > ordered the phones. **** > > ** ** > > So the decision is not your customer's, but yours. If you choose to allow > the customer to move their phone then you either have to place a sticker on > the phone stating that 911 service will not be available to the customer OR > you have to provide the customer with a way to change their address > information when they do move the phone. While you could offer either > option to customers based on how much they wanted to pay, I would think > liability wise it would be better if you either offered it to everyone or > no one at all because it would be too easy for one of your employees to > make a mistake in setting someone up and not put them on the right plan.** > ** > > ** ** > > ** ** > > Mary Lou Carey**** > > BackUP Telecom Consulting**** > > marylou at backuptelecom.com **** > > Office: 615-791-9969 x 2001**** > > ** ** > > **** > > ** ** > > *From:* voiceops-bounces at voiceops.org [mailto: > voiceops-bounces at voiceops.org] *On Behalf Of *Carlos Alvarez > *Sent:* Friday, January 18, 2013 9:51 AM > *To:* voiceops at voiceops.org > *Subject:* [VoiceOps] 911 address policy for company phones at home**** > > ** ** > > We have a customer who wants us to block 911 on the phones that they give > to key employees to take home. They don't want to pay fees for 911 service > at each home (which is stupid, since it's so cheap, but that's a > digression). I told them this is "illegal" but they asked to see the law, > and I can't actually find something that says so. Yet that's the common > knowledge around the industry. I do have the FCC documents that require an > ITSP to provide the service, but the customer contends it doesn't apply to > this specific case.**** > > ** ** > > So two questions...**** > > ** ** > > Does anyone here allow their customers to do this?**** > > ** ** > > What is the best document to give the customer to support our position? > **** > > ** ** > > -- **** > > Carlos Alvarez**** > > TelEvolve**** > > 602-889-3003**** > > ** ** > -- Carlos Alvarez TelEvolve 602-889-3003

13 45

Pre-deployment/upgrade and Constant Quality Monitoring
by lakmalfdo＠ymail.com Jan. 21, 2013

Jan. 21, 2013

You may check Arptel, www.arptel.com. ?They are having a system to test your?requirements. Best Regards, Lakmal Fernando?

1 0

CALEA for the small fry operator
by nathana＠fsr.com Jan. 20, 2013

Jan. 20, 2013

We are a small-ish, regional broadband ISP in the U.S. (inland Washington and Idaho) that has also rolled out an interconnected VoIP product over the past year. I'm trying to wrestle through and understand what our responsibilities and obligations are with regards to CALEA compliance at both the legal and technical levels. Confession time: we did not purchase a commercial softswitch product. We built our own solution on top of Asterisk. (I can already hear the groans and feel the tangible disapproval.) We went this route for cost reasons, yes, but more importantly we did it because with a custom-engineered solution, we were able to seamlessly integrate our new voice offering with our other existing products when it comes to both provisioning and billing, and this (I believe) leads to a better and more uniform experience for our customers. For better or worse, we are an ISP first and foremost, and an ITSP second, and provisioning for the new product needed to conform to existing practices rather than be an island unto itself, as so many "turn-key" offerings are. But I recognize that going down this path has brought with it a distinct disadvantage when it comes to solving the CALEA complaince problem. Notably, there are no known CALEA solutions for Asterisk of any stripe that I have been able to find, and any discussion about Asterisk and CALEA seems to have peaked around the time (2006-2007) that the feds announced VoIP providers were going to have to bring themselves into compliance, and then quickly faded after that. Sure, I could easily come up with something that would allow for live or recorded call interception and/or delivery of CDR/CPNI to law enforcement using existing tools already available to me. What is unclear to me, though, is whether there is any particular format or delivery mechanism for this data that the law stipulates we follow. I know that there is an ANSI standard, T1.678v2 (and the subsequent supplements), but of course I have no access to that (200+ page) document without paying the publisher hundreds of dollars for a copy. And even if we got our hands on a copy, it sounds like it would be prohibitively difficult to implement by ourselves. Does the law actually stipulate that T1.678 be followed, and are you not in compliance with CALEA regulations unless you specifically use a solution that is T1.678-compatible? Or is the T1.678 standard simply recommended and preferred by LEAs? I have seen discussion threads where other people have talked about their "creative" solutions to CALEA compliance, which include things such as proxying the RTP stream and having a bank of E&M channels at the ready to mirror the audio to (http://fonality.com/trixbox/forums/trixbox-forums/open-discussion/what-i-ne…) Do these people actually know if their solution gets a passing grade, or are they taking a gamble? Thanks, -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

11 25

CALEA for the small fry operator
by nathana＠fsr.com Jan. 20, 2013

Jan. 20, 2013

Replying to myself here (but still seeking comments from others...). Apologies in advance for the length. The CALEA law states in section 107(a)(2): "COMPLIANCE UNDER ACCEPTED STANDARDS - A telecommunications carrier shall be found to be in compliance with the assistance capability requirements under section 103 [...] if the carrier, manufacturer, or support service provider is in compliance with publicly available technical requirements or standards adopted by an industry association or standard-setting organization..." This would seem to state that the industry is responsible for helping to set standards that can be used to deliver the required information (section 103) to LEA, and so the very existence of standards such as J-STD-025-A/B and T1.678 (both headed by ATIS) and their adoption by the industry I take as an indication that whatever solution we come up with *has to adhere to these technical standards and protocols*, by law. Now, in section 107(b), it is stated that (summarizing here...you can read a copy for yourself that I found @ http://cdn.ientry.com/sites/webpronews/pdf/calea.pdf) if the industry fails to come up with standards, OR if an agency finds the standards to be "deficient", then they can petition the FCC to come up with and enforce a different standard. INTERESTINGLY, at http://en.wikipedia.org/wiki/Lawful_interception there is a comment at the end of the "Technical description" section that mentions that "all of these standards have been challenged as 'deficient' by the U.S. Dept of Justice pursuant to CALEA." I don't know if that means we are currently off-the-hook and in some state of "limbo" right now where any reasonable attempt on a carrier's part to deliver a tap or CDRs pursuant to a court order is considered acceptable, whether or not it adheres to any of the ATIS-led and ANSI-adopted standards released to-date. As far as the standards themselves go, Sid Rao contacted me off-list to inform me that the live signalling format I was asking about earlier is in fact expected to adhere to J-STD-025, transmitted over a VPN, while the live call audio is forked to a PSTN destination. This is interesting, because I did some digging and ran into a product by IP Fabrics (http://www.ipfabrics.com/) called the "DeepSweep." They have a CALEA-for-VoIP edition. The manual (http://www.ipfabrics.com/pdf/VoIP_SM_users_manual.pdf) states that their product adheres to T1.678, which was specifically developed for interconnected VoIP providers (whereas J-STD-025(-A/B) was developed before interconnected VoIP was really a "thing" in the industry and is meant for circuit-switched voice traffic). Perhaps not all agencies know how to deal with T1.678-encapsulated messages yet, or perhaps preference of delivery method varies on an agency-by-agency basis. In any case, section 2.5 of the DeepSweep manual says this: "T1.678 gives the implementer a basic choice in CII messages (section 6.4). One choice is to map SIP (and H.323, if one is providing that, which DeepSweep does not) into J-STD-025 messages defined for circuit-switched telephony. This is called mapped signaling information, or mapped. The other choice is DSR (direct signal reporting), where most of the signaling is delivered on the CII interface by encapsulating the SIP message. DeepSweep implements DSR. Thus the T1.678 message types that are generated are the DSR and DialedDigitExtraction messages, and, if content intercept is authorized, the CCOpen, CCClose, and CCChange. DialedDigitExtraction comes from the VoIP content SM; the others come from the VoIP controller SM." I take this to mean that T1.678 gives you the option of either translating the SIP signalling into J-STD-025 format, OR simply sending the raw SIP dialogs themselves. In either case, it does sound like T1.678 defines some kind of encapsulation protocol that either signalling format needs to be stuffed into before transmission to the LEA's off-site data collector; you can't just mirror the IP or ethernet frames containing the SIP signalling and throw those at them. It is sounding more and more like we are either expected to adhere to these industry standards or are going to be expected to at some point, depending on what the DoJ has actually filed in response to these standards and how section 107(b) of the CALEA of 1994 is to be interpreted. *sigh* Anybody know anything about these DeepSweep appliances? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: Nathan Anderson Sent: Saturday, January 19, 2013 3:26 PM To: 'Carlos Alvarez'; 'voiceops at voiceops.org' Subject: RE: [VoiceOps] CALEA for the small fry operator Carlos, thanks for doing that legwork. A few questions come to mind: 1) What is the "one allowed data standard", and where did you find it referenced? 2) Is there any reference copy of the data standard publicly available? Is it in fact the T1.678 that http://askcalea.fbi.gov/ mentions? 3) What signalling information do they require be recorded and/or streamed in real-time? 4) One might wonder if the concession made to operators not being required to completely redesign their networks was specifically made for those who had networks operating before CALEA compliance was made mandatory. Is there any reason to believe that those of us who have started up networks in the last year or two, well after the CALEA requirements were put in place, cannot use this excuse? It seems to me they could try to argue that we should have known at the outset that this would be required of us, and should have planned our network accordingly. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez Sent: Saturday, January 19, 2013 8:13 AM To: voiceops at voiceops.org Subject: Re: [VoiceOps] CALEA for the small fry operator I'm trimming all previous replies because this isn't in reply to any one thing. I spent several hours last night reading FCC docs, FBI stuff, and whatever I could find on this topic. There are a few bullet points that stuck in my mind. These are according to my interpretation, and while I've been reading FCC and other legal stuff for a very long time, I'm not a lawyer and my expertise isn't in law. It seems that there is one allowed data standard, but repeatedly I saw that the FCC refused to limit delivery methods, particularly for packet-switched networks. It seems to me that a meetme in Asterisk is almost compliant, though missing some of the signaling stuff. There is in fact an option on the FCC compliance form for "proprietary/home-grown" solution. On that topic however, I repeatedly saw "if reasonably available." The FCC says that you must provide all the signaling requested "if reasonably available" at the network intercept point. They specifically said they don't expect operators to completely redesign their networks. This of course is rather unclear. From our perspective, as a tiny company, it would be easy to argue that it's not reasonable for us to spend 50% of a year's profit changing our network. I may be crazy and that may not work, I don't know. You can charge any time you get a request for records or intercept. Actually a lot. As a comparative number, Comcast charges $1k to set up an intercept and provide a month of service, $750/mo thereafter. They charge $200/mo for weekly call record delivery. -- Carlos Alvarez TelEvolve 602-889-3003

3 3

CALEA for the small fry operator
by nathana＠fsr.com Jan. 18, 2013

Jan. 18, 2013

(Given how you opened your e-mail, I'll assume that you actually meant to send your reply to the list instead of only to me, so I'm putting the VoiceOps address back on the recipients list. Apologies if this is not what you wanted.) So it would seem that the concensus so far is that you simply have to be prepared to offer a LEA some kind of recording or live stream in a format that can be reasonably thought of as being a standard (or widely understood/decodeable). If that is the case, who can explain to me what exactly the purpose of this ANSI T1.678 document is, and who is expected to use it? -- Nathan Anderson First Step Internet, LLC nathana at fsr.com -----Original Message----- From: Faisal Imtiaz [mailto:faisal at snappydsl.net] Sent: Friday, January 18, 2013 3:01 PM To: Nathan Anderson Subject: Re: [VoiceOps] CALEA for the small fry operator I would love to hear comments and discussion on this topic, from others who may be more knowledgeable and or had experience in providing the info requested in a CALEA Warrant. My Comments are in-line below:- Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: Support at Snappydsl.net On 1/18/2013 4:54 PM, Nathan Anderson wrote: > We are a small-ish, regional broadband ISP in the U.S. (inland Washington and Idaho) that has also rolled out an interconnected VoIP product over the past year. I'm trying to wrestle through and understand what our responsibilities and obligations are with regards to CALEA compliance at both the legal and technical levels. Great, you are in the same boat as a lot of us here. > Confession time: we did not purchase a commercial softswitch product. We built our own solution on top of Asterisk. (I can already hear the groans and feel the tangible disapproval.) We went this route for cost reasons, yes, but more importantly we did it because with a custom-engineered solution, we were able to seamlessly integrate our new voice offering with our other existing products when it comes to both provisioning and billing, and this (I believe) leads to a better and more uniform experience for our customers. For better or worse, we are an ISP first and foremost, and an ITSP second, and provisioning for the new product needed to conform to existing practices rather than be an island unto itself, as so many "turn-key" offerings are. Don't beat yourself up too bad for having done this, there is nothing wrong with it, and you are neither alone nor the first one to do so. The key test from business side is , if it works and you can make $ with it .. then just keep doing it ... you must be doing something right. > But I recognize that going down this path has brought with it a distinct disadvantage when it comes to solving the CALEA complaince problem. Notably, there are no known CALEA solutions for Asterisk of any stripe that I have been able to find, and any discussion about Asterisk and CALEA seems to have peaked around the time (2006-2007) that the feds announced VoIP providers were going to have to bring themselves into compliance, and then quickly faded after that. There is no disadvantage here.... just a lack of open discussion and a lot of phoo-phooing from folks who had spent a lot of $ on their switches, and found out that others were getting similar results on the Telephony side of things. > Sure, I could easily come up with something that would allow for live or recorded call interception and/or delivery of CDR/CPNI to law enforcement using existing tools already available to me. What is unclear to me, though, is whether there is any particular format or delivery mechanism for this data that the law stipulates we follow. I know that there is an ANSI standard, T1.678v2 (and the subsequent supplements), but of course I have no access to that (200+ page) document without paying the publisher hundreds of dollars for a copy. And even if we got our hands on a copy, it sounds like it would be prohibitively difficult to implement by ourselves. All of my research todate shows that there is no CALEA standard. The Law requires cooperation and delivery of the Data Stream to the Law Enforcement Agency requesting it, but it does not specify any particular standard. The impression I get is that, a number of formats may be acceptable by different agencies. The actual format gets to be agreed upon with the agency requesting the the info. > Does the law actually stipulate that T1.678 be followed, and are you not in compliance with CALEA regulations unless you specifically use a solution that is T1.678-compatible? Or is the T1.678 standard simply recommended and preferred by LEAs? I have seen discussion threads where other people have talked about their "creative" solutions to CALEA compliance, which include things such as proxying the RTP stream and having a bank of E&M channels at the ready to mirror the audio to (http://fonality.com/trixbox/forums/trixbox-forums/open-discussion/what-i-ne…) Do these people actually know if their solution gets a passing grade, or are they taking a gamble? Since the Law does not specify what is acceptable, as such it also does not specify what is not acceptable, thus making all of the above very viable methods of delivering the data. I believe the passing grade is in having the ability to send them the data stream, and not necessarily in what format it is in. After-all they have Computer Folks on their side too who can just as easily assemble the real time data stream back into a Voice Recording, which is what they are trying to get. > Thanks, >

2 1

911 address policy for company phones at home
by carlos＠televolve.com Jan. 18, 2013

Jan. 18, 2013

We have a customer who wants us to block 911 on the phones that they give to key employees to take home. They don't want to pay fees for 911 service at each home (which is stupid, since it's so cheap, but that's a digression). I told them this is "illegal" but they asked to see the law, and I can't actually find something that says so. Yet that's the common knowledge around the industry. I do have the FCC documents that require an ITSP to provide the service, but the customer contends it doesn't apply to this specific case. So two questions... Does anyone here allow their customers to do this? What is the best document to give the customer to support our position? -- Carlos Alvarez TelEvolve 602-889-3003

7 6