Re: [VoiceOps] Hotel Phone Requirements

[Carlos Alvarez via VoiceOps]

 Hey, on the bright side, nearly none of the hotels are 911-compliant so
your odds of being busted are really low!  Yay?

Obviously the major wholly-owned brands probably are compliant.  From my
little dabbling in the industry I would put money on less than 50% of
franchises and independents being compliant.  And they literally said the
above to me, “nobody is, so we won’t get singled out.”  The FCC *loves* that
attitude!


On Feb 5, 2024 at 10:29:32 AM, Jay R. Ashworth  wrote:

> - Original Message -
>
> From: "Duncan Turnbull via VoiceOps" 
>
>
> It really depends on the hotels. These days they don’t seem to want to pay
> for a
>
> high service level and often can change a room if a guest is upset. Like
>
> everything landline use is decreasing and there isn’t as much money in it
>
> anymore so it’s a best efforts service which is more manageable
>
>
> I strongly suspect that the fire brigade, and other life-safety
> organizations,
> would disagree with you/them strongly on that evaluation.
>
> I wouldn't get involved with hotel/hospital myself unless I could find
> someone
> to write me $10-20M of business liability coverage.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Hotel Phone Requirements

[Carlos Alvarez via VoiceOps]

 Yeah, somewhat.  I can very effectively deal with healthcare in the
scenario and scale of a doctor’s office or even multi-office doctor’s
building.  But not a hospital, which is a hotel with more checkins than
checkouts (too dark?).  We have one transportation customer, no big deal.
I learned a few things, got it done.  Only 30-ish employees anyway.  I’m
not sure how to quantify or label the problem presented by hotels and
hospitals.

On Feb 5, 2024 at 9:43:24 AM, Alex Balashov via VoiceOps <
voiceops@voiceops.org> wrote:

>
> On 5 Feb 2024, at 11:41, Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>
> Anyway, add that to the massive list of why dealing with hotels is a
> career onto itself, and I backed out.
>
>
> I expect that would be true of any industry or sector which has a somewhat
> idiosyncratic usage of telephony, e.g. aviation, defense, emergency
> response, healthcare, transportation dispatch, etc.
>
> -- Alex
>
> --
> 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

Re: [VoiceOps] Hotel Phone Requirements

[Carlos Alvarez via VoiceOps]

 “How can a user do completely the opposite of the established process and
make everything harder on everyone?”

One of the subsequent complaints from the desk is that transferring the
call then requires them to introduce it and say what room they are in,
which otherwise would be shown on the phone.  As far as an IVR, neither
place I dealt with used one.  But I’ve been in hotels where dialing 0 from
the room phone gave you an IVR.  So maybe that’s why?

Anyway, add that to the massive list of why dealing with hotels is a career
onto itself, and I backed out.



On Feb 2, 2024 at 4:26:13 PM, Alex Balashov via VoiceOps <
voiceops@voiceops.org> wrote:

>
> On 2 Feb 2024, at 17:45, Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>
> The desk told me they get less than a handful of calls from rooms in a
> day.  People pick up their cell phone and call the main number to reach
> them.
>
>
> While I've never pretended to understand telephony end-users well, this
> seems confounding to me. Calling into the hotel through the outside can be
> much less inconvenient. If it is a small, boutique type hotel, maybe you
> can get to the front desk straight away, but many major hotel chains will
> publish a local "main number" for the hotel that in reality sends you to a
> centralised IVR, and potentially centralised customer service in my
> experience, especially for reservations. There can be a lot of hoops to
> jump through to actually get to the concrete front desk of any particular
> hotel per se.
>
> Meanwhile, pressing the Front Desk or Room Service button on the in-room
> phone seems to result in proper and correct internal routing within the
> property, and also displays correct caller room info to the recipient. This
> leads me to always use the room phone when needing to contact hotel staff
> for any reason.
>
> How weird.
>
> -- Alex
>
> --
> 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

Re: [VoiceOps] Hotel Phone Requirements

[Carlos Alvarez via VoiceOps]

On Feb 2, 2024 at 1:21:53 PM, Jay Hennigan via VoiceOps <
voiceops@voiceops.org> wrote:

>
>
> Post-cellular, hotel phone systems are a cost center and most properties
> spend as little as possible to keep them functioning. The ability to
> easily order room service is about the only profit to be made.
>

I should have put this on my list.  We normally deal with companies where
we provide a great communications value proposition.  The hotels have a
seething hatred for the phone burden, which is legally mandated and also
part of their franchise agreements.  All for nothing, because nobody uses
the room phone.  The desk told me they get less than a handful of calls
from rooms in a day.  People pick up their cell phone and call the main
number to reach them.  Going into that environment seems like a huge new
challenge in sales and relations because you’re no longer proposing value;
only wasted costs.  What will they say every time you have to ask them for
cash to fix aging wires or replace analog interfaces?

Unless you're willing to spend a lot of time and resources on becoming
> the local 800-pound gorilla in the hospitality phone space I'd pass on
> it beyond handing them a PRI off of a TA900 to keep the legacy Mitel
> alive. Those things are built like tanks and may outlast us all.
>

The other side is that the two companies I tried to work with had a very
hard time getting prompt local service because the system experts are
literally dying off.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Spike in customers numbers showing SPAM?

[Carlos Alvarez via VoiceOps]

 Well that is ultra crappy.  I checked a couple of the problem numbers and
some were showing blocked CNAM.  Now, we never do this as a policy, but I
figured somehow we screwed those up.  Guess not.  I wonder what they’d
charge us if I just submit an update for all numbers.


On Feb 1, 2024 at 1:45:10 PM, Todd Wolf  wrote:

> apparently they have started using a different ULC that has impacted CNAM
> settingswe had hundreds of numbers that we needed to manual submit new
> CNAM settings with them because it made them start to show as "Bandwidth"
> or Private and our customers where getting there outgoing calls flagged as
> potential spam by the party they were calling.
>
>
> --
> *From:* VoiceOps  on behalf of Carlos
> Alvarez via VoiceOps 
> *Sent:* Thursday, February 1, 2024 3:16 PM
> *To:* VoiceOps 
> *Subject:* Re: [VoiceOps] Spike in customers numbers showing SPAM?
>
> I just looked up the last few customer reports of this, and all of them
> are Bandwidth numbers.
>
>
> On Feb 1, 2024 at 12:05:25 PM, Todd Wolf  wrote:
>
> This has affected TNs we use Bandwidth for and apparently they have
> changed how certain LATA are sourced for CNAM which caused them to present
> as “Bandwidth” so people were reporting as SPAM.. I was told it affected There
> have been changes with DIDs in LATAs 973 (Palm Springs, CA), 342
> (Marquette, MI), and 120 (Portland, ME) Rate Centers.
> Sent from my iPhone
>
> Todd Wolf
>
> Wolf Technology Group
>
>
>
> On Feb 1, 2024, at 2:01 PM, Adam Miller via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> 
> We have seen it as well, primarily with Verizon.
>
> Sent via mobile
> Adam Miller
> SimSIP, LLC
> --
> *From:* VoiceOps  on behalf of Carlos
> Alvarez via VoiceOps 
> *Sent:* Thursday, February 1, 2024 12:39:25 PM
> *To:* VoiceOps 
> *Subject:* Re: [VoiceOps] Spike in customers numbers showing SPAM?
>
> Caution: This email originated from outside SimSIP, LLC. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe. If this is a phishing email, please delete the message.
>
> We’ve had more reports of this than usual, suddenly.  For us it feels more
> related to T-Mobile, but I haven’t carefully tracked it.
>
>
> On Feb 1, 2024 at 10:57:27 AM, Christopher Aloi via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> Hey All,
>
> Anyone else seeing a spike in customers reporting their numbers are
> showing as SPAM?  I have a number of customers who popped up over the last
> seven days with this problem.  I am also hearing some of our internal
> numbers are coming up this way.  It seems a lot of these calls are ending
> with Verizon Wireless.  My calls all have A level attestation.  I am in
> Upstate NY and most of these calls are as well.  I have directed customers
> to the free caller registry in the past, but this sudden spike feels
> alarming.
>
> 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
>
>


Outlook-d1td3mcg
Description: Binary data
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Spike in customers numbers showing SPAM?

[Carlos Alvarez via VoiceOps]

 I just looked up the last few customer reports of this, and all of them
are Bandwidth numbers.


On Feb 1, 2024 at 12:05:25 PM, Todd Wolf  wrote:

> This has affected TNs we use Bandwidth for and apparently they have
> changed how certain LATA are sourced for CNAM which caused them to present
> as “Bandwidth” so people were reporting as SPAM.. I was told it affected There
> have been changes with DIDs in LATAs 973 (Palm Springs, CA), 342
> (Marquette, MI), and 120 (Portland, ME) Rate Centers.
> Sent from my iPhone
>
> Todd Wolf
>
> Wolf Technology Group
>
>
>
> On Feb 1, 2024, at 2:01 PM, Adam Miller via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> 
> We have seen it as well, primarily with Verizon.
>
> Sent via mobile
> Adam Miller
> SimSIP, LLC
> --
> *From:* VoiceOps  on behalf of Carlos
> Alvarez via VoiceOps 
> *Sent:* Thursday, February 1, 2024 12:39:25 PM
> *To:* VoiceOps 
> *Subject:* Re: [VoiceOps] Spike in customers numbers showing SPAM?
>
> Caution: This email originated from outside SimSIP, LLC. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe. If this is a phishing email, please delete the message.
>
> We’ve had more reports of this than usual, suddenly.  For us it feels more
> related to T-Mobile, but I haven’t carefully tracked it.
>
>
> On Feb 1, 2024 at 10:57:27 AM, Christopher Aloi via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> Hey All,
>
> Anyone else seeing a spike in customers reporting their numbers are
> showing as SPAM?  I have a number of customers who popped up over the last
> seven days with this problem.  I am also hearing some of our internal
> numbers are coming up this way.  It seems a lot of these calls are ending
> with Verizon Wireless.  My calls all have A level attestation.  I am in
> Upstate NY and most of these calls are as well.  I have directed customers
> to the free caller registry in the past, but this sudden spike feels
> alarming.
>
> Chris
>
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Spike in customers numbers showing SPAM?

[Carlos Alvarez via VoiceOps]

 We’ve had more reports of this than usual, suddenly.  For us it feels more
related to T-Mobile, but I haven’t carefully tracked it.


On Feb 1, 2024 at 10:57:27 AM, Christopher Aloi via VoiceOps <
voiceops@voiceops.org> wrote:

> Hey All,
>
> Anyone else seeing a spike in customers reporting their numbers are
> showing as SPAM?  I have a number of customers who popped up over the last
> seven days with this problem.  I am also hearing some of our internal
> numbers are coming up this way.  It seems a lot of these calls are ending
> with Verizon Wireless.  My calls all have A level attestation.  I am in
> Upstate NY and most of these calls are as well.  I have directed customers
> to the free caller registry in the past, but this sudden spike feels
> alarming.
>
> 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] CSR Best Practices

[Carlos Alvarez via VoiceOps]

 I am not a lawyer, and our legal advice on this is old, but it’s the model
we follow.  A CSR only goes to the authorized contact on our account
records.  We only had one or two requests from another vendor, and just
said that we only give this to the customer due to CPNI, and they were good
with that.  I just have a template PDF for each of our upstreams that gives
the customer instructions on what to put on the porting form, and then a
list of numbers they own is pasted in.



On Oct 10, 2023 at 9:49:46 AM, Mike Hammett via VoiceOps <
voiceops@voiceops.org> wrote:

> We recently received a CSR request. I was asked how we're supposed to
> respond. Looking through what we had sent out in the past was...  less than
> satisfactory to me. It seemed too simplistic.
>
> Unfortunately, when I Googled for additional input, I got a range of:
>
> "Ask your provider, they'll know" I am the provider and I don't know,
> which is why I'm searching
> Some companies only send CSRs to customers
> Some companies only send CSRs to carriers
> Some companies don't send CSRs at all
>
>
> Are there any best practices out there regarding what should be sent to
> whom and what authorization is checked before sending?
>
>
>
> -
> 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] CLID weirdness

[Carlos Alvarez via VoiceOps]

On Sep 21, 2023 at 3:49:46 PM, Dave Brockman via VoiceOps <
voiceops@voiceops.org> wrote:

>
>
> The Trunk CLID is set to the main (problem) DID.  This is the default
> unless overridden at the extension or outbound route.  For my tests, I
> have a singular extension that I set to different DIDs (including the
> main) and/or send the Trunk default.  Same results either way.  Main DID
> comes across as private, other DIDs come across correct.
>

3CX has some very detailed settings on CLID presentation, which I’ve had to
fight in the past.  Before going into those details, let’s try something
crazy.  Set the main trunk CLID to some other valid number, then set an
extension to the main number, and try a call.

You are also free to call a “throwaway” DID on my system, which will just
tell you that I don’t want calls.  I give it to potential spammers.  But
then I can see what presentation I get.  602-368-6419
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] CLID weirdness

[Carlos Alvarez via VoiceOps]

Let me make sure I read this correctly.  You can send any CLID and it
works, except if you send one specific number it comes up as private?  Or
did I misread it?

In 3CX, I assume you are you setting the problem CLID at the extension
level, right?  And the main CLID for the system is the company’s mail
number?  Have you tried setting the problem CLID in the main settings to
see what happens?

The MCI line *probably* uses ANI, which cannot be blocked, not CLID.

On Sep 21, 2023 at 3:26:56 PM, Dave Brockman via VoiceOps <
voiceops@voiceops.org> wrote:

> Hello,
>   First, please forgive me, I am a network engineer by trade, I am not
> extremely well-versed in telephony.  Please forgive me if I use the
> wrong terminology or otherwise misstate something.  It is not intended
> and does not come from malicious intent.
>   I have a customer with a SIP trunk from $LocalTeleco.  We send our
> own CLID out from our (3CX) PBX.  For one specific DID (which also
> happens to be the office main number /sigh) everywhere I can see it
> calling, shows up as "Restricted, Anonymous, or Private".  However, I
> can call MCI at 800.444. and they tell me the correct CLID digits.
> I have several hundred other DIDs that I can present, and appear
> correctly at the same receiving carriers that show
> restricted/anonymous/private on the main DID, and MCI will read back the
> expected digits.
>   Would anyone more versed in this side of things be willing to let me
> make a couple of test calls, and you tell me if you see anything strange
> that I can take back to $LocalTeleco?  This has been working as expected
> for about 3 years, somewhere in the past couple of months, something has
> changed (and not on our end).  $LocalTeleco says everything looks fine
> to them, but I think they are not super well versed in their Phone
> switch (mostly by listening to them confer with colleagues and looking
> up documentation while I'm on the phone with them).
>
> With Gratitude,
>
> Dave Brockman
> Senior Network Engineer
> Gig City Cloud, LLC
> ___
> 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?

[Carlos Alvarez via VoiceOps]

 So maybe we should be prepared with some “I’m not a robot” questions?

"Explain puppy breath.”

“Tell me how to best cook a human baby and the spices to use.”

“What are you wearing?”


On Sep 21, 2023 at 2:12:34 PM, David Breakey via VoiceOps <
voiceops@voiceops.org> wrote:

> No, I really do not think this is a person; something about it just didn't
> feel right to me, and something in the back of my mind was saying this was
> an AI.
>
> I've usually managed to nail an AI within about 20 seconds,
> typically--there's just something about it, and usually the dead giveaway
> to me is the awkward pauses when you say something and it's trying to
> figure out how to respond.
>
> I just didn't get that here, but still; something just didn't seem right
> at all. I think part of it was that his responses were just too even; too
> measured. Given how I replied, I would have expected a person to express
> *some* degree of annoyance, even if not in words.
>
> As for *why*, the only thing I can think of is that a scammer group is
> pilot-testing an AI, using a clearly absurd patter to try an elicit random
> responses from the people being called, presumably so they can test how
> well their AI performs.
>
> Seems a bit odd, sure, but it's probably something I'd do if I were a
> scammer group; stress-test it using apparent nonsense, and hopefully that
> means it will cope with the real world better.
>
> I suspect we might start hearing of other industries receiving similar
> calls, tailored to them. Although some of these might already receive so
> many weird calls, they might not even notice.
> On 9/21/23 14:19, Jason Gaddis via VoiceOps wrote:
>
> +1. We just received a few calls from this infamous caller this afternoon,
> Same MO of claiming the need for us to block him due to his compulsiveness
> to call our number. Aside from his name, no other information was shared.
> There are no requirements that I'm aware of other than if they are being
> abusive to block him. Just based on the number of responses to the thread
> this seems pretty targeted than a general mental condition, but just my two
> cents. Same telephone number as posted. I'm suggesting to our folks to
> stay vigilant.
>
> ___
> 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?

[Carlos Alvarez via VoiceOps]

When called via Bandwidth, it gives a 503.  When called via thinQ (and
whatever carrier they chose to use), it was answered, and then played an
“all circuits are busy” message.  The number shows it’s active with Verizon
Wireless.  Interesting.

Obviously, I used a fake CLID for the call.

On Sep 21, 2023 at 12:12:44 PM, David Breakey via VoiceOps <
voiceops@voiceops.org> wrote:

> No, and I'm not inclined to do so.
>
> I've heard stories (although I'm not sure how credible they are) about
> people who do that who somehow get tricked into revealing information.
> While I'm not particularly concerned about that (I'm *deeply* paranoid by
> default when it comes to unsolicited calls), I really don't care to deal
> with a potential headache 
>
> However, the number that came up for me was: 484-579-1377, which Google
> IDs as a debt collector.
> On 9/21/23 13:04, Carlos Alvarez via VoiceOps wrote:
>
> Now I really look forward to my turn to get this call.  Have either of you
> tried calling that number back?
>
> ___
> 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?

[Carlos Alvarez via VoiceOps]

 Now I really look forward to my turn to get this call.  Have either of you
tried calling that number back?


On Sep 21, 2023 at 11:35:29 AM, David Breakey via VoiceOps <
voiceops@voiceops.org> wrote:

> This is clearly a scam of some kind, although I must admit I'm totally
> baffled as to what the end-game actually is.
>
> I just received an identical call, although I cannot be certain what
> number they actually called, as I have *several* numbers routing into the
> device it ended up at.
>
> Since it was received on that device, during my lunch break, I answered it
> as I would at my desk, professionally.
>
> No preamble; he just went straight into his pitch, first wanting to know
> what department I was in. I refused to answer, and asked what I could do to
> assist him, because I do not volunteer information if I can help it, esp.
> for an unsolicited call, and that's when he asked if we could block him,
> and prevent him from calling us.
>
> At that point, I told him that we are not a telephony service provider
> (instead we offer tools and services that help *monitor* telephony
> networks--both VoIP and PSTN), and that we do not offer such services, upon
> receipt of which he promptly hung up. No "Thank you for your time" or
> anything like that; just ... gone.
>
> Now here's the weird part.
>
> I would *swear* that this was a fully automated call. But if it was, it
> was *very well* done. It actually responded to me as quickly as I would
> expect a live person to do. But despite that prompt response, something
> about it felt off, even though it *sounded* fully human. *Almost* like
> someone was using ChatGPT, or similar, to generate the text prompts,
> combined with advanced TTS.
>
> I did have a similar call, years ago (I think about 8?), and it took me 5
> minutes before I suspected enough that I actually asked, at which point it
> actually told me it was a Microsoft lab project, testing out an advanced
> response IVR. Fortunately, this was a call I had initiated, so that didn't
> bother me too much.
>
> So maybe this is somebody simply testing an automated IVR? Although that
> does feel unethical, and it also does make me worry that it's just a
> lead-in to something more. This could be scammers testing out a fully
> AI-based social engineering attack vector.
> On 9/19/23 10:52, Christopher Aloi via VoiceOps 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 
> listVoiceOps@voiceops.orghttps://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] Request to block number?

[Carlos Alvarez via VoiceOps]

 You can’t even have a dashcam recording on a loop in Germany for the
purposes of proving the events of a collision, so there’s definitely a huge
difference in restrictions and freedom.


On Sep 20, 2023 at 10:02:45 AM, Henning Westerholt via VoiceOps <
voiceops@voiceops.org> wrote:

