Re: [VoiceOps] recommendations for PRI/POTS/DATA CPE device with fiber handoff

[Paul Timmins]

The MX408e are nice boxes, but I'd never use them for anything other than 
pseudowire. I use them for customers who have ethernet (usually whatever hands 
off our ethernet handles the QoS) and need TDM T1 services. They don't support 
TACACS+, the GUI breaks randomly on anything but IE, and even then still 
doesn't always work.

But the DS1 PWE is rock solid.

-Paul

On Tue, 01/28/2014 03:53 PM, Matt Yaklin myak...@g4.net wrote:
 I was looking at a variation of your idea.
 
 http://adtran.com/web/page/portal/Adtran/product/1189608G1
 
 The MX408e.
 
 8 DS1 circuit emulated T1 interfaces
 4 10/100 ports
 1 SFP port for uplink to us.
 
 And can work in a p2p or point to multipoint configuration.
 NEBS complaint for CO installation.
 
 I have so many TA6xx boxes laying around it is pathetic so there
 are my POTS.
 
 It just seems QoS might be an issue as I would be relying on the
 box to prioritize the emulated T1s and I am unclear how well it
 does it. TA90Xe boxes I like and trust.
 
 Plus it is a lot more complicated and expensive. I would have to
 buy 3 to start. One for the CO, one for the customer, and a spare.
 My PRI would still be TDM based, the POTS would be TDM based from
 GR303, etc...
 
 Your idea is nicer. Especially if I do not have to buy new cards
 for a TA5000 or what not to get it working temp with a SFP like
 this?
 
 https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjaved=0CCkQFjAAurl=http%3A%2F%2Factive.elmat.pl%2Fpobierz%2F103ei=PBjoUvq8KMnesATVqIKQBQusg=AFQjCNH2qBc564HinryGMOa2FkThS79Cbgsig2=F8akfOEutOotlZa9pIvWGQbvm=bv.60157871,d.cWc
 
 m...@g4.net
 
 
 On Tue, 28 Jan 2014, Paul Timmins wrote:
 
  Here's an attempt to increase my SNR..
  
  http://www.adtran.com/web/page/portal/Adtran/group/3968
  
  The Total Access 372 provides eight (8) POTS, four (4) DS1 circuit emulated 
  T1 interfaces, dual (2) Gigabit Ethernet
  Optical Small Business Unit(SBU) ONT
  
  On Tue, 01/28/2014 03:33 PM, Paul Timmins  
  target=_blankp...@timmins.net wrote:
Err, GPON and ActiveE. Brain fart.
 
On Tue, 01/28/2014 03:33 PM, Paul Timmins  
  target=_blankp...@timmins.net wrote:
  There's a pretty sweet GPON/EPON ONT (forget the model number, 
  it's in the TA300 series) that has
  8 POTS, 2 GigE, and 2 DS1 Pseudowire. Tricky to configure, but 
  works awesome.
  
 
  On Tue, 01/28/2014 03:31 PM, Matt Yaklin  
  target=_blankmyak...@g4.net wrote:
All,
 
I was looking at Adtran's website at the TA90Xe boxes 
  because I swore
they made a model with a SFP port but I cannot seem to 
  find one. I am
waiting for my Adtran SE to call back so I thought I 
  would email the
list and see what everyone else is using in this 
  situation.
 
We run fiber directly to the customer premise. The 
  customer wants
a PRI, 6 POTS, and 10-20 Mb/s internet.
 
I want QoS on the upstream to be solid, I would prefer a 
  device which
can terminate the fiber directly, and run all the 
  services from the
same device.
 
If my memory was incorrect and the TA90Xe does not offer 
  a SFP port
should I just stick a media converter in front of it or 
  does anyone
else have some gear to recommend?
 
Thanks for any tips,
 
m...@g4.net
___
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] CNAM on toll free?

[Paul Timmins]

There's no place where the CNAM database pointcode can be stored in the 800SMS. 
Would be awesome if the industry got their act together on this.

On Fri, 02/14/2014 01:55 PM, Graham Freeman gfree...@sungevity.com wrote:
 Hi, folks,
 Can toll-free numbers have CNAM registrations?   We're hoping to have it say 
 something other than TOLL-FREE CALLER, but our vendor says that toll-free 
 CNAMs can't change.
 thanks,
 

 Graham freemangfree...@sungevity.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] Fraud

[Paul Timmins]

We do something similar in our environment. We have a per-tn blacklist that 
starts with all country codes except about 20 of them in it. If a customer 
calls to complain (I think one of them did this so far out of thousands), we 
remove a specific country from the list (or all of them).

Combined with a system that completely restricts international calling based on 
the customer's rolling 24 hour cost to us for international calls (we basically 
rate the calls every few minutes at the rates we're billed for them, and if you 
use over X amount at our cost over 24 hours, you get your international service 
shut off until we call you. The system sends a report to the account manager 
team and NOC and shuts them off instantly, and then the account managers work 
with the NOC to contact the customer offering technical assistance, and the 
account managers work with them on the financial side.

This strategy nearly eliminates losses on our side, because the account team 
knows what that traffic cost us, the NOC helps prevent the customer from 
further fraud by giving them advice or helping them, and the customer has to 
pay us maybe $100.

-Paul

On Tue, 02/25/2014 09:34 AM, My List Account myli...@battleop.com wrote:
 




I’m pretty sure it would ruffle some feathers around here if I sent that list 
out into the public domain.  I can tell you that we basically go thought the 
rate deck and filter anyone that’s above X amount per minute and then throw in 
countries where customer’s hacked PBX’s send calls to.  It’s not the most 
scientific method but it’s the most complaint free method.
 
Richey
 
From: John Curry [mailto:telec...@gmail.com] 
 Sent: Monday, February 24, 2014 4:21 PM
 To: 'My List Account'; voiceops@voiceops.org
 Subject: RE: [VoiceOps] Fraud
 
Would you mind sharing your hi toll rate destination dial plan?
 
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of My List 
Account
 Sent: Monday, February 24, 2014 1:48 PM
 To: voiceops@voiceops.org
 Subject: Re: [VoiceOps] Fraud
 
Maybe I am missing something here but why does the carrier that delivers the 
fraudulent traffic to the Telco that’s in on the fraud pay the Telco that’s in 
on the fraud for the calls that are delivered to their network?   Seems pretty 
simple, if you cut off their revenue stream they won’t have a reason to 
continue.   
 
I guess we all know there is no incentive for them to stop this practice 
because it’s a big cash cow for everyone except for the poor end user who is 
left holding the bag.
 
Our default dial plan won’t let you dial these destinations so we don’t have a 
real issue with this abusive traffic.   Most of our customers who use 
international go with one of our filtered dial plans that let them dial most of 
the world except for known fraudulent and high toll rate destinations.
 
 
Richey
 
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Ryan 
Delgrosso
 Sent: Saturday, February 22, 2014 11:48 AM
 To: voiceops@voiceops.org
 Subject: Re: [VoiceOps] Fraud
 
In most cases you will lose this customer. They don't see this as their 
responsibility (i.e. the credit card fraud defense) but the reality is their 
equipment was compromised due to their negligence. 
 
 If the customer is reasonable offer them your cost on the damages so its just 
 a passthrough. Otherwise you can take them to court or just send them to 
 collections. 
 
 BTW while many will advocate fraud detection and mitigation systems here, its 
 been my experience (we wrote our own fraud system that out-performs our 
 upstream carriers by hours) that if you detect fraud on a customer like this, 
 and shut it down in minutes, and mitigate what could have been thousands of 
 dollars in damage due to their mis-configured systems, reducing it to just 
 tens or hundreds they will often still fight that amount and deny 
 responsibility. The fraud system protects you, and by extension the customer, 
 but the customers don't see it that way. 
 
 -Ryan
On 02/19/2014 02:09 PM, John Curry wrote:
 I am new to your site. I was looking in the Archives and saw in November 2013 
 there were some of you who experienced fraud. We had a an Avaya IP Office 
 customers system who got hit pretty bad. The customer is treating the 
 fraudulent calls like credit card fraud and not taking any responsibility. 
 Does anyone have any advice on how to persuade the customer take this issue 
 seriously?  His bill was racked up pretty good.  Strangely and coincidentally 
 Avaya came out with a security bulletin the end of December 2013 on this same 
 issue.  I tried to contact Avaya with no response. It seems as though someone 
 has built a sniffer for the Avaya IP Offices and gleaning their registrations.
 
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
 

___
VoiceOps mailing list

Re: [VoiceOps] Linefeed in CNAM data?

[Paul Timmins]

6617480240 - 6617480993: NEUTRAL TANDEM-CALIFORNIA, LLC - CA CA (OCN: 649C) 
NPAC SPID (ONSP): 505B
6617480240 - SKYPE CALLER
That's what I get via TNSi, who uses the legacy Verisign SS7 based CNAM system.
I wonder if the SS7 provider providing that data uses TARGUSinfo. (Syniverse 
does, for example). They have this synthetic CNAM data that's really 
questionable sometimes.

-Paul

On Mar 19, 2014, at 9:12 PM, Nathan Anderson nath...@fsr.com wrote:

 Our CNAM lookup provider is sending us name data for one particular number 
 that includes a linefeed in it.  It's possible that it's their mistake and 
 that this particular number's CNAM data doesn't actually have this character 
 in it, but it raises the question: is this a legal character?
 
 The number in question is a SkypeOut gateway: 661-748-0240 -- I'd be curious 
 to know what other people are seeing on a CNAM lookup for this.  What we are 
 getting is SKYPE USER\nSKYPE USER.  And, actually, now that I think about 
 it, this can't possibly be the actual value since I believe CNAM is limited 
 to 15 characters.  So I'll talk to our provider about this.  (This is the 
 only number that we have seen anything like this with.)
 
 BTW, it turns out that when Asterisk sends an INVITE and the CALLERID(name) 
 value has been stuffed with a string that contains a newline, it decides to 
 send this in the headers:
 
 From: SKYPE USER\
 SKYPE USER sip:6617480240@192.0.2.1
 
 ...so it includes the linefeed (ASCII 10) in the string, but tries to escape 
 it with a '\' (which is not entirely unprecedented).  An Asterisk box on the 
 receiving end of that INVITE, however, will completely ignore the INVITE...it 
 won't log an error and doesn't bother dignifying it with a response, probably 
 because it sees that as two separate lines (it doesn't concatenate two lines 
 that are separated by a '\') and the second line all by itself looks like 
 garbage/wouldn't make sense to a SIP dialog parser.
 
 -- 
 Nathan Anderson
 First Step Internet, LLC
 nath...@fsr.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] New Exchange 217/777

[Paul Timmins]

What's worse really is not that you have to look at ILEC tandems out of 
area - they don't perform any route filtering, if the originating caller 
is calling out of area, it gets sent to their PIC/LPIC LD carrier.


So what you really need is every IXC in the country to make sure they 
have a route to you either directly, through whatever tandem homing 
arrangements you have, or via another IXC (really common especially in 
rural areas to see a Level 3/Global Crossing hand off to 
Qwest/ATT/Verizon for the final termination.).


-Paul

On 07/15/2014 10:52 AM, Adam Vocks wrote:

So, at the very least, I need to start looking at each of the ILEC's
tandems in a specific LATA?

Adam

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Alex
Balashov
Sent: Tuesday, July 15, 2014 9:48 AM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] New Exchange 217/777

On 07/15/2014 10:44 AM, Adam Vocks wrote:


:-)

Take Kidd's call from Verizon in Colorado.  If there isn't our
exchange in their local switch, do they forward the call on to another
switch in hopes that it will know where to send it?  Similar to a
default gateway in IP world?

It would get kicked up to an ILEC tandem inside that LATA. There is
really no default gateway beyond that; at that point, you've already
exited into what the IP world would call default route-free or Tier
1 routing space.

--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

Please be kind to the English language:

http://www.entrepreneur.com/article/232906
___
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] New Exchange 217/777

[Paul Timmins]

Level 3 is a big wholesale route for a lot of smaller IXC carriers and 
VoIP providers, so when they fix it, you'll probably see immense 
improvement.


On 07/15/2014 02:10 PM, Adam Vocks wrote:

I'm really hoping Level3 is having a routing issue with our code.  Some
tried a call on level3 to us which failed.  Odd things is that Level3 is
directly connected to the Tandem we subtend.  I wouldn't think Level3
would send it off their network???

Adam

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Paul
Timmins
Sent: Tuesday, July 15, 2014 12:30 PM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] New Exchange 217/777

What's worse really is not that you have to look at ILEC tandems out of
area - they don't perform any route filtering, if the originating caller
is calling out of area, it gets sent to their PIC/LPIC LD carrier.

So what you really need is every IXC in the country to make sure they
have a route to you either directly, through whatever tandem homing
arrangements you have, or via another IXC (really common especially in
rural areas to see a Level 3/Global Crossing hand off to
Qwest/ATT/Verizon for the final termination.).

-Paul

On 07/15/2014 10:52 AM, Adam Vocks wrote:

So, at the very least, I need to start looking at each of the ILEC's
tandems in a specific LATA?

Adam

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of
Alex Balashov
Sent: Tuesday, July 15, 2014 9:48 AM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] New Exchange 217/777

On 07/15/2014 10:44 AM, Adam Vocks wrote:


:-)

Take Kidd's call from Verizon in Colorado.  If there isn't our
exchange in their local switch, do they forward the call on to
another switch in hopes that it will know where to send it?  Similar
to a default gateway in IP world?

It would get kicked up to an ILEC tandem inside that LATA. There is
really no default gateway beyond that; at that point, you've already
exited into what the IP world would call default route-free or Tier
1 routing space.

--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

Please be kind to the English language:

http://www.entrepreneur.com/article/232906
___
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] New Exchange 217/777

[Paul Timmins]

Level 3 is a big wholesale route for a lot of smaller IXC carriers and 
VoIP providers, so when they fix it, you'll probably see immense 
improvement.


On 07/15/2014 02:10 PM, Adam Vocks wrote:

I'm really hoping Level3 is having a routing issue with our code.  Some
tried a call on level3 to us which failed.  Odd things is that Level3 is
directly connected to the Tandem we subtend.  I wouldn't think Level3
would send it off their network???

Adam

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Paul
Timmins
Sent: Tuesday, July 15, 2014 12:30 PM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] New Exchange 217/777

What's worse really is not that you have to look at ILEC tandems out of
area - they don't perform any route filtering, if the originating caller
is calling out of area, it gets sent to their PIC/LPIC LD carrier.

So what you really need is every IXC in the country to make sure they
have a route to you either directly, through whatever tandem homing
arrangements you have, or via another IXC (really common especially in
rural areas to see a Level 3/Global Crossing hand off to
Qwest/ATT/Verizon for the final termination.).

-Paul

On 07/15/2014 10:52 AM, Adam Vocks wrote:

So, at the very least, I need to start looking at each of the ILEC's
tandems in a specific LATA?

Adam

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of
Alex Balashov
Sent: Tuesday, July 15, 2014 9:48 AM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] New Exchange 217/777

On 07/15/2014 10:44 AM, Adam Vocks wrote:


:-)

Take Kidd's call from Verizon in Colorado.  If there isn't our
exchange in their local switch, do they forward the call on to
another switch in hopes that it will know where to send it?  Similar
to a default gateway in IP world?

It would get kicked up to an ILEC tandem inside that LATA. There is
really no default gateway beyond that; at that point, you've already
exited into what the IP world would call default route-free or Tier
1 routing space.

--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

Please be kind to the English language:

http://www.entrepreneur.com/article/232906
___
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 over 3G/4G Data Connection

[Paul Timmins]

On the other hand, if you can get SIP/TLS over TCP going, do in fact do that. 
You'll work around a lot of NAT and ALG issues because the ALGs can't see the 
traffic. Most of them don't even look at 5060/tcp as well, so TCP is often 
enough.

TCP is good for being behind multiple layers of NAT (your cradlepoint being 
one, and the carrier being the other) because NAT devices treat TCP better 
because they know whether a session is still up or not (UDP is stateless, so 
you often have to keep your registration timers very low in order to make 
things work right consistently).

I've had good luck with G722 but if you're not sure you'll always have 4g, I've 
had much better luck with iLBC over 3G than any other protocol. It's not widely 
supported but my 3g/4g experience has mostly been with xlite on an ipad 3G or 
an android handset to asterisk, both of which support it. (as well as TCP, TLS 
and SRTP)

-Paul

On Fri, 07/25/2014 12:41 PM, Jared Geiger ja...@compuwizz.net wrote:
 I would suggest getting a static IP from the carrier. The Carrier Grade NAT 
 that US mobile providers use could make stationary phones lose registration 
 without it. On LTE, you'll be fine with almost any codec that you want. I 
 typically use ulaw and g722 over 4G LTE with no problems. If you are doing it 
 over a 3G connection, stick with g729.

 TCP isn't mandatory, I use UDP signaling and don't have issues on T-Mobile, 
 Sprint, or Verizon LTE. I have not tried ATT LTE and VoIP. I would suggest 
 talking with the carrier you chose to see what their session timeout value 
 is. You'll want to set your registration time lower than this to keep the 
 Internet session up. You may be able to even set the session refresh rate in 
 the cradlepoint itself. I have not used them though.

 Good luck and report back!
 ~Jared
 
 On Thu, Jul 24, 2014 at 7:54 PM, Colton Conor colton.co...@gmail.com wrote:
 
 What are the recommended settings to successfully implement VoIP over 3G/4G
data connection? Assume we are talking about using Polycom phones, and the
3G/4G data connection comes from a Cradlepoint router that is plugged in
with AC power and has high gain antennas. The device will be stationary, so
we will not have to worry about tower handoffs breaking the connection.
This will be for fixed wireless aiming at a cell tower. I assume packet loss 
will be a big concern as we have no control or QoS abilities. Plus, the speed 
fluctuates so much. 

I have read to use G.729 codec, and TCP for signaling to bypass firewalls.
Besides that, what other settings are recommended?  Changes in MTU? Changes
in voice payload ms? Is there a better codec to use? Header compression?


 ___
 
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] Multi Tenant Commercial Softswitch Besides Broadsoft

[Paul Timmins]

Our asterisk system is peaking at over 800 standing calls without 
breaking a sweat.



On 08/07/2014 11:01 AM, Peter Rad. wrote:


From what I have been told, Asterisk can handle 300 simultaneous calls 
per user. Most ITSPs wouldn't know because they aren't seeing that 
kind of volume.


Cbeyond bought a company called Aretta that did Asterisk in containers 
- one for each customer. It became unmanageable.


Just some thoughts this morning.

Peter




___
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] HD voice?

[Paul Timmins]

If anyone has contacts with cell providers that are interested in testing out 
HD Voice interop (or hell anyone, especially if they're interconnected with 
inteliquent) I'm very much in favor of playing with it with other providers and 
see what we can get going.


 On Oct 30, 2014, at 20:48, Graham Freeman gfree...@sungevity.com wrote:
 
 Any SIP providers offering HD voice interop with cell phone providers?
 
 Graham Freeman // Security and Network Architect
 +1-415-506-9350 UTC-0700
 gfree...@sungevity.com mailto:gfree...@sungevity.com
 Sungevity // Generate Positive // 66 Franklin Street, Oakland, CA 94607 USA
 ___
 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] SIP HD Peering with Wireless Carriers

[Paul Timmins]

If this is happening I want in. I know Intelliquent allows G722 
interconnect, is anyone actually using it and want to play with it with us?


On 02/13/2015 09:11 AM, Colton Conor wrote:
As you know most all the wireless cellular carriers are deploying HD 
voice with VoLTE. Most of these carriers, like Verizon Wireless, have 
a wholesale wireline division that sells wholesale SIP minutes. Are 
these carriers going to enable HD G722 SIP peering to their wireless 
counterparts networks?


That way an office worker, talking on a HD capable handset, like a 
Polycom, could talk in HD to a wireless cell phone user with a HD 
capable VoLTE smartphone. What is needed to make this happen? Are any 
of the big 4 carriers already doing this?



___
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] IXC/LD No audio or delayed audio

[Paul Timmins]

NT/Inteliquent has always been awesome in helping narrow this down. If 
you haven't called them for fear of wasting their time, I strongly 
suggest it. ATT is next to useless on FGD trunking no matter who you 
talk to. I usually can't even get them to tell me which carrier is 
attempting to terminate a call on me, pleading CPNI regulations.


-Paul

On 04/23/2015 10:17 AM, Starr, Steve wrote:
A growing number of IXC/LD calls inbound into us have either no audio 
or delayed audio.  We are attempting to narrow down the common 
carrier, but this is a difficult task. We have IXC trunks with 
multiple providers.  So far it seems to be mostly our ATT trunks and 
Neutral Tandem trunks.  ATT being TDM and Neutral Tandem being VoIP.  
This leads me to believe it is an IXC carrier causing the trouble and 
not circuit trouble. Also, it is just inbound.  When our customer 
returns the call it is fine.  If the person calls our customers 
tollfree it completes fine.


Is anyone else experiencing the trouble?
Does anyone have any contacts at ATT that might be able to assist?

Thank you,


:: Steve Starr
:: Daystarr Communications
:: steve.st...@daystarrfiber.net mailto:steve.st...@daystarrfiber.net
:: v - 989.720.6000
:: 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

Re: [VoiceOps] Wholesale Orig Provider with Low DID MRC and LNP Fees

[Paul Timmins]

On 06/18/2015 01:59 PM, Alex Balashov wrote:

On 06/18/2015 01:47 PM, Colton Conor wrote:


What nationwide providers offers DID's at a true wholesale rate?


What is a true wholesale rate? Isn't that a bit like asking, Which 
major stores offer Old Spice at a true retail rate? (i.e. a retail 
rate I'd like to pay)


Seems straightforward enough of a term for me. Telephone numbers 
themselves don't have an actual cost, and in fact generate revenue for 
the LEC. Places that charge for example $10 a number are not wholesale 
rates. Places that cover a reasonable cost for LNP fees, cost recovery 
for maintenance/carrying cost/billing, a reasonable profit and expect 
you to know what you're doing. A true wholesale rate would be something 
you could make a reasonable profit with selling retail services to end 
users with.


http://www.businessdictionary.com/definition/wholesale-price.html

The cost http://www.businessdictionary.com/definition/cost.html of a 
good sold by a wholesaler 
http://www.businessdictionary.com/definition/wholesaler.html. The 
wholesaler will usually charge 
http://www.businessdictionary.com/definition/charge.html a price 
http://www.businessdictionary.com/definition/labor-rate-price-variance.html 
somewhat higher than he or she paid to the producer 
http://www.businessdictionary.com/definition/producer.html, and the 
retailer http://www.businessdictionary.com/definition/retailer.html 
who purchases 
http://www.businessdictionary.com/definition/purchase.html the goods 
http://www.businessdictionary.com/definition/goods.html from the 
wholesaler will increase the price again when they sell 
http://www.businessdictionary.com/definition/sell.html the good in 
their store http://www.businessdictionary.com/definition/store.html.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] ATT Cellular - DTMF

[Paul Timmins]

ATT doesn't (reliably) pass two way audio until the call supervises. I had a 
customer with this issue before and they were sending a proceeding (technically 
a 183 with SDP because they were SIP) and playing a menu recording, and not 
sending the supervisory message (in their case a 200 ok) until they pressed a 
key. This worked with every cell phone except ATT (and of course that was my 
fault). I set my system to answer calls via a feature server then ring it into 
them, and that fixed it, and then I called their vendor to the mat for doing 
things that way. They fixed it and the issue was resolved.

-Paul

On Wed, 06/24/2015 12:57 PM, Adam Vocks adam.vo...@cticomputers.com wrote:
 




I’ve got an odd problem that someone might be able to point me in the right 
direction to get some help.
 
ATT cellular customer calls a number destined to our LRN.  Customer presses a 
digit on the phone, no DTMF audio ever comes across the trunk.  If that same 
customer calls a number with the same npa/nxx not destined for our LRN, DTMF 
audio comes across the trunk.  These calls are coming to us via SS7 trunks and 
the ILEC that these calls transit through has verified that both calls come in 
on the same trunks, one has DTMF audio, one does not.
 
This problem started on Thursday morning.  Prior to Thursday morning, ATT 
cellular calls were arriving to us via our FGD Tandem connection, now they are 
arriving via the local rate center switch.
 
I’ve talked to ATT and attempted to put in a ticket on the DS3 that enters the 
ILEC, but they refused to do that because they said the DTMF would be audio and 
they would just pass it through.
 
Anyone have advice?
 
ATT (low level tech) states that the DTMF tones are generated at the phone and 
are in the audio stream the entire way.  Does anyone know if ATT uses some 
sort out of band dtmf signaling?
 
Thanks!
 
Adam Vocks
CTI Fiber 

___
 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] Preventing calls to cell phones with guaranteed accuracy

[Paul Timmins]

I know a guy who runs a site that sells the npa nxx to carrier type at a 
fraction of the lerg costs

On Aug 19, 2015 11:39 AM, Alex Balashov abalas...@evaristesys.com wrote:

 ‎Indeed, you'd start from the NPAC, which would get you, for a given TN, an 
 LRN. Then what?
 ‎
 --
 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/

 Sent from my BlackBerry.
   Original Message  
 From: Kidd Filby
 Sent: Wednesday, August 19, 2015 10:52
 To: Carlos Alvarez
 Cc: voiceops@voiceops.org
 Subject: Re: [VoiceOps] Preventing calls to cell phones with guaranteed 
 accuracy

 If I were to offer this service or database access, I would start with my own 
 local copy of NPAC that I'd update every X-minutes a day.  This product is 
 available now and has been for a while.  This is the only sure-way, I know 
 of, to have the most accurate data to work from.

 Kidd

 On Tue, Aug 18, 2015 at 2:30 PM, Carlos Alvarez caalva...@gmail.com wrote:
 I have a customer in market research who is legally required to manually dial 
 calls to cell phones.  Right now they are considering abandoning all of their 
 auto/predictive dialer software and going to manual dial for everything, 
 because the list-scrubbing services have been shown to be inaccurate.  There 
 are extreme penalties for auto-dialing a cell phone, and best effort is NOT 
 a defense to this, at all.  For example, Gallup just settle a claim for $12M.

 So they need a totally accurate way to prevent a cell phone call from 
 originating from their dialer.  The only thing I can think of is some sort of 
 LRN dip + LRN-to-carrier-type response.  One of their people talked to 
 Neustar, but didn't get great answers because he doesn't really understand 
 telephony.  Before I get in touch with Neustar, I thought I'd see if people 
 here have some ideas.

 If you provide a commercial product for this, please feel free to tell me so 
 on or off list, the customer is willing to pay for the service and we're open 
 to all options.  I don't have a budget number yet but manual dialing is going 
 to cost them quite a bit for some types of studies.

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


 -- 
 Kidd Filby
 661.557.5640 (C)
 http://www.linkedin.com/in/kiddfilby

 ___
 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] ADT Alarms Special Dialing?

[Paul Timmins]

TA5k only speaks DTMF inband VDSL2 and ADSL2+ combo cards. It's not a 
changeable setting.

-Paul

 On Aug 6, 2015, at 21:55, Colton Conor colton.co...@gmail.com wrote:
 
 Wow thanks to all this has been a huge help! So we are using a Broadsoft for 
 the voice switch connected by SIP to an Adtran Total Access 5000 that has 
 VDSL2 Combo cards. So I assume we would need to change the DTMF settings on 
 the Adtran. Have any recommendations on what to look for to make this work 
 with ADT alarm lines if its truly a DMT issue.
 
 I don't like the idea of changing setting on the actual alarm. I prefer to 
 get the POTS working right so it works regardless of the alarms settings. 
 
 On Thu, Aug 6, 2015 at 7:03 PM, Nathan Anderson nath...@fsr.com 
 mailto:nath...@fsr.com wrote:
 I doubt it.  We are an ISP and ITSP doing voice exclusively 100% over IP.  We 
 have historically actively discouraged hooking up an alarm system to our 
 service and relying on that (in order to avoid support headaches, liability 
 issues, etc.), but we ourselves have an ADT system that was previously hooked 
 up to local ILEC POTS service and that we moved over to an ATA of ours as an 
 experiment.
 
 It actually works just fine now, but it didn't initially.  Turns out that the 
 default modulation technique used between the panel and the monitoring 
 center is...DTMF.  Really.  It appeared that either the monitoring center or 
 the panel (or both) did not like something about how either the ATA or the 
 terminating provider was regenerating the DTMF tones from the OOB info.  Not 
 sure if it was a timing issue or what.  I am pretty sure I did try forcing 
 DTMF to not be decoded/re-encoded and just remain inband, but that didn't 
 seem to work for whatever reason (can't remember the details; it's been a 
 while since this all transpired).
 
 Eventually, I managed to track down an installer's manual for the particular 
 model of panel we have, and was able to reprogram it to use a form of FSK 
 modulation to talk to the monitoring center instead.  It's super low bitrate 
 (300 baud IIRC), and works 100% perfectly over G.711 PCM.  (I know this 
 because after I made the change, I accidentally managed to set the alarm off, 
 and ADT called my boss, etc.; that was fun...)  We have been using the panel 
 this way for months, plugged into a VoIP ATA.
 
 The panel dials an 800 number periodically to check in, and also when the 
 alarm is tripped.  If it cannot complete a check-in successfully, a light on 
 the panel will be illuminated.  That LED has not come on since the modulation 
 switch.  If they were doing LRN lookups, we would fail that test as well 
 since none of our sources for DIDs are on ADT's approved list, either.  I 
 am sure I can get you the number that ours dials if you care to have it, but 
 I have no way of knowing if they use the same number in all geographies or 
 across all product lines (ours is an office/business system that I'm pretty 
 sure doesn't get used in residential installs; for all I know, it may call a 
 different monitoring center than the residential product(s) do).
 
 Hope this helps at least give you some more ideas,
 
 --
 Nathan Anderson
 First Step Internet, LLC
 nath...@fsr.com mailto:nath...@fsr.com
 
 -Original Message-
 From: VoiceOps [mailto:voiceops-boun...@voiceops.org 
 mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton Conor
 Sent: Thursday, August 06, 2015 4:30 PM
 To: voiceops@voiceops.org mailto:voiceops@voiceops.org
 Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
 
 I did find this page http://www.adt.com/customer-service/voip-faqs 
 http://www.adt.com/customer-service/voip-faqs Seems that your phone company 
 has to be:
 
 A Qualified “Managed Facility Voice Network (MFVN)”includes the following:
 1. Has a physical facilities network which is managed and maintained 
 (directly or indirectly) by the service provider. Can ensure service quality 
 from the service subscriber location to the PSTN or other MFVN peer network.
 2. Utilizes similar signaling and related protocols as the PSTN with respect 
 to dialing, dial plan, call completion, carriage of alarm signals and 
 protocols, and loop voltage treatment.
 3. Provides real-time transmission of voice signals, carrying alarm formats 
 unchanged.
 4. Provides professional installation that preserves primary line seizure for 
 alarm signal transmission.
 5. Has major and minor disaster recovery plans to address both individual 
 customer outages and widespread events such as tornados, ice storms and other 
 natural disasters. This includes specific network power restoration 
 procedures that are comparable to those of traditional landline telephone 
 services in the same geographic region.
 6. Has informed ADT that its network meets the characteristics of a MFVN.
 Still how are they controlling this? Think ADT is smart enough to do a LRN 
 lookup on a number, and see its not one from their qualified list?
 
 

Re: [VoiceOps] ADT Alarms Special Dialing?

[Paul Timmins]

The liability of a common carrier is typically limited to the amount 
paid for their services. I can't sue FedEx for a million dollars because 
they delivered a million dollar contract a day late and caused me to 
lose the deal. We'd all be bankrupt if someone dialed 911 during a phone 
outage and we were liable for it.


IANAL but if telephone companies and ISPs were liable for damages for 
their services not working, they'd all be bankrupt after every natural 
disaster that takes out the phone lines, for making phone lines capable 
of being sabotaged by invaders prior to breaking in, and numerous other 
things. Analog CO lines get screwed up all the time. At least twice a 
year my analog line has an issue that my home's alarm system doesn't 
like, and takes at least 2-3 days to fix (even though I work at the CLEC 
and can directly open the ticket with the underlying carrier). ATT 
isn't liable to me if my home gets broken into during that time, and my 
employer is liable for nothing more than perhaps a service credit for 
the 2 days I was without service.


-Paul

On 08/07/2015 02:41 PM, David Thompson wrote:


Alarm systems being serviced over VoIP are generally speaking a very 
bad idea. What are you supposed to do when and if the power fails? A 
UPS is only going to last for so long hours maybe. An analog CO line 
gets power from the wire and won’t go offline in the event of a 
natural or manmade disaster. The CO usually has a generator and 
guaranteed fuel delivery. By bringing VoIP into the mix your opening 
yourself up a huge liability if the alarm system fails due to your 
failure and someone gets burglarized, robbed, and worse injured or 
killed you’ll most likely be on the hook. Do yourself a favor and stay 
away from supporting it.


David Thompson
Network Services Support Technician
(O) 858.357.8794
(F) 858-225-1882
(E) dthomp...@esi-estech.com mailto:dthomp...@esi-estech.com
(W) www.esi-estech.com http://www.esi-estech.com

*From:*VoiceOps [mailto:voiceops-boun...@voiceops.org 
mailto:voiceops-boun...@voiceops.org] *On Behalf Of *Colton Conor

*Sent:* Thursday, August 06, 2015 6:21 PM
*To:* voiceops@voiceops.org mailto:voiceops@voiceops.org
*Subject:* [VoiceOps] ADT Alarms Special Dialing?

We are a CLEC and have a had a couple of customers port away from 
Verizon's landline service and to our voice service where we provided 
an analog POTS line with the same number just as the client had before 
with Verizon. We hook the POTS line up to the exact same wire going to 
the client's alarm panel, but the alarm can't communicate with ADT.


We called ADT on multiple clients behalfs, and they basically said 
Verizon is on an approved list to work with their services and our 
CLEC is not, so it would not work.


How is ADT limiting this? Does their alarm panels dial a special 
number that only Verizon knows or allows? This has happened with 
multiple clients.


We have not been able to get on the voice switch and see what numbers 
they panel is actually trying to dial, but any insight to this would 
be helpful.


I have read that some alarm companies uses a special code before they 
make an outbound call so the long distance gets billed to them or 
something?




___
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] ADT Alarms Special Dialing?

[Paul Timmins]

On 08/10/2015 06:36 PM, Colton Conor wrote:

Paul,

So is this just a limitation of Adtran's implementation of SIP on the 
5000, or are all MSAN's from Vendors like Calix, Zhone, and ALU the 
same way?




Specific to the 5k. We have some older Zhone equipment that does T.38 
and RFC-2833 and mid call re-invites just fine. It crashes the web 
interface hard when we try an MLT, but such is life.


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

Re: [VoiceOps] Disconnected numbers and SIP

[Paul Timmins]

If this was true, why does ISUP 1 map to 404 by standard?

On Oct 21, 2015 2:13 PM, Brooks Bridges  wrote:
>
> "6xx codes are supposed to be used to indicate definitive knowledge that a 
> number can't be reached by any other means globally." 
>
> Yet vendors build hardware that still route advances on a 6XX... (yes, I'm 
> looking at you, Sonus)  *grumble* 
>
> 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 
>
> -Original Message- 
> From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Alex 
> Balashov 
> Sent: Wednesday, October 21, 2015 11:04 AM 
> To: Peter E 
> Cc: VoiceOps 
> Subject: Re: [VoiceOps] Disconnected numbers and SIP 
>
> I see 404 fairly commonly used to indicate "I don't have a route for this". 
> 6xx codes are supposed to be used to indicate definitive knowledge that a 
> number can't be reached by any other means globally. 
>
> -- 
> 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/ 
>
> 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 
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Disconnected numbers and SIP

[Paul Timmins]

I would consider anything but 404 (at least as long as the terminating LEC send 
a cause code 1 properly) a glaring bug that I would demand a fix for until I 
received one, but I have different standards than most (many?) folk it seems.

But I have zero tolerance for exotica on my TDM or SIP terminations.

> On Oct 20, 2015, at 22:48, Alex Balashov  wrote:
> 
> ‎Thanks. And I'm guessing the best one can hope for from a SIP termination 
> provider is an ambiguous 404, or, more likely, a 503, which seems to have 
> become misused an opaque, catch-all epithet for any and all completion 
> failures?
> 
> --
> 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/
> 
> Sent from my BlackBerry.
> 

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

Re: [VoiceOps] Preventing calls to cell phones with guaranteed accuracy

[Paul Timmins]

 On Aug 25, 2015, at 23:49, John Levine jo...@taugh.com wrote:
 
 most landline carriers won't port it to a landline if it's out of
 ratecenter.
 
 I thought ports were only possible within a rate centre, and so by 
 definition impossible to port to a carrier which doesn't operate in that 
 rate centre?
 
 It is my impression that ports are technically possible anywhere
 within a LATA, but for business reasons most telcos won't port between
 rate centers.
 
 They're definitely not possible across the country because long
 distance calls only do the LNP lookup after routing the call to
 the destination tandem.  (That's the L in LNP.)

Your impression is correct. My commentary regarding cross-national number 
access on a POTS line was based on the idea i'd be trucking it across my 
network from a tandem in California in that example across my network to 
detroit, and dropping it on your doorstep, but yes, LATA. And the business 
reason has to do with local calling areas if you're not on an unlimited plan, 
as well as intercarrier compensation even if you are.

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

Re: [VoiceOps] Preventing calls to cell phones with guaranteed accuracy

[Paul Timmins]

On 08/25/2015 05:52 PM, Alex Balashov wrote:

On 08/25/2015 04:41 PM, Paul Timmins wrote:


most landline carriers won't port it to a landline if it's out of
ratecenter.


I thought ports were only possible within a rate centre, and so by 
definition impossible to port to a carrier which doesn't operate in 
that rate centre?




That's what the rules say, yes. The language seems clear but these days 
really isn't.


The technology itself lets you basically port anything in the LATA 
you're in as long as your LRN is well connected. operating in the 
ratecenter can get pretty nebulous when you're talking about things 
like hosted PBX, remote call forwards, VoIP ATAs, remote office things 
like google voice, etc.


Nothing technically stops me from providing you a POTS line here in 
Detroit with a Los Angeles phone number, in and out. I could load a 
detroit 911 address and even not have to worry that you'll die if 
something untoward happens here. And it could all be as baseband voice 
on that twin copper wire coming into your house (and I could put bonded 
VDSL2/ADSL2+ on that if you wanted, too, depending on the wirecenter and 
distance!). For me, it's just keystrokes at my desk. And depending on 
what and how you and I contract, there's nothing at all illegal or even 
unethical about it. Heck, foreign exchange lines are a tariffed product 
still in many states!


What i cannot do for sure is have you request service from me, give you 
a number 3 towns over and not have you aware of that, and then laugh as 
you try to take that to ATT POTS and watch them tell you in a 
bewildered tone that you can't keep that number and how do you have that 
anyway.


(This language applies mostly to Michigan as we've mostly deregulated 
our entire telecom industry here, to the consumer's detriment)


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

Re: [VoiceOps] ADT Alarms Special Dialing?

[Paul Timmins]

Especially curious if that Broadsoft by chance is hooking to a Taqua T7000 
running RFC2833 DTMF.

I know of some bugs if so.

-Paul


 On Aug 27, 2015, at 00:22, Nathan Anderson nath...@fsr.com wrote:
 
 Wait, weren't we talking about turning *off* both OOB DTMF (RFC2833) as well 
 as T.38, because both protocol could potentially mess with either of the 
 modulation schemes (DTMF and FSK, respecitvely) that ADT might use?
  
 If the Adtran 5000 does everything inband and you are doing PCM/uLaw audio 
 end-to-end, it seems to me that looking to your MSAN for potential problems 
 is a red herring.  You said the TA5K is getting fed by a Broadsoft switch.  
 How does the Broadsoft tie into the PSTN?  If it's SIP trunks all the way 
 down, how do you know that the Broadsoft (or even something upstream of 
 it…whatever sits between it and something TDM) isn't trying to be clever and 
 decode the in-band DTMF it gets from the TA5K and re-encode them as RFC2833 
 signals before passing them on?
  
 --
 Nathan Anderson
 First Step Internet, LLC
 nath...@fsr.com mailto:nath...@fsr.com
  
 From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Colton 
 Conor
 Sent: Wednesday, August 26, 2015 7:27 PM
 To: Paul Timmins
 Cc: voiceops@voiceops.org
 Subject: Re: [VoiceOps] ADT Alarms Special Dialing?
  
 Know anything about other vendors besides Adtran and Zhone? What about Calix 
 and ALU? Do their POTs/Combo cards support T.38 and RFC-2833? 
  
 On Mon, Aug 10, 2015 at 6:21 PM, Paul Timmins p...@timmins.net 
 mailto:p...@timmins.net wrote:
 On 08/10/2015 06:36 PM, Colton Conor wrote:
 Paul,
 
 So is this just a limitation of Adtran's implementation of SIP on the 5000, 
 or are all MSAN's from Vendors like Calix, Zhone, and ALU the same way?
 
 
 Specific to the 5k. We have some older Zhone equipment that does T.38 and 
 RFC-2833 and mid call re-invites just fine. It crashes the web interface hard 
 when we try an MLT, but such is life.
 
 -Paul
  
 ___
 VoiceOps mailing list
 VoiceOps@voiceops.org mailto:VoiceOps@voiceops.org
 https://puck.nether.net/mailman/listinfo/voiceops 
 https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] WiFi SIP phones recommendations

[Paul Timmins]

On 09/08/2015 03:43 PM, Alex Balashov wrote:

On 09/08/2015 03:35 PM, Carlos Alvarez wrote:


Every Wifi phone I've tried will roam just fine between APs assuming the
APs are properly configured.


Really? Can this take place seamlessly mid-call? With DHCP? What about 
DHCP lease acquisition delay?


Would such a configuration involve merely bridging all the APs onto 
the same LAN segment so that the same DHCP server feeds them? If so, 
where's the guarantee that the DHCP server will lease out the same IP 
address to the client?


Or is this really a static IP + WAP association-only undertaking?


Why would your client mess with DHCP on roaming? Mine at home never do. 
I roam between 3 of them several times a day, a proper handoff on both 
sides means i don't even realize it happening, let alone re-associate 
with DHCP and all that jazz - it happens at the MAC layer and isn't 
visible to the OS unless it asks the current station BSSID and decides 
to do something about it. "APs properly configured" comes into play here 
heavily.

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

Re: [VoiceOps] WiFi SIP phones recommendations

[Paul Timmins]

On 09/08/2015 03:58 PM, Alex Balashov wrote:
In principle, yes, but I've never seen an OS network management 
infrastructure which eliminates this bureaucracy when switching APs or 
does this seamlessly.


For example, as far as I know, neither my Ubuntu laptop nor my Android 
phone will automatically switch APs with the same ESSID. They'll hang 
onto the old AP for as long as possible, then drop it and reassociate, 
with DHCP jazz and all. However, I would think that putting the client 
on a static IP would largely obviate this.


Have I just missed a subtle shift in implementation over the last few 
years? I don't have two APs handy. Or are WiFi SIP phones specifically 
designed to work as you describe
I'm using Meraki MR16 and MR12 throughout my house. It will request 
clients reallocate themselves to access points as needed to balance out 
traffic, if you want. None of this stuff including my Macbook Pro, my 
Nexus 6, my iPad 2 3G, or my HP Windows 10 tablet hybrid thingy seem to 
have any trouble, or even knowledge of which one they're on. I've 
rebooted the main one and it's invisible to me, as the clients get 
shoved to the next wired AP they can reach instead, then it goes down 
for reboot.


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

Re: [VoiceOps] Preventing calls to cell phones with guaranteed accuracy

[Paul Timmins]

On 08/25/2015 04:29 PM, Alex Balashov wrote:

On 08/25/2015 04:24 PM, Paul Timmins wrote:


taking the obvious cell phone blocks out first saves you time and
money.


Curious, how does that deal with a scenario in which there was an 
intermodal port wireless - fixed-line? Or does this just not tend to 
happen to any non-negligible degree?


If so, I wonder if that may change with the advent of MVNOs whose back 
side is a VoIP-oriented CLEC + the regulatory movement toward non-LEC 
ITSPs owning their own number resources Is it reasonable to expect 
that all mobile numbers operated by some sort of enhanced wireless 
provider (e.g. a boutique MVNO) will be homed to the big networks' 
number blocks which return a wireless affiliation?


Most marketers don't care. It happens, but very very rarely - the cost 
benefits of pre-scrubbing a few million numbers this way tends to 
outweigh the occasional sale they'll get hitting one of these (remember, 
the call to conversion ratio is typically amazingly low to begin with). 
If things do move back to landline, it's usually stuff that started that 
way. Many people have wireless numbers not in their home ratecenter 
(because wireless carriers do things by MSA and never really had to 
care) and most landline carriers won't port it to a landline if it's out 
of ratecenter.


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

Re: [VoiceOps] Preventing calls to cell phones with guaranteed accuracy

[Paul Timmins]

On 08/25/2015 04:22 PM, Alex Balashov wrote:
That's exactly right. There's no way to clean up a list by NPA-NXX. 
You need to know where the call is going to go, which cannot be 
determined from the number itself[1]. So, you still need to do an LNP 
lookup to know which prefix the number is genuinely' affiliated with.


[1] Except for nonportable blocks/areas.

As I explain to my customers, you can absolutely use my data to do the 
initial scrub. LNP dips tend to cost money per dip, so taking the 
obvious cell phone blocks out first saves you time and money. But you 
MUST do the next step and scrub them after dipping too.


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

Re: [VoiceOps] Preventing calls to cell phones with guaranteed accuracy

[Paul Timmins]

Right. All these products are doing is doing the NPA-NXX lookup AFTER 
the LNP lookup. The NPA-NXX of the LRN is the carrier of record. If it's 
a cell phone company NPA/NXX you're dealing with a cellphone.


-Paul

