Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA
My call to the Sinch TFN resulted in a valid Identity header. Calls to other TFNs received no identity header. Calls to Sinch 1-425 ## answer & disconnect immediately Thanks for setting this up ? From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of David Frankel <dfrankel at zipdx.com> Date: Sunday, July 3, 2022 at 11:13 AM To: voiceops at voiceops.org <voiceops at voiceops.org> Subject: [VoiceOps] Identity Header Test Tool CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe. Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I see you have Bandwdith there. As an FYI when you *send* calls via BandWidth if you send the identity header with compact SIP headers they drop it. This is a known issue by them that they are working on. On Sun, Jul 3, 2022 at 11:13 AM David Frankel <dfrankel at zipdx.com> wrote:
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation? David Zilk CDK Global/IP Networked Services -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders. Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
It seems that BandWidth is currently signing all calls from their customer where the DID is not with BandWidth as B. On Tue, Jul 5, 2022 at 12:31 PM Zilk, David <David.Zilk at cdk.com> wrote:
I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation?
David Zilk CDK Global/IP Networked Services
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool
CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders.
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
https://www.bandwidth.com/blog/abcs-of-attestation-and-analytics/ This may be helpful. Dave From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Dovid Bender Sent: Tuesday, July 5, 2022 11:34 AM To: Zilk, David <David.Zilk at cdk.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool It seems that BandWidth is currently signing all calls from their customer where the DID is not with BandWidth as B. On Tue, Jul 5, 2022 at 12:31 PM Zilk, David <David.Zilk at cdk.com <mailto:David.Zilk at cdk.com> > wrote: I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation? David Zilk CDK Global/IP Networked Services -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> > On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders. Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth. CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com] ...And term provider 3 is a customer of Bandwidth.com. <https://www.bandwidth.com/blog/abcs-of-attestation-and-analytics/> Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co Schedule a meeting <https://ecg.co/lindsey/schedule>
On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com> wrote:
I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation?
David Zilk CDK Global/IP Networked Services
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool
CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders.
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
If that is the case, a scammer that should be either attested C, or not attested at all can game the system and upgrade their calls to any customer of Bandwidth to B. Granted, B attestation isn't much better than nothing, but still it violates both the intent and the letter of the law. David Zilk CDK Global/IP Networked Services From: Mark Lindsey <lindsey at e-c-group.com> Sent: Tuesday, July 5, 2022 9:58 AM To: Zilk, David <David.Zilk at cdk.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth. CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__Bandwidth.com&d=DwMFAg&c...>] ...And term provider 3 is a customer of Bandwidth.com.<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bandwidth.com_blog_...> Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co<mailto:mark at ecg.co> Schedule a meeting<https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule...> On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> wrote: I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation? David Zilk CDK Global/IP Networked Services -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders. Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__identity.legalcallsonly.org&d=DwMFAg&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=qZMqiJ48ZdgXQNJnrLDT8ChNCkk7sQ42nMiHCNHAHu2zOSre0DPgkmi2n_jtKDvD&s=9EE8xl5gvlIOy3Ck4bTVDx8WWiobc-X72SZEUOtN0o8&e=>. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
The primary problem to fix, in this scenario, is that Term Provider 2 is stripping the Identity header, and therefore violating 47 CFR?? 64.6302(a) <https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart...>. So many engineers have configured SBCs to strip every header except the handful they want to carry, but Identity needs to be added to those lists. The secondary problem to fix is that 47 CFR?? 64.6302(b) <https://www.ecfr.gov/current/title-47/chapter-I/subchapter-B/part-64/subpart...> allows intermediate providers to legally opt out of STIR/SHAKEN in any practical fashion. I am speculating in the example call flow shown below, but I wouldn't see Bandwidth's behavior as a key problem. The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality. Nobody just accepts SIP traffic from random, anonymous sources for termination. I'm glad Bandwidth is adding the attestation that it can add. Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co Schedule a meeting <https://ecg.co/lindsey/schedule>
On Jul 5, 2022, at 13:01, Zilk, David <David.Zilk at cdk.com> wrote:
If that is the case, a scammer that should be either attested C, or not attested at all can game the system and upgrade their calls to any customer of Bandwidth to B. Granted, B attestation isn?t much better than nothing, but still it violates both the intent and the letter of the law.
David Zilk CDK Global/IP Networked Services
From: Mark Lindsey <lindsey at e-c-group.com <mailto:lindsey at e-c-group.com>> Sent: Tuesday, July 5, 2022 9:58 AM To: Zilk, David <David.Zilk at cdk.com <mailto:David.Zilk at cdk.com>> Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool
I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth.
CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__Bandwidth.com&d=DwMFAg&c...>]
...And term provider 3 is a customer of Bandwidth.com. <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bandwidth.com_blog_...>
Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co <mailto:mark at ecg.co> Schedule a meeting <https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule...>
On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com <mailto:David.Zilk at cdk.com>> wrote:
I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation?
David Zilk CDK Global/IP Networked Services
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org>> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool
CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders.
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__identity.legalcallsonly....>. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
If term provider 2 has TDM trunks with term provider 1, there would be no headers to pass, correct? From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Mark Lindsey Sent: Tuesday, July 5, 2022 12:16 PM To: David Zilk <David.Zilk at cdk.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool The primary problem to fix, in this scenario, is that Term Provider 2 is stripping the Identity header, and therefore violating 47 CFR ? 64.6302(a)<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecfr.g...>. So many engineers have configured SBCs to strip every header except the handful they want to carry, but Identity needs to be added to those lists. The secondary problem to fix is that 47 CFR ? 64.6302(b)<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecfr.g...> allows intermediate providers to legally opt out of STIR/SHAKEN in any practical fashion. I am speculating in the example call flow shown below, but I wouldn't see Bandwidth's behavior as a key problem. The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality. Nobody just accepts SIP traffic from random, anonymous sources for termination. I'm glad Bandwidth is adding the attestation that it can add. Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co<mailto:mark at ecg.co> Schedule a meeting<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fecg.co%2Fl...> On Jul 5, 2022, at 13:01, Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> wrote: If that is the case, a scammer that should be either attested C, or not attested at all can game the system and upgrade their calls to any customer of Bandwidth to B. Granted, B attestation isn't much better than nothing, but still it violates both the intent and the letter of the law. David Zilk CDK Global/IP Networked Services From: Mark Lindsey <lindsey at e-c-group.com<mailto:lindsey at e-c-group.com>> Sent: Tuesday, July 5, 2022 9:58 AM To: Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth. CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense...>] ...And term provider 3 is a customer of Bandwidth.com.<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense...> Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co<mailto:mark at ecg.co> Schedule a meeting<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense...> On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> wrote: I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation? David Zilk CDK Global/IP Networked Services -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders. Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__identity.legalcallsonly.org%26d%3DDwMFAg%26c%3DN13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc%26r%3DVcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs%26m%3DqZMqiJ48ZdgXQNJnrLDT8ChNCkk7sQ42nMiHCNHAHu2zOSre0DPgkmi2n_jtKDvD%26s%3D9EE8xl5gvlIOy3Ck4bTVDx8WWiobc-X72SZEUOtN0o8%26e%3D&data=05%7C01%7Clriemer%40bestline.net%7C6273bc57ce064def5ed908da5eaaa9ac%7C48dea55b9e01496eb644a99251da8160%7C0%7C0%7C637926384372832575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=5jCCyLP5pZ1OMjYw8UPF1W%2Fq1YlaLngnvrs3%2ForzDg4%3D&reserved=0>. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fvoiceops&data=05%7C01%7Clriemer%40bestline.net%7C6273bc57ce064def5ed908da5eaaa9ac%7C48dea55b9e01496eb644a99251da8160%7C0%7C0%7C637926384372832575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TVifl2xeIJCwV9M0yUNvMrp%2FUBJ2qMtMQaBMpNMlA1k%3D&reserved=0> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fvoiceops&data=05%7C01%7Clriemer%40bestline.net%7C6273bc57ce064def5ed908da5eaaa9ac%7C48dea55b9e01496eb644a99251da8160%7C0%7C0%7C637926384372832575%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TVifl2xeIJCwV9M0yUNvMrp%2FUBJ2qMtMQaBMpNMlA1k%3D&reserved=0>
Mark, Agreed. I guess it comes down to how to decide who the originating carrier is that should be doing the attestation. As an intermediate carrier, Bandwidth should just pass through whatever Identity header they get; but if there is no Identity header (stripped header, TDM link in the path, originating carrier not attesting, etc.) then the only assumption they can make is that the partner originated the call (even if they didn?t) and ?B? is the only proper attestation they can apply. Bandwidth making the assumption that they are an intermediate carrier (and the unattested calls came from some other (non-partner) service provider) isn?t a reasonable assumption. David From: Mark Lindsey <lindsey at e-c-group.com> Sent: Tuesday, July 5, 2022 10:16 AM To: Zilk, David <David.Zilk at cdk.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool The primary problem to fix, in this scenario, is that Term Provider 2 is stripping the Identity header, and therefore violating 47 CFR ? 64.6302(a)<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ecfr.gov_current_ti...>. So many engineers have configured SBCs to strip every header except the handful they want to carry, but Identity needs to be added to those lists. The secondary problem to fix is that 47 CFR ? 64.6302(b)<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ecfr.gov_current_ti...> allows intermediate providers to legally opt out of STIR/SHAKEN in any practical fashion. I am speculating in the example call flow shown below, but I wouldn't see Bandwidth's behavior as a key problem. The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality. Nobody just accepts SIP traffic from random, anonymous sources for termination. I'm glad Bandwidth is adding the attestation that it can add. Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co<mailto:mark at ecg.co> Schedule a meeting<https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule...> On Jul 5, 2022, at 13:01, Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> wrote: If that is the case, a scammer that should be either attested C, or not attested at all can game the system and upgrade their calls to any customer of Bandwidth to B. Granted, B attestation isn?t much better than nothing, but still it violates both the intent and the letter of the law. David Zilk CDK Global/IP Networked Services From: Mark Lindsey <lindsey at e-c-group.com<mailto:lindsey at e-c-group.com>> Sent: Tuesday, July 5, 2022 9:58 AM To: Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> Cc: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth. CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__Bandwidth.com&d=DwMFAg&c...>] ...And term provider 3 is a customer of Bandwidth.com.<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bandwidth.com_blog_...> Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co<mailto:mark at ecg.co> Schedule a meeting<https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule...> On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> wrote: I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation? David Zilk CDK Global/IP Networked Services -----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders. Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__identity.legalcallsonly.org&d=DwMFAg&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=qZMqiJ48ZdgXQNJnrLDT8ChNCkk7sQ42nMiHCNHAHu2zOSre0DPgkmi2n_jtKDvD&s=9EE8xl5gvlIOy3Ck4bTVDx8WWiobc-X72SZEUOtN0o8&e=>. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=aeE_eSJTR92A8G3x5c2t8ijZIxi52ZwThftNTV696VFw81HptjOHUXj7g4LuI1NY&s=9OieWFAAriFZo3GZS0qjYxEuaYJPYcxjkXRzg-6KqJE&e=> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=aeE_eSJTR92A8G3x5c2t8ijZIxi52ZwThftNTV696VFw81HptjOHUXj7g4LuI1NY&s=9OieWFAAriFZo3GZS0qjYxEuaYJPYcxjkXRzg-6KqJE&e=>
What are your opinions regarding intermediate carriers signing unattested calls? Not to say they are the source of the call, but to facilitate tracebacks and take accountability for transiting the call from whatever upstream didn't sign or preserve the signature. Calvin Ellison Systems Architect calvin.ellison at voxox.com +1 (213) 285-0555 <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately. On Tue, Jul 5, 2022 at 11:47 AM Zilk, David <David.Zilk at cdk.com> wrote:
Mark,
Agreed. I guess it comes down to how to decide who the originating carrier is that should be doing the attestation.
As an intermediate carrier, Bandwidth should just pass through whatever Identity header they get; but if there is no Identity header (stripped header, TDM link in the path, originating carrier not attesting, etc.) then the only assumption they can make is that the partner originated the call (even if they didn?t) and ?B? is the only proper attestation they can apply.
Bandwidth making the assumption that they are an intermediate carrier (and the unattested calls came from some other (non-partner) service provider) isn?t a reasonable assumption.
David
*From:* Mark Lindsey <lindsey at e-c-group.com> *Sent:* Tuesday, July 5, 2022 10:16 AM *To:* Zilk, David <David.Zilk at cdk.com>; voiceops at voiceops.org *Subject:* Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool
The primary problem to fix, in this scenario, is that Term Provider 2 is stripping the Identity header, and therefore violating 47 CFR ? 64.6302(a) <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ecfr.gov_current_ti...>. So many engineers have configured SBCs to strip every header except the handful they want to carry, but *Identity* needs to be added to those lists.
The secondary problem to fix is that 47 CFR ? 64.6302(b) <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ecfr.gov_current_ti...> allows intermediate providers to legally opt out of STIR/SHAKEN in any practical fashion.
I am speculating in the example call flow shown below, but I wouldn't see Bandwidth's behavior as a key problem. The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality. Nobody just accepts SIP traffic from random, anonymous sources for termination. I'm glad Bandwidth is adding the attestation that it can add.
*Mark R Lindsey **|* *SMTS **|** +1-229-316-0013 **|* *mark at ecg.co* <mark at ecg.co>
Schedule a meeting <https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule...>
On Jul 5, 2022, at 13:01, Zilk, David <David.Zilk at cdk.com> wrote:
If that is the case, a scammer that should be either attested C, or not attested at all can game the system and upgrade their calls to any customer of Bandwidth to B. Granted, B attestation isn?t much better than nothing, but still it violates both the intent and the letter of the law.
David Zilk
CDK Global/IP Networked Services
*From:* Mark Lindsey <lindsey at e-c-group.com> *Sent:* Tuesday, July 5, 2022 9:58 AM *To:* Zilk, David <David.Zilk at cdk.com> *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool
I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth.
CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__Bandwidth.com&d=DwMFAg&c...> ]
...And term provider 3 is a customer of Bandwidth.com. <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bandwidth.com_blog_...>
*Mark R Lindsey **|* *SMTS **|** +1-229-316-0013 **|* *mark at ecg.co* <mark at ecg.co>
Schedule a meeting <https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule...>
On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com> wrote:
I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation?
David Zilk CDK Global/IP Networked Services
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool
CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders.
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__identity.legalcallsonly....>. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman...> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops <https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman...>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Carriers can host the signing of calls for other carriers, but every originating company needs its own token. VSPs can get fined big time for knowingly passing along robocalls of other carriers so just be very careful who you serve and make sure they have their own token. MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2022-07-05 02:02 PM, Calvin Ellison wrote:
What are your opinions regarding intermediate carriers signing unattested calls? Not to say they are the source of the call, but to facilitate tracebacks and take accountability for transiting the call from whatever upstream didn't sign or preserve the signature.
Calvin Ellison
Systems Architect
calvin.ellison at voxox.com
+1 (213) 285-0555
[8]
[9] [10] [11] [12] The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately.
On Tue, Jul 5, 2022 at 11:47 AM Zilk, David <David.Zilk at cdk.com> wrote:
Mark,
Agreed. I guess it comes down to how to decide who the originating carrier is that should be doing the attestation.
As an intermediate carrier, Bandwidth should just pass through whatever Identity header they get; but if there is no Identity header (stripped header, TDM link in the path, originating carrier not attesting, etc.) then the only assumption they can make is that the partner originated the call (even if they didn?t) and ?B? is the only proper attestation they can apply.
Bandwidth making the assumption that they are an intermediate carrier (and the unattested calls came from some other (non-partner) service provider) isn?t a reasonable assumption.
David
From: Mark Lindsey <lindsey at e-c-group.com> Sent: Tuesday, July 5, 2022 10:16 AM To: Zilk, David <David.Zilk at cdk.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool
The primary problem to fix, in this scenario, is that Term Provider 2 is stripping the Identity header, and therefore violating 47 CFR ? 64.6302(a) [1]. So many engineers have configured SBCs to strip every header except the handful they want to carry, but _Identity_ needs to be added to those lists.
The secondary problem to fix is that 47 CFR ? 64.6302(b) [1] allows intermediate providers to legally opt out of STIR/SHAKEN in any practical fashion.
I am speculating in the example call flow shown below, but I wouldn't see Bandwidth's behavior as a key problem. The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality. Nobody just accepts SIP traffic from random, anonymous sources for termination. I'm glad Bandwidth is adding the attestation that it can add.
Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co
Schedule a meeting [2]
On Jul 5, 2022, at 13:01, Zilk, David <David.Zilk at cdk.com> wrote:
If that is the case, a scammer that should be either attested C, or not attested at all can game the system and upgrade their calls to any customer of Bandwidth to B. Granted, B attestation isn?t much better than nothing, but still it violates both the intent and the letter of the law.
David Zilk
CDK Global/IP Networked Services
From: Mark Lindsey <lindsey at e-c-group.com> Sent: Tuesday, July 5, 2022 9:58 AM To: Zilk, David <David.Zilk at cdk.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool
I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth.
CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com [3]]
...And term provider 3 is a customer of Bandwidth.com. [4]
Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co
Schedule a meeting [5]
On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com> wrote:
I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation?
David Zilk CDK Global/IP Networked Services
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool
CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders.
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org [6]. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops [7] _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops [7]
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Links: ------ [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ecfr.gov_current_title-2D47_chapter-2DI_subchapter-2DB_part-2D64_subpart-2DHH_section-2D64.6302&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=aeE_eSJTR92A8G3x5c2t8ijZIxi52ZwThftNTV696VFw81HptjOHUXj7g4LuI1NY&s=hOdJJ6IH2hogIFreou6rwumeJHyESpE2STfbVEyextw&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=aeE_eSJTR92A8G3x5c2t8ijZIxi52ZwThftNTV696VFw81HptjOHUXj7g4LuI1NY&s=vIqTzfmopHuZNSqB4ZJS4QYpUWvfa-B0pSBCBkWgVSA&e= [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__Bandwidth.com&d=DwMFAg&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=qZMqiJ48ZdgXQNJnrLDT8ChNCkk7sQ42nMiHCNHAHu2zOSre0DPgkmi2n_jtKDvD&s=R4TtBNn8t5SrkyFy1ozowPSgquZflYU50Y-F6uixyH0&e= [4] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.bandwidth.com_blog_abcs-2Dof-2Dattestation-2Dand-2Danalytics_&d=DwMFAg&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=qZMqiJ48ZdgXQNJnrLDT8ChNCkk7sQ42nMiHCNHAHu2zOSre0DPgkmi2n_jtKDvD&s=G7fgN1eoXUXYZw4vwpfoD5Doij6odPvNXwS2PHlZyM0&e= [5] https://urldefense.proofpoint.com/v2/url?u=https-3A__ecg.co_lindsey_schedule&d=DwMFAg&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=qZMqiJ48ZdgXQNJnrLDT8ChNCkk7sQ42nMiHCNHAHu2zOSre0DPgkmi2n_jtKDvD&s=CBHDNMBQRfN66ebOCNYxTHugStaeRttBIJ0aIgaIuEk&e= [6] https://urldefense.proofpoint.com/v2/url?u=http-3A__identity.legalcallsonly.org&d=DwMFAg&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=qZMqiJ48ZdgXQNJnrLDT8ChNCkk7sQ42nMiHCNHAHu2zOSre0DPgkmi2n_jtKDvD&s=9EE8xl5gvlIOy3Ck4bTVDx8WWiobc-X72SZEUOtN0o8&e= [7] https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=aeE_eSJTR92A8G3x5c2t8ijZIxi52ZwThftNTV696VFw81HptjOHUXj7g4LuI1NY&s=9OieWFAAriFZo3GZS0qjYxEuaYJPYcxjkXRzg-6KqJE&e= [8] http://voxox.com [9] https://www.facebook.com/VOXOX/ [10] https://www.instagram.com/voxoxofficial/ [11] https://www.linkedin.com/company/3573541/admin/ [12] https://twitter.com/Voxox _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Allowing the unrestricted laundering of all calls placed through their network under their own ?B? attestation, uncritically and without differentiation, and without regard to any already-present attestation, is becoming a common intermediate service provider decision.
On Jul 5, 2022, at 3:02 PM, Calvin Ellison <calvin.ellison at voxox.com> wrote:
What are your opinions regarding intermediate carriers signing unattested calls? Not to say they are the source of the call, but to facilitate tracebacks and take accountability for transiting the call from whatever upstream didn't sign or preserve the signature.
Calvin Ellison Systems Architect calvin.ellison at voxox.com +1 (213) 285-0555
The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately.
On Tue, Jul 5, 2022 at 11:47 AM Zilk, David <David.Zilk at cdk.com> wrote: Mark,
Agreed. I guess it comes down to how to decide who the originating carrier is that should be doing the attestation.
As an intermediate carrier, Bandwidth should just pass through whatever Identity header they get; but if there is no Identity header (stripped header, TDM link in the path, originating carrier not attesting, etc.) then the only assumption they can make is that the partner originated the call (even if they didn?t) and ?B? is the only proper attestation they can apply.
Bandwidth making the assumption that they are an intermediate carrier (and the unattested calls came from some other (non-partner) service provider) isn?t a reasonable assumption.
David
From: Mark Lindsey <lindsey at e-c-group.com> Sent: Tuesday, July 5, 2022 10:16 AM To: Zilk, David <David.Zilk at cdk.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool
The primary problem to fix, in this scenario, is that Term Provider 2 is stripping the Identity header, and therefore violating 47 CFR ? 64.6302(a). So many engineers have configured SBCs to strip every header except the handful they want to carry, but Identity needs to be added to those lists.
The secondary problem to fix is that 47 CFR ? 64.6302(b) allows intermediate providers to legally opt out of STIR/SHAKEN in any practical fashion.
I am speculating in the example call flow shown below, but I wouldn't see Bandwidth's behavior as a key problem. The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality. Nobody just accepts SIP traffic from random, anonymous sources for termination. I'm glad Bandwidth is adding the attestation that it can add.
Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co
Schedule a meeting
On Jul 5, 2022, at 13:01, Zilk, David <David.Zilk at cdk.com> wrote:
If that is the case, a scammer that should be either attested C, or not attested at all can game the system and upgrade their calls to any customer of Bandwidth to B. Granted, B attestation isn?t much better than nothing, but still it violates both the intent and the letter of the law.
David Zilk
CDK Global/IP Networked Services
From: Mark Lindsey <lindsey at e-c-group.com> Sent: Tuesday, July 5, 2022 9:58 AM To: Zilk, David <David.Zilk at cdk.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool
I expect Bandwidth is attesting that they know the identity of the SIP trunking provider that sent your call to Bandwidth.
CDK Global -> [term provider 1] -> [term provider 2, Strips Identity Header] -> [term provider 3] -> [Bandwidth.com]
...And term provider 3 is a customer of Bandwidth.com.
Mark R Lindsey | SMTS | +1-229-316-0013 | mark at ecg.co
Schedule a meeting
On Jul 5, 2022, at 12:19, Zilk, David <David.Zilk at cdk.com> wrote:
I am getting results from a test to the Bandwidth number that are confusing. It appears that our Identity header is not making it through to them, however the call does have an Identity header, certified by Bandwith, with B attestation. This is odd as we don't have any direct business relationship with Bandwidth. How can they claim B attestation?
David Zilk CDK Global/IP Networked Services
-----Original Message----- From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [EXTERNAL] [VoiceOps] Identity Header Test Tool
CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders.
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Mark Lindsey wrote:
The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality.
As a side-note, I have observed that when calling Lumen/Level3 DIDs of ours from an AT&T mobile, those calls arrive to us with "C"-level attestation, signed with a CenturyLink/Lumen SHAKEN cert. -- Nathan
C level attestation is the appropriate attestation level for an intermediate provider to use when signing a call. Below is the text from ATIS-1000074.v002 regarding B level attestation: ============================================================== B. Partial Attestation: The signing provider shall satisfy all of the following conditions: * Is responsible for the origination of the call onto the IP-based service provider voice network. * Has a direct authenticated relationship with the customer and can identify the customer. * Has NOT established a verified association with the telephone number being used for the call. NOTE: By populating this value, the service provider attests that it can trace the source of the call to a customer for policy enforcement purposes. ============================================================== An intermediate provider is not ?responsible for the origination of the call onto the IP-based service provider voice network?. An intermediate provider does not have ?a direct authenticated relationship with the customer and can identify the customer?. The FCC worded it slightly differently, but perhaps more clearly, in the First Report and Order (FCC-20-42A1): ============================================================== 8. The STIR/SHAKEN framework relies on the originating voice service provider attesting to the subscriber?s identity. The SHAKEN specification allows an originating voice service provider to provide different ?levels? of attestation. Specifically, the voice service provider can indicate that (i) it can confirm the identity of the subscriber making the call, and that the subscriber is using its associated telephone number (?full? or ?A? attestation); (ii) it can confirm the identity of the subscriber but not the telephone number (?partial? or ?B? attestation); or merely that (iii) it is the point of entry to the IP network for a call that originated elsewhere, such as a call that originated abroad or on a domestic network that is not STIR/SHAKEN-enabled (?gateway? or ?C? attestation). ============================================================== An intermediate provider cannot ?confirm the identity of the subscriber?. Sincerely, Alec Fenichel From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Nathan Anderson <nathana at fsr.com> Date: Tuesday, July 5, 2022 at 19:04 To: 'Mark Lindsey' <lindsey at e-c-group.com>, voiceops at voiceops.org <voiceops at voiceops.org> Subject: Re: [VoiceOps] [EXTERNAL] Identity Header Test Tool Mark Lindsey wrote:
The ATIS destination of the C-level attestation is for a situation that, like flying pigs, doesn't appear to occur anywhere in reality.
As a side-note, I have observed that when calling Lumen/Level3 DIDs of ours from an AT&T mobile, those calls arrive to us with "C"-level attestation, signed with a CenturyLink/Lumen SHAKEN cert. -- Nathan _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fvoiceops&data=05%7C01%7Calec.fenichel%40transnexus.com%7C57c3d227476748a3156708da5edac04f%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C637926590880060406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=3q2CQUI1LgYhw9eXvxbXOBo8%2FWX2cs5e07g8L2Mxl%2Bk%3D&reserved=0
This totally rocks; thank you for putting this together. In case anyone is interested, here is what I happen to see when calling any of these numbers through VoIP Innovations' T.38 deck; I will try other LCR rate decks of theirs, as well as other term providers, in the near future: Like others here have observed happening to them, calling the Bandwidth.com number results in the call being shown as attested, but our original signed attestation has gone missing and been replaced with a "B"-level attestation by Bandwidth themselves. So perhaps VI does not send any term traffic to Bandwidth, or they just aren't included in the T.38 LCR (very likely, since VI's portal indicates that Bandwidth does not support T.38 on origination, so it's equally likely they don't for term, either, especially since it's much tricker to support for term if you aren't doing the T.38 gatewaying for all TDM- or POTS-destined traffic yourself), and either some intermediate provider is stripping our Identity header out or it's going IP-to-TDM-to-IP with no STI-CPS/OOB-SHAKEN. The Sinch number seems to be hosted by Inteliquent, and our own signed "A"-level attestation arrives at the destination unmolested. Makes sense since VI does a ton of business with IQ. None of our calls to any of the toll-free numbers are attested at all. Somewhat surprising in the case of Lumen/L3, even more surprising with Sinch/IQ. -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [VoiceOps] Identity Header Test Tool Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Inteliquent was just got bought out by Sinch so they are one and the same. Inteliquent also bought out several companies like Onvoy several years back so it has multiple company names riding its network. It's my understanding that Sinch (fka Inteliquent) also sells DID services through several different affiliate companies. So you can't always go by the name associated with the OCN. A better way to tell which NXXs are part of each carrier's network is to pay attention to the AOCN number associated with each of the NXXs in the LERG. MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2022-07-05 05:52 PM, Nathan Anderson wrote:
This totally rocks; thank you for putting this together.
In case anyone is interested, here is what I happen to see when calling any of these numbers through VoIP Innovations' T.38 deck; I will try other LCR rate decks of theirs, as well as other term providers, in the near future:
Like others here have observed happening to them, calling the Bandwidth.com number results in the call being shown as attested, but our original signed attestation has gone missing and been replaced with a "B"-level attestation by Bandwidth themselves. So perhaps VI does not send any term traffic to Bandwidth, or they just aren't included in the T.38 LCR (very likely, since VI's portal indicates that Bandwidth does not support T.38 on origination, so it's equally likely they don't for term, either, especially since it's much tricker to support for term if you aren't doing the T.38 gatewaying for all TDM- or POTS-destined traffic yourself), and either some intermediate provider is stripping our Identity header out or it's going IP-to-TDM-to-IP with no STI-CPS/OOB-SHAKEN.
The Sinch number seems to be hosted by Inteliquent, and our own signed "A"-level attestation arrives at the destination unmolested. Makes sense since VI does a ton of business with IQ.
None of our calls to any of the toll-free numbers are attested at all. Somewhat surprising in the case of Lumen/L3, even more surprising with Sinch/IQ.
-- Nathan
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [VoiceOps] Identity Header Test Tool
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I was aware of Inteliquent's history as Neutral Tandem & then getting merged with Onvoy, who itself was also owned by Zayo at one point, etc. But had no idea they had been gobbled up by Sinch, or even who Sinch was...clearly I'm way behind on my news, lol. I did briefly glance at Sinch's page before posting, but it just struck me as a Twilio clone, and I simply assumed they were using IQ numbers. I don't have a subscription to LERG, and it's not clear to me how often publicly-available resources (e.g., telcodata.us) are updated. But in most places, the IQ OCNs still seem to be listed as "ONVOY, LLC", and from looking at the IQ web site which is still a separate thing, it appears Sinch is looking to preserve the IQ branding for that set of products. So absent some change in marketing strategy or yet another set of acquisitions, I'm guessing that the OCN name is unlikely to change in the foreseeable future... -- Nathan -----Original Message----- From: Mary Lou Carey [mailto:marylou at backuptelecom.com] Sent: Tuesday, July 5, 2022 4:27 PM To: Nathan Anderson <nathana at fsr.com> Cc: 'David Frankel' <dfrankel at zipdx.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] Identity Header Test Tool Inteliquent was just got bought out by Sinch so they are one and the same. Inteliquent also bought out several companies like Onvoy several years back so it has multiple company names riding its network. It's my understanding that Sinch (fka Inteliquent) also sells DID services through several different affiliate companies. So you can't always go by the name associated with the OCN. A better way to tell which NXXs are part of each carrier's network is to pay attention to the AOCN number associated with each of the NXXs in the LERG. MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2022-07-05 05:52 PM, Nathan Anderson wrote:
This totally rocks; thank you for putting this together.
In case anyone is interested, here is what I happen to see when calling any of these numbers through VoIP Innovations' T.38 deck; I will try other LCR rate decks of theirs, as well as other term providers, in the near future:
Like others here have observed happening to them, calling the Bandwidth.com number results in the call being shown as attested, but our original signed attestation has gone missing and been replaced with a "B"-level attestation by Bandwidth themselves. So perhaps VI does not send any term traffic to Bandwidth, or they just aren't included in the T.38 LCR (very likely, since VI's portal indicates that Bandwidth does not support T.38 on origination, so it's equally likely they don't for term, either, especially since it's much tricker to support for term if you aren't doing the T.38 gatewaying for all TDM- or POTS-destined traffic yourself), and either some intermediate provider is stripping our Identity header out or it's going IP-to-TDM-to-IP with no STI-CPS/OOB-SHAKEN.
The Sinch number seems to be hosted by Inteliquent, and our own signed "A"-level attestation arrives at the destination unmolested. Makes sense since VI does a ton of business with IQ.
None of our calls to any of the toll-free numbers are attested at all. Somewhat surprising in the case of Lumen/L3, even more surprising with Sinch/IQ.
-- Nathan
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [VoiceOps] Identity Header Test Tool
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
It's a pain in the butt to change the OCN name on NXXs every time there is a merger. So most of the time the carriers just keep the name associated with the original company and just update the contact information and add a target OCN that ties them all together. I don't think the LERG lists the target OCN so really the only way someone who doesn't have direct access to BIRRDS can tell is by looking up the AOCN number in the LERG. All the big guys have been operating this way for years so it's pretty much a big mess because of all the mergers. I only know about Sinch because I have a dedicated sales rep I work with for the majority of my consulting clients. MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2022-07-05 07:09 PM, Nathan Anderson wrote:
I was aware of Inteliquent's history as Neutral Tandem & then getting merged with Onvoy, who itself was also owned by Zayo at one point, etc. But had no idea they had been gobbled up by Sinch, or even who Sinch was...clearly I'm way behind on my news, lol. I did briefly glance at Sinch's page before posting, but it just struck me as a Twilio clone, and I simply assumed they were using IQ numbers.
I don't have a subscription to LERG, and it's not clear to me how often publicly-available resources (e.g., telcodata.us) are updated. But in most places, the IQ OCNs still seem to be listed as "ONVOY, LLC", and from looking at the IQ web site which is still a separate thing, it appears Sinch is looking to preserve the IQ branding for that set of products. So absent some change in marketing strategy or yet another set of acquisitions, I'm guessing that the OCN name is unlikely to change in the foreseeable future...
-- Nathan
-----Original Message----- From: Mary Lou Carey [mailto:marylou at backuptelecom.com] Sent: Tuesday, July 5, 2022 4:27 PM To: Nathan Anderson <nathana at fsr.com> Cc: 'David Frankel' <dfrankel at zipdx.com>; voiceops at voiceops.org Subject: Re: [VoiceOps] Identity Header Test Tool
Inteliquent was just got bought out by Sinch so they are one and the same. Inteliquent also bought out several companies like Onvoy several years back so it has multiple company names riding its network. It's my understanding that Sinch (fka Inteliquent) also sells DID services through several different affiliate companies. So you can't always go by the name associated with the OCN. A better way to tell which NXXs are part of each carrier's network is to pay attention to the AOCN number associated with each of the NXXs in the LERG.
MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111
On 2022-07-05 05:52 PM, Nathan Anderson wrote:
This totally rocks; thank you for putting this together.
In case anyone is interested, here is what I happen to see when calling any of these numbers through VoIP Innovations' T.38 deck; I will try other LCR rate decks of theirs, as well as other term providers, in the near future:
Like others here have observed happening to them, calling the Bandwidth.com number results in the call being shown as attested, but our original signed attestation has gone missing and been replaced with a "B"-level attestation by Bandwidth themselves. So perhaps VI does not send any term traffic to Bandwidth, or they just aren't included in the T.38 LCR (very likely, since VI's portal indicates that Bandwidth does not support T.38 on origination, so it's equally likely they don't for term, either, especially since it's much tricker to support for term if you aren't doing the T.38 gatewaying for all TDM- or POTS-destined traffic yourself), and either some intermediate provider is stripping our Identity header out or it's going IP-to-TDM-to-IP with no STI-CPS/OOB-SHAKEN.
The Sinch number seems to be hosted by Inteliquent, and our own signed "A"-level attestation arrives at the destination unmolested. Makes sense since VI does a ton of business with IQ.
None of our calls to any of the toll-free numbers are attested at all. Somewhat surprising in the case of Lumen/L3, even more surprising with Sinch/IQ.
-- Nathan
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Frankel Sent: Sunday, July 3, 2022 8:05 AM To: voiceops at voiceops.org Subject: [VoiceOps] Identity Header Test Tool
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Thank you for building this. It helped us verify that we are correctly passing the Identity headers. I've found that no one is universally passing the headers end to end to all the test numbers. Some of our vendors will make it all the way to most but not all. I also think that some of the inbound validation is failing because of how the DID is routed to the end device. If a trunk is set to deliver e164 with a + in the From but the Identity header doesn't contain that, the validation match fails. I've tested the ZipDX numbers, Sansay, and Voxbeam numbers from full LCR and "OnNet" trunks via ANI, Bandwidth, Comcast, Intrado, Peerless, Sinch, and Level3. The closest to perfect is ANI's Toll Free passes validation to all 3 of ZipDX's TF DIDs. Bandwidth OnNet passes validation to all the numbers that are reachable via that route. ~Jared On Sun, Jul 3, 2022 at 8:12 AM David Frankel <dfrankel at zipdx.com> wrote:
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Thanks for this, David, very helpful. Earlier Lee asked, *"If term provider 2 has TDM trunks with term provider 1, there would be no headers to pass, correct?"* This is one of the (many) flaws to the SHAKEN implementation. It ignores the fact that there's still tons of legacy telco networking out there. And as such, an awful lot of traffic is having its attestation stripped. There's an out-of-band API lookup that can be used, but I don't think anyone's using it, really. Today, a small percentage of traffic we receive is attested. It's hard to turn on verification if most of the traffic is going to get flagged as possible spam -- it's like the boy who cried wolf. On Sun, Jul 3, 2022 at 11:13 AM David Frankel <dfrankel at zipdx.com> wrote:
Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help.
What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header.
Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid.
Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that.
Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible.
Happy 4th of July!
David Frankel ZipDX LLC St. George, UT USA
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (14)
-
abalashov＠evaristesys.com -
alec.fenichel＠transnexus.com -
calvin.ellison＠voxox.com -
David.Zilk＠cdk.com -
dfrankel＠zipdx.com -
dfrigen＠wabash.net -
dovid＠telecurve.com -
jared＠compuwizz.net -
lindsey＠e-c-group.com -
LRiemer＠bestline.net -
marylou＠backuptelecom.com -
matthew＠corp.crocker.com -
nathana＠fsr.com -
peeip989＠gmail.com