from:"Mark R Lindsey"

Re: [VoiceOps] CPA for Telecom Companies

2024-03-22 Thread Mark R Lindsey via VoiceOps

Our firm can do this work. The contact is Stephen Rice (CPA), 
sr...@e-c-group.com, 229-316-0011.

Mark R Lindsey | +1-229-316-0013 | m...@ecg.co <mailto:m...@ecg.co>



> On Mar 22, 2024, at 17:10, Mary Lou Carey via VoiceOps 
>  wrote:
> 
> Can anyone recommend a good CPA who can file income taxes for telecom 
> companies?
> 
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

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

[VoiceOps] US Telecom Privacy regulations change - Q with attorneys/engineer

2024-01-19 Thread Mark R Lindsey via VoiceOps

We talk here occasionally about privacy regulations. For anybody here offering 
voice services in the US, the federal rules related to privacy have recently 
changed. (Recently, one company was fined for the way their app password reset 
process worked because it ran afoul federal regulations.)

I'm hosting a webinar where some attorneys will explain the rules and take your 
questions.  (I'm an engineer so I'm interested in how we implement the new 
rules in a cost-effective way.)

You can register here to watch live or see recording.  Ask questions live or 
email them to me in advance to be answered. (To send questions, please reply 
privately to this email.)

https://info.ecg.co/privacy-by-design-webinar



Mark R Lindsey | +1-229-316-0013 | m...@ecg.co 

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

Re: [VoiceOps] Scam Caller - course of action for service provider?

2023-09-26 Thread Mark R Lindsey via VoiceOps

Chris, good work chasing it down.

Report it to your state Attorney General, 
the FTC: https://reportfraud.ftc.gov/#/
And the FCC: https://fcc.gov/complaints



State Attorney Generals prosecute fraud cases regularly. They're the most 
active in the fight against these scams.

The FTC might already be working on a case against them. They file state 
lawsuits directly.

The FCC has much less power; they can issue a notice to block traffic from a 
service provider, but this has little effect on a scammer who's just moving 
from service provider to service provider.

Mark R Lindsey | +1-229-316-0013 | m...@ecg.co | Schedule a Meeting 
<https://ecg.co/lindsey/schedule> | Newsletter 
<https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/>

> On Sep 26, 2023, at 08:58, Christopher Aloi via VoiceOps 
>  wrote:
> 
> Hey All,
> 
> We have a customer who came on board and used our hosted phone service.  They 
> made it through our "know your customer process" by misrepresenting 
> themselves.  They were actually referred by another customer.  24 hours into 
> their service with us one of our carriers flagged their calls.  I started 
> digging into their traffic and learned they are running a scam to convince 
> elderly folks to give up their credit card information.  It makes me sick to 
> think this was on my network.  I have obviously terminated their service.  I 
> would like to take this to the authorities.  I have call recordings and KYC 
> information.  Thoughts on where to start?
> 
> Chris
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops

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

Re: [VoiceOps] Request to block number?

2023-09-20 Thread Mark R Lindsey, ECG via VoiceOps

Why do we assume the caller has the right to place calls from the number
he’s using?

If you can call him back and reach him at the number from which he is
calling, then I would have a stronger reason to believe that he actually
has the right place calls from that number.

But in the absence of good evidence that he has right to place calls from
that number, this sounds like an attempt to get your assistance to prevent
a different person from being able to place calls. I would make a complaint
to your state attorney general office; that’s where most of the Telecom
fraud and scam investigations are occurring in the USA. If there is
anything at all that has been said that was misleading, or the caller
doesn’t have the right to call from that number, that could qualify as
criminal fraud.



On Tue, Sep 19, 2023 at 13:40 Paul Timmins via VoiceOps <
voiceops@voiceops.org> wrote:

> I wonder if the plan is to spoof a victim's number and  get people to
> block someone who is about to be victimized to prevent them from
> complaining or stopping some form of fraud that they're planning.
>
> Did the stir/shaken header on this call indicate it came from Verizon
> Wireless?
>
>
> On Sep 19, 2023, at 1:31 PM, Christopher Aloi via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> Here is another link if that one didn't work -
>
>
> https://www.icloud.com/iclouddrive/0dff3yxAUUyWu_Nd9ddlMGY8w#2023%5FSeptember%5F19%5F095014%5FEST-EDT%5FInbound%5F4845791377%5F7169616161%5F714
>
> On Tue, Sep 19, 2023 at 1:19 PM Christopher Aloi  wrote:
>
>> I appreciate the concern, and the thought crossed our minds.  He called
>> twice and once ended up in sales and once in support and he didn't seem to
>> be interested in who he spoke with.
>>
>> Here is a recording of the call..
>>
>>
>> https://vaspian-my.sharepoint.com/personal/caloi_vaspian_com/_layouts/15/stream.aspx?id=%2Fpersonal%2Fcaloi%5Fvaspian%5Fcom%2FDocuments%2F2023%5FSeptember%5F19%5F095014%5FEST%2DEDT%5FInbound%5F4845791377%5F7169616161%5F714%2Emp3=1
>>
>>
>>
>> On Tue, Sep 19, 2023 at 1:12 PM Carlos Alvarez via VoiceOps <
>> voiceops@voiceops.org> wrote:
>>
>>> Is it possible that he’s fixated on a specific employee?  Not to be
>>> alarmist, but it’s worth asking around.  I once had a situation where I
>>> noticed some crazy calling activity in a log, just by coincidence, and
>>> found that an employee was being stalked/harassed.
>>>
>>> On Sep 19, 2023 at 10:08:33 AM, Christopher Aloi via VoiceOps <
>>> voiceops@voiceops.org> wrote:
>>>
 Ha!  He did say "he has no self control".  Maybe just someone with some
 mental challenges.

 On Tue, Sep 19, 2023 at 1:05 PM Alex Balashov via VoiceOps <
 voiceops@voiceops.org> wrote:

> Does your company provide anything of interests to addicts, or anyone
> with a compulsive habit they are trying to kick? (e.g. compulsive shopping
> for new VoIP handsets)
>
> > On Sep 19, 2023, at 12:52 PM, Christopher Aloi via VoiceOps <
> voiceops@voiceops.org> wrote:
> >
> > Hey All,
> >
> > I have a new one.
> >
> > We (hosted phone provider) have received three calls today from an
> individual asking us to block him from calling our company.  I can't 
> figure
> out his end game.  He's tried multiple times and didn't explain why when
> questioned.  He said multiple times he wanted his number to be blocked 
> from
> calling our company.
> >
> > Thoughts?
> >
> > Could it be a social engineering attempt?  What for?
> >
> > Chris
> >
> >
> > ___
> > VoiceOps mailing list
> > VoiceOps@voiceops.org
> > https://puck.nether.net/mailman/listinfo/voiceops
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com
> Tel: +1-706-510-6800
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
 ___
 VoiceOps mailing list
 VoiceOps@voiceops.org
 https://puck.nether.net/mailman/listinfo/voiceops

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

Re: [VoiceOps] Call term misrouting?

2023-07-26 Thread Mark R Lindsey via VoiceOps

It would not only be a form of fraud, but sounds be a violation of the Rural 
Call Completion rules (specifically 47 CFR 64.2119(a)). I would recommend you 
make a complaint to the FCC and categorize them at Rural Call Completion 
issues. Provide as much info as you can on carrier names, dates and times of 
the calls.

The FCC staff do contact carriers and intermediate providers to track down RCC 
problems. I worked with one rural provider in the US on an issue related to 
rural call completion, and our complaints were getting callbacks to help us 
troubleshoot from Comcast, Verizon and AT at different points in the 
troubleshooting.

The FCC requires all the intermediate providers to retain records of call 
routing attempts in a readily-accessed format for six months.
https://www.ecfr.gov/current/title-47/section-64.2103

There are minimum standards of quality for carriers related to the successful 
delivery and routing of calls.
https://www.ecfr.gov/current/title-47/section-64.2119


(I'm an engineer, not a lawyer, and this is technical advice, not legal advice.)
Mark R Lindsey | +1-229-316-0013 | m...@ecg.co | Schedule a Meeting 
<https://ecg.co/lindsey/schedule> | Newsletter 
<https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/>


> On Jul 26, 2023, at 09:28, Nathan Anderson via VoiceOps 
>  wrote:
> 
> ...by which I mean, we send a call to a term provider via SIP, who then 
> *seems* to terminate the call to the wrong callee entirely.
> 
> What the heck actually causes this?
> 
> Whenever I have experienced it, it inevitably involves a rural carrier of 
> some kind, one that likely charges a lot to accept traffic.  Over the course 
> of a few days, we just went through twelve rounds of having a wholesale term 
> provider blacklist various carriers from their LCRs for calls headed to this 
> particular exchange, before the problem stopped happening.  "Is it working 
> yet?"  "Nope."  "How about now?"  "Still nope."  And it's random and sporadic 
> enough that I have to place a lot of test calls (as well as continue to field 
> feedback from our end-users) before I can be sure that the problem is 
> actually fixed.  It's aggravating...
> 
> It doesn't seem to be the final destination carrier that's screwing up the 
> call routing after having received the call: I can call the same number over 
> and over again through a "reputable" carrier, or via my personal cell (but I 
> repeat myself), and get connected to the right destination every time.  Based 
> on my experiences, I highly doubt the misdirected calls are even getting as 
> far as the CO's switch for that exchange.
> 
> So I have to hypothesize that some sketch carrier getting is picked from an 
> LCR table, one who just doesn't like sending the call to a rural carrier who 
> either charges that much, or that they suspect is engaging in fraud.  
> But...WHY *misroute* it?  I'd rather you just reject the call if you don't 
> want to carry it.
> 
> The misrouted calls in this latest case more often than not seemed to be 
> hitting a foreign voicemail system that sounded an awful lot like AT 
> Mobility's default voicemail greeting.  But we have definitely had calls just 
> end up ringing the absolute wrong phone...in one case a few months back, I 
> tried ringing the public library branch in this one rural town, and ended up 
> getting the answering machine for some random business (...and also the call 
> quality was *abysmal* on top of that).  (Never did manage to figure out where 
> that business whose answering machine I got was actually located.  It was a 
> generic-enough name for a business in their industry, but what I can tell you 
> is that there was no business by that name in the rate centers covered by 
> that rural carrier.  And also that my CDRs back up the fact that I did *not* 
> mis-dial that call.)
> 
> About the only theory I can come up with that makes a lick of sense is that 
> these cut-rate carriers in these LCRs decide to throw to a rando number if 
> they get asked to term to a high-cost exchange, so that they can record a 
> call completion and charge the caller for it anyway.  Which would be a form 
> of fraud itself, if that's actually happening.
> 
> I suppose there could be a leg of the call that is being signalled 
> non-digitally (so, not SS7, not SIP, ...), and something is getting either 
> mis-transmitted or mis-interpreted.  But if they were doing something like 
> (e.g.) in-band DTMF over a crap connection to an old switch somewhere, I 
> would expect dropped digits, and thus not enough to construct a viable & 
> valid destination number out of.
> 
> -- Nathan
> 
> ___
> 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 warning!

2023-06-30 Thread Mark R Lindsey via VoiceOps

Like Mary Lou, I'd like to help all voice service providers get their 
STIR/SHAKEN implementations up and running. And it's crucial to do verification 
as well as attestation! 
<https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-compliant-mark-lindsey/?trackingId=ooNgRZYHQ5eltXyut2F7dw==>

There are a lot of good options -- I'm personally seeing a lot of activity 
around Neustar, Sansay, and Transnexus. I personally like to implement the 
HTTPS REST interface, but most implementations are doing it with SIP and 302. I 
think I've configured over 10 different variations so far. There are tons of 
technical methods.

BUT... the rules on this third-party SHAKEN are not completely clear cut; I 
tell my clients that "the jury is still out," because the FCC is still seeking 
comment on whether this is appropriate. I'm expecting rules to be issued 
clarifying it.

To read more about where the FCC is on this, see the section starting at 
Paragraph 99 in FCC-23-18A1 published March 17, 2023:

We seek comment on whether, and under what circumstances, a third party may 
authenticate calls on behalf of a provider with A- or B-level attestations 
consistent with the ATIS standards. Pursuant to ATIS-174, in order to apply 
a B-level attestation for a call, the signing party must originate the call 
onto the IP-based service network and have a direct authenticated relationship 
with the customer.An A-level attestation additionally requires the signing 
provider to establish a verified association with the telephone number used for 
the call.341 Can a third-party authenticating a call on behalf of an 
originating provider satisfy all or any these criteria, and if so, how? Does 
the answer to that question depend on the nature of the relationship between 
the originating provider and the third party? For instance, is it possible for 
a third party that is a wholesale provider for a reseller, or an intermediate 
provider, to apply A- or B-level attestations on behalf of an originating 
provider in a manner that complies with the ATIS attestation-level criteria, 
but not a different type of third party? Are there third parties authenticating 
calls on behalf of originating providers that can only apply C-level 
attestations under the ATIS criteria? If commenters contend that third parties 
can meet the ATIS criteria for signing calls with A- and B-level attestations 
because they effectively stand in the shoes of the originating provider with 
the direct relationship with the customer, we ask that they specify the legal 
bases for that conclusion, e.g., the specific grounds for an agency theory, if 
any, and/or how the terms of the ATIS standards may be construed to include the 
third-party arrangement.

To the extent commenters contend that third parties may satisfy the criteria to 
sign calls with A- or B-level attestations, what information must be shared 
between originating providers and third parties for those attestation levels to 
be applied, is that information sharing occurring, and does it implicate any 
legal or public interest concerns, including privacy concerns?

Read it here: https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf

Mark R Lindsey | +1-229-316-0013 | m...@ecg.co | Schedule a Meeting 
<https://ecg.co/lindsey/schedule> | Newsletter 
<https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/>

> On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps 
>  wrote:
> 
> I've heard from several clients that their upstream carrier told them they 
> don't need to worry about being STIR/SHAKEN compliant because they are taking 
> care of everything for them.
> 
> THAT IS NOT CORRECT! Every phone company is required to have its own 
> certificate/token!
> 
> It doesn't matter if you're a reseller or a facilities-based carrier. Whoever 
> bills the customer is the carrier of record and is responsible for signing 
> the customer's calls with THEIR OWN certificate/token. While an upstream 
> carrier can sign calls for your company, they must sign with YOUR 
> certificate/token - not their own because they don't have a direct connection 
> with your customer.
> 
> Please understand that you're putting your network at risk when you share a 
> token with another company because there's no way to differentiate between 
> traffic when it's all under the same certificate/token. If your upstream 
> carrier signs all their customer's traffic with their token, it only takes 
> one bad customer to shut their whole network down. The only way to protect 
> your company from other companies' mistakes is to make sure your upstream 
> carrier is signing your calls with your certificate/token.
> 
> One may not think they can get away with using someone else's 
> certificate/token because it would be difficult to monitor the call stream 
> for offenders. Let

Re: [VoiceOps] Outbound Calls being marked as SPAM

2023-04-05 Thread Mark R Lindsey via VoiceOps

Matt, That's really helpful. The ATIS NNI documents functionally set the 
standard for many of these matters, and number formatting ("canonicalization") 
is one of the big ones. You can find some details on the canonicalization 
algorithm in some of their docs:
https://access.atis.org/apps/group_public/download.php/67436/ATIS-174.v003.pdf
https://access.atis.org/apps/group_public/download.php/63572/IPNNI-2022-9R000.docx

The number formatting is summarized several places like this:
...treat the calling TN as if it were an E.164 number; i.e., canonicalize the 
calling TN to remove any leading “+” sign or visual separators (i.e., “.”, “-”, 
“(”, and “)”)

Thus the "orig" value for a STIR/SHAKEN header should be something like 
"12293160013"  (because the country code is 1), and when the UK is sending 
PASSporT's someday, the orig value would be something like "442078702900" 
(because 44 is the UK country code).


Mark R Lindsey | +1-229-316-0013 | m...@ecg.co | Schedule a Meeting 
<https://ecg.co/lindsey/schedule> | Newsletter 
<https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/>

> On Apr 5, 2023, at 16:07, Matthew Yaklin via VoiceOps  
> wrote:
> 
> I was talking with a comcast guy a while back when we had a SBC incorrectly 
> set. Here is what he said. By any chance are you sending a 10 digit in the to 
> or from? Comcast wants 11 digits for both with no exceptions. We simply 
> logged into the Neustar portal and made a small adjustment on that side as it 
> was easier then tweaking the acme sbc.
>  
> “Hello. My name is XXX XXX; I am an Engineer in Comcast’s Voice 
> Communications Engineering organization. I obtained your contact information 
> from the Robocall Mitigation Database. Below is an example call and Identity 
> header that fails Comcast’s STIR-SHAKEN verification service. You are signing 
> the call using only a 10 digit TO and FROM number. All TO and FROM numbers 
> need to be 11 digits. Almost all 8M Comcast residential voice customers have 
> Xfinity Voice Spam Blocker enabled with the default settings. Failed 
> STIR-SHAKEN calls are sent directly to voicemail and do not ring my 
> customer’s phone.”
>  
> matt
>  
>  
> From: VoiceOps  <mailto:voiceops-boun...@voiceops.org>> On Behalf Of Matthew Crocker via 
> VoiceOps
> Sent: Wednesday, April 5, 2023 3:59 PM
> To: voiceops@voiceops.org <mailto:voiceops@voiceops.org>
> Subject: [VoiceOps] Outbound Calls being marked as SPAM
>  
>  
> We have a customer whos outbound calls are being marked as SPAM by the 
> terminating carrier.   We are sending the calls out fully signed 
> (STIR/SHAKEN) with attest ‘A’ and all of the propery identity headers.  The 
> terminating carrier is Comcast from what we can tell,  does anyone have any 
> tricks we can use or something we may have missed to help get the calls 
> marked correctly?
>  
> Thanks
>  
> -Matt
>  
>  
>  
> ___
> 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] Carriers Keeping Acquired Defunct Company Names

2021-10-24 Thread Mark R Lindsey, ECG

My understanding is that this is all about the administrative friction of
transfers and re-registrations.

Once you’re registered with the FCC, state Public Utilities Commissions,
local authorities for access to right of way and pole access, name changes
and transfers can be complex. Then there are telecom-specific registries
like NANP and NPAC, where each reassignment of a NPANXX block might require
filing several forms. It’s also possible for those transfers to be
rejected, hypothetically even if the FTC, DOJ or other related agencies
have approved the transfer.

However certain transactions, like a simple change of ownership, or an
addition of a DBA identity, can be successful ways to get through the red
tape. Therefore you’ll still see names going back to the original creation
of the databases at the breakup of “Ma Bell;” e.g., blocks of numbers
assigned to “Southern Bell”, later renamed BellSouth, later acquired by
AT But in some databases it’s still retained as the old name from the
early 1989s.

On Sat, Oct 23, 2021 at 18:32 Peter Beckman  wrote:

> I'm curious why companies like T-Mobile and Inteliquent/Onvoy/Voyant
> continue to retain company names and corporate entities long after their
> brands have been retired, acquired, and generally shell entities holding
> phone numbers.
>
> Some examples:
>
>  T-Mobile-> Omnipoint, Aerial Communications, Suncom, Powertel,
> Sprint, Eliska Wireless Ventures Subsidiary I
>  Sprint  -> O1 Communications, US Telepacific
>  AT-> New Cingular Wireless, Southwestern Bell, Pacific Bell,
> Bell South, Southern Bell, Ameritech
>  Verizon -> Cellco Partnership, Bell Atlantic Nynex Mobile
>  Inteliquent -> Radiant IQ, Onvoy, Voyant, Broadvox, Layered, Neutral
> Tandem
>  CenturyLink -> United Telephone, Qwest
>  Spectrum-> Charter Fiberlink
>
> So many of these brands are dead and acquired, yet these companies live on
> and own phone numbers. Cingular died in 2006. Radiant IQ acquired in 2015.
> Bell Atlantic went away in 2000 with Verizon acquiring Bell Atlantic and
> GTE.
>
> Why? What benefit does this provide the owning/operating companies? Legal
> insulation?
>
> Beckman
>
> PS -- This all started when I saw Inteliquent request VoIP Numbering for
> Radiant IQ in June 2020, a company they acquired in 2015, and generally
> does not exist in any meaningful way to customers or consumers, residential
> or business. This industry in the US is weird.
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com
> https://www.angryox.com/
> ---
> ___________
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-- 
Mark R Lindsey | Senior Member of Technical Staff / VP
+1-229-316-0013 | Calendar: https://ecg.co/lindsey
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Broadworks Device Management Security

2021-10-20 Thread Mark R Lindsey

The most common approaches we see in networks are, with the strongest at the 
top, are:

1. Mutual TLS with X.509 Attribute Validation 
2. Mutual TLS  without X.509 Attribute Validation
3. Per-device credentials (HTTP username/password)
4. Per-device-type credentials (HTTP username/password)  
5. IP allow-list to permit only certain clients to download 
6. Funny filenames (like 
https://xsp.serviceprovider.com/dms/CustomModifiedPolycomVVX/ )

The first one, Mutual TLS (verifying the device's certificate created by proper 
manufacturer) with X.509 Attribute Validation (like MAC address) requires this:
-- HTTPS
-- When the client connects, the server requests the client certificate
-- The server checks to see if the client certificate matches the requested 
file type. For example, if you're requesting a Cisco MPP file, then the client 
should be presenting a certificate signed by Cisco.
-- The server checks the content of the certificate against the specific file. 
For example, if the file requested is /0abcdef12345.cfg then the Certificate 
X.509 attributes SAN or CN should contain the MAC address 0ABCDEF12345. The 
formatting of the SAN or CN can vary.

Because devices don't generally have Hardware Security Modules to protect the 
TLS secret key for the certificate signed by the manufacturer, I believe some 
attackers will, someday, determine how to retrieve the secret key and 
certificate from some device. Though I've analyzed many attacks on SIP device 
management, I am not personally aware of any examples of the disclosure of a 
secret key from a device. I expect it to occur someday because of the way the 
software on certain devices manages those keys.

To defend against that eventuality, and the ability to weaponize it into a 
tool, I would not want to rely only on a client's ability to provide any signed 
certificate provided by one of my trusted vendors to download any configuration 
file. For example, I would not want to allow a HTTPS client with a Yealink 
certificate to download a Poly config file.  Further, by validating the MAC 
address inside the X.509 attributes, I am defending against this case by 
ensuring that the disclosed certificate and key can only be used to access 
files for a single MAC address from a specific manufacturer.

In our case, we've implemented this in multiple networks with F5 Labs LTM. The 
builtin BroadWorks support doesn't do all that is needed.

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

> On Oct 20, 2021, at 10:36 AM, Dave Sill  wrote:
> 
> All,
> 
> I’m interested in what you’re doing to protect Broadworks device profile 
> files.  Unique credentials for access, IP whitelist, HTTPS, something else?
> 
> Thanks,
> 
> Dave Sill
> IT Director, Socket Telecom <https://www.socket.net/>
> 573-817- ext 211
> 
> 
> 
> 
> 
> 
> ___
> 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 non-tech

2021-06-23 Thread Mark R Lindsey

You used the term "policy and procedure changes", but that depends on your 
business. I've read many of the RMPs filed in the database, and in most cases, 
the policies they describe are already practices that were in place.

Here are a couple of overviews from law firms --
https://commlawgroup.com/2021/may-6-2021-deadline-to-have-robocall-mitigation-plan-rmp-and-know-your-customer-procedures-operational-fast-approaching-deadline-to-register-and-file-rmp-with-fcc-on-the-horizon/

<https://commlawgroup.com/2021/may-6-2021-deadline-to-have-robocall-mitigation-plan-rmp-and-know-your-customer-procedures-operational-fast-approaching-deadline-to-register-and-file-rmp-with-fcc-on-the-horizon/>

From CommLaw Group -- 
A good RMP will contain detailed (but not necessarily lengthy) descriptions of 
an SVP’s:

• acceptable use policy
• know your customer procedures (e. information that confirms the 
customer’s identity)
• telephone number authorization
• monitoring
• investigation of suspicious activity and traceback
• blocking
• plan update information.

https://www.dwt.com/insights/2020/10/fcc-stir-shaken-robocall-mitigation-plan-deadline

<https://www.dwt.com/insights/2020/10/fcc-stir-shaken-robocall-mitigation-plan-deadline>

From DWT -- 
The FCC requires all programs to include: 
• (1) Detailed practices that can reasonably be expected to 
significantly reduce the origination of illegal robocalls; 
• (2) Compliance with the described practices; and 
• (3) Participation in industry traceback efforts.

If you're an "Intermediate Provider" (calls enter your network from another 
voice service provider, and without going to an end-user subscriber they also 
leave your network, but IANAL so read the legal definition 
<https://www.law.cornell.edu/cfr/text/47/64.2115>) then the changes are more 
likely to be substantial. If you allow people to signup with a credit card and 
start sending you calls from random numbers, then you're probably not 
demonstrating that you "know your customer", also known as KYC. And if they're 
sending calls from US telephone numbers and non-US IP addresses, then you 
should know exactly why.

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

> On Jun 23, 2021, at 3:18 PM, Mike Hammett  wrote:
> 
> We have a consultant filing our mitigation plan (June 30 deadline) and are 
> working with Metaswitch\TNS on the technical aspects (seems like we have 
> until 2022 to do that).
> 
> From some webinars I got the impression that we needed a variety of policy 
> and procedure changes to be compliant. Where is a good resource to figure 
> those out?
> 
> Yes, I am working a variety of things in parallel in this project.
> 
> 
> 
> -
> 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
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Get ready for a weird dialplan change. 9-8-8 suicide hotline.

2020-07-18 Thread Mark R Lindsey, ECG

Fortunately, all we have to do is setup call forwarding for 988 calls to go
to +1-800-273-8255

If anyone here would like to help, they can send me the config steps
necessary to make this work on the platforms you manage. I’ll collect and
publish them (tentatively at http://988.support/ ).

For me, the health-and-safety element of voice telecom is a big part of the
reason it’s important. People depend on us — in a small way — for their
safety.

—
Mark R Lindsey ECG +1-229-316-0013

On Sat, Jul 18, 2020 at 21:45 Jay Hennigan  wrote:

> This should be fun. FCC is designating 9-8-8 as a service code.
>
>
> https://www.fcc.gov/document/fcc-designates-988-national-suicide-prevention-lifeline
>
> --
> Jay Hennigan - j...@west.net
> Network Engineering - CCIE #7880
> 503 897-8550 - WB6RDV
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-- 
Mark R Lindsey | Senior Member of Technical Staff / VP
+1-229-316-0013 | Calendar: https://ecg.co/lindsey
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Three Digit Numbers

2020-03-24 Thread Mark R Lindsey

Gradually building up this list by accretion -- 988 is a new requirement coming 
out too.

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

> On Mar 24, 2020, at 11:55 AM, Hiers, David  wrote:
> 
> I’m not up on the final status, but 811 started off being not all that 
> optional…
>  
>  
> https://docs.fcc.gov/public/attachments/FCC-05-59A1.pdf 
> <https://docs.fcc.gov/public/attachments/FCC-05-59A1.pdf>
>  
> “require the use of 811 as the national abbreviated dialing code for 
> providing advanced notice of excavation activities to underground facility 
> operators within two years after publication of this Order in the Federal 
> Register…”
>  
>  
> “The 811 abbreviated dialing code shall be deployed ubiquitously by carriers…”
>  
>  
> From: VoiceOps [mailto:voiceops-boun...@voiceops.org 
> <mailto:voiceops-boun...@voiceops.org>] On Behalf Of Carlos Alvarez
> Sent: Tuesday, March 24, 2020 8:36 AM
> To: Ed Guy mailto:ed...@eguy.org>>
> Cc: voiceops@voiceops.org <mailto:voiceops@voiceops.org>
> Subject: Re: [VoiceOps] Three Digit Numbers
>  
> Context matters here, i think.  We are a business-only provider, we don't 
> have any residential.  That means that we probably serve people with fewer 
> need for some of these services.  We have a customer that's a major road 
> construction company, and they've never dialed 811.  They know WHO to call, 
> and don't need this national system at all.
>  
> We do have a big list of 911-inclusive dialing patters like that, an 9911, 
> etc.
>  
> Our only international users are call centers owned by US companies, and have 
> specifically asked us to block 911.  I can't find any regulation requiring us 
> to provide them with emergency dialing on softphones used for a call center.
>  
> Like Nick, we used to route 411 to Free411, but during a major system revamp, 
> we saw that it had only ever been dialed twice--during testing.  So we didn't 
> re-implement it in the new system.
>  
> In our state, 511 is for traffic info, but again, we don't handle that and 
> nobody has complained.  It's 2020, people use the web.
>  
>  
> On Tue, Mar 24, 2020 at 8:26 AM Ed Guy  <mailto:ed...@eguy.org>> wrote:
> See https://nationalnanpa.com/number_resource_info/n11_codes.html 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__nationalnanpa.com_number-5Fresource-5Finfo_n11-5Fcodes.html=DwMFaQ=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ=tl9zw0D7cTZtm62zcgN7LHwxsuqcTXVyUuJPEaOe8hE=ARmkQAWsporAHBisnvO-3jazn6o7Gh23P4I-9tRpKFg=>
>  
> Couple things to keep in mind –
> Consider handling 112 and 999 if your service might be used internationally.
> Also – not sure where the current regulation is on this, but the requirements 
> around 911 suggest handling 
> all sorts of additional dialing patterns, e.g., 1010xxx911, et al.   Much of 
> this is legacy, but be aware.
>  
> /Ed
>  
>  
> From: VoiceOps  <mailto:voiceops-boun...@voiceops.org>> on behalf of Carlos Alvarez 
> mailto:caalva...@gmail.com>>
> Date: Tuesday, March 24, 2020 at 11:20 AM
> To: "voiceops@voiceops.org <mailto:voiceops@voiceops.org>" 
> mailto:voiceops@voiceops.org>>
> Subject: Re: [VoiceOps] Three Digit Numbers
>  
> We're in the US, and yes 811 is the underground utility line, but I don't 
> think any of our carriers will pass it.  I don't recall the details on who 
> does what, but carriers like Intelliquent, Bandwidth, and thinQ all do 911 
> testing on 711/811. 
>  
> Yeah, I just tried 811 to Intelliquent and it read back my phone number.
>  
>  
> On Tue, Mar 24, 2020 at 8:14 AM Mike Hammett  <mailto:voice...@ics-il.net>> wrote:
> What country is this? I believe 811 is supposed to be a USA-wide number to 
> call for locating utilities for digging projects.
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ics-2Dil.com=DwMFaQ=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ=tl9zw0D7cTZtm62zcgN7LHwxsuqcTXVyUuJPEaOe8hE=zN8qNDkr5HXBjZ-z0fTk0CoIYg_rncLx8gUGXjaBt3M=>
> 
> 
> 
> Midwest Internet Exchange
> http://www.midwest-ix.com 
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.midwest-2Dix.com=DwMFaQ=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ=tl9zw0D7cTZtm62zcgN7LHwxsuqcTXVyUuJPEaOe8hE=yFi64O5oGZEEsEnY6TBtF-gABzmXYe2KfO8Tpo-BFmc=>
> 
>  
> From: "Carlos Alvarez" mailto:caalva...@gmail.com>>
> To: voiceops@voiceops.or

Re: [VoiceOps] AT Answering Misdials

2019-08-16 Thread Mark R Lindsey, ECG

Almost certainly, answering these misdials and listening is part of a
robocalling detection platform. It’s a PSTN honeypot.

On Fri, Aug 16, 2019 at 12:02 Mary Lou Carey 
wrote:

> Interesting marketing tactic! Makes them appear helpful and accrues CABS
> revenue.
>
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-
>
> On 2019-08-16 10:29 AM, Matthew Yaklin wrote:
> > I realize billing for that type of call is almost nothing now days...
> > but wouldn't that go from a call that has no billing charge what so
> > ever to a call with a tiny bill tied to it since it was answered? If
> > you are ATT that could add up?
> >
> > Just curious since it was brought up.
> >
> >  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 Mike
> > Hammett 
> > SENT: Friday, August 16, 2019 11:24:05 AM
> > TO: Voiceops.org 
> > SUBJECT: [VoiceOps] AT Answering Misdials
> >
> >  I misdialed a number (312) 817-1629 and got the message, "At no
> > additional charge, AT can help you find a similar business in the
> > same area, since the number you called is not in service." It then
> > went into an IVR.
> >
> > Is this common?
> >
> > Does this break any automated systems?
> >
> > No, I have no desire to implement this on our numbers.
> >
> > -
> > 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
>
-- 
Mark R Lindsey | Senior Member of Technical Staff / VP
+1-229-316-0013 | Calendar: https://ecg.co/lindsey
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] LCA file for Broadworks across provinces / states

2019-06-14 Thread Mark R Lindsey, ECG

Are both SHERBROOKE ‘s in the same LATA number? BroadWorks distinguishes
the same names based on LATA. E.g., there are tons of “Springfield”s and
“Albany”s in the US and Canada but in different LATAs.

If you’re using BroadWorks LCA, then you’ll also need to load an
NNACL-formatted file. (I think that’s usually excerpted from LERG6.)

Of course, BroadWorks doesn’t really care where you get the data. It’s
certainly possible to create inconsistencies.

On Fri, Jun 14, 2019 at 13:36 Julien Lamarche  wrote:

> Hi,
>
>   I was building an LCA file for a VoIP provider that uses Broadworks.
>
>   I noticed that the LCA file examples I've been given only lists the
> rate center names, not the provinces.  Yet in LERG6 and LERG8, short and
> long names for rate centers are not unique across all provinces /
> states.
>
> Sherbrooke QC and Sherbrook NS, for example, is listed as SHERBROOKE for
> both it's shot and long name.
>
> Should the LCA file distinguish these two rate centers by listing
> SHERBROOKE, QC as PQSHERBROOKE?If not, what field in NNACL should I
> use to distinguish them?  Or do I have to start creating my own rate
> center names?
>
>
>
> Julien
>
> --
> Make innovation easy
> http://www.credil.org/
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-- 
Mark R Lindsey | Senior Member of Technical Staff / VP
+1-229-316-0013 | Calendar: https://ecg.co/lindsey
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] SUBSCRIBE/NOTIFY method for CNAM querying

2017-10-30 Thread Mark R Lindsey

It appears that it was documented by BroadSoft (Sam Hoffpauir, currently VP 
Engineering) in May 2004, but never submitted as an informational RFC (as RFC 
2705 was done by Cisco for MGCP).

Mark R Lindsey, SMTS 
+1-229-316-0013
m...@ecg.co
http://ecg.co/lindsey/



> On Oct 30, 2017, at 4:25 PM, Ryan Delgrosso <ryandelgro...@gmail.com> wrote:
> 
> The first place i recall seeing this flow was Broadsoft. It was the sole 
> method you could perform CNAM dips as far back as I can recall which was R13. 
> To carbon date that, other softswitches which would have been contemporaries 
> to Broadsoft in ~2005 when that was state of the art were Sylantro (no such 
> support) and Metaswitch (only SS7 support at the time).
> 
> My guess is Broadsoft may have defined a de-facto standard by implementing an 
> esoteric mechanism, and forcing their large subset of customers to require it 
> so all the providers supported it and viola a standard is born. If this is 
> true its unlikely you will find any ratified standard.
> 
> Maybe someone with deeper historical roots than I could shed some light on 
> this, though FWIW this flow has a decidedly broadsoftian feel to it.
> 
> 
> On 10/30/2017 12:12 PM, Alex Balashov wrote:
>> Thanks Carlos.
>> 
>> But to clarify my question:
>> 
>> There is clearly is *some* kind of standard out there, as indicated by
>> the number of (big) vendors who implement it in an agreed-upon way.
>> 
>> So, what I'm trying to figure out is what that standard is and where
>> it's defined.
>> 
>> The Neustar documentation contains obvious cut-and-paste from an ABNF
>> spec:
>> 
>>calling-name-request = callee CRLF
>>[ called CRLF ]
>>callee =“Calling-Party” HCOLON addr-spec
>>called =“Called-Party” HCOLON addr-spec
>>addr-spec =SIP URI / SIPS URI / TEL URI
>> 
>> And it does not seem thematically consistent with the general tenor of
>> that document to suddenly break out some ABNF on their own accord. So,
>> this syntax spec comes from *somewhere*, though no citations revealing
>> its provenance are provided.
>> 
>> The same kind of thing is true in all other docs on this topic from
>> other major vendors. None of them reference anything non-generic (e.g.
>> RFC 3265).
>> 
>> So, what's the standard? Is it the Verizon patent? If so, why don't they
>> any vendor docs refer to it by name?
>> 
>> -- Alex
>> 
> 
> ___
> 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