On 08/19/2015 07:25 PM, Carlos Alvarez wrote:
Their lists are already cleaned by NPA-NXX, it's just not sufficient 
any more because of LNP.  Looks like the TCPA compliance product from 
Neustar, which someone else posted yesterday, is the best solution.  
Pretty cheap too.  It's just indicates intermodal porting of a number 
with no other info.



On Wed, Aug 19, 2015 at 12:40 PM Paul Timmins p...@timmins.net 
mailto:p...@timmins.net wrote:


I know a guy who runs a site that sells the npa nxx to carrier
type at a fraction of the lerg costs

On Aug 19, 2015 11:39 AM, Alex Balashov abalas...@evaristesys.com
mailto:abalas...@evaristesys.com wrote:

 ‎Indeed, you'd start from the NPAC, which would get you, for a
given TN, an LRN. Then what?
 ‎
 --
 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/

 Sent from my BlackBerry.
   Original Message
 From: Kidd Filby
 Sent: Wednesday, August 19, 2015 10:52
 To: Carlos Alvarez
 Cc: voiceops@voiceops.org mailto:voiceops@voiceops.org
 Subject: Re: [VoiceOps] Preventing calls to cell phones with
guaranteed accuracy

 If I were to offer this service or database access, I would
start with my own local copy of NPAC that I'd update every
X-minutes a day.  This product is available now and has been for a
while.  This is the only sure-way, I know of, to have the most
accurate data to work from.

 Kidd

 On Tue, Aug 18, 2015 at 2:30 PM, Carlos Alvarez
caalva...@gmail.com mailto:caalva...@gmail.com wrote:
 I have a customer in market research who is legally required to
manually dial calls to cell phones.  Right now they are
considering abandoning all of their auto/predictive dialer
software and going to manual dial for everything, because the
list-scrubbing services have been shown to be inaccurate.  There
are extreme penalties for auto-dialing a cell phone, and best
effort is NOT a defense to this, at all.  For example, Gallup
just settle a claim for $12M.

 So they need a totally accurate way to prevent a cell phone call
from originating from their dialer.  The only thing I can think of
is some sort of LRN dip + LRN-to-carrier-type response.  One of
their people talked to Neustar, but didn't get great answers
because he doesn't really understand telephony.  Before I get in
touch with Neustar, I thought I'd see if people here have some ideas.

 If you provide a commercial product for this, please feel free
to tell me so on or off list, the customer is willing to pay for
the service and we're open to all options.  I don't have a budget
number yet but manual dialing is going to cost them quite a bit
for some types of studies.

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


 --
 Kidd Filby
 661.557.5640 (C)
 http://www.linkedin.com/in/kiddfilby

 ___
 VoiceOps mailing list
 VoiceOps@voiceops.org mailto:VoiceOps@voiceops.org
 https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org mailto: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] Future of the Traditional PSTN vs VOIP and VoLTE

[Paul Timmins]

No, it won't. The rejections the other side provides are largely 
optional, and in fact the FCC has issued strict guidance about the 
necessary level of matching on an LSR (I want to say it's telephone 
number, account number, PIN if applicable, and zipcode, but I know 
there's some conditional variations on this).


Making the customer request a code from their losing carrier violates 
(at least the spirit, if not the letter of) current regulations by 
giving the current carrier a chance to market to an existing customer, 
threaten them, or make them pay a fee or contract termination price up 
front to get the code, or create undue levels of complexity on getting 
the code.


Currently, you can create subscriptions against a number and force the 
issue, porting the number under hostile conditions is in fact 
technically possible (in fact, i've done it before, with a service 
provider placing a large quantity of numbers in conflict over a 
unrelated dispute, conflict expiration window can be your friend if you 
use it carefully). The only person who can complain about it is the 
customer themselves as long as the numbers are active, so if they're on 
your side and you're certain the number is active, the losing carrier 
has little recourse. Adding a step where your ability to port relies on 
the good graces of the losing carrier is going to create a far worse 
situation.


-Paul

On 12/07/2015 11:06 AM, Peter Beckman wrote:

I hadn't heard of Iconectiv (one "n") before. I found this:

http://www.ericsson.com/news/150326-fcc-authorizes-local-number-portability_244069647_c 



Was it Neustar prior to this change?

I dream of a process for LNP that goes like this:

1. Customer goes to current carrier, requests a Porting Authorization
   Code for a number (or set of numbers), either online or over 
the phone.


2. Current carrier generates a Porting Authorization Code and 
provides

   it to the Customer.

3. Customer goes to new carrier, provides Phone Number, Current
   Carrier, and the Porting Authorization Code.

4. New carrier submits port request to Current Carrer with the Number
   and Porting Authorization Code. No name, billing address, PIN/SSN,
   just those three things.

5. Current carrier matches the Porting Authorization Code with their
   records for that Number and the port goes through.

Since all of this is centralized, just have Iconectiv manage it -- the
Current Carrier uses an API with Iconectiv to register the number and 
get a
code back. The New Carrier uses the API with Iconectiv with the number 
and

the code to verify porting. Codes expire after x days.

Will Iconectiv bring this level of sanity to porting in the NANP? Or will
it be more of the same, with rejections for an incorrect street 
abbreviation?


I know it's more complicated than that to implement, but it really 
ticks me

off how difficult it is to port numbers these days if you aren't a Tier 1
wireless carrier.

Beckman

On Sat, 5 Dec 2015, Erik Flournoy wrote:


Aloha Group,

I'm curious to know others thoughts on where they believe the 
traditional
PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be 
administering

the LNP in the US I feel as though it's the best time to try and propose
new or more up to date solutions that allow smaller carriers to operate.

For example there is no charge to have the ability to port numbers in 
NPAC,
but there is a monthly charge for the remote access to the NPAC. Then 
the

interconnectivity at the LEC level. The archaic ways of telecom have not
seemed to change much although VOIP is now in my opinion the standard of
telecom. VOIP will soon be able to get code blocks and route via SIP 
vs SS7
and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing 
company.


--- 


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


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

Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE

[Paul Timmins]

Honestly, I think the proper balance here (my 2c) would be creating a 
rolodex of properly maintained carrier contact information (with 
controlled distribution) so we could reach out to carriers we exchange a 
useful amount of traffic with, and working out privately the contortions 
necessary to connect to each other over SIP, and deciding then to route 
the intercarrier calls to each other over a private trunk group. My 
switches look up the LRN, and I can add anything to the translations for 
a particular LRN, including ISDN PRI, MF, SS7, or SIP. I can probably do 
H.323 to a carrier but you'll never hear me admit that (ugh!).


We have all the parts we need to convert the PSTN to SIP already. We 
don't need FCC permission to do this, we just need to take it upon 
ourselves to reach out, exchange information, and set up our 
interconnections accordingly.


The biggest concern for me would be keeping that rolodex out of the 
hands of sales departments so I don't get endless calls offering me LD 
termination, etc etc. Or looney end users complaining about spoofed 
numbers or collections agencies calling them from our codes and making 
legal threats that nobody but their pretend internet lawyers would take 
as a case.


-Paul


On 12/07/2015 12:00 PM, Pete E wrote:
These are the crux of the issue. If there were a cooperative group 
willing to peer to circumvent the PSTN, and if the group were large 
enough, then it could offer *some* competitive pressure to get the 
ILEC's to change. In fairness, Verizon and AT have been petitioning 
and hit some roadblocks by the FCC to retire their legacy networks. 
Some of these concerns are legit, some are not.  Now, I'm not naive 
enough to believe these petitions are for the good of the consumer or 
for anyone other than Verizon and AT But technologically, it's a 
step in the right direction.


But for the signaling issue mentioned above, there could potentially 
be a new DNS record type created which defines accepted signaling.


Trust is a whole different problem. Without a central authority, it 
could be chaotic and really difficult to manage. But I think the BGP 
analogy is a good one. If there could be a method of passing info and 
then either allowing or blocking it would be ideal, but it is a really 
big shift in VoIP security, as was pointed out.


That said, anyone interested in setting up a lab environment to hash 
this out?


On Sat, Dec 5, 2015 at 5:19 PM, Paul Timmins <p...@timmins.net 
<mailto:p...@timmins.net>> wrote:


Ah, but how would you know what IPs your inbound call should be
trusted from for your SBCs? It's hard enough to get people
properly interopped when the calling activity is planned, let
alone have random endpoints hit your network. Are they going to
use E.164? Should they send npdi/rn data? Should you trust the
calling party information being sent? How do you know the original
caller is even a legitimate telco and not some telemarketer going
on a rampage connecting directly with everything? If you are
getting problematic (abusive, illegal) inbound calls, how do you
look up that IP to know who to complain about? Is WHOIS enough?

-Paul



On Dec 5, 2015, at 15:14, Erik Flournoy <e...@eespro.com
<mailto:e...@eespro.com>> wrote:

Additionally to come to Neustar NPAC extremely LATE proposal
rescue of using the IP and SMS fields in the NPAC to packet route
calls instead of via the TDM/SS7 Path that would kinda remove IQ
from the path and allow carriers to directly connect via
packets.  Put the call on the IP packet path if it's voice and
use TDM only for faxing which I wish would disappear for goodness
sakes.

On Sat, Dec 5, 2015 at 12:09 PM, Alex Balashov
<abalas...@evaristesys.com <mailto:abalas...@evaristesys.com>> wrote:

On 12/05/2015 05:05 PM, Erik Flournoy wrote:

If a packet transverses your entire network as a packet
then it's never
a toll charge. It's a packet.


Well, right. :-) No provider of voice networks wants
value-added services to go away and be replaced by OTT
applications for whom they're just a low-margin, flat-rate,
95% percentile-billed transport layer.

To a point, you can understand where they're coming from.
They do the hard, capital-intensive work of building out the
network, while some clever mobile app out of Silicon Valley
pockets all the profits. That wasn't the assumption from
which they built anything.


-- 
Alex Balashov | Principal | Evariste Systems LLC

303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States

Tel: +1-800-250-5920 <tel:%2B1-800-250-5920> (toll-free) /
+1-678-954-0671 <tel:%2B1-678-954-0671> (direct)
Web: http:/

Re: [VoiceOps] SIP provider that will route to free conference services

[Paul Timmins]

Then they should charge a rate relative to the costs of terminating it and 
route it without discrimination. Hence the point of the FCC's order.



> On Dec 2, 2015, at 20:21, Colin Brown  wrote:
> 
> that's because  712-775  is an expensive rate.
> 
> On Wed, Dec 2, 2015 at 10:14 PM, Alex Balashov  > wrote:
> ‎I would guess the PDD is upstream LCR hunting through a large amount of 
> vendors who fail to take the call before finding one that will take it.


> [lots of trimming here - PT ]



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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] USF and Minimum Billing

[Paul Timmins]

IANAL but that's how I read it too. USF is to be levied on interstate services 
(of which voip is automatically because internet) and a contract shortfall is 
neither federal in jurisdiction nor a telecommunications service.


> On Dec 2, 2015, at 19:23, Peter Beckman  wrote:
> 
> Hey Folks --
> 
> I've got a carrier to which I've made a minimum commitment. I didn't get
> around to getting my spend up to the commit, and when my contract renewed,
> they billed me a minimum commit fee. Understandable, and I'm fine paying
> it. I didn't get anything for it -- zero telecom-related services.
> 
> However, they also charged the USF percentage on the minimum fee.
> 
> The Language from the FCC leads me to believe that this carrier's
> assessment of the USF on minimum billing is incorrect and illegal, as that
> fee is not interstate nor international end-user revenues. For specific
> detail, FCC Form 499-Q item 115 clearly states that the USF is to be
> taxed on:
> 
> "Telecommunications provided to other universal service contributors for
> resale as telecommunications or as interconnected VoIP"
> 
> The minimum fee is not telecommunications.
> 
> Additionally Form 499-A for Line 418 states:
> 
> "Line 418. — Other revenues that should not be reported in the contribution
> bases; Non-interconnected VoIP Revenues. Line 418 should include all
> non-telecommunications service revenues on the filer’s books, as well as
> some revenues that are derived from telecommunications-related functions,
> but that should not be included in the universal service or other fund
> contribution bases. For example, information services offering a capability
> for generating, acquiring, storing, transforming, processing, retrieving,
> utilizing, or making available information via telecommunications are not
> included in the universal service or other fund contribution bases."
> 
> Anyone else experience this? Or have any background? I do not believe the
> carrier should charge me nor pay the FCC the USF on non-telecom fees.
> 
> Any Telecom lawyers out there?
> 
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] "West" (humor)

[Paul Timmins]

Intrado announced they are rebranding to "West" today: 
http://www.intrado.com/events/OneWest/911Enable/?utm_source=iContact_medium=email_campaign=Intrado_content=One+West+-+911Enable
 


I made this fake marketing poster for them in honor of their new brand: 
http://www.telcodata.us/~paul/911enable-intrado-west.jpg 


-Paul


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE

[Paul Timmins]

I can only point out what I pointed out in the FCC comment period - iconnectiv 
already charges both sides for the LERG, which it solely maintains with an iron 
grip. It maintains many if not practically all of the standards documents, and 
now we're proposing (well, too late for future tense) to let them have control 
over number portability now.

The LERG update system and all of its screens, and all the goofy identifiers 
each held behind their own paywalls and gatekeepers - nothing about it looks to 
be modernizing any time soon. If you're hoping for forward looking ideas out of 
this company, you're not going to find them. They have entrenched interest in 
maintaining the status quo.

I'd love for it to be different, but I see this only as more consolidation 
around the dinosaurs that created this convoluted market to begin with.

-Paul

> On Dec 5, 2015, at 14:17, Erik Flournoy  wrote:
> 
> Aloha Group,
> 
> I'm curious to know others thoughts on where they believe the traditional 
> PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering 
> the LNP in the US I feel as though it's the best time to try and propose new 
> or more up to date solutions that allow smaller carriers to operate.
> 
> For example there is no charge to have the ability to port numbers in NPAC, 
> but there is a monthly charge for the remote access to the NPAC. Then the 
> interconnectivity at the LEC level. The archaic ways of telecom have not 
> seemed to change much although VOIP is now in my opinion the standard of 
> telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 
> and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
> 
> 
> Erik F.
> 
> CONFIDENTIALITY NOTICE
> This e-mail message, including any attachments from EESPRO.com - contain 
> information which is CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The information 
> is intended only for the use of the individual named above and may not be 
> disseminated to any other party without written permission. If you are not 
> the intended recipient, or the employee or agent responsible for delivering 
> the message to the intended recipient, you are hereby notified that any 
> dissemination, disclosure, distribution, copying or taking of any action in 
> reliance on the contents of this e-mailed information is strictly prohibited. 
> If you have received this transmission in error, please immediately notify 
> i...@eespro.com , and permanently delete this e-mail 
> and the attachments hereto, if any, and destroy any printout thereof.
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE

[Paul Timmins]

They operate a competing interconnection service that you can use to in some 
circumstances entirely replace interaction with the RBOC, save for doing things 
like LSRs for number portability. You can get an entirely VoIP handoff to them.

As for any to any interconnection, without some sort of central authority this 
will take the already terrible security of the PSTN and make it even worse. Why 
pay a carrier to dump tons of fraud calls on and risk getting shut off when you 
can blast it out yourself, SMTP style? I mean, i love the concept in theory but 
in practice we need an arbiter of the trust relationships between us to 
maintain the integrity of the network, what little it even has at this point.

-Paul

> On Dec 5, 2015, at 14:41, Erik Flournoy <e...@eespro.com> wrote:
> 
> What's Inteliquent's Position? PSTN 2.0 is a great way to describe the 
> upgraded regulation of a system that's not invented to be free to the masses 
> but more so profited by one large mass. I just can't wrap my head around how 
> the government supposedly broke up the bells years ago but for the past 
> century Neustar has been the hub of all the numbering and telcordia the 
> guideline to how you do telecom. A guideline that is licensed and not free to 
> the masses.
> 
> I continually see smaller CLEC get eaten alive by the ILEC or all the 
> regulatory fees that are based around the telecom system of my great 
> grandparents. Example to order services from most ILEC's you need access to 
> telecordia to get CLLI codes or NC/NCI codes all information owned and 
> licensed by one company.
> 
> 
> 
> On Sat, Dec 5, 2015 at 11:29 AM, Alex Balashov <abalas...@evaristesys.com 
> <mailto:abalas...@evaristesys.com>> wrote:
> On 12/05/2015 04:28 PM, Paul Timmins wrote:
> 
> Are you ignoring the position Intelliquent has in the market?
> 
> Am I?
> 
> 
> --
> 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.evaristesys.com/>, 
> http://www.csrpswitch.com/ <http://www.csrpswitch.com/>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
> https://puck.nether.net/mailman/listinfo/voiceops 
> <https://puck.nether.net/mailman/listinfo/voiceops>
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE

[Paul Timmins]

Ah, but how would you know what IPs your inbound call should be trusted from 
for your SBCs? It's hard enough to get people properly interopped when the 
calling activity is planned, let alone have random endpoints hit your network. 
Are they going to use E.164? Should they send npdi/rn data? Should you trust 
the calling party information being sent? How do you know the original caller 
is even a legitimate telco and not some telemarketer going on a rampage 
connecting directly with everything? If you are getting problematic (abusive, 
illegal) inbound calls, how do you look up that IP to know who to complain 
about? Is WHOIS enough?

-Paul

> On Dec 5, 2015, at 15:14, Erik Flournoy  wrote:
> 
> Additionally to come to Neustar NPAC extremely LATE proposal rescue of using 
> the IP and SMS fields in the NPAC to packet route calls instead of via the 
> TDM/SS7 Path that would kinda remove IQ from the path and allow carriers to 
> directly connect via packets.  Put the call on the IP packet path if it's 
> voice and use TDM only for faxing which I wish would disappear for goodness 
> sakes.
> 
> On Sat, Dec 5, 2015 at 12:09 PM, Alex Balashov  > wrote:
> On 12/05/2015 05:05 PM, Erik Flournoy wrote:
> 
> If a packet transverses your entire network as a packet then it's never
> a toll charge. It's a packet.
> 
> Well, right. :-) No provider of voice networks wants value-added services to 
> go away and be replaced by OTT applications for whom they're just a 
> low-margin, flat-rate, 95% percentile-billed transport layer.
> 
> To a point, you can understand where they're coming from. They do the hard, 
> capital-intensive work of building out the network, while some clever mobile 
> app out of Silicon Valley pockets all the profits. That wasn't the assumption 
> from which they built anything.
> 
> 
> --
> 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 
> 
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE

[Paul Timmins]

T-Mobile is entirely switching away from TDM connectivity and using IQ for 
their entire TDM interop from what a little birdie told me. That alone seemed 
like a pretty big paradigm shift.

> On Dec 5, 2015, at 15:00, Alex Balashov <abalas...@evaristesys.com> wrote:
> 
> On 12/05/2015 04:55 PM, Paul Timmins wrote:
> 
>> I'd say probably 1/3 to 1/2 of our traffic ends up never touching
>> RBOC equipment.
> 
> Oh, okay, so there's been some progress in this area since I last looked 
> around.
> 
> I suppose it's moderated by the degree to which the Tier 1 CLEC oligopoly 
> that feeds the VoIP supply chain is willing to participate. And it sounds 
> like their willingness may be higher than I imagined.
> 
> --
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Unsecured conference lines

[Paul Timmins]

Does it expose you to anything? If not shrug and shut it off. If so, 
offer it with something that passes the exposure on instead, explaining 
your costs change. No need to lecture them on their own laws or protect 
them from themselves. They need a service provider, not a parent. :)


On 06/02/2016 03:33 PM, Carlos Alvarez wrote:
Believe me, I've covered that and several other regulatory matters, 
they maintain they don't care.  The directive I got was from the 
second from the top, and he claims the CEO is behind him.  Right now 
the stale-mate is at "we can have a conference call to discuss it with 
the CEO, but I won't do it without that."  If they call me on it, well 
then...I'm just not sure.


As to what type of "medical" company, I would like to keep the 
customer info very anonymous, but I'll say that it's way more than 
uniforms but not quite discussing a specific patient's ED 
prescription.  There's probably not any specific patient data on a 
call, or maybe just very rarely.


On Thu, Jun 2, 2016 at 12:27 PM, Anthony Orlando > wrote:


Carlos
Just mention HIPAA.  You might also have some HIPAA compliance
issues as well.



> On Jun 2, 2016, at 1:54 PM, Carlos Alvarez > wrote:
>
> We have a customer who has been nagging us to remove the PIN
from their conference lines.  They are getting more insistent. 
We've said no, for the obvious security reasons, and explained

them all clearly.  On top of it, this is a medical-related company
having sensitive conversations on conferences.  They keep pushing
us.  What would you do?  On the one hand I think we have no
liability in the matter, but on the other, we're more of a
consulting ITSP than just a generic service provider.  We
specialize in helping people not do stupid things with their phone
system.  There's also the matter of just eating up a bunch of
channels by people using it as their own conference.
>
> ___
> 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] Can anyone port a Rock Hill, SC number?

[Paul Timmins]

Ooh! You found a fun one! Nobody in that ratecenter except the RLEC and 
the various wireless characters, and possibly your lucky day, these guys:


http://www.navacore.net/

They look like they'd be willing to sell you a sip trunk on it from 
their website, that's on you to negotiate of course.


-Paul

On 01/18/2016 10:37 AM, Peter Beckman wrote:

803-981- Verizon Wireless

None of my current sources can port it, not even Verizon non-Wireless
itself.

Simply unportable forever?

--- 


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] Instant Porting

[Paul Timmins]

"Formal" process is that your CLEC looks at your LOA, tucks it in a drawer 
after a cursory glance (hopefully they at least look at it), then submits a LSR 
(electronically or via excel spreadsheet) to the losing carrier. The losing 
carrier gives an FOC within 24 hours for usually within 3 days (or whenever 
they request the due date to be). Your CLEC builds the NPAC subscriptions, the 
losing carrier might or might not concur them (concurrence timers in the NPAC 
are out of scope for this question).

On the due date, the new carrier clicks activate in LTI (or sends an EDI 
message into the LSMS using their mechanized interfaces) and the national 
databases update within a few seconds (some may take a minute or two, ugh, 
unless they're disconnected and your number could be stuck in that LSMS for up 
to 24 hours). The losing carrier pulls out the routes/translations/whatever 
from their switch and issues a final bill.

Technically and legally, nothing stops your new carrier from calling a buddy at 
the old carrier, saying:
Winning: "hey john can we port this #, we have an LOA"
Losing: "sure, let me get into NPAC. create the subscription for now and i'll 
concur it"
Both carriers: *tap tap tap*
Losing: "okay i granted concurrence"
Winning: "thanks buddy, I just activated it, you can clean up your routes now"
Losing: "no problem great to hear from you!"
Winning: "lunch tomorrow?"
Losing: "sure!"

That actually meets FCC requirements. It doesn't meet ATIS recommendations but 
they're only recommendations (mostly put in place by people who really like the 
status quo).

-Paul

> On Feb 10, 2016, at 08:14, Colton Conor <colton.co...@gmail.com> wrote:
> 
> So what is the best case senario under todays rules for wireline carriers? 
> Lets assume we are talking about a CLEC with their own switch and number pool 
> porting away from the incumbend ILEC (Verizon or AT wireline). Assume the 
> CLEC has access to NPAC.
> 
> How does this process even work? Today we just have our customer sign an loa, 
> and then upload the LOA to our wholesaler. They take it from there, but I 
> would like to know the process and what is involved. Does each carrier have 
> their own system to verifying that the number and account number belongs to 
> the said provider?
> 
> On Tue, Feb 9, 2016 at 8:59 PM, Paul Timmins <p...@timmins.net 
> <mailto:p...@timmins.net>> wrote:
> A lot of it also comes down to cellular portability being required by the FCC 
> to process ports in 4 hours or less from the day it was started as well. The 
> FCC saw how wireline worked and said they weren't going to have that on 
> wireless. Shortly after they cleaned up wireline (it used to be much worse!), 
> and then introduced rules for intermodal ports.
> 
> On Feb 9, 2016 20:43, Carlos Alcantar <car...@race.com 
> <mailto:car...@race.com>> wrote:
> >
> >
> > A lot of it goes into literally 4 companies working together to have 
> > automation.  I don't know that process would scale if it was hundreds of 
> > companies trying to accomplish the same thing without a clearinghouse in 
> > the middle and everyone talking the same language.
> >
> > ​
> > Carlos Alcantar
> > Race Communications / Race Team Member
> > 1325 Howard Ave. #604, Burlingame, CA. 94010
> > Phone: +1 415 376 3314 <tel:%2B1%20415%20376%203314> / car...@race.com 
> > <mailto:car...@race.com> / http://www.race.com <http://www.race.com/>
> >
> >
> > 
> > From: VoiceOps <voiceops-boun...@voiceops.org 
> > <mailto:voiceops-boun...@voiceops.org>> on behalf of Alex Balashov 
> > <abalas...@evaristesys.com <mailto:abalas...@evaristesys.com>>
> > Sent: Tuesday, February 9, 2016 3:02 PM
> > To: Alexander Lopez; voiceops@voiceops.org <mailto:voiceops@voiceops.org>
> > Subject: Re: [VoiceOps] Instant Porting
> >
> > One would think that the incentives would diverge depending on whether
> > the given wireless operator expects to be a net beneficiary of porting
> > in or a net loser to porting out -- a function of their market position,
> > which is not equal.
> >
> > --
> > Alex Balashov | Principal | Evariste Systems LLC
> > 303 Perimeter Center North, Suite 300
> > Atlanta, GA 30346
> > United States
> >
> > Tel: +1-800-250-5920 <tel:%2B1-800-250-5920> (toll-free) / +1-678-954-0671 
> > <tel:%2B1-678-954-0671> (direct)
> > Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>, 
> > http://www.csrpswitch.com/ <http://www.csrpswitch.com/>
> > _

Re: [VoiceOps] Instant Porting

[Paul Timmins]

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
This does raise, in light of the OP, the question of what economic or
political incentive wireless carriers have to cooperate in relatively
seamless porting to/from each other.

--
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
___
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

Re: [VoiceOps] Instant Porting

[Paul Timmins]

How about a Vatican II for LNP processes, eh?

On Wed, 02/10/2016 12:20 PM, Mary Lou Carey <mary...@backuptelecom.com> wrote:
> 



 .mceResizeHandle {position: absolute;border: 1px solid black;background: 
#FFF;width: 5px;height: 5px;z-index: 1}.mceResizeHandle:hover {background: 
#000}img[data-mce-selected] {outline: 1px solid black}img.mceClonedResizable, 
table.mceClonedResizable {position: absolute;outline: 1px dashed black;opacity: 
.5;z-index: 1}
.mceResizeHandle {position: absolute;border: 1px solid black;background: 
#FFF;width: 5px;height: 5px;}
.mceResizeHandle:hover {background: #000;}
img[data-mce-selected] {}
img.mceClonedResizable, table.mceClonedResizable {position: absolute;}
 
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 <p...@timmins.net> 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 <n...@flhsi.com> 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" <alex.lo...@opsys.com>
>  Sent: Tuesday, February 09, 2016 6:00 PM
>  To: "Alex Balashov" <abalas...@evaristesys.com>, "voiceops@voiceops.org" 
> <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

Re: [VoiceOps] Instant Porting

[Paul Timmins]

If both carriers have a good business relationship and are willing to 
write matching orders in the NPAC (winning carrier makes the 
subscriptions, the losing carrier submits concurrence) you can port 
numbers in literally seconds.


But we're not required to do things that fast so it rarely happens. Why 
move fast to let our customers leave when we can legally take our time 
and spend a couple days collecting more revenue from them?


-Paul
(DEFINITELY not speaking on behalf of my employer!)

On 02/09/2016 04:24 PM, Adam Vocks wrote:


Our landline ports are instantaneous.  (Or so we think.)  It’s always 
been that way for us.  I didn’t know there was any other way.


Adam

*From:*VoiceOps [mailto:voiceops-boun...@voiceops.org] *On Behalf Of 
*Colton Conor

*Sent:* Tuesday, February 9, 2016 2:52 PM
*To:* voiceops@voiceops.org
*Subject:* [VoiceOps] Instant Porting

How do cellular carriers perform almost instant porting of number, and 
why can't landline providers do the same? For example if I take my 
Sprint cell phone to an AT store, and switch over to AT they can 
do this almost instantly.


I met someone one time at a tradeshow claiming they could do same day 
porting for landline numbers just as the cellular industry did, but I 
was not sure how he was doing it or if it was a myth.


I know cell systems are more automated and require a pin.



___
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

[Paul Timmins]

A lot of it also comes down to cellular portability being required by the FCC 
to process ports in 4 hours or less from the day it was started as well. The 
FCC saw how wireline worked and said they weren't going to have that on 
wireless. Shortly after they cleaned up wireline (it used to be much worse!), 
and then introduced rules for intermodal ports.

On Feb 9, 2016 20:43, Carlos Alcantar  wrote:
>
>
> A lot of it goes into literally 4 companies working together to have 
> automation.  I don't know that process would scale if it was hundreds of 
> companies trying to accomplish the same thing without a clearinghouse in the 
> middle and everyone talking the same language. 
>
> ​ 
> Carlos Alcantar 
> Race Communications / Race Team Member 
> 1325 Howard Ave. #604, Burlingame, CA. 94010 
> Phone: +1 415 376 3314 / car...@race.com / http://www.race.com 
>
>
>  
> From: VoiceOps  on behalf of Alex Balashov 
>  
> Sent: Tuesday, February 9, 2016 3:02 PM 
> To: Alexander Lopez; voiceops@voiceops.org 
> Subject: Re: [VoiceOps] Instant Porting 
>
> One would think that the incentives would diverge depending on whether 
> the given wireless operator expects to be a net beneficiary of porting 
> in or a net loser to porting out -- a function of their market position, 
> which is not equal. 
>
> -- 
> 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 
>
> ___
> 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] Test Call Request

[Paul Timmins]

Level 3 routed away from an "underlying carrier" and now i can call 
through just fine. They opened a ticket with the "underlying carrier" so 
hopefully that kicks this issue in the junk for you :D


On 02/12/2016 05:33 PM, Rafael Possamai wrote:

Called from 414-269-60xx via SIP Logic out of NYC.

The recording played right away, no problems here.

On Fri, Feb 12, 2016 at 1:42 PM, Nick Olsen > wrote:


Greetings all,
I come to you today with a request.
We've been getting a lot of complaints from customers about their
number not being able to be called. In our CDR, We show no record
of the call attempt.
We get two general reports. 1. The call rings and rings (We never
get the call). 2. The call plays back "Please wait while we
contact the party you are calling" followed by never ending
ringing. (We never get the call).
I was hoping I could get a few of you to call a test number of
mine and report failures.
The number is 321-205-1234 , It should
immediately answer and play back our "You've reached Florida High
Speed Internet" sound file. No DTMF options will work, Then it'll
hang up.
If you could report back (on/offlist) with the outcome of the
call. And the carrier you terminated the call to.
It would be greatly appreciated, Thanks!

Nick Olsen
Network Operations
(855) FLSPEED  x106


___
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 Innovations reliability

[Paul Timmins]

Sadly, assassins win if i stop breathing, so if someone starts to choke 
me, I fight it the best I can and run away at my earliest opportunity.


On 03/17/2016 07:38 PM, Anthony Orlando via VoiceOps wrote:
It's a shame we can't support them. This could be anyone of us. 
Hackers win if you port away.


Sent from my iPhone

On Mar 17, 2016, at 5:43 PM, Robert Johnson > wrote:


Their primary SBC and DR IP are both in the same IP netblock, so 
whenever the DDOS hits, both IPs are affected. The past few outages 
have involved 80% packet loss or so to both hosts, so some calls do 
make their way through, and plenty of wierdness ensues when an INVITE 
makes its way through but not the OK on the way back.


Can't wait to get our numbers ported out.

On Thu, Mar 17, 2016 at 6:27 PM, Nate Burke > wrote:


Annnd they're down again.


On 3/17/2016 5:14 PM, Nate Burke wrote:

6 calls from 4 different CID numbers.  All within 3 minutes.

On 3/17/2016 4:58 PM, Nathan Anderson wrote:


Yesterday I definitely saw calls coming from the DR IP in my
logs, but I had not yet added that IP as a peerin our SBC. 
I'll have to comb through logs today to see if we got any.


Are you saying that the multiple calls you saw coming to your
desk were all from the same number?  If I had to guess, their
side probably sent continuous INVITEs to you when it failed to
get back an OK for any of them (not that you weren't sending
back OK, but that their either didn't reach their SBC or did
not reach it in a timely manner).

-- Nathan

*From:*VoiceOps [mailto:voiceops-boun...@voiceops.org] *On
Behalf Of *Jeff Waddell
*Sent:* Thursday, March 17, 2016 2:53 PM
*To:* Nate Burke
*Cc:* voiceops@voiceops.org 
*Subject:* Re: [VoiceOps] VoIP Innovations reliability

That is the issue a lot of our customers are reporting - where
multiple calls are sent

On Thu, Mar 17, 2016 at 5:49 PM, Nate Burke > wrote:

I didn't see any traffic increment on the DR IP Address in my
firewall rules, but this was odd.  During the 15 minute period,
I had probably 5 or 6 simultaneous calls ring into my desk.  I
normally only take a handfull of calls a day.

On 3/17/2016 4:39 PM, Jeff Waddell wrote:

We implemented it too - I haven't checked to see if any
traffic was sent across it

On Thu, Mar 17, 2016 at 5:20 PM, Nate Burke
> wrote:

Only 15 Minutes this time though.  I had implemented the
Disaster Recover Trunk as mentioned previously, but I
didn't seem to be getting any calls completed through it.

On 3/17/2016 4:16 PM, Shripal Daphtary wrote:

Down again!

Thanks,

Shripal


On Mar 16, 2016, at 9:50 AM, Nate Burke
> wrote:

Looks like it just came back up for me. Just over
30 min.

Nate

On 3/16/2016 8:45 AM, Shripal Daphtary wrote:

We are experiencing an outage as well.

Thanks,

Shripal


On Mar 16, 2016, at 9:36 AM, Nate Burke
> wrote:

Problems again this morning?  Looks to be
acting the same as it has been.

On 3/11/2016 6:00 PM, Alexander Lopez wrote:

I added them to our monitoring
platform, stated getting alarms this
past hour or so.

Up and down.



 Original message 
From: Nathan Anderson 

Date: 3/11/2016 6:31 PM (GMT-05:00)
To: 'Nate Burke' 
,
voiceops@voiceops.org

Subject: Re: [VoiceOps] VoIP
Innovations reliability

...aand we're back.

-- Nathan

-Original Message-
From: VoiceOps
[mailto:voiceops-boun...@voiceops.org]
On Behalf Of Nathan Anderson
Sent: Friday, March 11, 2016 3:30 PM
To: 'Nate 

Re: [VoiceOps] SS7

[Paul Timmins]

You could do it by saying "hey, this handset is roaming on me" then 
directing the call back to the handset in question, I figure. It would 
be inbound only intercept, but i could see that working.


-Paul

On 04/21/2016 02:12 PM, Matthew Yaklin wrote:



The part I was curious about and perhaps someone can clarify who has 
more knowledge than I is...



It appears in order to record calls the attacker has to be in very 
close proximity to the target. Like radio/tower range.


You cannot record a conversation half way across the world.


Matt




*From:* VoiceOps  on behalf of Matthew 
Yaklin 

*Sent:* Thursday, April 21, 2016 2:09 PM
*To:* Kidd Filby; Chris Aloi
*Cc:* voiceops@voiceops.org
*Subject:* Re: [VoiceOps] SS7


Here is a paper that may shed some light on the discussion for the 
curious.



https://www.sans.org/reading-room/whitepapers/critical/fall-ss7--critical-security-controls-help-36225

SANS Institute InfoSec Reading Room 


www.sans.org
The Fall of SS7 Ð How Can the Critical Security Controls Help? 4 " 
#$$#%!&'()#*+!"#$$#%,-')#*./-#01,2'-! area notices this registration 
and transfers to a Visitor ...







*From:* Kidd Filby 
*Sent:* Thursday, April 21, 2016 2:01 PM
*To:* Chris Aloi
*Cc:* Matthew Yaklin; voiceops@voiceops.org
*Subject:* Re: [VoiceOps] SS7
In a strictly TDM world, or conversation... having access to the SS7 
network gets you nothing but what and where the call traversed.  NO 
audio is carried and without End Office controlling software for call 
routing, just dropping it into some IP connection is not going to 
afford you anything other than what you already have.  You still need 
access to the audio carrying infrastructure of the network to get the 
audio.


I cannot comment on CALEA

Kidd

On Thu, Apr 21, 2016 at 10:56 AM, Chris Aloi > wrote:


It looked like they had access to SS7 links (likely A links
terminated to a physical server) and were using FreeSWITCH to
somehow fork the media from the call and record it.  Just a guess
based on  the quick console recording.

Correct, SS7 doesn't carry the actual voice it handles the
signaling to bring up the voice channels (by identifying be point
code and CICs) and various other signaling bits.  Not sure if
there are provisions for CALEA in SS7 that could fork a media
stream or exactly how that would work.

So I guess the barrier to entry would be access to the SS7
network, not as easy as hopping on the Internet, but certainly not
much of a challenge.

---
Christopher Aloi
Sent from my iPhone

On Apr 21, 2016, at 11:52 AM, Kidd Filby > wrote:


There is no VOICE traversing the SS7 network, so you cannot
possibly record a conversation by having access to the SS7
network only.

On Thu, Apr 21, 2016 at 9:36 AM, Matthew Yaklin
> wrote:


In other words the hacker has to have working SS7 trunks or
access to someone who does? That is how I understood it.

Not exactly a remote hack from mom's basement sort of thing.

Matt


From: VoiceOps > on behalf of Peter
Rad. >
Sent: Thursday, April 21, 2016 11:25 AM
To: voiceops@voiceops.org 
Subject: [VoiceOps] SS7

FYI...

  U.S. carriers mum on 60 Minutes report on vulnerability in
SS7 -

http://www.fiercewireless.com/story/us-carriers-mum-60-minutes-report-vulnerability-ss7/2016-04-19

Regards,

Peter Radizeski
RAD-INFO, Inc.
813.963.5884 
http://rad-info.net
* Need bandwidth or colocation? call me
___
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




-- 
Kidd Filby

661.557.5640  (C)
http://www.linkedin.com/in/kiddfilby
___
VoiceOps mailing list
VoiceOps@voiceops.org 
https://puck.nether.net/mailman/listinfo/voiceops





--
Kidd Filby

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

[Paul Timmins]

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 
> 


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] AT / Onvoy / Vonage call routing screwup after LNP

[Paul Timmins]

The fact that Vonage hasn't disconnected the ATAs makes me feel like 
their disconnect workflow hasn't quite worked, and if they have a direct 
peering arrangement with AT this could be involved in that. They may 
try to contact Vonage as well and ask them about it, they certainly have 
experienced it somewhere before I'm sure, and might have a workflow for 
fixing it.


Of course, opening a ticket with the originating carrier (AT) 
definitely needs to happen, since they're making the routing decision 
they're the ones that can fix it.


-Paul

On 12/05/2016 09:16 AM, Oren Yehezkely wrote:

Had similar experiences, but with different vendor.
I would try to open a ticket with ATT to fix their routing. I know, it 
won't be easy.
I would also try to speak with Vonage. I wouldn't have the customer 
disconnect before calls are flowing correctly.
If this doesn't work, and you wait another day or two with no results, 
I may try to port the numbers away from convoy.


Interested to know how you solved it...
Good luck.

On Dec 5, 2016 8:06 AM, "Nathan Anderson" > wrote:


So here's a weird one: we took over a small business account from
Vonage.  Vonage was using Onvoy for origination, and we elected to
keep the TNs with Onvoy (through a wholesaler). So the "port" only
consisted of Onvoy repointing traffic for those TNs internally
away from Vonage and to our reseller, with no LRN change.

The weird bit is that we definitely are seeing some traffic for
those numbers hitting us, but it's been nearly 72 hours now and
some calls are still ringing their Vonage ATAs.  I couldn't tell
you definitively where the delineation is, but I can tell you, for
example, that if I call any of the TNs from my AT cell, those
calls still hit Vonage, so I can at least reproduce the problem
at-will.  This is for a local real-estate office, and AT is big
in our relatively rural market, so even if it turns out that AT
is the only provider that is affected, that is still a huge
percentage of our end-user's client base.  And the frustrating bit
is that traffic is now effectively being "forked", which is a huge
inconvenience for our end-user since they have an old key system
with analog trunks and so we have to choose between having our IAD
hooked up to their KSU or having their stack of Vonage ATAs hooked
up.  (For now, we have left the Vonage ATAs in place, and we are
forwarding calls tha
 t come to us to a single line from the ILEC that this office
ended up keeping.  I don't know what we would have done if they
didn't have that line.)

Onvoy swears up and down that everything is configured correctly
on their side, and given that we are at least getting *some*
calls, I am inclined to believe them.  When I give them call
examples from my cell phone, they say that they don't even see
those calls hitting their systems at all.  At this point, the
running theory is that AT must have some kind of direct peering
with Vonage, and Onvoy isn't in the loop at all on those calls. 
If that's the case, then perhaps everything magically works itself

out once I have the end-user call up Vonage and have them close
out the account completely.  But I'm not sure it is worth the risk
of having them take that step with things as they are, on the
off-chance that I guessed wrong (instead of the problem getting
fixed, calls from AT start going to /dev/null).

Has anybody encountered anything like this before, or heard of
national wireless carriers doing direct peering with national VoIP
providers while completely bypassing PSTN switching
infrastructure?  Are there any AT, Onvoy, and/or Vonage reps
reading this who can help un- this cluster?

Thanks,

--
Nathan Anderson
First Step Internet, LLC
nath...@fsr.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] Feedback request - Inteliquent

[Paul Timmins]

We started with Inteliquent when they were Neutral Tandem. We use their local 
interconnection, Feature Group D originating and terminating, and AIA (on-net 
LD termination) products and have had minimal issues with them over the years, 
and they've been generally helpful with any issues we have had, though a few 
times we've had to apply firm but reasonable pressure to get them to look at 
issues they initially thought weren't theirs, but i get that with a lot of 
companies from time to time.

-Paul

> On Apr 19, 2017, at 19:42, Brad Anouar  wrote:
> 
> Hi All,
> 
> Do any of the group members use (used) Inteliquent for 
> termination/origination? If so, your feedback would be appreciated. Feel free 
> to contact me directly.
> 
> Thank you,
> 
> -- 
> 
> Brad Anouar
> Director of Systems Engineering
> Email brad.ano...@masergy.com 
> Office +1 310 360 2028 <>
> 
> 
> www.m asergy.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] Past due/overdue invoices for Doctor offices - How to handle?

[Paul Timmins]

I'd imagine Doc has a cellphone if s*it hits the fan. If not, he surely 
has a visa card that he could give you.


And yes, we warm line customers who don't pay for a day or so first, 
they can call repair and 911 and that's it. Then that goes dark too.


On 03/09/2017 02:23 PM, Carlos Alvarez wrote:
I'm not sure why you'd treat them any differently from any other 
customer?  Your service agreement should include clear info on when 
accounts will be disconnected, and presumably the customer signed it.  
Doctor's offices are not considered emergency medical facilities, and 
in fact, 100% of our doctor/medical offices include "if this is an 
emergency dial 911" at the beginning of their greetings.


Our ToS also includes:
This service may not be used in any life support, emergency response, 
or other critical communications which may cause loss of life, injury, 
or property damage. Customer acknowledges that the service may be 
interrupted on nights and weekends for routine maintenance.




On Thu, Mar 9, 2017 at 12:16 PM, jungle Boogie 
> wrote:


Hi All,

What's the general rule/experience when dealing with Doctor offices
that have unpaid invoices on postpaid telephone service plans?

This may vary largely in different regions/states, but can a VoIP
provider threaten to disconnect telephone service for unpaid invoices?
If a Doctor office is on a pre-paid plan, like most VoIP operations,
are is there any liabilities on the VoIP provider when the balance
falls below a 0 or negative balance and there happens to be a medical
emergency? Perhaps it would be possible to disable calling to everyone
except 911. Is this a legitimate practice?

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



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

Re: [VoiceOps] under what circumstances can a port out request be rejected?

[Paul Timmins]

These are for tollfree, the rules for LNP are different.

On 04/05/2017 06:45 PM, Reinventing Rich wrote:

Thanks mark!

On Wed, Apr 5, 2017 at 4:31 PM, Mark Diaz > wrote:


According to or legal firm, these are the valid disputes:

Valid port dispute reasons

Customer name mismatch/missing 01

Address mismatch/missing 02

Contact/Customer Signature missing 03

Toll Free Shared/Bundled 04

Signature Date missing or Expired 05

Sent to Wrong Resp Org 06

TFN Not listed on Request 07

All Data Mismatch 08

LOA/Linking LOA missing 09

Illegible LOA 11

More Recent LOA 12

Unauthorized Contact/customer signature 13




On Apr 5, 2017, at 6:29 PM, Reinventing Rich
> wrote:


thanks so much everyone. I really want to do right by everyone I
just cant find any of these rules regarding porting on the FCC
site that isn't specifically for wireless providers and we are a
voip provider

On Wed, Apr 5, 2017 at 4:23 PM, Carlos Alvarez
> wrote:

Our attorney advised that we can reject it for unpaid
balances, but not for future revenue based on a contract.  I
never thought to ask whether early term fees could be
assessed immediately so it could be denied.  Tread lightly,
the FTC/FCC like to take the customer's side.

I think I'd call the customer and ask their intentions.


On Wed, Apr 5, 2017 at 3:09 PM, Reinventing Rich
> wrote:

Long story but we bought out a persons 3 year Century
Link 3 yr contract and now half a year later we just got
a port out request for their main TN.

Ordinarily I would say hey if you dont like the service
no big deal but this is going to hurt bad if they won't
pay up what they owe on the contract (at least what we
had to pay Century Link)

I've never tried to reject someones port out request, can
I just reject for lack of payment?

Do I have to give a reason?

Do I just do like all the other providers do to me and
make them provide CSR data and keep telling them its
wrong... XD

I'm asking in earnest, I want to be legit but this is
really going to hurt the company I work for

___
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





-- 
Cheers,

Rich Breton

Give a man a program, you will frustrate him for a day;Teach him
how to program, you will frustrate him for a lifetime.
___
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





--
Cheers,
Rich Breton

Give a man a program, you will frustrate him for a day;Teach him how 
to program, you will frustrate him for a lifetime.



___
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] TN and carrier list in a rate center

[Paul Timmins]

If you're set up in the NPAC you can request a report of all LNP data in 
your region, or subsections thereof. If a snapshot is good enough.


-Paul

On 04/05/2017 07:10 PM, Keln Taylor wrote:

Not free.
Cheaper. :)

 I was hoping there might be a more efficient (and I assumed cheaper) 
way than dipping all the numbers individually in a rate center.




On Apr 5, 2017 6:01 PM, "Alex Balashov" > wrote:


So you are looking for a free means of bulk-dipping a large group
of numbers?

-- Alex

On Apr 5, 2017, at 6:58 PM, Keln Taylor > wrote:


I think that my question wasn't clear, or I'm not finding the
right options at http://www.localcallingguide.com/
 or http://telcodata.us/

Even though a block of TNs may be assigned to a carrier, an
individual number may be ported elsewhere.  I would like to know
where each number is ported. for example:

the carrier for 123-456-0001 might be Level 3 and the carrier for
123-456-0002 might be Vonage

I would like a list of individual numbers and their current
carriers in a rate center.



Sincerely,
Keln Taylor
870-204-2121 
kelntay...@gmail.com 

On Wed, Apr 5, 2017 at 10:41 AM, Mary Lou Carey
> wrote:

www.localcallingguide.com 
Mary Lou Carey
BackUP Telecom Consulting
mary...@backuptelecom.com 
Office: 615-791-9969 
Cell: 615-796- 

On April 5, 2017 at 8:33 AM Shripal Daphtary
> wrote:

Telcodata.us ?
If you already have the blocks and you want to find npac
like data and cnam you can use everyoneapi


Thanks,
Shripal

On Apr 5, 2017, at 9:21 AM, Keln Taylor
> wrote:


I would like to acquire a list of TN's and their respective
carriers for a small rate center (14 blocks of numbers)
I can do API requests to Twilio or another provider to
lookup a carrier per TN, but that is outside of my budget.
Does anyone know a more efficient way to acquire this
information?

Sincerely,
Keln Taylor
kelntay...@gmail.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] Neustar Port PS Alternative?

[Paul Timmins]

You can get all that information in the LTI, if i recall

> On Jan 2, 2018, at 18:01, Robert Johnson  wrote:
> 
> Nuestar's Port PS is now a paid service and I have been tasked with finding 
> quotes for competing services. Iconectiv was my first choice, but I have been 
> informed their tool is not yet available. What other options are out there?
> ___
> 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] Phone auth for incoming calls?

[Paul Timmins]

> On Aug 9, 2018, at 9:47 PM, Brandon Martin  
> wrote:
> 
> On 08/09/2018 04:46 AM, Alex Balashov wrote:
>> Yes, but until and unless your upstream supply chain is doing TLS and
>> you can provide end-to-end security, it's a pointless waste of time.
> 
> There's also an argument to be made that I haven't seen brought up for 
> protecting SIP registration credentials either by providing transport 
> confidentiality for a conventional password/secret or by using TLS client 
> certificates.  If you're at all worried about an adversary observing your 
> actual comms, I'd be doubly worried about somebody stealing registration 
> credentials and abusing them.

TLS was never about end to end confidentiality. We have wiretap obligations 
after all. Until the last copper line is dead and gone there will always be a 
way for unencrypted calls to occur.

TLS is good when you don't want your local IT staff to know what the CEO is 
talking about, or to wiretap his coworkers (assuming hosted PBX). The likely 
attack surface for a customer's confidentiality will be somewhere between that 
handset and you, and you have a means to protect that.

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

[VoiceOps] 605-562 - Arbitrage scam?

[Paul Timmins]

Is anyone else seeing lots of long duration calls to the 605-562 
exchange that when you dial the respective number, it supervises to dead 
air?


Seems like a new kind of toll fraud that international fraud detection 
systems won't catch.


-Paul

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

Re: [VoiceOps] 605-562 - Arbitrage scam?

[Paul Timmins]

Yeah, what makes it notable in this case is it seems like it's dead air 
calls and hacked phones like traditional international fraud, not free 
conference call services.


On 5/29/19 4:16 PM, Matthew Yaklin wrote:


Nevermind.. you meant interstate calling fraud detection systems I 
assume. Sorry. Please ignore me. I just reread again.



*Matthew Yaklin*
Network Engineer
*FirstLight*
359 Corporate Drive │ Portsmouth, NH 03801
Mobile 603-845-5031
myak...@firstlight.net | www.firstlight.net
/This email may contain FirstLight confidential and/or privileged 
information. If you are not the intended recipient, you are directed/
/not to read, disclose or otherwise use this transmission and to 
immediately delete same. Delivery of this message is not intended/

/to waive any applicable privileges./


*From:* VoiceOps  on behalf of Matthew 
Yaklin 

*Sent:* Wednesday, May 29, 2019 4:14:02 PM
*To:* Paul Timmins; voiceops@voiceops.org
*Subject:* Re: [VoiceOps] 605-562 - Arbitrage scam?

Paul,


Why do you mention international toll fraud when that is an area code 
and exchange for


Pine Ridge South Dakota?


And just imagining how small that company must be wouldn't a logical 
guess be more like they just messed up in some fashion?



But in your defense that telecom company is fishy and Sprint tried to 
sue them. I am not sure what ended up happening. Typical crap with 
free conf stuff and having traffic sent to a high cost area...





*Matthew Yaklin*
Network Engineer
*FirstLight*
359 Corporate Drive │ Portsmouth, NH 03801
Mobile 603-845-5031
myak...@firstlight.net | www.firstlight.net
/This email may contain FirstLight confidential and/or privileged 
information. If you are not the intended recipient, you are directed/
/not to read, disclose or otherwise use this transmission and to 
immediately delete same. Delivery of this message is not intended/

/to waive any applicable privileges./


*From:* VoiceOps  on behalf of Paul 
Timmins 

*Sent:* Wednesday, May 29, 2019 3:50:35 PM
*To:* voiceops@voiceops.org
*Subject:* [VoiceOps] 605-562 - Arbitrage scam?
Is anyone else seeing lots of long duration calls to the 605-562
exchange that when you dial the respective number, it supervises to dead
air?

Seems like a new kind of toll fraud that international fraud detection
systems won't catch.

-Paul

___
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] Connecting to Remote Tandems

[Paul Timmins]

Inteliquent has several products:

Outbound IXC termination - good for sending translated toll free calls. They 
give you money for sending the calls.
LTS - inbound and outbound local/local toll exchange with inteliquent members. 
Not an A-Z product, but the cheapest way to send calls to tmo/comcast/etc. You 
get the calls back through this too.
IXC terminating inbound - they become the tandem of record in the LERG for your 
interlata traffic. I think they give you a cut of the tandem transit fee they 
charge IXCs but it's been a while since I read the contract.
AIA - outbound LD product, not A-Z - super competitive rates to on-net carriers 
and a few others they get a deal on. If someone else uses this, it comes in the 
IXC terminating inbound and you bill inteliquent's CIC for the inbound inter 
carrier compensation where applicable. They make their money in not having to 
pay the tandem transit and other crap that an IXC would ordinarily pay to 
terminate, but they still pay the terminating carrier's inter carrier comp.

Local interconnection service - mostly for interconnected voip. You use their 
switches too interconnect. Not cheaper than doing it yourself, unless you don't 
already have a TDM switch and SS7 links and transport. If you lack either of 
the 3, it can work out financially.

-Paul



> On Aug 9, 2019, at 5:42 PM, Mike Hammett  wrote:
> 
> I wanted to note that I am still interested in working with competitive 
> tandem providers for "on-net" calls...  calls among their customers, without 
> ever hitting an ILEC tandem.
> 
> Also, now that I look at their web page...  it says it allows me to receive 
> both local and long distance calls using that service... which seems to 
> conflict with what the sales guy told me.  *sigh*
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com 
> 
> 
> 
> From: "Mike Hammett" 
> To: "VoiceOps" 
> Sent: Friday, August 9, 2019 2:42:37 PM
> Subject: [VoiceOps] Connecting to Remote Tandems
> 
> I'm evaluating methods of extending our footprint. I purposely left out 
> company names.
> 
> One of the companies we talked to was really only interested in getting us 
> the inbound long distance calls, not the local ones. Well, they would, but 
> the terms were vastly different.
> 
> Given that I still need to build out to connect to the local tandem, what's 
> the point in using a third party to connect to long distance?
> 
> Are the terms for connecting to the local tandems different because the 
> access tandem is simpler, whereas the local tandem could potentially involve 
> connections to a bunch of other switches, once volume dictated I needed 
> direct connections...  and they don't want to deal with that?
> 
> Are there third parties that don't have vastly different terms for local 
> tandem services?
> 
> Also, is it likely that I just don't understand what's going on? I went 
> circles with the sales rep to make sure I understood what he was saying, but 
> I could be wrong.
> 
> 
> 
> -
> 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 
> 
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Connecting to Remote Tandems

[Paul Timmins]

I'm sure I know which one you're talking about. It's because they exist 
in entirely different regulatory domains. The upside of inbound feature 
group D is that you get to cut out a terrible ILEC tandem, and at least 
the vendor I'm thinking of doesn't charge for the trunks themselves, so 
you're at a very strong cost advantage on it.


Inbound local trunking, usually interconnection agreements dictate that 
the trunks have to be dedicated per carrier, so you're just avoiding 
sinking hardware cost and transport, but it still uses up considerable 
resources at least in AT areas. So if you need 3 trunks to CHCGILWB's 
tandem, they can't just route that to their trunks where they have 
existing capacity, like FGD, but they have to install 3 shiny new T1s 
just for your traffic, that they order as you, to their equipment. It's 
stupid, convoluted, and wasteful but it's not the vendor's fault, it's 
AT maintaining artificial barriers to competition. As if they'd have 
it any other way.


-Paul

On 8/9/19 3:42 PM, Mike Hammett wrote:
I'm evaluating methods of extending our footprint. I purposely left 
out company names.


One of the companies we talked to was really only interested in 
getting us the inbound long distance calls, not the local ones. Well, 
they would, but the terms were vastly different.


Given that I still need to build out to connect to the local tandem, 
what's the point in using a third party to connect to long distance?


Are the terms for connecting to the local tandems different because 
the access tandem is simpler, whereas the local tandem could 
potentially involve connections to a bunch of other switches, once 
volume dictated I needed direct connections...  and they don't want to 
deal with that?


Are there third parties that don't have vastly different terms for 
local tandem services?


Also, is it likely that I just don't understand what's going on? I 
went circles with the sales rep to make sure I understood what he was 
saying, but I could be wrong.




-
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

Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

[Paul Timmins]

I see it as stopping fraud the same way SPF and DKIM stopped spam.

On 12/17/19 3:38 PM, Dovid Bender wrote:
Mike beat me to it. It's going to stop fraud. The bigger issue you are 
going to have is the larger packets. So many devices out there can't 
seem to fragment packets correctly.



On Tue, Dec 17, 2019 at 3:28 PM > wrote:


Hi Peter,

Good question.  First, if you're using Hooli, you'll have to
migrate to
Pipernet sooner or later.  Their middle-out compression provides
much better
call quality so it's worth the effort to migrate.

But to the issue you raised, the purpose of STIR/SHAKEN is not to
block
robocalls per se, it is to provide an authentication chain so that
you can
determine and contact the originating carrier regardless of the
route the
call took to reach the terminating side.  This has been a big
issue; many
VoIP companies hand off calls to large indifferent CLEC or IXCs
who send
them everywhere but won't respond to the terminating carrier's
fraud and
nuisance requests.

So, now we can see that the call was attested by Hooli, and if
Hooli does
not cooperate with our fraud/nuisance investigations we are now
authorized
to block traffic signed by Hooli.  That does fix the problem to a
large
degree.

However, it's also worthy of note that this is not the main
problem that
needs to be solved.  The main problem that needs to be solved is
the case
where you are sending the call to Hooli originating from a number
that is
assigned to our CLEC, which you don't have permission to use. This
does
solve that problem, because Hooli is only going to issue partial
attestation
for that call since it's not their number.  So we can still
contact Hooli
about it because they attested it and from that I can find them,
but we or
our subscriber can also block calls with partial attestations if
we/they
choose to.

Regards,

Mike

Mike Ray, MBA, CNE, CTE
Astro Companies, LLC
11523 Palm Brush Trail #401
Lakewood Ranch, FL  34202
DIRECT: call or text 941 600-0207
http://www.astrocompanies.com

-Original Message-
From: VoiceOps mailto:voiceops-boun...@voiceops.org>> On Behalf Of Peter Beckman
Sent: Tuesday, December 17, 2019 2:58 PM
To: VoiceOps mailto:voiceops@voiceops.org>>
Subject: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

A few months ago I attended an FCC STIR/SHAKEN discussion in
Washington DC.
They didn't get deep into the technical details but there were a
bunch of
big carrier representatives there.

If you haven't followed STIR/SHAKEN, it's really just an
additional SIP
header that contains cryptographically-signed information about
the origin
point of the call.

You can verify the signature with publically published public keys
so you
know whomever signed it is really them.

Here's a few resources if you want to learn more:

https://www.bandwidth.com/glossary/stir-shaken/
https://www.fcc.gov/call-authentication
https://en.wikipedia.org/wiki/STIR/SHAKEN
https://www.home.neustar/stir-shaken-resource-hub

There are three levels to tell you how much you should trust the
origin of
the call:

     1. Full -- The call came from the originating carrier's
customer and is
         authorized to use the number

     2. Partial -- The call came from the originating carrier's
customer but
         may or may not be authorized to use the number

     3. Gateway -- The carrier has authenticated from where it
received the
         call, but cannot authenticate the call source (e.g.,
International
         Gateway call).

As an example, as will be many legit cases, a Verizon Wireless mobile
customer will place a call, which will route to Verizon, who will
sign the
call using STIR/SHAKEN with Full Attestation and we can all
"trust" the
call.

But now we throw in VoIP.

I'm a small customer, Initech, of a larger carrier, Hooli. I don't
sign my
calls, so I hand my calls to my larger carrier, Hooli. Hooli sees
the call
from me (their customer) with a valid CallerID I'm authorized to
use and so
Hooli signs the call with STIR/SHAKEN with Full Attestation.

Turns out the call was a robocall.

What changes? The only thing that changes is that the receiving
party, say
Soylent Corp, knows that Hooli originated the call. Soylent is not
Hooli's
customer, so how does Soylent complain to Hooli about the content
of the
call?

And as carriers, we are not legally responsible for the content of our
customer's calls.

How will Soylent accept 90% of Hooli's Fully Attested valid
traffic but
avoid the 10% that is spam/robocalls that are ALSO 

Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

[Paul Timmins]

On 12/17/19 6:24 PM, Alex Balashov wrote:


There are many other reasons why SIP messages are getting bigger and
bigger, of which STIR/SHAKEN is not the first, second or fifth: other
standards, WebRTC interop, more/wideband codecs in SDP bodies,
SRTP(-SDES/DTLS), support for other features and standards, etc. So,
this problem needs to be dealt with one way or another and is pervasive
irrespectively of STIR/SHAKEN.

The solution, of course, is to use SIP over TCP.

-- Alex

Hell, it's worth it for the avoidance of cheap, stupid SIP ALGs* all by 
itself.


* Is there any other type? For that matter, is there actually someone 
who went HOT DAMN THANK GOD THIS ROUTER HAS SIP ALG let alone "THANK GOD 
ITS ON BY DEFAULT WITH THE SWITCH SNAPPED OFF"


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

Re: [VoiceOps] STIR/SHAKEN Discussion: Will it help?

[Paul Timmins]

> On Dec 19, 2019, at 12:09 AM, Peter Beckman  wrote:
> 
> Is STIR/SHAKEN not really completed and ready for deployment yet? The FCC
> and larger carriers seem to be moving forward with test implementations
> without of TN authorization and delegation.

Oh, thank goodness. I was worried for a second that we were being given a legal 
mandate to use a finished protocol specification. It's good to see that we're 
so worried about acting that the lack of completed standards is no obstacle. /s___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Three Digit Numbers

[Paul Timmins]

If people will use it I can spin up wiki.telcodata.us 
<http://wiki.telcodata.us/> and link to it from the main page. Interested? I 
could use mediawiki like Wikipedia does, or something else if people want.

> On Mar 25, 2020, at 12:45 PM, Mike Hammett  wrote:
> 
> Right. The "more details" is the part I'm looking to build a library of.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
> 
> 
> From: "Brandon Svec" 
> To: "Mike Hammett" 
> Cc: "Paul Timmins" , "Voiceops.org" 
> Sent: Wednesday, March 25, 2020 11:42:15 AM
> Subject: Re: [VoiceOps] Three Digit Numbers
> 
> NANPA defines normal uses for Nxx and refers to local regulators for more 
> details: 
> https://nationalnanpa.com/number_resource_info/n11_codes.html 
> <https://nationalnanpa.com/number_resource_info/n11_codes.html>
> 
> Security Made Simple with Cisco Meraki: http://bit.ly/MerakiSecure 
> <http://bit.ly/MerakiSecure>
> 
> Brandon Svec 
> CA C-7 Lic. #822064 
> <https://www.cslb.ca.gov/OnlineServices/CheckLicenseII/LicenseDetail.aspx?LicNum=822064>
> .ılı.ılı. Cisco Meraki CMNA
> 15106862204  voice | sms
> teamonesolutions.com <https://teamonesolutions.com/> 
> 
> 
> 
> 
> 
> On Wed, Mar 25, 2020 at 6:25 AM Mike Hammett  <mailto:voice...@ics-il.net>> wrote:
> Other than voip-info.org <http://voip-info.org/>, is there a voice-centric 
> WIKI out there that we may be able to crowd-source this information? I'd be 
> up for contributing the information I collect for my coverage area to some 
> central repository.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
> 
> 
> From: "Paul Timmins" mailto:p...@timmins.net>>
> To: "Mike Hammett" mailto:voice...@ics-il.net>>
> Cc: "Ken Mix" mailto:ken@clearfly.net>>, 
> voiceops@voiceops.org <mailto:voiceops@voiceops.org>
> Sent: Wednesday, March 25, 2020 8:15:39 AM
> Subject: Re: Three Digit Numbers
> 
> Definitely not. Especially with stuff like 2-1-1 which (at least in Michigan) 
> routes on the county level.
> 
> On Mar 25, 2020, at 8:06 AM, Mike Hammett  <mailto:voice...@ics-il.net>> wrote:
> 
> I take it there's no authoritative list of what geographies need to send what 
> N11 calls where?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
> 
> 
> From: "Ken Mix" mailto:ken@clearfly.net>>
> To: "Mike Hammett" mailto:voice...@ics-il.net>>, "Paul 
> Timmins" mailto:p...@timmins.net>>
> Cc: voiceops@voiceops.org <mailto:voiceops@voiceops.org>
> Sent: Tuesday, March 24, 2020 11:29:59 AM
> Subject: RE: Three Digit Numbers
> 
> If there's something standardized out there, I’d love to see a link to it. We 
> have a nationwide US footprint and had to build an internal system to handle 
> routing to 211, 311, 511, 711 & 811 based on calling number. It was a real 
> pain tracking down all of the numbers we need to translate to, though.
>  
> We’re a pretty small business-only carrier, and volume to non-911 N11 numbers 
> is low, but not insignificant. Current N11 call counts in 2020:
>  
> 211 - 270
> 311 - 82
> 511 - 67
> 711 - 34
> 811 - 323
>  
>  
> From: VoiceOps  <mailto:voiceops-boun...@voiceops.org>> On Behalf Of Mike Hammett
> Sent: Tuesday, March 24, 2020 09:25
> To: Paul Timmins mailto:p...@timmins.net>>
> Cc: voiceops@voiceops.org <mailto:voiceops@voiceops.org>
> Subject: Re: [VoiceOps] Three Digit Numbers
>  
> Are we supposed to be providing the intelligence in how to route those calls? 
> IE: Customer is in the City of Chicago, so route it to the city's Digger 10 
> digit, whereas if the customer is anywhere else in Illinois, route it to the 
> state's JULIE 10 digit?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
> 
>  
> From: "Paul Tim

Re: [VoiceOps] Three Digit Numbers

[Paul Timmins]

Definitely not. Especially with stuff like 2-1-1 which (at least in Michigan) 
routes on the county level.

> On Mar 25, 2020, at 8:06 AM, Mike Hammett  wrote:
> 
> I take it there's no authoritative list of what geographies need to send what 
> N11 calls where?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
> 
> 
> From: "Ken Mix" 
> To: "Mike Hammett" , "Paul Timmins" 
> Cc: voiceops@voiceops.org
> Sent: Tuesday, March 24, 2020 11:29:59 AM
> Subject: RE: Three Digit Numbers
> 
> If there's something standardized out there, I’d love to see a link to it. We 
> have a nationwide US footprint and had to build an internal system to handle 
> routing to 211, 311, 511, 711 & 811 based on calling number. It was a real 
> pain tracking down all of the numbers we need to translate to, though.
>  
> We’re a pretty small business-only carrier, and volume to non-911 N11 numbers 
> is low, but not insignificant. Current N11 call counts in 2020:
>  
> 211 - 270
> 311 - 82
> 511 - 67
> 711 - 34
> 811 - 323
>  
>  
> From: VoiceOps  On Behalf Of Mike Hammett
> Sent: Tuesday, March 24, 2020 09:25
> To: Paul Timmins 
> Cc: voiceops@voiceops.org
> Subject: Re: [VoiceOps] Three Digit Numbers
>  
> Are we supposed to be providing the intelligence in how to route those calls? 
> IE: Customer is in the City of Chicago, so route it to the city's Digger 10 
> digit, whereas if the customer is anywhere else in Illinois, route it to the 
> state's JULIE 10 digit?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
> 
>  
> From: "Paul Timmins" mailto:p...@timmins.net>>
> To: "Carlos Alvarez" mailto:caalva...@gmail.com>>
> Cc: voiceops@voiceops.org <mailto:voiceops@voiceops.org>
> Sent: Tuesday, March 24, 2020 10:14:18 AM
> Subject: Re: [VoiceOps] Three Digit Numbers
> 
> 711 and 811 have federal mandates to go to telecommunications relay service 
> and one call facilities flagging services respectively. Be careful about 
> working like that.
>  
> On Mar 24, 2020, at 11:10 AM, Carlos Alvarez  <mailto:caalva...@gmail.com>> wrote:
>  
> We don't handle any others in a traditional way.  Well, 611 is actually in 
> place, to our support line, but it has never once been used.  811 and 711 are 
> used for 911 testing without a real 911 call, as carriers mostly use those 
> for automated systems that return your 911 info.
>  
> On Tue, Mar 24, 2020 at 7:55 AM Mike Hammett  <mailto:voice...@ics-il.net>> wrote:
> What three digit numbers are commonly in use and how are people routing them?
>  
> Obviously there's 911 and that has a whole routing ecosystem.
> What about 811? 311? X11?
>  
>  
> What other special numbers are people handling?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com <http://www.ics-il.com/>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com <http://www.midwest-ix.com/>
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
> https://puck.nether.net/mailman/listinfo/voiceops 
> <https://puck.nether.net/mailman/listinfo/voiceops>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
> https://puck.nether.net/mailman/listinfo/voiceops 
> <https://puck.nether.net/mailman/listinfo/voiceops>
> 
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
> https://puck.nether.net/mailman/listinfo/voiceops 
> <https://puck.nether.net/mailman/listinfo/voiceops>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Analog Phone Lines - Timesouce for PBX System

