Nathan, Could it be your carriers that are dropping the headers? We have tested with a self signed cert and expected to have issues across the board. I don't want to name shame so overall using a few carriers to terminate calls to call Sansays number this is what we found - For some carriers regardless of what we sent attestation always seemed to have come back as B. - For others where we send a self signed cert the attestation always comes back as C. - For the carriers where if we send a self signed cert it comes in as C, if we send nothing the call comes in as B. - Looking at our apache logs we mainly see Verizon wireless getting our certs (could be others are caching?). Surprisingly #2 is Telnyx followed by random requests from AWS, Google and MS IP's.
On Mon, Jun 27, 2022 at 7:47 PM Nathan Anderson <[email protected]> wrote: > Carlos, > > Nifty; thanks. Unfortunately, I tried calling via 2 different carriers > who both pass through Identity headers if supplied, but got > No-TN-Validation result both times, implying that the PASSporT is getting > stripped out somewhere along the way. Your number looks to be supplied by > Level3, so a bit surprised at this result since I know for a fact both of > the services I tried have direct relationships with L3 & so I would think > that they'd look-up LRN & then try to send the call direct to them rather > than punt it to their LCRs, but **shrug**. > > I don't have direct access to L3/Lumen term...any chance I can send the > INVITE directly to an SBC on your side to just bypass the problematic > path(s)? (I presume I'd have to supply you with an IP on our side for you > to whitelist...) > > If I get a failed validation result from the service, is it possible for > somebody at Sansay look up on your side what specific part of the > validation failed for a given call? > > At the moment, here is where I stand: > > Found a Voxbeam number (302-257-7304) that will read back attestation > level. This will read back exactly the attestation level that I supply in > the PASSporT that I attach to the call, but it "works" regardless of > whether I'm using self-signed testing cert or an actual, valid SHAKEN > cert. So this service doesn't actually seem to be validating anything. At > least I know that Identity header is making it all the way there & that > it's encoded properly... > > IDT's service, on the other hand, will show that validation passed and the > correct attestation level if I do not transmit my own Identity header, and > instead have upstream carrier attest it themselves. However, if I send our > own Identity header using *either* our self-signed cert *or* our Sansay > SHAKEN cert, I get "N/A - problematic" as the result, with no other > explanation. > > If the Sansay testing service ends up having no problem validating our > PASSporTs, that will be reassuring from one perspective, but concerning > from another (why can IDT not validate any of our calls that we sign > ourselves using our production cert, but Sansay can?). So I'm kinda > rooting for the Sansay test service to fail when validating our calls... > > -- Nathan > > ------------------------------ > *From:* Carlos Perez <[email protected]> > *Sent:* Monday, June 27, 2022 3:37 PM > *To:* Nathan Anderson <[email protected]> > *Cc:* Voiceops.org <[email protected]> > *Subject:* Re: [VoiceOps] SHAKEN testing services > > Hi Nathan, > > We've put together something like you've requested (also open to the > public) recently. > In the future we will also provide the SPID in the report, right now you > get the status of the validation (Passed, Failed, No Validation) and the > attestation level. Feel free to dial +18586098097. > > Regards, > > Carlos Perez > Sansay, Inc. > +1 858-754-2216 Direct > +1 858-754-2211 Support > +1-858-754-2200 Main > > https://calendly.com/cperez-sansay/30min > > > On Mon, Jun 27, 2022 at 3:34 PM Nathan Anderson <[email protected]> wrote: > > Is there a list somewhere of third-party SHAKEN testing services available > to the public? Although our own STI-VS can validate our own PASSporTs > signed by our newly-minted private key, I want to verify what the world > at-large is seeing before I flip the switch on for all outgoing calls (& > potentially cause a bunch of problems if it turns out that something's > wrong). So I'm envisioning something along the lines of a phone # one can > call, and then get a report back of whether the terminating provider was > able to validate the contents of the Identity header or not, and if not > what the exact problem is. (Obviously the path between us and them would > need to be IP end-to-end unless out-of-band SHAKEN is in place for the PSTN > "glue" circuit.) > > I've found a couple, but the results for the ones I've tried (e.g., IDT > BYOC) are woefully simplistic and don't really explain what went wrong if > something does go wrong. > > Thanks, > > -- Nathan > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops > > _______________________________________________ > VoiceOps mailing list > [email protected] > https://puck.nether.net/mailman/listinfo/voiceops >
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