2015-12-09 Thread Mark R Lindsey

This is a slight topic change, but at SIPNOC for the last few years, FCC and 
FCC-connected people have come and talked about the plans for transitioning. My 
general sense is that the they're considering adding something like an IP 
address to the NPAC data structure.

There's a new IETF working group, "Modern":
> This list is for discussion of systems required to support the management 
> of telephone numbers after traditional telephone functions have migrated to 
> the Internet. In particular, this list considers Internet protocol 
> interfaces needed to register, provision and audit data related to 
> telephone numbers. It is expected that discussion will also involve ongoing 
> development of experimental systems to implement these functions.

A big thrust there is to develop Internet protocols to talk to all the 
old-school telecom systems that have kept us going through the 1980s-present. 

They're also talking a lot there about who "owns" telephone numbers.

Here are some good introductory  slides from the IETF meeting in March: 
https://www.ietf.org/proceedings/92/slides/slides-92-modern-0.pdf




> On Dec 9, 2015, at 10:46 , Pete Eisengrein  wrote:
> 
> Not us.
> 
> Is this topic interesting enough to everyone to try and formalize and 
> develop? (i.e. take it off the email list and do something more)? Maybe meet 
> up at SIPNOC? (though that's 1/2 year away). We'd be happy to host something 
> (say, a two-day meeting) here sooner, if there's interest.
> 
> On Tue, Dec 8, 2015 at 11:57 AM, Erik Flournoy  > wrote:
> Can I get a count of how many folks have SPID? There is a process that some 
> major carriers that were once small used to do exactly what we are 
> describing. The routing issues happen all the time even if it's not a 
> reseller amongst CLECs, ILEC everyday even when NPAC says the number goes to 
> xyz the ILEC ultimately controls 75% of where the call goes on the tandem.
> 
> 
> On Tue, Dec 8, 2015 at 4:34 AM, Peter E  > wrote:
> Well, I think that's where Mark's Bitcoin-ish idea comes in. I'm sure he can 
> explain it better than I can.
> 
> On Dec 8, 2015, at 00:35, Peter Beckman  > wrote:
> 
> Reseller C and the end user knows where the chain ends, but how do WE know
> that reseller C and end-user are honest?
> ___
> 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 and Minimum Billing

2015-12-03 Thread Mark R Lindsey

If I read this right, I think Peter's offering to pay any invalid USF fees. 

Such holiday generosity!

:-)



> On Dec 3, 2015, at 14:30 , Peter Rad.  wrote:
> 
> USF is 16% -- you are all worked up over how much money?
> Emails to the list, frustration, looking up the law references -- you 
> probably blew more time on this issue than what the actually fee was. 
> 
> I understand it is the "principle" of the thing, but it was probably billed 
> by USOC or billing item -- and that billing item always gets billed USF - and 
> they use that USOC billing code for their 499, so they have no real process 
> to not bill you USF since they will be remitting USF based on that USOC. 
> 
> On 12/3/2015 12:33 PM, Peter Beckman wrote:
>> On Thu, 3 Dec 2015, Carlos Alvarez wrote: 
>> 
>>> I agree with you, and I'd ask the carrier to remove that.  It sounds like 
>>> you haven't asked yet.  The whole thing is highly negotiable anyway, since 
>>> it wasn't an actual cost to them.  You might even get them to drop it or 
>>> severely reduce the overage based on future business. 
>> 
>>  I've asked -- this email is verbatim what I sent to them. Their response: 
>> 
>>  "We consider the minimum commitment to make up for services that were not 
>>   utilized during the usage period. Therefore all taxes and regulatory fees 
>>   associated with the service/product will also apply to the minimum 
>>   commitment fee on your invoice." 
>> 
>>  But that isn't how the FCC requirements read. 
>> 
>>  The frustrating part -- engaging a lawyer is likely more expensive than 
>>  simply giving up. And leaving the carrier hurts my business. And this is 
>>  only a one-time issue, not an ongoing billing dispute. 
>> 
>>  I'm quite confident that the USF shouldn't be billed on this non-telecom 
>>  fee, and I can get a lawyer involved and they'll capitulate, but it will 
>>  likely create bad blood plus I'll lose money on the process. 
>> 
>>  I really really dispise companies not taking ownership of issues and just 
>>  blinding standing ground. It makes me wish there were more telecom 
>>  companies that highly regarded customer service like Zappos. 
>> 
>> Beckman 
>> 

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

Re: [VoiceOps] Polycom provisioning for a hosted PBX environment

2015-10-16 Thread Mark R Lindsey

TLS Client Certificate Authentication is what you're looking for.  Polycom 
signs the TLS certificate including the MAC address.

Setup rules in your F5 LTM (or maybe Apache) to enforce this:
1. Only deliver Polycom files to Polycom phones
2. Only deliver the files for MAC address X if the vendor-signed 
certificate provided includes MAC address X.

I would stick with Option 66 (or 160) forever. But if you need to bootstrap the 
phones with Option 66, then use permanently-configured settings thereafter, you 
can actually modify the permanent settings by using a file like this. You have 
to be sure to deliver this as the first file the Polycom phone downloads. 

It's not clear in documentation, but Polycom actually has two config file 
formats: the "master file", and the ordinary config file. SIP Server settings 
are in the latter, but the "master file" can do special things like specify 
other files to download, or -- in this case -- reconfigure the phone's 
provisioning server settings.

 ftp://aaa.bbb.ccc.ddd " 
device.prov.serverType.set="1" device.prov.serverType="0" 
device.prov.user.set="1" device.prov.user="abc" device.prov.password.set="1" 
device.prov.password="def" />   

--- m...@ecg.co
+1-229-316-0013
http://ecg.co/lindsey

> On Oct 16, 2015, at 15:53 , Carlos Alvarez  wrote:
> 
> We don't sell/recommend Polycom, but we have quite a few customers coming to 
> us from other VoIP carriers and they already have them.  We have built a 
> provisioning system that will use HTTP, and it works just fine, except we're 
> not sure what the best way to secure it might be.
> 
> The phones can do username/password, but then that means someone has to go 
> put that into every single phone.  From what we're able to find, there's no 
> way for option 66 to assign this info permanently (meaning you can remove the 
> option 66 settings after initial config).  We don't think we can permanently 
> leave option 66 in place because many customers have a mix of phones, and 
> will need different settings for each type.  Also we don't control their 
> internal network, and forcing them to make a permanent change could be 
> challenging.
> 
> I'd love to hear how some of you in an ITSP/hosted environment are handling 
> 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] (no subject)

2015-04-24 Thread Mark R Lindsey

I talk to a lot of service providers that are improving their security in the 
aftermath of fraud. When they're recovering from a fraud event:

-- They're coping with a loss of tens-of-thousands of dollars. 

-- The ops teams must answer to senior management about how they let 
this happen. 

-- They're confounded to know how the attacker figured out their 
password scheme, or their phone config file names.

-- Sometimes they're frustrated to find a silly mistake that was made 
long ago, and never fixed.

-- Sometimes they're concerned about an insider threat. (Is somebody 
selling our list of MAC addresses necessary to download all the config files?)

-- They may have legal questions, because in hosted PBX and SIP 
trunking, knowing exactly who's responsible for the security and who's got to 
pay for the fraud is unclear.

So for several reasons, you'll find them in poor spirits, and seldom ready to 
chit-chat.

All that said: good, informal relationships among the engineers and ops folks 
at different service providers can help a lot. Go to SIPNOC every year and meet 
your peers at other SP's. And go to your vendors' events, like the BroadSoft 
and Metaswitch customer meetings. Get to know some other tech folks, and keep 
in touch.

And of course, we consultants can help too. People from ECG and other 
consulting firms do promise to keep secrets of our clients, but we also learn 
the techniques and know-how used by the fraud attackers and the defenders.


  
  --- mailto:m...@ecg.co 
  tel:+1-229-316-0013 
  http://ecg.co/lindsey 




 On Apr 24, 2015, at 13:06 , Rob Dawson rdaw...@force3.com wrote:
 
 I wasn’t necessarily thinking of a commercial solution, something more ad 
 hoc, but they do have some pretty innovative and cool solutions.
  
 Rob
  
 From: Alex Hardie [mailto:ahar...@bellsouth.net 
 mailto:ahar...@bellsouth.net] 
 Sent: Friday, April 24, 2015 11:55 AM
 To: Rob Dawson
 Cc: voiceops@voiceops.org mailto:voiceops@voiceops.org
 Subject: Re: [VoiceOps] (no subject)
  
 Have you looked at PinDrop? They specialize in toll fraud for both 
 enterprises and carriers.
  
 Alex Hardie
 
 alex hardie | ahar...@bellsouth.net mailto:ahar...@bellsouth.net | +1 404 
 229 7635
 
 On Apr 24, 2015, at 11:51 AM, Rob Dawson rdaw...@force3.com 
 mailto:rdaw...@force3.com wrote:
 
 Anyone aware of a voice fraud mailing list or listing service? Something of a 
 repository of new attack vectors and remediations or something . . . just 
 thinking it would be cool to see what new attacks people are running into.
  
 If not, any thoughts on something like this?
  
 Rob
 ___
 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] Easy ways to measure PDD

2015-04-21 Thread Mark R Lindsey

I don't think most end users or IT managers are going to agree with these
definitions for PDD. If your customers complain to your local Public Utilities
Commission or equivalent governing body, they're not complaining about time
between SIP messages. They're talking about the time from output of the
dialing signals...from the terminal of the calling subscriber until the
ring-back tone is received.
https://books.google.com/books?id=Byl4uDi-tBICpg=PA72dq=post+dial+delayhl=ensa=Xei=CXk2VebFNNKVyAT-sYH4Bgved=0CCkQ6AEwAg#v=onepageq=post%20dial%20delayf=false

For all of my termination to the PSTN in the US, the ringback is in audio. To
really get PDD, you'd need to process the audio channel and listen for voice
energy. With G.711 it's probably pretty easy to decode just a little RTP to
detect it. For example, you could look at the variance of the last 100 RTP
payload byte values, and if they're zero then you've got silence.

The signaling based methods we're all discussing here are actually measuring
the time to establish a SIP dialog. That's certainly informative and it's easy
to cheat: the UAS (downstream carriers) can start sending a 183 in place of
100.

To answer the OP question, I have a lot of fun with tshark -Tfields. You'd have
to correlate the call IDs...for example,
tshark -i en6 -Y 'sip.CSeq.method==INVITE' -T fields -e
frame.time_epoch -e sip.Call-ID -e sip.to.tag -e sip.Status-Code

You might get output like this:

1429634006.4677130005ca341afb6da7cd2
1429634006.5122730005ca341afb6da7cd2100
1429634006.5544760005ca341afb6da7cd21752914037-1429634006342
401
1429634006.6354240005ca341afb6da7cd2
1429634006.6789920005ca341afb6da7cd2100
1429634010.4858040005ca341afb6da7cd21553636734-1429634010302
183

The fourth frame is the original INVITE; there's no Status-Code, but we have
the call ID.

The final frame shows the establishment of the dialog. It took 3.85 seconds.

The To-Tag is important because you want to distinguish between initial INVITEs
(which have no To-Tag until the dialog begins) and re-INVITEs (which have a
To-Tag on the INVITE because they're in-dialog transactions.)

Because of the tshark/dumpcap interconnection using temporary files, tshark
can't run forever.

--- mailto:m...@ecg.co
tel:+1-229-316-0013
http://ecg.co/lindsey

On Apr 21, 2015, at 11:21 , Ivan Kovacevic ivan.kovace...@startelecom.ca
wrote:

We have recently started measuring it (using FreeSwitch). It is the time
from the initial INVITE to the first provisional response (e.g. 180/183).

Best Regards,

Ivan Kovacevic
Vice President, Client Services
Star Telecom | www.startelecom.ca | SIP Based Services for Contact Centers

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Eric
Wieling
Sent: Tuesday, April 21, 2015 11:15 AM
To: Jesse Howard; Richard Jobson; Peter Beckman
Cc: VoiceOps
Subject: Re: [VoiceOps] Easy ways to measure PDD

I thought PDD / Post Dial Delay was the time between the caller dialing
and the caller hearing ringback. If that is correct you will *never* get
PDD info out of Asterisk. Asterisk only tracks the time between dialing
and answer.

-Original Message-
From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Jesse
Howard
Sent: Tuesday, April 21, 2015 11:10 AM
To: Richard Jobson; Peter Beckman
Cc: VoiceOps
Subject: Re: [VoiceOps] Easy ways to measure PDD

Isn't this exactly what the timeout option in the dial command is for on
Asterisk?

You can both limit the maximum PDD and route advance/alert directly from
your dialplan.

To be honest, ASR and ACD have always been more telling from trending
perspectives than PDD where I only care about PDD when it is overly long.
What it was before the current delay is usually irrelevant for the most
part especially since PDD tends to manifest for specific routes vs. the
carrier in general.

Jesse

From: Richard Jobson [rich...@teraquant.com]
Sent: Monday, April 20, 2015 11:16 PM
To: Peter Beckman
Cc: Calvin E.; VoiceOps
Subject: Re: [VoiceOps] Easy ways to measure PDD

Well if it needs to be real-time, it is not really a CDR function.
Oracles Palladion/COM can do it out of the box. But there again you need
to install a box. You can install it on VME.
It will send you an SNMP trap or email in real-time as soon as the minute
average KPI (e.g. PDD) is exceeded per trunk. And Oracle has a reseller
who can make Palladion sing for its supper :)

On 4/20/15, 5:02 PM, Peter Beckman beck...@angryox.com wrote:

On Mon, 20 Apr 2015, Richard Jobson wrote:

Do you have an SBC or switch that already measures this and outputs
it with the CDR?

Nope.

Do you want to report on all PDD long-term? Or just

Re: [VoiceOps] Broadworks URL Dialing

2015-03-02 Thread Mark R Lindsey

BroadSoft's URL Dialing is pretty important for several of the services. In
particular, any time the Network Server receives an INVITE to route a call to
an Application Server user sip:User@AppServer where User is a UserID, and
AppServer identifies an application server.

URL Dialing is necessary lately, but it'll also make your Network Server return
Contacts in the 302 response that aren't helpful. For example, I've seen folks
who used starbucks.com as a customer domain. Then when one of their users
calls to sip:bo...@starbucks.com, your App Server could do a DNS lookup, and
you'll find INVITE's being attempted to 98.99.252.71, with SNMP traps when that
call fails.

Even worse if your firewall allows them through.

Even worse if your firewall has a default SIP ALG that opens a global pinhole
allowing anything on the Internet to reply when the trusted side sends out a
SIP INVITE to the Internet
http://www.juniper.net/documentation/en_US/junos11.4/topics/task/configuration/alg-security-sip-configuring.html.

In this case, I vote you fix the problem by blocking outbound
(trusted-to-untrusted) SIP in the firewall.

--- mailto:m...@ecg.co
tel:+1-229-316-0013
http://ecg.co/lindsey

On Mar 2, 2015, at 13:47 , Hird, James james.h...@cdk.com wrote:

Greetings All,

I am attempting to fix a condition with camped calls where a camped calling
party never transfers to a now idle user unless there is a DID assigned as
well as extension. We have found that once the URL Dialing policy is added to
the routing profile that the network server lookup succeeds.

We have never enabled the URL Dialing policy on the Network Server routing
profile except for testing in the lab. Can any of the BroadWorks users out
there comment on the impact of enabling URL Dialing across the BroadWorks
platform?

James Hird
Voice Engineer
CDK Global, LLC
503.402.3795 (o)
503.309.5846 (c)
james.h...@cdk.com

Formerly ADP Dealer Services

This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential. If
the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, notify the sender immediately by return
email and delete the message and any attachments from your system.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

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

Re: [VoiceOps] Broadsoft MoH

2014-08-19 Thread Mark R Lindsey

Yes, those are the folks; I've worked with them on tech but not the pricing.

MOHA is BroadSoft certified -- which means they have a Partner Config Guide 
(PCG), and that BroadSoft Inc employees have verified the calls flows.

It seems like all the major vendors I'm familiar with integrate with an 
external media server for interesting music on hold. Hence the market for MOHA. 
Some of the big guys sell a pre-integrated package from another firm, though, 
so you get some of the advantages of having a single vendor to support the 
whole package.

You can search in BroadSoft xChange for other on-hold device PCGs. For example, 
I know there's a device made for Pandora streaming music that's compatible.

 m...@ecg.co +1-229-316-0013 http://ecg.co/lindsey

On Aug 19, 2014, at 08:47 , Colton Conor colton.co...@gmail.com wrote:

 Mark,
 
 Is this the Messages On Hold Australia? http://www.messagesonhold.com.au/ How 
 much does a service like this cost?
 
 Which external music on hold product/services are certified from Broadsoft? 
 What if the client want to plug in an ipod or something local for music on 
 hold with Broadsoft. 
 
 Am I the only one that thinks its silly Broadsoft requires an external device 
 to play more than one song? 
 
 
 On Tue, Aug 19, 2014 at 7:02 AM, Mark Lindsey lind...@e-c-group.com wrote:
 BroadSoft's MOH has two option: a simple file (as you mentioned) and
 an external source.
 
 There are lots of external MOH sources; the most sophisticated is from
 Messages On Hold Australia. It's a BroadWorks (and anybody else...)
 -compatible standard-SIP platform that streams audio according to
 schedules, and records who listens to which recording.
 
 This is a case where any platform with the right external hooks is
 drastically improved through an external SIP device. And as a bonus:
 no IMS are acronyms required.
 
  m...@ecg.co +12293160013 http://ecg.co/lindsey
 
  On Aug 19, 2014, at 2:46, Colton Conor colton.co...@gmail.com wrote:
 
  I was talking with a friend about their broadsoft implementation, and they 
  mentioned that the had a client complaining about Broadsoft's music on 
  hold's features. Basically, the said you could only upload one music file 
  at a time, and it would only play the beginning of that file every time. 
  Plus you can only upload a .wav file, and broadsoft won't convert a .mp3 or 
  other audio file for you.
 
  Sure enough I checked out Wholesalers implementation, and found the same 
  thing. Is this true for all Broadsoft installations? This seems like quite 
  a feature limitation for the most advanced softswitch 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] Hackers Crash Clay Co. Phones ...

2014-08-18 Thread Mark R Lindsey

Ryan, does it seem as though TDoS will be most effectively addressed by the
origination companies? i.e., the guys with the TDM trunks to the local
tandems, such as incumbents, Verizon, Level(3).

It seems to me that some use of statistics could probably make reasonable
guesses about whether a given PSTN origination call is likely to be legitimate
(for a call from A to B). For example, I'll bet you could make a good start
looking at numbers and geographic areas:

-- Has telephone number A called to telephone number B before? Or B-A ?

-- Has GeographicArea(A) called to telephone number B before? Or
GeographicArea(B) - A?

The more you know about telephone numbers A and B, the more you could guess
about the likelihood that a given call is legitimate.

And getting good at this should be a competitive advantage, just as effective
anti-spam is an advantage elsewhere. Vendors that build the edge gear -- in
particular, the SBC and TDM SS7 gateway vendors -- should be leading the way.

And wholesale carriers could take some advantage and make it broadly available.
For example, let's say Verizon came along and said, Here's a reason to port
your numbers from Level(3) to us: When you're under attack, we're going to be
smart about the ways we selectively admit calls to your network.

m...@ecg.co +1-229-316-0013 http://ecg.co/lindsey

On Aug 18, 2014, at 13:52 , Ryan Delgrosso ryandelgro...@gmail.com wrote:

IP DDOS and TDOS are really two different problems but yes we as ITSP's and
CLECs living in the IP space are absolutely susceptible to both.

Ive done a fair amount of research into both of these topics and we have seen
varying cases of both, but usually IP DDOS steals the spotlight because the
numbers are bigger and the effects are usually more widespread whereas a TDOS
attack is rarely felt by anyone that doesn't live in the affected region or
isn't actively trying to call the victim, and usually telcos keep these
issues pretty close to the chest.

I expect this sort of attack is going to increase in magnitude in the coming
24-36 months as attackers figure out how to wield it. Mark Collier gave a
very interesting talk at one of the CFCA events on this topic, though the
focus was on the enterprise victim, but the lessons are really the same.
There just arent really any good tools to mitigate this sort of attack today,
especially at the carrier level.

-Ryan

On 8/18/2014 6:30 AM, Matt Yaklin wrote:

It seems like almost every telephone company can be hit like that
except the ?largest?...

A denial of service attack by simply calling so many times it
fills up their main trunks.

And we saw how the large IP colo providers handle this for customers
who get dos'd. The amount of bandwidth they have is staggering and
they still cannot guarantee you will stay up if a ?skilled? attacker
wants you down. So you keep throwing money at it until you are
so well established online that you look at your monthly bill and
want to puke.

matt

On Mon, 18 Aug 2014, Frank Bulk wrote:

http://www.wibw.com/home/headlines/Hackers-Behind-Phone-Outage-In-Clay-County-271463051.html?ref=051

Painful issue for Big River Telephone!

Frank