Hello,
trying to get outbound stir_shaken.conf and caller_id_number calls working
When I dial out of asterisk I want to send my Cert and attestation for the caller IDs we service sent.
however in stir_shaken.conf the setting caller_id_number wants to match only the dialed number not the caller ID the call is originating from. if I put in the number I am dialing it will pass the cert and attestation level of the call. If I put in the caller ID of the originating caller that we own it gives me this error
res_stir_shaken.c:1200 ast_stir_shaken_sign: Failed to retrieve certificate for caller ID ‘15555555555’
res_pjsip_stir_shaken.c:416 add_identity_header: Failed to sign STIR/SHAKEN payload
I tried putting in the variable of ${CALLERID(num)} like this
caller_id_number= ${CALLERID(num)} with no work.
also tried patterns like
caller_id_number= _NxxNxxxxxx
My extensions.conf looks like this
exten => _1.,1,Set(CALLERID(name)=${CALLERID(name)})
exten => _1.,2,Set(CALLERID(num)=${CALLERID(num)})
exten => _1.,3,Dial(${TRUNK}/${EXTEN:1})
exten => _1.,4,Dial(PJSIP/${EXTEN}@ trunk_outbound_0,60)
exten => _1.,5,Dial(PJSIP/${EXTEN}@ trunk_outbound_1,60)
exten => _1.,6,Dial(PJSIP/${EXTEN}@ trunk_outbound_2,60)
exten => _1.,7,Congestion
stir_shaken.conf looks like this
[certificate]
; type must be “certificate”
type=certificate
; File path to a certificate. This can be RSA or ECDSA, but eventually only ECDSA will be supported.
path=/etc/asterisk/stir/xxxk.pem
; URL to the public certificate. Must be of type X509 and be derived from the
; certificate located at path.
; This will be put in the identity header when signing.
public_cert_url=xxxxx.com
; The caller ID number to match on
caller_id_number=(this is the problem child)
; Must have an attestation of A, B, or C
attestation=A
Try the branch from Github instead of the latest release, if I recall correctly a fix went in for that particularly though there is still more work to do on STIR/SHAKEN so it may still not work.
So the fix still has bugs?
Looks like they are trying to get it tested,
Any way i could help? I would be great to get this by june 30th the new fcc deadline
Shoot I wish I could do that level work, if I manually put in the outbound caller ID I am dialing it sends the proper identity header out and I verified it with jwt.io so Asterisk is sending the correct info for stir shaken we just need it to kick the identity header off for ALL outbound calls. Do you know of a way to trick asterisk to do that maybe?
gotcha, well I found another error asterisk is using the called caller ID in Both the Dest and the Orig in the cert when it forms the identity header, the Orig should be the From callerID (from our system).
I guess even if you could kick the cert off each time with out a caller ID check it would fail since the header is not being constructed right…
if anyone needs a beta tester to work on this I can do it! I just not sure I could do all the coding.
I posted my findings to the #62, hope it makes sense, doesn’t piss anyone off and I can help.
Hi guys, not sure if I am helping here but been trying to get asterisk to send S/S identity header for a week now.
I found another issue with the stir shaken identity header that is created by asterisk to send out is that the To Caller ID is also the Orig Caller ID in the identity header. I am pretty sure all we need is to put the $callerid(num) from extensions.conf for outbound calls in the origin in the header creation and just send that for all outbound calls and not try to match a cert to a caller ID number since all we are doing is sending out a master cert for the owner of all the numbers in the switch to prove the outbound call is legit and the owner is certified. I hope this makes sense. I can help test any releases if you want I would just need some direction on how to compile it on my lab server.
Hi,
As some of us have deadlines set to the very next days (mid-July 2023 for me), does it make sense to use an external program to compute this Identity header before including it with the usual PJSIP_HEADER, in the outbound INVITE ?
I’m sorry if my question appears to be silly for experienced people, but I would like, in light of this thread content, to better understand what Asterisk CAN positively do today.
My dialplan contains:
exten = s,1,Dial(PJSIP/123456789@mytrunk)
My strir_shaken.conf contains a single alice section:
[alice]
callerid=s
attestation=C
…
When calling 123456789 using the above dialplan, I could issue an outbound Stir/Shaken certified call (with Asterisk 16.28).
In this case, Asterisk seems to match the alice cert thanks to usage of s extension in dialplan.
Is this correct or did I misunderstood what I observed ?
Said differently, shall I both add in extensions.conf and strir_shaken.conf files, lines such as the ones bellow if I want to certify other callerids ?
I can only comment based on integration testing that was done previously, to say that the produced Identity header even with matching a certificate has been shown to not be verifiable by other implementations. There is further work to be done in the STIR/SHAKEN implementation to have it work, aside from the callerid aspect, with other implementations.
DO NOT look at asterisk for stir shaken right now, whoever originally programmed it thought you had to sign the cert on the number you dialed NOT the number you are dialing from AND the shaken header does not contain the from calleID just the dialed number twice.
I can only say that in testing with other implementations the signed part did not validate against the public certificate. Nothing we’ve done has touched that, so it is possible either OpenSSL was broken during testing, or it is something sporadic/off-nominal. I don’t know.
On a side note, what is current Stir/Shaken in the USA ?
I thought it became mandatory during 2021 but it seems there is a new milestone set in june 2023, isn’t it ?
In France, compliance is scheduled for mid-July 2023 but nobody seems to be ready.
I would swear that at least, 70% of mobile phones can’t display any Stir/Shaken-derived data to callee.
For enterprise desk phones, this rate is IMHO above 90% and will remain so for a couple of months.
2021 was big carriers deadline
June 2022 was deadline for small carriers who do not bundle broadband
june 2023 is the deadline for small carriers who bundle broadband