- VoiceOps - lists.voiceops.org

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. 19, 2013

Jan. 19, 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

Conversent Communications rejects port out request for incorrect account number
by orenyny＠gmail.com Jan. 16, 2013

Jan. 16, 2013

Hi, Does anybody have a clue why all of a sudden carriers started rejecting port out requests for an incorrect account number? Specifically done by Conversent Communications, but I think that L3 and Global Crossing also started rejecting requests with this reason. Until now this type of rejection was received for cell phone numbers only. Any idea how to resolve it? Thanks, Oren

3 4

SIPNOC 2013 starts April 22
by lindsey＠e-c-group.com Jan. 15, 2013

Jan. 15, 2013

The SIPForum conference, SIPNOC, starts earlier this year -- April 22. You guys who have opinions and painful experiences -- come and give your talk! SIPNOC is the top engineering meeting for this industry. It's not about sales pitches or vendor demos; it's about ideas and practices from the people making VoIP Networks operate. >>> mark at ecg.co +12293160013 http://ecg.co/lindsey Begin forwarded message: From: "Marc Robins" <marc.robins at sipforum.org> Subject: [Sipnocus2012-attendees] The SIP Forum Opens Call for Presentations for SIPNOC 2013 Date: January 15, 2013 15:12:32 United States Time (New York) To: <sipnocus2012-attendees at sipforum.org> Reply-To: marc.robins at sipforum.org Proposals are now being accepted for workshops, panels, speaker presentations and ?Birds of a Feather? sessions addressing the deployment of SIP in service provider environments; Early Bird registration special has been extended to February 1, 2013 The SIP Forum has announced that it has opened the official Call for Presentations for the third annual SIP Network Operators Conference (SIPNOC 2013), being held at the Hyatt Dulles Hotel in Herndon, VA, April 22 -25, 2013. SIPNOC 2013 has been expanded to a three-day educational conference, focusing on the challenges and opportunities related to the deployment of SIP-based carrier services. Organizers invite companies, executives and industry insiders to propose presentations highlighting the use of session initiation protocol (SIP) in service provider environments. Operators are encouraged to present SIP-related success stories, deployment issues and concerns in their networks, while equipment vendors and other industry stakeholders are invited to work with operators to present real-world deployment experiences. SIPNOC 2013 attendees will include telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. Early Bird Registration for attending SIPNOC 2013 is now open, and participants registering before February 1 save $145. Click here to register or visit http://www.regonline.com/sipnoc2013. SIPNOC 2013 Call for Presentations proposals can be submitted by visiting the SIP Forum Call for Presentations site. Possible topics can include SIP peering, SIP trunking, Emergency Services, Congestion Control, Scaling and Capacity Issues, SIP-based applications, Routing, Security, SIP-Network Operations Center Best Practices, IPv6 deployment challenges, User-agent Configuration, Standardization Issues and Progress, HD voice deployments, Video Interoperability, WebRTC and SIP, FoIP/T.38 Deployment, Testing or other issues facing SIP network operations. SIPNOC 2013 offers several different types of speaking opportunities including: ? General Session Talks: A General Session presentation should be on a topic of interest to the general SIPNOC audience, and may be up to 30 minutes long (including time for Q&A). ? General Session Panels: Panels are sessions with a moderator and a team of panelists. The panel moderator should submit an abstract on the panel topic, a list of panelists, and how the panel will be organized. Panel selection is based on the importance, originality, focus and timeliness of the topic, expertise of proposed panelists, as well as the potential for informative and controversial discussion. ? Special Workshops: The SIPNOC 2013 program has been expanded to include special workshops that run for 2-3 hours, providing time to focus in-depth on a variety of issues important to the SIPNOC community. Topics can include a review of SIP RFCs and standards development, the regulatory environment, etc. ? Research Topics: Researchers are invited to present short summaries of their work for operator feedback. Topics may include call routing, network performance, statistical measurement and analysis and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. ? BOFs: BOFs (Birds of a Feather sessions) are informal sessions on topics which are of interest to a portion of the SIPNOC community. BOFs may be held in break?out areas or in an unscheduled room. Requests for scheduled BOFs can be made at any time, including on site at the show. Acceptance notifications for speaking at SIPNOC 2013 will be sent by the Program Committee in early March. Conference registration fees will be waived for any confirmed speakers. The following is a complete list of key dates for the SIPNOC 2013 speaking program: SIPNOC 2013 Call for Presentation Key Dates Presentation Abstracts January 25, 2013 Draft Presentations Due February 15, 2013 Acceptance Decision and Notifications March 1, 2013 Draft Program Published March 11, 2013 Final Presentations Due March 25, 2013 Final Agenda Published Conference Begins April 1, 2013 April 22, 2013 The SIPNOC 2013 event website is located at www.sipnoc.org. SIPNOC 2013 Call for Presentations General Info To view the official call for presentations, which includes instructions on submitting material and specific SIPNOC policies, please visit www.sipnoc.org. To submit, visithttps://www.easychair.org/conferences/?conf=sipnoc2013. SIPNOC Early Bird Registration Info: Deadline February 1, 2013 Save $145 if you register for SIPNOC 2013 by February 1. A special early-bird registration rate of $850 ? $145 off the regular rate of $995 ? is now in effect! Register at http://www.regonline.com/sipnoc2013. SIPNOC 2013 General Show Info For more information about SIPNOC 2013, please visit www.sipnoc.org or send an email tosipnocinfo at sipforum.org. SIPNOC 2013 Sponsorship Info For information about corporate sponsorship opportunities at SIPNOC 2013, please contact Marc Robins, SIP Forum President and Managing Director, at 203-829-6307 or marc.robins ?at?sipforum.org. ************************* Marc Robins President and Managing Director SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins *************************

1 0

Twitter Blacklist feed
by sil＠infiltrated.net Jan. 10, 2013

Jan. 10, 2013

So I rebuilt/redesigned/re-deployed a script to add bad hosts to a blacklist. Script is monitoring my SBCs, hosted PBXs, etc., aggregated, sorted, then reported. Tried to remove duplicate addresses. Also, because I deal with forensics and malware, I did a similar script for bad sites that are serving out malware. For VoIP attacks, one can make a script to check for VoIP based attackers and block them on the fly. E.g,: links -dump twitter.com/efensive|awk '/VoIP/' To make say an automated ipfilter rule: links -dump twitter.com/efensive |\ awk '{print "iptables -A INPUT -s "$1" -j DROP"}' |sort -u|\ sh Same goes for any other style rule (ASA, PIX, ScreenOS on the command line) You get the point. Enjoy. (Cross posted to Voice Ops) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

4 3

4
by naushit＠yahoo.com Jan. 10, 2013

Jan. 10, 2013

http://whaouh.com/market/inMaking%20money%20from%20home%20has%20never%20bee…!

1 0

Twitter blacklist feed
by joquendo＠e-fensive.net Jan. 9, 2013

Jan. 9, 2013

So I rebuilt/redesigned/re-deployed a script to add bad hosts to a blacklist. Script is monitoring my SBCs, hosted PBXs, etc., aggregated, sorted, then reported. Tried to remove duplicate addresses. Also, because I deal with forensics and malware, I did a similar script for bad sites that are serving out malware. For VoIP attacks, one can make a script to check for VoIP based attackers and block them on the fly. E.g,: links -dump twitter.com/efensive|awk '/VoIP/' To make say an automated ipfilter rule: links -dump twitter.com/efensive |\ awk '{print "iptables -A INPUT -s "$1" -j DROP"}' |sort -u|\ sh You get the point. Enjoy. (Cross posted to Voice Ops) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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

1 0

CTI Group call recording
by David.Hiers＠adp.com Jan. 8, 2013

Jan. 8, 2013

Anyone out there using CTI for call recording? 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.

1 0