It is not implemented in the C code of Kamailio's module, but libsecsipid offers a function to sign any payload and headers json documents, pasting from its API:


// SecSIPIDSignJSONHP --
// * sign the JSON header and payload with provided private key
// * headerJSON -  header part in JSON forman (0-terminated string)
// * payloadJSON -  payload part in JSON forman (0-terminated string)
// * prvkeyPath - path to private key to be used to generate the signature
// * outPtr - to be set to the pointer containing the output (it is a
//   0-terminated string); the `*outPtr` must be freed after use
// * return: the length of `*outPtr`
extern int SecSIPIDSignJSONHP(char* headerJSON, char* payloadJSON, char* prvkeyPath, char** outPtr);


Meaning that one can build the headers and payload json documents as they want in the config with script operations and get it back encoded and with signature. This function can be easily exported to kamailio.cfg. Obviously, adding additional code to simplify usage in kamailio.cfg for this particular case would be probably better, but requires more C (to Kamailio) or Go (to libsecsipid) coding. If someone wants to do it, he/she is more that welcome. Personally I do not have an immediate need for this extension, with other higher priority tasks, it's not something I can allocate spare time for it.


More over, one can do alternative implementation in Lua or Python, using KEMI or inline execution via app_lua or app_python3. I remember people saying they did it (in Lua, iirc) before we had any dedicated kamailio module.


Cheers,
Daniel



On 09.06.21 16:30, Steven Wheeler wrote:

I believe that David's interpretation is correct. My understanding of the standard is that it allows carriers which are diverting a call (call forwarding, simultaneous ringing, etc.) on behalf of one of their customers to provide the original attestation they received as well as information about where the call is being diverted to.


I'm no expert in STIR/SHAKEN, but my understanding is that this proposal adds two options to handle diversions. The first is a "div" passport which is added as an additional Identity header to the outgoing SIP message. The second is a "div-o" passport which includes the original Identity header within its value and replaces the original Identity header in the outgoing SIP message.


Steven Wheeler


From: David Villasmil <david.villasmil.work@gmail.com>
Sent: Wednesday, June 9, 2021 6:50 AM
To: Kamailio (SER) - Users Mailing List; miconda@gmail.com
Cc: Steven Wheeler
Subject: Re: [SR-Users] ATIS-1000085 STIR/SHAKEN DIV PASSporT
 
From reading, I understood a div PASSporTs without attestation should be added by the entity doing the diversion.






On Wed, 9 Jun 2021 at 12:10, Daniel-Constantin Mierla <miconda@gmail.com> wrote:

Hello,


I was not aware if this, it does not seem to be from IETF. Can you summarize what it is about, eventually comparing what are the differences to the IETF STIR/SHAKEN specs? Is it about adding the caller signature in another header than Identity and also verifying  another header?


Cheers,
Daniel


On 08.06.21 23:58, Steven Wheeler wrote:

My Google searches aren't turning up any results, probably because this standard isn't finalized yet, but is anyone aware of a module which implements DIV PASSporTs for diverted calls?


More details on the standard here: https://transnexus.com/blog/2020/shaken-div-std-letter-ballot/


Steven Wheeler

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Regards,

David Villasmil
phone: +34669448337

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda