On an Asterisk instance powered with PR-815, I’ve observed that when CALLERID(num) is set to +123456789 and no 123456789 entry exists among TNs, then no Identity header at all is attached to outbound INVITE.
The outbound trunk is bound to a stir_shaken_profile defined with
attest_level: C
endpoint_behavior: on
I would expect that when a callerid is missing among TNs, a C attest_level would be used.
If think this behaviour also exist in 20.10.0-rc2.
If you add a TN entry matching 123456789, then Identity is present (with the attest_level that goes along the TN entry).
Can this be reproduced elsewhere or is it something tied to my setup ?
Your answer made me read ATIS-1000074.v003 (see [1]).
Let suppose, we are an ITSP getting an outbound call from a known authenticated customer.
For some reason (call forwarding, customer forgot to declare a legitimate number, customer wants to use a number is doesn’t own, …), your customer is using as a callerid, a number that is unknown by you.
My reading of ATIS-1000074.v003, §5.2.4, is that you have to attest this call with level B as:
you are responsible of the origination of the SIP call
you have a direct authenticated relationship with the customer
you have not established a verified relation with the callerid
Do you agree on this ?
If positive, how can a previously unknown callerid, can get a corresponding TN entry ?
Yeah I think you’re right. Go ahead and open a BUG issue (as opposed to an enhancement or improvement) at Issues · asterisk/asterisk · GitHub with a title like “Stir-Shaken doesn’t allow B or C attestation for unknown callerid which is allowed by ATIS-1000074.v003, §5.2.4”. I’ll have to add an ‘unknown_tn_attest_level’ option to ‘profile’ and maybe ‘attestation’.