[Paul Timmins]

A lot of older systems will set the clock from the incoming caller ID 
data - the time and date are in the stream of FSK along with the number 
and name. You'd want to make sure that ATA has valid time and timezones 
set, then send a call into them and the PBX should jump to the correct 
time and date


On 5/14/20 11:42 AM, Colton Conor wrote:
We had a customer that had Frontier Analog phone lines going into 
their Panasonic TDA-50 PBX system. We recently ported the numbers from 
Frontier to our Broadsoft, and deployed a Poly OBI508 ATA onsite. We 
also replaced their router and internet connection.


Customer is complaining that their phones are displaying the wrong 
time. We explained to them that we did not mess with their phone 
system PBX only the input lines.


My question is, do oldschool, onsite PBX systems, like a Panasonic 
TDA-50, use the analog FXS input lines from the provider (us) as a 
timing source? If so, what protocol is this, and where would be change 
it on the adapter?


I would think most PBX systems are like computers, and would use NTP 
as the timing source.




___
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] Toll Free Caller ID

[Paul Timmins]

1. What's the news on using TFN as a caller ID?
1. People have been doing it for years
2. Does this require a local charge number in P-Charge-Info or
   P_Asserted_Identity or elsewhere?
1. It does if you want calling other toll-free numbers or 911 to
   work, otherwise it doesn't really matter.
3. Has the FCC or anyone else approved TFN as ANI?
1. Does anyone need to?
4. Is TF ANI supported for STIR/SHAKEN?
1. If you have the certs, you can attest to whatever you want. It's
   designed to create accountability for originating carriers, not
   police numbering formats.


On 5/14/20 11:56 AM, Oren Yehezkely wrote:

Calvin,

I wonder if you got any insight to this question?

Regards,
Oren

On Tue, May 12, 2020 at 5:01 PM Calvin Ellison 
mailto:calvin.elli...@voxox.com>> wrote:


It looks like Somos is pushing TFN CNAM, press release below from
Mar 30, 2020. I've always understood TF ANI to be invalid.

What's the news on using TFN as a caller ID?
Does this require a local charge number in P-Charge-Info or
P_Asserted_Identity or elsewhere?
Has the FCC or anyone else approved TFN as ANI?
Is TF ANI supported for STIR/SHAKEN?


https://www.prnewswire.com/news-releases/toll-free-caller-id-information-helps-hhs-get-critical-phone-calls-answered-301031714.html



Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.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] Investigating random call completion issues nationwide

[Paul Timmins]

We've been seeing issues on outbound related to (supposedly) tandem overload in 
some areas through Verizon Business at a minimum, it would be unsuprising to 
see that affect incoming to other carriers, since by definition, it's outgoing 
calls from us to other carriers that are affected.

Verizon also mentioned something about a software licensing issue on something 
of their network.


> On Mar 19, 2020, at 7:29 PM, Darren Schreiber  wrote:
> 
> Hi folks,
> We’ve been getting occasional, very infrequent, reports of 
> people hitting busy signals or intercept messages when calling numbers routed 
> to us. At first we thought the issue was between us and Peerless but we now 
> have reports with bandwidth and Inteliquent. So, then of course naturally we 
> thought the issue was in our systems. But again, we’ve come up empty. We also 
> thought it may be trunk or port limitations upstream. Have checked those. No 
> dice.
>  
> The issue seems to always be the same. Customer from cell 
> phone or landline dials a number, reaches a busy signal or intercept message. 
> All reports are from Verizon or AT callers. We check our logs, don’t see 
> any attempt to even reach our system (we log freakin everything). So we reach 
> out to the upstream provider, and they too claim it never reached their 
> tandem/network.
>  
> I know everyone on earth is currently WFH so perhaps that 
> warrants just shutting up & dealing with it but I’ve been surprised not to 
> see any chatter on this list or elsewhere in this regard. Is anyone else 
> having indications of capacity issues (and are y’all just not talking about 
> it) or is it just us and we should keep looking?
>  
> - Darren
>  
> ___
> 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] Three Digit Numbers

[Paul Timmins]

711 and 811 have federal mandates to go to telecommunications relay service and 
one call facilities flagging services respectively. Be careful about working 
like that.

> On Mar 24, 2020, at 11:10 AM, Carlos Alvarez  wrote:
> 
> We don't handle any others in a traditional way.  Well, 611 is actually in 
> place, to our support line, but it has never once been used.  811 and 711 are 
> used for 911 testing without a real 911 call, as carriers mostly use those 
> for automated systems that return your 911 info.
> 
> On Tue, Mar 24, 2020 at 7:55 AM Mike Hammett  > wrote:
> What three digit numbers are commonly in use and how are people routing them?
> 
> Obviously there's 911 and that has a whole routing ecosystem.
> What about 811? 311? X11?
> 
> 
> What other special numbers are people handling?
> 
> 
> 
> -
> 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

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

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

Exactly that. The idea is collateral pain for misbehavior. Or attorneys 
general knocking on doors wondering why they're allowing robocalls 
through their network. Ideally both.


On 9/2/20 3:06 PM, Alex Balashov wrote:
That’s what I thought, thank you for clarifying. I was just confused 
because of the language in Paul’s previous explanation—no fault of his.


But in the bottom of the barrel, it will leave some folks with a 
conundrum about what to do when XYZTelecom sends their good 
conversational traffic through their peer A, and their crappier 
traffic through their peer B. But I suppose that is the very dilemma 
that this technique is meant to force.


—
Sent from mobile, with due apologies for brevity and errors.


On Sep 2, 2020, at 3:01 PM, Mark Lindsey  wrote:

SHAKEN doesn't record the chain (like you'd see with Via headers, 
for example) of Intermediate Providers who handle the call. There's 
only one Identity header and it is to be passed unchanged from the 
origin point to the terminating Voice Service Provider.


When the Identity header with PASSporT arrives at the final Voice 
Service Provider, that recipient can determine who created the 
PASSporT and then make judgments. For example, there has been a lot 
of discussion in FCC filings about "reputation" of service providers. 
Perhaps you could subscribe to a Reputation database to determine 
what to do with the calls.


For example, "This call got an A level attestation from XYZTelecom, 
but XYZTelecom has a 5% score in the reputation database, so I'm 
going to treat it as if this call is likely a nuisance call."




*Mark R Lindsey, SMTS**| **+1-229-316-0013|m...@ecg.co 
<mailto:m...@ecg.co>**|**https://ecg.co/lindsey/*

*
*



On Sep 2, 2020, at 2:52 PM, Alex Balashov <mailto:abalas...@evaristesys.com>> wrote:


Thank you, that’s very clear and sums it all up!

One lingering question: even without providing a fully attestable 
chain of custody, if the call took a route A -> B -> C, are 
signatures cumulative such that I could block calls attested by B 
coming through C? Or am I constrained to blocking a certain level of 
attestation only through the last/proximate peering hop (C) that 
directly touches me?


I suppose success is going to come down to the on-the-ground 
realities, political viability, etc of taking that “block attested 
calls from carrier X” step.


—
Sent from mobile, with due apologies for brevity and errors.

On Sep 2, 2020, at 2:47 PM, Paul Timmins <mailto:ptimm...@clearrate.com>> wrote:




The solution is that you sign your calls with your certificate. 
Carriers aren't doing LNP dips to verify the number is really 
yours, they're trusting your attestation (A: yes, the caller id is 
verified, B: it comes from our customer, but not verified, C: "this 
touched our switches, good luck with it"). If you attest total 
nonsense as A, or send tons of nonsense in general, people start 
blocking calls you sign.



It really verifies who is sending the call, and what that company 
says the call is verified, not a full chain of custody of the 
number back to the NANPA/PA. Could you attest A a call from "0" or 
"911", or "999-999-"? Yes, you could. It'd work for a while, 
til someone said "Wow, Alex's SPID is signing tons of bullshit. 
Let's block attested calls from his SPID"



-Paul




*From:* VoiceOps <mailto:voiceops-boun...@voiceops.org>> on behalf of Alex Balashov 
mailto:abalas...@evaristesys.com>>

*Sent:* Wednesday, September 2, 2020 2:42 PM
*To:* VoiceOps
*Subject:* Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
LCR or no LCR, using a termination vendor that is different to 
one’s origination vendor for a given CID is more normal than not in 
VoIP. I would guess it’s the default wholesale use-case. 
Origination and termination are very different business models with 
radically different economics.


I’m not clear on what the official STIR/SHAKEN solution to this is. 
I assume it’s delegated certificates as Jared suggested.


—
Sent from mobile, with due apologies for brevity and errors.

On Sep 2, 2020, at 2:39 PM, Carlos Alvarez <mailto:caalva...@gmail.com>> wrote:



If I understand correctly, no as long as your providers are all 
supporting this. What I think you mean is that you get 
origination/DIDs from say Bandwidth, and you use LCR to route 
calls to whoever is cheapest?  There are ways to work with that 
challenge as long as your carriers are ready to do so.


On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger <mailto:ja...@compuwizz.net>> wrote:


If we purchase our numbers through wholesalers, would we need
delegated certificates if we are sending an outbound call
through a vendor that is not the wholesaler we got the number
from?

On Wed, Sep 2, 2020 at 7:22 AM Dave

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

The solution is that you sign your calls with your certificate. Carriers aren't 
doing LNP dips to verify the number is really yours, they're trusting your 
attestation (A: yes, the caller id is verified, B: it comes from our customer, 
but not verified, C: "this touched our switches, good luck with it"). If you 
attest total nonsense as A, or send tons of nonsense in general, people start 
blocking calls you sign.


It really verifies who is sending the call, and what that company says the call 
is verified, not a full chain of custody of the number back to the NANPA/PA. 
Could you attest A a call from "0" or "911", or "999-999-"? Yes, you could. 
It'd work for a while, til someone said "Wow, Alex's SPID is signing tons of 
bullshit. Let's block attested calls from his SPID"


-Paul



From: VoiceOps  on behalf of Alex Balashov 

Sent: Wednesday, September 2, 2020 2:42 PM
To: VoiceOps
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

LCR or no LCR, using a termination vendor that is different to one’s 
origination vendor for a given CID is more normal than not in VoIP. I would 
guess it’s the default wholesale use-case. Origination and termination are very 
different business models with radically different economics.

I’m not clear on what the official STIR/SHAKEN solution to this is. I assume 
it’s delegated certificates as Jared suggested.

—
Sent from mobile, with due apologies for brevity and errors.

On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:


If I understand correctly, no as long as your providers are all supporting 
this.  What I think you mean is that you get origination/DIDs from say 
Bandwidth, and you use LCR to route calls to whoever is cheapest?  There are 
ways to work with that challenge as long as your carriers are ready to do so.

On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger 
mailto:ja...@compuwizz.net>> wrote:
If we purchase our numbers through wholesalers, would we need delegated 
certificates if we are sending an outbound call through a vendor that is not 
the wholesaler we got the number from?

On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen 
mailto:dfri...@wabash.net>> wrote:
There is a STIR-SHAKEN process of registering and testing with the Policy
Administrator (PA) as a certified Service Provider (SP) before you can
purchase SHAKEN token certificates from a Certificate Authority (CA) and
begin to engage in using the technology. This is not a walk in the park.
Transnexus is one of two public CA's in the U.S. today. They are experts on
the subject and can help you through both processes. In order to get the
best call attestation you must prove to the PA and CA that you are a bono
fide service provider and not a bad-acting enterprise on a network that
deserves lesser attestation levels.

One of the registration requirements is a SP 's access to valid national
phone number pools. This has been very confusing for some resale providers
that purchase and use numbers from wholesalers only. If your organization
does not have it's own numbering resources, you can register using your
wholesale provider's numbering pool data. Don't assume you have to register
with the FCC and possess your own pool of numbers to become a registered
SHAKEN SP.

SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
attestation level possible for a SP is essential to the SP and the SHAKEN
ecosystem. Register and test for the best attestation level possible.
Transnexus is a seasoned expert on the subject and a U.S. registered CA with
the PA.

Dave


-Original Message-
From: VoiceOps 
mailto:voiceops-boun...@voiceops.org>> On Behalf 
Of Mary Lou Carey
Sent: Tuesday, September 1, 2020 5:36 PM
To: Dovid Bender mailto:do...@telecurve.com>>
Cc: Voiceops.org mailto:voiceops@voiceops.org>>
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless and
VOIP carriers install and maintain their PSTN networks for the the last 20
years. I can help clients get their FCC Certification to become a
STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training, etc
(if you need those pieces). Once my clients get their certification, I refer
them to TransNexus. Jim and his team can help you with the process of
turning your STIR/SHAKEN services up.

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2020-08-31 05:37 AM, Dovid Bender wrote:
> Hi,
>
> Does anyone have a recommendation for a company that get us everything
> needed for STIR/SHAKEN setup? By setup I mean helping us file to get a
> cert etc. From the small research I have done there is a lot of
> fragmented information out there and it would be easier for us to pay
> someone else to do this then invest our own time to take care of this.
>
> TIA.
>
> Regards,
>
> Dovid
> ___
> VoiceOps mailing list
> 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

Once signed, you just pass it on with its existing signature. Only the 
originator signs it. It could technically have multiple headers, but 
that's not the intent.


As for on the ground realities, I can only point out that out of 8008 
possibly signed inbound calls in the last 24 hours (only my intelliquent 
SIP trunks have the ability to pass the identity header right now):

319 have attest A,
None have attest B,
2 have Attest C

310 of the calls were T-Mobile, 5 were comcast, and 6 were other.

Out of the last 10,000 calls I have originated toward the STIR/SHAKEN 
routes (which covers about 2 hours), I signed:

2643 have attest A
4695 have attest B (this is our default where I haven't explicitly 
verified the customer is only sending numbers that are theirs)
244 have attest C (this gets triggered if there's a header indicating 
the call was redirected)


It's really not as complicated as people are making it out to be. 
Transnexus has been great to work with, as has Inteliquent.


-Paul



On 9/2/20 2:52 PM, Alex Balashov wrote:

Thank you, that’s very clear and sums it all up!

One lingering question: even without providing a fully attestable 
chain of custody, if the call took a route A -> B -> C, are signatures 
cumulative such that I could block calls attested by B coming through 
C? Or am I constrained to blocking a certain level of attestation only 
through the last/proximate peering hop (C) that directly touches me?


I suppose success is going to come down to the on-the-ground 
realities, political viability, etc of taking that “block attested 
calls from carrier X” step.


—
Sent from mobile, with due apologies for brevity and errors.


On Sep 2, 2020, at 2:47 PM, Paul Timmins  wrote:



The solution is that you sign your calls with your certificate. 
Carriers aren't doing LNP dips to verify the number is really yours, 
they're trusting your attestation (A: yes, the caller id is verified, 
B: it comes from our customer, but not verified, C: "this touched our 
switches, good luck with it"). If you attest total nonsense as A, or 
send tons of nonsense in general, people start blocking calls you sign.



It really verifies who is sending the call, and what that company 
says the call is verified, not a full chain of custody of the number 
back to the NANPA/PA. Could you attest A a call from "0" or "911", or 
"999-999-"? Yes, you could. It'd work for a while, til someone 
said "Wow, Alex's SPID is signing tons of bullshit. Let's block 
attested calls from his SPID"



-Paul




*From:* VoiceOps  on behalf of Alex 
Balashov 

*Sent:* Wednesday, September 2, 2020 2:42 PM
*To:* VoiceOps
*Subject:* Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
LCR or no LCR, using a termination vendor that is different to one’s 
origination vendor for a given CID is more normal than not in VoIP. I 
would guess it’s the default wholesale use-case. Origination and 
termination are very different business models with radically 
different economics.


I’m not clear on what the official STIR/SHAKEN solution to this is. I 
assume it’s delegated certificates as Jared suggested.


—
Sent from mobile, with due apologies for brevity and errors.


On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:


If I understand correctly, no as long as your providers are all 
supporting this.  What I think you mean is that you get 
origination/DIDs from say Bandwidth, and you use LCR to route calls 
to whoever is cheapest?  There are ways to work with that challenge 
as long as your carriers are ready to do so.


On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger <mailto:ja...@compuwizz.net>> wrote:


If we purchase our numbers through wholesalers, would we need
delegated certificates if we are sending an outbound call
through a vendor that is not the wholesaler we got the number from?

On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen mailto:dfri...@wabash.net>> wrote:

There is a STIR-SHAKEN process of registering and testing
with the Policy
Administrator (PA) as a certified Service Provider (SP)
before you can
purchase SHAKEN token certificates from a Certificate
Authority (CA) and
begin to engage in using the technology. This is not a walk
in the park.
Transnexus is one of two public CA's in the U.S. today. They
are experts on
the subject and can help you through both processes. In
order to get the
best call attestation you must prove to the PA and CA that
you are a bono
fide service provider and not a bad-acting enterprise on a
network that
deserves lesser attestation levels.

One of the registration requirements is a SP 's access to
valid national
phone number pools. This has been very confusing for some
resale provide

Re: [VoiceOps] Question about SS7 routing

[Paul Timmins]

You only send calls to point codes you're connected to with ISUP trunks (what 
is a control network without bearer channels?), so you don't really do it that 
way. You would look at your usual LCR/routing table, and the adjacent switch 
you want to pass it to, be it a local end office, feature group D regional ILEC 
tandem, or long distance carrier wholesale circuit, and you would send it to 
the point code of the switch you're connected to that is the appropriate next 
hop for the call.



From: VoiceOps  on behalf of Ross Tajvar 

Sent: Wednesday, September 2, 2020 5:46 PM
To: VoiceOps
Subject: [VoiceOps] Question about SS7 routing

Hi all,

I'm trying to understand how routing works in SS7-land. I am familiar with 
portability, and I know (at least in the US) the first step in routing a call 
is doing an LNP dip to get the LRN.

However, it looks like addresses in MTP3 are "point codes" (PCs) which are 
assigned to switches. Calls are set up with ISDN-UP, which is transported via 
MTP3. So in order for a call to be set up, the destination switch's PC must be 
known. How is the destination PC determined from the destination LRN?

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

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

In practice i can sign anything and it properly flags on comcast and tmo. There 
are totally legitimate circumstances (like forwarding a call) where you might 
attest C a call that isn't sourced from a number you own.



From: VoiceOps  on behalf of Jared Geiger 

Sent: Wednesday, September 2, 2020 2:27 PM
To: Voiceops.org
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

If we purchase our numbers through wholesalers, would we need delegated 
certificates if we are sending an outbound call through a vendor that is not 
the wholesaler we got the number from?

On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen 
mailto:dfri...@wabash.net>> wrote:
There is a STIR-SHAKEN process of registering and testing with the Policy
Administrator (PA) as a certified Service Provider (SP) before you can
purchase SHAKEN token certificates from a Certificate Authority (CA) and
begin to engage in using the technology. This is not a walk in the park.
Transnexus is one of two public CA's in the U.S. today. They are experts on
the subject and can help you through both processes. In order to get the
best call attestation you must prove to the PA and CA that you are a bono
fide service provider and not a bad-acting enterprise on a network that
deserves lesser attestation levels.

One of the registration requirements is a SP 's access to valid national
phone number pools. This has been very confusing for some resale providers
that purchase and use numbers from wholesalers only. If your organization
does not have it's own numbering resources, you can register using your
wholesale provider's numbering pool data. Don't assume you have to register
with the FCC and possess your own pool of numbers to become a registered
SHAKEN SP.

SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
attestation level possible for a SP is essential to the SP and the SHAKEN
ecosystem. Register and test for the best attestation level possible.
Transnexus is a seasoned expert on the subject and a U.S. registered CA with
the PA.

Dave


-Original Message-
From: VoiceOps 
mailto:voiceops-boun...@voiceops.org>> On Behalf 
Of Mary Lou Carey
Sent: Tuesday, September 1, 2020 5:36 PM
To: Dovid Bender mailto:do...@telecurve.com>>
Cc: Voiceops.org mailto:voiceops@voiceops.org>>
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless and
VOIP carriers install and maintain their PSTN networks for the the last 20
years. I can help clients get their FCC Certification to become a
STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training, etc
(if you need those pieces). Once my clients get their certification, I refer
them to TransNexus. Jim and his team can help you with the process of
turning your STIR/SHAKEN services up.

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2020-08-31 05:37 AM, Dovid Bender wrote:
> Hi,
>
> Does anyone have a recommendation for a company that get us everything
> needed for STIR/SHAKEN setup? By setup I mean helping us file to get a
> cert etc. From the small research I have done there is a lot of
> fragmented information out there and it would be easier for us to pay
> someone else to do this then invest our own time to take care of this.
>
> TIA.
>
> Regards,
>
> Dovid
> ___
> 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] TNS Outage?

[Paul Timmins]

We use them for CNAM/LNP/TF lookups and aren't seeing issues. We don't get our 
A Links from them though.


From: VoiceOps  on behalf of randal k 

Sent: Wednesday, September 9, 2020 3:03 PM
To: VoiceOps
Subject: [VoiceOps] TNS Outage?

We have redundant A-Links to TNS and both are hard down. Ticket is
open, but no ETR. Anybody have an idea what's happening?
___
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] Got my first inbound call with a STIR/SHAKEN checkmark

[Paul Timmins]

Can you imagine AT or Verizon actually doing IP interconnect in a 
meaningful way? I'm not holding my breath.


(he says, as he made a test call today to another small/medium sized 
CLEC with their newly minted STIR/SHAKEN services today, and passes tons 
of calls to T-Mo and comcast with the checkmark on them)


I'm not sure how long it'll take before we see useful activity out of 
the monopolies on this one, but i get this feeling we'll all beat them 
to it.


FWIW, Sprint isn't sending it across to Inteliquent yet.

On 9/9/20 5:10 PM, Brandon Svec wrote:
I had noticed this for T-Mobile and Comcast for several months.  
Interesting to hear Sprint is on board now too.  Probably/possibly due 
to merger.  Any bets on the next "big" provider?  at, Verizon, ?

*Brandon Svec*
*15106862204  voice|sms
**teamonesolutions.com *



On Wed, Sep 9, 2020 at 1:33 PM Jared Geiger > wrote:


I got my first validated call today from a Sprint subscriber to a
T-Mobile subscriber. Presents with a tiny check mark in the Missed
Calls tab on my iPhone. Unfortunately the originating party
misdialed my number.