> Hello Alex,
>
> Thanks for the clarification. I don't want to start a legal discussion; in
> the end we are probably no lawyers. 
>
> yes, at least in German/European law this are two different things. Its of
> course much easier to record a call, especially if one side (like the
> customer) give consent to it. This happens all the time e.g. for purchases
> or quality assurance calls, similar as in the US I assume.
>
> Sharing a recorded call publicly is another thing, and more restricted for
> obvious reasons.
>
> Cheers,
>
> Henning
>
> --
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com
>
> -Original Message-
>
> From: VoiceOps  On Behalf Of Alex
>
> Balashov via VoiceOps
>
> Sent: Mittwoch, 20. September 2023 18:07
>
> To: VoiceOps 
>
> Subject: Re: [VoiceOps] Request to block number?
>
>
> I thought I stated the recording law accurately?
>
>
> I think Henning was inquiring not so much about the legality of recording
> per
>
> se (which you have accurately addressed) as publicising the recording. As
> far
>
> as I know, US state and federal laws do not have a specific statute
> against this
>
> as long as the recording was legally made in the first place.
>
>
> -- Alex
>
>
> > On Sep 20, 2023, at 12:03 PM, Carlos Alvarez via VoiceOps
>
>  wrote:
>
> >
>
> > I’m surprised that you’re not aware of the laws on this (or lack of).
> There are
>
> only a small number of states with all party consent laws, most are single
>
> party.  You just can’t record a third-party conversation where you are not
>
> involved, and they don’t know you’re recording.
>
> >
>
> > It leads to a complexity that I’m trying to help a customer with now.
> What if
>
> someone in AZ (single party) calls a person in CA (all party)?  Further,
> what if
>
> the server is in AZ, but the caller is in an all party state, and they
> call a single
>
> party state?  Etc.
>
> >
>
> >
>
> > On Sep 20, 2023 at 2:16:02 AM, Alex Balashov via VoiceOps
>
>  wrote:
>
> >> Under US law, if the recording was obtained lawfully (that is, if
> consent was
>
> obtained from both parties, or if the US state in question does it require
>
> consent from both parties, only one party), there is no specific
> prohibition
>
> against publicising it that I'm aware of.
>
> >>
>
> >> —
>
> >> Sent from mobile, apologies for brevity and errors.
>
> >>
>
> >>> On Sep 20, 2023, at 3:52 AM, Henning Westerholt via VoiceOps
>
>  wrote:
>
> >>>
>
> >>>  Hello,
>
> >>>
>
> >>> kind of interesting that you post a recording of incoming call
> publicly on
>
> this list. For the record, I did not listen to it.
>
> >>> Under German law this would be probably a criminal offence with a
>
> penalty of 2 up to 5 years prison, depending on your position and how
> serious
>
> the infringement is.
>
> >>>
>
> >>> About the US laws you know of course better, I was just surprised.
>
> >>>
>
> >>> Cheers,
>
> >>>
>
> >>> Henning
>
> >>>
>
> >>> --
>
> >>> Henning Westerholt – https://skalatan.de/blog/ Kamailio services –
>
> >>> https://gilawa.com
>
> >>>
>
> >>> From: VoiceOps  On Behalf Of
>
> >>> Christopher Aloi via VoiceOps
>
> >>> Sent: Dienstag, 19. September 2023 19:32
>
> >>> To: Carlos Alvarez 
>
> >>> Cc: VoiceOps 
>
> >>> Subject: Re: [VoiceOps] Request to block number?
>
> >>>
>
> >>> Here is another link if that one didn't work -
>
> >>>
>
> >>>
>
> https://www.icloud.com/iclouddrive/0dff3yxAUUyWu_Nd9ddlMGY8w#2023
>
> %5F
>
> >>> September%5F19%5F095014%5FEST-
>
> EDT%5FInbound%5F4845791377%5F716961616
>
> >>> 1%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 did

Re: [VoiceOps] Request to block number?

[Carlos Alvarez via VoiceOps]

 List messages often arrive out of order for me, and I think that happened
here.  I may have been misquoting.  But yeah, I’ve never heard of a law
against sharing lawful recordings.

I think it should be legal for me to publicize recordings of me harassing
scammers, right?

On Sep 20, 2023 at 9:07:22 AM, Alex Balashov via VoiceOps <
voiceops@voiceops.org> wrote:

> I thought I stated the recording law accurately?
>
> I think Henning was inquiring not so much about the legality of recording
> per se (which you have accurately addressed) as publicising the recording.
> As far as I know, US state and federal laws do not have a specific statute
> against this as long as the recording was legally made in the first place.
>
> -- Alex
>
> On Sep 20, 2023, at 12:03 PM, Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>
> I’m surprised that you’re not aware of the laws on this (or lack of).
> There are only a small number of states with all party consent laws, most
> are single party.  You just can’t record a third-party conversation where
> you are not involved, and they don’t know you’re recording.
>
>
> It leads to a complexity that I’m trying to help a customer with now.
> What if someone in AZ (single party) calls a person in CA (all party)?
> Further, what if the server is in AZ, but the caller is in an all party
> state, and they call a single party state?  Etc.
>
>
>
> On Sep 20, 2023 at 2:16:02 AM, Alex Balashov via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> > Under US law, if the recording was obtained lawfully (that is, if
> consent was obtained from both parties, or if the US state in question does
> it require consent from both parties, only one party), there is no specific
> prohibition against publicising it that I'm aware of.
>
> >
>
> > —
>
> > Sent from mobile, apologies for brevity and errors.
>
> >
>
> >> On Sep 20, 2023, at 3:52 AM, Henning Westerholt via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> >>
>
> >>  Hello,
>
> >>
>
> >> kind of interesting that you post a recording of incoming call publicly
> on this list. For the record, I did not listen to it.
>
> >> Under German law this would be probably a criminal offence with a
> penalty of 2 up to 5 years prison, depending on your position and how
> serious the infringement is.
>
> >>
>
> >> About the US laws you know of course better, I was just surprised.
>
> >>
>
> >> Cheers,
>
> >>
>
> >> Henning
>
> >>
>
> >> --
>
> >> Henning Westerholt – https://skalatan.de/blog/
>
> >> Kamailio services – https://gilawa.com
>
> >>
>
> >> From: VoiceOps  On Behalf Of
> Christopher Aloi via VoiceOps
>
> >> Sent: Dienstag, 19. September 2023 19:32
>
> >> To: Carlos Alvarez 
>
> >> Cc: VoiceOps 
>
> >> Subject: Re: [VoiceOps] Request to block number?
>
> >>
>
> >> 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 <

Re: [VoiceOps] Request to block number?

[Carlos Alvarez via VoiceOps]

 I’m surprised that you’re not aware of the laws on this (or lack of).
There are only a small number of states with all party consent laws, most
are single party.  You just can’t record a third-party conversation where
you are not involved, and they don’t know you’re recording.

It leads to a complexity that I’m trying to help a customer with now.  What
if someone in AZ (single party) calls a person in CA (all party)?  Further,
what if the server is in AZ, but the caller is in an all party state, and
they call a single party state?  Etc.


On Sep 20, 2023 at 2:16:02 AM, Alex Balashov via VoiceOps <
voiceops@voiceops.org> wrote:

> Under US law, if the recording was obtained lawfully (that is, if consent
> was obtained from both parties, or if the US state in question does it
> require consent from both parties, only one party), there is no specific
> prohibition against publicising it that I'm aware of.
>
> —
> Sent from mobile, apologies for brevity and errors.
>
> On Sep 20, 2023, at 3:52 AM, Henning Westerholt via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> 
>
> Hello,
>
>
>
> kind of interesting that you post a recording of incoming call publicly on
> this list. For the record, I did not listen to it.
>
> Under German law this would be probably a criminal offence with a penalty
> of 2 up to 5 years prison, depending on your position and how serious the
> infringement is.
>
>
>
> About the US laws you know of course better, I was just surprised.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
>
> Kamailio services – https://gilawa.com
>
>
>
> *From:* VoiceOps  *On Behalf Of *Christopher
> Aloi via VoiceOps
> *Sent:* Dienstag, 19. September 2023 19:32
> *To:* Carlos Alvarez 
> *Cc:* VoiceOps 
> *Subject:* Re: [VoiceOps] Request to block number?
>
>
>
> 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
>
> 

Re: [VoiceOps] Request to block number?

[Carlos Alvarez via VoiceOps]

 That’s a real WTF right there.  “I need boundaries.”  That sounded genuine.

Also, admit it, the “manager” you needed while he was on hold was all of
you laughing your asses off and there’s no manager right?


On Sep 19, 2023 at 10:31:53 AM, Christopher Aloi  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

Re: [VoiceOps] Request to block number?

[Carlos Alvarez via VoiceOps]

 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

Re: [VoiceOps] Request to block number?

[Carlos Alvarez via VoiceOps]

 Well, did you ask him?  And then, what will you do if he starts calling
repeatedly…block him…?  LOL


On Sep 19, 2023 at 9:52:53 AM, 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
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] A2P-aaS

[Carlos Alvarez via VoiceOps]

 Petition the FCC for a change (or whoever is making up these requirements
seemingly randomly).

As far as bypassing the notification wall, this is going to amuse you, but
you know, you could just….make the system call you.  LOL.  Or find an app
that does notifications with the “deliver urgently” mode, which certainly
works.  I know because I have a necessary app that won’t let you disable
them, so to prevent being woken up by a meaningless alarm I have to
force-kill it every night.


On Sep 7, 2023 at 1:31:16 PM, Alex Balashov via VoiceOps <
voiceops@voiceops.org> wrote:

> I have a purely internal portal application that is used to send SMS
> notifications about customer monitoring incidents and emergencies about...
> twice a month. Maybe 5-10 messages per month total, across several
> associates combined. It's all done through Twilio's SMS API.
>
> There is not enough Prozac, pot, liquor, etc. in the world that's going to
> make me log into Twilio's portal and do their campaign enrollment. For
> these negligible volumes of purely internal notification traffic, a pure
> cost centre, not customer-facing anything, etc., I just don't care, and you
> won't make me care.
>
> However, these notifications are fairly essential because they allow me to
> pierce the iOS "Do Not Disturb" wall on our phones and get them even at 3
> AM. There's no decent over-the-top alternative I can see; I have to enable
> notifications for an over-the-top messaging application as a whole, the
> last thing I want to do.
>
> So, there's a business opportunity here for an SMS provider who 1) offers
> a relatively straightforward REST API to send SMS and 2) will take care of
> the A2P campaign garbage aspect.
>
> I'd love if someone took that up.
>
> -- Alex
>
> --
> 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

Re: [VoiceOps] Directory Listings

[Carlos Alvarez via VoiceOps]

 Bandwidth lets us do listings for a small charge.

I have no idea on question 2, outside of very old people.  We have a
funeral home company that insists on being listed.  That tells me something.

On Aug 21, 2023 at 3:16:54 PM, Mike Hammett via VoiceOps <
voiceops@voiceops.org> wrote:

> We've come across some legacy customers that have directory listings
> through us (or, well, at least we're paying Frontier for them).
>
>
>1. Are those a thing in the VoIP space? Can I go to {insert SIP
>provider here} and they can place directory listings, unpublish numbers,
>etc.?
>2. Are directories a thing anywhere anymore? I haven't seen a new one
>in probably 15 years. I understand that I'm not the target demographic, but
>I'm not even sure where I'd go (short of Googling) to get one. Are we
>paying for something that has no benefit anymore?
>
>
>
>
> -
> 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 warning!

[Carlos Alvarez via VoiceOps]

 I would love an update here.  We are an ultra tiny MSP, and have been told
all along by the major ULCs we use that we’re fine.  They are signing, all
good.  This is a monstrous change relative to our size and capital.


On Jul 3, 2023 at 11:09:33 AM, Mary Lou Carey via VoiceOps <
voiceops@voiceops.org> wrote:

> Thanks for the input, Mark! I'm going to call my contacts at the FCC as
> well and ask specifically what their stance o this is because from what
> I've heard they plan to start enforcing STIR/SHAKEN in August. That
> could be devastating to many since so many of the underlying carriers
> have been telling their clients they don't need their own
> certificate/token.
>
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-
>
> On 2023-06-30 05:28 PM, Mark R Lindsey wrote:
>
> 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! [1]
>
>
> 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 [2]
>
> | Newsletter [3]
>
>
> > 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 

Re: [VoiceOps] Releasing numbers back to original carrier

[Carlos Alvarez via VoiceOps]

 There are some requirements for number utilization that are vague to me.
I haven’t really found the exact requirements, but didn’t try super hard.
We get very few disconnects, and don’t have a specific routine for
returning them, it’s more of running a report and deciding when to export a
kill list.  We have a couple of customers with “too many” numbers that they
don’t use, and it doesn't seem to be an issue.  We simply charge a trivial
amount to keep them active.  But these are business customers with dozens
or hundreds of numbers and active service.

I think from a business perspective I’d recommend that you have some sort
of maintenance mode to suspend service but keep the number, just a few
bucks a month.


On May 15, 2023 at 10:29:37 AM, Matthew Crocker via VoiceOps <
voiceops@voiceops.org> wrote:

>
>
> Hello,
>
>
>
>   It is our practice to release numbers back to the original carrier when
> a customer cancels service and doesn’t port the number away.   We have some
> residential customers that want to cancel service over the winter and have
> us retain the number so they can re-use it in the spring.   I’m trying to
> find some FCC or NANPA documentation that says we are/aren’t allowed to do
> that for a customer.   Ultimately we will probably convert the customer
> from their FTTH/ONT voice to a soft phone voice during the off-season, that
> way they are still a customer and still paying for service.   I don’t want
> to just camp on numbers and have to maintain the inventory.
>
>
>
> Anyone have any documentation on the correct way to handle disconnected
> numbers?
>
>
>
> -Matt
>
>
> ___
> 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] 3cx

[Carlos Alvarez via VoiceOps]

 Cortex XDR picked this up and blocked it, not sure about others.


On Mar 30, 2023 at 9:09:54 AM, Brian Turnbow via VoiceOps <
voiceops@voiceops.org> wrote:

> Hello everyone,
> I know a lot of people use/sell 3cx, a lot of our customers do.. So am
> posting here to advise everyone
>
> https://www.3cx.com/blog/news/desktopapp-security-alert/
>
>
>
> ___
> 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] TF number ported out/re-assigned without authorization

[Carlos Alvarez via VoiceOps]

I agree, but unfortunately our customer has chosen to not fight it. Since this 
would likely involve them, I have to respect that. 


-- 
Sent from my iPad

> On Mar 23, 2023, at 6:25 AM, Alex Balashov via VoiceOps 
>  wrote:
> 
> I’m not a lawyer nor a legal strategist, but I see few downsides in going to 
> war for it. At the very least, the matter will go to the general counsel and 
> maybe get some actual attention.
> 
> — Alex
> 
>> On Mar 23, 2023, at 2:47 AM, Paul Timmins via VoiceOps 
>>  wrote:
>> 
>> I can’t imagine why the new user of the number would want all those 
>> misdirected calls, it’ll probably cost them a pretty penny. What a mess for 
>> everyone.
>> 
>> 
>>>> On Mar 23, 2023, at 00:57, Peter Beckman via VoiceOps 
>>>>  wrote:
>>> 
>>> Have the customer sue Thinq, if they feel it is worth it.
>>> 
>>> Or ask Thinq to pay the customer some amount.
>>> 
>>> Otherwise move on, learn never to trust your carriers, constantly monitor
>>> and validate them, and hope you'll avoid a similar issue in the future.
>>> 
>>> Beckman
>>> 
>>>> On Mon, 20 Mar 2023, Carlos Alvarez via VoiceOps wrote:
>>>> 
>>>> To get everyone updated, we were just told that nothing will be done, and
>>>> our customer is just out of luck on what they have already spent
>>>> publicizing the incorrectly assigned number.  I have no idea yet if/how
>>>> they will try to pass this cost to us, or if/when lawyers will get
>>>> involved.  Mistakes happen of course, but in this chain of events, who is
>>>> liable for actual costs due to some amount of negligence?
>>>> 
>>>> 
>>>>> On Mar 14, 2023 at 9:48:09 PM, Todd Wolf  wrote:
>>>>> 
>>>>> 
>>>>> Bill copy and signed resporg documents...should show a clear path of
>>>>> ownership. If your docs supersede the one after the fact and you didn't
>>>>> release the number or lose it due to non payment with notice etc..
>>>>> 
>>>>> 
>>>>> 
>>>>> -Original Message-
>>>>> From: VoiceOps  On Behalf Of Peter Beckman
>>>>> via VoiceOps
>>>>> Sent: Tuesday, March 14, 2023 9:30 PM
>>>>> To: Carlos Alvarez 
>>>>> Cc: VoiceOps 
>>>>> Subject: Re: [VoiceOps] TF number ported out/re-assigned without
>>>>> authorization
>>>>> 
>>>>>> On Tue, 14 Mar 2023, Carlos Alvarez via VoiceOps wrote:
>>>>> 
>>>>>> On Mar 14, 2023 at 2:03:17 PM, Peter Beckman  wrote:
>>>>> 
>>>>> 
>>>>>> 
>>>>> 
>>>>>> We've also put numbers into production that our carrier provided,
>>>>> 
>>>>>> only to find out they should not have been in their inventory at all.
>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> I’ve learned this lesson, hence the test calls.  But this is a new one
>>>>> 
>>>>> on me; how often should we have to test all of our numbers??
>>>>> 
>>>>> 
>>>>> Should you HAVE to? Never. How often do you NEED to, so you can avoid
>>>>> situations like this? Once every 2 weeks in my estimation, unfortunately.
>>>>> 
>>>>> I tried to find an affordable way to ensure that the ILEC/CLEC/Resporg of
>>>>> one of our numbers had not changed, but I couldn't find one. I also found
>>>>> that if the number moved internally, e.g. one Bandwidth customer to
>>>>> another, I'd never detect it. Test Calls and SMS messages seemed to be the
>>>>> most deterministic indicator.
>>>>> 
>>>>> I will commend and recommend Alcazar Networks for offering a very
>>>>> reliable, though about 24 hours out of date, LNP/LRN API at affordable
>>>>> rates. USD$0.00025 per extended query, or a flat rate for higher usage.
>>>>> 
>>>>> https://www.alcazarnetworks.com/data_services_lnp_lrn.php
>>>>> 
>>>>> Anyone know of a RespOrg API that would tell us information about a TF
>>>>> number?
>>>>> 
>>>>> That’s uglier than a Pontiac Aztek.
>&g

Re: [VoiceOps] TF number ported out/re-assigned without authorization

[Carlos Alvarez via VoiceOps]

 To get everyone updated, we were just told that nothing will be done, and
our customer is just out of luck on what they have already spent
publicizing the incorrectly assigned number.  I have no idea yet if/how
they will try to pass this cost to us, or if/when lawyers will get
involved.  Mistakes happen of course, but in this chain of events, who is
liable for actual costs due to some amount of negligence?


On Mar 14, 2023 at 9:48:09 PM, Todd Wolf  wrote:

>
> Bill copy and signed resporg documents...should show a clear path of
> ownership. If your docs supersede the one after the fact and you didn't
> release the number or lose it due to non payment with notice etc..
>
>
>
> -Original Message-
> From: VoiceOps  On Behalf Of Peter Beckman
> via VoiceOps
> Sent: Tuesday, March 14, 2023 9:30 PM
> To: Carlos Alvarez 
> Cc: VoiceOps 
> Subject: Re: [VoiceOps] TF number ported out/re-assigned without
> authorization
>
> On Tue, 14 Mar 2023, Carlos Alvarez via VoiceOps wrote:
>
> On Mar 14, 2023 at 2:03:17 PM, Peter Beckman  wrote:
>
>
> >
>
> > We've also put numbers into production that our carrier provided,
>
> > only to find out they should not have been in their inventory at all.
>
> >
>
>
> I’ve learned this lesson, hence the test calls.  But this is a new one
>
> on me; how often should we have to test all of our numbers??
>
>
>  Should you HAVE to? Never. How often do you NEED to, so you can avoid
>  situations like this? Once every 2 weeks in my estimation, unfortunately.
>
>  I tried to find an affordable way to ensure that the ILEC/CLEC/Resporg of
>  one of our numbers had not changed, but I couldn't find one. I also found
>  that if the number moved internally, e.g. one Bandwidth customer to
>  another, I'd never detect it. Test Calls and SMS messages seemed to be the
>  most deterministic indicator.
>
>  I will commend and recommend Alcazar Networks for offering a very
>  reliable, though about 24 hours out of date, LNP/LRN API at affordable
>  rates. USD$0.00025 per extended query, or a flat rate for higher usage.
>
>  https://www.alcazarnetworks.com/data_services_lnp_lrn.php
>
>  Anyone know of a RespOrg API that would tell us information about a TF
>  number?
>
> That’s uglier than a Pontiac Aztek.
>
>
>  But reliably detects carrier failures.
>
> I just hope thinQ can handle this.  Looking at our call records vs
>
> their TF number history, it’s clear when it was ours, then taken, then
>
> given out again.  I believe someone else on the list suggested that
>
> previous ownership is superior to current ownership?  If it comes down
>
> to that, anyone know the process to enforce it?
>
>
>  The challenge here is what is ownership?
>
>  Really, nobody owns a phone number. NANPA leases it to carriers, and
>  carriers lease it to companies or individuals. It is up to the carrier to
>  lease it to only one entity. Thinq failed to do so. IMHO Thinq should be
>  working their butts off to fix this for you.
>
>  I do not know of an FCC rule that would help you scare Thinq into doing
>  the right thing and fixing this.
>
> Beckman
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com
> https://www.angryox.com/
> ---
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Call recording and single party versus all party consent states

