My point was simply that there's more challenge in the bureaucracy than technical
implementation.
From a technical standpoint, the corner cases to consider are:
1. Number validity. Sure things that fit into an e.164 and/or recognizable number patterns
are simple. What happens when someone sends a From: URI of `sip:anonymous@domain.com` -
IIRC, the orig_tn field within the identity header is supposed to be numeric. Do you
reject the call? Attest it as "C" and provide this in the `orig_tn` field or in
a separate field?
2. Handling of forwarded calls - If you're sending a Diversion: header, do you also
add an Identity header with a `div` passport? Rewrite the From header? How do you
determine the attestation in that case?
3. Known customers sending numbers for which you're not the provider? Strictly
speaking this should attest as "B", but supposing that you're a secondary
vendor for the customer, and they're sending their primary number which is with a
different provider? Do you then allow them to submit an LOA (or whatever your
jurisdictional equivalent is) and attest as A?
The questions above are strictly for STI Authentication. Verification has some other
idiosyncrasies. Consider that there's three attestation levels for authentication,
and normally as a carrier it is not desirable to pass the Identity header to the customer
(consider if Privacy: is on). The general practice is to assign this to a verstat
parameter to the user portion of a PAI header's **USER** field, which is syntactically
awkward in Kamailio. Also strictly speaking AFAIK, the verstat only has two values -
passed or failed - so there's three possible attestation levels but they only map to
two verification levels. Therea are suggestions on how to deal with this, but I'm not
sure on their official status.
This brings up the final complexity: It's a rapidly evolving system without a high
degree of consistency vendor to vendor, so there's as much of a challenge of staying
on top of things as anything else.
-----Original Message-----
From: Olle E. Johansson via sr-users <sr-users(a)lists.kamailio.org>
Sent: Friday, October 20, 2023 2:08 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Olle E. Johansson <oej(a)edvina.net>
Subject: [SR-Users] Re: STIR/SHAKEN with Kamailio
CAUTION: This email originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
On 19 Oct 2023, at 18:46, Alex Balashov via sr-users
<sr-users(a)lists.kamailio.org> wrote:
Would join Kaufman here to say that free-range STIR/SHAKEN
implementations in the US are limited by the small number of certified
authentication providers, but presumably the EU version will to some
extent avoid US-style Guilded Age corporate welfare...
Sadly that's my view of
the US implementation. I can't say if it solved the problem, but I can see that a lot
of new and old actors got an oppurtunity to earn more money.
There's no EU-wide implementation or regulation at this point. I am aware of France.
There are certainly discussions.
/O
-- Alex
On 19 Oct 2023, at 09:33, Ben Kaufman via
sr-users <sr-users(a)lists.kamailio.org> wrote:
Like some of the other posters here, we've implemented it as a 302-redirect server.
This was the primary reason for using the secsipid rather than stirshaken module. Both
modules have a function to append an Identity header, but secsipid also has functions to
simply build the identity header which can then easily be appended to the reply, rather
than only appending to the request and plucking the Identity header from there. Secsipid
also has a function secsipid_sign() which allows for creating your own JWT. This is
useful if you want to create some variations on the Identity header - we use this to
create div passports (as opposed to shaken passports) in some situations.
Not sure how it will be implemented there, but the biggest challenge for me in the US was
acquiring certificates because there is a very limited number of regulatory approved
vendors.
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevar
istesys.com%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C31a9da72c1db4b26
7ff308dbd13cd073%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C63833383
1362925788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w9TCfesrCll46onz
GqiIndpnonmKJpi06JrS1s3FJK4%3D&reserved=0
Tel: +1-706-510-6800
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To
unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to
sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe: