- VoiceOps - lists.voiceops.org

verizon call issues
by David.Hiers＠adp.com April 18, 2013

April 18, 2013

No responses... really? Has everyone been happy with Verizon VOIP over the past few hours? We've been hammered. David From: Hiers, David (DS) Sent: Thursday, April 18, 2013 11:22 To: voiceops at voiceops.org; outages at outages.org Subject: verizon call issues Anyone having trouble with inbound calls from Verizon? 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.

3 2

verizon call issues
by David.Hiers＠adp.com April 18, 2013

April 18, 2013

Anyone having trouble with inbound calls from Verizon? 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.

2 1

Verizon outage
by peeip989＠gmail.com April 18, 2013

April 18, 2013

Again... anyone else experiencing this? started approx 13:30 EDT. We are connected to 11 gateways and all are impacted. Outbound calling seems ok.

1 1

Newfies-Dialer : Voice Broadcasting, Auto-Dialer and IVR Survey Software
by javieraristizabal＠gmail.com April 16, 2013

April 16, 2013

Newfies-Dialer can support distributed processing on cloud servers or be installed on a standalone server, and it is simple and easy to use. Contacts, phonebooks and campaigns are selected by the user, who then chooses a voice application. Newfies-Dialer then spools the outbound calls using the FreeSWITCH Telephony engine, which dials the contact, and once the call is answered, either by a person or an answering machine, Newfies-Dialer is notified and the relevant message is relayed via FreeSWITCH. Django Python is the framework that is used to build Newfies-Dialer, which enables the building of clean, maintainable web applications and encourages rapid development with clean and pragmatic design. See all the features of Newfies-Dialer at http://www.newfies-dialer.org/ and watch our Phone blasting Screencast: http://www.newfies-dialer.org/phone-blasting-made-easy/ -- Javier Aristiz?bal

1 0

Evariste Systems drops open source, becomes Acme Packet VAR
by abalashov＠evaristesys.com April 1, 2013

April 1, 2013

For immediate release: ATLANTA, GA (1 April 2013)--Evariste Systems LLC, an Atlanta-based consultancy specialising in Kamailio-based VoIP infrastructure solutions for the ITSP and CLEC market, has announced that beginning in the second quarter of 2013, it will be abandoning its Kamailio-based technology portfolio to focus on its new role as a preferred VAR (Value Added Reseller) for Acme Packet (NASDAQ:APKT). "It is with a heavy heart that we abandon five years of Kamailio-oriented work and the Canonical SIP Routing Platform product derived from it," said Alex Balashov, the principal of the company. "However, the reality is that investment in open-source VoIP technology is a dead end. From a technological point of view, we have lagged very badly in meeting the needs of today's sophisticated VoIP market, and it's time to cut our losses. Asterisk, Kamailio, FreeSWITCH--all this stuff just hasn't kept up with the pace of evolution of 3GPP, ETSI, and ITU standards. We are tired of saying 'sorry, we don't support IMS or H.323' to our resultingly dwindling customer base. Does anyone actually run an all-SIP network?" Starting in early April, Evariste will begin providing value-added consultancy related to the implementation of the Acme Packet Net-Net Session Director. In Balashov's view, "the Net-Net SD is the only product capable of meeting the perimeter security, routing and peering needs of today's VoIP service delivery environment." Fred Posner, the director of Team Forrest, a Palner Group integration and consultancy operation based in the Jacksonville, Florida area, agreed: "SIP is a tiny piece of the telephony puzzle. The big boys of ClueCon [an interoperator revenue-sharing consortium] want DIAMETER-based interdomain peering policy control, H.323, MGCP, and IMS. IMS is pretty much how VoIP architecture is done now. We got out of the Asterisk business just in time, right before Mitel swallowed the PBX world. I'm glad to see Evariste is finally seeing the light, and I'm sure its shareholders are too." Posner also believes Evariste's lack of support for TDM interfaces accounted for dwindling market share. "Have you seen CSRP? It's SIP in, SIP out. Real inter-LATA haulers and application service providers use TDM and leave SIP for things like voicemail. I can't plug my DS3s into a SIP proxy, so I just don't think there was any real demand for the sort of thing they were doing." Noting Oracle's US$2.5bn acquisition of Acme Packet in early February, as well as its more recently announced buyout of Tekelec, a Siris Capital Group portfolio company, Balashov remarked: "The obvious shift to an Oracle-centric telephony paradigm was a kind of validation, if you will, of our decision to unload our dead weight and sign on to the revolution in unified communications." Sean McCord, of CyCORE Systems, an Atlanta-based software consulting house and long-time Evariste creditor, agreed that there was a natural synergy between Evariste's shift to Acme Packet and Oracle's dominance of telephony infrastructure. "Oracle is a forward-thinking telecom pioneer," McCord said. "The telephone is Oracle, and Oracle is the telephone." Balashov also noted that a tightening regulatory environment and new consumer protection rules helped hasten the decision to embrace the more professionalised Acme Packet product portfolio. John Knight, Senior Engineer at Hendersonville, NC-based Ringfree Communications, one of Evariste's oldest channel partners, said: "As one of Evariste's long-time disties, we were jittery about exposure to CALEA and the QA requirements of large call centers. We tried to make do, but at some point we just had to put the relationship on stop. I'm all in favour of open, but there's just no open-source software out there that does call recording, and that's the bottom line for us. In the end, we had to restructure some debt just to get bondholders to let us source a proprietary solution on tick." In a thematically related move, Evariste will be dropping its heavy use of the open-source PostgreSQL database manager for its rating and reporting tools. "The business case for standardising on Oracle's databases could not be clearer. With Oracle Database 11g's support of warehousing and OLTP, the real mystery is why we didn't go there sooner," said Balashov. Carlos Alvarez, a director at Televolve, a growing Phoenix-area VoIP operator, recently spearheaded a move away from Evariste's PostgreSQL- based call detail record (CDR) storage solution to one running atop Microsoft SQL Server 2008. Alvarez commented: "Evariste had a nice idea, in a cute, David-and-Goliath kind of way, but we're processing over five hundred phone calls a day now. Are we really going to store those kinds of volumes in an open-source database? Might as well just put it all in flat text files at that point. Phone service is an uptime game. You can't compromise on this stuff. What if someone needs to call 911?" Asked to summarise his expectations, Balashov said: "I hope this turns us around in a big way. We were wrong to think that nobody cared about stuff like P-CSCFs, or that you could deliver even rudimentary VoIP to the premise without the expansive feature set of a comprehensive solution like the Net-Net SBC. I can only hope the market forgives us for betting on 'SIP Express Router' and its ilk back in the day, and gives us a chance to do it right in round two." Fred Posner, of Team Forrest, added: "Besides, if you look at the Git repository, Kamailio hasn't had any code contributions in at least five years. It seems everyone's figured out this pure SIP stuff is defunct and hokey."

6 6

LIDB Usage
by jared＠compuwizz.net April 1, 2013

April 1, 2013

A lot of our customers have been asking how they can better scrub their calling lists to only call provisioned numbers. They do the normal DNC list scrubbing, but they need something more. Does the LIDB database have this sort of information in it as for as if the number is active and provisioned? I know it won't be perfect as a CLEC such as Level3 could have the number provisioned to an ITSP who just has it in inventory. It would help at least a little bit to be able to skip over the Not Provisioned numbers. If the LIDB can't handle this, what other database should I be looking for to do dips to? If it can do this type of thing (I know its mainly used for 8YY calling dips) where can we get access to the database? Regards, Jared Geiger

2 1

+44 190 prefix
by abalashov＠evaristesys.com March 24, 2013

March 24, 2013

A customer of mine is seeing aggressive attempts to dial +441904891769 through their system, but I can't find +44 190, or any superset or subset thereof (beyond '44', obviously) in any rate decks easily at my disposal. None of the usual retail suspects have it listed in any of their online pricing, either. I assume this means it's a new prefix, but can anyone tell if it's a premium number? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

7 9

Older Cisco SIP firmware download
by abaird＠telesphere.com March 23, 2013

March 23, 2013

Hi all. I have been tasked with performing a SIP interop with the Cisco 7941 model IP phone. I've failed to get it working with the latest SIP 9.x which is still available from Cisco w/o a contract. >From what I've found in my research, an older version 8.5.4 might be the way to go but I can't download it from Cisco without a contract. I'm not sure why they chose to protect the older versions but not the newer. Anyway, would any of you happen to know an alternate place for me to download the file? I'm not sure I'll be able to purchase a contract to allow me to download the file since this model went EOS so long ago. I'm looking for: cmterm-7941_7961-sip.8-5-4.zip Feel free to direct message me if you prefer. Thanks -Adam

