Re: [VoiceOps] Question about SS7 routing

[Paul Timmins]

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

-Paul




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

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

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

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

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



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

Hi all,

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

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

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

Re: [VoiceOps] Question about SS7 routing

[Alex Balashov]

Your number block homing arrangements should be published in the LERG.

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

> On Sep 2, 2020, at 6:12 PM, Ross Tajvar  wrote:
> 
> 
> I see, that makes sense. So then I have two follow-up questions:
> If you are connected to multiple carriers, e.g. multiple long distance 
> carriers, how do you populate your routing table? (Obviously "it depends" but 
> I'd be interested to hear an example.)
> If you are setting up equipment for the first time, with a new number block, 
> how do you make sure other people include you/your block in their routing 
> tables?
> 
>> On Wed, Sep 2, 2020 at 5:56 PM Paul Timmins  wrote:
>> You only send calls to point codes you're connected to with ISUP trunks 
>> (what is a control network without bearer channels?), so you don't really do 
>> it that way. You would look at your usual LCR/routing table, and the 
>> adjacent switch you want to pass it to, be it a local end office, feature 
>> group D regional ILEC tandem, or long distance carrier wholesale circuit, 
>> and you would send it to the point code of the switch you're connected to 
>> that is the appropriate next hop for the call.
>> 
>> 
>> 
>> From: VoiceOps  on behalf of Ross Tajvar 
>> 
>> Sent: Wednesday, September 2, 2020 5:46 PM
>> To: VoiceOps
>> Subject: [VoiceOps] Question about SS7 routing
>>  
>> Hi all,
>> 
>> I'm trying to understand how routing works in SS7-land. I am familiar with 
>> portability, and I know (at least in the US) the first step in routing a 
>> call is doing an LNP dip to get the LRN.
>> 
>> However, it looks like addresses in MTP3 are "point codes" (PCs) which are 
>> assigned to switches. Calls are set up with ISDN-UP, which is transported 
>> via MTP3. So in order for a call to be set up, the destination switch's PC 
>> must be known. How is the destination PC determined from the destination LRN?
>> 
>> Thanks,
>> Ross
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Question about SS7 routing

[Ross Tajvar]

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

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


On Wed, Sep 2, 2020 at 5:56 PM Paul Timmins  wrote:

> You only send calls to point codes you're connected to with ISUP trunks
> (what is a control network without bearer channels?), so you don't really
> do it that way. You would look at your usual LCR/routing table, and the
> adjacent switch you want to pass it to, be it a local end office, feature
> group D regional ILEC tandem, or long distance carrier wholesale circuit,
> and you would send it to the point code of the switch you're connected to
> that is the appropriate next hop for the call.
>
>
> --
> *From:* VoiceOps  on behalf of Ross Tajvar
> 
> *Sent:* Wednesday, September 2, 2020 5:46 PM
> *To:* VoiceOps
> *Subject:* [VoiceOps] Question about SS7 routing
>
> Hi all,
>
> I'm trying to understand how routing works in SS7-land. I am familiar with
> portability, and I know (at least in the US) the first step in routing a
> call is doing an LNP dip to get the LRN.
>
> However, it looks like addresses in MTP3 are "point codes" (PCs) which are
> assigned to switches. Calls are set up with ISDN-UP, which is transported
> via MTP3. So in order for a call to be set up, the destination switch's PC
> must be known. How is the destination PC determined from the destination
> LRN?
>
> Thanks,
> Ross
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Question about SS7 routing

[Paul Timmins]

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



From: VoiceOps  on behalf of Ross Tajvar 

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

Hi all,

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

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

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

[VoiceOps] Question about SS7 routing

[Ross Tajvar]

Hi all,

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

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

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

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Dave Frigen]

So far this trail of emails is correct. All calls have to be traceable back to 
the origination provider (via PA registered certificates) for legal enforcement 
purposes. So each SP will need to authenticate (guarantee validity of) their 
own calls. You just don’t necessarily need access to your own phone numbers if 
you lease. 

 

I would add that not only will a network likely be blocked for monkey business, 
it will be prosecuted too. And with the recent passing of the Traced Act and 
all the hype at the FCC lately they’re likely to impose big penalties on 
bad-actors.   

 

Dave

 

From: VoiceOps  On Behalf Of Mark Lindsey
Sent: Wednesday, September 2, 2020 2:01 PM
To: Alex Balashov 
Cc: VoiceOps 
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

 

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

 

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

 

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

 

 

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

 

 





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

 

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

 

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

 

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

—

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





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

 

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

 

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

 

-Paul

 


  _  


From: VoiceOps mailto:voiceops-boun...@voiceops.org> > on behalf of Alex Balashov 
mailto:abalas...@evaristesys.com> >
Sent: Wednesday, September 2, 2020 2:42 PM
To: VoiceOps
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup 

 

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

 

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

— 

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





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

 

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

 

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

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

 

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

There is a STIR-SHAKEN process of registering and testing with the Policy
Administrator (PA) as a certified Service Provider (SP) before you 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Zilk, David]

Replace “robocalls” with “spoofed calls” and you would be correct.  A service 
provider can legitimately provide A attestation to calls that turn out to be 
illegal robocalls, as long as the caller can legitimately use the number they 
are calling from.  At that point the traceback functionality of STIR/SHAKEN can 
be invoked and trace the call back to the robocaller for prosecution. The 
service provider would not be on the hook for attesting the illegal calls.

However, if the calling number is spoofed and is not one that the end user can 
legitimately use, the service provider could have their SHAKEN certificate 
revoked for attesting that traffic at the A level (presumably after a certain 
period of warning and if they were not responsive to resolving the situation).

From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Paul Timmins
Sent: Wednesday, September 2, 2020 12:12 PM
To: voiceops@voiceops.org
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

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

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

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

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


On Sep 2, 2020, at 3:01 PM, Mark Lindsey 
 wrote:
SHAKEN doesn't record the chain (like you'd see with Via headers, for example) 
of Intermediate Providers who handle the call. There's only one Identity header 
and it is to be passed unchanged from the origin point to the terminating Voice 
Service Provider.

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

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


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




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

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

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

I suppose success is going to come down to the on-the-ground realities, 
political viability, etc of taking that “block attested calls from carrier X” 
step.
—
Sent from mobile, with due apologies for brevity and errors.


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

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

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

-Paul


