As I already said.
Here is the packet capture
and here is the log.
xx:47 the call connects
xx:48:05 the internal extension hangs up
xx:48:32 the external phone hangs up
It looks like Asterisk is trying to set up a new TLS session to the caller, to send the BYE, and rejecting the encryption they are offering. What I take to be the original TLS session is still up.
Next thing to check is whether Contact header in the original INVITE contains something that would trigger this.
|4603|2024-04-05 19:48:05.457661|24.10.90.240|45.32.129.200|SIP|529|Request: BYE sip:[email protected]:5060 | |
|---|---|---|---|---|---|---|
|4604|2024-04-05 19:48:05.458499|45.32.129.200|24.10.90.240|SIP|445|Status: 200 OK (BYE) | |
|4616|2024-04-05 19:48:05.660110|45.32.129.200|192.76.120.10|TCP|74|46084 → 5061 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM TSval=814077 TSecr=0 WS=128|
|4625|2024-04-05 19:48:05.744722|192.76.120.10|45.32.129.200|TCP|74|5061 → 46084 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1436 SACK_PERM TSval=1821496421 TSecr=814077 WS=128|
|4626|2024-04-05 19:48:05.744774|45.32.129.200|192.76.120.10|TCP|66|46084 → 5061 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=814161 TSecr=1821496421|
|4629|2024-04-05 19:48:05.755443|45.32.129.200|192.76.120.10|TLSv1.2|313|Client Hello|
|4635|2024-04-05 19:48:05.840131|192.76.120.10|45.32.129.200|TCP|66|5061 → 46084 [ACK] Seq=1 Ack=248 Win=65024 Len=0 TSval=1821496516 TSecr=814172|
|4636|2024-04-05 19:48:05.842777|192.76.120.10|45.32.129.200|TLSv1.2|2914|Server Hello|
|4637|2024-04-05 19:48:05.842828|45.32.129.200|192.76.120.10|TCP|66|46084 → 5061 [ACK] Seq=248 Ack=2849 Win=34944 Len=0 TSval=814259 TSecr=1821496519|
|4638|2024-04-05 19:48:05.842840|192.76.120.10|45.32.129.200|TLSv1.2|837|Certificate, Server Key Exchange, Server Hello Done|
|4639|2024-04-05 19:48:05.842845|45.32.129.200|192.76.120.10|TCP|66|46084 → 5061 [ACK] Seq=248 Ack=3620 Win=37760 Len=0 TSval=814259 TSecr=1821496519|
|4640|2024-04-05 19:48:05.844137|45.32.129.200|192.76.120.10|TLSv1.2|192|Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message|
|4646|2024-04-05 19:48:05.928456|192.76.120.10|45.32.129.200|TCP|66|5061 → 46084 [ACK] Seq=3620 Ack=374 Win=65024 Len=0 TSval=1821496605 TSecr=814261|
|4647|2024-04-05 19:48:05.929421|192.76.120.10|45.32.129.200|TLSv1.2|308|New Session Ticket, Change Cipher Spec, Encrypted Handshake Message|
|4648|2024-04-05 19:48:05.929868|45.32.129.200|192.76.120.10|TLSv1.2|97|Encrypted Alert|
|4649|2024-04-05 19:48:05.929901|45.32.129.200|192.76.120.10|TCP|66|46084 → 5061 [FIN, ACK] Seq=405 Ack=3862 Win=40704 Len=0 TSval=814346 TSecr=1821496606|
|4654|2024-04-05 19:48:06.014480|192.76.120.10|45.32.129.200|TCP|66|5061 → 46084 [ACK] Seq=3862 Ack=405 Win=65024 Len=0 TSval=1821496691 TSecr=814346|
|4655|2024-04-05 19:48:06.014630|192.76.120.10|45.32.129.200|TCP|66|5061 → 46084 [FIN, ACK] Seq=3862 Ack=406 Win=65024 Len=0 TSval=1821496691 TSecr=814346|
|4656|2024-04-05 19:48:06.014652|45.32.129.200|192.76.120.10|TCP|66|46084 → 5061 [ACK] Seq=406 Ack=3863 Win=40704 Len=0 TSval=814431 TSecr=1821496691|
Filter was: tcp.port==5061 or udp.port==5060
Adding FIN to the filter confirms that the TLS session, to 5061, open at the start wasn’t closed within the capture.
tcp.port==5061 and tcp.flags.fin == 1 or udp.port==5060
There isn’t actually a contact header, but there is a record-route. I’m not sure how record-route is supposed to be handled for TCP, but the port number on the record-route is 5061.
It is definitely trying to use the new outgoing TLS session, and I can’t find anything wrong about that in RFC 3261.
I think you need to work out why the TLS session to 192.76.120.10:5061 is being aborted by Asterisk. I suspect there may be incompatible settings. Unfortunately the alert, that probably explains it, is encrypted (line 4648) and nothing has been logged on the Asterisk side, at least not at your current logging level. It will be coming form OpenSSL and OpenSSL failures don’t seem to be logged well.
5061 is standard TLS port
What test should I run next?
Where do I go from here?
The point about 5061 is that it wasn’t the remote end of the incoming TLS session, so it does seem to be asking to start a new connection. That new connection has failed, for a security related reason.
I dont know what to think about asterisk ignoring the existing connection and trying to start a new connection just for the purpose of saying “BYE”.
Both Telnyx and Asterisk are configured to use 5061
I think that is correct behaviour. I think I was confused by WebRTC which has to reuse the connection both ways.
That’s only for the destination. Telnyx’s source was 46531. However I think that is academic, as I don’t think reusing is possible.
Are you validating certificate subject names, because you only know Telnyx’s proxy by its IP address, so would presumably validate against that, but it’s certificate says:
RelativeDistinguishedName item (id-at-commonName=sip.telnyx.com)
i.e. it is claiming to be sip.telnyx.com, not 192.76.120.10. The IP address is not given as an alternative.
I don’t know what FreePBX’s default behaviour is, with regard to this.
I think we are getting in the weeds here.
FreePBX does not initiate a proper BYE sequence with TLS trunks when FreePBX hangs up first.
Should I try to submit a bug to someone?
one weed yet to check, have you sent the invite to sip.telnyx.com ?
I don’t quite understand your question.
Can you direct me for how to check regarding what you are asking?
how is your TLS ‘trunk’ configured when attempting calls to and from Telnyx?
Its authenticated by both FQDN and Username / Password
Will you show us all the explicits ?
Sorry, can’t input any more, it JWFM
It does initiate a proper BYE sequence. The problem is that the TLS connection it needs to make to achieve that is being aborted.
The INVITE in question (at least in the logs provided) is incoming, and the failure is happening on an established dialogue, so no SIP level authentication is required, and, in any case, the TLS session is aborted just as it is established, before any user data has been sent.
The TLS session may be being authenticated, but it is being set up to an outbound proxy of Telnyx. That actually is sip.telnyx.com, but the record-route gives its IP address, not its domain name, so I don’t think the TLS session layer would know that certificate is valid for it. I’m not, however, certain that the session is being abandoned at the point where the certificate would be checked.
I’d look for an option something like Verify Server, and make sure it off (not best practice, but might be needed here).
However, I believe Telnyx should be sending a domain name in their Record-Route header, or including the IP address on the certificate.
If Verify Server is already off, it would presumably be cipher settings that are causing the problem. In that case, loging levels need to be turned up to try and see the actual OpenSSL failure reason.
I’ve found 4 or 5 other threads both here and other places that never resolve this. I think this thread has gone further in its troubleshooting than any others.
What is the next step? Report the bug to someone at Sangoma?
Disable Server Verify if set. If set and that fixes it, report the bug to Telnyx.
1 Like