In Signal's design, participants have a long term identity key, and the thing you're verifying is essentially just the combination of your long term identity key with the other party's long term identity key, but deterministically ordered so that you both see the exact same value. They call this the "Safety Number". So e.g. maybe your identity can be summarised as A4 and Jim's identity is C6, Signal will show you the value A4C6 as the "Safety Number" for Jim, while Jim also sees A4C6 as the "Safety Number" for lucgommans.
This value is calculated by your client (and Jim's client). The server could present you a new long term identity key for Jim (because Jim's phone dropped dead and he bought a new one, or because the Secret Police want to intercept messages for Jim) but this triggers your client to warn you that the Safety Number changed and you need to decide if this is still Jim.
The Safety Number isn't calculated for each messages, or call, or whatever, because it's made from these long term keys.
The Signal UI reflects the reality that the only way to be sure Jim is seeing the same Safety Number as you is to physically meet up and compare. I think it has pretty nice affordance for that scenario, you can scan a QR code from another Signal user to verify them.
It's tempting to think, but I could just read my Safety Number out, on this call, and then we verify that way. Signal won't prevent you from attempting this, but it actually isn't necessarily safe, so it also doesn't encourage that. Can a Nation State adversary fake up the "verification" step in a voice call? Maybe. Would you notice if they tried? Maybe. Best to sidestep the maybes entirely and if your threat model requires it just actually perform Verification of the Safety Number in person.