When sending a BYE in an inbound call in a TLS trunk, PJSIP throws the following error:
ERROR[6320]: res_pjsip/pjsip_transport_events.c:160 verify_log_result: Transport 'x.x.x.x-tls' to remote '1.2.3.4' - The server identity does not match to any identities specified in the certificate
See attached screenshot of a SIP ladder presenting the problem. The BYE from FreePBX is marked, and this does not seem to arrive to the far end, which is why they send their own BYE after a while (to which FreePBX responds with a 481). My assumption is that this issue is actually identified in PJRPOJECT (but nobody is working on it), and it revolves around PJSIP not using FQDNs for the BYE message in an UAS scenario, but IP addresses instead, which indeed would be a problem.
For UAC scenarios, this problem is not happening.
The expected correct behavior would be the BYE from FreePBX actually getting sent out both as UAS or UAC, and the error message would not be displayed.
BYE, like any request, is always sent by a UAC. Do you really mean by the callee in the original call?
I think the key problem here is that the original TLS connection has been lost, for some reason, so a new connection has had to be set up in the reverse direction. Is the address in the ACK the same as the BYE; that would confirm that it is able to reuse the connection.
Also, are you sure that the caller isn’t sending an IP address in the Contact header on the original request, as that is what should be used for the BYE.
I’d imagine disabling TLS server verification would avoid the problem.
Thanks, what I meant as UAS is that the dialog is inbound to FreePBX.
It is merely a hypothesis at this stage, but symptoms seem to agree with this PJPROJECT issue linked above. If this is true, then the BYE is not even sent from PJSIP/Asterisk/FreePBX due to the bug (and why the HEP protocol sends a non-existant BYE to Heplify is another question, might be due to timing between res_hep vs res_pjsip_xxxx). At any rate, the far end confirms this BYE never arrives to them, therefore there is no ACK for it (see the screenshot of the SIP flow above).
The Contact header in the original inbound INVITE contains FQDN, not IPs. And a proper port (6002).
Yeah, that’s not the issue here. If the PBX is sending a BYE to Telnyx then Telnyx shouldn’t be sending a BYE back to the PBX. Telnyx should be sending a 200 OK reply to the BYE request but instead they are sending their own BYE and when that hits the PBX the PBX no longer believes the transaction exists (probably due to sending a BYE already to end it).
So that is the problem, the OP is sending a BYE to Telnyx but Telnyx sent back a new BYE request instead of replying to the BYE request.
@BlazeStudios@david55 Thanks, but isn’t the problem TLS related instead? The BYE marked in the screenshot from my FreePBX is actually, physically not getting sent (but certainly does not arrive). Because (so goes my hypothesis) PJSIP under Asterisk is faltering due to the bug linked above. Not sure how does HEP pick up the non-sent BYE message, I guess the order of when it fails in PJSIP and when the HEP resource is picking it up is not ideal, but I’ve had the far end system owners checked, and it is actually not getting sent there.
The workaround for now is that I had to disable the TLS Server Verification in FreePBX as @david55 suggested, and this completely fixes this. Not really a long term solution though, but now that BYE is getting sent, and received fine.