Tested later on T-Mobile to T-Mobile and got a checkmark in the
missed calls list but not on the screen during the call
notification. Maybe due to the number being in the Contacts list
already.

~Jared
___
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] Question about SS7 routing

[Paul Timmins]

  1.  You route it to the one that's least expensive, or provides the highest 
quality, or whatever your target market is. This part's really up to you and 
it's part of the differentiator of your product.
  2.  Apply for the blocks with NANPA/National Pooling after getting all the 
right licensure, interconnection agreements with whoever the local tandems are 
run by, then make a relationship with an AOCN (NANPA runs one) that can input 
your blocks into the LERG.
  3.  Reach out to your local tandem operators before doing this to work out 
the finer details of routing inbound calls. There are usually the local ILEC, 
but there are alternative tandem providers such as Inteliquent.
  4.  Realize that regardless, you may have to connect with many tandems, and 
several local phone companies to get proper inbound coverage for your numbers. 
Connecting in the Chicago LATA, this can be something like a minimum of 10-11 
T1s to various tandems and trunk groups, in the Upper Penninsula of Michigan 
this could be two T1s to Marquette, MI, one for local/intralata calling, one 
for interlata calls.

-Paul




From: Ross Tajvar 
Sent: Wednesday, September 2, 2020 6:10 PM
To: Paul Timmins
Cc: VoiceOps
Subject: Re: [VoiceOps] Question about SS7 routing

I see, that makes sense. So then I have two follow-up questions:

  1.  If you are connected to multiple carriers, e.g. multiple long distance 
carriers, how do you populate your routing table? (Obviously "it depends" but 
I'd be interested to hear an example.)
  2.  If you are setting up equipment for the first time, with a new number 
block, how do you make sure other people include you/your block in their 
routing tables?

On Wed, Sep 2, 2020 at 5:56 PM Paul Timmins 
mailto:ptimm...@clearrate.com>> wrote:

You only send calls to point codes you're connected to with ISUP trunks (what 
is a control network without bearer channels?), so you don't really do it that 
way. You would look at your usual LCR/routing table, and the adjacent switch 
you want to pass it to, be it a local end office, feature group D regional ILEC 
tandem, or long distance carrier wholesale circuit, and you would send it to 
the point code of the switch you're connected to that is the appropriate next 
hop for the call.



From: VoiceOps 
mailto:voiceops-boun...@voiceops.org>> on behalf 
of Ross Tajvar mailto:r...@tajvar.io>>
Sent: Wednesday, September 2, 2020 5:46 PM
To: VoiceOps
Subject: [VoiceOps] Question about SS7 routing

Hi all,

I'm trying to understand how routing works in SS7-land. I am familiar with 
portability, and I know (at least in the US) the first step in routing a call 
is doing an LNP dip to get the LRN.

However, it looks like addresses in MTP3 are "point codes" (PCs) which are 
assigned to switches. Calls are set up with ISDN-UP, which is transported via 
MTP3. So in order for a call to be set up, the destination switch's PC must be 
known. How is the destination PC determined from the destination LRN?

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

Re: [VoiceOps] Charter/Spectrum Port Out?

[Paul Timmins]

Have you guys filed a State PUC complaint? I've seen same day resolution 
on that stuff sometimes.


On 6/18/20 5:48 PM, jd wrote:


I’m having this same issue with ringcentral, nobody is answering me 
and they’re claiming to not even see the port request, it’s just rejected.


There must be better protection here, ringcentral is raking in a lot 
of money on something that isn’t used and they know it..


*From:*VoiceOps [mailto:voiceops-boun...@voiceops.org] *On Behalf Of 
*Aaron C. de Bruyn via VoiceOps

*Sent:* Wednesday, June 17, 2020 10:56 AM
*To:* voiceops@voiceops.org
*Subject:* [VoiceOps] Charter/Spectrum Port Out?

Is there anyone at Charter/Spectrum (Oregon area) that can help with a 
port out?


It's been rejected 5 times now.

Every time I call in, the rep gives me a slightly different variation 
of the address to re-submit.


The winning carrier keeps getting rejected and asks for a CSR copy.  
Charter/Spectrum flat-out tells me "we don't do CSR reports for small 
business customers" and then proceeds to give me a slightly different 
version of the address every time I call in.


They absolutely refuse to let me talk to or communicate with the team 
that actually makes the accept/reject decision to find out why.  They 
simply say "it was rejected because of the address".


I've spent hours on the phone over the last few weeks and I'm getting 
nowhere.


Thanks,

-A


___
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] Production STIR/SHAKEN

[Paul Timmins]

Is anyone but T-Mobile and Comcast (and now us) doing STIR/SHAKEN right now and 
want to make test calls? We're on Inteliquent if that helps.

-Paul



Paul Timmins
Senior Network Engineer
Clear Rate Communications
Direct: (248) 556-4532
Customer Support: (877) 877-4799
24 Hour Repair: (866) 366-4665
Network Operations: (877) 877-1250
www.clearrate.com

This message contains confidential information intended only for the use of the 
intended recipient(s) and may contain information that is privileged. If you 
are not the intended recipient, or the person responsible for delivering it to 
the intended recipient, you are hereby notified that reading, disseminating or 
copying this message is strictly prohibited.

If you have received this message by mistake, please immediately send 
notification by replying to the message, indicate the message was received by 
mistake, and then delete the original message immediately thereafter. Thank you.

Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.


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

Re: [VoiceOps] Area code 886

[Paul Timmins]

11xx codes are a pulse dial substitute for the matching *xx code. so 1167 sets 
the privacy flag just like *67 does. They're not dialable outside of a class 5 
end user.

(12xx replaces the #)



From: VoiceOps  on behalf of Jared Geiger 

Sent: Friday, July 24, 2020 1:51 PM
To: VoiceOps
Subject: Re: [VoiceOps] Area code 886

Semi related:

Depending on the International vendor, I see the codes 108, 109, 1129, 1139, 
1171, 1172, 1173, 1178 being claimed as either valid codes in Canada or the US. 
I haven't found much information on them but I believe they are special in 
Canada dial codes for certain services and would likely never complete if a 
call originated outside of the country.

Watch out for those in ratesheets if your customers dial the 011 prefix for an 
International call, it may confuse your LCR/rating engine.

~Jared

On Fri, Jul 24, 2020 at 10:09 AM John R Levine 
mailto:jo...@taugh.com>> wrote:
> I think you misread that 886 is reserved for TF. It was released from TF 
> reservation in 2003 and us currently unassigned so could pop up anywhere as a 
> new code.

If that is the case, you should tell NANPA.  I just downloaded their NPA
database, dated today.  It says:

NPA_ID,type_of_code,ASSIGNABLE,EXPLANATION,RESERVED,ASSIGNED,ASSIGNMENT_DT,USE,LOCATION,COUNTRY,IN_SERVICE,IN_SERVICE_DT,STATUS,PLANNING_LETTERS,"NOTES",OVERLAY,OVERLAY_COMPLEX,PARENT_NPA_ID,SERVICE,TIME_ZONE,AREA_SERVED,MAP,IN_JEOPARDY,RELIEF_PLANNING_IN_PROGRESS,HOME_NPA_LOCAL_CALLS,HOME_NPA_TOLL_CALLS,FOREIGN_NPA_LOCAL_CALLS,FOREIGN_NPA_TOLL_CALLS,PERM_HNPA_LOCAL_CALLS,PERM_HNPA_TOLL_CALLS,PERM_HNPA_FOREIGN_LOCAL_CALLS,"DIALING_PLAN_NOTES"
886,General Purpose Code,No,Set aside for toll 
free,No,No,,N,,,N"",No,,,Toll-FreeNo,No""

R's,
John


>> On Jul 24, 2020, at 9:22 AM, John Levine 
>> mailto:jo...@taugh.com>> wrote:
>>
>> In article 
>> mailto:aazodf_9-eqevho93w-dw...@mail.gmail.com>>
>>  you write:
>>> Does anyone know if area code 886 was allocated to Canada and if yes where
>>> in Canada? We were just told by an international vendor that it is a new
>>> area code in Canada yet I can't find anything on it.
>>
>> You can check the definitive NANPA list at https://nationalnanpa.com/
>>
>> It says that 886 is reserved for toll-free expansion. Your vendor is
>> confused.
>>
>> A long time ago, codes 880, 881, and 882 were used for paid
>> international calls to North American 800, 888, and 877 numbers, so
>> they might be telling you a garbled version of that. That hack went
>> away 15 years ago and those codes are now also reserved for toll-free
>> expansion.___
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] Production STIR/SHAKEN

[Paul Timmins]

T-Mobile is using PA certificates, I'm passing live traffic with them right 
now. What I've heard so far intercarrier is just Comcast (private cert), 
T-Mobile (STI-PA cert), Twilio (not sure), and us (STI-PA cert). Verizon and 
AT have just been doing private interconnect from what I understand.


-Paul



From: VoiceOps  on behalf of Dave Frigen 

Sent: Monday, July 27, 2020 3:49 PM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] Production STIR/SHAKEN


Paul, this is in reply to your question posted on July 24th: Currently there 
are 34 active STI-GA SHAKEN participants authorized to exchange SHAKEN tokens 
in the U.S. While Canada and the UK are working on SHAKEN, to my knowledge 
there are no PA’s or CA’s to operate and approve new applicants in those 
countries.



T-Mobile, Comcast, Verizon, and AT were the first four carriers to adopt 
SHAKEN and are still temporarily using self-signed certificates (not official 
PA authored certificates that Transnexus and the rest of the U.S. uses). This 
is due to FCC expectations of having a SHAKEN platform in production at the 
beginning of the year and there not being a PA (Policy Administrator), nor any 
CA’s (Certificate Authorities) at that time. Self-signing certificates were the 
only means of operating the SHAKEN platform in the FCC timeframe. We, as 
out-of-band (OOB) operators do not have the ability to exchange certs. 
(certificates) with the self-signers today. It goes without saying that these 
networks are huge and not easily converted. T-Mobile and Comcast are in the 
process of converting to official PA authored certificates, they are expected 
to be on-line in the coming month. Both AT and Verizon are in the engineering 
stages and planning to convert in the future. I reside on a board seat of the 
national STI-GA governance board as an NTCA representative, and have asked the 
self-signers to begin publishing their self-signing root addresses so every can 
exchange tokens in the interim regardless of whether or not they are official 
PA authored certs. I anticipate self-signing certs going away, and likely 
within the coming months. In summary, we, as out-of-band (OOB) operators, do 
not have the ability to exchange certs. with the self-signers today, hopefully 
they will agree to publish their root certificate addresses soon.



I want to prequalify this next statement by congratulating any TDM provider 
that is adopting OOB or some sort of TDM SHAKEN technology. You’re doing the 
right thing, because TDM isn’t going away anytime soon. And all Americans 
deserve the right to have their calls officially authenticated and verified 
just like any iP network provider’s calls. OOB and other technologies for use 
on TDM calls for SHAKEN are in the infant stages and are just now being 
discussed and considered for permanent TDM standards. The body that is adopting 
new TDM standards is the PTSC Non-IP Call Authentication Task Force, led by 
ATIS. Anyone is welcome to become a member of the task force. There is a 
nominal $250 fee for organizations that are not already an ATIS member. If you 
want more information on how to join the committee, I’d be glad to help. 
Belonging to the committee is one of many ways to comply with the FCC’s mandate 
for TDM providers to adopt SHAKEN.



As to the original question of who to test OOB with, Transnexus to Transnexus 
will allow for both authentication and verification testing; or Transnexus to 
Netnumber or Neustar. These would be OOB to OOB calls. Regarding OOB to IP, or 
the reverse……it’s my understanding that OOB to in-band will only work one way 
today. OOB can authenticate a PA certificate that in-band can receive. HTTP 
Post software or a Call Placement Service (CPS) is required for an IP provider 
to post a token to an OOB provider. With that being said, Wabash is a 
Transnexus customer and would be more than happy to test OOB SHAKEN with any 
provider desiring to do so. Let me know and I’ll get you in touch with our 
engineers.



Lastly, I’d like to add that Wabash originally implemented OOB SHAKEN into a 
C-15 with no CapEx, just existing translations modifications. After running the 
Transnexus/ClearIP platform for a while, we decided to upgrade our SBC to a 
cloud solution for under $100 a month, but to date that is our only capital 
expense to be OOB SHAKEN enabled. So, don’t let your switch vendor insist that 
you break-the-bank to operate OOB.



Dave







Dave Frigen

Chief Operating Officer

Wabash Communications CO-OP | www.wabash.net

Office: 618.665.3311



[cid:image001.png@01D66409.4059F990][cid:image002.png@01D66409.4059F990][cid:image003.png@01D66409.4059F990]
 [cid:image004.png@01D66409.4059F990] 

Re: [VoiceOps] Can carriers still refuse port-outs if an account is being closed?

[Paul Timmins]

Port the entire account with the remark "disconnect all remaining 
services" in the remarks field of the LSR. Send the carrier nothing from 
the customer.


On 7/22/20 4:02 PM, Carlos Alvarez wrote:
The customer said they tried to do that, but was told that they can 
either cancel the account in full, or not, but can't cancel the renewal.


Even if they do, it leaves the question of being billed for one more 
month of service they won't be using.



On Wed, Jul 22, 2020 at 12:55 PM Paul Timmins <mailto:p...@timmins.net>> wrote:


Send a letter cancelling the autorenewal, allowing it to go month
to month. Then port it.

On 7/22/20 3:43 PM, Carlos Alvarez wrote:

We've had issues in the long past where ILECs in particular would
refuse a port-out for "pending orders" if they had received a 30
day notice of cancellation.  This basically would help get them
an extra month of revenue.  We have a customer whose service
renews in a few days for another year, if they don't cancel.  If
we enter a port order today, and they give a 30 day notice
tomorrow, could that port be blocked?


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



___
VoiceOps mailing list
VoiceOps@voiceops.org <mailto: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] Can carriers still refuse port-outs if an account is being closed?

[Paul Timmins]

Send a letter cancelling the autorenewal, allowing it to go month to 
month. Then port it.


On 7/22/20 3:43 PM, Carlos Alvarez wrote:
We've had issues in the long past where ILECs in particular would 
refuse a port-out for "pending orders" if they had received a 30 day 
notice of cancellation.  This basically would help get them an extra 
month of revenue.  We have a customer whose service renews in a few 
days for another year, if they don't cancel.  If we enter a port order 
today, and they give a 30 day notice tomorrow, could that port be 
blocked?



___
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] Definition: Local Calls

[Paul Timmins]

Local calling areas are defined in the CLEC tariff filed with the state. 
Most CLECs mirror the ILEC local calling areas. Check your tariffs to 
see what the PUC approved you to do.


On 12/8/20 12:35 PM, Mike Hammett wrote:

Is there any legal definition as to what constitutes local calls?

I know that Local Calling Guide reports on what the ILECs treat as 
local, but I don't know if there's anything that is requiring me to 
have the same definition.



My operating theory is that if it's on the same tandem switch, I might 
as well treat it as local.



For reporting purposes (state and federal) would local calls be 
treated as intrastate calls when not otherwise broken out?




-
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

Re: [VoiceOps] Verizon Wireless Porting

[Paul Timmins]

https://www.syniverse.com/customer-support-resources 


Contact the trading partner contact to set up an agreement with the carriers. 
They all use Syniverse Port Out GUI.

> On Nov 24, 2020, at 2:50 PM, Mike Hammett  wrote:
> 
> Does anyone know where to go at Verizon Wireless to get set up for porting? 
> My Google-fu seems to be lacking.
> 
> 
> 
> -
> 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

Re: [VoiceOps] STIR/SHAKEN for call centers

[Paul Timmins]

On 12/2/20 4:49 PM, Patrick Labbett wrote:


However, it's not clear (to me) how the Attestation aspect of things 
will work (and if it even effects the typical customer):


  * Does just being a customer of the Originating Carrier give the
Call Center's calls Full Attestation?

That depends on the originating carrier's policies. They could attest A 
a number that they've verified to be yours.


  * As a call center, if spoofing a number not owned/in inventory,
would that be Partial Attestation?

That depends on the originating carrier's policies. They could attest A 
a number that they've verified to be yours. Otherwise, they would attest 
B because they could verify the origin of the call, but not the accuracy 
of the caller ID.


  * Does the owner/location of the spoofed number matter, i.e. :
  o Partial Attestation: Number owned by Originating carrier, but
not by customer making call
  o Gateway Attestation: Number not owned by Originating carrier
(and by extension not owned by customer making the call)

We mark forwarded calls as C, paying customers B, and customers we've 
taken the time to verify their ID as A. Some carriers do only A and C 
since customers can't specify their own caller ID (such as Comcast 
residential voice, or cell carriers)


  * Will different Terminating carriers treat Attestation designations
differently?

Of course! My T-Mobile phone doesn't display signed calls in any 
specific way, but others may. Our customers get a [V] in front of the 
caller ID with name data if we verified attestation A, nothing for any 
other form of attestation or no validation at all.


  * Is this largely a framework that carriers will implement some day
in the future?

The standards for how we treat this stuff are loose to give carriers 
flexibility in how they convey it to the customers.

Am I way overthinking this? (Yes.)


Not nearly as bad as many!

My personal plan of attack for call centers:


  * Document permission and business use case for numbers spoofed on
behalf of customers
  * That's it - that's the whole plan.
  * 

Aside from making sure my carriers know I exist and that I have 
permission to use those numbers, what else is there?


