STIR/SHAKEN

Yeti-Switch is compatible with STIR/SHAKEN mechanisms and allows you to perform both Identity validation and signing. The Yeti system does not require any external components to perform these operations.

        graph LR
    gw1[Call originator]
    gw2[Termination provider]


    gw1 -->|legA SIP initial INVITE<br>**Identity:.....;x5u=https:\/\/example.com/certs/pub.pem**| validation-logic
    validation-logic --> call-routing
    validation-logic --> call-reject
    call-routing --> signing-logic

    signing-logic -->|legB SIP initial INVITE| gw2

    signing-certificate-repository -->|Fetching private certificate| signing-logic


    public-certificate-repository[Public certificate repository<br>**https:\/\/example.com/certs/pub.pem**]
    public-certificate-cache[Certificate Cache]

    validation-logic -->|Fetching public certificate| public-certificate-cache
    public-certificate-cache -->|Fetching public certificate| public-certificate-repository


    subgraph yeti[Yeti SBC]
        validation-logic[Signature Validation]
        public-certificate-cache
        signing-certificate-repository
        signing-logic[Signing]
        call-routing
        call-reject
    end

Signature Validation

Signature validation logic is controlled by Customers Auth STIR/SHAKEN settings. Depending on the configuration, Yeti may take different actions if the signature is missing or invalid.

The validation procedure requires a public key certificate to perform the cryptographic signature check. This certificate is retrieved from a public repository according to the X5U parameter of the incoming Identity header.

During signature validation, Yeti performs the following steps:

  • Check if the public certificate repository URL from the X5U parameter is allowed by Trusted repository configuration

  • Retrieve the public certificate from the repository URL or from the internal cache

  • Verify that the public certificate is valid and not expired

  • Ensure that the certificate chain is linked to a trusted root certificate defined in Trusted certificates configuration

  • Validate the JWT signature

  • Check the iat (issued-at) timestamp for expiration

  • Confirm that the orig.tn and dest.tn attributes in the Identity header match the Source and Destination numbers present in SIP signaling

The results of signature validation are stored in the CDR fields: Lega Ss Status and Lega Identity.

Signing

When sending a call to the termination gateway, Yeti can either:

  • pass the original Identity header as-is,

  • remove it,

  • generate and attach its own signature.

This behavior is controlled by Termination gateway STIR/SHAKEN settings.

To perform signing, a private certificate and key material are required. These are defined in Signing Certificates configuration.

Yeti supports multiple signing certificates, and you can choose which certificate will be used for signing in Termination gateway STIR/SHAKEN settings. Additionally, it is possible to override the certificate in Customers Auth STIR/SHAKEN settings, allowing different certificates to be used for different call originators (customers).