From: VoiceOps 
mailto:voiceops-boun...@voiceops.org>> on behalf 
of Alex Balashov mailto:abalas...@evaristesys.com>>
Sent: Wednesday, September 2, 2020 2:42 PM
To: VoiceOps
Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

LCR or no LCR, using a termination vendor that is different to one’s 
origination vendor for a given CID is more normal than not in VoIP. I would 
guess it’s the 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

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


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


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


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


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

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


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


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




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

*
*



On Sep 2, 2020, at 2:52 PM, Alex Balashov > wrote:


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

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


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


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

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




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



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



-Paul




*From:* VoiceOps > on behalf of Alex Balashov 
mailto:abalas...@evaristesys.com>>

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


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


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

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



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


On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger > wrote:


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

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

There is a STIR-SHAKEN process of registering and testing
with the Policy

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

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


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

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

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

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

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


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


-Paul



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

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

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


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


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


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



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



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



-Paul




*From:* VoiceOps  on behalf of Alex 
Balashov 

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


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


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


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


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


On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger > wrote:


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

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

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

One of the registration requirements is a SP 's access to
valid national
phone number pools. This has been very confusing for some
resale providers
that purchase and use numbers from wholesalers only. If your
   

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Alex Balashov]

That’s what I thought, thank you for clarifying. I was just confused because of 
the language in Paul’s previous explanation—no fault of his.

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

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

> On Sep 2, 2020, at 3:01 PM, Mark Lindsey  wrote:
> 
> SHAKEN doesn't record the chain (like you'd see with Via headers, for 
> example) of Intermediate Providers who handle the call. There's only one 
> Identity header and it is to be passed unchanged from the origin point to the 
> terminating Voice Service Provider.
> 
> When the Identity header with PASSporT arrives at the final Voice Service 
> Provider, that recipient can determine who created the PASSporT and then make 
> judgments. For example, there has been a lot of discussion in FCC filings 
> about "reputation" of service providers. Perhaps you could subscribe to a 
> Reputation database to determine what to do with the calls.
> 
> For example, "This call got an A level attestation from XYZTelecom, but 
> XYZTelecom has a 5% score in the reputation database, so I'm going to treat 
> it as if this call is likely a nuisance call."
> 
> 
> 
> Mark R Lindsey, SMTS | +1-229-316-0013 | m...@ecg.co | https://ecg.co/lindsey/
> 
> 
> 
> 
>> On Sep 2, 2020, at 2:52 PM, Alex Balashov  wrote:
>> 
>> Thank you, that’s very clear and sums it all up! 
>> 
>> One lingering question: even without providing a fully attestable chain of 
>> custody, if the call took a route A -> B -> C, are signatures cumulative 
>> such that I could block calls attested by B coming through C? Or am I 
>> constrained to blocking a certain level of attestation only through the 
>> last/proximate peering hop (C) that directly touches me?
>> 
>> I suppose success is going to come down to the on-the-ground realities, 
>> political viability, etc of taking that “block attested calls from carrier 
>> X” step.
>> 
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>> 
 On Sep 2, 2020, at 2:47 PM, Paul Timmins  wrote:
 
>>> 
>>> The solution is that you sign your calls with your certificate. Carriers 
>>> aren't doing LNP dips to verify the number is really yours, they're 
>>> trusting your attestation (A: yes, the caller id is verified, B: it comes 
>>> from our customer, but not verified, C: "this touched our switches, good 
>>> luck with it"). If you attest total nonsense as A, or send tons of nonsense 
>>> in general, people start blocking calls you sign.
>>> 
>>> 
>>> 
>>> It really verifies who is sending the call, and what that company says the 
>>> call is verified, not a full chain of custody of the number back to the 
>>> NANPA/PA. Could you attest A a call from "0" or "911", or "999-999-"? 
>>> Yes, you could. It'd work for a while, til someone said "Wow, Alex's SPID 
>>> is signing tons of bullshit. Let's block attested calls from his SPID"
>>> 
>>> 
>>> 
>>> -Paul
>>> 
>>> 
>>> 
>>> From: VoiceOps  on behalf of Alex Balashov 
>>> 
>>> Sent: Wednesday, September 2, 2020 2:42 PM
>>> To: VoiceOps
>>> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
>>>  
>>> LCR or no LCR, using a termination vendor that is different to one’s 
>>> origination vendor for a given CID is more normal than not in VoIP. I would 
>>> guess it’s the default wholesale use-case. Origination and termination are 
>>> very different business models with radically different economics.
>>> 
>>> I’m not clear on what the official STIR/SHAKEN solution to this is. I 
>>> assume it’s delegated certificates as Jared suggested.
>>> 
>>> —
>>> Sent from mobile, with due apologies for brevity and errors.
>>> 
 On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:
 
 
 If I understand correctly, no as long as your providers are all supporting 
 this.  What I think you mean is that you get origination/DIDs from say 
 Bandwidth, and you use LCR to route calls to whoever is cheapest?  There 
 are ways to work with that challenge as long as your carriers are ready to 
 do so.
 
> On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger  wrote:
> If we purchase our numbers through wholesalers, would we need delegated 
> certificates if we are sending an outbound call through a vendor that is 
> not the wholesaler we got the number from?
> 
>> On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen  wrote:
>> There is a STIR-SHAKEN process of registering and testing with the Policy
>> Administrator (PA) as a certified Service Provider (SP) before you can
>> purchase SHAKEN token certificates from a Certificate Authority (CA) and
>> begin to engage in using the technology. This is not a walk in the park.
>> Transnexus is one of two 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Mark Lindsey]

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

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

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



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





> On Sep 2, 2020, at 2:52 PM, Alex Balashov  wrote:
> 
> Thank you, that’s very clear and sums it all up! 
> 
> One lingering question: even without providing a fully attestable chain of 
> custody, if the call took a route A -> B -> C, are signatures cumulative such 
> that I could block calls attested by B coming through C? Or am I constrained 
> to blocking a certain level of attestation only through the last/proximate 
> peering hop (C) that directly touches me?
> 
> I suppose success is going to come down to the on-the-ground realities, 
> political viability, etc of taking that “block attested calls from carrier X” 
> step.
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>> On Sep 2, 2020, at 2:47 PM, Paul Timmins  wrote:
>> 
>> 
>> The solution is that you sign your calls with your certificate. Carriers 
>> aren't doing LNP dips to verify the number is really yours, they're trusting 
>> your attestation (A: yes, the caller id is verified, B: it comes from our 
>> customer, but not verified, C: "this touched our switches, good luck with 
>> it"). If you attest total nonsense as A, or send tons of nonsense in 
>> general, people start blocking calls you sign.
>> 
>> 
>> 
>> It really verifies who is sending the call, and what that company says the 
>> call is verified, not a full chain of custody of the number back to the 
>> NANPA/PA. Could you attest A a call from "0" or "911", or "999-999-"? 
>> Yes, you could. It'd work for a while, til someone said "Wow, Alex's SPID is 
>> signing tons of bullshit. Let's block attested calls from his SPID"
>> 
>> 
>> 
>> -Paul
>> 
>> 
>> 
>> From: VoiceOps  on behalf of Alex Balashov 
>> 
>> Sent: Wednesday, September 2, 2020 2:42 PM
>> To: VoiceOps
>> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
>>  
>> LCR or no LCR, using a termination vendor that is different to one’s 
>> origination vendor for a given CID is more normal than not in VoIP. I would 
>> guess it’s the default wholesale use-case. Origination and termination are 
>> very different business models with radically different economics.
>> 
>> I’m not clear on what the official STIR/SHAKEN solution to this is. I assume 
>> it’s delegated certificates as Jared suggested.
>> 
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>> 
>>> On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:
>>> 
>>> 
>>> If I understand correctly, no as long as your providers are all supporting 
>>> this.  What I think you mean is that you get origination/DIDs from say 
>>> Bandwidth, and you use LCR to route calls to whoever is cheapest?  There 
>>> are ways to work with that challenge as long as your carriers are ready to 
>>> do so.
>>> 
>>> On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger >> > wrote:
>>> If we purchase our numbers through wholesalers, would we need delegated 
>>> certificates if we are sending an outbound call through a vendor that is 
>>> not the wholesaler we got the number from?
>>> 
>>> On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen >> > wrote:
>>> There is a STIR-SHAKEN process of registering and testing with the Policy
>>> Administrator (PA) as a certified Service Provider (SP) before you can
>>> purchase SHAKEN token certificates from a Certificate Authority (CA) and
>>> begin to engage in using the technology. This is not a walk in the park.
>>> Transnexus is one of two public CA's in the U.S. today. They are experts on
>>> the subject and can help you through both processes. In order to get the
>>> best call attestation you must prove to the PA and CA that you are a bono
>>> fide service provider and not a bad-acting enterprise on a network that
>>> deserves lesser attestation levels. 
>>> 
>>> One of the registration requirements is a SP 's access to valid national
>>> phone number pools. This has been very confusing for some resale providers
>>> that purchase and use numbers from wholesalers only. If your organization
>>> does not have it's own numbering resources, you can 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Alex Balashov]

Thank you, that’s really helpful info.

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

> On Sep 2, 2020, at 2:49 PM, Mark Lindsey  wrote:
> 
> The official SHAKEN/STIR answer, anticipated by the FCC rules, ignores 
> how/where you're buying origination services. Unless an lawyer tells me 
> otherwise, the FCC says each "Voice Service Provider" must implement the 
> SHAKEN framework on all its SIP network, and so you (as the Voice Service 
> Provider) have to verify the callers' rights to use those telephone numbers 
> for outbound calls before you add the A-Level Attestation. You use your own 
> certificate to sign your own calls.
> 
> It's not clear that it's legal under the TRACED Act to merely depend on your 
> downstream providers to implement SHAKEN so you don't have to.
> 
> Mark R Lindsey, SMTS | +1-229-316-0013 | m...@ecg.co | https://ecg.co/lindsey/
> 
> 
> 
> 
>> On Sep 2, 2020, at 2:42 PM, Alex Balashov  wrote:
>> 
>> LCR or no LCR, using a termination vendor that is different to one’s 
>> origination vendor for a given CID is more normal than not in VoIP. I would 
>> guess it’s the default wholesale use-case. Origination and termination are 
>> very different business models with radically different economics.
>> 
>> I’m not clear on what the official STIR/SHAKEN solution to this is. I assume 
>> it’s delegated certificates as Jared suggested.
>> 
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>> 
 On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:
 
>>> 
>>> If I understand correctly, no as long as your providers are all supporting 
>>> this.  What I think you mean is that you get origination/DIDs from say 
>>> Bandwidth, and you use LCR to route calls to whoever is cheapest?  There 
>>> are ways to work with that challenge as long as your carriers are ready to 
>>> do so.
>>> 
 On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger  wrote:
 If we purchase our numbers through wholesalers, would we need delegated 
 certificates if we are sending an outbound call through a vendor that is 
 not the wholesaler we got the number from?
 
> On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen  wrote:
> There is a STIR-SHAKEN process of registering and testing with the Policy
> Administrator (PA) as a certified Service Provider (SP) before you can
> purchase SHAKEN token certificates from a Certificate Authority (CA) and
> begin to engage in using the technology. This is not a walk in the park.
> Transnexus is one of two public CA's in the U.S. today. They are experts 
> on
> the subject and can help you through both processes. In order to get the
> best call attestation you must prove to the PA and CA that you are a bono
> fide service provider and not a bad-acting enterprise on a network that
> deserves lesser attestation levels. 
> 
> One of the registration requirements is a SP 's access to valid national
> phone number pools. This has been very confusing for some resale providers
> that purchase and use numbers from wholesalers only. If your organization
> does not have it's own numbering resources, you can register using your
> wholesale provider's numbering pool data. Don't assume you have to 
> register
> with the FCC and possess your own pool of numbers to become a registered
> SHAKEN SP.
> 
> SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
> attestation level possible for a SP is essential to the SP and the SHAKEN
> ecosystem. Register and test for the best attestation level possible.
> Transnexus is a seasoned expert on the subject and a U.S. registered CA 
> with
> the PA. 
> 
> Dave
> 
> 
> -Original Message-
> From: VoiceOps  On Behalf Of Mary Lou Carey
> Sent: Tuesday, September 1, 2020 5:36 PM
> To: Dovid Bender 
> Cc: Voiceops.org 
> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
> 
> I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless 
> and
> VOIP carriers install and maintain their PSTN networks for the the last 20
> years. I can help clients get their FCC Certification to become a
> STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training, 
> etc
> (if you need those pieces). Once my clients get their certification, I 
> refer
> them to TransNexus. Jim and his team can help you with the process of
> turning your STIR/SHAKEN services up.
> 
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-
> 
> On 2020-08-31 05:37 AM, Dovid Bender wrote:
> > Hi,
> > 
> > Does anyone have a recommendation for a company that get us everything 
> > needed for STIR/SHAKEN setup? By setup I mean helping us file to get a 
> > cert etc. From the small research I have done there is a lot of 
> > fragmented 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Alex Balashov]

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

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

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

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

> On Sep 2, 2020, at 2:47 PM, Paul Timmins  wrote:
> 
> 
> The solution is that you sign your calls with your certificate. Carriers 
> aren't doing LNP dips to verify the number is really yours, they're trusting 
> your attestation (A: yes, the caller id is verified, B: it comes from our 
> customer, but not verified, C: "this touched our switches, good luck with 
> it"). If you attest total nonsense as A, or send tons of nonsense in general, 
> people start blocking calls you sign.
> 
> 
> 
> It really verifies who is sending the call, and what that company says the 
> call is verified, not a full chain of custody of the number back to the 
> NANPA/PA. Could you attest A a call from "0" or "911", or "999-999-"? 
> Yes, you could. It'd work for a while, til someone said "Wow, Alex's SPID is 
> signing tons of bullshit. Let's block attested calls from his SPID"
> 
> 
> 
> -Paul
> 
> 
> 
> From: VoiceOps  on behalf of Alex Balashov 
> 
> Sent: Wednesday, September 2, 2020 2:42 PM
> To: VoiceOps
> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
>  
> LCR or no LCR, using a termination vendor that is different to one’s 
> origination vendor for a given CID is more normal than not in VoIP. I would 
> guess it’s the default wholesale use-case. Origination and termination are 
> very different business models with radically different economics.
> 
> I’m not clear on what the official STIR/SHAKEN solution to this is. I assume 
> it’s delegated certificates as Jared suggested.
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>>> On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:
>>> 
>> 
>> If I understand correctly, no as long as your providers are all supporting 
>> this.  What I think you mean is that you get origination/DIDs from say 
>> Bandwidth, and you use LCR to route calls to whoever is cheapest?  There are 
>> ways to work with that challenge as long as your carriers are ready to do so.
>> 
>>> On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger  wrote:
>>> If we purchase our numbers through wholesalers, would we need delegated 
>>> certificates if we are sending an outbound call through a vendor that is 
>>> not the wholesaler we got the number from?
>>> 
 On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen  wrote:
 There is a STIR-SHAKEN process of registering and testing with the Policy
 Administrator (PA) as a certified Service Provider (SP) before you can
 purchase SHAKEN token certificates from a Certificate Authority (CA) and
 begin to engage in using the technology. This is not a walk in the park.
 Transnexus is one of two public CA's in the U.S. today. They are experts on
 the subject and can help you through both processes. In order to get the
 best call attestation you must prove to the PA and CA that you are a bono
 fide service provider and not a bad-acting enterprise on a network that
 deserves lesser attestation levels. 
 
 One of the registration requirements is a SP 's access to valid national
 phone number pools. This has been very confusing for some resale providers
 that purchase and use numbers from wholesalers only. If your organization
 does not have it's own numbering resources, you can register using your
 wholesale provider's numbering pool data. Don't assume you have to register
 with the FCC and possess your own pool of numbers to become a registered
 SHAKEN SP.
 
 SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
 attestation level possible for a SP is essential to the SP and the SHAKEN
 ecosystem. Register and test for the best attestation level possible.
 Transnexus is a seasoned expert on the subject and a U.S. registered CA 
 with
 the PA. 
 
 Dave
 
 
 -Original Message-
 From: VoiceOps  On Behalf Of Mary Lou Carey
 Sent: Tuesday, September 1, 2020 5:36 PM
 To: Dovid Bender 
 Cc: Voiceops.org 
 Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
 
 I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless and
 VOIP carriers install and maintain their PSTN networks for the the last 20
 years. I can help clients get their FCC Certification to become a
 STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training, 
 etc
 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Mark Lindsey]

The official SHAKEN/STIR answer, anticipated by the FCC rules, ignores 
how/where you're buying origination services. Unless an lawyer tells me 
otherwise, the FCC says each "Voice Service Provider" must implement the SHAKEN 
framework on all its SIP network, and so you (as the Voice Service Provider) 
have to verify the callers' rights to use those telephone numbers for outbound 
calls before you add the A-Level Attestation. You use your own certificate to 
sign your own calls.

It's not clear that it's legal under the TRACED Act to merely depend on your 
downstream providers to implement SHAKEN so you don't have to.

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





> On Sep 2, 2020, at 2:42 PM, Alex Balashov  wrote:
> 
> LCR or no LCR, using a termination vendor that is different to one’s 
> origination vendor for a given CID is more normal than not in VoIP. I would 
> guess it’s the default wholesale use-case. Origination and termination are 
> very different business models with radically different economics.
> 
> I’m not clear on what the official STIR/SHAKEN solution to this is. I assume 
> it’s delegated certificates as Jared suggested.
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>> On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:
>> 
>> 
>> If I understand correctly, no as long as your providers are all supporting 
>> this.  What I think you mean is that you get origination/DIDs from say 
>> Bandwidth, and you use LCR to route calls to whoever is cheapest?  There are 
>> ways to work with that challenge as long as your carriers are ready to do so.
>> 
>> On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger > > wrote:
>> If we purchase our numbers through wholesalers, would we need delegated 
>> certificates if we are sending an outbound call through a vendor that is not 
>> the wholesaler we got the number from?
>> 
>> On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen > > wrote:
>> There is a STIR-SHAKEN process of registering and testing with the Policy
>> Administrator (PA) as a certified Service Provider (SP) before you can
>> purchase SHAKEN token certificates from a Certificate Authority (CA) and
>> begin to engage in using the technology. This is not a walk in the park.
>> Transnexus is one of two public CA's in the U.S. today. They are experts on
>> the subject and can help you through both processes. In order to get the
>> best call attestation you must prove to the PA and CA that you are a bono
>> fide service provider and not a bad-acting enterprise on a network that
>> deserves lesser attestation levels. 
>> 
>> One of the registration requirements is a SP 's access to valid national
>> phone number pools. This has been very confusing for some resale providers
>> that purchase and use numbers from wholesalers only. If your organization
>> does not have it's own numbering resources, you can register using your
>> wholesale provider's numbering pool data. Don't assume you have to register
>> with the FCC and possess your own pool of numbers to become a registered
>> SHAKEN SP.
>> 
>> SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
>> attestation level possible for a SP is essential to the SP and the SHAKEN
>> ecosystem. Register and test for the best attestation level possible.
>> Transnexus is a seasoned expert on the subject and a U.S. registered CA with
>> the PA. 
>> 
>> Dave
>> 
>> 
>> -Original Message-
>> From: VoiceOps > > On Behalf Of Mary Lou Carey
>> Sent: Tuesday, September 1, 2020 5:36 PM
>> To: Dovid Bender mailto:do...@telecurve.com>>
>> Cc: Voiceops.org mailto:voiceops@voiceops.org>>
>> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
>> 
>> I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless and
>> VOIP carriers install and maintain their PSTN networks for the the last 20
>> years. I can help clients get their FCC Certification to become a
>> STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training, etc
>> (if you need those pieces). Once my clients get their certification, I refer
>> them to TransNexus. Jim and his team can help you with the process of
>> turning your STIR/SHAKEN services up.
>> 
>> MARY LOU CAREY
>> BackUP Telecom Consulting
>> Office: 615-791-9969
>> Cell: 615-796-
>> 
>> On 2020-08-31 05:37 AM, Dovid Bender wrote:
>> > Hi,
>> > 
>> > Does anyone have a recommendation for a company that get us everything 
>> > needed for STIR/SHAKEN setup? By setup I mean helping us file to get a 
>> > cert etc. From the small research I have done there is a lot of 
>> > fragmented information out there and it would be easier for us to pay 
>> > someone else to do this then invest our own time to take care of this.
>> > 
>> > TIA.
>> > 
>> > Regards,
>> > 
>> > Dovid
>> > ___
>> > 

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

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


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


-Paul



From: VoiceOps  on behalf of Alex Balashov 

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

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

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

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

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


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

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

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

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

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

Dave


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

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

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

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

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Alex Balashov]

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

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

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

> On Sep 2, 2020, at 2:39 PM, Carlos Alvarez  wrote:
> 
> 
> If I understand correctly, no as long as your providers are all supporting 
> this.  What I think you mean is that you get origination/DIDs from say 
> Bandwidth, and you use LCR to route calls to whoever is cheapest?  There are 
> ways to work with that challenge as long as your carriers are ready to do so.
> 
>> On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger  wrote:
>> If we purchase our numbers through wholesalers, would we need delegated 
>> certificates if we are sending an outbound call through a vendor that is not 
>> the wholesaler we got the number from?
>> 
>>> On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen  wrote:
>>> There is a STIR-SHAKEN process of registering and testing with the Policy
>>> Administrator (PA) as a certified Service Provider (SP) before you can
>>> purchase SHAKEN token certificates from a Certificate Authority (CA) and
>>> begin to engage in using the technology. This is not a walk in the park.
>>> Transnexus is one of two public CA's in the U.S. today. They are experts on
>>> the subject and can help you through both processes. In order to get the
>>> best call attestation you must prove to the PA and CA that you are a bono
>>> fide service provider and not a bad-acting enterprise on a network that
>>> deserves lesser attestation levels. 
>>> 
>>> One of the registration requirements is a SP 's access to valid national
>>> phone number pools. This has been very confusing for some resale providers
>>> that purchase and use numbers from wholesalers only. If your organization
>>> does not have it's own numbering resources, you can register using your
>>> wholesale provider's numbering pool data. Don't assume you have to register
>>> with the FCC and possess your own pool of numbers to become a registered
>>> SHAKEN SP.
>>> 
>>> SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
>>> attestation level possible for a SP is essential to the SP and the SHAKEN
>>> ecosystem. Register and test for the best attestation level possible.
>>> Transnexus is a seasoned expert on the subject and a U.S. registered CA with
>>> the PA. 
>>> 
>>> Dave
>>> 
>>> 
>>> -Original Message-
>>> From: VoiceOps  On Behalf Of Mary Lou Carey
>>> Sent: Tuesday, September 1, 2020 5:36 PM
>>> To: Dovid Bender 
>>> Cc: Voiceops.org 
>>> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
>>> 
>>> I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless and
>>> VOIP carriers install and maintain their PSTN networks for the the last 20
>>> years. I can help clients get their FCC Certification to become a
>>> STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training, etc
>>> (if you need those pieces). Once my clients get their certification, I refer
>>> them to TransNexus. Jim and his team can help you with the process of
>>> turning your STIR/SHAKEN services up.
>>> 
>>> MARY LOU CAREY
>>> BackUP Telecom Consulting
>>> Office: 615-791-9969
>>> Cell: 615-796-
>>> 
>>> On 2020-08-31 05:37 AM, Dovid Bender wrote:
>>> > Hi,
>>> > 
>>> > Does anyone have a recommendation for a company that get us everything 
>>> > needed for STIR/SHAKEN setup? By setup I mean helping us file to get a 
>>> > cert etc. From the small research I have done there is a lot of 
>>> > fragmented information out there and it would be easier for us to pay 
>>> > someone else to do this then invest our own time to take care of this.
>>> > 
>>> > TIA.
>>> > 
>>> > Regards,
>>> > 
>>> > Dovid
>>> > ___
>>> > VoiceOps mailing list
>>> > VoiceOps@voiceops.org
>>> > https://puck.nether.net/mailman/listinfo/voiceops
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>> 
>>> ___
>>> VoiceOps mailing list
>>> VoiceOps@voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Paul Timmins]

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



From: VoiceOps  on behalf of Jared Geiger 

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

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

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

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

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

Dave


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

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

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

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

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

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Carlos Alvarez]

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

On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger  wrote:

> If we purchase our numbers through wholesalers, would we need delegated
> certificates if we are sending an outbound call through a vendor that is
> not the wholesaler we got the number from?
>
> On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen  wrote:
>
>> There is a STIR-SHAKEN process of registering and testing with the Policy
>> Administrator (PA) as a certified Service Provider (SP) before you can
>> purchase SHAKEN token certificates from a Certificate Authority (CA) and
>> begin to engage in using the technology. This is not a walk in the park.
>> Transnexus is one of two public CA's in the U.S. today. They are experts
>> on
>> the subject and can help you through both processes. In order to get the
>> best call attestation you must prove to the PA and CA that you are a bono
>> fide service provider and not a bad-acting enterprise on a network that
>> deserves lesser attestation levels.
>>
>> One of the registration requirements is a SP 's access to valid national
>> phone number pools. This has been very confusing for some resale providers
>> that purchase and use numbers from wholesalers only. If your organization
>> does not have it's own numbering resources, you can register using your
>> wholesale provider's numbering pool data. Don't assume you have to
>> register
>> with the FCC and possess your own pool of numbers to become a registered
>> SHAKEN SP.
>>
>> SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
>> attestation level possible for a SP is essential to the SP and the SHAKEN
>> ecosystem. Register and test for the best attestation level possible.
>> Transnexus is a seasoned expert on the subject and a U.S. registered CA
>> with
>> the PA.
>>
>> Dave
>>
>>
>> -Original Message-
>> From: VoiceOps  On Behalf Of Mary Lou
>> Carey
>> Sent: Tuesday, September 1, 2020 5:36 PM
>> To: Dovid Bender 
>> Cc: Voiceops.org 
>> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
>>
>> I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless
>> and
>> VOIP carriers install and maintain their PSTN networks for the the last 20
>> years. I can help clients get their FCC Certification to become a
>> STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training,
>> etc
>> (if you need those pieces). Once my clients get their certification, I
>> refer
>> them to TransNexus. Jim and his team can help you with the process of
>> turning your STIR/SHAKEN services up.
>>
>> MARY LOU CAREY
>> BackUP Telecom Consulting
>> Office: 615-791-9969
>> Cell: 615-796-
>>
>> On 2020-08-31 05:37 AM, Dovid Bender wrote:
>> > Hi,
>> >
>> > Does anyone have a recommendation for a company that get us everything
>> > needed for STIR/SHAKEN setup? By setup I mean helping us file to get a
>> > cert etc. From the small research I have done there is a lot of
>> > fragmented information out there and it would be easier for us to pay
>> > someone else to do this then invest our own time to take care of this.
>> >
>> > TIA.
>> >
>> > Regards,
>> >
>> > Dovid
>> > ___
>> > VoiceOps mailing list
>> > VoiceOps@voiceops.org
>> > https://puck.nether.net/mailman/listinfo/voiceops
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Jared Geiger]

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

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

> There is a STIR-SHAKEN process of registering and testing with the Policy
> Administrator (PA) as a certified Service Provider (SP) before you can
> purchase SHAKEN token certificates from a Certificate Authority (CA) and
> begin to engage in using the technology. This is not a walk in the park.
> Transnexus is one of two public CA's in the U.S. today. They are experts on
> the subject and can help you through both processes. In order to get the
> best call attestation you must prove to the PA and CA that you are a bono
> fide service provider and not a bad-acting enterprise on a network that
> deserves lesser attestation levels.
>
> One of the registration requirements is a SP 's access to valid national
> phone number pools. This has been very confusing for some resale providers
> that purchase and use numbers from wholesalers only. If your organization
> does not have it's own numbering resources, you can register using your
> wholesale provider's numbering pool data. Don't assume you have to register
> with the FCC and possess your own pool of numbers to become a registered
> SHAKEN SP.
>
> SHAKEN ROBO call mitigation is a new frontier, and obtaining the best
> attestation level possible for a SP is essential to the SP and the SHAKEN
> ecosystem. Register and test for the best attestation level possible.
> Transnexus is a seasoned expert on the subject and a U.S. registered CA
> with
> the PA.
>
> Dave
>
>
> -Original Message-
> From: VoiceOps  On Behalf Of Mary Lou Carey
> Sent: Tuesday, September 1, 2020 5:36 PM
> To: Dovid Bender 
> Cc: Voiceops.org 
> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup
>
> I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless and
> VOIP carriers install and maintain their PSTN networks for the the last 20
> years. I can help clients get their FCC Certification to become a
> STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training,
> etc
> (if you need those pieces). Once my clients get their certification, I
> refer
> them to TransNexus. Jim and his team can help you with the process of
> turning your STIR/SHAKEN services up.
>
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-
>
> On 2020-08-31 05:37 AM, Dovid Bender wrote:
> > Hi,
> >
> > Does anyone have a recommendation for a company that get us everything
> > needed for STIR/SHAKEN setup? By setup I mean helping us file to get a
> > cert etc. From the small research I have done there is a lot of
> > fragmented information out there and it would be easier for us to pay
> > someone else to do this then invest our own time to take care of this.
> >
> > TIA.
> >
> > Regards,
> >
> > Dovid
> > ___
> > VoiceOps mailing list
> > VoiceOps@voiceops.org
> > https://puck.nether.net/mailman/listinfo/voiceops
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Looking for SIP/PRI provider

[Eric Wieling via VoiceOps]

Many Adtran NetVanta and Total Access 9xx boxes can convert a PRI to SIP 
or SIP to PRI.


On 9/2/20 12:56 PM, Christopher Aloi wrote:
We have a customer who needs a PRI to SIP gateway to handle some legacy 
applications and a service provider to handle their calls (1T!1, 
~25k/month).  It is not a market we deal with but I am looking to refer 
the customer to a provider who does.  Any recommendations?  I would just 
direct the customer to the provider, not looking to stay in the middle 
of this.


Thanks,

Chris



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



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

Re: [VoiceOps] Looking for SIP/PRI provider

[J. Hellenthal via VoiceOps]

As much as I hate to suggest it in light of the recent BGP problems that arose 
with them but Centurylink can handle what you need. I you get ahold of them and 
they suggest a representative, you can find one here https://www.doyen-ns.com 
which may be a good place to start. They’ll help you get it figured out. If 
he’s available “Chris Scott” ask for him. He’ll bend over backwards to achieve 
what you need… And let him know I said hi!

Good luck

> On Sep 2, 2020, at 11:57, Christopher Aloi  wrote:
> 
> Should read, 25k MOU per month!
> 
> On Wed, Sep 2, 2020 at 12:56 PM Christopher Aloi  wrote:
> We have a customer who needs a PRI to SIP gateway to handle some legacy 
> applications and a service provider to handle their calls (1T!1, ~25k/month). 
>  It is not a market we deal with but I am looking to refer the customer to a 
> provider who does.  Any recommendations?  I would just direct the customer to 
> the provider, not looking to stay in the middle of this.
> 
> Thanks,
> 
> Chris
> 
> 
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops


-- 

J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a 
lot about anticipated traffic volume.








smime.p7s
Description: S/MIME cryptographic signature
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Looking for SIP/PRI provider

[Matthew Yaklin]

I was just going to ask where are they located? What part of the country? If in 
my region I might say us. If they are half way across the country I would pass.

Matt


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



From: VoiceOps  on behalf of Brandon Svec 

Sent: Wednesday, September 2, 2020 1:03 PM
To: Christopher Aloi 
Cc: Voiceops.org 
Subject: Re: [VoiceOps] Looking for SIP/PRI provider

Pretty much anyone provides this.  I would first decide if you want to go with 
an OTT (over the top) provider or ILEC/CLEC that services your customer's 
location.  For OTT, I have always liked Nexvortex.  They have been around a 
long time.
Brandon Svec


On Wed, Sep 2, 2020 at 9:58 AM Christopher Aloi 
mailto:cta...@gmail.com>> wrote:
Should read, 25k MOU per month!

On Wed, Sep 2, 2020 at 12:56 PM Christopher Aloi 
mailto:cta...@gmail.com>> wrote:
We have a customer who needs a PRI to SIP gateway to handle some legacy 
applications and a service provider to handle their calls (1T!1, ~25k/month).  
It is not a market we deal with but I am looking to refer the customer to a 
provider who does.  Any recommendations?  I would just direct the customer to 
the provider, not looking to stay in the middle of this.

Thanks,

Chris


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

Re: [VoiceOps] Looking for SIP/PRI provider

[Brandon Svec]

Pretty much anyone provides this.  I would first decide if you want to go
with an OTT (over the top) provider or ILEC/CLEC that services your
customer's location.  For OTT, I have always liked Nexvortex.  They have
been around a long time.
*Brandon Svec*


On Wed, Sep 2, 2020 at 9:58 AM Christopher Aloi  wrote:

> Should read, 25k MOU per month!
>
> On Wed, Sep 2, 2020 at 12:56 PM Christopher Aloi  wrote:
>
>> We have a customer who needs a PRI to SIP gateway to handle some legacy
>> applications and a service provider to handle their calls (1T!1,
>> ~25k/month).  It is not a market we deal with but I am looking to refer the
>> customer to a provider who does.  Any recommendations?  I would just direct
>> the customer to the provider, not looking to stay in the middle of this.
>>
>> Thanks,
>>
>> Chris
>>
>>
>> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Looking for SIP/PRI provider

[Dovid Bender]

Try ric...@jivetel.com. They have a lot of legacy clients that they help
accommodate and are knowledgeable in the different gateway options.


On Wed, Sep 2, 2020 at 12:58 PM Christopher Aloi  wrote:

> We have a customer who needs a PRI to SIP gateway to handle some legacy
> applications and a service provider to handle their calls (1T!1,
> ~25k/month).  It is not a market we deal with but I am looking to refer the
> customer to a provider who does.  Any recommendations?  I would just direct
> the customer to the provider, not looking to stay in the middle of this.
>
> Thanks,
>
> Chris
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Looking for SIP/PRI provider

[Christopher Aloi]

We have a customer who needs a PRI to SIP gateway to handle some legacy
applications and a service provider to handle their calls (1T!1,
~25k/month).  It is not a market we deal with but I am looking to refer the
customer to a provider who does.  Any recommendations?  I would just direct
the customer to the provider, not looking to stay in the middle of this.

Thanks,

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

Re: [VoiceOps] Looking for SIP/PRI provider

[Christopher Aloi]

Should read, 25k MOU per month!

On Wed, Sep 2, 2020 at 12:56 PM Christopher Aloi  wrote:

> We have a customer who needs a PRI to SIP gateway to handle some legacy
> applications and a service provider to handle their calls (1T!1,
> ~25k/month).  It is not a market we deal with but I am looking to refer the
> customer to a provider who does.  Any recommendations?  I would just direct
> the customer to the provider, not looking to stay in the middle of this.
>
> Thanks,
>
> Chris
>
>
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] 3CX Trunk Unregistering

[Tim Bray via VoiceOps]

On 02/09/2020 13:46, Pete Eisengrein wrote:
The problem comes in when we get the un-REGISTER but it is not 
followed by a new REGISTER and calls begin to fail. The customer is 
obviously frustrated and is expecting _me _to do something about it, 
but...


Sounds like the timer for refreshing the registration is longer than the 
registration valid time (or the same).


I don't know if 3CX works like that.  I've asked out support team at work.


As for the 3CX not under support.  You can get quite big systems now - 
like 8 calls, (maybe bigger) without paying 3CX.  So tempting for people 
to use the free one.


--
Tim Bray
Huddersfield, GB
t...@kooky.org

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

Re: [VoiceOps] 3CX Trunk Unregistering

[Pete Eisengrein]

Thanks Carlos.

I did try searching the web, and thus the 3CX forums, before emailing the
group but came up blank.

We will move to unauthenticated, IP-based trust if necessary, but that's
usually a last resort. But I will ask about the low-level settings. Thanks
for the advice.

On Wed, Sep 2, 2020 at 10:11 AM Carlos Alvarez  wrote:

> We host 3CX for our customers, in our own infrastructure, and manage it
> for them.  I have an advanced certification with them, but this sort of
> thing was never covered in training, and I've never heard of it before.
> Our core infrastructure is Asterisk (where all other servers register to).
> So this all may be very different from your situation.  We also have one
> customer with their own off-net server.  In every case, we use IP
> authentication and not usernames, that may be something to consider trying.
>
> 3CX has some semi-hidden features that can deeply modify the SIP
> behavior.  We have not changed any of that, other than how CLID is
> presented so that calls that forward from the PBX who the original CLID and
> not the PBX's own CLID.  I'd ask if any of that has been changed.
>
> The 3CX forums are very good, and very much to the point.  It's a resource
> you should search, at least, and perhaps post there.  Their support is also
> quite good, if maybe slightly slow because most of them are in the EU and
> the timezones play a factor.  If the customer is off support, well, excuse
> me, but screw them for being idiots.
>
>
> On Wed, Sep 2, 2020 at 5:48 AM Pete Eisengrein  wrote:
>
>> Hi all.
>>
>> I have a customer running 3CX who sometimes has calling problems because
>> the trunk becomes unregistered from our Broadworks platform. When you look
>> at the REGISTERs, there are a couple peculiarities:
>>
>>
>>1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs
>>rather than just re-registering the session
>>2. 3CX sometimes, but not always, starts a new session (new Call-ID)
>>for the "new" REGISTER rather than simply refreshing the existing session
>>3. Not a problem, but something I find odd and worth mentioning is
>>that it sends the User-Agent info when it un-registers but *not *when
>>it registers
>>
>>
>> The problem comes in when we get the un-REGISTER but it is not followed
>> by a new REGISTER and calls begin to fail. The customer is obviously
>> frustrated and is expecting *me *to do something about it, but
>>
>> Anyone familiar with 3CX and can give advice? Any idea why it behaves
>> this way? They're running v16.0.5.619 (based on #3 above).
>>
>> Thanks in advance.
>> -Pete
>>
>>
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup

[Dave Frigen]

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

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

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

Dave
 

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

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

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

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

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

Re: [VoiceOps] 3CX Trunk Unregistering

[Carlos Alvarez]

We host 3CX for our customers, in our own infrastructure, and manage it for
them.  I have an advanced certification with them, but this sort of thing
was never covered in training, and I've never heard of it before.  Our core
infrastructure is Asterisk (where all other servers register to).  So this
all may be very different from your situation.  We also have one customer
with their own off-net server.  In every case, we use IP authentication and
not usernames, that may be something to consider trying.

3CX has some semi-hidden features that can deeply modify the SIP behavior.
We have not changed any of that, other than how CLID is presented so that
calls that forward from the PBX who the original CLID and not the
PBX's own CLID.  I'd ask if any of that has been changed.

The 3CX forums are very good, and very much to the point.  It's a resource
you should search, at least, and perhaps post there.  Their support is also
quite good, if maybe slightly slow because most of them are in the EU and
the timezones play a factor.  If the customer is off support, well, excuse
me, but screw them for being idiots.


On Wed, Sep 2, 2020 at 5:48 AM Pete Eisengrein  wrote:

> Hi all.
>
> I have a customer running 3CX who sometimes has calling problems because
> the trunk becomes unregistered from our Broadworks platform. When you look
> at the REGISTERs, there are a couple peculiarities:
>
>
>1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs
>rather than just re-registering the session
>2. 3CX sometimes, but not always, starts a new session (new Call-ID)
>for the "new" REGISTER rather than simply refreshing the existing session
>3. Not a problem, but something I find odd and worth mentioning is
>that it sends the User-Agent info when it un-registers but *not *when
>it registers
>
>
> The problem comes in when we get the un-REGISTER but it is not followed by
> a new REGISTER and calls begin to fail. The customer is obviously
> frustrated and is expecting *me *to do something about it, but
>
> Anyone familiar with 3CX and can give advice? Any idea why it behaves this
> way? They're running v16.0.5.619 (based on #3 above).
>
> Thanks in advance.
> -Pete
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] 3CX Trunk Unregistering

[Mark Wiles]

Back some time ago, we had a customer using 3CX to our Metaswitch… somewhat 
similar issues.
Every time their 3CX had a hiccup, they too expected us to fix their issue… we 
could prove via capture it wasn’t us.  We tried everything we could come up 
with… no luck.  Finally suggested they engage 3CX… they told us they didn’t 
have support on the product.  While this doesn’t help your situation, it does 
let you know you’re not alone.



From: VoiceOps  On Behalf Of Pete Eisengrein
Sent: Wednesday, September 2, 2020 8:47 AM
To: Voiceops.org 
Subject: [VoiceOps] 3CX Trunk Unregistering

Hi all.

I have a customer running 3CX who sometimes has calling problems because the 
trunk becomes unregistered from our Broadworks platform. When you look at the 
REGISTERs, there are a couple peculiarities:


  1.  3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs rather 
than just re-registering the session
  2.  3CX sometimes, but not always, starts a new session (new Call-ID) for the 
"new" REGISTER rather than simply refreshing the existing session
  3.  Not a problem, but something I find odd and worth mentioning is that it 
sends the User-Agent info when it un-registers but not when it registers

The problem comes in when we get the un-REGISTER but it is not followed by a 
new REGISTER and calls begin to fail. The customer is obviously frustrated and 
is expecting me to do something about it, but

Anyone familiar with 3CX and can give advice? Any idea why it behaves this way? 
They're running v16.0.5.619 (based on #3 above).

Thanks in advance.
-Pete


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

Re: [VoiceOps] 3CX Trunk Unregistering

[Kent Adams]

Pete,

Does the same behavior happen regardless of how they are registered?
Specifically SRV, vs A record, vs IP registration? We have experienced some
peculiar behavior of this kind with customers and found that changing the
host resolution method to be an effective strategy for "fixing" such
problems.

Thanks,

Kent

On Wed, Sep 2, 2020 at 8:47 AM Pete Eisengrein  wrote:

> Hi all.
>
> I have a customer running 3CX who sometimes has calling problems because
> the trunk becomes unregistered from our Broadworks platform. When you look
> at the REGISTERs, there are a couple peculiarities:
>
>
>1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs
>rather than just re-registering the session
>2. 3CX sometimes, but not always, starts a new session (new Call-ID)
>for the "new" REGISTER rather than simply refreshing the existing session
>3. Not a problem, but something I find odd and worth mentioning is
>that it sends the User-Agent info when it un-registers but *not *when
>it registers
>
>
> The problem comes in when we get the un-REGISTER but it is not followed by
> a new REGISTER and calls begin to fail. The customer is obviously
> frustrated and is expecting *me *to do something about it, but
>
> Anyone familiar with 3CX and can give advice? Any idea why it behaves this
> way? They're running v16.0.5.619 (based on #3 above).
>
> Thanks in advance.
> -Pete
>
>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] 3CX Trunk Unregistering

[Pete Eisengrein]

Hi all.

I have a customer running 3CX who sometimes has calling problems because
the trunk becomes unregistered from our Broadworks platform. When you look
at the REGISTERs, there are a couple peculiarities:


   1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs
   rather than just re-registering the session
   2. 3CX sometimes, but not always, starts a new session (new Call-ID) for
   the "new" REGISTER rather than simply refreshing the existing session
   3. Not a problem, but something I find odd and worth mentioning is that
   it sends the User-Agent info when it un-registers but *not *when it
   registers


The problem comes in when we get the un-REGISTER but it is not followed by
a new REGISTER and calls begin to fail. The customer is obviously
frustrated and is expecting *me *to do something about it, but

Anyone familiar with 3CX and can give advice? Any idea why it behaves this
way? They're running v16.0.5.619 (based on #3 above).

Thanks in advance.
-Pete
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops