August 2009 - VoiceOps - lists.voiceops.org

Trunk Group Identity on Cisco IOS
by mh＠markholloway.com Aug. 6, 2009

Aug. 6, 2009

I would like to provision a Broadworks trunk group and use Trunk Group Identity to allow Unscreened Calls (R14.SP9). Does anyone know how to configure TGI on a Cisco router or IAD? Thanks, Mark

1 1

The big ENUM question (Was: VPFs)
by carlos＠race.com Aug. 6, 2009

Aug. 6, 2009

That part of the SS7 network is very true there are trusted service providers running them on top of that it actually takes some capital to be able to interconnect into the ss7 network which most people that are just trying to cause havic aren't going to be up for. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Hiers, David Sent: Thursday, August 06, 2009 10:44 AM To: John Todd; voiceops at voiceops.org Subject: Re: [VoiceOps] The big ENUM question (Was: VPFs) Every time this comes up, I find myself longing for the security, trustworthiness, and reliability of the physically separate, media-free, well-defined-trusted-service-providers-only network that is SS7. Even when the main attack tool was a simple PSTN analog phone and a box of cracker jacks, we found it necessary to bear the tremendous expense of creating SS7 to get the security (and features) that was needed. It is probably possible to run a signaling plane on the internet that can replace SS7, but it's a pretty tall order. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of John Todd Sent: Wednesday, August 05, 2009 2:44 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] The big ENUM question (Was: VPFs) Comments in-line. On Aug 5, 2009, at 11:19 AM, Mark R Lindsey wrote: > At IPTComm a couple of years ago, Jonathan Rosenberg stood up and said > the big problem was the walled gardens that are telcos and ITSPs. We > carriers just aren't passing traffic via VoIP. Even Cisco customers > aren't passing traffic within their own company; you'd have a BTS over > here and a BTS over there, owned by the same Cable MSO, passing > traffic via ISUP. > > Continuing this conversation about VPFs: what would it take for you to > start routing calls across the Internet using lookups like ENUM? > > 1. A big task would be advertising our routes. We'd have to pull our > user's numbers out of our boxes -- Asterisk, BroadWorks, MetaSwitch, > Taqua, Sonus, Nortel, Cisco, etc., and advertise those numbers > somehow. I'm sure tools to extract the list of local numbers from each > of these systems would be pretty easy. Raise your hand if you're > excited about advertising all of your user's telephone numbers to make > the telemarketing and SPIT easier. I think that should already exist, if you're offering some sort of routing to start with. If you don't know the E.164 addresses that are assigned to each customer, how are you getting calls to them in the first place? As far as authenticating to protect against SPIT, that's not overly difficult, I believe. I had a suggestion some time ago that would at least let you create black/whitelists based on asserted domain name. Here is discussion and code I wrote that might be of some interest: https://mail.internet2.edu/wws/arc/sip.edu/2006-07/msg00012.html http://forum.e164.org/index.php?topic=16.0 > 2. We'd need to agree on some way to ensure that these routes > advertised were authoritative. E.g., how would YOU know that I'm > really authorized to advertise +1-229-316-0013? If you dip to SS7, > that goes to my CLEC-partner-of-the-week. OK, now this is a serious issue that I have no easy answer for. There are two companies here in North American that would be GLAD to offer the ability to look that data up in their proprietary databases, and charge you for that service. Personally, I'm not really interested in that model, though Bellheads nearly froth with glee when the concept of a "central database" starts to be needed for EVERY transaction. > 3. Then we'd need to agree on some way to do the lookup. ENUM seems > like a nice option -- if the basic delegation mechanism made sense. > It makes sense if we have large blocks of numbers, like NPANXXs, and > there are no number ports. But since we all have number ports, the > large blocks will be punctuated by many, many individual references to > the ITSP that ported in the number. So the ability to delegate > subdomains using ENUM doesn't bring much value, to my mind. So > whether we use ENUM or a normal SIP redirect server probably doesn't > make a lot of difference. OK, another huge stumbling block. Especially when we're now talking about creating ENUM trees that have to be completely broken down to individual responses for each 0-9 subdomain space for each reply if one number is ported out of the block. Gak. DNS doesn't like this. > 4. We'd also need to make peace on the whole transport thing. As Brian > Sneddon just said, the commodity Internet remains acceptable for a lot > of purposes. There's risk in betting on that, of course. If the user doesn't know what to expect, yes, that's very true. > 5. And then we'd have to figure out how to bill each other, if we're > going to do billing. But is billing each other for 100 kbps audio > streams worthwhile anyway? In my opinion, no. But I'm not a carrier who has become used to feeding from that teat of inter-carrier compensation. I'm used to charging my users for connecting their calls in or out, not charging someone else for the luxury of reaching my customers. > 6. Of course, we also want to be sure we're allowing calls only from > the right people. A few years ago, many of us setup our SBCs to allow > calls from the public Internet, but that's much less common now. Oh, > we'll accept any ol' screechy call that comes from our known peer, and > pay him to do it. I guess I can agree with this, but I don't know what "allowing calls from the right people" means, except in the context of getting paid for inbound calls (see my reply to your #5) or in a quality assurance issue (see #4.) > And once we figure out all of these challenges -- which are really > quite moderate -- we've got to convince ourselves that the effort is > worth the reward: we get to bypass the big carriers for some calls, > and get to use fancy codecs like G.722 and video. > > The technical challenges are really quite moderate. The VPF people are > trying to solve it but only within their club. Why pay them when we > can do it ourselves? I agree with this last statement entirely, but with a caveat. The caveat is that I think that E.164 is broken, from both an operational and political level. I used to be a big believer, and I still think it probably is good non-global peering arrangements. But for public use, I think it's dead. (possibly excepting iNum, but I'm still viewing that with some suspicion) What's the punchline to this set of comments I've made? I am an advocate (and administrator) of the freenum.org system, which uses a concept called "ISN", which is an alternate pointer system which can replace E.164. It uses organizationally-based numbering schemes which are keypad friendly (12 digit standard DTMF keyboard) and which are suitably different from An ISN (ITAD Subscriber Number) is formed very much like a SIP URI: a subscriber portion, a separator, and an organization identifier. A SIP URI might be "1234 at loligo.com", and a similar ISN would be "1234*256". In this case, loligo.com (me) has received ITAD 256 from IANA a few years ago. So the ENUM-like lookup is "4.3.2.1.256.freenum.org" - the freenum.org zone can either delegate zone "256" to me, or I can do what most organizations do and put in a wildcard NAPTR record that just points all SIP calls to my Asterisk SIP platform. In this example case, the NAPTR for 4.3.2.1.256.freenum.org maps to "1234 at loligo.com", and uses standard SIP lookups from there on out. Here's a small set of advantages of freenum.org over E.164: - Not similar to E.164 numbers (users have expectation of "internet calling") - Works on most of the world's existing phones - Requires no alphanumerics - Maps very cleanly to SIP infrastructures - Uses all standard ENUM methods, but slightly modifies root - Totally free - IANA-based registry for organizations (not-for-profit) - Layers onto existing E.164 system, if you so wish (12125551212*254 would work fine, as an example) - Does not involve the ITU - Does not involve governments - Assumes end-to-end IP SIP at no charge between entities - Organizationally-based, not geographic - Scales better than ENUM, and within organizations can scale laterally - OpenSER, SER, Asterisk, FreeSwitch support existing already for dialing/DNS lookups - We have SIP, ENUM shims for systems that So, I believe that many of the problems with ENUM are insurmountable on a large scale. A different system needs to be put in place that allows dialpad access yet is more friendly and scalable for systems which are internet-enabled in the core. Hopefully, you'll take a look at the concept and see if you might permit your users to dial those digits and also accept inbound calls. JT _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops 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

3 2

The big ENUM question (Was: VPFs)
by lindsey＠e-c-group.com Aug. 6, 2009

Aug. 6, 2009

At IPTComm a couple of years ago, Jonathan Rosenberg stood up and said the big problem was the walled gardens that are telcos and ITSPs. We carriers just aren't passing traffic via VoIP. Even Cisco customers aren't passing traffic within their own company; you'd have a BTS over here and a BTS over there, owned by the same Cable MSO, passing traffic via ISUP. Continuing this conversation about VPFs: what would it take for you to start routing calls across the Internet using lookups like ENUM? 1. A big task would be advertising our routes. We'd have to pull our user's numbers out of our boxes -- Asterisk, BroadWorks, MetaSwitch, Taqua, Sonus, Nortel, Cisco, etc., and advertise those numbers somehow. I'm sure tools to extract the list of local numbers from each of these systems would be pretty easy. Raise your hand if you're excited about advertising all of your user's telephone numbers to make the telemarketing and SPIT easier. 2. We'd need to agree on some way to ensure that these routes advertised were authoritative. E.g., how would YOU know that I'm really authorized to advertise +1-229-316-0013? If you dip to SS7, that goes to my CLEC-partner-of-the-week. 3. Then we'd need to agree on some way to do the lookup. ENUM seems like a nice option -- if the basic delegation mechanism made sense. It makes sense if we have large blocks of numbers, like NPANXXs, and there are no number ports. But since we all have number ports, the large blocks will be punctuated by many, many individual references to the ITSP that ported in the number. So the ability to delegate subdomains using ENUM doesn't bring much value, to my mind. So whether we use ENUM or a normal SIP redirect server probably doesn't make a lot of difference. 4. We'd also need to make peace on the whole transport thing. As Brian Sneddon just said, the commodity Internet remains acceptable for a lot of purposes. There's risk in betting on that, of course. 5. And then we'd have to figure out how to bill each other, if we're going to do billing. But is billing each other for 100 kbps audio streams worthwhile anyway? 6. Of course, we also want to be sure we're allowing calls only from the right people. A few years ago, many of us setup our SBCs to allow calls from the public Internet, but that's much less common now. Oh, we'll accept any ol' screechy call that comes from our known peer, and pay him to do it. And once we figure out all of these challenges -- which are really quite moderate -- we've got to convince ourselves that the effort is worth the reward: we get to bypass the big carriers for some calls, and get to use fancy codecs like G.722 and video. The technical challenges are really quite moderate. The VPF people are trying to solve it but only within their club. Why pay them when we can do it ourselves? On Aug 5, 2009, at 11:29 AM, Brian Sneddon wrote: > I've looked at Stealth's VPF a little before, but I also don't see > them as too compelling yet. The voip carriers we use are well > connected on the commodity Internet and latency remains within > acceptable levels with those carriers. The last time I checked VPFs > didn't take care of the most complex issues such as being able to > interop or negotiating rates, so paying a premium for a VPF doesn't > yet benefit us enough. > > Brian > > ----- "David Hiers" <David_Hiers at adp.com> wrote: > >> Hi, >> Does anyone use a voice peering fabric? >> >> I look at 'em from time to time, but just don't see them as a >> compelling option yet. >> >> >> Thanks, >> >> >> >> David Hiers >> >> CCIE (R/S, V), CISSP >> ADP Dealer Services >> 2525 SW 1st Ave. >> Suite 300W >> Portland, OR 97201 >> o: 503-205-4467 >> f: 503-402-3277 >> >> >> >> 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 > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops Mark R Lindsey lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013

3 2

Level 3 contact on voice ops
by john.turek＠gmail.com Aug. 6, 2009

Aug. 6, 2009

Greetings I am John from Level3 technical support center. Just wanted to let you all know I am here if anybody has questions/comments. I am on the advanced technical support team for ip and voice services Thanks JT Sent from my iPhone

3 2

broadsoft patchtool
by David_Hiers＠adp.com Aug. 6, 2009

Aug. 6, 2009

Hi, What's your upgrade stance on BW's patchtool? Its recommend to upgrade it when you patch, but the thing is always running. You can't run tech-support without invoking patchtool, for instance. David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 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.

4 12

Message transfer from yahoo group: SANSAY SPX
by David_Hiers＠adp.com Aug. 6, 2009

Aug. 6, 2009

Hi, I'm transferring the bodies of the first message in each technical thread from the old yahoo site to this group. ### Any of you running Sansay SPXs as you SBCs better make sure you don't have telnet, SSH, or FTP open to the world. Several, including two of mine, have now been hit with what I believe is going to turn out to be a standard script kiddie vs. linux default accounts attack. No operational impact at this time, but they were owned, the people who left the ports open beaten to a bloody pulp, and the new units will come in via courier tomorrow. Should be a no downtime replacement. ### 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.

2 1

critical mass
by David_Hiers＠adp.com Aug. 5, 2009

Aug. 5, 2009

Hi All, The more people sign up for this list, the more valuable it will be for all of us. If you get a chance, you may want to mention the list to your colleagues. With our growth rate (288 members in 5 days) its clear that you guys are getting the word out, thanks for that :) Thanks, David Hiers CCIE (R/S, V), CISSP ADP Dealer Services 2525 SW 1st Ave. Suite 300W Portland, OR 97201 o: 503-205-4467 f: 503-402-3277 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.

