How to configure a large amount of TNs for stir Shaken?


I need to be able to attest thousands of callerids in a target Stir Shaken system. I wonder what is the best way to configure the corresponding TNs entries in stir_shaken.conf.

I foresee three alternatives:

  1. use a templating engine to produce a file to be included in stir_shaken.conf
  2. query an SQL database
  3. query a web application.

Did I miss alternatives ?

For querying, at the moment, I can’t find many ways to customize queries when data stored in current database, use a different formats ,for instance, as TNs requires E164 and my database stores +E164 numbers.
Any guidance or advice for this ?


The “tn” sorcery object can be directed to a database.

The stir_shaken.conf.sample file has an example at the bottom.


The extconfig.conf.sample file also has an example that shows mapping stir_tn to an odbc database…

;stir_tn => odbc,asterisk

There’s also an alembic script in contrib/ast-db-manage/config/versions/
that will create the table for you.

The ‘+’ may be problematic though. If you have an existing table with +E164, I wonder if instead of creating stir_tn as a table, you could create it as a view and have the id column created as a function that strips the +. I’m not sure what that’d do to performance though. Alternatively, you may be able to create triggers on your existing table that populate the stir_tn table with the stripped TN.

Thanks for replying !

As I’ve never used realtime config yet, it seems to the simplest way to integrate Asterisk with my current SQL database is using curl with something like
stir_tn=>curl,http://myserver:8000/stir_tn (see [1])

This way, anytime an outbound call to 123456789, needs to be attested, Asterisk will send an HTTP GET request to http://myserver:8000/stir_tn/123456789, or will it sends an HTTP POST request to http://myserver:8000/stir_tn/ passing id=123456789 within POST content ?

How exactly should the HTTP server package the answer (ie sending back private_key_file, public_cert_url, attest_level, send_mky values for given stir_tn) ?
Adding in Content a line such as :


[1] cURL - Asterisk Documentation

The page you linked to has a number of good examples but basically…

Assuming the following config…

; Since TNs will actually rarely change change once added, adding a cache will reduce the load on your http server and backend and decrease response time.


; ss_tn has to match the tn=realtime line in sorcery.conf
ss_tn=curl, http://myserver:8000/stir_tn

When Asterisk needs a single TN (18005551212 for example), like when it’s doing an attestation, it should send a POST request to http://myserver:8000/stir_tn/single with id=18005551212 in the application/x-www-form-urlencoded POST body.

The server should then respond with…

If you were doing a stir_shaken show tns from the Asterisk CLI, Asterisk would send http://myserver:8000/stir_tn/multi with id=LIKE=% in the application/x-www-form-urlencoded POST body.

The server would then respond with …

Now, this is how it should work but I’ve never actually used the curl module. I will test it later today though.

I think in total I’ve heard of maybe 5 people using the curl module.

If I could specify with realtime/extconfig/whatever, an ODBC function defined in func_odbc.conf, that would be perfectly fine for me.

Thanks to your description, usage of curl module is much clearer for me, now.
I’ve never thought about this “stir_shaken show tns” command.
No matter how tns are defined, if there is a lot of them, you need to be able to control how many tns should be displayed on screen.

Life is hard, anyway :wink:

I just tested this and it seems to work fine except… You must not include fields that don’t have a value so if the TN will use the default private_key_file or public_cert_url, they must not be specified in the response. So if you only need to set a specific attest_level and let everything else default, you’d send back…


Though I couldn’t yet test this solution myself, I think it fully replies to my original post.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.