Sounds good to me. For a lot of carriers, a simple explanation they can 
easily verify (like you call the number, and they answer with your 
client's name) is probably adequate.


-Paul


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

Re: [VoiceOps] SS7 problems

[Paul Timmins]

The part of the company to call depends on what part of the company 
those trunks come from. Contact your AT account manager.


If they're IXC circuits, https://primeaccess.att.com/shell.cfm?section=4343

On 12/21/20 10:56 AM, Dave Frigen wrote:


We’ve narrowed this down to calls completing on our facilities (from 
likely least cost routing) down an AT TDM/SS7 terminating trunk 
group. We have no contacts for this trunk group, and even turned the 
trunk group down for a day thinking we would get a call, but didn’t. 
We’re still getting two calls to a single number, one call with caller 
on it and the other with dead air. The dual calls are coming from 
various service providers on this trunk group.


Anyone have any suggestions?

Dave

*From:* Dave Frigen 
*Sent:* Friday, December 11, 2020 11:55 AM
*To:* 'voiceops@voiceops.org' 
*Cc:* 'Rodney Young' ; 'Don Ross' 
; 'Barry Adair' 

*Subject:* SS7 problems

I know SS7 is not a big part of the voice world for many of you, but 
for those of you still exposed to it, just curious if anyone 
experienced any problems with SS7 signaling in the past couple of days 
where Terminating signaling times out and a 2^nd retry and new call 
set up for the call delivery occurs. The result was the phone ringing 
the customer, no one there. Second attempt successfully (if multiline 
hunt group) comes in on next line/trunk.


Trouble tickets reported:  Customers complaining about phones ringing, 
no one on the other end.


We traced the issue upstream in the SS7 signaling. The signaling was 
timing out after 15 seconds, creating call retry. We had our SS7 
provider look into it. No trouble found, but the “gremlins” 
mysteriously disappeared after the testing……concerned trouble may reoccur.


Any reference to anyone else experiencing these issues recently would 
be appreciated.


Dave

*Dave Frigen*

*/Chief Operating Officer /*

Wabash Communications CO-OP | www.wabash.net 

Office: 618.665.3311

 



WabashCom_CO-OP_RGB.png 


___
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 STIR/SHAKEN Consultants

[Paul Timmins]

Working with TransNexus has been painless and their console makes 
troubleshooting so easy it's immensely obvious where you are messing up and 
even more so if someone else's stuff is messing up.

On Nov 12, 2020 14:21, "Zilk, David"  wrote:
We are looking for a consultant to assist in the process of implementing 
STIR/SHAKEN in our network.  Has anyone used any consultants for STIR/SHAKEN 
that they were particularly happy with?

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

Re: [VoiceOps] False 911 calls and old abandoned DID

[Paul Timmins]

No, it's really just 1-9 clicks, or 10 clicks for 0. I've got a rotary 
dial on the desk next to me.



On 1/21/21 6:42 PM, Pete Mundy wrote:

So close! But on the PoTS equipment I'm familiar with (others can chime in and 
correct me if I'm wrong on a larger scale) the numbers are reversed

(well for all except 5 :)

Basically it counts down from 10. 1 pulse is digit '9', 4 pulses is digit '6', 
10 pulses is digit '0'.

So do dial 911 you need:

1 brief loop interruption
pause
9 brief loop interruptions
pause
9 brief loop interruptions



Pete



On 22/01/2021, at 12:07 PM, Mike Johnston  wrote:

One interrupt represents the digit "1" being dialed.  Two rapid interrupts represents the 
digit "2", and so on.  You need to have at least a brief timeout


___
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] USF is 33.4% for 2Q2021

[Paul Timmins]

It feels like every year, I see some elementary school building a 100gb 
coherent 288 strand dark fiber ring on e-rate funds. Yeah, I'm 
exaggerating a bit, but in the case of a local district, only by a bit 
(they were doing 40gb, for a district).


A far cry from when we just subsidized some pots lines or a PRI.

On 6/10/21 11:01 AM, Adam Moffett wrote:
I don't have any inside info on that, but the purpose of USF is to 
subsidize service in high cost areas (usually rural).
So either there are more services needing subsidies or fewer services 
paying in or some combination of both.


Q2 2021 – 33.4%
Q1 2021 – 31.8%
Q4 2020 – 27.1%
Q3 2020 – 26.5%
Q2 2020 – 19.6%
Q1 2020 – 21.2%
Q4 2019 – 25.0%
Q3 2019 – 24.4%
Q2 2019 – 18.8%
Q1 2019 – 20.0%
Q4 2018 – 20.1%
Q3 2018 – 17.9%
Q2 2018 – 18.4%


-- Original Message --
From: "Peter Beckman" 
To: "VoiceOps" 
Sent: 6/10/2021 12:15:16 AM
Subject: [VoiceOps] USF is 33.4% for 2Q2021


Um. Wow. This is crazy. Why is it 33.4%???

2 years ago it was 18.8%. This is DOUBLE!

Will it stop increasing? Go back down? Are we doomed?

Beckman
--- 


Peter Beckman Internet Guy
beckman@angryox.comhttp://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



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

Re: [VoiceOps] USF is 33.4% for 2Q2021

[Paul Timmins]

It is when we pay to build far more capacity than the school can 
conceivably use to a network that can't be repurposed for other things, 
especially when it overbuilds existing networks (ie: The school can't 
even make money leasing back excess capacity, because nobody needs the 
extra glass on that route).


If the local taxpayers want to spend their money that way doing that in 
a metro area that's fine, but if we have to raise USF to get the funds 
needed to provide fiber to a school district fed by 6 T1s in BFE, then 
there's a huge problem with that, not just inequity (that school could 
self fund it, they're in one of the top 10 wealthiest zipcodes in the 
nation) but lack of priorities (they already have an existing 10 gig 
ring on IRUs and a handful of lit services, where some erate entrants 50 
miles away are trying to upgrade from sharing a double digit cablemodem 
or even multilink T1s).


If we fund them all, then you get 33.4% and rising. If we told that 
other school that they had to demonstrate the 10gb ring was insufficient 
for their needs in order to upgrade, we'd have more money to spend on 
the rural and inner city districts who don't have the money.


-Paul

On 6/10/21 11:11 AM, Joseph Jackson wrote:

Is that a bad thing?

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Paul Timmins
Sent: Thursday, June 10, 2021 10:07 AM
To: Adam Moffett; VoiceOps
Subject: Re: [VoiceOps] USF is 33.4% for 2Q2021

It feels like every year, I see some elementary school building a 100gb
coherent 288 strand dark fiber ring on e-rate funds. Yeah, I'm
exaggerating a bit, but in the case of a local district, only by a bit
(they were doing 40gb, for a district).

A far cry from when we just subsidized some pots lines or a PRI.

On 6/10/21 11:01 AM, Adam Moffett wrote:

I don't have any inside info on that, but the purpose of USF is to
subsidize service in high cost areas (usually rural).
So either there are more services needing subsidies or fewer services
paying in or some combination of both.

Q2 2021 – 33.4%
Q1 2021 – 31.8%
Q4 2020 – 27.1%
Q3 2020 – 26.5%
Q2 2020 – 19.6%
Q1 2020 – 21.2%
Q4 2019 – 25.0%
Q3 2019 – 24.4%
Q2 2019 – 18.8%
Q1 2019 – 20.0%
Q4 2018 – 20.1%
Q3 2018 – 17.9%
Q2 2018 – 18.4%


-- Original Message --
From: "Peter Beckman" 
To: "VoiceOps" 
Sent: 6/10/2021 12:15:16 AM
Subject: [VoiceOps] USF is 33.4% for 2Q2021


Um. Wow. This is crazy. Why is it 33.4%???

2 years ago it was 18.8%. This is DOUBLE!

Will it stop increasing? Go back down? Are we doomed?

Beckman
---

Peter Beckman Internet Guy
beckman@angryox.comhttp://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


___
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



--
Paul Timmins
Clear Rate Communications
Direct: (248) 556-4532
Customer Support: (877) 877-4799
24 Hour Repair: (866) 366-4665
Network Operations: (877) 877-1250
www.clearrate.com

This message contains confidential information intended only for the use of the 
intended recipient(s) and may contain information that is privileged. If you 
are not the intended recipient, or the person responsible for delivering it to 
the intended recipient, you are hereby notified that reading, disseminating or 
copying this message is strictly prohibited.

If you have received this message by mistake, please immediately send 
notification by replying to the message, indicate the message was received by 
mistake, and then delete the original message immediately thereafter. Thank you.

Clear Rate Communications, Inc. 2600 W Big Beaver, Suite 450, Troy, MI 48034.

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

Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data

[Paul Timmins]

The perimeta should auto-detect the NAT and start a "fast register" in 
their parlance. You might want to look into this and possibly force nat 
on your MaXUC instead of using nat autodetect, and make sure fast 
register is configured. It will handle keeping the signaling portion 
open for you.


https://community.metaswitch.com/support/solutions/articles/7607855-product-advisory-perimeta-and-sip-application-level-gateways-algs-

On 6/10/21 9:18 AM, Mark Wiles wrote:


Hi Dovid,

So just thinking about this… granted, there wasn’t SIP traffic for “X” 
amount of time… but there would have been RTP… so wouldn’t that have 
been seen as traffic?


Hmmm… but as soon as I typed that, SIP traffic’s on one port… RTP 
traffic’s on another port… so even with the RTP flowing along and 
happy… the SIP’s another matter… right?  Duh!  (I’ve not had my coffee 
yet)


Are you saying that you’re using Metaswitch MaX UC and you’re doing a 
SIP OPTIONS message every 49 seconds?


I totally agree it does sound like a NAT pinhole is closing.  It would 
seem that if that’s the case, Meta would have run into this before and 
had “recommendations” to address this.


I’ll bounce your thoughts off of them.

Thanks!

Mark

*From:* Dovid Bender 
*Sent:* Thursday, June 10, 2021 8:47 AM
*To:* Mark Wiles 
*Cc:* voiceops@voiceops.org
*Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data

If I had to guess Verizon is using CGNAT and since there is no traffic 
for X amount of time the NAT hole for the SIP traffic is closed. When 
you send a re-invite at the 30 minute mark that session as far as 
Verizon's CGNAT devices are concerned have been closed a long 
time ago. You would need to send a packet to the phone or have the 
phone send to your switch some sort of traffic (we send SIP OPTIONS 
every 49 seconds) to ensure that the session stays alive.


On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles <mailto:mwi...@akabis.com>> wrote:


If there’s a Verizon cellular data guru monitoring here, I’d love
to get your insight!

Otherwise, let me toss this out to the group for thoughts and
opinions please…

We’re a Metaswitch shop, and use their MaX UC mobile softphone
client (iPhone/Android).

We had a customer using the MaX UC client on a long call… they
were using Verizon cellular data (confirmed by IP address).

At thirty (30) minutes into the call, the call “dropped”.  The
call was re-established, and again, after thirty minutes, the call
dropped.

We’re pretty sure the user was in a static position (non-mobile)…
and logically _assume_ they were on the same cell tower for both
calls that dropped (the Verizon IP was the same).

Looking at Metaswitch SAS (their diagnostics tool), at the thirty
minute mark, we send out a re-INVITE message to the softphone
client… and we receive no reply… so after ten seconds, we
breakdown the call assuming they’re gone.  Then about eight
seconds later, we see an INVITE message from the softphone’s same
IP address (with the same Call ID)… however, it’s coming from a
different port.  So to be clear, the original call setup and
connection was using 1.2.3.4:6789… then eight seconds after we
ended the call with a BYE (assuming they were gone due to lack of
reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876
<http://1.2.3.4:9876>.

Metaswitch looked at the diags from the softphone (we downloaded
them), and they’re confirming that the softphone never received
our re-INVITE at the 30 minute mark.

Metaswitch also looked at the bug/crash logs on the softphone, and
confirmed neither was the case.

It almost sounds like a NAT thing going on… but I’m pretty
ignorant when it comes to cellular data.  It looks to me as if the
Verizon side simply changed port numbers, and assumed we’d know
maybe via mental telepathy? 

Has anyone had experience with such an occurrence… or any thoughts?

Thank you!

Mark

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

<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fpuck.nether.net%2fmailman%2flistinfo%2fvoiceops=E,1,lh_KPqz2X9PUlHuKPJ5xHOv6u61RFEXqn0IsKcXIj8NwnKlOz0fW5zqT3A9VPfn4xZipprpMy9tXkVyIfmOS7R3SB2CeIgsA5IPv6mEk65Mh92RokKDZDpu9AsXm=1>


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



--
Paul Timmins
Clear Rate Communications
Direct: (248) 556-4532
Customer Support: (877) 877-4799
24 Hour Repair: (866) 366-4665
Network Operations: (877) 877-1250
www.clearrate.com

This message contains confidential information intended only for the use of the 
intended recipient(s) and may contain information that is privileged. If you

Re: [VoiceOps] USF is 33.4% for 2Q2021

[Paul Timmins]

On 6/10/21 6:23 AM, Alex Balashov wrote:


Yeah, observing it as an outsider who is not a service provider, I'm a 
little shocked to say the least. It's hard to understand where that 
kind of money is supposed to come from with the margins in this business.


-- Alex

Passthru fees to the end user, duh. There's nothing us telcos can't cram 
on the bottom of the bill.


Customers are gonna be ticked, but what ya gonna do. It's a line item 
now, and a line item later.


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

Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data

[Paul Timmins]

Perimeta's fast register causes it to refresh faster than once a minute. 
It doesn't log this in the SAS, but there's a way to verify at the 
perimeta CLI it's occurring. You might want to have your SE verify that 
the subscriber is being detected properly as NAT when on the verizon 
towers, and if not, possibly just force nat all the time on max-uc 
(since it's really rare there will be a max-uc session that's NOT behind 
a nat)


On 6/10/21 2:30 PM, Mark Wiles wrote:


Since I’m as dumb as a bag of hammers when it comes to cellular data… 
what do you think the NAT timeout might standardly be, before the 
pin-hole goes away?


Strange we’ve not run into this before.

*From:* VoiceOps  *On Behalf Of *Paul 
Timmins

*Sent:* Thursday, June 10, 2021 11:12 AM
*To:* voiceops@voiceops.org
*Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data

The perimeta should auto-detect the NAT and start a "fast register" in 
their parlance. You might want to look into this and possibly force 
nat on your MaXUC instead of using nat autodetect, and make sure fast 
register is configured. It will handle keeping the signaling portion 
open for you.


https://community.metaswitch.com/support/solutions/articles/7607855-product-advisory-perimeta-and-sip-application-level-gateways-algs 
<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2fcommunity.metaswitch.com%2fsupport%2fsolutions%2farticles%2f7607855-product-advisory-perimeta-and-sip-application-level-gateways-algs=E,1,y0GVFh4InJbiGA_p7LsIOQ53DOKFu20uC7tzS2O0aprTQyEoSEYfcuCoPnEPgoDIKx6FG9ffmXeQPB5RVGEhzUKd-y_ZSrmXJR4DmkX-uw,,=1>-


On 6/10/21 9:18 AM, Mark Wiles wrote:

Hi Dovid,

So just thinking about this… granted, there wasn’t SIP traffic for
“X” amount of time… but there would have been RTP… so wouldn’t
that have been seen as traffic?

Hmmm… but as soon as I typed that, SIP traffic’s on one port… RTP
traffic’s on another port… so even with the RTP flowing along and
happy… the SIP’s another matter… right?  Duh!  (I’ve not had my
coffee yet)

Are you saying that you’re using Metaswitch MaX UC and you’re
doing a SIP OPTIONS message every 49 seconds?

I totally agree it does sound like a NAT pinhole is closing.  It
would seem that if that’s the case, Meta would have run into this
before and had “recommendations” to address this.

I’ll bounce your thoughts off of them.

Thanks!

Mark

*From:* Dovid Bender 
<mailto:do...@telecurve.com>
*Sent:* Thursday, June 10, 2021 8:47 AM
*To:* Mark Wiles  <mailto:mwi...@akabis.com>
*Cc:* voiceops@voiceops.org <mailto:voiceops@voiceops.org>
*Subject:* Re: [VoiceOps] "Timeout" on VoIP call traversing
Verizon data

If I had to guess Verizon is using CGNAT and since there is no
traffic for X amount of time the NAT hole for the SIP traffic is
closed. When you send a re-invite at the 30 minute mark that
session as far as Verizon's CGNAT devices are concerned have been
closed a long time ago. You would need to send a packet to the
phone or have the phone send to your switch some sort of traffic
(we send SIP OPTIONS every 49 seconds) to ensure that the session
stays alive.

On Wed, Jun 9, 2021 at 3:27 PM Mark Wiles mailto:mwi...@akabis.com>> wrote:

If there’s a Verizon cellular data guru monitoring here, I’d
love to get your insight!

Otherwise, let me toss this out to the group for thoughts and
opinions please…

We’re a Metaswitch shop, and use their MaX UC mobile softphone
client (iPhone/Android).

We had a customer using the MaX UC client on a long call… they
were using Verizon cellular data (confirmed by IP address).

At thirty (30) minutes into the call, the call “dropped”.  The
call was re-established, and again, after thirty minutes, the
call dropped.

We’re pretty sure the user was in a static position
(non-mobile)… and logically _assume_ they were on the same
cell tower for both calls that dropped (the Verizon IP was the
same).

Looking at Metaswitch SAS (their diagnostics tool), at the
thirty minute mark, we send out a re-INVITE message to the
softphone client… and we receive no reply… so after ten
seconds, we breakdown the call assuming they’re gone.  Then
about eight seconds later, we see an INVITE message from the
softphone’s same IP address (with the same Call ID)… however,
it’s coming from a different port.  So to be clear, the
original call setup and connection was using 1.2.3.4:6789…
then eight seconds after we ended the call with a BYE
(assuming they were gone due to lack of reply), we get an
INVITE (with the same Call ID) from 1.2.3.4:9876
<http://1.2.3.4:9876>.

Metaswitch looked at the 

Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data

[Paul Timmins]

The metaswitch way is that it will do it automatically for you if it thinks 
you're behind a NAT. So if you force nat, it will do the fast registration 
automatically. It's one line of config on the sip adjacency for the MaxUC 
application.

> On Jun 10, 2021, at 5:33 PM, Matthew Crocker  wrote:
> 
>  
> The acme/oracle way of doing Hosted NAT Traversal is to set the expire time 
> down to 30 seconds and have the phones REGISTER every 30 seconds.   The SBC 
> eats the registration so it doesn’t overload the switch.   If the CGN NAT 
> drops the entry it gets recreated with the new registration in 30 seconds.
>  
> We have had very good results with the acme/oracle approach
>  
> From: VoiceOps  > on behalf of Pete Mundy 
> mailto:p...@mac.geek.nz>>
> Date: Thursday, June 10, 2021 at 5:11 PM
> To: VoiceOps mailto:voiceops@voiceops.org>>
> Subject: Re: [VoiceOps] "Timeout" on VoIP call traversing Verizon data
> 
> CAUTION: This email originated from outside of Crocker. Do not click links or 
> open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Precisely. And those "NAT table entries" eventually time out. On CG-NAT they 
> often time out aggressively; <60 seconds. Hence sending OPTIONS over SIP over 
> UDP regularly keeps the NAT table entries refreshed and active and therefore 
> the UDP 'connection' open. I've come across firewalls with 30 second 
> timeouts, so we use 25 second keepalives (OPTIONS).
> 
> Pete
> 
> >> On 11/06/2021, at 8:24 AM, Alex Balashov  >> > wrote:
> >>
> >> Not to muddy the waters here with needless pedantry, but:
> >>
> >> While UDP may be "connectionless", the only way UDP, and in particular, 
> >> symmetric SIP signalling, can work through NAT is if a stateful firewall + 
> >> NAT gateway has some awareness (that is, state) of UDP "flows", or groups 
> >> of packets flowing between ports consistently in some kind of temporary 
> >> logical association--one might say, the endpoints have a "connection" of 
> >> sorts...
> >>
> >> -- Alex
> >>
> > On 6/10/21 4:07 PM, Peter Beckman wrote:
> > u SIP here is UDP, no?
> > There's no connection to close for UDP.
> > The source port for UDP doesn't matter. It's not part of the whole
> > conversation, unless your switch cares that all communications continue to
> > come from the source port. It's connectionless.
> > TCP 5060 isn't even listening on our switches.
> > So, maybe you're doing SIP over TCP?
> > On Thu, 10 Jun 2021, Mark Wiles wrote:
> ___
> 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] LRN and valid values

[Paul Timmins]

How are you even getting operator assisted calls onto your network to begin 
with? Do you have an operator service you still pay for?

> On May 25, 2021, at 10:47 PM, Peter Beckman  wrote:
> 
> Carrier A provided us a US NPANXX Rate Deck that had some values in it that
> were not valid, such as 732040.
> 
> When asked about it, they claim that Access Tandem Codes are valid LRN
> values for operator services calls.
> 
> Carrier B provides an API for us to query to get the LRN for a termination
> number, so we can rate it properly and implement our own LCR. Carrier B
> says LRNs will always be valid NPANXX values, and 732040 and similar would
> never be returned.
> 
> I don't have access to the LERG, and frankly, even if I did, I'm not sure
> where I'd look to see who wins the conflict.
> 
> Any suggestions?
> 
> 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] LRN and valid values

[Paul Timmins]

> I don't know. I cannot seem to get my carrier to identify a situation where
> I would want to terminate a call and the LRN I would get back would be
> 732040 or similar. 

It never will. The code is unrouteable. I'm sure it exists in the LERG 
somewhere for some sort of pANI or billing purpose, but that doesn't make it a 
routable code.

> I'm trying to figure out if I don't know something or if my termination 
> carrier is mildly nutso.


The people making the rate deck have no idea how the network actually works. 
They just think it costs X to terminate a call to pac bell or whatever so they 
include it, despite it not being a dialable code.

> Unless it will occur and there's something I don't know or understand.

In 20 years of running telcodata.us <http://telcodata.us/>, and 15 years of 
running the network of a regional CLEC, I've never seen any code like that in 
the network outside of AT's weird BTNs (313-K60- and such) but those 
again, aren't billable and in that case aren't even really numbers and in any 
case, don't appear in the PSTN at all, just in category 11 files and on bills 
and ASRs and LSRs)

-Paul


> On May 27, 2021, at 12:08 AM, Peter Beckman  wrote:
> 
> On Wed, 26 May 2021, Alex Balashov wrote:
> 
>> Where does this conflict emerge in practice? Do customers call numbers in
>> this exchange? Do you get billed for calls (less any LRN dip fees) to this
>> exchange even though none of your wholesale termination vendors can route it?
> 
> I don't know. I cannot seem to get my carrier to identify a situation where
> I would want to terminate a call and the LRN I would get back would be
> 732040 or similar. They keep telling me that it exists in the LERG6 and
> LERG6ATC and LERG6ODD, and that's fine, but why would it be in an NPANXX
> rate deck???
> 
> On Wed, 26 May 2021, Paul Timmins wrote:
> 
>> How are you even getting operator assisted calls onto your network to begin
>> with? Do you have an operator service you still pay for?
> 
> I'm not, AFAIK. This is a termination deck. I don't even know of a phone
> number that would return an LRN like this. I'm trying to figure out if I
> don't know something or if my termination carrier is mildly nutso.
> 
> On Thu, 27 May 2021, Jamie Montgomery wrote:
> 
>> There is an entry for 732040A.. OCN refers back to Verizon of Jew Jersey. The
>> Rate Center is all X's, so it's a special code of some kind..  cant be 
>> assinged
>> to an originating number, I dont believe.
> 
> And that's what I'm trying to figure out. I believe the same, but if this
> is true, why would a termination rate deck include 732040 as an LRN prefix
> so we can do LCR? Why include a rate in a deck that will never occur?
> 
> Unless it will occur and there's something I don't know or understand.
> 
> Thus this thread. :-)
> 
> 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] interconnect directly with a PSAP?

[Paul Timmins]

The answer to all 3 is, it depends. Generally there are non clec ways to attach 
to 911 directly (the exact process will have to be worked out by talking to the 
carrier providing 911 in that area) (or indirectly through the likes of intrado 
or intelliquent) and at least in Michigan, the carrier who won 911 contracts 
throughout Michigan actually is native IP on the network, and TDM connectivity 
is an upcharge.

On Jul 4, 2021 19:05, Rob Verk  wrote:

I have been out of the game for about 20 years and now I am back.  I have a lot 
to catch up on but I'm hoping this listserv can help me out.   I have a few 
questions



  *   Is it possible to interconnect directly with a PSAP?
  *   Is a CLEC license/agreement still required?
  *   Is this interconnection still only offered via TDM or is IP/SIP an option?





Thanks for your help.



Rob


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

Re: [VoiceOps] interconnect directly with a PSAP?

[Paul Timmins]

INDigital's system they built with Penninsula FiberNet in Michigan is SIP, with 
private ethernet connectivity to PFN's switches (not public IP networks). Not 
sure about other states.



From: VoiceOps  on behalf of Rob Verk 

Sent: Wednesday, July 7, 2021 2:55 PM
To: Mike Hammett
Cc: voiceops@voiceops.org
Subject: Re: [VoiceOps] interconnect directly with a PSAP?

Is the interconnection TDM or IP?  I did not see much on their site.  I did see 
they provide services in a few States.

From: Mike Hammett 
Sent: Tuesday, July 6, 2021 3:15 PM
To: Rob Verk 
Cc: voiceops@voiceops.org 
Subject: Re: [VoiceOps] interconnect directly with a PSAP?

You'll It'll likely vary state-by-state.

Here in Illinois, we're migrating from a traditional model to an NG911 platform 
by INDigital. You can only interconnect with INDigital at a few locations, none 
of them in-LATA.



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



Midwest Internet Exchange
http://www.midwest-ix.com




From: "Rob Verk" 
To: voiceops@voiceops.org
Sent: Sunday, July 4, 2021 6:01:58 PM
Subject: [VoiceOps] interconnect directly with a PSAP?


I have been out of the game for about 20 years and now I am back.  I have a lot 
to catch up on but I'm hoping this listserv can help me out.   I have a few 
questions



  *   Is it possible to interconnect directly with a PSAP?
  *   Is a CLEC license/agreement still required?
  *   Is this interconnection still only offered via TDM or is IP/SIP an option?





Thanks for your help.



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

Re: [VoiceOps] 8YY Traffic

[Paul Timmins]

How would you go about determining if a toll free number is intralata or not?



From: VoiceOps  on behalf of Mary Lou Carey 

Sent: Thursday, July 1, 2021 5:31 PM
To: Mike Hammett
Cc: voiceops
Subject: Re: [VoiceOps] 8YY Traffic

You should be able to route 8YY traffic over both but only IntraLATA 8YY
traffic over the Local IntraLATA trunk group.

MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-

On 2021-07-01 10:20 AM, Mike Hammett wrote:
> Is there any reason I can't throw all 8YY traffic at my IXC tandem?
>
> In looking in my Metaswitch config, it appears that only 8YY traffic
> destined for my LATA (which doesn't really make any sense) goes to the
> tandem. Everything else goes out to a domestic termination provider.

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

Re: [VoiceOps] Robocall Mitigation in lieu of STIR/SHAKEN

[Paul Timmins]

I suspect that will more than pass muster, given it's what we're expected to do 
under S/S but more thorough, with hard know your customer enforcement.

> On Mar 11, 2021, at 1:22 AM, Nathan Anderson  wrote:
> 
> I don't know if this will pass muster or not, and I don't think it will be 
> too long before we can have full S/S up and running anyway, but we don't 
> allow and have never allowed any of our customers to send a value for CLID 
> that does not match a number linked to their account.  Full stop.  If they 
> transmit a number that isn't actually provisioned on their account, we don't 
> block the call, but the CLID gets forcibly overwritten with their BTN 
> instead.  We simply won't allow a CLID spoof.
>  
> Now, if they want to use us only for some of their term & have a bunch of 
> numbers from another provider that they wish to source calls from through us, 
> we will whitelist those numbers on their account on our side, but only after 
> they have first supplied us with sufficient documentation / proof of 
> ownership of those numbers.
>  
> --
> Nathan Anderson
> First Step Internet, LLC
> nath...@fsr.com 
>   <>
> From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Zilk, David
> Sent: Tuesday, March 9, 2021 4:31 PM
> To: Voiceops.org
> Subject: [VoiceOps] Robocall Mitigation in lieu of STIR/SHAKEN
>  
>  
> The FCC is mandating that service providers must fully implement STIR/SHAKEN 
> or certify that they are taking reasonable steps to avoid originating illegal 
> robocall traffic in the portions of their network where STIR/SHAKEN can’t be 
> implemented. They have also declined to specify what those steps might be, 
> though there may be more information available when they clarify the 
> certification process by March 30th.
>  
> What steps are people taking to meet this robocall mitigation requirement 
> when STIR/SHAKEN is not able to be implemented?
>  
> David
>  
>  
> ___
> 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