4 4

360networks on the Board
by RGarcia＠360.net Aug. 5, 2009

Aug. 5, 2009

Hey all - since more than a few of our customers are on here- thought it would be a good idea to round up a 360 ops person on here. I've asked Cindy to join the group. For those here that know her you know she is extremely helpful. I can help with product, marketing, and general knowledge across the space, gear, service providers etc. Best, Rick Rick Garcia VoIP Strategist 360networks (USA) Inc. 206-239-4059 - O 206-999-6666 - C 206-299-9383 - F

1 0

Level 3 contact on voice ops
by carlos＠race.com Aug. 5, 2009

Aug. 5, 2009

welcome good to see the list is growing -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of John Turek Sent: Tuesday, August 04, 2009 2:16 PM To: voiceops at voiceops.org Subject: [VoiceOps] Level 3 contact on voice ops Greetings I am John from Level3 technical support center. Just wanted to let you all know I am here if anybody has questions/comments. I am on the advanced technical support team for ip and voice services Thanks JT Sent from my iPhone _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0

Any subscribers from the UK?
by carlos＠race.com Aug. 5, 2009

Aug. 5, 2009

I know as Metaswitch goes it's in c/c++. Metaswitch parent company is Data Connection which actually writes a lot of the network/voip protocol stacks that cisco/juniper/lucent ect use. So it's always nice to have some support from that arm of the company when you have that low of a level of an issue which by the way I have and my support guy and myself worked with the data connection arm to figure out the issue. Carlos Alcantar Race Telecommunications, Inc. 101 Haskins Way South San Francisco, CA 94080 P: 650.649.3550 x143 F: 650.649.3551 -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Peter Beckman Sent: Wednesday, August 05, 2009 12:31 AM To: Alex Balashov Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Any subscribers from the UK? On Wed, 5 Aug 2009, Alex Balashov wrote: > I abdicate the question with a parting thought: Why is it that more > high-capacity, commercial-grade stuff (of the standalone, not web front-end > variety) isn't written in PHP? Why doesn't someone like Metaswitch or > Broadsoft implement internals in PHP? To some extent, the answer is > accounted for by the stubbornness of large-corporate fashions and entrenched > interests surrounding certain technology stacks, as we well know, but I don't > think that's the whole explanation. It's not like these guys didn't get the > memo on PHP or something. I really think it has to do with the existing code-base and the existing developers. Each company is beholden to the geeks that build, maintain and manage the mess of code that exists. Those geeks either get to choose what technologies are used, or do not have the resources to rewrite working code and are forced to maintain the code already written, maybe adding things on in different more familiar languages along the way, until you're in a giant pile of spaghetti code in 9 languages, all tangled loosely but functionally together by a very thin thread. What do Metaswitch or Broadsoft use? C? Perl? Are they using Asterisk or did they build their own telecom server stack? How do you know they are NOT using PHP internally or even externally? Disabling the web management server's tag (not returning "Apache/1.2.47 PHP/5.2.5" on requests, even though that is exactly what it is running) is trivial and a good security choice, assuming these devices are configured via a web-based interface. >>> Good to know; I had not considered the soft reload angle. Thanks! >> >> No problem! Just be sure that if your FastAGI is using HTTP API calls to >> your backend that you are able to manage DB changes gracefully. Having an >> existing call make a call to an internal backend API that now requires an >> additional variable will fail unless that case is handled. This is one of >> the reasons the FastAGI does not talk to the DB directly, but through HTTP >> API calls that are handled quickly by PHP. > > That's a smart setup. And, PHP is a fine language to use for an HTTP and/or > RESTful API dispatcher. :) Why thank you! :-) Beckman ------------------------------------------------------------------------ --- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ------------------------------------------------------------------------ --- _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

1 0