<div dir="ltr">You might get more information from ATIS or the SIP Forum, where these standards are developed and tested. The IP-NNI is the specific work group, <a href="https://www.sipforum.org/activities/nni-task-force-introduction/">https://www.sipforum.org/activities/nni-task-force-introduction/</a>.<div><br></div><div>Their mailing lists can be found here <a href="https://www.sipforum.org/activities/mailing-list-overview-and-sign-up/">https://www.sipforum.org/activities/mailing-list-overview-and-sign-up/</a></div><div><br></div><div>Try the general discussion list first. The IP-NNI-specific mailing list has some additional verification required to join since it cross-posts to the ATIS paid membership mailing list.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:"Proxima Nova",sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:800;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:"Proxima Nova",sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:800;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:"Proxima Nova",sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:800;vertical-align:baseline;white-space:pre-wrap">Calvin Ellison</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:"Proxima Nova",sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Systems Architect</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:"Proxima Nova",sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><a href="mailto:calvin.ellison@voxox.com" target="_blank">calvin.ellison@voxox.com</a></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:10pt;font-family:"Proxima Nova",sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">+1 (213) 285-0555</span><span style="font-size:2.25pt;font-family:"Proxima Nova",sans-serif;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="http://voxox.com" target="_blank"><span style="font-size:10pt;font-family:"Proxima Nova",sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:139px;height:53px"><img src="https://lh5.googleusercontent.com/IpUfF3j5Y4T9UmEfLISsHXhgSenc131vheivxwdo6oyzyT1i5KfVnK8cftA1Qx-APliNpMTLx5PUOZ6k1lXHgMZvDXTXKkOWDpmXMlUcmsoKBZQIE_wip4sS8XMtdryakordMboW" width="139" height="53" style="margin-left:0px;margin-top:0px"></span></span></a></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><a href="https://www.facebook.com/VOXOX/" target="_blank"><span style="font-size:12pt;font-family:"Proxima Nova",sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:27px;height:27px"><img src="https://lh6.googleusercontent.com/qS_cwPUkKDN7UEAMffT5cjE1qN41OWxwS8HKu2DZi8R9OfYZCrdVxxPsyJy_SOaTDjWHjPAsBAzGnrgiSgrqDFWQKoi1HAdYUldZOtUQY_2EH0FC7M67fPko4xEmw7yfwiIpnRIF" width="27" height="27" style="margin-left:0px;margin-top:0px"></span></span></a><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"> </span><a href="https://www.instagram.com/voxoxofficial/" target="_blank"><span style="font-size:12pt;font-family:"Proxima Nova",sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:26px;height:26px"><img src="https://lh3.googleusercontent.com/AFGDGW3w1Yco24kAphoI6UZW170z44YjZpLZ0rHGRfCDNyctuD4DkIYooDbxEoJxrv0NQ4TswSWA4k0FPOD6w5v_ZFadQmeoXHhP1rgeZXdoLV7n-1PGxYhi31pbte1GHYwURny8" width="26" height="26" style="margin-left:0px;margin-top:0px"></span></span></a><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"> </span><a href="https://www.linkedin.com/company/3573541/admin/" target="_blank"><span style="font-size:12pt;font-family:"Proxima Nova",sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:26px;height:26px"><img src="https://lh6.googleusercontent.com/skcophrAnEg1jyCTXau3hMbh0GF9b1TeZ-SdROEZ0OxxHuTRKGNTS_lYIh2LIdgJ6rLTL1LMUVOlhxrHm7hxZ6p8XfYovu7xd-tXhvU1OEm4Hi6niWF6Trr7EfMFqGoLNMMeyYqk" width="26" height="26" style="margin-left:0px;margin-top:0px"></span></span></a><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"> </span><a href="https://twitter.com/Voxox" target="_blank"><span style="font-size:12pt;font-family:"Proxima Nova",sans-serif;color:rgb(17,85,204);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><span style="border:none;display:inline-block;overflow:hidden;width:26px;height:26px"><img src="https://lh6.googleusercontent.com/-IAXOgfWybf32YI5OpWoYsxhr1Iq2lvdT8a7LDpiP9IIXDxWemvF2v-dQrQC7ZPDn6eQtNQav84fAm6w39EUMfUkEq9e-mebAWCw5F1g57C3UWrnxcLoJmnPxTsSec0vI-biI8J7" width="26" height="26" style="margin-left:0px;margin-top:0px"></span></span></a></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:9pt;font-family:"Helvetica Neue",sans-serif;color:rgb(153,153,153);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">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.</span></p></span></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 28, 2022 at 4:00 PM Nathan Anderson <<a href="mailto:nathana@fsr.com">nathana@fsr.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
I could swear that I saw examples of decoded PASSporT JWTs where "orig" and "dest" fields had "+1" prefixed to the NANP number, but darned if I can find them now...</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Reading through RFCs 8224 and 8225 again, though example numbers referenced outside of a fully-formed example JSON are all + prefixed, the actual numbers within the JSON are
<i>not</i> (<i>e.g.</i>, see: RFC 8225, 5.2.1.4).</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
I also just spotted this language in RFC 8224 section 8.3:</div>
<blockquote style="border-left:3px solid rgb(200,200,200);border-top-color:rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-color:rgb(200,200,200);padding-left:1ex;margin-left:0.8ex">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<ul>
<li><span style="margin:0px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Implementations MUST drop any "+"s, internal dashes, parentheses, or other non-numeric characters, except for the "#" or "*" keys used in some special service
numbers (typically, these will appear only in the To header field value). This MUST result in an ASCII string limited to "#", "*", and digits without whitespace or visual separators.</span></li><li style="margin:0px;display:block;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</li><li style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span style="margin:0px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Next, an implementation must assess if the number string is a valid, globally routable number with a leading country code. If not, implementations SHOULD convert the number
into E.164 format, adding a country code if necessary; this may involve transforming the number from a dial string (see [RFC3966]), removing any national or international dialing prefixes or performing similar procedures.</span><br>
</li></ul>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
</div>
</blockquote>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">
<div>
<div><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">So I guess the implication is that since the number is
</span><i style="font-size:12pt;font-variant-ligatures:inherit;font-variant-caps:inherit;font-weight:inherit">assumed</i><span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt"> to be global at the outset, the + is unnecessary
(as well as actually against spec)?</span><br>
</div>
</div>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Talking to Carlos about this, apparently some STI-VS implementations do allow for the +. At the moment, it so happens that Twilio is back-end-ing the Sansay test # (though this is subject to change in the future), and perhaps they just don't. I did find it
odd that the various test services in question would consider a malformed (by spec) PASSporT to simply be unverified rather than report that the verification failed, but also found some Twilio documentation on their own implementation and what the possible
causes for certain results might be. Taken from <a href="https://www.twilio.com/docs/voice/trusted-calling-with-shakenstir#changes-for-twilio-customers" id="gmail-m_-5352957807705957403LPNoLPOWALinkPreview" target="_blank">https://www.twilio.com/docs/voice/trusted-calling-with-shakenstir#changes-for-twilio-customers</a> --</div>
<blockquote style="border-left:3px solid rgb(200,200,200);border-top-color:rgb(200,200,200);border-right-color:rgb(200,200,200);border-bottom-color:rgb(200,200,200);padding-left:1ex;margin-left:0.8ex">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt">'No-TN-Validation' Possible causes:</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<ul>
<li>A malformed E.164 phone number</li><li style="display:block">[...]</li><li>SHAKEN PASSporT orig field doesn't match with actual callerid in the SIP messages (P-Asserted-Identity, Remote-Party-Identity, or From header).</li><li>SHAKEN PASSporT dest field doesn't match with the actual destination of the call in the SIP Request-URI.</li><li style="display:block">[...]</li></ul>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
</div>
</blockquote>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Now, I would argue that many of the causes that they list in their documentation that can lead to this result should actually be considered failed validations instead; however, I guess a case could be made that if a PASSporT is signed with a cert that has a
proper chain-of-trust back to a legit STI-CA & shows no signs of tampering, but otherwise does not contain the proper 'orig' or 'dest' numbers, that it is not strictly speaking an invalid PASSporT, just one that merely doesn't actually speak to the call in
question that it's attached to.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
I suppose it's also possible that this STI-VS implementation may allow for + prefix in the phone numbers within the PASSporT contents, but engages in
<i><u>strict</u></i> matching of 'orig' and 'dest' with the TNs in the SIP headers; that is to say, if you have the + in the PASSporT but NOT in From: and/or P-A-I:, but the TNs are otherwise the same, then it still technically & literally "doesn't match".
Further testing would be needed to determine if maybe this was actually why our PASSporTs were returning this result.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
-- Nathan</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-5352957807705957403divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> VoiceOps <<a href="mailto:voiceops-bounces@voiceops.org" target="_blank">voiceops-bounces@voiceops.org</a>> on behalf of Jared Geiger <<a href="mailto:jared@compuwizz.net" target="_blank">jared@compuwizz.net</a>><br>
<b>Sent:</b> Tuesday, June 28, 2022 3:05 PM<br>
<b>Cc:</b> Voiceops.org <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
<b>Subject:</b> Re: [VoiceOps] SHAKEN testing services</font>
<div> </div>
</div>
<div>
<div dir="ltr">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. </div>
<br>
<div>
<div dir="ltr">On Tue, Jun 28, 2022 at 2:14 PM Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
I removed the +, and instantly both the Sansay and IDC tools could decode and verify our PASSporTs.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Much thanks to Carlos and Sansay for the assist in hunting this down.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
-- Nathan</div>
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072appendonsend"></div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> VoiceOps <<a href="mailto:voiceops-bounces@voiceops.org" target="_blank">voiceops-bounces@voiceops.org</a>>
on behalf of Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>><br>
<b>Sent:</b> Tuesday, June 28, 2022 1:24 PM<br>
<b>To:</b> Dovid Bender <<a href="mailto:dovid@telecurve.com" target="_blank">dovid@telecurve.com</a>><br>
<b>Cc:</b> Voiceops.org <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
<b>Subject:</b> Re: [VoiceOps] SHAKEN testing services</font>
<div> </div>
</div>
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Dovid,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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).</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
-- Nathan</div>
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072x_signature_bookmark"></div>
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072x_appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Dovid Bender <<a href="mailto:dovid@telecurve.com" target="_blank">dovid@telecurve.com</a>><br>
<b>Sent:</b> Tuesday, June 28, 2022 3:18 AM<br>
<b>To:</b> Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>><br>
<b>Cc:</b> Carlos Perez <<a href="mailto:cperez@sansay.com" target="_blank">cperez@sansay.com</a>>; Voiceops.org <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
<b>Subject:</b> Re: [VoiceOps] SHAKEN testing services</font>
<div> </div>
</div>
<div>
<div dir="ltr">Nathan,<br>
<br>
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
<div>- For some carriers regardless of what we sent attestation always seemed to have come back as B.<br>
- For others where we send a self signed cert the attestation always comes back as C.<br>
- 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.<br>
- 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.</div>
</div>
<br>
<div>
<div dir="ltr">On Mon, Jun 27, 2022 at 7:47 PM Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
Carlos,</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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 *<b>shrug*</b>.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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...)</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
At the moment, here is where I stand:</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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...</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
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...</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
-- Nathan</div>
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072x_x_gmail-m_399748475416406296signature_bookmark">
</div>
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072x_x_gmail-m_399748475416406296appendonsend">
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-5352957807705957403x_gmail-m_-7930021113393894072x_x_gmail-m_399748475416406296divRplyFwdMsg" dir="ltr">
<font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Carlos Perez <<a href="mailto:cperez@sansay.com" target="_blank">cperez@sansay.com</a>><br>
<b>Sent:</b> Monday, June 27, 2022 3:37 PM<br>
<b>To:</b> Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>><br>
<b>Cc:</b> Voiceops.org <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
<b>Subject:</b> Re: [VoiceOps] SHAKEN testing services</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div>Hi Nathan,</div>
<div><br>
</div>
<div>We've put together something like you've requested (also open to the public) recently.
<br>
</div>
<div>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.
<span>Feel free to dial +18586098097.</span></div>
<div><span><br>
</span></div>
<div><span>Regards,<br>
</span></div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>
<div>Carlos Perez</div>
<div>Sansay, Inc.</div>
<div>
<div>
<div>+1 858-754-2216 Direct</div>
<div>+1 858-754-2211 Support<br>
</div>
<div>+1-858-754-2200 Main</div>
<div><br>
</div>
<div><a href="https://calendly.com/cperez-sansay/30min" target="_blank">https://calendly.com/cperez-sansay/30min</a><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
</div>
</div>
<br>
<div>
<div dir="ltr">On Mon, Jun 27, 2022 at 3:34 PM Nathan Anderson <<a href="mailto:nathana@fsr.com" target="_blank">nathana@fsr.com</a>> wrote:<br>
</div>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.)<br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
-- Nathan<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
</div>
</div>
</div>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><br>
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote></div>