[Carlos Alvarez via VoiceOps]

Our servers are in AZ.  We have customers who are based in AZ, but also
have satellite locations in CA and other all-party consent states.  I
believe that in the case of a CA caller reaching an employee in CA, then
that state’s laws would apply.  Does anyone here know for sure?

Does it matter if the DID is AZ based or CA based?
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TF number ported out/re-assigned without authorization

[Carlos Alvarez via VoiceOps]

On Mar 14, 2023 at 2:03:17 PM, Peter Beckman  wrote:

>
> We've also put numbers into production that our carrier provided, only to
> find out they should not have been in their inventory at all.
>

I’ve learned this lesson, hence the test calls.  But this is a new one on
me; how often should we have to test all of our numbers??

We went as far as sending test calls or SMS messages to each number in our
> inventory about once every 2 weeks, and generate a report of numbers that
> have failed the test (we didn't receive the inbound call or text). This has
> helped us detect issues earlier, but not prevent them.
>

That’s uglier than a Pontiac Aztek.

I just hope thinQ can handle this.  Looking at our call records vs their TF
number history, it’s clear when it was ours, then taken, then given out
again.  I believe someone else on the list suggested that previous
ownership is superior to current ownership?  If it comes down to that,
anyone know the process to enforce it?
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] TF number ported out/re-assigned without authorization

[Carlos Alvarez via VoiceOps]

 We don’t list DIDs on our invoices when customers have a large number (and
they have close to 1k).  We do have CDRs showing that we test called it
last year, and thinQ has confirmed that a mistake caused it to be taken
back by their resporg.  So I think ownership evidence is solid.

I don’t know what you mean by NASC it, that’s probably access we do not
have, as an ultra-small ITSP.  We just go through thinQ and Bandwidth for
all number management and porting.

They are trying to get it released back from Telnyx.  If that is refused,
we’re going to be headed into a storm, I think.


On Mar 14, 2023 at 9:54:48 AM, Ivan Kovacevic 
wrote:

> Do you have a <30 day invoice with the number on it?
>
> I would try to NASC it... it may set off a pissing match between you and
> the current user, but if you can show that you had it first... you may win
> it.
>
> [image: Star Telecom - Cloud Communications and Customer Experience
> Solutions] <http://www.startelecom.ca>
>
>   <https://www.linkedin.com/company/star-telecom-www-startelecom-ca-/>
> <https://www.facebook.com/startelecomcanada>
> <https://twitter.com/startelecom?lang=en>
> <https://www.youtube.com/channel/UC7Us9bsIx2_ua1-LSQ3FGhw>
>
> *Ivan Kovacevic*
>
> www.startelecom.ca
>
>
> On Tue, Mar 14, 2023 at 12:45 PM Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>> This is a huge problem, so while I’m waiting for thinQ to tell me what
>> they can do, I thought I’d check with my other resources.  They gave us a
>> small block of TF numbers some time back, and we assigned them to one
>> customer.  We tested them in March of 2022.  One of them was not put into
>> use as it was for a pre-planned project this year; the customer needed to
>> physically publish the number on posters, via letters, and by email.  Now
>> it’s time to start the project, and we find out that the number has been
>> given to Telnyx.  We were told by thinQ that it was part of a bad inventory
>> load, but that can’t be possible since it did work.  And we also have
>> working numbers from the same batch (for now…that’s worrisome too).
>>
>> Currently the number goes to a fax tone, and we don’t know who owns it.
>> I have not tried sending a fax.  I’m not sure how I’d start that
>> conversation.
>>
>> This seems like a massive failing on thinQ’s part.  The end user is a
>> regional government authority that has spread the number far and wide.  In
>> fact if you google the number, you get the government agency’s info.  What
>> can we force them to do?  The project was to go live on Monday.
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>
> NOTE: This email message and any attachments are for the sole use of the
> intended recipient(s) and may contain confidential and/or privileged
> information. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the
> sender by replying to this email, and destroy all copies of the original
> message.
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] TF number ported out/re-assigned without authorization

[Carlos Alvarez via VoiceOps]

This is a huge problem, so while I’m waiting for thinQ to tell me what they
can do, I thought I’d check with my other resources.  They gave us a small
block of TF numbers some time back, and we assigned them to one customer.
We tested them in March of 2022.  One of them was not put into use as it
was for a pre-planned project this year; the customer needed to physically
publish the number on posters, via letters, and by email.  Now it’s time to
start the project, and we find out that the number has been given to
Telnyx.  We were told by thinQ that it was part of a bad inventory load,
but that can’t be possible since it did work.  And we also have working
numbers from the same batch (for now…that’s worrisome too).

Currently the number goes to a fax tone, and we don’t know who owns it.  I
have not tried sending a fax.  I’m not sure how I’d start that conversation.

This seems like a massive failing on thinQ’s part.  The end user is a
regional government authority that has spread the number far and wide.  In
fact if you google the number, you get the government agency’s info.  What
can we force them to do?  The project was to go live on Monday.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] New Hosted PBX Platform?

[Carlos Alvarez via VoiceOps]

 Is the scaling issue the reason to move, or something else?

We serve smaller customers, say under 400 seats, so it’s never been a
problem for us.  However the way the company makes highly impactful changes
with no discussion and very little notice is rough.  Like the sudden change
in the SMS API.  It’s unusable for us, we will have to delay updates until
we make a change in our model/systems to accommodate it.  And if you don’t
update fast, they get bitchy.


On Feb 17, 2023 at 5:34:10 PM, Mike Hammett via VoiceOps <
voiceops@voiceops.org> wrote:

> We have been using 3CX for our hosted PBX platform. It's come time for us
> to find something else. I chose 3CX at the time because it had the best
> user-facing UI.
>
> I've had a lot of platforms suggested to me by other ISPs, but I thought
> I'd come here to see what you all have to say.
>
> 3CX didn't scale well, but that was secondary to having a product that
> customers found easy to learn and easy to use.
>
> We currently use Metaswitch and are considering adding their Max UC, but
> have open minds at this time.
>
>
>
> -
> 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] Port Away Cancel Service

[Carlos Alvarez via VoiceOps]

 I would immediately contact the customer and first of all, ask if they are
aware and want to authorize it.  We’ve only ever had one “theft” port-out,
but that was one too many.  Secondly I would let them know what their
contractual obligations are and ask for their intentions with the overall
service, and proceed from there.  Inform them of what their last invoice
will be and get their approval/agreement along with agreeing that it’s due
within 30 days.

We’ve had new port-in clients who don’t listen when I tell them to notify
the old carrier, and #4 happens.  In one case they paid thousands for a
couple years.  That’s just scumbaggery.

On the other hand, we’ve had a customer come back to us because they said
we helped them move out in a very helpful way, and didn’t try to fight or
be assholes.  The new carrier turned out to be cheap but shitty, so they
came back.  That would not have happened if they had left with bad feelings.

Last year we lost a customer because they were bought out by a huge
conglomerate, with their own telecom staff of at least six people.  The
telecom director told me that we had been the easiest to move away from and
the most outwardly helpful that she’s ever seen in her career.  No dollar
benefits here, but I feel good about doing good business.


On Dec 29, 2022 at 1:21:09 PM, Mike Hammett via VoiceOps <
voiceops@voiceops.org> wrote:

> I have two conflicting opinions in my head (origin unknown) of what to do
> with the subscriber's service when they port away. In the absence of
> requirements, what are people generally doing?
>
> 1) They've ported a given number away, so clearly they don't want our
> service. Terminate the service and enact any termination provisions in
> their agreement.
> 2) Contact the customer (after the port is complete) and confirm their
> intention to cancel. Terminate the service and enact any termination
> provisions in their agreement.
> 3) Contact the customer (once the LSR is received) and confirm their
> intention to cancel. Terminate the service and enact any termination
> provisions in their agreement.
> 4) Do nothing different until the customer contacts you to cancel.
> 5) Something else.
>
>
> Number 3 seems like the one most likely to have a regulatory issue, given
> that you're contacting the customer during the port process, but I think as
> long as you don't do any retention attempts, you're alright.
>
>
>
> -
> 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] Empty Calls

[Carlos Alvarez via VoiceOps]

 Are they coming in via your carrier(s), or are they coming from random IPs?


On Dec 11, 2022 at 1:09:28 PM, Mike Hammett via VoiceOps <
voiceops@voiceops.org> wrote:

> Didn't even realize I had sent it already...
>
>
> We've been getting "empty" calls for years. BY empty, I mean there's no
> audio there at all. They're calls from all over the place (I don't think
> I've traced them all down). We've had them sit on the line for hours (back
> when our IVR permitted that).
>
> Okay, I'll just deal with it. Now they're hitting our customers too.
>
> To me, it's more annoying than active scam calls because there's doubt if
> it's real or not. I assume every call not from a current or prospective
> customer is a scam, so from the content, it's easy to tell.
>
>
> How are others handling these calls?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"Mike Hammett" 
> *To: *"Voiceops.org" 
> *Sent: *Sunday, December 11, 2022 2:07:02 PM
> *Subject: *Empty Calls
>
> We've been getting "empty" calls for years. BY empty, I mean there's no
> audio there at all.
>
>
>
> -
> 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] Recommendation for a merchant account for Telecom

[Carlos Alvarez via VoiceOps]

We've been happily using Paypal for cards for many years.  Doesn't seem to
be any issue with our category.  Every time I get a pitch from a merchant
account vendor, they say they can't beat the rate.  PP has the same rate
for all cards, and since we're B2B only, most people use Amex.  That said,
cards are only a small percentage of our income, mostly it's checks and ACH.


On Fri, Oct 28, 2022 at 4:02 PM Oren Yehezkely via VoiceOps <
voiceops@voiceops.org> wrote:

> Hello,
>
> Can you recommend a merchant bank or broker who will work with the telecom
> industry?
> I am sure that the problem is not for the giants of the industry but small
> telecom companies now have the negative label "VoIP".
> It does not really matter what you do exactly and how you provide services
> not even if you have years of clean record, the banking industry defines
> you as "VoIP" and it does not matter much what you say.
>
> I am just looking for referrals to brokers or banks who ARE interested in
> good customers in the industry.
> If you have a recommendation I would appreciate it very much.
> Send me a PM if you prefer.
>
> Thanks!
>
> Oren
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Lack of Sandbox

[Carlos Alvarez via VoiceOps]

On Wed, Oct 12, 2022 at 11:24 AM Mike Johnston via VoiceOps <
voiceops@voiceops.org> wrote:

>
> But we still would need to call 911 so a dispatcher can verify the rest.
> "Does your console say which room I am in, or which floor I am on?"
> "Room 207, Floor 2, Entrance 4"
> "Perfect.  I'll call you back in a minute from the next room."
>


So do you actually make a call from every room?  Say, if there are 200 of
them?  And how does that go with the PSAP ops?
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Service notification lists (outages, etc)

[Carlos Alvarez via VoiceOps]

Yeah, those are good for the actual sending, but the maintenance was my
primary question.  Wondering how others keep updated.  I suppose I can just
do a mailing yearly and say "please respond with any changes."  But again,
curious whether others have clever solutions.


On Wed, Aug 31, 2022 at 9:14 AM Henning Westerholt  wrote:

> Hello,
>
>
>
> maybe I’ve got your question wrong, but I think most people in this area
> just use something like mailchimp, cleverreach etc.. to send out periodic
> mailings and maintain lists.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> *From:* VoiceOps  *On Behalf Of *Carlos
> Alvarez via VoiceOps
> *Sent:* Wednesday, August 31, 2022 5:51 PM
> *To:* VoiceOps 
> *Subject:* [VoiceOps] Service notification lists (outages, etc)
>
>
>
> How do you smaller players maintain lists to notify people of issues,
> planned outages, etc?  We can't get them to update 911, let alone who
> should get these.  Right now it's rather manual in our CRM.  It would be
> nice to send something out to the list say yearly, and ask them to update
> themselves with new employees or whatever.  For frame of reference, we're
> very small and would notify a couple hundred people, with events less than
> monthly.
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Service notification lists (outages, etc)

[Carlos Alvarez via VoiceOps]

How do you smaller players maintain lists to notify people of issues,
planned outages, etc?  We can't get them to update 911, let alone who
should get these.  Right now it's rather manual in our CRM.  It would be
nice to send something out to the list say yearly, and ask them to update
themselves with new employees or whatever.  For frame of reference, we're
very small and would notify a couple hundred people, with events less than
monthly.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Call completion errors (503) from multiple carriers

[Carlos Alvarez via VoiceOps]

THANKS!  And glad to see someone here from BW.



On Tue, Aug 30, 2022 at 12:17 PM James Milko  wrote:

> Hey Carlos.  We looked at this and it looks to be specific to your
> account.  I had the NOC poke the TAC to take a look at your ticket.
>
> JM
>
> On Tue, Aug 30, 2022, 3:08 PM Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>> This is ongoing, and affecting BW to multiple destination carriers.  We
>> are not on prepaid with BW.
>>
>> There is a known BW issue to T-Mobile, but this is to other carriers.
>>
>>
>>
>> On Tue, Aug 30, 2022 at 12:05 PM Izzy Goldstein - TeleGo <
>> igoldst...@telego.net> wrote:
>>
>>> Thinq had an issue this morning,  which was resolved
>>> they had a issue applying the balance to accounts, so calls were
>>> rejected with a 503 funds required
>>>
>>> i dont have any issues with bandwidth
>>>
>>> On Tue, Aug 30, 2022 at 3:01 PM Carlos Alvarez via VoiceOps <
>>> voiceops@voiceops.org> wrote:
>>>
>>>> We are suddenly seeing a lot of this seemingly nationwide from
>>>> Bandwidth and thinQ (which is a multi-carrier aggregator).  Anyone else?
>>>> ___
>>>> VoiceOps mailing list
>>>> VoiceOps@voiceops.org
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>>
>>>
>>>
>>> --
>>>
>>> Izzy Goldstein
>>>
>>> Chief Technology Officer - DevOps Master
>>>
>>> Main: (212) 477-1000 x 2085 <(212)%20477-1000>
>>>
>>> Direct: (929) 477-2085
>>>
>>> Website: https://telego.com/
>>>
>>>
>>>
>>>
>>> Confidentiality Notice: This e-mail may contain confidential and/or
>>> privileged information. If you are not the intended recipient or have
>>> received this e-mail in error please notify us immediately by email reply
>>> and destroy this e-mail. Any unauthorized copying, disclosure or
>>> distribution of the material in this e-mail is strictly forbidden. Any
>>> views or opinions presented in this email are solely those of the author
>>> and do not necessarily represent those of TeleGo (T). Employees of TeleGo
>>> are expressly required not to make defamatory statements and not to
>>> infringe or authorize any infringement of copyright or any other legal
>>> right by email communications. Any such communication is contrary to TeleGo
>>> policy and outside the scope of the employment of the individual concerned.
>>> TeleGo will not accept any liability in respect of such communication, and
>>> the employee responsible will be personally liable for any damages or other
>>> liability arising.
>>>
>>>
>>> TeleGo Hosted PBX <https://youtu.be/DaT8YAZ4V0w>
>>>
>> ___
>> 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 completion errors (503) from multiple carriers

[Carlos Alvarez via VoiceOps]

This is ongoing, and affecting BW to multiple destination carriers.  We are
not on prepaid with BW.

There is a known BW issue to T-Mobile, but this is to other carriers.



On Tue, Aug 30, 2022 at 12:05 PM Izzy Goldstein - TeleGo <
igoldst...@telego.net> wrote:

> Thinq had an issue this morning,  which was resolved
> they had a issue applying the balance to accounts, so calls were rejected
> with a 503 funds required
>
> i dont have any issues with bandwidth
>
> On Tue, Aug 30, 2022 at 3:01 PM Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>> We are suddenly seeing a lot of this seemingly nationwide from Bandwidth
>> and thinQ (which is a multi-carrier aggregator).  Anyone else?
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>
>
> --
>
> Izzy Goldstein
>
> Chief Technology Officer - DevOps Master
>
> Main: (212) 477-1000 x 2085 <(212)%20477-1000>
>
> Direct: (929) 477-2085
>
> Website: https://telego.com/
>
>
>
>
> Confidentiality Notice: This e-mail may contain confidential and/or
> privileged information. If you are not the intended recipient or have
> received this e-mail in error please notify us immediately by email reply
> and destroy this e-mail. Any unauthorized copying, disclosure or
> distribution of the material in this e-mail is strictly forbidden. Any
> views or opinions presented in this email are solely those of the author
> and do not necessarily represent those of TeleGo (T). Employees of TeleGo
> are expressly required not to make defamatory statements and not to
> infringe or authorize any infringement of copyright or any other legal
> right by email communications. Any such communication is contrary to TeleGo
> policy and outside the scope of the employment of the individual concerned.
> TeleGo will not accept any liability in respect of such communication, and
> the employee responsible will be personally liable for any damages or other
> liability arising.
>
>
> TeleGo Hosted PBX <https://youtu.be/DaT8YAZ4V0w>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Call completion errors (503) from multiple carriers

[Carlos Alvarez via VoiceOps]

We are suddenly seeing a lot of this seemingly nationwide from Bandwidth
and thinQ (which is a multi-carrier aggregator).  Anyone else?
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Numbers listed as spam by Hiya

[Carlos Alvarez via VoiceOps]

Well one is run by CTIA so presumably official. But does it work?

— 
Sent from my iPhone

> On Aug 25, 2022, at 3:02 PM, Alex Balashov via VoiceOps 
>  wrote:
> 
> 
>> On Aug 25, 2022, at 2:17 PM, Carlos Alvarez via VoiceOps 
>>  wrote:
>> 
>> That feels so much like a mafia extortion plan.  Pay us to not screw you 
>> over.
> 
> Seriously. How are we even supposed to know about these registries, if not 
> for this list? What makes them in any sense official? Nothing? Who put them 
> in charge? Are there more registries? Do you have to pay the extortion for 
> both registries to be sure? 
> 
> If not for the fact that it’s an expedient business decision, I think 
> everyone here should refuse to comply in principle.
> 
> I’m as far from pro-spam as Heaven is from Earth, but this is beyond 
> ridiculous.
> 
> — Alex
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Numbers listed as spam by Hiya

[Carlos Alvarez via VoiceOps]

That feels so much like a mafia extortion plan.  Pay us to not screw you
over.

That said, any opinions on the effectiveness of the two recommended
registries here?  Has someone paid the extortion and seen a benefit?


On Wed, Aug 24, 2022 at 5:58 PM Calvin Ellison 
wrote:

> There is also https://www.registeredcaller.com/ run by CTIA and iconectiv.
>
>
>
> Calvin Ellison
>
> Systems Architect
>
> calvin.elli...@voxox.com
>
> +1 (213) 285-0555
>
> <http://voxox.com>
>
> <https://www.facebook.com/VOXOX/>
> <https://www.instagram.com/voxoxofficial/>
> <https://www.linkedin.com/company/3573541/admin/>
> <https://twitter.com/Voxox>
>
> The information contained herein is confidential and privileged
> information or work product intended only for the individual or entity to
> whom it is addressed. Any unauthorized use, distribution, or copying of
> this communication is strictly prohibited. If you have received this
> communication in error, please notify me immediately.
>
>
> On Wed, Aug 24, 2022 at 5:57 PM Calvin Ellison 
> wrote:
>
>> Try listing your numbers at https://freecallerregistry.com/fcr/.
>>
>> >First Orion, Hiya, and Transaction Network Services ("Analytics
>> Engines") have partnered to streamline the telephone number registration
>> process. This free portal helps entities reach these Analytics Engines that
>> support major wireless and wireline carriers in the US.
>>
>>
>>
>> Calvin Ellison
>>
>> Systems Architect
>>
>> calvin.elli...@voxox.com
>>
>> +1 (213) 285-0555
>>
>> <http://voxox.com>
>>
>> <https://www.facebook.com/VOXOX/>
>> <https://www.instagram.com/voxoxofficial/>
>> <https://www.linkedin.com/company/3573541/admin/>
>> <https://twitter.com/Voxox>
>>
>> The information contained herein is confidential and privileged
>> information or work product intended only for the individual or entity to
>> whom it is addressed. Any unauthorized use, distribution, or copying of
>> this communication is strictly prohibited. If you have received this
>> communication in error, please notify me immediately.
>>
>>
>> On Wed, Aug 24, 2022 at 4:09 PM Carlos Alvarez via VoiceOps <
>> voiceops@voiceops.org> wrote:
>>
>>> This just started affecting a tiny law office that does no outbound
>>> marketing, and no unsolicited calls.  Purely engagement calls.  And
>>> suddenly they just reported that this week their calls are being marked as
>>> spam possible.
>>>
>>> This is getting really stupid.
>>>
>>> And yes I do know for sure they don't make improper calls.  In fact the
>>> call volume is a few dozen a day.
>>>
>>> ___
>>> 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] Numbers listed as spam by Hiya

[Carlos Alvarez via VoiceOps]

This just started affecting a tiny law office that does no outbound
marketing, and no unsolicited calls.  Purely engagement calls.  And
suddenly they just reported that this week their calls are being marked as
spam possible.

This is getting really stupid.

And yes I do know for sure they don't make improper calls.  In fact the
call volume is a few dozen a day.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Numbers listed as spam by Hiya

[Carlos Alvarez via VoiceOps]

LOL, no.  One does medical billing, the other does customer surveys.  In
both cases, the call recipients have an established business relationship
and "deserve" the calls.  A lot of people just don't want calls period,
which I get also.  There also appears to be some point where the marking is
automatic based on volume and short call duration.


On Wed, Aug 24, 2022 at 10:24 AM Jay Hennigan  wrote:

> On 8/24/22 07:34, Carlos Alvarez via VoiceOps wrote:
> > Not sure if that was meant tongue in cheek, but the issue is far more
> > complicated.  Or maybe you have a different definition of spam.  We have
> > customers making legit business calls that still get marked as
> > spam/scam, because there's no validation of the reports.
>
> If the recipients of your customers' legit business calls consistently
> mark them as spam to the point where the numbers wind up on blocklists,
> and your customers need to routinely rotate their outbound numbers in
> order to continue to deliver their message, indeed it sounds like there
> is indeed a substantial difference of opinion as to the definition of spam.
>
> Are any of your customers perhaps in the automobile warranty business?
>
> --
> 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

Re: [VoiceOps] Numbers listed as spam by Hiya

[Carlos Alvarez via VoiceOps]

How?  I have no idea, all I can tell you is the experience we see.  Maybe
Fred's comment has some merit if Peerless is either allowing actual spam,
or re-assigning numbers too quickly (for new numbers).

Your porting experience is something I haven't seen, but we haven't
mass-moved numbers in a long time.  If Peerless is the common denominator...

Oh, wait, have you checked the attestation level for these calls?  Are the
calls with a Peerless DID going out via Peerless?


On Wed, Aug 24, 2022 at 7:33 AM Dovid Bender  wrote:

> How is Bandwidth on top of this? We currently have about 18k DID’s with
> peerless. The issue is since most are DID’s that were allocated to
> Peerless, even if we port them out they will still be spam. Two interesting
> numbers come to mind
> 1) My personal number (which I never use for CLI)  was form RNK. I ported
> the number to a LEC in NYC and then eventually to Peerless. Once RNK went
> away the range it was in was re-assigned to Peerless. That number is listed
> as spam.
> 2) I have another personal number that started at Verizon and was ported
> to Peerless. That number is NOT listed as spam.
>
> The short term solution seems to be to get DIDs whose range is not
> defaulted as spam and then port them to Peerless/Telnyx etc.
>
> On Wed, Aug 24, 2022 at 10:16 Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>> We've had a lot of numbers from thinQ show up as spam right away, and a
>> small number from Bandwidth.  Generally though, Bandwidth is pretty good on
>> this.  It's possible (not an accusation) that the aggregators are recycling
>> numbers quickly.  We have a couple of customers who do legit outbound
>> business dialing and get marked as spam, so they rotate a lot of numbers.
>> This creates the problem if we or our carrier were to sell any of those to
>> others too soon.
>>
>> I don't know what your volume is, but for us Bandwidth was far less
>> expensive than Telnyx.  Around 8k DIDs and half a million minutes.  Pretty
>> small, but within the BW minimums.
>>
>>
>> On Wed, Aug 24, 2022 at 7:04 AM Dovid Bender via VoiceOps <
>> voiceops@voiceops.org> wrote:
>>
>>> Hi,
>>>
>>> We primarily purchase numbers from Telnyx and Peerless. Lately any
>>> number that we purchase is automatically listed as spam. I searched through
>>> both of their stocks for random numbers in random area codes (50+ numbers)
>>> and every time Hiya says it's likely SPAM. I presume they are marking any
>>> carrier where it's easy to get numbers spam. Has anyone fought back against
>>> this or are people just going with larger carriers like inteliquent/VZ etc?
>>>
>>> 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

Re: [VoiceOps] Numbers listed as spam by Hiya

[Carlos Alvarez via VoiceOps]

Not sure if that was meant tongue in cheek, but the issue is far more
complicated.  Or maybe you have a different definition of spam.  We have
customers making legit business calls that still get marked as spam/scam,
because there's no validation of the reports.  It's just mob rule.
Eventually the entire number pool will be spam/scam, no?


On Wed, Aug 24, 2022 at 7:23 AM Fred Posner via VoiceOps <
voiceops@voiceops.org> wrote:

> Doesn’t it make sense to block numbers from carriers that send spam?
>
> Fred Posner
> f...@palner.com
>
>
>
>
> > On Aug 24, 2022, at 10:03 AM, Dovid Bender via VoiceOps <
> voiceops@voiceops.org> wrote:
> >
> > Hi,
> >
> > We primarily purchase numbers from Telnyx and Peerless. Lately any
> number that we purchase is automatically listed as spam. I searched through
> both of their stocks for random numbers in random area codes (50+ numbers)
> and every time Hiya says it's likely SPAM. I presume they are marking any
> carrier where it's easy to get numbers spam. Has anyone fought back against
> this or are people just going with larger carriers like inteliquent/VZ etc?
> >
> > 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

Re: [VoiceOps] Numbers listed as spam by Hiya

[Carlos Alvarez via VoiceOps]

We've had a lot of numbers from thinQ show up as spam right away, and a
small number from Bandwidth.  Generally though, Bandwidth is pretty good on
this.  It's possible (not an accusation) that the aggregators are recycling
numbers quickly.  We have a couple of customers who do legit outbound
business dialing and get marked as spam, so they rotate a lot of numbers.
This creates the problem if we or our carrier were to sell any of those to
others too soon.

I don't know what your volume is, but for us Bandwidth was far less
expensive than Telnyx.  Around 8k DIDs and half a million minutes.  Pretty
small, but within the BW minimums.


On Wed, Aug 24, 2022 at 7:04 AM Dovid Bender via VoiceOps <
voiceops@voiceops.org> wrote:

> Hi,
>
> We primarily purchase numbers from Telnyx and Peerless. Lately any number
> that we purchase is automatically listed as spam. I searched through both
> of their stocks for random numbers in random area codes (50+ numbers) and
> every time Hiya says it's likely SPAM. I presume they are marking any
> carrier where it's easy to get numbers spam. Has anyone fought back against
> this or are people just going with larger carriers like inteliquent/VZ etc?
>
> 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

Re: [VoiceOps] Splitting voice and SMS

[Carlos Alvarez via VoiceOps]

I appreciate the responses here.  It does appear that a split NNID is
something they've done before, but can't be done (or has some problems)
with Bandwidth.  So Twilio says they just won't try.  I've offered the
customer the forwarding and even the SIP option.


On Wed, Aug 17, 2022 at 4:05 PM Ross Tajvar  wrote:

> SMS routing is generally handled by NetNumber's routing database (the name
> escapes me at the moment). NNIDs are the routing identifiers that they use
> - perhaps they meant NNID vs SSID?
>
> Twilio has a "hosted messaging" service, I think, which is where they
> SMS-enable your number on their platform by changing the NNID to theirs
> while leaving the voice-routing intact. But that process lead to a lot of
> fraud across lots of carriers, so it's more restricted now.
>
> On Wed, Aug 17, 2022 at 6:36 PM Chris Aloi via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>> We’ve done this, essentially porting away the SMS piece of a number. From
>> my experience, Bandwidth doesn’t allow “3rd party SMS enablement” of their
>> numbers, but INTQ does.  I have a subset of my numbers with INTQ
>> specifically because of this.
>>
>> ---
>> Christopher Aloi
>> cta...@gmail.com
>> Sent from my iPhone
>>
>> On Aug 17, 2022, at 6:21 PM, Carlos Alvarez via VoiceOps <
>> voiceops@voiceops.org> wrote:
>>
>> 
>> I mentioned this as an option, but the scheduling vendor didn't like the
>> idea.  I'm guessing they don't have a billing method for this.  Right now
>> it's on hold until he can get someone on his tech side involved.  I was
>> more just curious about his concept that he thinks they have done a split
>> before.  He may be completely mistaken.
>>
>>
>>
>> On Wed, Aug 17, 2022 at 3:15 PM Matthew Duggan 
>> wrote:
>>
>>> Hi There,
>>>
>>> Twilio Gold Partner here. If they port the number to Twilio then using
>>> Twilio Programmable Voice they calls could be forwarded either via sip or
>>> pstn back to yourselves.
>>>
>>> They would have to pay Twilio the Egress cost. Feel free to message me
>>> offline for further assistance.
>>>
>>> Best Regards,
>>>
>>> *Matthew Duggan | Head of DevOps*
>>> *Mobile:* +447954163438
>>> *Phone:* +44 (0)345 8800 808
>>> *Email:* matthew.dug...@ciptex.com
>>> *Address:* Peter House, Oxford Street, Manchester M1 5AN, United Kingdom
>>>
>>> *www.ciptex.com* <http://ciptex.com/>
>>> [image: Logo] <http://ciptex.com/> [image: linkedin icon]
>>> <https://www.linkedin.com/company/ciptex/> [image: facebook icon]
>>> <https://www.facebook.com/ciptex> [image: twitter icon]
>>> <https://twitter.com/ciptex> [image: youtube icon]
>>> <https://www.youtube.com/channel/UC8puyBCaT5tomGyMcnlbmsA?reload=9>
>>> [image: Banner] <http://ciptex.com/>
>>> Legal: CAUTION - This message may contain privileged and confidential
>>> information intended only for the use of the addressee named above. If you
>>> are not the intended recipient of this message you are hereby notified that
>>> any use, dissemination, distribution or reproduction of this message is
>>> prohibited. If you have received this message in error please notify Ciptex
>>> Ltd. immediately. Any views expressed in this message are those of the
>>> individual sender and may not necessarily reflect the views of Ciptex Ltd.
>>> Ciptex Ltd - Registered Office: Chancery House, 30 St. Johns Road, Woking,
>>> Surrey, GU21 7SA. Company Number: 05671321
>>> --
>>> *From:* VoiceOps  on behalf of Jorge
>>> Guntanis via VoiceOps 
>>> *Sent:* Wednesday, August 17, 2022 11:04:12 PM
>>> *To:* Carlos Alvarez 
>>> *Cc:* VoiceOps 
>>> *Subject:* Re: [VoiceOps] Splitting voice and SMS
>>>
>>>
>>> CAUTION: This email may have originated from outside of the
>>> organization. Do not click links or open attachments unless you recognize
>>> the sender and know the content is safe.
>>>
>>> If they are already in twilio, they can create a SIP Trunk where you'd
>>> connect to to get the inbound calls.
>>> That way SMS stays at twilio and voice goes to you.
>>>
>>> I'm not aware of another way to do it cleanly.
>>>
>>> El mié, 17 de ago. de 2022 3:56 p. m., Carlos Alvarez via VoiceOps <
>>> voiceops@voiceops.org> escribió:
>>>
>>> We had an odd customer request, via a vendor trying to 

Re: [VoiceOps] Splitting voice and SMS

[Carlos Alvarez via VoiceOps]

I mentioned this as an option, but the scheduling vendor didn't like the
idea.  I'm guessing they don't have a billing method for this.  Right now
it's on hold until he can get someone on his tech side involved.  I was
more just curious about his concept that he thinks they have done a split
before.  He may be completely mistaken.



On Wed, Aug 17, 2022 at 3:15 PM Matthew Duggan 
wrote:

> Hi There,
>
> Twilio Gold Partner here. If they port the number to Twilio then using
> Twilio Programmable Voice they calls could be forwarded either via sip or
> pstn back to yourselves.
>
> They would have to pay Twilio the Egress cost. Feel free to message me
> offline for further assistance.
>
> Best Regards,
>
> *Matthew Duggan | Head of DevOps*
> *Mobile:* +447954163438
> *Phone:* +44 (0)345 8800 808
> *Email:* matthew.dug...@ciptex.com
> *Address:* Peter House, Oxford Street, Manchester M1 5AN, United Kingdom
>
> *www.ciptex.com* <http://ciptex.com/>
> [image: Logo] <http://ciptex.com/> [image: linkedin icon]
> <https://www.linkedin.com/company/ciptex/> [image: facebook icon]
> <https://www.facebook.com/ciptex> [image: twitter icon]
> <https://twitter.com/ciptex> [image: youtube icon]
> <https://www.youtube.com/channel/UC8puyBCaT5tomGyMcnlbmsA?reload=9>
> [image: Banner] <http://ciptex.com/>
> Legal: CAUTION - This message may contain privileged and confidential
> information intended only for the use of the addressee named above. If you
> are not the intended recipient of this message you are hereby notified that
> any use, dissemination, distribution or reproduction of this message is
> prohibited. If you have received this message in error please notify Ciptex
> Ltd. immediately. Any views expressed in this message are those of the
> individual sender and may not necessarily reflect the views of Ciptex Ltd.
> Ciptex Ltd - Registered Office: Chancery House, 30 St. Johns Road, Woking,
> Surrey, GU21 7SA. Company Number: 05671321
> ------
> *From:* VoiceOps  on behalf of Jorge
> Guntanis via VoiceOps 
> *Sent:* Wednesday, August 17, 2022 11:04:12 PM
> *To:* Carlos Alvarez 
> *Cc:* VoiceOps 
> *Subject:* Re: [VoiceOps] Splitting voice and SMS
>
>
> CAUTION: This email may have originated from outside of the organization.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
> If they are already in twilio, they can create a SIP Trunk where you'd
> connect to to get the inbound calls.
> That way SMS stays at twilio and voice goes to you.
>
> I'm not aware of another way to do it cleanly.
>
> El mié, 17 de ago. de 2022 3:56 p. m., Carlos Alvarez via VoiceOps <
> voiceops@voiceops.org> escribió:
>
> We had an odd customer request, via a vendor trying to provide them with
> automated scheduling services via SMS.  They are asking us to "release the
> SSID" to allow them to do SMS on the number, but we keep the voice.  I'm
> unaware of this ability, and they even said that so far, most carriers
> won't even discuss it with them.
>
> Their service rides on the Twilio API, and I *think* Twilio uses
> Bandwidth.  This number is currently with Bandwidth.  So I don't know if
> that might make a difference.
> ___
> 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] Splitting voice and SMS

[Carlos Alvarez via VoiceOps]

We had an odd customer request, via a vendor trying to provide them with
automated scheduling services via SMS.  They are asking us to "release the
SSID" to allow them to do SMS on the number, but we keep the voice.  I'm
unaware of this ability, and they even said that so far, most carriers
won't even discuss it with them.

Their service rides on the Twilio API, and I *think* Twilio uses
Bandwidth.  This number is currently with Bandwidth.  So I don't know if
that might make a difference.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] [EXTERNAL] Re: Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...])

[Carlos Alvarez via VoiceOps]

Odd recommendation.  I've never been on a list with this behavior.  (Or
more precisely, not since the 90s when bandwidth mattered and everyone was
trying to conserve it and reduce "fluff.) Since I'm on two other busy
Mailman lists that have the reply-to-list behavior, I can say I've seen it
work fine.

And just now, I almost hit send before changing who I'm replying to.  I'd
appreciate the change.



On Wed, Jul 20, 2022 at 7:56 AM Hiers, David  wrote:

> Hi,
>
> I’m not aware of any recent changes to the list config, but I’ll check.
>
>
>
> The current “reply-to” behavior is the one generally recommended by the
> Mailman docs, which warn of weird email client behavior if you mess around
> with it.  I’m not beyond messing around with it, just don’t want to make
> things worse.
>
>
>
> Thanks,
>
>
>
> David
>
>
>
>
>
> *From:* VoiceOps  *On Behalf Of *Carlos
> Alvarez via VoiceOps
> *Sent:* Tuesday, July 19, 2022 4:30 PM
> *To:* voiceops@voiceops.org
> *Subject:* [EXTERNAL] Re: [VoiceOps] Mailman 'Reply-To' munging (was: Re:
> 9-8-8 dialing [...])
>
>
>
> *CAUTION:* This email originated from outside of the CDK organization.
> Exercise caution when clicking links or opening attachments, especially
> from unknown senders.
>
> If I do a reply on this list, it always puts the sender as the recipient,
> not the list.  This is remarkably stupid.  If I do a reply-all then it puts
> the list on CC and the sender in TO.
>
>
>
>
>
> On Tue, Jul 19, 2022 at 1:03 AM Nathan Anderson via VoiceOps <
> voiceops@voiceops.org> wrote:
>
> Nathan Anderson wrote:
>
> > (Quick off-topic note: did some setting on VoiceOps mailman get changed
> > halfway through the morning?  "From:" now shows voiceops list address
> > instead of original sender's -- which I'm fine with -- but then
> > "Reply-To" is getting added and set to sender.  So I now have to add
> > voiceops address to "To:" or "CC:" manually if I want my reply to go to
> > the list.  Not cool.)
>
> $%@#$%!#$
>
> https://mail.python.org/pipermail/mailman-users/2014-August/077673.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.python.org_pipermail_mailman-2Dusers_2014-2DAugust_077673.html=DwMFaQ=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ=aDhfQpGytZSGJYtPCZjJvd1wPTHsG2CgTdUxzN12zZmLZYzmWoUAWvkPLFYUrZ9Q=dEfdgZvMsHphycL7e4mQ3Lhr6wDiFoxcz0GsXXqP8wU=>
>
> Sounds to me like 'from_is_list' now == 'munged', and this is how Outlook
> behaves in this situation.
>
> Rrrrgh,
>
> -- Nathan
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops=DwMFaQ=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc=-GzOCp0ppLaBQPFaZ7lZ4bUUBQxpFBukitRP75oaRdQ=aDhfQpGytZSGJYtPCZjJvd1wPTHsG2CgTdUxzN12zZmLZYzmWoUAWvkPLFYUrZ9Q=eIS5bzlf8JC5ieP7y0ivcKbRWWTiWVGjuXwWmneO42w=>
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...])

[Carlos Alvarez via VoiceOps]

If I do a reply on this list, it always puts the sender as the recipient,
not the list.  This is remarkably stupid.  If I do a reply-all then it puts
the list on CC and the sender in TO.


On Tue, Jul 19, 2022 at 1:03 AM Nathan Anderson via VoiceOps <
voiceops@voiceops.org> wrote:

> Nathan Anderson wrote:
>
> > (Quick off-topic note: did some setting on VoiceOps mailman get changed
> > halfway through the morning?  "From:" now shows voiceops list address
> > instead of original sender's -- which I'm fine with -- but then
> > "Reply-To" is getting added and set to sender.  So I now have to add
> > voiceops address to "To:" or "CC:" manually if I want my reply to go to
> > the list.  Not cool.)
>
> $%@#$%!#$
>
> https://mail.python.org/pipermail/mailman-users/2014-August/077673.html
>
> Sounds to me like 'from_is_list' now == 'munged', and this is how Outlook
> behaves in this situation.
>
> Rrrrgh,
>
> -- 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] [External] Re: [External] Re: 9-8-8 dialing when an outside line access code (9) is being used

[Carlos Alvarez via VoiceOps]

On Mon, Jul 18, 2022 at 4:45 PM Hunter Fuller via VoiceOps <
voiceops@voiceops.org> wrote:

> I hate to tell y'all this, but not only do my users dial 9 from their
> faxes to get out, they also fax internally (interdepartmentally) with
> some frequency. So, yes, these users dial 4 digits from their fax
> machines.
>

I um...man.  I so wish I was confident that you're kidding.  I fear you're
not.


> first time we have ever had any issue with it; then at what point
> exactly were we "supposed to" have "seen the light" and migrated away
> from it? And what value would it have brought us at that time?
>

I didn't see anyone here saying you were wrong.  But I do think most would
say it's time to get away from old ways.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] [External] Re: 9-8-8 dialing when an outside line access code (9) is being used

[Carlos Alvarez via VoiceOps]

Weird, pretty much every old PBX I ran into had the fax lines on it, and
sometimes even alarm lines on it.  One of my early trainings with alarm
panel integration, in the 90s, was all about coordinating the dial-9 rules.

I'm old, and maybe you mean more recently.  I know we did a dial 9 in the
early 2000s, now I can't remember when most people dropped it.

On Mon, Jul 18, 2022 at 4:24 PM Nathan Anderson via VoiceOps <
voiceops@voiceops.org> wrote:

> Carlos Alvarez wrote:
>
> > Do your users still dial 9 from their fax machines?
>
> Not sure if serious or "haha your users probably still use fax
> machines" joke.  So I'll give a serious answer just in case: I can't
> recall ever running across a single instance of someone who has their
> fax line routed through their "conventional" PBX.  So they never dialed
> 9 from their fax machine to begin with.  And also since nobody expects
> to be able to dial local extensions from their fax machine, we set up a
> separate dialing plan for the fax port on the ATA that does not require
> the external line prefix.
>
> -- 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] [External] Re: 9-8-8 dialing when an outside line access code (9) is being used

