Re: [SR-Users] ATIS-1000085 STIR/SHAKEN DIV PASSporT

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 &lt;david.villasmil.work(a)gmail.com&gt; &lt;david.villasmil.work(a)gmail.com&gt; *Sent:* Wednesday, June 9, 2021 6:50 AM *To:* Kamailio (SER) - Users Mailing List; miconda(a)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. https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-09#se… draft-ietf-stir-passport-divert-09 <https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-09#section-5> datatracker.ietf.org PASSporT Extension for Diverted Calls (Internet-Draft, 2020) On Wed, 9 Jun 2021 at 12:10, Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; wrote: -- Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users(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: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users(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: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users