17 27

Call Forwarding is broken; or, when CF meets LCR
by nathana＠fsr.com March 21, 2013

March 21, 2013

On Monday, March 18, 2013 12:40 PM, Mike Ray <> wrote: > Many factors went into our decision on how to handle these situations. > Regulation is one of those; it is illegal to stuff the ANI to change the > jurisdiction of the call although we know that many carriers/ITSPs do that > anyway. Perhaps this is splitting hairs (and I admittedly have not read the actual language of the law(s) you are citing), but I would argue that in my example, if I were to "stuff" the ANI in the way I describe (take called party/forwarder's number and use that for ANI), I wouldn't be doing so to necessarily change the jurisdiction of the call to be in my favor; there would be scenarios in which it would be advantageous for me from a billing perspective to *not* do that. I would, in fact, be doing it to actually set the *correct* jurisdiction of that leg of the call, regardless of whether it happens to be in my favor or not. Using the caller's ANI as ANI for the forwarded leg is causing the *incorrect* jurisdiction to be selected, but is the only way to get the correct Caller-ID passed through end-to-end. *That* is the frustrating part. > However, as you noted, if you stuff the ANI it will negatively > affect your customer's perception of your service, since that is not how a > PSTN forward would be handled. Thus, a disincentive to me and other reputable ITSPs to engage in such activity. > The real issue is that the PSTN, both at the SS7 and PRI signalling > levels, recognizes both the ANI and the BillingNumber fields for any call > but SIP does not have that construct. The "PSTN-proper" way to handle > this would be to pass the original caller's ANI for CallerID, but to pass > your forwarded customer's BillingNumber. However, SIP just has ANI and > that's it. Actually, as I understand it, PSTN doesn't "automatically" pass the caller's ANI for CNID, which is another reason to consider the "industry-standard" methods of SIP->SS7 interop to be broken. There are, to my knowledge, *three* separate fields: 1) CNID 2) ANI 3) BTN (Then there is also ANI2, but that's not terribly relevant to this discussion, I don't think.) I have also heard #2 and #3 referred to as "ANI" and "Charge ANI" respectively. What I have never quite understood is what the relationship between the two are, and if someone could explain that, I would be grateful. However, I am quite sure that CNID does *not* have to match ANI, and I would be quite content if, instead of adding a new field to the SIP header for BTN (leaving CNID+ANI the way it is now), ANI+BTN were instead combined, CNID was split out into its own thing, and new field was added instead for either CNID or ANI+BIN. (Of course, ultimately, it would be best for all 3 to be separate if that is how they are signalled on SS7.) > So the way we decided to handle this in the final analysis is that we > already bill our wholesale ITSP subscribers for outbound calls on two > levels: one for local and the other for non-local. We use the actual ANI > of the calling party to determine this jurisdiction (local/non-local) > because that is what will trigger the terminating carrier's access > billing to us, and we bill our ITSP customer the proper rate based upon > that, regardless of the forwarding-customer's number. Right, and that's how everybody seems to be doing it. But, again, the problem I'm pointing out is that using the calling party's number to determine this juristiction is horribly broken and wrong, IMO. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com

3 4

711 relay
by brandon＠kamikos.com March 21, 2013

March 21, 2013

We used 933 to verify 911 info, leaving 811 for OneCall utility locates. Carlos Alvarez <carlos at televolve.com> wrote: >On Wed, Mar 20, 2013 at 7:12 PM, Mike Ray <mike at astrocompanies.com> wrote: > >> Are you sure that your CLEC provider isn't doing this for you? We do. >> CLECs are required to provide this service, and the translations happen in >> our switch when you send us an x11 call. So you shouldn't have to do >> anything. >> > >I can tell you that if we send 811 to Vitelity, they just read back our >CID. We, and they, use this for testing 911 systems. We have the >customers dial 811 to verify the 911 CID is right. Which in light of >today's conversation is clearly not legal, though arguably far more useful >than having someone come out and mark utility lines. > >I have not tried sending 711 to any of our carriers. They are all >SIP-based and I have no idea how they will handle it, but I'm going to try >it. > >-- >Carlos Alvarez >TelEvolve >602-889-3003 > >_______________________________________________ >VoiceOps mailing list >VoiceOps at voiceops.org >https://puck.nether.net/mailman/listinfo/voiceops

1 0