I've also been unsure how the ANI should be encoded in the Identity header. Before S/S, most termination vendors wanted the CallerID to be in 10 digit form without a leading +1. Only a couple vendors could support e164 format with a leading + or +1.
On Tue, Jun 28, 2022 at 2:14 PM Nathan Anderson <[email protected]> wrote: > Following up here to let you all know that after consulting with Carlos, > the only obvious difference that could be seen between our PASSporTs that > were not being validated by both the Sansay & IDT tools and the ones being > generated by our upstreams that were being validated, was that we were > formatting the origination and destination numbers in globalized E.164 > format within the PASSporT JWT, complete with the + prefix, while the > others included the U.S. country code of 1 but no + prefix. > > I removed the +, and instantly both the Sansay and IDC tools could decode > and verify our PASSporTs. > > Much thanks to Carlos and Sansay for the assist in hunting this down. > > -- Nathan > ------------------------------ > *From:* VoiceOps <[email protected]> on behalf of Nathan > Anderson <[email protected]> > *Sent:* Tuesday, June 28, 2022 1:24 PM > *To:* Dovid Bender <[email protected]> > *Cc:* Voiceops.org <[email protected]> > *Subject:* Re: [VoiceOps] SHAKEN testing services > > Dovid, > > Our carriers swear up and down they are passing the Identity header we are > sending to them; I opened tickets with them to verify. And that if we do > not send an Identity header, both of them will attest the call themselves. > > At this point, I also have no reason to doubt them, because we are getting > identical results across two different carriers, and upon further testing, > what I've found is that if we *don't* send our own Identity header, our > calls pass validation with the PASSporT that our carriers generate & send. > It's when we send our own that we get the "No-TN-Validation" result back > from the Sansay test number. Which now makes me suspect that there must be > something wrong with what we're doing (even though that Voxbeam number that > I referenced in my prior response has no problem reading back our > attestation level to us). I just don't know *what* is wrong, because none > of these testing services actually give back detailed info about the mode > of failure in the case of a problem. > > I've reached out to Carlos/Sansay to see if they can pull logs on their > side in order to tell me what they're seeing when we call their number. > > You also implied that when you call the Sansay test number, you actually > get back an attestation level from it. That also has not been our > experience: the Sansay number tells us whether the TN validation passed, > failed, or is simply unvalidated...it doesn't read back the attestation > level if it passes. So I'm not sure why your experience is different > there, unless you mistakenly wrote "Sansays number" when you meant > something else (like "Voxbeam number" maybe). > > -- Nathan > > ------------------------------ > *From:* Dovid Bender <[email protected]> > *Sent:* Tuesday, June 28, 2022 3:18 AM > *To:* Nathan Anderson <[email protected]> > *Cc:* Carlos Perez <[email protected]>; Voiceops.org < > [email protected]> > *Subject:* Re: [VoiceOps] SHAKEN testing services > > 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 >
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