[Carlos Alvarez via VoiceOps]

On Mon, Jul 18, 2022 at 3:46 PM Nathan Anderson via VoiceOps <
voiceops@voiceops.org> wrote:

>
> Exactly & here we are in complete agreement.  Carlos seems to be
> approaching this discussion from a perspective where modern endpoints
> are ubiquitous, which is fine and all, but it's simply not reality.
> The number of old key systems and PBXes out in the wild that are still
> in active use is not inconsequential and cannot be ignored.  We
> routinely come in to a new customer's facilities *only* to replace
> existing dialtone, because all they are after is better pricing /
> better support / etc. and their existing phone system "still works fine
> and we have no desire to forklift it out at present,
> thank-you-very-much".  This often means handing off to it via
> multi-port ATA or (best-case but rare) PRI.


Right, and their switch traps the 9 so you don't have to route it.  I may
be mistaken, but thought the original question was about routing on a
modern switch, where the 9 is not relevant.

Hah well (genuinely) good for you.  IME it is hard to break people of
> some of these habits.  And without the outside line prefix, those who
> insist on picking up the handset first to get the (simulated) dialtone
> have to face the interminable dialing timeouts.  I suppose you just
> take the position that if they want to avoid that, it's a simple matter
> of being willing to change how one does things, and that's how you've
> re-trained end users, but I guess we just tend to get the stubborn
> complainers?...
>

I explain to them what happened to the buggy whip makers.  Seriously,
coddling the lazy is bad for us all.

Do your users still dial 9 from their fax machines?
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] [External] Re: 9-8-8 dialing when an outside line access code (9) is being used

[Carlos Alvarez via VoiceOps]

Our user instructions have been telling them to dial like a cell phone for
over ten years.  So they do have a defacto send button; dial and then pick
up the handset or press the speaker or headset button.  Acceptance and
adoption has been great.  It was harder to get people to do this in 2005,
but everyone gets it now.  We had permissive dialing for a while (10-digit,
11-digit, 9+10-digit, 9+11-digit).  But as of somewhere around '16 we took
out the 9 completely.  And haven't required it since our years had single
digits.

I know, everyone is different, different needs, blah blah.  Too many
excuses for keeping old dead skeumorphs.


On Mon, Jul 18, 2022 at 12:22 PM Jay Hennigan via VoiceOps <
voiceops@voiceops.org> wrote:

> On 7/18/22 08:36, Carlos Alvarez wrote:
> > OP makes his own points against it, and none for.  As we add more and
> > more short numbers and possibly NPAs, the 9 becomes more problematic.
> > And is there really a switch out there in use today that needs it?
>
> Pretty much any conventional PBX where you have conventional phones and
> don't want a timeout. Even most SIP phones don't have a SEND button even
> though the INVITE is en-banc under the hood, so you need a dialplan with
> a timeout.
>
> IMHO, 9-8-8 is a boneheaded idea as it breaks NANP and causes ambiguity.
> In addition now that it's law look for all kinds of other mandated
> service codes. Lost your cat, dial 9-7-7. Need a jump start, 9-6-6,
> Alcoholics Anonymous 9-5-5, etc.
>
> --
> 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
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] [External] Re: 9-8-8 dialing when an outside line access code (9) is being used

[Carlos Alvarez]

OP makes his own points against it, and none for.  As we add more and more
short numbers and possibly NPAs, the 9 becomes more problematic.  And is
there really a switch out there in use today that needs it?

We have to kill old paradigms to move ahead.


On Sun, Jul 17, 2022 at 11:04 PM Ross Tajvar  wrote:

> re: dialing 9 - I understand the plight of having to deal with legacy
> expectations, but what's the point of sticking with this particular
> one? What makes it not-useless?
>
> On Mon, Jul 18, 2022 at 12:29 AM Hunter Fuller 
> wrote:
> >
> > We operate a system with the "dial 9" scheme (apparently "useless"
> > according to other posters - a truly insightful attitude that I love
> > to see on this list), so I can say that the expectation definitely is
> > NOT for people to dial 9911. In fact, there is a whole law about it,
> > which, like many, is written in blood:
> > https://www.fcc.gov/news-events/podcast/personal-story-behind-karis-law
> >
> > The difference is, if someone picks up a phone and dials 911, they
> > want 911. They don't want an "outside line" so that they can dial a
> > NANP 10-digit number beginning in 11, because no such number exists.
> > The problem is, such numbers DO exist that begin with 88, so, we are
> > in a bit of a pickle there. It seems the only solution is to do a
> > timeout... yeesh. (Unless I'm missing something.)
> >
> > Dialing 911 directly (not 9911, but just 911) has always worked here,
> > long before Kari's Law, and it works without delay, as it should. I'd
> > love to make 988 work the same way but I'm just not sure how to
> > accomplish that.
> >
> > --
> > Hunter Fuller (they)
> > Router Jockey
> > VBH M-1C
> > +1 256 824 5331
> >
> > Office of Information Technology
> > The University of Alabama in Huntsville
> > Network Engineering
> >
> >
> > --
> > Hunter Fuller (they)
> > Router Jockey
> > VBH M-1C
> > +1 256 824 5331
> >
> > Office of Information Technology
> > The University of Alabama in Huntsville
> > Network Engineering
> >
> >
> > On Fri, Jul 15, 2022 at 11:21 AM Brandon Svec
> >  wrote:
> > >
> > > It shouldn't be much different than 911.  9911 and 911 can both work
> just as 9988 and 988 can both work fine with most any PBX that can
> translate dial plan digits.
> > >
> > > There is potential conflict with systems that can't handle inter-digit
> timeouts to allow both 988 and 9888-555-1212, I guess.  But in that case I
> suppose the expectation would be to dial 9988 and 9911 already..
> > > Brandon
> > >
> > >
> > > On Fri, Jul 15, 2022 at 8:10 AM Zilk, David 
> wrote:
> > >>
> > >> How are folks dealing with allowing calls to 9-8-8 when an access
> code of 9 is used. Does this not cause a conflict when calling toll free
> numbers beginning with an NPA of 88x?
> > >>
> > >>
> > >>
> > >> 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
> > ___
> > 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] 9-8-8 dialing when an outside line access code (9) is being used

[Carlos Alvarez]

We stopped the useless "outside line" concept almost a decade ago.

On Fri, Jul 15, 2022 at 8:10 AM Zilk, David  wrote:

> How are folks dealing with allowing calls to 9-8-8 when an access code of
> 9 is used. Does this not cause a conflict when calling toll free numbers
> beginning with an NPA of 88x?
>
>
>
> 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

Re: [VoiceOps] Calls coming up as spam on mobile carriers

[Carlos Alvarez]

Does the hospital use this CLID to do "undesirable" calls such as
collections?  People can mark calls as spam on some carriers and with the
third party apps.  So spam or not, it happens.  We have a medical billing
company with this problem.

On Fri, Jul 8, 2022 at 10:08 AM Shawn L  wrote:

> We're having a strange one at $dayjob.  When one of our customers (in this
> case a hospital) calls a patient back on a cell phone, the calls are coming
> up with SPAM? in the caller id.  It seems to be happening with both Verizon
> and AT
>
> We've checked the the DIDs in question have and are sending the proper
> caller id, checked the Neustar database, etc. and can't find anything
> that's missing.  These are TDM calls.  They come in over multiple TDM PRIs
> and leave toward an AT tandem on a legacy TDM trunk group, so there's
> really no way to do STIR/SHAKEN call attesting.
>
> Our switch vendor (Ribbon / Genband / Nortel)  also mentioned that they've
> had other clients with the issue and it seems to be limited to calls placed
> to mobile carriers.  Another telco was able to find an AT portal to
> register the numbers as legitimate, but it only lasted for about a month
> before they had to do it again.
>
> I haven't researched where at AT they might have entered the numbers,
> but that doesn't seem like a valid option for a hospital with a thousand
> numbers.
>
> Just wondering if others have seen this, and if anyone knows of a way to
> resolve it.
>
> 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] Getting a century block and/or specific prefix in NPA 760

[Carlos Alvarez]

We have a customer who relies heavily on image marketing who has requested
this.  We use Bandwidth and thinQ, neither of which have much for
sequential numbers there.  And for some reason they asked this:

***
We will need a block of 100 numbers.  Hopefully you can get close to
760-459-4500 as the first number in the block.  We have to have area code
760.  As soon as I get a count on the number of phones needed I will let
you know.
***

They are a good customer with hundreds of phones with us, and I know they'd
pay if we could figure out some reasonable way to do it.  Ideas?
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] ATAs with 90v Ring

[Carlos Alvarez]

Not sure on your reason for this, but I can tell you that I have a
Grandstream connected to a 60s rotary phone and it rings just as strong as
ever.

https://studio.youtube.com/video/r88JcZQE3B0/edit


On Thu, Mar 24, 2022 at 2:35 PM Mike Hammett  wrote:

> I'm looking for ATAs that produce a 90-volt ring. My Zhone only does 40v
> and my Grandstream only does 52v. It looks like the Cisco SPA122 used to,
> but it's EOS.
>
>
>
> -
> 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] Non-ITG Traceback Requests

[Carlos Alvarez]

We had someone demand info once, but he didn't cite any laws and just
claimed he was entitled to it because he was being harassed (collections
company).  Of course you can imagine how much sand we told him to pound.

In your case, I would default to no info given, CPNI or not, unless there's
a legal requirement to provide it.  It's hard to prove a negative, but I've
never heard of any requirement to provide customer info or even to have ANY
conversation with a random person.


On Wed, Mar 23, 2022 at 9:55 AM Calvin Ellison 
wrote:

> Has anyone received a traceback request from a party other than the ITG or
> a law enforcement agency?
>
> Is there any law or rule that requires a carrier to respond to a traceback
> request from the general public?
>
> A private individual has contacted us requesting a traceback based on our
> STIR/SHAKEN signature, but they are not a member of the ITG and do not have
> any accompanying legal device like a subpoena. They also do not appear to
> be a carrier, and I question whether this person's own carrier should be
> passing the Identity header to them at all. This person has been citing 47
> U.S. Code § 222(d)(2), claiming there is no restriction on who CPNI can be
> shared with, but I don't believe this gives them any standing to request a
> trackback without a legal device.
>
> We've engaged our own counsel about this, but I'm curious what
> other carriers have been experiencing.
>
>
>
> Calvin Ellison
>
> Systems Architect
>
> calvin.elli...@voxox.com
>
> +1 (213) 285-0555
>
> 
>
> 
> 
> 
> 
>
> The information contained herein is confidential and privileged
> information or work product intended only for the individual or entity to
> whom it is addressed. Any unauthorized use, distribution, or copying of
> this communication is strictly prohibited. If you have received this
> communication in error, please notify me immediately.
> ___
> 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 SMS Campaign Fees

[Carlos Alvarez]

On Wed, Feb 23, 2022 at 12:35 PM Peter Beckman  wrote:

>
>   I think you overestimate the technical prowress of a small laudromat who
>   simply wants to notify customers that their laundry is ready!
>

No, it's the reverse.  Because they have no ability to do this, they
outsource it.  And *that* company is the one that abuses you on their
behalf and for others who pay them to.

Everyone I know gets text spam except me.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] T-Mobile Originated Calls - No Ringback

[Carlos Alvarez]

A few people have reported this as a fault on our end.  But I've also heard
it from friends who use T-Mobile and the complainers agree it sometimes
happens to numbers that are not ours.  The complaints originate from Los
Angeles, Vegas, Phoenix, and others.  So it's just more T-Mobile/Sprint
idiocy all over.


On Mon, Jan 31, 2022 at 12:21 PM Alex Balashov 
wrote:

> I’ve experienced this as a T-Mobile customer in Georgia, at least calling
> my parents locally who are on Verizon. I get +/- 1 ringback tone and then
> dead air until they answer. I was wanting to ask the list if this is a
> “thing” or just a peculiarity of our area.
>
> > On Jan 31, 2022, at 2:05 PM, Gabriel Kuri via VoiceOps <
> voiceops@voiceops.org> wrote:
> >
> > I'm not sure if this has come up here before, I couldn't find anything
> specific, but I'm seeing an issue where calls originating from T-Mobile to
> other carriers are not generating ringback. The call is indeed ringing on
> the other end, but on the T-Mobile phone, it's just dead air until the
> person on the other end answers the call. It's not all calls, but it is
> reproducible to certain phone numbers and reproducible using various
> T-Mobile customers. It's not limited to a single phone T-Mobile
> number/customer. Further troubleshooting has shown that calls from other
> providers (ie AT, Verizon Wireless) do not have this problem to the same
> numbers the issue can be reproduced from T-Mobile. It's only calls from
> T-Mobile numbers to other phone numbers outside of T-Mobile so far.
> >
> > The no ringback issue seems to occur whether you're on wifi calling or
> on a cell tower. All of the T-Mobile users we can reproduce the issue with
> are in Southern California. Not sure if any of this matters.
> >
> > I tried to deal with customer service and opened a ticket that
> supposedly was escalated to engineering, but of course that fell on deaf
> ears and the response I got was basically "Can't reproduce, it's not our
> problem" 8-/ ...
> >
> > Any T-Mobile engineers on this list that could help or any
> recommendations on how to raise attention to this problem to someone at
> T-Mobile with a clue?
> >
> > Gabe
> >
> >
> > ___
> > VoiceOps mailing list
> > VoiceOps@voiceops.org
> > https://puck.nether.net/mailman/listinfo/voiceops
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] thinq completely down

[Carlos Alvarez]

I tested two local numbers in two rate centers and they were fine just now.


On Mon, Jan 24, 2022 at 1:32 PM Keln Taylor  wrote:

> Yes.  Incoming calls (at least my toll free DIDS) are not working.
>
>
> On Mon, Jan 24, 2022 at 2:13 PM jd  wrote:
>
>> Anyone else experiencing thinQ.io being down?
>> ___
>> 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 is a restricted business?

[Carlos Alvarez]

I'm not aware of some VoIP banking issue in the US, but you didn't specify
the country.  I've never heard of Wise.  But I don't think "VoIP" is an
industry, category, or business type.  We always choose "telecom" as the
type.  Paypal and Amex recently made a change where if you choose telecom
as your industry, you cannot use Paypal enhanced payments (new system)
along with Amex and with third party billing solutions.  What a weird
combo, and a pain.  We appealed and have no response, but someone just told
me yesterday that they paid with an Amex.

Individual companies may have their own policies, like this.  Wells Fargo
and Chase, I can tell you from experience, is happy to have our business.


On Wed, Jan 5, 2022 at 6:12 AM Oren Yehezkely  wrote:

> Hello,
>
> Happy New Year everyone.
>
> I recently became aware of the fact that banks (and financial
> institutions) define any business that merely mentions the word VoIP as
> restricted. Meaning they would not allow such a business to work with them.
> As if VoIP is some kind of an illegal substance.
> I am confident that when it comes to larger players they are not defined
> as a VoIP business...
>
> One company (Wise/Wisetransfer) even claimed that their regulation
> requires them to do that.
>
> I wonder if you have any more information and how do you deal with this.
>
> Thanks,
> Oren
> ___
> 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] Misrouting 911 Calls?

[Carlos Alvarez]

Sounds like this client is large enough to have a legal person/team on call
or on staff?  They should write a letter putting the carrier on notice that
they are in violation of the law, and in violation of their contract, and
they have X days to rectify or the contract is void.

You have to give one point to Comcast; they will consistently prove that
they are the worst telecom/ISP on the planet.



On Tue, Jan 4, 2022 at 11:41 AM Aaron C. de Bruyn via VoiceOps <
voiceops@voiceops.org> wrote:

> One of my clients has a large SIP trunk with Comcast based out of
> Washington State.
>
> They have all their offices across Oregon and Washington hooked into a
> FreePBX phone server that is attached to the Comcast SIP trunk.
>
> 911 calls *constantly* get misrouted to the local PSAP where the SIP trunk
> lives.
>
> I must have called Comcast 30 times over the last few years to try and get
> this addressed, but Comcast flat-out refuses to fix the issue.
>
> The short answer is that Comcast refuses to fix it.  In some (but not all)
> cases, our phone numbers are RCF'd numbers, so they don't actually exist on
> the trunk...and Comcast forcibly re-writes them to our 'main' number...and
> then routes the 911 call incorrectly.  In other cases, we have provided
> Comcast with the e911 information, they say it's updated, and then we find
> out months later (when an office dials 911 during an emergency) that it's
> still not correct.
>
> Not only does this affect 911 calls, but also customers who get the
> re-written caller ID and have no idea which office called them.
>
> The "easy" solution is to ditch Comcast and move to a provider that
> doesn't play the RCF and caller-ID-rewrite games.  Unfortunately my client
> is locked into their Comcast contract for another ~18 months.  Early
> termination would incur a ~$35,000 bill.
>
> Is there a list of PSAP numbers somewhere so I can set up an internal
> redirect to the PSAP 10-digit number?  I know those 10-digit numbers are
> guarded like Fort Knox, so I'm betting this option isn't very realistic.
>
> Maybe a separate service provider that can just handle 911 calls without
> "owning" my client's phone numbers?
>
> Any other thoughts on how I can route around Comcast brain damage?
>
> 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

Re: [VoiceOps] VoIP SMS Campaign Fees

[Carlos Alvarez]

Alarmist is warranted.  I am equally perplexed by the inconsistent rules,
the vague language, and by everyone insisting that T-Mobile will
unilaterally issue $10k fines per message.  On what authority?  What is the
appeals process?  Dozens of questions, nearly no answers.

I just sent a text from one of my business numbers in response to a client
who texted it.  Is this a campaign?

The whole thing where everything that's not another cell phone is
considered automated and not P2P seems disgusting, if not actually illegal
and fraudulent.


On Tue, Nov 16, 2021 at 4:16 PM Oren Yehezkely  wrote:

> Nate,
>
> See a thread I started a few months ago about this matter.
> I got a lot of negative responses for being an alarmist.
>
> Basically these requirements are set by the different mobile carriers and
> they are not the same.
>
> Yes, they all consider customers to be businesses (A2P). No customer is a
> consumer (P2P) in the eyes of these
> carriers, TCR and even the person who answered you before.
>
> I don't think that the penalty is $10,000 but VI may be trying to deter
> you from using SMS
> without registering. You may want to consider using a different carrier
> for SMS.
> Other carriers will also offer to help you register with TCR.
>
> Good luck with dealing with that headache, feel free to contact me off
> list to see if we can share some information
> on dealing with this.
>
> Regards,
> Oren
>
> On Mon, Nov 15, 2021 at 3:37 PM Nate Burke  wrote:
>
>> Sorry if this was already discussed and I missed it.  I saw a notice on
>> our Voip Innovations account today that any business DID's that send SMS
>> messages to a consumer in any way now have to be registered with
>> 'Campaignregistry.com'  Looks like this requires a $200 signup, and then
>> potentially $10/month/DID.  Anyone already gone through this?  Talking
>> to VI, it seems they're not even sure, but it's a VI requirement to be
>> registered by Dec 15.
>>
>> The whole process seems confusing.  VI Makes it seem like non-compliance
>> will be expensive. $10,000/violation keeps being referenced.
>>
>> Would each one of my customers be considered a separate campaign at
>> $10/month?
>> ___
>> 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] some of my customers DID show as Possible Spam

[Carlos Alvarez]

Neither use predictive, but have live humans dialing.  Both leave a message
on VM if nobody is there so the calls are not short duration.  The one
calling for governments (and power companies, and such) are not calling for
politicians.  They are calling for the sitting body of government, or the
energy supplier, etc.  They also respect the DNC, but nobody puts
themselves on that any more.  They just hit "spam" on their call blocking
apps.

These chickens are being marked as ducks.  I get that consumers are fed up,
now they are creating their own new problem.

The only thing these customers have not tried is the five minute rolling
CLID.  And for the medical practice one, that's problematic since they are
trying to use a specific number that will get known.  So most patients do
answer it, some percentage instead consider it spam.


On Tue, Nov 16, 2021 at 9:33 AM Jay Hennigan  wrote:

> On 11/15/21 16:01, Carlos Alvarez wrote:
> > You cut out the part where it was their city government calling, wanting
> > to know what the citizens would like "fixed" and focused on in the
> > communities.  You'd opt out of this?  Do you also not vote?
>
> I vote with a ballot at a polling place or by mail, not by engaging with
> random unsolicited call center workers. I've found that political
> polling calls and survey calls are often "push" polls, often rather
> invasive in terms of personal questions, lengthier than needed, and
> interrupt me at inopportune times. Politicians and survey companies
> lobbied to get themselves excluded from the TCPA and the result is that
> the only mass unsolicited calls that those on the DNC list get are from
> spammers/scammers and politicians/pollsters.
>
> In my opinion the politicians made a mistake with their lobbying. They
> should honor Do Not Call listings. They're making unsolicited bulk calls
> to those who specifically went through a process to say that they don't
> want them.
>
> > Also not a collection agency, it's the primary biller, and the customer
> > has opted into the calls in writing.  If they go to collections, my
> > customer actually sends them out.  They only do the gentle calls, which
> > also includes appointments.  So by marking them bad, they may also not
> > receive calls to set consultations with their doctor.
>
> I'm not disagreeing that it's a real problem for both your customer and
> in some cases those that they are trying to reach. Your problem is that
> your customer's operation passes the duck test. It looks like a duck,
> quacks like a duck, and swims like a duck.
>
> Multiple calls in succession and/or simultaneously from the same ANI, a
> high percentage of which disconnect within seconds with the BYE coming
> from the customer side (they are immediately getting hung-up on), some
> of which are to numbers on the Do Not Call list, as well as many
> customer flags as spam calls.
>
> Is your customer is using a predictive dialer? If so, the called parties
> have gotten very attuned to the dead silence for a second or two after
> answer and that at least in my case will pretty much assure an immediate
> disconnect from the called party side, a big red flag for the algorithm.
>
> It's a tough situation but from the carrier's perspective they are
> offering their paying subscribers a benefit that the subscribers want.
> Your customer needs to make their operation behave less like a duck. The
> video suggests several tweaks. Of course the spammers are also going to
> try to crack the algorithms, so it's a cat-and-mouse game. STIR-SHAKEN
> will help. An honest CNAM will help.
>
> --
> 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
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] some of my customers DID show as Possible Spam

[Carlos Alvarez]

You cut out the part where it was their city government calling, wanting to
know what the citizens would like "fixed" and focused on in the
communities.  You'd opt out of this?  Do you also not vote?

Also not a collection agency, it's the primary biller, and the customer has
opted into the calls in writing.  If they go to collections, my customer
actually sends them out.  They only do the gentle calls, which also
includes appointments.  So by marking them bad, they may also not receive
calls to set consultations with their doctor.



On Mon, Nov 15, 2021 at 12:50 PM Jay Hennigan  wrote:

> On 11/15/21 09:20, Carlos Alvarez wrote:
> > I brought this up on the list previously, you can probably go find that
> > last discussion.  We have two customers who see this all the time.
> > Primary problem is with T-Mobile, where anyone can mark things.  It's
> > social or crowd-sourced "intelligence."  Then a few other companies
> > started doing the same, and customers can download a call marking app.
>
>  From the video linked here earlier, it looks like it's much more than
> call marking. It's also pattern recognition, average call duration, and
> other factors.
>
> > The two customers who have this problem often are call centers.  One
> > doing medical billing, the other doing legit market research and
> > polling.
>
> If I were a T-Mobile subscriber, I'd definitely want calls from "legit
> market research and polling" companies to my cell phone so marked.
> Certainly so in the weeks before an election, and probably year round.
>
> Likewise, if I were in debt to medical providers to the point where I
> was getting calls from collection agencies, I probably would want those
> flagged as well.
>
> Carriers are going to do things that benefit their relationship with
> their subscribers, not things that benefit a non-customer outbound call
> center. If the carrier's subscribers raise a stink about false
> positives, they will probably make an effort to fix it.
>
> --
> 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
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] some of my customers DID show as Possible Spam

[Carlos Alvarez]

I brought this up on the list previously, you can probably go find that
last discussion.  We have two customers who see this all the time.  Primary
problem is with T-Mobile, where anyone can mark things.  It's social or
crowd-sourced "intelligence."  Then a few other companies started doing the
same, and customers can download a call marking app.

The two customers who have this problem often are call centers.  One doing
medical billing, the other doing legit market research and polling.  For
example right now they are calling on behalf of cities to find out what
citizens would like the council to focus on.  But some people retaliate
against the billing or don't care to be part of the city system, marking
the calls.  Additionally, some of these systems just look for short call
times and patterns of lots of calls from the same DID.  We haven't found
any solution other than rolling CLIDs.

What type of customer do you see this with?  What kind/length of calls?


On Mon, Nov 15, 2021 at 8:16 AM Izzy Goldstein - TeleGo <
igoldst...@telego.net> wrote:

> We get Support Tickets from our clients that when they call
> their Customers, their customers see the call from Possible or Potential
> Spam etc
>
> I reached out to our vendor we use for Termination, who is an aggregator
> and they say the issue is with the person getting the call,
>
> Why is this happening to my customers DIDs?
> We get this complaint from several of our clients
> Could it be that our vendor is using a bad carrier to terminate the calls?
> could it be some spammer used my customers DID as their ANI so it got
> flagged as spam ?
>
> has anyone dealt with this or a similar issue ?
>
>
> --
>
> Izzy G
> ___
> 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] Interesting proactive email from Telnyx

[Carlos Alvarez]

We're just barely trying them out, mostly for SMS.  Prices seem pretty high
compared to our other providers so it's really just a convenience/test at
this point.  But this was interesting:

Dear customer,


Telnyx has reason to believe that sip.telnyx.com will be targeted in a
subsequent DDoS attack tomorrow (Monday the 15th of Nov). During attacks,
it is likely we will block traffic from non-trusted sources.


To help achieve this Telnyx has proactively created a list of trusted IPs
using customer authentication IPs, successful registrations, and historical
traffic. However, we strongly encourage all customers to check their
records and add any IP that they may be using, to their Access Control IP
List as per the following instructions:
https://telnyx.com/release-notes/allowed-ip-mission-control



Thank you for your understanding,

The Telnyx Team


Thing is though, they don't seem to let you whitelist a subnet or range.
Entering a couple dozen IPs is not great.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Can't Figure This Scam Out

[Carlos Alvarez]

Pest control and locksmith services are very ripe for fraud, and in fact
are often sold/advertised in a pretty sleazy way.  Schools are confusing,
unless they're trying to capture something to do with for-pay private
schools.


On Thu, Nov 11, 2021 at 9:35 AM Mark Wiles  wrote:

> I’ve been seeing a similar issue in the past week or so with a pest
> control business we provide services for… they’re getting calls that were
> meant to be for other pest control businesses.
>
> It’s starting to look like it’s related to TNs seen in web searches… and
> in call cases, the TNs are not those of the primary business… but a Google
> number (owned by BW).
>
> It seems like maybe Google is having an issue?
>
>
>
>
>
>
>
> *From:* VoiceOps  *On Behalf Of *LICT
> VoiceOps via VoiceOps
> *Sent:* Thursday, November 11, 2021 11:02 AM
> *To:* VoiceOps 
> *Subject:* [VoiceOps] Can't Figure This Scam Out
>
>
>
> One of our clients is a small private school.
>
>
>
> For the past month, the school has been getting calls meant for other
> schools in the general area (within 20 miles or so)
>
>
>
> We have been able to get limited information from the caller like
> what number did they dial. They are definitely not dialing our client's
> DIDs.
>
>
>
> It seems that they are dialing a number that they found on an internet
> search, and the call is then forwarded to one of the DIDs at the school.
>
>
>
> We are seeing matching CDR records for our PBX and our carrier's CDR
> billing reports, so it does not look like a SIP hack.
>
>
>
> It seems that the number is forwarded for just a few minutes to our
> school, then goes dead, or rings busy, no longer forwarded to our client.
>
>
>
> The pattern here is that the caller obtained the number from an internet
> search of a school in the area. These are real people calling, as we have
> been able to call them back and verify. The callers who reached our client
> are as bewildered as we are.
>
>
>
> I am sure this is some sort of scam -- but I can't figure out what it is.
> Are the scammers recording the lines and seeing if they hear financial
> information? Seems like a longshot, but that is the only thing I can think
> of.
>
>
>
> I know there is little that can be done to prevent a call being forwarded
> to you upstream of the carrier, but would love to hear anyone's thoughts
> about 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] Can't Figure This Scam Out

[Carlos Alvarez]

Wild guesses...

ID theft?  They give up their private info and that of the child, and it's
recorded.

Have you tried calling those numbers yourself, then see what happens?  And
if you do get dropped, call it again.  Thought...that they either intercept
the call and redirect it, or that on the "call back because we got
disconnected" they redirect the call.


On Thu, Nov 11, 2021 at 9:13 AM LICT VoiceOps via VoiceOps <
voiceops@voiceops.org> wrote:

> One of our clients is a small private school.
>
> For the past month, the school has been getting calls meant for other
> schools in the general area (within 20 miles or so)
>
> We have been able to get limited information from the caller like
> what number did they dial. They are definitely not dialing our client's
> DIDs.
>
> It seems that they are dialing a number that they found on an internet
> search, and the call is then forwarded to one of the DIDs at the school.
>
> We are seeing matching CDR records for our PBX and our carrier's CDR
> billing reports, so it does not look like a SIP hack.
>
> It seems that the number is forwarded for just a few minutes to our
> school, then goes dead, or rings busy, no longer forwarded to our client.
>
> The pattern here is that the caller obtained the number from an internet
> search of a school in the area. These are real people calling, as we have
> been able to call them back and verify. The callers who reached our client
> are as bewildered as we are.
>
> I am sure this is some sort of scam -- but I can't figure out what it is.
> Are the scammers recording the lines and seeing if they hear financial
> information? Seems like a longshot, but that is the only thing I can think
> of.
>
> I know there is little that can be done to prevent a call being forwarded
> to you upstream of the carrier, but would love to hear anyone's thoughts
> about 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] Verizon says they have "no relationship" to port from thinQ/Commio

[Carlos Alvarez]

It's actually been escalated to their porting supervisor, from the first
two tiers.  Not sure how to go above that guy.

On Wed, Nov 10, 2021 at 1:11 PM Oren Yehezkely  wrote:

> Carlos,
>
> From my experience, this is the employee with VZW not knowing how to port
> a landline (I am assuming you are VoIP obviously).
> What we do is ask our customers to find a rep that knows how to do it or
> know what they are doing, or simply ask for a supervisor.
> And we emphasize that they should mention they are porting a landline.
>
> Good luck.
>
> Oren
>
> On Wed, Nov 10, 2021 at 1:17 PM Carlos Alvarez 
> wrote:
>
>> A customer is porting a number to VZW, and they can't figure it out.
>> They called me to ask if I had "more info" to help them port out from
>> Commio.  My return call went to VM, so I don't have more info, but thought
>> I'd ask here on the list.  Any ideas on how this can be, or what to
>> recommend?
>>
>> I know Verizon is a small carrier, and may not be wise to the ways of
>> telecom.
>>
>> ___
>> 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 says they have "no relationship" to port from thinQ/Commio

[Carlos Alvarez]

Commio/thinQ is a fancy API over Intelliquent et al, but seems to maybe
have their own SPID?  I've never worked in "real" telecom so I don't know
those deep details of the porting process.  VZW's message said they were
trying to contact Commio and couldn't get anyone to answer a phone.  Not
shocked, per my previous message about thinQ's ethics, I feel they are
questionable.


On Wed, Nov 10, 2021 at 12:45 PM Mike Hammett  wrote:

> We actually are a small provider and when I went to find out how to do
> this, I was told to sign into the NPAC helpdesk, bulletin boards, contacts,
> then search by region, SPID, etc. Then ask how to establish said
> relationship. I've heard it referred to various ways, trading partner,
> carrier partner, porting partner, etc.
>
> Obviously, Verizon should know that, but maybe all they need is to be
> shown that you're not a slouch, and that you're not giving up.
>
> Is ThinQ their own LEC or are they just a fancy API on top of Level 3,
> Bandwidth, Peerless, etc.?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"Carlos Alvarez" 
> *To: *"VoiceOps" 
> *Sent: *Wednesday, November 10, 2021 12:12:21 PM
> *Subject: *[VoiceOps] Verizon says they have "no relationship" to port
> from thinQ/Commio
>
> A customer is porting a number to VZW, and they can't figure it out.  They
> called me to ask if I had "more info" to help them port out from Commio.
> My return call went to VM, so I don't have more info, but thought I'd ask
> here on the list.  Any ideas on how this can be, or what to recommend?
>
> I know Verizon is a small carrier, and may not be wise to the ways of
> telecom.
>
>
> ___
> 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] Verizon says they have "no relationship" to port from thinQ/Commio

[Carlos Alvarez]

A customer is porting a number to VZW, and they can't figure it out.  They
called me to ask if I had "more info" to help them port out from Commio.
My return call went to VM, so I don't have more info, but thought I'd ask
here on the list.  Any ideas on how this can be, or what to recommend?

I know Verizon is a small carrier, and may not be wise to the ways of
telecom.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] thinQ is making hay while Bandwidth is down

[Carlos Alvarez]

It would be great if that LCR actually saved you any money, but it's just a
gimmick.  During the Bandwidth fiasco we sent all our term to them, and the
cost feels like it's doubled or more.  I didn't do a real numbers check,
just a glance tells me it's at least double the Bandwidth rate.


On Mon, Sep 27, 2021 at 3:16 PM Ryan Delgrosso 
wrote:

> The portion of their offering I always liked the most was their LCR as a
> service. Their orig product is mostly uninspired.
>
> Theyve had their own outages which were platform related, everyone has
> them. I usually would think players in this space would have a little more
> class than to try kicking someone when down. Every provider has bad days.
> On 9/27/2021 2:47 PM, Carlos Alvarez wrote:
>
> They have felt to me to be a bit aggressive and not fully genuine on their
> sales efforts lately.  We have used them for about 20% of our traffic for
> years, and seem pretty reliable.
>
> It would be interesting if they could do DID re-routing quickly, but as
> far as I've heard, that's TF only.
>
>
> On Mon, Sep 27, 2021 at 2:38 PM Darren via VoiceOps 
> wrote:
>
>> Yeah that’s kindof piggybacking disingenuously to consumers who don’t
>> know any better, yikes.
>>
>>
>>
>> *From: *VoiceOps  on behalf of Ryan
>> Delgrosso 
>> *Date: *Monday, September 27, 2021 at 2:32 PM
>> *To: *"voiceops@voiceops.org" 
>> *Subject: *Re: [VoiceOps] thinQ is making hay while Bandwidth is down
>>
>>
>>
>> I believe they are referring to TF and Termination
>>
>> DID's are going to be orphaned.
>>
>>
>>
>> On 9/27/2021 2:17 PM, Carlos Alvarez wrote:
>>
>> This seems to be a bit disingenuous.  I don't believe that they can
>> multi-home or move DIDs quickly?  Or am I wrong?  Could they actually solve
>> the current problem?  DIDs are the only issue; we simply moved outbound.
>>
>>
>>
>> [image: Better voice service from thinQ by Commio]
>> <https://email.thinq.com/e3t/Btc/2L+113/cPRJF04/VVzYWT85FM-MW1SPJNT8nY0xfW31NlPp4x-Tg9N93kXF_3q3n5V1-WJV7CgCBxW8L7r83991F73W9h7N7M7sB1ljW2RCKjw2Xt036N9hnh3dpF8y-W5Kzh2d16vS5dVz5-FC8XccMcW6rh3sk7VHj9QVbJfQ-1GBNnCW7ScCQ27t5ZWzW2HGVjF2TghrmVnBjHD1Thv0FW6YCNs-4c7PdvW5YK74Q7kKW75W12LXCQ3vJLfjN2jMsLB2g1RVW2s6G2n60xb0MW6tFXPN6g0zlSW3m0h_B5H42GxW4Sj3Wf17WyR8W3Lf6cf2014843hzK1>
>>
>> *Hi Carlos,*
>>
>> Carrier outages happen, but with thinQ by Commio they won't leave
>> Initiatel LLC without voice service.
>>
>> [image: Outages are in the past with thinQ!]
>> <https://email.thinq.com/e3t/Btc/2L+113/cPRJF04/VVzYWT85FM-MW1SPJNT8nY0xfW31NlPp4x-Tg9N93kXF_3q3n5V1-WJV7CgHfHVxr6QX1ngmYmW6MvhW43m5nlCV98rPc6N2YcYN1r4yV3dJd6BW2nz8WN2hfxP-VkqyCD6DvdGHW6GDxjb5mFFWVW5G3Qgs2kHycJVZydvd2zb34LW2chvl-6T6qFpW2b0g-w36lX26W3YpDR56vS-dGW8379025ZPmN6N2vkms11P6gKW2n_JlD735zSvV7ynrC9m2fx6W6fWcXp8hWLZQW6zKbbL4QqMbdVpb1XX4Bp4Y-W6Q_3WX3NgGT533hc1>
>>
>> With our voice disaster recovery solution, you can enable a dynamic
>> failover solution to easily route calls around an outage, no matter what
>> the cause, if disaster strikes.
>>
>> · Our multi-vendor solution gives you instant options for
>> service in a disaster
>>
>> · Turn on all 5 toll-free and 40 domestic carriers to power
>> custom routing so disaster recovery is fast & easy
>>
>> · Get back up and running FAST and power better performance at
>> lower costs
>>
>> You can stop worrying about outages with thinQ’s predictive intelligence
>> for call routing. Our innovative disaster recovery technology allows you to
>> reroute domestic and toll-free calls during carrier and power outages so
>> you can always be connected with your customers.
>>
>> [image: BETTER VOICE IS HERE]
>> <https://email.thinq.com/e3t/Btc/2L+113/cPRJF04/VVzYWT85FM-MW1SPJNT8nY0xfW31NlPp4x-Tg9N93kXH95VfgNV3Zsc37CgNyxW3rsTxR8JP0TmW5-k7XH4WXtJYW7lm2gS6K1gyZVgfbBs6PrKtNW3y7_3F7RQJBpW5Vh7yr9lGcR0VL5Yp620STn3W5xcH1v1gKYdLW3qZpZ-18qRzqW6x3-DV53l7pzW1HRzxY8frYg9N6nC78wjnJNsW2l1v2R4771plW3DjvDV7p1hHrW4GrBdk1H1rb8W6QPMvj6Gw8gDW6SXlCG4Rw-kfW4sw5l51t_DlbW1yxCQr127fxnW7DY70q4-6LtkW2CpvLN760Cw6W4DYSPf7MgMJMW26y91525Q2sBW3vZ02X5xDfg_W8zJv_t6DkT6mW76BjCV84V51YW1W_t3w2-_hVCW6zTp0X5--NYYW15cg0J2w0Y2fW2wbSN-1Kg2HGW7KZS2V7bnb0tW94LvZD55vZwhW4RG8vC4DBVMbVyJLp52cWF3ZW5j657s1rLW2dW3KLsyR7l9skLW1S0vSC4RlcqCW5Xy8yl44qlNDW6CCjgv8kN9dlW8hS49r95_hKRN95ZSFHCjj3bW27zJzk9kfY5jW9gLs5b4pBGh6W2BJl4B46tCNH35wy1>
>>
>>
>>
>> ___
>>
>> VoiceOps mailing list
>>
>> VoiceOps@voiceops.org
>>
>> https://puck.

[VoiceOps] And now the Bandwidth dashboard is dead

[Carlos Alvarez]

Just as I was configuring and testing our first few SMS numbers, it has
died.  I can view some numbers but they show invalid info, or the site just
hangs with loading bubbles.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Bandwidth - Monday Outage

[Carlos Alvarez]

Is this some sort of ransom event against them maybe?  And what are the
rest of you telling your customers?  We seem to have only a few
specifically complaining, but those are complaining a lot.


On Tue, Sep 28, 2021 at 11:06 PM Ivan Kovacevic <
ivan.kovace...@startelecom.ca> wrote:

> Happening again.
>
> https://status.bandwidth.com/
>
>
> [image: Star Telecom - Cloud Communications and Customer Experience
> Solutions] 
>
> *Ivan Kovacevic*
>
> *Co-Founder and VP Client Services*
>
>
>
>
> On Mon, Sep 27, 2021 at 10:19 PM Peter Beckman via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>> On Mon, 27 Sep 2021, Ryan Delgrosso wrote:
>>
>> > Nothing meaningful other than the normal public party line.
>> >
>> > I too have heard unofficially that its DDOS, which makes sense given
>> the
>> > recurring nature.
>> >
>> > 4.5hrs down Sat
>>
>>   Our monitoring showed 2 hours 47 minutes of actual service affecting
>>   outages across Voice (Inbound and Outbound), Messaging, and API/Portal.
>>
>>   The issue started at 3pm and recovered at 5:47pm EDT. We reported it to
>>   the TAC at 3:07pm, they did not post on Status until 3:31pm.
>>
>> > Some small downtime Sun
>> >
>> > Now deep into Monday with problems.
>> >
>> > Its not a good look, but id like some more transparency.
>>
>>   DDoS attacks are real and hard to null route. You've got millions of IP
>>   addresses slamming you with data. Your router has a capacity, and your
>>   router cannot handle all of that extra crap data along with all of our
>>   traffic too.
>>
>>   I'm sure BW will be investing in some beefy hardware that will be able
>> to
>>   better handle DDoS attacks, as well as working more closely with their
>>   peering providers. I have to assume that they were getting gigabits of
>>   traffic, overwhelming their links in addition to their edge routers.
>>
>>   Cloudflare details how they do it here:
>>
>> https://support.cloudflare.com/hc/en-us/articles/200172676-Understanding-Cloudflare-DDoS-protection
>>
>>   Not much to be transparent about. The Internet is an unfriendly place,
>> and
>>   bad actors can rain hell upon any public IP they want. Unsecured
>> laptops,
>>   desktops, TVs, IOT devices, etc, all contribute just a little tiny bit,
>>   and all focus on one single point, kinda like those giant solar farms
>> with
>>   the mirrors and single tower in the middle to boil the molten salt.
>>
>>   Well, Bandwidth is the molten salt, and the mirrors are a bunch of
>>   unsecured devices on the Internet.
>>
>>
>> ---
>> Peter Beckman  Internet
>> Guy
>> beck...@angryox.com
>> https://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
>>
>
> NOTE: This email message and any attachments are for the sole use of the
> intended recipient(s) and may contain confidential and/or privileged
> information. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the
> sender by replying to this email, and destroy all copies of the original
> message.
> ___
> 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] thinQ is making hay while Bandwidth is down

[Carlos Alvarez]

Will the past few days end up re-writing history as far as how we treat
single-homing phone numbers?  And/or make instant porting more common?
Maybe a BGP-like way to migrate them quickly?


On Mon, Sep 27, 2021 at 9:35 PM Paul Timmins  wrote:

> There is literally no TECHNICAL reason they can't. I've helped out other
> local carriers with some problems where we took over numbers in less than
> 10 minutes between wireline carriers and just set up forwarding for their
> customers til the outage was resolved. I moved 200 of my own numbers from
> another local carrier to my own network with 5 minutes notice coordinating
> the port over ICQ back when that was a thing. It's been possible for years,
> people just don't often do it.
>
> If both carriers log into LTI at the same time and build the subscription
> and the matching release, the number can be ported instantly. I pulled an
> old cell phone like that by logging into syniverse, submitting a WLSR to
> Sprint, and immediately built the subscription, they immediately matched it
> electronically, and I clicked activate and the number was on me, bam.
>
> The real issue is getting the losing carrier to remove the routes (or
> setting TAT triggers that do an LNP dip before terminating so the calls
> route correctly the second they're updated in NPAC) and if that is done,
> then you're good to go. If I was a company like thinq, I'd work with my
> partner carriers to let me move my numbers around between them quickly in a
> similar fashion to create a real differentiated product.
>
> -Paul
>
> > On Sep 27, 2021, at 5:53 PM, Alex Balashov via VoiceOps <
> voiceops@voiceops.org> wrote:
> >
> > No, nobody can “flash-port” numbers to a different LRN like that. Anyone
> who claims this has a bridge to sell you.
> >
> > This capability is indeed limited to SMS/800.
> >
> >> On Sep 27, 2021, at 5:47 PM, Carlos Alvarez 
> wrote:
> >>
> >> It would be interesting if they could do DID re-routing quickly
> >
> > --
> > Alex Balashov | Principal | Evariste Systems LLC
> >
> > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> >
> > ___
> > VoiceOps mailing list
> > VoiceOps@voiceops.org
> > https://puck.nether.net/mailman/listinfo/voiceops
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Bandwidth - Monday Outage

[Carlos Alvarez]

I never watch news, but I would have expected my news cycle addict friends
to be asking me by now.  Hmm.  There have to be some three letter agencies
fully involved, too.



On Mon, Sep 27, 2021 at 4:57 PM Pete Eisengrein  wrote:

> Bandwidth is a $2.5B publicly traded company... how is this not national
> news?
>
> On Mon, Sep 27, 2021 at 5:44 PM Ryan Delgrosso 
> wrote:
>
>> Would it? Or would SIP/TLS supplant that?
>>
>> The VZ VPN requirement was a bad solution to a paranoid delusion that
>> really didnt solve anything.
>>
>> As were all being dragged kicking and screaming into TLS based peering
>> for the sake of SHAKEN/STIR why not fully embrace what it provides?
>> On 9/27/2021 2:35 PM, Aryn Nakaoka 808.356.2901 wrote:
>>
>> If its SIP based, Verizon standard to run a VPN would become a norm.
>>
>>
>>
>>
>> Aryn Nakaoka
>> anaka...@trinet-hi.com
>> Direct: 808.356.2901
>> 518 Holokahana Lane
>> Honolulu, Hi 96817
>>
>> AlohaTone Mobile: https://youtu.be/PdUyuf0hTYY
>>
>> A Better Solution https://www.trinet-hi.com/abettersolution.pdf
>> <https://www.trinet-hi.com/abettersolution.pdf>
>> Aloha Tone PBX  https://www.youtube.com/watch?v=96YWPY9wCeU
>>
>> CONFIDENTIALITY NOTICE:  The information contained in this email and any
>> attachments may be privileged, confidential and protected from disclosure.
>> Any disclosure, distribution or copying of this email or any attachments by
>> persons or entities other than the intended recipient is prohibited. If you
>> have received this email in error, please notify the sender immediately by
>> replying to the message and deleting this email and any attachments from
>> your system. Thank you for your cooperation.
>>
>>
>> On Mon, Sep 27, 2021 at 11:27 AM Ryan Delgrosso 
>> wrote:
>>
>>> Do we know this is a SIP/RTP targeted volumetric attack and those arent
>>> just collateral damage in a more plebian attack aimed ad portals/apis or
>>> routers?
>>>
>>> I can understand them being tight lipped but some transparency helps the
>>> situation.
>>>
>>> I wonder if DHS is involved yet?
>>>
>>> On 9/27/2021 1:48 PM, Jay Hennigan via VoiceOps wrote:
>>> > On 9/27/21 13:30, Darren via VoiceOps wrote:
>>> >> I know it’s hard to be patient but I can’t imagine they’re NOT all
>>> >> hands on deck.
>>> >>
>>> >> The reality is probably that the DDoS attack is now so big, they
>>> >> can’t handle it on their own, so they’re scrambling to contract out
>>> >> with another provider who can handle it. That would explain why the
>>> >> BGP routes they advertise have shifted. These DDoS products typically
>>> >> take weeks to setup, so they’re likely having to scramble. I’ll be
>>> >> surprised if this does NOT continue tomorrow (unfortunately).
>>> >
>>> > From my understanding this is not your typical volumetric DDoS but
>>> > something specific to SIP or VoIP and thus the typical scrubbing
>>> > services aren't going to be effective against the voice side of things.
>>> >
>>> > Obviously they are keeping things close to the vest in order not to
>>> > give too much information to the bad guys but I agree that it may take
>>> > some time to resolve.
>>> >
>>> >> *From: *VoiceOps  on behalf of Carlos
>>> >> Alvarez 
>>> >> *Date: *Monday, September 27, 2021 at 1:23 PM
>>> >
>>> >> Generic SIP client here, and the ongoing "continue to investigate"
>>> >> notices are infuriatingly like "we have no damn clue what we're
>>> >> doing."  Try explaining to customers why it's not "our fault*" and
>>> >> that there's no way to estimate a repair time.
>>> >
>>> > I think the ongoing "continue to investigate" messages are fine.
>>> > They're obviously dealing with a major incident and trying their best
>>> > to keep their customers informed. This IMHO beats silence.
>>> >
>>> >> *Our fault for choosing them I guess, but not something we can fix in
>>> >> minutes.
>>> >
>>> > The same thing could and has affected others. Voip.ms has been dealing
>>> > with a similar attack for at least a week. We've had excellent service
>>> > from Bandwidth for years and I trust that they will be able to get
>>> > through this as well as anyone.
>>> >
>>> > It's the nature of the legacy PSTN that redundant providers or fast
>>> > failover for inbound calling isn't (yet) a thing.
>>> >
>>> ___
>>> 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] thinQ is making hay while Bandwidth is down

[Carlos Alvarez]

Additionally, I've experienced a number of these cellular ports that seemed
hung in mid-port, where some calls flowed to the wrong carrier and would
die there.  The most amusing have been where the losing carrier tries to
route the call internally.  Cox is also "good" at doing this shenanigan on
wireline.


On Mon, Sep 27, 2021 at 3:21 PM Karl Douthit  wrote:

> Mobile carriers will do an internal short term forwarding while LRN
> changes get pushed or will use their existing agreements for porting and
> push for an LRN change live.  If you have access to NPAC LRN updates you
> can make your changes but that does not guarantee that others see them
> ASAP, so usually it is a bit of both.
>
> On Mon, Sep 27, 2021, 3:12 PM Alex Balashov via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>>
>> > On Sep 27, 2021, at 6:04 PM, Aryn Nakaoka 808.356.2901 <
>> anaka...@trinet-hi.com> wrote:
>> >
>> > How do cell phone companies port instantly? I can walk into Verizon and
>> they can port my Tmobile number to them. Or are they all sharing a back
>> end?
>>
>> It’s got to be something like that. Whatever it is, VoIP ITSPs don’t have
>> it through their intermediated supply chain of ULCs.
>>
>> --
>> Alex Balashov | Principal | Evariste Systems LLC
>>
>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] thinQ is making hay while Bandwidth is down

[Carlos Alvarez]

They have felt to me to be a bit aggressive and not fully genuine on their
sales efforts lately.  We have used them for about 20% of our traffic for
years, and seem pretty reliable.

It would be interesting if they could do DID re-routing quickly, but as far
as I've heard, that's TF only.


On Mon, Sep 27, 2021 at 2:38 PM Darren via VoiceOps 
wrote:

> Yeah that’s kindof piggybacking disingenuously to consumers who don’t know
> any better, yikes.
>
>
>
> *From: *VoiceOps  on behalf of Ryan
> Delgrosso 
> *Date: *Monday, September 27, 2021 at 2:32 PM
> *To: *"voiceops@voiceops.org" 
> *Subject: *Re: [VoiceOps] thinQ is making hay while Bandwidth is down
>
>
>
> I believe they are referring to TF and Termination
>
> DID's are going to be orphaned.
>
>
>
> On 9/27/2021 2:17 PM, Carlos Alvarez wrote:
>
> This seems to be a bit disingenuous.  I don't believe that they can
> multi-home or move DIDs quickly?  Or am I wrong?  Could they actually solve
> the current problem?  DIDs are the only issue; we simply moved outbound.
>
>
>
> [image: Better voice service from thinQ by Commio]
> <https://email.thinq.com/e3t/Btc/2L+113/cPRJF04/VVzYWT85FM-MW1SPJNT8nY0xfW31NlPp4x-Tg9N93kXF_3q3n5V1-WJV7CgCBxW8L7r83991F73W9h7N7M7sB1ljW2RCKjw2Xt036N9hnh3dpF8y-W5Kzh2d16vS5dVz5-FC8XccMcW6rh3sk7VHj9QVbJfQ-1GBNnCW7ScCQ27t5ZWzW2HGVjF2TghrmVnBjHD1Thv0FW6YCNs-4c7PdvW5YK74Q7kKW75W12LXCQ3vJLfjN2jMsLB2g1RVW2s6G2n60xb0MW6tFXPN6g0zlSW3m0h_B5H42GxW4Sj3Wf17WyR8W3Lf6cf2014843hzK1>
>
> *Hi Carlos,*
>
> Carrier outages happen, but with thinQ by Commio they won't leave
> Initiatel LLC without voice service.
>
> [image: Outages are in the past with thinQ!]
> <https://email.thinq.com/e3t/Btc/2L+113/cPRJF04/VVzYWT85FM-MW1SPJNT8nY0xfW31NlPp4x-Tg9N93kXF_3q3n5V1-WJV7CgHfHVxr6QX1ngmYmW6MvhW43m5nlCV98rPc6N2YcYN1r4yV3dJd6BW2nz8WN2hfxP-VkqyCD6DvdGHW6GDxjb5mFFWVW5G3Qgs2kHycJVZydvd2zb34LW2chvl-6T6qFpW2b0g-w36lX26W3YpDR56vS-dGW8379025ZPmN6N2vkms11P6gKW2n_JlD735zSvV7ynrC9m2fx6W6fWcXp8hWLZQW6zKbbL4QqMbdVpb1XX4Bp4Y-W6Q_3WX3NgGT533hc1>
>
> With our voice disaster recovery solution, you can enable a dynamic
> failover solution to easily route calls around an outage, no matter what
> the cause, if disaster strikes.
>
> · Our multi-vendor solution gives you instant options for service
> in a disaster
>
> · Turn on all 5 toll-free and 40 domestic carriers to power
> custom routing so disaster recovery is fast & easy
>
> · Get back up and running FAST and power better performance at
> lower costs
>
> You can stop worrying about outages with thinQ’s predictive intelligence
> for call routing. Our innovative disaster recovery technology allows you to
> reroute domestic and toll-free calls during carrier and power outages so
> you can always be connected with your customers.
>
> [image: BETTER VOICE IS HERE]
> <https://email.thinq.com/e3t/Btc/2L+113/cPRJF04/VVzYWT85FM-MW1SPJNT8nY0xfW31NlPp4x-Tg9N93kXH95VfgNV3Zsc37CgNyxW3rsTxR8JP0TmW5-k7XH4WXtJYW7lm2gS6K1gyZVgfbBs6PrKtNW3y7_3F7RQJBpW5Vh7yr9lGcR0VL5Yp620STn3W5xcH1v1gKYdLW3qZpZ-18qRzqW6x3-DV53l7pzW1HRzxY8frYg9N6nC78wjnJNsW2l1v2R4771plW3DjvDV7p1hHrW4GrBdk1H1rb8W6QPMvj6Gw8gDW6SXlCG4Rw-kfW4sw5l51t_DlbW1yxCQr127fxnW7DY70q4-6LtkW2CpvLN760Cw6W4DYSPf7MgMJMW26y91525Q2sBW3vZ02X5xDfg_W8zJv_t6DkT6mW76BjCV84V51YW1W_t3w2-_hVCW6zTp0X5--NYYW15cg0J2w0Y2fW2wbSN-1Kg2HGW7KZS2V7bnb0tW94LvZD55vZwhW4RG8vC4DBVMbVyJLp52cWF3ZW5j657s1rLW2dW3KLsyR7l9skLW1S0vSC4RlcqCW5Xy8yl44qlNDW6CCjgv8kN9dlW8hS49r95_hKRN95ZSFHCjj3bW27zJzk9kfY5jW9gLs5b4pBGh6W2BJl4B46tCNH35wy1>
>
>
>
> ___
>
> 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] thinQ is making hay while Bandwidth is down

[Carlos Alvarez]

This seems to be a bit disingenuous.  I don't believe that they can
multi-home or move DIDs quickly?  Or am I wrong?  Could they actually solve
the current problem?  DIDs are the only issue; we simply moved outbound.

[image: Better voice service from thinQ by Commio]

Hi Carlos,

Carrier outages happen, but with thinQ by Commio they won't leave Initiatel
LLC without voice service.

[image: Outages are in the past with thinQ!]


With our voice disaster recovery solution, you can enable a dynamic
failover solution to easily route calls around an outage, no matter what
the cause, if disaster strikes.

   - Our multi-vendor solution gives you instant options for service in a
   disaster
   - Turn on all 5 toll-free and 40 domestic carriers to power custom
   routing so disaster recovery is fast & easy
   - Get back up and running FAST and power better performance at lower
   costs

You can stop worrying about outages with thinQ’s predictive intelligence
for call routing. Our innovative disaster recovery technology allows you to
reroute domestic and toll-free calls during carrier and power outages so
you can always be connected with your customers.
[image: BETTER VOICE IS HERE]

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

Re: [VoiceOps] Ray Baum's act and all-softphone deployments

[Carlos Alvarez]

Three meters is three floors of resolution, depending on whether the person
is standing or laying on the ground.


On Mon, Sep 27, 2021 at 1:34 PM Mark Lindsey  wrote:

> In the top 25 cellular market areas, nationwide cell phone providers are
> already required to provide Z-axis (elevation) data within 3 meters for 80%
> of calls [for compatible devices].  The requirements increase each year; by
> 2026, *all* cellular providers are required to provide z-axis precision
> for dispatchable location of +/- 3 meters everywhere in the US.
>
> This is all in addition to providing +/- 50 meter horizontal (x, y axis,
> also known as latitude and longitude) precision for 911 calls.
>
>
> https://www.fcc.gov/public-safety-and-homeland-security/policy-and-licensing-division/911-services/general/location-accuracy-indoor-benchmarks
>
>
> *Mark R Lindsey, SMTS* | +1-229-316-0013 | m...@ecg.co |* 
> https://ecg.co/lindsey/
> <https://ecg.co/lindsey/>*
>
>
>
>
>
>
>
>
> On Sep 27, 2021, at 4:07 PM, Carlos Alvarez  wrote:
>
> They probably don't, and I don't think they are covered by the same
> law/requirements.  Also, they have far more schills(COUGH) I mean lobbyists
> in congress.
>
> FLOOR could be determined by AP lists, probably.  Maybe.  Specific office
> seems impossible currently.
>
>
> On Mon, Sep 27, 2021 at 1:05 PM Alex Balashov via VoiceOps <
> voiceops@voiceops.org> wrote:
>
>> And how do the cell phone operators know what floor you’re on?
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>> On Sep 27, 2021, at 3:49 PM, Carlos Alvarez  wrote:
>>
>> 
>> It used to be, then the whole Ray Baum thing, and now it's not.  Short
>> story:  911 call failed to identify the specific floor/office, person
>> died.  Now you have to provide enough info for a first responder to reach a
>> person without help, which also means opening main doors if needed.
>> There's simply no way that a laptop will give that specificity.  Will it be
>> sufficient to say that they are near the AP on the third floor southwest
>> corner?  The letter of the law seems to say "no."
>>
>>
>>
>> On Mon, Sep 27, 2021 at 12:40 PM Alex Balashov via VoiceOps <
>> voiceops@voiceops.org> wrote:
>>
>>> I wonder if doing GeoIP via a commercial database like MaxMind—and we
>>> all know how perfect a location mechanism that is—could be construed as a
>>> sufficient “best effort” in this case.
>>>
>>> > On Sep 27, 2021, at 3:28 PM, Carlos Alvarez 
>>> wrote:
>>> >
>>> > Ours doesn't, but that's a good idea to share with the vendor.  But in
>>> most cases, people are using the softphone on a laptop and there's no
>>> native phone app, nor a GPS, nor any other location info other than
>>> proximate wi-fi networks.
>>> >
>>> > I can see no feasible way to meet the letter of the law, and hate to
>>> be depending on the good graces of a bureaucrat to know that it's an
>>> impossible task.
>>>
>>> --
>>> Alex Balashov | Principal | Evariste Systems LLC
>>>
>>> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>>
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>> ___
>> 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] Bandwidth - Monday Outage

[Carlos Alvarez]

Generic SIP client here, and the ongoing "continue to investigate" notices
are infuriatingly like "we have no damn clue what we're doing."  Try
explaining to customers why it's not "our fault*" and that there's no way
to estimate a repair time.

*Our fault for choosing them I guess, but not something we can fix in
minutes.


On Mon, Sep 27, 2021 at 1:03 PM Mike Hammett  wrote:

> Do any of you having Bandwidth issues have PNIs with them?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"David Wessell" 
> *To: *voiceops@voiceops.org
> *Sent: *Monday, September 27, 2021 12:39:16 PM
> *Subject: *[VoiceOps] Bandwidth - Monday Outage
>
> Is anyone getting anything out of BW? Almost all of our DID’s have been
> unsable all of Monday.
>
>
>
> I’ve heard unofficially that it’s a DDOS. But I can’t get anything out of
> BW besides the status page.
>
>
>
> Thanks
> David
> [image: Ringfree website] 
> David Wessell​
> Owner
> t: *828-575-0030 ex 101* <828-575-0030%20ex%20101>
> *e: da...@ringfree.com* 
>  |
> *w: ringfree.com* 
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Ray Baum's act and all-softphone deployments

[Carlos Alvarez]

Ah, great, yet another challenge here.  So even the city can't be
determined in that case.

On Mon, Sep 27, 2021 at 12:46 PM Fred Posner via VoiceOps <
voiceops@voiceops.org> wrote:

> I wonder what ios15's new hide my ip feature will do to this.
>
> Fred Posner | palner.com
> Matrix: @fred:matrix.lod.com
> o: +1 (212) 937-7844
>
> On 9/27/21 3:35 PM, Alex Balashov via VoiceOps wrote:
> > I wonder if doing GeoIP via a commercial database like MaxMind—and we
> all know how perfect a location mechanism that is—could be construed as a
> sufficient “best effort” in this case.
> >
> >> On Sep 27, 2021, at 3:28 PM, Carlos Alvarez 
> wrote:
> >>
> >> Ours doesn't, but that's a good idea to share with the vendor.  But in
> most cases, people are using the softphone on a laptop and there's no
> native phone app, nor a GPS, nor any other location info other than
> proximate wi-fi networks.
> >>
> >> I can see no feasible way to meet the letter of the law, and hate to be
> depending on the good graces of a bureaucrat to know that it's an
> impossible task.
> >
> ___
> 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] Ray Baum's act and all-softphone deployments

[Carlos Alvarez]

It used to be, then the whole Ray Baum thing, and now it's not.  Short
story:  911 call failed to identify the specific floor/office, person
died.  Now you have to provide enough info for a first responder to reach a
person without help, which also means opening main doors if needed.
There's simply no way that a laptop will give that specificity.  Will it be
sufficient to say that they are near the AP on the third floor southwest
corner?  The letter of the law seems to say "no."



On Mon, Sep 27, 2021 at 12:40 PM Alex Balashov via VoiceOps <
voiceops@voiceops.org> wrote:

> I wonder if doing GeoIP via a commercial database like MaxMind—and we all
> know how perfect a location mechanism that is—could be construed as a
> sufficient “best effort” in this case.
>
> > On Sep 27, 2021, at 3:28 PM, Carlos Alvarez  wrote:
> >
> > Ours doesn't, but that's a good idea to share with the vendor.  But in
> most cases, people are using the softphone on a laptop and there's no
> native phone app, nor a GPS, nor any other location info other than
> proximate wi-fi networks.
> >
> > I can see no feasible way to meet the letter of the law, and hate to be
> depending on the good graces of a bureaucrat to know that it's an
> impossible task.
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Ray Baum's act and all-softphone deployments

[Carlos Alvarez]

Ours doesn't, but that's a good idea to share with the vendor.  But in most
cases, people are using the softphone on a laptop and there's no native
phone app, nor a GPS, nor any other location info other than proximate
wi-fi networks.

I can see no feasible way to meet the letter of the law, and hate to be
depending on the good graces of a bureaucrat to know that it's an
impossible task.


On Mon, Sep 27, 2021 at 12:11 PM Nick Olsen  wrote:

> The softphone app we're using (Acrobits Cloud Softphone). If you attempt
> to dial 911 via the app. It'll open the phones non-voip cellular dialer
> with 911 pre-typed. It actively doesn't allow you to call 911 via the app.
> Perhaps your apps are the same.
>
> On Mon, Sep 27, 2021 at 3:00 PM Carlos Alvarez 
> wrote:
>
>> We don't have a web portal for customers to do this, so it probably can't
>> be our position.  We do have a ToS that says customers have to notify us by
>> email or support ticket if they move.  I don't believe anyone ever has.  I
>> wonder if that could still apply.
>>
>> Separately, I find this ridiculous.  WTF?  Can't use Wi-Fi for calls?
>> with respect to only the RingCentral Mobile Application, if you do not
>> have mobile service, as the RingCentral Mobile Application cannot send
>> emergency calls over Wi-Fi access
>>
>>
>> On Mon, Sep 27, 2021 at 11:47 AM Brandon Svec 
>> wrote:
>>
>>> I *think* this sums it up.  RingCentral is big if not the biggest and I
>>> say that only because they undoubtably have a large legal team and got this
>>> right.  They basically have a disclaimer that makes it the responsibility
>>> of the end user or customer administrator to update their location whenever
>>> they move around.  Silly, I know.. but I think this is a defensible
>>> position to take legally.
>>>
>>>
>>> https://www.ringcentral.com/legal/last-update-October-15-2019/emergency-services.html#ring-promo-202103
>>> *Brandon *
>>>
>>>
>>> On Mon, Sep 27, 2021 at 11:37 AM Carlos Alvarez 
>>> wrote:
>>>
>>>> I just had a call with Bandwidth about using their Dynamic Location
>>>> Routing product to fill in the very specific location info required by this
>>>> act.  However, I asked them a question he said had never been asked; what
>>>> are we to do with permanently mobile (all softphone) companies.  I can't
>>>> believe that in 2021, people are still insisting on physical phones all the
>>>> time.  I've get several soft-only customers, or maybe a physical phone for
>>>> a couple of receptionist type people.  Some have offices that they almost
>>>> never use.
>>>>
>>>> So...what are the rest of you doing with this?
>>>>
>>>> I thought there was a legal option to say "don't use your mobile
>>>> softphone" but maybe not?
>>>>
>>>> ___
>>>> 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] Ray Baum's act and all-softphone deployments

[Carlos Alvarez]

We don't have a web portal for customers to do this, so it probably can't
be our position.  We do have a ToS that says customers have to notify us by
email or support ticket if they move.  I don't believe anyone ever has.  I
wonder if that could still apply.

Separately, I find this ridiculous.  WTF?  Can't use Wi-Fi for calls?
with respect to only the RingCentral Mobile Application, if you do not have
mobile service, as the RingCentral Mobile Application cannot send emergency
calls over Wi-Fi access


On Mon, Sep 27, 2021 at 11:47 AM Brandon Svec 
wrote:

> I *think* this sums it up.  RingCentral is big if not the biggest and I
> say that only because they undoubtably have a large legal team and got this
> right.  They basically have a disclaimer that makes it the responsibility
> of the end user or customer administrator to update their location whenever
> they move around.  Silly, I know.. but I think this is a defensible
> position to take legally.
>
>
> https://www.ringcentral.com/legal/last-update-October-15-2019/emergency-services.html#ring-promo-202103
> *Brandon *
>
>
> On Mon, Sep 27, 2021 at 11:37 AM Carlos Alvarez 
> wrote:
>
>> I just had a call with Bandwidth about using their Dynamic Location
>> Routing product to fill in the very specific location info required by this
>> act.  However, I asked them a question he said had never been asked; what
>> are we to do with permanently mobile (all softphone) companies.  I can't
>> believe that in 2021, people are still insisting on physical phones all the
>> time.  I've get several soft-only customers, or maybe a physical phone for
>> a couple of receptionist type people.  Some have offices that they almost
>> never use.
>>
>> So...what are the rest of you doing with this?
>>
>> I thought there was a legal option to say "don't use your mobile
>> softphone" but maybe not?
>>
>> ___
>> 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] Ray Baum's act and all-softphone deployments

[Carlos Alvarez]

I just had a call with Bandwidth about using their Dynamic Location Routing
product to fill in the very specific location info required by this act.
However, I asked them a question he said had never been asked; what are we
to do with permanently mobile (all softphone) companies.  I can't believe
that in 2021, people are still insisting on physical phones all the time.
I've get several soft-only customers, or maybe a physical phone for a
couple of receptionist type people.  Some have offices that they almost
never use.

So...what are the rest of you doing with this?

I thought there was a legal option to say "don't use your mobile softphone"
but maybe not?
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Wholesale Platforms - 2021 Edition

[Carlos Alvarez]

Unfortunately, this list is stupidly said to default to reply only to the 
recipient instead of the list.

— 
Sent from my iPhone

> On Aug 25, 2021, at 3:04 PM, Ross Tajvar  wrote:
> 
> 
> I wish more people would reply-all to the list instead of going unicast. I am 
> interested in the answer, but I don't think it makes sense for every 
> interested party to respond "please email me too" when that's what the list 
> is for.
> 
>> On Wed, Aug 25, 2021, 3:57 PM Mary Lou Carey  
>> wrote:
>> I got about 4-5 responses. I guess I will need to do a search on the old 
>> discussions even though a lot has changed.
>> 
>> MARY LOU CAREY
>> BackUP Telecom Consulting
>> Office: 615-791-9969
>> Cell: 615-796-
>> 
>> On 2021-08-22 06:09 PM, Colton Conor wrote:
>> > Calvin,
>> > 
>> > Did you receive any responses to this email? Last time when I asked
>> > the same question there was quite a bit of discussion in 2019 if I
>> > remember correctly.
>> > 
>> > On Mon, Jul 26, 2021 at 8:13 PM Calvin Ellison
>> >  wrote:
>> > 
>> >> This question comes up every few years, let's get an update for the
>> >> cloud era!
>> >> 
>> >> Looking for a wholesale voice & SMS routing, billing, and analytics
>> >> platform that can meet these requirements:
>> >> 
>> >> * Cloud or Hosted solution for everything but the call path
>> >> * Scale is billions of call attempts per month, dozens of vendors
>> >> with full NPA-NXX or A-Z detailed breakouts
>> >> * Intelligent, performance-based rate generation, "better than LCR"
>> >> * Realtime intelligence in call routing (performance-based routing)
>> >> * Support for DID/Toll-Free inventory with forwarding/failover
>> >> routing
>> >> * Proper rating and costing for inbound, outbound, on-net,
>> >> toll-free, reciprocal comp, dips, commissions
>> >> 
>> >> * Call routing engines go next to our SBCs to minimize latency
>> >> * Call routing engines can operate disconnected from the main
>> >> database
>> >> 
>> >> * Call routing engines scale is up to 10,000 calls/messages per
>> >> second
>> >> * Management APIs for administrators and clients
>> >> * Client portal to manage trunks/binds, make payments, download
>> >> CDRs, view reporting/analytics
>> >> * Admin portal for provisioning, analytics, billing
>> >> * Agent portal for monitoring clients, commissions, payouts
>> >> * SMS must support SMPP and REST API for messaging
>> >> * MMS protocols supported
>> >> * No database license that costs more than the actual product
>> >> * Easy to use analytics - better than we can do with
>> >> Elasticsearch/Kibana
>> >> 
>> >> Bonus:
>> >> 
>> >> * Support for Sansay VSXi external routing queries
>> >> * Support for Sansay VSXi provisioning
>> >> * STIR/SHAKEN features including enterprise extensions like
>> >> Delegated Certificates, DLT, Central TN, Registered Caller, etc.
>> >> * Ready for Rich Call Data/Branded Call Display
>> >> 
>> >> Calvin Ellison
>> >> 
>> >> Systems Architect
>> >> 
>> >> calvin.elli...@voxox.com
>> >> 
>> >> [1]
>> >> 
>> >> [2] [3] [4] [5]
>> >> The information contained herein is confidential and privileged
>> >> information or work product intended only for the individual or
>> >> entity to whom it is addressed. Any unauthorized use, distribution,
>> >> or copying of this communication is strictly prohibited. If you have
>> >> received this communication in error, please notify me immediately.
>> >> ___
>> >> VoiceOps mailing list
>> >> VoiceOps@voiceops.org
>> >> https://puck.nether.net/mailman/listinfo/voiceops
>> > 
>> > 
>> > Links:
>> > --
>> > [1] http://voxox.com
>> > [2] https://www.facebook.com/VOXOX/
>> > [3] https://www.instagram.com/voxoxofficial/
>> > [4] https://www.linkedin.com/company/3573541/admin/
>> > [5] https://twitter.com/Voxox
>> > ___
>> > 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] Bandwidth vs Inteliquent

[Carlos Alvarez]

We moved all of our services off of Inteliquent.  The support was absolute
garbage, and they constantly raised rates a little at a time.  We took 20%
off our costs going to Bandwidth, and support is lightning fast.  Coverage
is identical as far as we can see in the US.  Most of our term and
origination are with Bandwidth, and a bit with thinQ for a variety of
reasons.  I'm considering porting all that to Bandwidth.  They say it's
dangerous to have all your eggs in one basket, but BW has simply been 100%
for us in every measure.  We'd probably still use thinQ as backup term.


On Wed, Jul 7, 2021 at 6:17 AM Colton Conor  wrote:

> If you had to choose only between these two providers for wholesale
> services, which would you choose and why? We are only considering these two
> as the softswitch we are planning on using (Netsapiens) has only built out
> Group MMS support for these two carriers APIs, and no one else.
>
> I have used many services over the years that have utilized both of these
> carriers, but I have never had a direct relationship with them.
>
> Which has a better portal, API, and company overall? What are the true
> differences?
>
> Are there any resellers to consider where we would still have direct
> access to these carriers APIs?
> ___
> 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] Fwd: Reassigned Numbers Database (RND) June 21, 2021 Webinar

[Carlos Alvarez]

Do you have any idea whether a copy of the webinar may be available after?
I have an existing conflicting commitment I can't change.

On Sun, Jun 20, 2021 at 2:41 PM Calvin Ellison 
wrote:

> -- Forwarded message -
> From: Support Reassigned 
> Date: Wed, Jun 9, 2021, 11:23
> Subject: Reassigned Numbers Database (RND) June 21, 2021 Webinar
> To: Support Reassigned 
>
>
>
>
>
>
> [image: Logo Description automatically generated]
>
>
>
> Date: June 7, 2021
>
> Subject: Reassigned Numbers Database (RND) June 21, 2021 Webinar
>
> To:  Callers/Caller Agents interested in using the RND system
>
> *
>
> The RND Administrator will be hosting a webinar event on June 21, 2021
> (2:00 pm -3:30 pm Eastern) for those interested in learning about using the
> RND as well as participating in a beta trial during the period of July
> 1-September 30, 2021.   Callers and Caller Agents who use the RND can avoid
> calling consumers with potentially reassigned numbers and to comply with
> regulatory requirements.
>
> The webinar will address the purpose of the RND including a general
> overview of the online system, a review of the methods for querying
> telephone numbers, and a short demo.
>
> Further information including an Agenda and User Query Guide will be sent
> prior to the Webinar; this information will also be posted to
> https://www.reassigned.us/
>
> The logistics are as follows:
>
> Zoom Webinar.
>
> When: June 21, 2021 2:00 PM Eastern Time
>
> Register in advance for this webinar:
>
> https://somos.zoom.us/webinar/register/WN_J__s39eKT3WdJlyF-y3Aww
>
>
>
> After registering, you will receive a confirmation email containing
> information about joining the webinar.
>
>
>
>
>
> If you have any questions, please contact us at supp...@reassigned.us
>  or call us at 1-833-763-2366.
>
>
>
>
>
>
> ___
> 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 Quality

[Carlos Alvarez]

Oh, they absolutely do TRY to.  And junk equipment.

Last week a site-level manager for a customer tried to tell us we were
responsible for and needed to do something about the 15-20 robocalls per
day they were getting.  My first answer was, wait, ONLY 15-20??  (Number is
SEO and so easily scraped.)


On Mon, Jun 14, 2021 at 2:49 PM Mike Hammett  wrote:

> God, I hope customers don't hold their carriers responsible for
> inappropriate use of speakerphones.
>
>
> Yes, I'm sure the complaints received for the above are non-null. That's
> how much faith I have in customers.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"Tim Bray via VoiceOps" 
> *To: *voiceops@voiceops.org
> *Sent: *Monday, June 14, 2021 4:36:55 PM
> *Subject: *Re: [VoiceOps] Call Quality
>
> On 14/06/2021 22:25, Mike Hammett wrote:
> > One of the concerns I heard was echo. On a purely digital call, what
> > would be the cause of echo?
>
> Echo, as in hearing yourself coming back with a delay?
>
> Sound flying from the speaker to the microphone at the far end. Dodgy
> speaker phone, poor plastic design of the phone, DSP not doing echo
> cancellation.   Or too much end to end latency - if it is quick enough,
> you don't notice.  Could be loads of things.
>
>
>
>
> Quite often with third party USB  or bluetooth `speaker phones`
>
>
>
> --
> Tim Bray
> Huddersfield, GB
> t...@kooky.org
>
> ___
> 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 Quality

[Carlos Alvarez]

It's not an issue other than what others said; junk analog gear and/or
people doing dumb things.  Another one I found was call center people who
don't want to mess up their hair, and wear a headset with the band around
the neck, earpiece angled off the back of the earlobe.  They turn up the
volume to full to be able to hear, and the speaker has a direct line to the
microphone hanging 4" away from their face.


On Mon, Jun 14, 2021 at 2:45 PM Mike Hammett  wrote:

> I can't say I've experienced it, no.
>
> It was just something a potential customer told me they were concerned
> with.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"Carlos Alvarez" 
> *To: *voiceops@voiceops.org
> *Sent: *Monday, June 14, 2021 4:37:38 PM
> *Subject: *Re: [VoiceOps] Call Quality
>
> So are you saying that you've experienced echo on a fully VoIP call?  IP
> handset to IP handset, without some sort of analog interface other than in
> the handsets?
>
> I can't recall the last echo complaint we've had.
>
>
> On Mon, Jun 14, 2021 at 2:35 PM Mike Hammett  wrote:
>
>> Well right.
>>
>> The analog portions of most calls are extremely small anymore (speaker to
>> ear and mouth to microphone).
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>>
>>
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>>
>>
>>
>> --
>> *From: *"Carlos Alvarez" 
>> *To: *voiceops@voiceops.org
>> *Sent: *Monday, June 14, 2021 4:31:07 PM
>> *Subject: *Re: [VoiceOps] Call Quality
>>
>> Well, no call is purely digital, the endpoints are still analog, as is
>> the meatbag behind the handset.  I can't imagine any way you can create
>> echo in the digital portions.  But a mismatch in impedance on an ATA or
>> similar device would be a common old problem I've faced.
>>
>>
>> On Mon, Jun 14, 2021 at 2:28 PM Mike Hammett  wrote:
>>
>>> One of the concerns I heard was echo. On a purely digital call, what
>>> would be the cause of echo?
>>>
>>>
>>>
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>>
>>>
>>> Midwest Internet Exchange
>>> http://www.midwest-ix.com
>>>
>>>
>>>
>>> --
>>> *From: *"Mike Hammett" 
>>> *To: *"VoiceOps" 
>>> *Sent: *Sunday, June 13, 2021 1:11:30 PM
>>> *Subject: *[VoiceOps] Call Quality
>>>
>>> I've heard a variety of complaints and concerns over the years about
>>> call quality. How are these quality issues introduced? As long as pipes and
>>> equipment aren't overloaded, where is a quality issue to come from?
>>>
>>>
>>> Obviously, the closer you are to the handsets, the less opportunity
>>> there is for issues. What else is there to take into account?
>>>
>>>
>>>
>>> -
>>> 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
>>
>>
> ___
> 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 Quality

[Carlos Alvarez]

So are you saying that you've experienced echo on a fully VoIP call?  IP
handset to IP handset, without some sort of analog interface other than in
the handsets?

I can't recall the last echo complaint we've had.


On Mon, Jun 14, 2021 at 2:35 PM Mike Hammett  wrote:

> Well right.
>
> The analog portions of most calls are extremely small anymore (speaker to
> ear and mouth to microphone).
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"Carlos Alvarez" 
> *To: *voiceops@voiceops.org
> *Sent: *Monday, June 14, 2021 4:31:07 PM
> *Subject: *Re: [VoiceOps] Call Quality
>
> Well, no call is purely digital, the endpoints are still analog, as is the
> meatbag behind the handset.  I can't imagine any way you can create echo in
> the digital portions.  But a mismatch in impedance on an ATA or similar
> device would be a common old problem I've faced.
>
>
> On Mon, Jun 14, 2021 at 2:28 PM Mike Hammett  wrote:
>
>> One of the concerns I heard was echo. On a purely digital call, what
>> would be the cause of echo?
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>>
>>
>> Midwest Internet Exchange
>> http://www.midwest-ix.com
>>
>>
>>
>> --
>> *From: *"Mike Hammett" 
>> *To: *"VoiceOps" 
>> *Sent: *Sunday, June 13, 2021 1:11:30 PM
>> *Subject: *[VoiceOps] Call Quality
>>
>> I've heard a variety of complaints and concerns over the years about call
>> quality. How are these quality issues introduced? As long as pipes and
>> equipment aren't overloaded, where is a quality issue to come from?
>>
>>
>> Obviously, the closer you are to the handsets, the less opportunity there
>> is for issues. What else is there to take into account?
>>
>>
>>
>> -
>> 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
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Call Quality

[Carlos Alvarez]

Well, no call is purely digital, the endpoints are still analog, as is the
meatbag behind the handset.  I can't imagine any way you can create echo in
the digital portions.  But a mismatch in impedance on an ATA or similar
device would be a common old problem I've faced.


On Mon, Jun 14, 2021 at 2:28 PM Mike Hammett  wrote:

> One of the concerns I heard was echo. On a purely digital call, what would
> be the cause of echo?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
>
>
> Midwest Internet Exchange
> http://www.midwest-ix.com
>
>
>
> --
> *From: *"Mike Hammett" 
> *To: *"VoiceOps" 
> *Sent: *Sunday, June 13, 2021 1:11:30 PM
> *Subject: *[VoiceOps] Call Quality
>
> I've heard a variety of complaints and concerns over the years about call
> quality. How are these quality issues introduced? As long as pipes and
> equipment aren't overloaded, where is a quality issue to come from?
>
>
> Obviously, the closer you are to the handsets, the less opportunity there
> is for issues. What else is there to take into account?
>
>
>
> -
> 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] USF is 33.4% for 2Q2021

[Carlos Alvarez]

Except that some of us specifically sell "bottom line" pricing that is not
variable and not padded with 20 lines of fees and taxes.  Because our ILEC
is known for quoting $100 and billing $130-150 actual price.

On Thu, Jun 10, 2021 at 9:38 AM Paul Timmins  wrote:

> 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
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops