Re: [VoiceOps] LNP, tandems, etc.

[Anthony Orlando via VoiceOps]

I was just about to post that Mary Lou can help you but she beat me to it. 

Sent from my iPhone

> On Aug 29, 2018, at 9:28 AM, BackUP Telecom Consulting 
>  wrote:
> 
> You can pick which rate center your LRN will be assigned from, but you still 
> have to follow the tandem homing established by the ILEC for that rate 
> center. Not all ILECs require the same type of trunking to each of the 
> tandems, but all require you to home your LRN on the tandem that your LRN-NXX 
> would normally be served by in the PSTN network. Now you can appear to get 
> around this by using the CLLI code of a third party providers, but the third 
> party providers network is required to route traffic like the ILEC so really 
> you're just using one pipe to send all your traffic to the ILEC and the third 
> party provider breaks it out according to what tandem the ILEC requires 
> trunking to.
> 
> Mary Lou Carey
> 
> BackUP Telecom Consulting
> 
> Office: 615-771-7868 (temporary)
> 
> Cell: 615-796-
> 
>> On 2018-08-28 09:56 PM, Mike Hammett wrote:
>> Okay. I'll take that as my action item. On to the understanding...
>> I don't understand how someone can aribrarily choose which tandem an
>> LRN hangs off of. Why aren't they forced to keep an LRN attached to
>> whatever tandem handles a given incumbent rate center? In my
>> situation, 815-901 is in DeKalb. DeKalb's tandem is...  DeKalb. How
>> can Comcast decide to throw it onto Dixon's tandem? I wouldn't have
>> this confusion if Comcast's LRN in Dixon was from an NPA-NXX assigned
>> to Dixon.
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>> -
>> FROM: "Matthew Crocker" 
>> TO: "Mike Hammett" 
>> CC: voiceops@voiceops.org
>> SENT: Tuesday, August 28, 2018 8:53:27 PM
>> SUBJECT: Re: [VoiceOps] LNP, tandems, etc.
>> Mike
>> You either need to connect to the other tandem or pay another carrier
>> to get you there.  It is the responsibility of the originating carrier
>> to get the call to the terminating carriers switch.  Depending on the
>> call volume you should probably just route through your LD carrier
>>> On Aug 28, 2018, at 9:15 PM, Mike Hammett  wrote:
>>> I drew a picture, hoping it would clear things up a bit.
>>> Through my switch, we're trying to call a number in a block assigned
>>> to Sycamore, with an LRN in a DeKalb number block, but the common
>>> tandem operator is telling me that the LRN actually lives on a
>>> different tandem.
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>> Midwest Internet Exchange
>>> http://www.midwest-ix.com
>>> -
>>> FROM: "Mike Hammett" 
>>> TO: voiceops@voiceops.org
>>> SENT: Tuesday, August 28, 2018 4:46:52 PM
>>> SUBJECT: [VoiceOps] LNP, tandems, etc.
>>> I thought you had to be on the same tandem to port a number, but
>>> with what our tandem operator (Frontier) is telling me, this isn't
>>> the case.
>>> Comcast ported a number from us in town A. The LRN they pointed to
>>> is based in town B (per TelcoData). The tandem generally used by
>>> carriers in both towns is based in town B. Naturally, we send
>>> traffic to that tandem.
>>> The operator of that tandem is telling us that the LRN is actually
>>> homed off of a different tandem in our LATA (operated by
>>> CenturyLink) in town C. Unfortunately, I can't corroborate this
>>> information with TelcoData the only rate center I see off of that
>>> tandem in TelcoData is an AT town next door.
>>> Where can I read up authoritatively on the porting requirements that
>>> would apply to this and related bits of info I should know?
>>> I'm checking on our LERG access as I know that has the authoritative
>>> information, but I don't have that access at the moment. Maybe we're
>>> not subscribed to it.
>>> Number NPA-NXX in town A:
>> https://www.telcodata.us/search-area-code-exchange-detail?npa=815=991
>>> LRN NPA-NXX in town B:
>> https://www.telcodata.us/search-area-code-exchange-detail?npa=815=901
>>> Tandem in town B:
>> https://www.telcodata.us/search-switches-by-tandem-clli?cllicode=DKLBILXA50T
>>> [1]
>>> Tandem in town C:
>> https://www.telcodata.us/search-switches-by-tandem-clli?cllicode=DIXNILXA50T
>>> Thanks.
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>> Midwest Internet Exchange
>>> http://www.midwest-ix.com
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>> 
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>> Links:
>> --
>> [1] 
>> https://www.telcodata.us/search-switches-by-tandem-clli?cllicode=DKLBILXA50T
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> 

Re: [VoiceOps] Broadworks / Merging calls with Voipmon

[Anthony Orlando via VoiceOps]

Sounds like a crappy way of correlating a call especially if u have several 
b2bua’s.  Several commercial products out there that have multiple ways of 
correlating a call. 

Sent from my iPhone

> On Jan 22, 2018, at 4:10 PM, Zilk, David  wrote:
> 
> If you click on the ‘Merge’ dropdown while displaying the Legs by Header, you 
> can select ‘SIP History’ to display the SIP Ladder diagram of all the legs 
> together.
>  
> David
>  
> From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew 
> Beckwell
> Sent: Monday, January 22, 2018 1:02 PM
> To: voiceops@voiceops.org
> Subject: Re: [VoiceOps] Broadworks / Merging calls with Voipmon
>  
> Hi Matt,
> Here's what I've done to get close to what you're looking for...
>  
> In the BroadWorks Application Server, set these parameters:
>  
> AS_CLI/Interface/SIP>
> sendCallCorrelationIDAccess = true
> sendCallCorrelationIDNetwork = true
>  
>  
> Once you do that, you'll see BroadWorks start to add a header for "related" 
> calls. They will have have a common correlation header (but different 
> call-id) like this:
>  
> X-BroadWorks-Correlation-Info:1126786:1
>  
>  
> Then, in voipmonitor.conf you can set this parameter in the sniffer 
> configuration to keep track of that header's value in the database:
>  
> matchheader = X-BroadWorks-Correlation-Info
>  
>  
> VoIPmonitor won't merge them into a single SIP Diagram (at least not that 
> I've found)-- but you should start to see the "related" call legs (with 
> different Call-ID's but the same X-BroadWorks-Correlation-Info header) show 
> up in the "Legs by header" tab when you're looking at a call's details in the 
> VoIPmonitor GUI.
>  
> ~Matthew
>  
>  
>  
>  
>  
> On Mon, Jan 22, 2018 at 2:36 PM, Matthew Crocker  
> wrote:
>
> Hello,
>  
>  
> We currently have Broadworks/AcmePacket handling calls to/from customers.  We 
> have a couple VoipMon sensors running watching all traffic inside/outside our 
> SBC.   Currently calls are presented in VoipMon as two different calls (PSTN 
> -> Broadworks & Broadworks -> Polycom) or (Polycom -> Broadworks & Broadworks 
> -> PSTN). The Call-id on each call is different,  Broadworks generates a 
> new SIP Dialog for the call.   If the customer has a hunt group there could 
> be several INVITEs going out to multiple phones, all with different Call-Id.  
>Does anyone know of a way to get VoipMon to merge the calls into a single 
> CDR/SIP Diagram?  Is there a way to configure Broadworks to embed the 
> original Call-Id in the new INVITE (Parent-Call-Id Header)?
>  
> I’m running R20sp1
>  
> Thanks
>  
> -Matt
>  
> -- 
> Matthew Crocker
> Crocker Communications, Inc.
> President
> 
> ___
> VoiceOps mailing list
> VoiceOps@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, notify the sender immediately by return 
> email and delete the message and any attachments from your system.
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Exclusive: Quitting the fast life of open-source SIP

[Anthony Orlando via VoiceOps]

I think I just threw up in my mouth 



Sent from my iPhone

> On Apr 1, 2017, at 6:26 AM, Shripal Daphtary  wrote:
> 
> Nice one!! 
> 
> 
> Thanks, 
> 
> Shripal
> 
>> On Apr 1, 2017, at 1:11 AM, Alex Balashov  wrote:
>> 
>> (Filed by UC Celeb Talk - 1 Apr 2017.)
>> 
>> BERLIN (Tegel), GERMANY--In the now-infamous breakdown episode on the
>> VIP tarmac at Berlin's Tegel Airport, Alex Balashov shocked the IP
>> telecoms celebrity world last month. 
>> 
>> Shielding his eyes from the punishingly bright daylight of an overcast
>> day in northern Germany, Balashov climbed out of his Gulfstream G650
>> jet, clutching a half-finished bottle of Woodford Reserve, and announced
>> his sudden retirement from the "fast life" of open-source SIP consulting
>> to a waiting gathering of tech business reporters. 
>> 
>> "I'm not with this 'live fast, die young' VoIP s*** anymore," he
>> reportedly shouted, before collapsing and vomiting profusely on the red
>> carpet.
>> 
>> UC Celeb Talk's own Benjamin Brant sat down with Balashov in an
>> exclusive interview to learn more about what happened, even as the
>> telecoms industry continues to digest the shock meltdown. 
>> 
>> --
>> 
>> BRANT: Everyone's dying to know, what was going through your head at
>> that moment?
>> 
>> BALASHOV: Funny how you mention dying. I want to live to see 35, man. I
>> can't handle the SIP biz anymore. 
>> 
>> BRANT: What do you mean? You seemed to have all the makings of an
>> open-source SIP superstar.
>> 
>> BALASHOV: I can't keep up with the drinks anymore, the three day-long
>> parties, the paparazzi, always watchin' my back at ClueCon...
>> 
>> BRANT: When'd you realise it might be time to call it?
>> 
>> BALASHOV: I'll tell you when. It was Kamailio World '16. Man, those
>> vodka + Club Mate drinks they pour down at Fokus are something else.
>> They'll really get you thinking about things. 
>> 
>> BRANT: So you had a cocktail and thought better of your entire life as a
>> SIP celebrity? The fans, the adulation, the glory? 
>> 
>> BALASHOV: When you wake up at 3 PM at the Park Inn on Alexanderplatz
>> with a $31,000 room service bill on your AMEX, a goat wandering around,
>> and reporters in your face, you tell me with a straight face you're not
>> gonna take stock of your life and make some changes.
>> 
>> BRANT: That really happened?
>> 
>> BALASHOV: That's what I'm trying to tell you! That's Kamailio World,
>> dude. That's the SIP software engineering culture. You wanna ITSP and
>> WebRTC? You're gonna have to bro down!
>> 
>> BRANT: Surely not everywhere. What about the IETF?
>> 
>> BALASHOV: Those guys drink more than ANYONE. Have you seen the SIP
>> Outbound RFC?
>> 
>> BRANT: That's the work-product of an alcohol-fuelled creative orgy?
>> 
>> BALASHOV: It's the work product of something-something. I don't know if
>> I'm allowed to identify the uh, substance in question.
>> 
>> BRANT: How are you going to live without the private jet? If I had a G6,
>> I wouldn't just turn over the keys.
>> 
>> BALASHOV: Yeah, I mean, open-source VoIP consulting has its upsides.
>> It's a fine way to make a living. But it's just not worth it. Besides,
>> hourly operating costs are through the roof. 
>> 
>> BRANT: But you were an icon, and quite a ladies' man too! How do you
>> walk away from that?
>> 
>> BALASHOV: Look man, of course women are gonna mob you when you're a SIP
>> consulting star. That's just part of the open-source tech life in
>> general.
>> 
>> But it's fake, man. They don't love you. They don't want to know who you
>> are inside. They just want you 'cause you know all about the SIP
>> transaction state machine, loose vs. strict routing, cross-compiling
>> Kamailio. They just got a crush on you 'cause you know presence and
>> parallel forking race conditions.  I want something real.
>> 
>> BRANT: But that's part of the social bargain of being an open-source SIP
>> celebrity. Didn't you once boast of having uh, lady friends, "in
>> different geographic and non-geographic operator codes"?
>> 
>> BALASHOV: Yeah, and that's cool, but I want to come home to a woman who
>> loves me for me, not Mr.  3...
>> 
>> ... 02, Moved Temporarily, but not happy necessarily. Feel me?
>> 
>> BRANT: What happened at ClueCon?
>> 
>> BALASHOV: You talking about the bullets Acme Packet ventilated me with?
>> 
>> BRANT: Five of them, as I heard.
>> 
>> BALASHOV: Well I'm still standin'. Took those shots and smiled.
>> 
>> BRANT: I know you guys have a kind of omertà about this stuff, but I've
>> got to ask: why?
>> 
>> BALASHOV: I ain't worried, kids growing up in today's world need to
>> learn the truth. 
>> 
>> They act like I was dealing transcoding licences on their block. O.G. 729.
>> 
>> BRANT: But that wasn't what gave you a wake-up call that the SIP game is
>> sharper than a razor blade?
>> 
>> BALASHOV: Hell no, it wasn't their block. That fake-ass east coast
>> channel partner crew can cash me 

Re: [VoiceOps] Maximum latency

[Anthony Orlando via VoiceOps]

Cool. Didn't realize u were running voice traffic while doing that?  What was 
the sound quality like?  

Sent from my iPhone

> On Mar 22, 2017, at 5:49 PM, Alex Balashov  wrote:
> 
> What is it that makes people think you need a special application or
> tool to do these things?
> 
> Here's my default gateway on my home LAN:
> 
> sasha@mouse ~> ping -c 5 172.30.105.1
> PING 172.30.105.1 (172.30.105.1) 56(84) bytes of data.
> 64 bytes from 172.30.105.1: icmp_seq=1 ttl=64 time=0.238 ms
> 64 bytes from 172.30.105.1: icmp_seq=2 ttl=64 time=0.618 ms
> 64 bytes from 172.30.105.1: icmp_seq=3 ttl=64 time=0.457 ms
> 64 bytes from 172.30.105.1: icmp_seq=4 ttl=64 time=0.474 ms
> 64 bytes from 172.30.105.1: icmp_seq=5 ttl=64 time=0.382 ms
> 
> --- 172.30.105.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4052ms
> rtt min/avg/max/mdev = 0.238/0.433/0.618/0.126 ms
> 
> And here's my default gateway on my home LAN with 300 ms of latency
> "injected":
> 
> sasha@mouse ~> sudo tc qdisc add dev enp1s0 root netem delay 300ms
> 
> sasha@mouse ~> ping -c 5 172.30.105.1
> PING 172.30.105.1 (172.30.105.1) 56(84) bytes of data.
> 64 bytes from 172.30.105.1: icmp_seq=1 ttl=64 time=300 ms
> 64 bytes from 172.30.105.1: icmp_seq=2 ttl=64 time=300 ms
> 64 bytes from 172.30.105.1: icmp_seq=3 ttl=64 time=300 ms
> 64 bytes from 172.30.105.1: icmp_seq=4 ttl=64 time=301 ms
> 64 bytes from 172.30.105.1: icmp_seq=5 ttl=64 time=300 ms
> 
> --- 172.30.105.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
> rtt min/avg/max/mdev = 300.841/300.902/301.038/0.605 ms
> 
> And here's 300ms latency +/- variability of 40ms:
> 
> sasha@mouse ~> sudo tc qdisc add dev enp1s0 root netem delay 300ms 40ms
> sasha@mouse ~> ping -c 5 172.30.105.1
> PING 172.30.105.1 (172.30.105.1) 56(84) bytes of data.
> 64 bytes from 172.30.105.1: icmp_seq=1 ttl=64 time=299 ms
> 64 bytes from 172.30.105.1: icmp_seq=2 ttl=64 time=316 ms
> 64 bytes from 172.30.105.1: icmp_seq=3 ttl=64 time=324 ms
> 64 bytes from 172.30.105.1: icmp_seq=4 ttl=64 time=321 ms
> 64 bytes from 172.30.105.1: icmp_seq=5 ttl=64 time=326 ms
> 
> --- 172.30.105.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4002ms
> rtt min/avg/max/mdev = 299.411/317.749/326.472/9.706 ms
> 
> And here's back to normal:
> 
> [root@mouse ~]# tc qdisc del dev enp1s0 root netem
> [root@mouse ~]# ping 172.30.105.1
> PING 172.30.105.1 (172.30.105.1) 56(84) bytes of data.
> 64 bytes from 172.30.105.1: icmp_seq=1 ttl=64 time=0.342 ms
> ^C
> --- 172.30.105.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.342/0.342/0.342/0.000 ms
> 
> And here's "loss insertion" of 5%:
> 
> sasha@mouse ~> sudo tc qdisc add dev enp1s0 root netem loss 5%
> sasha@mouse ~> ping -c 5 172.30.105.1
> PING 172.30.105.1 (172.30.105.1) 56(84) bytes of data.
> 64 bytes from 172.30.105.1: icmp_seq=2 ttl=64 time=0.514 ms
> 64 bytes from 172.30.105.1: icmp_seq=3 ttl=64 time=0.501 ms
> 64 bytes from 172.30.105.1: icmp_seq=4 ttl=64 time=0.546 ms
> 64 bytes from 172.30.105.1: icmp_seq=5 ttl=64 time=0.279 ms
> 
> --- 172.30.105.1 ping statistics ---
> 5 packets transmitted, 4 received, 20% packet loss, time 4056ms
> rtt min/avg/max/mdev = 0.279/0.460/0.546/0.105 ms
> 
> sasha@mouse ~> ping -c 5 172.30.105.1
> PING 172.30.105.1 (172.30.105.1) 56(84) bytes of data.
> 64 bytes from 172.30.105.1: icmp_seq=1 ttl=64 time=0.732 ms
> 64 bytes from 172.30.105.1: icmp_seq=2 ttl=64 time=0.471 ms
> 64 bytes from 172.30.105.1: icmp_seq=3 ttl=64 time=0.474 ms
> 64 bytes from 172.30.105.1: icmp_seq=4 ttl=64 time=0.334 ms
> 64 bytes from 172.30.105.1: icmp_seq=5 ttl=64 time=0.367 ms
> 
> --- 172.30.105.1 ping statistics ---
> 5 packets transmitted, 5 received, 0% packet loss, time 4020ms
> rtt min/avg/max/mdev = 0.334/0.475/0.732/0.141 ms
> 
> No, I'm not that brilliant. I Googled it:
> 
> http://stackoverflow.com/questions/614795/simulate-delayed-and-dropped-packets-on-linux
> 
> App to inject latency? You people kill me sometimes.
> 
> -- Alex
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Maximum latency

[Anthony Orlando via VoiceOps]

NIST used to have an impairment app for injecting latency etc.  Been many years 
since I've used it.

  From: Matthew M. Gamble 
 To: Carlos Alvarez ; "voiceops@voiceops.org" 
 
 Sent: Wednesday, March 22, 2017 1:27 PM
 Subject: Re: [VoiceOps] Maximum latency
   
#yiv3088174526 #yiv3088174526 -- _filtered #yiv3088174526 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv3088174526 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv3088174526 #yiv3088174526 p.yiv3088174526MsoNormal, #yiv3088174526 
li.yiv3088174526MsoNormal, #yiv3088174526 div.yiv3088174526MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv3088174526 a:link, 
#yiv3088174526 span.yiv3088174526MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv3088174526 a:visited, #yiv3088174526 
span.yiv3088174526MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv3088174526 
span.yiv3088174526EmailStyle17 
{font-family:Calibri;color:windowtext;}#yiv3088174526 span.yiv3088174526msoIns 
{text-decoration:underline;color:teal;}#yiv3088174526 
.yiv3088174526MsoChpDefault {font-size:10.0pt;} _filtered #yiv3088174526 
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv3088174526 div.yiv3088174526WordSection1 
{}#yiv3088174526 I use a FreeBSD box as a bump-in-the-wire to test and 
introduce additional latency, packet loss, and jitter using ipfw – this is a 
pretty good overview of how to do it: 
http://fjoanis.github.io/2013/08/31/Network_Simulation_FreeBSD_DummyNet/    
From: VoiceOps  on behalf of Carlos Alvarez 

Date: Wednesday, March 22, 2017 at 2:13 PM
To: "voiceops@voiceops.org" 
Subject: Re: [VoiceOps] Maximum latency    Those are some excellent points, 
Ivan.  They do indeed transfer calls regularly between agents in various US 
cities, so I assume the foreign ones will also.  I'll have to ask.    The US 
agents are on MPLS to us, 2-3ms at most.    Also, my satellite phone seems to 
have around 700ms delay, which is quite challenging.  I should try synthesizing 
250ms for them and let them try it.  Not sure how, but assume there's some open 
source out there to do it.          On Wed, Mar 22, 2017 at 11:08 AM, Ivan 
Kovacevic  wrote: 
  The reality is that you can’t get away from it. A private circuit may cut it 
by 10% and provide more stable Jitter… but that’s it. So your client and 
500,000 other agents in the Philippines and India are in the same boat.   Where 
latency gets really nasty and there is some scope to optimize is on call 
transfers/conferences. Make sure there is never hairpinning through the 
off-shore call centre. Or that call transfers or conferences have to double up 
on the path. It will depend on where the media gateways for the solution reside 
and whether you have any optimization when multiple call legs are made through 
your service.    Not sure if this helps…   Best Regards,   Ivan Kovacevic Vice 
President, Client Services Star Telecom |www.startelecom.ca | SIP Based 
Services for Contact Centers | LinkedIn   From: VoiceOps 
[mailto:voiceops-boun...@voiceops.org]On Behalf Of Carlos Alvarez
Sent: March 22, 2017 1:59 PM
To: voiceops@voiceops.org
Subject: [VoiceOps] Maximum latency   One of our larger customers is about to 
launch a new call center in Malaysia.  The connection there is fast, the trace 
looks surprisingly clean and short, but latency is consistently at 239-245ms.  
We've never knowingly had a connection over 130ms.  Does anyone have 
experiences, good or bad, with latency approaching a quarter second?  The 
jitter level seems fine, so I believe they'll just have a delay but decent call 
quality.   Error! Filename not specified. 
   ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


   ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Broadworks Portal Options

[Anthony Orlando via VoiceOps]

CrossSoft/Crosstel has a nice solution



> On Jan 28, 2017, at 8:35 PM, Shripal Daphtary  wrote:
> 
> Look at park bench solutions. Mark tribbe. It's a really nice end user and 
> admin portal and from what I know and the pricing is pretty solid. I haven't 
> done a demo in a while but when I saw it I was really impressed. 
> 
> 
> 
> Thanks, 
> 
> Shripal
> 
>> On Jan 28, 2017, at 9:13 PM, Rob Dawson  wrote:
>> 
>> Wondering what other “small” BroadWorks shops are doing for customer and 
>> provisioning portals? Looking for something at a reasonable cost, or 
>> possibly to get some input from folks that have developed their own to see 
>> what the LOE looked like. Ideally we would be able to augment the 
>> enterprise, group, and user provisioning automation that we have today with 
>> service activation and configuration etc. in addition to giving customers a 
>> slightly better experience than CommPilot. Would also be great to be able to 
>> hide configuration options based on user permissions/type, meaningful CDR 
>> reporting would be great as well.
>>  
>> Thanks,
>> Rob
>>  
>>  
>>  
>>  
>>  
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Metaswitch Equipment

[Anthony Orlando via VoiceOps]

I need a new boat anchor.  How much?

  From: "LeClaire, Keith" 
 To: voiceops@voiceops.org 
 Sent: Monday, November 21, 2016 12:31 PM
 Subject: [VoiceOps] Metaswitch Equipment
   

Hello All,
As a result of a merger I have a very young, complete Metaswitch Integrated 
Softswitch and SBC deployment available for sale as a whole or as components. 
If there is any interest please contact me off list for additional details.
Thank you,Keith
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


   ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Level3 (again)

[Anthony Orlando via VoiceOps]

Looks like something happened earlier.  I was getting long PDD and no audio on 
a few of my calls earlier this morning.  Looks to have cleared.

  From: Peter E 
 To: David Wessell  
Cc: "VoiceOps (voiceops@voiceops.org)" 
 Sent: Monday, October 17, 2016 11:03 AM
 Subject: Re: [VoiceOps] Level3 (again)
   
No issues here (yet). 
Downdetector shows something is up but not nearly what it looked like 2 weeks 
ago.
On Oct 17, 2016, at 11:26, David Wessell  wrote:

Is anyone having issues with SIP traffic from Level3 in ATL and Dallas? I'm 
starting to get reports of audio issues and the MTR's to the L3 IP's in ATL and 
Dallas are looking pretty rough.
Thanks
David

-- 
  
 
 
|  |   David Wessell     President,   Ringfree Communications, Incp: 
828-575-0030 x101   a: 475 S Church St Hendersonville, NC 28792s: 
www.ringfree.com   e: da...@ringfree.com   |


 ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


   ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Vitleity alternatives

[Anthony Orlando via VoiceOps]

Nice Nathan. You just jinxed yourself and them. :)

Sent from my iPhone

> On Sep 8, 2016, at 6:55 PM, Nathan Anderson  wrote:
> 
> Though we had a rough time a few months back when they were under DDoS, and 
> were nearly forced to jump ship as a result (see some of my own posts to this 
> group earlier this year), VoIP Innovations has proven to be rock-solid ever 
> since...it really seems like they managed to lick the problem, and in the 
> process added a bunch of new protections and redundancy that *knock on wood* 
> has made a huge difference.  Although I have a couple of minor quibbles about 
> some of their procedures, their ports department has always been responsive, 
> and I have to say that I really appreciated how they went out of their way to 
> make time and reach out to provide us with updates in the middle of the 
> crisis; this was true with how they handled their customers broadly, but even 
> more appreciated was the specific one-on-one communication and attention we 
> got, even though we are a small fish.
>  
> -- Nathan
>  
> From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Oren 
> Yehezkely
> Sent: Thursday, September 08, 2016 4:30 PM
> To: voiceops@voiceops.org
> Subject: [VoiceOps] Vitleity alternatives
>  
> Hello,
>  
> We have been using Vitelity in the last two years, a few months after they 
> were acquired by Onvoy.
>  
> In the last months we see a deterioration in the quality of their service. 
> Port requests we submit take weeks to complete, when we ask for an update 
> they try to sell us the expedited service for $75!!
>  
> It also seems that they have a big problem with staff as we see a big 
> turnover with the people we deal with.
>  
> Their portal may have been the state of the art years ago, now it feels like 
> it is from the middle ages.
>  
> Looks like Onvoy is busy spending money on acquisitions, but would not let 
> them provide good customer service.
>  
> Would be happy to hear if you can recommend any alternatives.
>  
> Thanks!
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Recording Audio for Troubleshooting

[Anthony Orlando via VoiceOps]

I don't know the law/statute, but the FCC has ruled that it is acceptable to 
record and listen to audio for troubleshooting purposes. In house counsel at my 
last two places of employment have only required a customer email acknowledging 
we were recording their calls. 

What would be the reasoning for recording all calls?  Hope you have a ton of 
storage. 

Sent from my iPhone

> On May 6, 2016, at 9:03 PM, Carlos Alvarez  wrote:
> 
> Andy makes a great point and I should have clarified.  We choose to be overly 
> careful about recording, but I don't think that capturing 100% of RTP is 
> illegal.  Now, losing control of that data, or having employees listen and 
> disclose info would bring down a rain of crap on you.  So our capture systems 
> are on an internal-only network with rather limited access.
> 
> 
> 
>> On Fri, May 6, 2016 at 6:54 PM, Andy Smith  
>> wrote:
>> As far as legal justification, see "18 US Code 2511"; specifically 2a(i).
>> 
>>> On May 6, 2016 5:14 PM, "Peter Fabian"  wrote:
>>> I know that many providers capture voice traffic (RTP) for troubleshooting 
>>> purposes, despite the various privacy laws that are in place against 
>>> wiretapping. 
>>> 
>>> We are planning to have a legal review of our rights and responsibilities 
>>> regarding this practice. In preparation for that, I want to identify what 
>>> regulations are being cited in defense of being able to capture and review 
>>> this traffic? What restrictions do people follow when doing these captures? 
>>> Are limited retention times enforced?
>>> 
>>> Assuming that a justification for initiating the capture is required, what 
>>> qualifies, and do you need to retain records of the justification?
>>> 
>>> We are located in the US and only provide services to US customers, so 
>>> rules relevant to operation in the United States are what I am interested 
>>> in. 
>>> 
>>> We will obviously look to our own legal counsel for direction, and not take 
>>> any information provided here as legal advise.
>>> 
>>> 
>>> 
>>> Thanks
>>> 
>>> Pete
>>> 
>>> 
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>> 
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Recommendations for high-cps SS7 OC-X gear?

[Anthony Orlando via VoiceOps]

I would be concerned about the IP infringement lawsuit they lost to Genband. My 
experience hasn't been good with them when using other application servers. 

Sent from my iPhone

> On Apr 22, 2016, at 12:47 PM, Brandon Buckner <bran...@kamikos.com> wrote:
> 
> Just curious: Is there a reason to avoid Metaswitch? 
> 
> My main experience is in Metaswitch and Sonus, but in Metaswitch it was 
> limited to the 2510 and 3510 gateways and the accompanying servers up to 7.4 
> software and none of the newer blade platforms. At the time I would have said 
> that Metaswitch would have worked quite well for what is being asked, 
> especially if wanting to split across many smaller gateways and 
> geographically distributed. Is there something with the new hardware and/or 
> software I don't know about quality-wise?
> 
> Sonus killed off the GSX4000 which would have lent better to spreading around 
> a bunch of smaller boxes. They still have the GSX9000 which goes up to single 
> OC-3 cards (so you'd have to have a couple to split an OC-48 still), but 
> their main push seems to be the SBC5210 and SBC7000 which are IP only, no 
> TDM. But spread across gateways the call processing can easily do the 500 
> CPS. 
> 
>> On 4/21/2016 5:00 AM, Anthony Orlando via VoiceOps wrote:
>> Avoid Meta at all cost. 
>> 
>> Sent from my iPhone
>> 
>> On Apr 20, 2016, at 10:35 PM, Paul Timmins <p...@timmins.net> wrote:
>> 
>>> You're going to handle 500CPS of legacy sonet based TDM and question 
>>> dropping 7 figures on the solution? *cringes*
>>> 
>>> This is literally what platforms like metaswitch, sonus and many others are 
>>> made for. If you're looking for low cost, Taqua's solution is decent, and 
>>> if you need to take that entire OC-48, you're all but eyeballs deep in 
>>> Sonus or Metaswitch land.
>>> 
>>> -Paul
>>> 
>>>> On Apr 20, 2016, at 17:54, Brooks Bridges <bbrid...@o1.com> wrote:
>>>> 
>>>> Looking for suggestions for NEBS compliant gear that can support SS7, 
>>>> handle OC-3 or higher levels of channels, and can support (in aggregate) 
>>>> up to around 500 cps through a *good* (key word) SIP interface.  I’m 
>>>> willing to entertain the idea of a single larger device that can take a 
>>>> full OC-48 and support the full 500 cps, but I’d prefer spread the load 
>>>> across multiple devices and smaller interfaces for load balancing and 
>>>> redundancy.
>>>>  
>>>> Any pointers?  Obviously there are products out there by the really big 
>>>> players, but I’d really rather not have to drop 7 figures on this project 
>>>> unless I have to.
>>>>  
>>>> Thanks!
>>>>  
>>>> Brooks Bridges | Sr. Voice Services Engineer
>>>> O1 Communications
>>>> 5190 Golden Foothill Pkwy
>>>> El Dorado Hills, CA 95762
>>>> office: 916.235.2097 | main: 888.444., Option 2
>>>> email: bbrid...@o1.com | web: www.o1.com
>>>>  
>>>> ___
>>>> VoiceOps mailing list
>>>> VoiceOps@voiceops.org
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>> 
>> 
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Recommendations for high-cps SS7 OC-X gear?

[Anthony Orlando via VoiceOps]

I've used in the past. Good success with them. 

Sent from my iPhone

> On Apr 22, 2016, at 1:26 PM, Calvin Ellison <calvin.elli...@voxox.com> wrote:
> 
> Anyone using TelcoBridges gear?
> 
> 
> 
> Regards,
> 
> Calvin Ellison
> Voice Operations Engineer
> calvin.elli...@voxox.com
> +1 (213) 285-0555
> 
> ---
> voxox.com 
> 5825 Oberlin Drive, Suite 5
> San Diego, CA 92121
> 
> 
>> On Fri, Apr 22, 2016 at 10:47 AM, Brandon Buckner <bran...@kamikos.com> 
>> wrote:
>> Just curious: Is there a reason to avoid Metaswitch? 
>> 
>> My main experience is in Metaswitch and Sonus, but in Metaswitch it was 
>> limited to the 2510 and 3510 gateways and the accompanying servers up to 7.4 
>> software and none of the newer blade platforms. At the time I would have 
>> said that Metaswitch would have worked quite well for what is being asked, 
>> especially if wanting to split across many smaller gateways and 
>> geographically distributed. Is there something with the new hardware and/or 
>> software I don't know about quality-wise?
>> 
>> Sonus killed off the GSX4000 which would have lent better to spreading 
>> around a bunch of smaller boxes. They still have the GSX9000 which goes up 
>> to single OC-3 cards (so you'd have to have a couple to split an OC-48 
>> still), but their main push seems to be the SBC5210 and SBC7000 which are IP 
>> only, no TDM. But spread across gateways the call processing can easily do 
>> the 500 CPS. 
>> 
>>> On 4/21/2016 5:00 AM, Anthony Orlando via VoiceOps wrote:
>>> Avoid Meta at all cost. 
>>> 
>>> Sent from my iPhone
>>> 
>>> On Apr 20, 2016, at 10:35 PM, Paul Timmins <p...@timmins.net> wrote:
>>> 
>>>> You're going to handle 500CPS of legacy sonet based TDM and question 
>>>> dropping 7 figures on the solution? *cringes*
>>>> 
>>>> This is literally what platforms like metaswitch, sonus and many others 
>>>> are made for. If you're looking for low cost, Taqua's solution is decent, 
>>>> and if you need to take that entire OC-48, you're all but eyeballs deep in 
>>>> Sonus or Metaswitch land.
>>>> 
>>>> -Paul
>>>> 
>>>>> On Apr 20, 2016, at 17:54, Brooks Bridges <bbrid...@o1.com> wrote:
>>>>> 
>>>>> Looking for suggestions for NEBS compliant gear that can support SS7, 
>>>>> handle OC-3 or higher levels of channels, and can support (in aggregate) 
>>>>> up to around 500 cps through a *good* (key word) SIP interface.  I’m 
>>>>> willing to entertain the idea of a single larger device that can take a 
>>>>> full OC-48 and support the full 500 cps, but I’d prefer spread the load 
>>>>> across multiple devices and smaller interfaces for load balancing and 
>>>>> redundancy.
>>>>>  
>>>>> Any pointers?  Obviously there are products out there by the really big 
>>>>> players, but I’d really rather not have to drop 7 figures on this project 
>>>>> unless I have to.
>>>>>  
>>>>> Thanks!
>>>>>  
>>>>> Brooks Bridges | Sr. Voice Services Engineer
>>>>> O1 Communications
>>>>> 5190 Golden Foothill Pkwy
>>>>> El Dorado Hills, CA 95762
>>>>> office: 916.235.2097 | main: 888.444., Option 2
>>>>> email: bbrid...@o1.com | web: www.o1.com
>>>>>  
>>>>> ___
>>>>> VoiceOps mailing list
>>>>> VoiceOps@voiceops.org
>>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>> ___
>>>> VoiceOps mailing list
>>>> VoiceOps@voiceops.org
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>> 
>>> 
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>> 
>> 
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Recommendations for high-cps SS7 OC-X gear?

[Anthony Orlando via VoiceOps]

When was that?  1999?

Sent from my iPhone

> On Apr 20, 2016, at 10:41 PM, Alex Balashov  wrote:
> 
> ‎Having seen GSXs knocked over with 100-200 CPS, I'd be inclined to even 
> question that, though I don't doubt Sonus and friends make a big enough box 
> for those walking in with a lotter winner-sized novelty check.
> ‎
> --
> Alex Balashov | Principal | Evariste Systems LLC
> 1447 Peachtree Street NE, Suite 700
> Atlanta, GA 30309
> United States
> 
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> Sent from my BlackBerry.
>   Original Message  
> From: Paul Timmins
> Sent: Wednesday, April 20, 2016 23:36
> To: Brooks Bridges
> Cc: voiceops@voiceops.org
> Subject: Re: [VoiceOps] Recommendations for high-cps SS7 OC-X gear?
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Recommendations for high-cps SS7 OC-X gear?

[Anthony Orlando via VoiceOps]

Avoid Meta at all cost. 

Sent from my iPhone

> On Apr 20, 2016, at 10:35 PM, Paul Timmins  wrote:
> 
> You're going to handle 500CPS of legacy sonet based TDM and question dropping 
> 7 figures on the solution? *cringes*
> 
> This is literally what platforms like metaswitch, sonus and many others are 
> made for. If you're looking for low cost, Taqua's solution is decent, and if 
> you need to take that entire OC-48, you're all but eyeballs deep in Sonus or 
> Metaswitch land.
> 
> -Paul
> 
>> On Apr 20, 2016, at 17:54, Brooks Bridges  wrote:
>> 
>> Looking for suggestions for NEBS compliant gear that can support SS7, handle 
>> OC-3 or higher levels of channels, and can support (in aggregate) up to 
>> around 500 cps through a *good* (key word) SIP interface.  I’m willing to 
>> entertain the idea of a single larger device that can take a full OC-48 and 
>> support the full 500 cps, but I’d prefer spread the load across multiple 
>> devices and smaller interfaces for load balancing and redundancy.
>>  
>> Any pointers?  Obviously there are products out there by the really big 
>> players, but I’d really rather not have to drop 7 figures on this project 
>> unless I have to.
>>  
>> Thanks!
>>  
>> Brooks Bridges | Sr. Voice Services Engineer
>> O1 Communications
>> 5190 Golden Foothill Pkwy
>> El Dorado Hills, CA 95762
>> office: 916.235.2097 | main: 888.444., Option 2
>> email: bbrid...@o1.com | web: www.o1.com
>>  
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Virtualized SBC

[Anthony Orlando via VoiceOps]

You didn't just seriously say that?

Sent from my iPhone

> On Apr 7, 2016, at 9:54 AM, Alex Balashov  wrote:
> 
> Indeed. As usual, it's very seldom about whether words arranged in a certain 
> order result in useful meaning. Marketing into the Bellhead CxO suite is a 
> kind of meme laundering operation: "what can of horseshit can we seed into 
> golf course and country club conversations?"
> 
> Apparently NFV‎ is the latest thing the barnacles are pumping out. Somewhere, 
> behind hundreds of directors, senior managers and channel partner liaisons, 
> there's a shared cube in the back with three poor H-1Bs who are all going, 
> "Uh, dude, we've been doing this since 2004. Is that what they're calling it 
> now?"
> 
> --
> Alex Balashov | Principal | Evariste Systems LLC
> 1447 Peachtree Street NE, Suite 700
> Atlanta, GA 30309
> United States
> 
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> Sent from my BlackBerry.
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Make Kamailio Great Again!

[Anthony Orlando via VoiceOps]

LOL. What were you drinking last night?

Sent from my iPhone

> On Apr 1, 2016, at 6:29 AM, Alex Balashov  wrote:
> 
> For immediate release:
> 
> ATLANTA, GA (1 April 2016)--Alex J. Balashov, a self-styled
> businessman based in Atlanta, Georgia, USA, has a plan to "Make
> Kamailio Great Again".
> 
> "Evariste Systems is huge. My name is on the building," said
> Balashov of his iconic VoIP consulting brand.
> 
> "And you know what, I have been very successful. Everybody loves me."
> 
> Balashov has capitalised on a contentious election cycle marked by
> deep political polarisation, growing income inequality and geopolitical
> challenges such as global terrorism. And his sharp message of alarm
> about the declining influence of the Kamailio SIP server project has
> resonated with increasing numbers in the CxO suite, vaulting him to
> the lead in the race for the IETF SIP Working Group nomination,
> according to recent polls of primary voters.
> 
> He has been quick to tout his competitive credentials in a tough
> global open-source ecosystem. At a recent colloqium on unified
> communications, he asked:
> 
> "When was the last time anybody saw us beating, let's say, OpenSIPS
> in Git commits? They kill us. I beat OpenSIPS all the time. All the
> time."
> 
> As Balashov sees it, a major cause of the beleaguered Kamailio
> project's woes lies in its liberal patch acceptance policy and
> lax scrutiny of third-party contributions:
> 
> "When GitHub sends its people, they're not sending their best.
> They're not sending you. They're not sending you. They're sending
> people that have lots of problems, and they're bringing those
> problems. They're bringing drugs. They're bringing crime. They're
> rapists. And some, I assume, are good people."
> 
> He has proposed a controversial solution that has drawn ire from
> liberal ranks in the open-source community, but has also attracted
> applause and standing ovations at his speaking engagements:
> 
> "We have to have a firewall around the Kamailio source code. We
> have to have an access control list. And in that firewall, we're
> going to have a big fat door where commits and pull requests can
> come into the master branch, but they have to come in legally.
> The firewall will go up, and GitHub will start behaving."
> 
> Balashov's firewall proposal has been met with scorn from critics who
> deride it as impractical and quixotic. In particular, commentators
> have raised questions about funding and resources as well as GitHub's
> willingness to entertain a boundary around a project in its vicinity.
> Balashov isn't concerned, however:
> 
> "I will build a great firewall--and nobody builds firewalls better
> than me, believe me--and I'll build them very inexpensively. I will
> build a great, great stateful packet inspection wall on our border
> with GitHub, and I will make GitHub pay for that wall. Mark my words."
> 
> He has also been rebuked by rival IETF leadership candidates for his
> often acerbic Twitter remarks directed at Lennart Poettering and the
> developers of "firewalld". As he sees it, however, the network effects
> of social media are a strength:  "My Twitter has become so powerful
> that I can actually make my enemies tell the truth." He scoffed at
> the suggestion that his characterisations of industry actors behind
> the RedHat-led "systemd" movement are misleading:
> 
> "RedHat was the worst Steward of Linux in the history of the kernel.
> There has never been a Steward so bad as RedHat. The source code
> blew up around us. We lost everything, including all synergies.
> There wasn't one good thing that came out of that administration or
> them being Stewards of Linux."
> 
> Balashov's idiosyncratic campaign is not standing still. He has proven
> to be a capable populist, adapting rapidly to an evolving sense of the
> kinds of pronouncements that activate his swelling crowds of devotees.
> Along the way, he has deftly deflected calls to subject his policy
> proposals to expert review.
> 
> "I know what I'm doing, and I listen to a lot of people, I talk to
> a lot of people, and at the appropriate time I'll tell you who
> the people are. But I speak to a lot of people, but my primary
> consultant is myself, and I have a good instinct for this stuff."
> 
> At a recent gathering of SIP stack interoperability specialists,
> Balashov the latest pillar of his platform to "Make Kamailio Great
> Again", in view of growing security vulnerabilities in the latest
> Kamailio modules:
> 
> "Alex J. Balashov is calling for a total and complete shutdown of
> commits entering the master branch from the territory of the European
> Union until our project's representatives can figure out what's going
> on. According to Netcraft, among others, there are a lot of buffer
> overflows in Kamailio by large segments of the EU population."
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> 

Re: [VoiceOps] G.729 A/B Experiences

[Anthony Orlando via VoiceOps]

Depends on whether you want to provide a quality product or not.  G.729 already 
hovers just above the line of "satisfied".  The slightest impairment drives 
that below what is considered acceptable.  I wouldn't deploy it.  

  From: Robert Johnson 
 To: voiceops@voiceops.org 
 Sent: Friday, March 11, 2016 5:43 PM
 Subject: [VoiceOps] G.729 A/B Experiences
   
Hey everyone,

I'm looking to deploy a lower-bandwidth codec, and am wondering what
everyone's experience has been with G.729, primary regarding voice
quality. Historically, we have limited our codec use to G.711.

Some test calls in the lab are showing promising results, I'm just
curious what might happen in the real-world.

Thank you for your time!!
-- 
Robert Johnson
BendTel, Inc.
(541)389-4020
Central Oregon's Own Telephone and Internet Service Provider
www.bendtel.com/about/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


   

Sent from Yahoo Mail  From: Robert Johnson 
 To: voiceops@voiceops.org 
 Sent: Friday, March 11, 2016 5:43 PM
 Subject: [VoiceOps] G.729 A/B Experiences
   
Hey everyone,

I'm looking to deploy a lower-bandwidth codec, and am wondering what
everyone's experience has been with G.729, primary regarding voice
quality. Historically, we have limited our codec use to G.711.

Some test calls in the lab are showing promising results, I'm just
curious what might happen in the real-world.

Thank you for your time!!
-- 
Robert Johnson
BendTel, Inc.
(541)389-4020
Central Oregon's Own Telephone and Internet Service Provider
www.bendtel.com/about/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] VoIP Monitor - How do you roll ?

[Anthony Orlando via VoiceOps]

I have.  It's always that build vs buy for me. Before Empirix we had various 
sniffers etc.  I like having a vendor/partner I can lean on for critical items. 
 I think most companies overlook the importance of tools.  In my current role 
we took ticket cycle time down from 160 hrs to 22 mostly attributed to adding 
Empirix. Adding their analytics package will then enable me to be proactive and 
 able to detect issues BEFORE our customers feel them.  This is obviously the 
holy grail for all of us.  

We will all have issues, but it's the tools that will set us apart and will 
enable us to resolve problems faster.  

  From: Peter E 
 To: Anthony Orlando  
Cc: Matt Ladewig ; "voiceops@voiceops.org" 

 Sent: Thursday, February 11, 2016 10:14 PM
 Subject: Re: [VoiceOps] VoIP Monitor - How do you roll ?
   
Keep beating that drum, Anthony. Have you tried voipmonitor? You might be 
surprised.
On Feb 11, 2016, at 22:21, Anthony Orlando  wrote:

Empirix Peter. Empirix 

Sent from my iPhone
On Feb 11, 2016, at 8:37 PM, Peter E  wrote:



We're in the middle of a trial of voipmonitor so this topic is timely as we're 
crushing the lab boxes and therefore don't trust any of the stats it is 
currently showing (MOS, PDD, etc). 
If you're capturing sip + rtp headers and you have a need (plus permission) to 
record full rtp for a single user, how's that done in the interface?
On Feb 11, 2016, at 15:40, Matt Ladewig  wrote:

#yiv7350399856 #yiv7350399856 -- _filtered #yiv7350399856 {panose-1:2 4 5 3 5 4 
6 3 2 4;} _filtered #yiv7350399856 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 
3 2 4;}#yiv7350399856 #yiv7350399856 p.yiv7350399856MsoNormal, #yiv7350399856 
li.yiv7350399856MsoNormal, #yiv7350399856 div.yiv7350399856MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7350399856 a:link, 
#yiv7350399856 span.yiv7350399856MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv7350399856 a:visited, #yiv7350399856 
span.yiv7350399856MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv7350399856 
span.yiv7350399856EmailStyle17 {color:#1F497D;}#yiv7350399856 
.yiv7350399856MsoChpDefault {} _filtered #yiv7350399856 {margin:1.0in 1.0in 
1.0in 1.0in;}#yiv7350399856 div.yiv7350399856WordSection1 {}#yiv7350399856 
Agreed, all sip signaling with RTP headers only for all calls. Only full RTP 
for specific troubleshooting and even then only by a very limited staff.    
From: VoiceOps [mailto:voiceops-boun...@voiceops.org]On Behalf Of Christopher 
Aloi
Sent: Thursday, February 11, 2016 11:35 AM
To: Carlos Alvarez ; voiceops@voiceops.org
Subject: Re: [VoiceOps] VoIP Monitor - How do you roll ?    We capture SIP 
signaling and RTP headers to evaluate the call quality our customers and 
carriers.  Using the data we can proactively solve problems etc..    If we are 
actively troubleshooting an issue we may capture the full RTP to analyze the 
packets.  The need to capture the full packet is pretty rare.       On Thu, Feb 
11, 2016 at 2:11 PM Carlos Alvarez  wrote: 
Doesn't anyone else see a major privacy/compliance/legal issue with capturing 
all packets?  We only record if a customer explicitly allows us as part of a 
problem complaint.    Anyway, that's my answer...only do it when necessary.     
  On Thu, Feb 11, 2016 at 11:45 AM, Christopher Aloi  wrote: 
Hey Everyone -     I know many of you are happy VoIP monitor customers, I am 
too !    Currently I have a "capture" node deployed in my three data centers 
pushing packets back to a centralized DB/GUI instance.  I hit some bottle necks 
around disk storage on the central instance and lost packets on the remote 
capture nodes.  I'm in the market for some new hardware to tidy this up a bit, 
curious - what does your deployment look like?  what type of hardware are you 
using?  do you split your capturing up (send/receive) or have any other 
hardware tips?    Thanks -     - Chris       

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops 
   ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops 
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops



  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] VoIP Monitor - How do you roll ?

[Anthony Orlando via VoiceOps]

Empirix Peter. Empirix 

Sent from my iPhone

> On Feb 11, 2016, at 8:37 PM, Peter E  wrote:
> 
> We're in the middle of a trial of voipmonitor so this topic is timely as 
> we're crushing the lab boxes and therefore don't trust any of the stats it is 
> currently showing (MOS, PDD, etc). 
> 
> If you're capturing sip + rtp headers and you have a need (plus permission) 
> to record full rtp for a single user, how's that done in the interface?
> 
> On Feb 11, 2016, at 15:40, Matt Ladewig  wrote:
> 
> Agreed, all sip signaling with RTP headers only for all calls. Only full RTP 
> for specific troubleshooting and even then only by a very limited staff.
>  
> From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of 
> Christopher Aloi
> Sent: Thursday, February 11, 2016 11:35 AM
> To: Carlos Alvarez ; voiceops@voiceops.org
> Subject: Re: [VoiceOps] VoIP Monitor - How do you roll ?
>  
> We capture SIP signaling and RTP headers to evaluate the call quality our 
> customers and carriers.  Using the data we can proactively solve problems 
> etc..   
> If we are actively troubleshooting an issue we may capture the full RTP to 
> analyze the packets.  The need to capture the full packet is pretty rare.
>  
>  
> On Thu, Feb 11, 2016 at 2:11 PM Carlos Alvarez  wrote:
> Doesn't anyone else see a major privacy/compliance/legal issue with capturing 
> all packets?  We only record if a customer explicitly allows us as part of a 
> problem complaint.
>  
> Anyway, that's my answer...only do it when necessary.
>  
>  
> On Thu, Feb 11, 2016 at 11:45 AM, Christopher Aloi  wrote:
> Hey Everyone - 
>  
> I know many of you are happy VoIP monitor customers, I am too !
>  
> Currently I have a "capture" node deployed in my three data centers pushing 
> packets back to a centralized DB/GUI instance.  I hit some bottle necks 
> around disk storage on the central instance and lost packets on the remote 
> capture nodes.  I'm in the market for some new hardware to tidy this up a 
> bit, curious - what does your deployment look like?  what type of hardware 
> are you using?  do you split your capturing up (send/receive) or have any 
> other hardware tips?
>  
> Thanks - 
>  
> - Chris
>  
>  
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> 
>  
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Instant Porting

[Anthony Orlando via VoiceOps]

That's why I hired your firm ML!!!  You know how to deal with these issues and 
get it done. 

Sent from my iPhone

> On Feb 10, 2016, at 11:20 AM, Mary Lou Carey  
> wrote:
> 
> I couldn't pull up the WPR, but obviously their WPR is nothing like an LSR, 
> which is all written in code and requires a bunch of fields that verify way 
> more than just the TN/PIN/Address/ZIP accuracy.
>  
> My guess is that it doesn't require a lot of training to teach someone how to 
> fill out a WPRs because they're in English and to the point. Unlike LSRs that 
> you need an LSOG guide to understand what it's asking for, hours of training 
> to know which fields to populate, and the patience of a saint to fight your 
> way through the process! Sounds like WPRs is the form that all carriers 
> should use to simplify the process, but then iconectiv would be out of 
> business and it would make it way easier for carriers to port numbers away 
> from the ILECs so I don't see that happening without a fight. I guess I 
> should be thankful because it gives people like me a job, but the whole 
> ASR/LSR process just seems stupid to me - like reading the bible in Latin to 
> a group of people who only speak English! 
>  
> Mary Lou Carey
> BackUP Telecom Consulting
> 615-791-9969 
>  
>> On February 10, 2016 at 12:00 PM Paul Timmins  wrote:
>> 
>> My understanding is that the winning carrier submits the subscription, 
>> issues an electronic WPR 
>> (https://www.syniverse.com/files/Single_Line_WPR.pdf) - similar to an LSR. 
>> The losing carrier verifies the WPR's accuracy (TN/PIN/Address/Zip) and 
>> issues a confirmation and concurrence, and then the winning carrier 
>> electronically activates in SOA.
>> 
>> Given this is 100% electronic (and all the majors use Syniverse for their 
>> SOA) it's immediate. Wireless carriers don't really have to worry about 
>> things like "do they have complex services like DSL, FTTH with bundle 
>> packaging, etc". They just drop the customer's subscriber information out of 
>> the switch and send a final bill.
>> 
>> -Paul
>> 
>>> On 02/10/2016 11:50 AM, Mary Lou Carey wrote:
>>> I really wonder if the big wireless carriers follow the same process that 
>>> wireline carriers do because the typical wireline process takes more than 5 
>>> minutes to complete. The whole process is:
>>>  
>>> 1. Issue an LSR order to the losing carrier requesting the port.
>>> 2. When you get confirmation, submit the port request in NPAC (or a SOA 
>>> system connected to NPAC)
>>> 3. Losing carrier confirms the port
>>> 4. Winning carrier accepts the port
>>>  
>>> The greatest portion of time is spent on getting the losing carrier to 
>>> accept the LSR and give confirmation, so I'm thinking these wireless 
>>> carriers must have agreements set up between them that allows them to 
>>> bypass the LSR process and just complete the NPAC work!
>>>  
>>> Mary Lou Carey
>>> BackUP Telecom Consulting
>>> 615-791-9969 
>>>  
 On February 10, 2016 at 9:57 AM Nick Olsen  wrote:
 
 Exactly this.
  
 I actually ported my personal cell number to Verizon from ATT yesterday.
  
 Gave the rep my ATT account number, He 30 seconds later asked me for the 
 PIN I set on my ATT account. I provided and my number was working before I 
 hit the door on the way out. Total port time was <5 Min.
  
 I questioned the Rep if this was always the case and he said only if 
 porting from Sprint/ATT/T-Mobile. And that basically any other carrier 
 (Not including MVNO's of the above) took 3-5 Business days. Which is about 
 in-line with my current wireline porting.
  
 I figure they all exchange so many numbers a day it was in all of their 
 best interest to work together.
  
 Not to mention, By automating the process. They don't have to keep an 
 entire call center worth of LNP personnel to handle their volume.
 
 Nick Olsen
 Network Operations
 (855) FLSPEED  x106
 
 
  
 From: "Alexander Lopez" 
 Sent: Tuesday, February 09, 2016 6:00 PM
 To: "Alex Balashov" , "voiceops@voiceops.org" 
 
 Subject: Re: [VoiceOps] Instant Porting
  
 I think the incentive is to cooperate because it is a relatively small 
 group of wireless carriers compared to wireline. 
  
 The main reason being that they don't want their ports held up, so they 
 work well with others.
  
 Also since there is a small group they could automate the back office 
 processes between them and submit the request and aknowledgment quickly 
 and without human interaction.
 
 
  Original message 
 From: Alex Balashov 
 Date: 2/9/2016 4:32 PM (GMT-05:00)
 To: voiceops@voiceops.org
 Subject: Re: [VoiceOps] Instant Porting

Re: [VoiceOps] Sprint sales contacts

[Anthony Orlando via VoiceOps]

Smith, Belinda [WLS] 


 

  From: Paul Timmins 
 To: voiceops@voiceops.org 
 Sent: Wednesday, December 30, 2015 10:56 AM
 Subject: Re: [VoiceOps] Sprint sales contacts
   
A little birdie told me they are rolling up the sidewalks on their 
IXC/TDM voice product entirely but I could be really wrong on that.

On 12/30/2015 11:14 AM, Collin Rose wrote:
> Any one have any Sprint wholesale sales contacts (TDM voice)?  My two
> contacts seem to have disappeared as my their email addresses are both
> bouncing.
>
>
> Collin Rose
> DayStarr Communications
> P: (989) 720-1000
> F: (989) 720-6060
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Leveraging a CLEC operating license to secure phone numbers

[Anthony Orlando via VoiceOps]

Agreed. She's the best. 

Sent from my iPhone

> On Dec 22, 2015, at 1:41 PM, Mary Lou Carey  wrote:
> 
> Thanks for the referral Alex! 
> 
> > On December 15, 2015 at 5:49 PM Alex Balashov  
> > wrote:
> > 
> > 
> > On 12/15/2015 05:47 PM, Armand De Sio wrote:
> > 
> > > We've recently been issued a CLEC license in the state of New Jersey and
> > > I'd like to leverage that to secure phone numbers for my customers. Who
> > > would I need to contact about Interconnects and how would I go about
> > > getting a block of numbers assigned to my company?
> > 
> > You obtained CLEC licence without knowing this information? :-)
> > 
> > Sounds like you need to talk to Mary Lou Carey:
> > 
> > Mary Lou Carey
> > BackUP Telecom Consulting
> > mary...@backuptelecom.com
> > Office: 615-791-9969
> > 
> > -- Alex
> > 
> > -- 
> > Alex Balashov | Principal | Evariste Systems LLC
> > 303 Perimeter Center North, Suite 300
> > Atlanta, GA 30346
> > United States
> > 
> > Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> > ___
> > VoiceOps mailing list
> > VoiceOps@voiceops.org
> > https://puck.nether.net/mailman/listinfo/voiceops
> Mary Lou Carey
> BackUP Telecom Consulting
> mary...@backuptelecom.com
> Office: 615-791-9969
> Cell: 615-796-
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Broadsoft and Metaswitch

[Anthony Orlando via VoiceOps]

Who is using Broadsoft and Metaswitch?  I have a call flow question and 
something Meta is calling optimization where they are not passing a re-invite.  
Let me know if you are willing to discuss this with me.___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] HPBX over ADSL

[Anthony Orlando via VoiceOps]

Is anyone having success deploying HPBX over DSL?  Not service providers that 
own the plant but those of you using another providers DSL.  Have you been 
successful?  If so what were the engineering guidelines you used?  What were 
the tolerances you used?  Any feedback would be very welcomed.___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Lack of Quality Industry-wide

[Anthony Orlando via VoiceOps]

You are correct Peter.  It's a  constant struggle.  For years I used a product 
from Empirix called Intelisight.  It gave us the ability to monitor carriers 
(and other managed objects) with defined sets of KPI's.  Once I saw a carrier 
have issues (PDD, quality, excessive 503's) I used to call them and tell them 
they had a problem.  Hours or days later they would resolve.  I got away from 
that practice and just routed around them.   Funny how they notice that.  Once 
the issue was resolved I put them in a penalty box and slowly added traffic.  
Once they realized I was measuring their performance and there would be 
financial repercussions it's amazing how the quality of their under lying 
carriers improved.  My carrier ticket count dropped by 25-30%.
  From: Peter Beckman 
 To: VoiceOps  
 Sent: Tuesday, October 6, 2015 10:27 AM
 Subject: [VoiceOps] Lack of Quality Industry-wide
   
In the last 3 months I've been consistently frustrated by my carriers.

    "3-4 minutes is acceptable delay for delivery of SMS messages."

    "Our termination change now throws 504s instead of 503s 20-50% of the
      time and adds 2-3 seconds of delay to your call attempts. We didn't
      notice, and though you did, it's been 3 days and we haven't fixed it.
      Sorry!"

    "There was an outage? Works for me now!"

    "Someone upstream is intentionally dropping SMS messages. But we can't
      say who it is, and we can't get them to fix it because they aren't our
      carrier."

Does the industry just suck at knowing when their stuff is broken, or only
react when enough customers complain? Do carriers simply not instrument,
monitor or graph metrics of their operations and proactively monitor and
fix issues?

My Thresholds:
    * SMS delivery end-to-end: Under 10 seconds
    * 503 Route Advance: Under 1 second
    * Response/Notice to termination/API/origination/server outage: 20 minutes
    * Fix a major issue (or provide a fix timeline): 3 days

Too many times in the last few months _I_ have been the canary in the
carrier's coal mine bringing attention to places where their operations are
broken or delayed. And even then, unless I escalate to management (like CEO
level), things move at the speed of a sloth. Most of the time it seems I
monitor my carrier's infrastructure more closely than they do.

I hope and dream of the unicorn carrier -- such great operational awareness
and execution that it doesn't matter how great their customer service is,
I'll never have to talk to them.

Beckman
---
Peter Beckman                                                  Internet Guy
beck...@angryox.com                                http://www.angryox.com/
---
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Lack of Quality Industry-wide

[Anthony Orlando via VoiceOps]

Just to be clear that was my OB traffic not my IB.  That's a whole different 
ball game. 
  From: Peter Beckman 
 To: Anthony Orlando  
Cc: VoiceOps  
 Sent: Tuesday, October 6, 2015 11:34 AM
 Subject: Re: [VoiceOps] Lack of Quality Industry-wide
   
That's a great story Anthony! It's similar to my issues. I already do this
for termination. DID and SMS issues are more difficult to manage. And the
issues you have with one carrier that drives you to mass port your DIDs
that you hope to escape start happening with your new carrier.

I wish carriers would have the same level of visibility in their service
and infrastructure as you seemed to have with Intellisight, and then fix
the problems proactively when they find them.

    "What gets measured gets managed."

So true. So elusive in this business.

Beckman



On Tue, 6 Oct 2015, Anthony Orlando wrote:

> You are correct Peter.  It's a  constant struggle.  For years I used a
> product from Empirix called Intelisight.  It gave us the ability to
> monitor carriers (and other managed objects) with defined sets of KPI's.
>  Once I saw a carrier have issues (PDD, quality, excessive 503's) I used
> to call them and tell them they had a problem.  Hours or days later they
> would resolve.  I got away from that practice and just routed around
> them.   Funny how they notice that.  Once the issue was resolved I put
> them in a penalty box and slowly added traffic.  Once they realized I was
> measuring their performance and there would be financial repercussions
> it's amazing how the quality of their under lying carriers improved.  My
> carrier ticket count dropped by 25-30%.

---
Peter Beckman                                                  Internet Guy
beck...@angryox.com                                http://www.angryox.com/
-

  ___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Hackers Crash Clay Co. Phones ...

[Anthony Orlando via VoiceOps]

i was thinking a conf call.  Maybe 4-5 participants.  Let me know who's 
interested.


On Tuesday, August 19, 2014 12:39 AM, Ryan Delgrosso ryandelgro...@gmail.com 
wrote:
 


Discuss away, were all riveted with antici..

:) 


On 8/18/2014 7:52 PM, Anthony Orlando via VoiceOps wrote:

All 
  I might have a solution that I'd like to talk to the group about. It can not 
only detect but could use your switch API to take action. Who's interested in 
discussing it!


Sent from my iPhone

On Aug 18, 2014, at 9:59 PM, Tim Jackson jackson@gmail.com wrote:


I think Ryan's point here is getting data on in-progress calls into it instead 
of completed calls..
AFAIK CPM basically watches the real time call logs from the CFS, and only 
knows about calls once they complete.
On Aug 18, 2014 6:04 PM, Simon Dredge simon.dre...@metaswitch.com wrote:

Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive 
analytics. It'll trigger immediately (in real-time) on an anomaly, informing 
the operator that action is required so they can take necessary action.

Cheers,


Simon.

-Original Message-
From: Ryan Delgrosso [mailto:ryandelgro...@gmail.com]
Sent: Monday, August 18, 2014 4:32 PM
To: Simon Dredge
Cc: voiceops@voiceops.org
Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...

Simon,
I think the gotcha with CPM in this scenario is its a
  great tool for determining this has happened but not so
  great for building a mitigation solution.

Is CPM driven off of CDR's or off of the SAS datastream or
  some other source?

If its CDR driven you will be blind to this problem
  because you wont be measuring calls that are rejected due
  to lack of capacity(no cdr cut).
If its driven off of SAS data you will get the
  missed/incomplete call stats but at the cost of speed
  (multiple orders of magnitude more data than CDR's)

It would be interesting to hear if this perhaps uses a
  different datasource. Perhaps there is a facility in
  perimeta that informs this better than CFS data sources.

-Ryan

On 8/18/2014 3:36 PM, Simon Dredge wrote:
 I know many meta-users like the new-ish call pattern
  monitor. It uses weighted profiling benchmarking algos
  similar to NBAD:

 http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern-
 Monitor.pdf

 Cheers,


 Simon.


 -Original Message-
 From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of
 Ryan Delgrosso
 Sent: Monday, August 18, 2014 1:53 PM
 To: ECG - Mark Lindsey
 Cc: voiceops@voiceops.org
 Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones
  ...

 I dunno that's a slippery slope. Im not a proponent
  of putting management of your network services into
  someone elses hands, especially things like this where the
  service provider should have visibility into what they are
  or are not admitting.

 Agreed on your synopsis of call admission control,
  the border should be able to make these decisions rapidly,
  freeing up softswitch resources to actually serve
  customers.

 This sounds like good territory for an acme SPL
  plugin, possibly in
 conjunction with this enum extension
 http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i 
 dont see a clear path for this in the TDM world but my exposure there is 
 limited. It would seem like a good solution might be using ENUM (with 
 source URI) to build statistics centrally based on calling/called numbers 
 and then forcing the ENUM response once thresholds are hit to illicit an 
 appropriate decline message for flagged invites with a retry-after interval 
 allowing you to effectively throttle specific call scenarios assuming your 
 origination carriers will behave correctly.

 2 of the examples we discussed previously were:

 1: Social media death star. Justin biebers (or anyone
  else with millions of rabid followers) twitter account 
  (53.7M followers) gets hacked and attacker tweets Call
  this number for free tickets or similar.

 2: T-DOS using stolen sip accounts effectively
  turning other service providers into a death star. More
  damage per source number (higher CPS than social media per
  attacker but less distributed source). This one seems much
  easier to create given the ease with which stolen sip
  accounts can be acquired, and harder to mitigate if the
  stolen accounts support callerID spoofing.

 Both of these situations are exacerbated by LCR
  resellers creating at times 10-20 invites from 1 due to
  route advancing when the destination is truly congested,
  which gets worse when the LCR resellers in turn have
  resellers in route

Re: [VoiceOps] Hackers Crash Clay Co. Phones ...

[Anthony Orlando via VoiceOps]

All 
  I might have a solution that I'd like to talk to the group about. It can not 
only detect but could use your switch API to take action. Who's interested in 
discussing it!


Sent from my iPhone

 On Aug 18, 2014, at 9:59 PM, Tim Jackson jackson@gmail.com wrote:
 
 I think Ryan's point here is getting data on in-progress calls into it 
 instead of completed calls..
 
 AFAIK CPM basically watches the real time call logs from the CFS, and only 
 knows about calls once they complete.
 
 On Aug 18, 2014 6:04 PM, Simon Dredge simon.dre...@metaswitch.com wrote:
 Heya, Ryan - It's SAS-like - But proactive analysis rather than reactive 
 analytics. It'll trigger immediately (in real-time) on an anomaly, informing 
 the operator that action is required so they can take necessary action.
 
 Cheers,
 
 
 Simon.
 
 -Original Message-
 From: Ryan Delgrosso [mailto:ryandelgro...@gmail.com]
 Sent: Monday, August 18, 2014 4:32 PM
 To: Simon Dredge
 Cc: voiceops@voiceops.org
 Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
 
 Simon,
 I think the gotcha with CPM in this scenario is its a great tool for 
 determining this has happened but not so great for building a mitigation 
 solution.
 
 Is CPM driven off of CDR's or off of the SAS datastream or some other source?
 
 If its CDR driven you will be blind to this problem because you wont be 
 measuring calls that are rejected due to lack of capacity(no cdr cut).
 If its driven off of SAS data you will get the missed/incomplete call stats 
 but at the cost of speed (multiple orders of magnitude more data than CDR's)
 
 It would be interesting to hear if this perhaps uses a different datasource. 
 Perhaps there is a facility in perimeta that informs this better than CFS 
 data sources.
 
 -Ryan
 
 On 8/18/2014 3:36 PM, Simon Dredge wrote:
  I know many meta-users like the new-ish call pattern monitor. It uses 
  weighted profiling benchmarking algos similar to NBAD:
 
  http://www.metaswitch.com/sites/default/files/Metaswitch-Call-Pattern-
  Monitor.pdf
 
  Cheers,
 
 
  Simon.
 
 
  -Original Message-
  From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of
  Ryan Delgrosso
  Sent: Monday, August 18, 2014 1:53 PM
  To: ECG - Mark Lindsey
  Cc: voiceops@voiceops.org
  Subject: Re: [VoiceOps] Hackers Crash Clay Co. Phones ...
 
  I dunno that's a slippery slope. Im not a proponent of putting management 
  of your network services into someone elses hands, especially things like 
  this where the service provider should have visibility into what they are 
  or are not admitting.
 
  Agreed on your synopsis of call admission control, the border should be 
  able to make these decisions rapidly, freeing up softswitch resources to 
  actually serve customers.
 
  This sounds like good territory for an acme SPL plugin, possibly in
  conjunction with this enum extension
  http://tools.ietf.org/html/draft-kaplan-enum-source-uri-00 unfortunately i 
  dont see a clear path for this in the TDM world but my exposure there is 
  limited. It would seem like a good solution might be using ENUM (with 
  source URI) to build statistics centrally based on calling/called numbers 
  and then forcing the ENUM response once thresholds are hit to illicit an 
  appropriate decline message for flagged invites with a retry-after 
  interval allowing you to effectively throttle specific call scenarios 
  assuming your origination carriers will behave correctly.
 
  2 of the examples we discussed previously were:
 
  1: Social media death star. Justin biebers (or anyone else with millions 
  of rabid followers) twitter account  (53.7M followers) gets hacked and 
  attacker tweets Call this number for free tickets or similar.
 
  2: T-DOS using stolen sip accounts effectively turning other service 
  providers into a death star. More damage per source number (higher CPS 
  than social media per attacker but less distributed source). This one 
  seems much easier to create given the ease with which stolen sip accounts 
  can be acquired, and harder to mitigate if the stolen accounts support 
  callerID spoofing.
 
  Both of these situations are exacerbated by LCR resellers creating at 
  times 10-20 invites from 1 due to route advancing when the destination is 
  truly congested, which gets worse when the LCR resellers in turn have 
  resellers in route etc etc.
 
  Of course any solution needs to have provisions for conveying congestion 
  control to the originating network so they stop route advancing.
 
 
  I think this has commercial viability for access providers protecting
  their customers business interests and for implementers designing
  solutions but perhaps not so much in a carrier to carrier capacity
  (beyond appropriate support of signaling congestion control).
 
 
  On 8/18/2014 12:48 PM, Mark R Lindsey wrote:
  Ryan, does it seem as though TDoS will be most effectively addressed by 
  the origination companies?  i.e., the guys with the TDM