14 Jun
2021
14 Jun
'21
11:15 a.m.
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(a)gmail.com>
*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…
<https://datatracker.ietf.org/doc/html/draft-ietf-stir-passport-divert-09#section-5>
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
<miconda(a)gmail.com <mailto: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:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
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/
<https://transnexus.com/blog/2020/shaken-div-std-letter-ballot/>
*Steven Wheeler*
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org <mailto: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
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org <mailto: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
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
<mailto:david.villasmil.work@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