SIP trunk can't hang up call

I’m having an odd problem. I’ve previously had one way audio trouble with calls through my remote SIP trunk due to a crud router which wasn’t properly capable of port forwarding.

I am now behind a pfsense firewall instead which is much better, and following the guide on their own website I have SIP calls to the phone network working nicely with two way audio.

However I have now noticed there is another problem, and that is that I cannot hang up. This only seems to happen if the other party does not answer the call. The asterisk console shows the following:

Executing [phone number removed@internal:1] Set("SIP/201-09785468", "CALLERID(num)=sip ID removed") in new stack
Executing [phone number removed@internal:2] Dial("SIP/201-09785468", "SIP/phone number removed@sipgate|25|trg") in new stack
Called phone number removed@sipgate
SIP/sipgate-0978f250 is making progress passing it to SIP/201-09785468
Spawn extension (internal, phone number removed, 2) exited non-zero on 'SIP/201-09785468'
[Jun  2 22:21:49] WARNING[7282]: chan_sip.c:12984 handle_response: Remote host can't match request CANCEL to call ''. Giving up.

The SIP trunk I am using is sipgate basic. I have no idea what the great big long string of characters before the final is all about.

Is this a network configuration issue, an asterisk configuration issue, or a sipgate issue?

Likely to be sipgate or the network. It would help to have the contents of the INVITE, the most recent interim response, and the CANCEL, particularly the Call-ID and the tags on the To and From lines.

The Request-URI, Call-ID, To, the numeric part of CSeq, and From header
fields in the CANCEL request MUST be identical to those in the request being cancelled,

Why is the call ID getting mashed up in the cancel request then? It shows the correct phone number in all other parts .

In order to diagnose this issue a full sip trace is needed on both side Asterisk and your carrier

The number in the CANCEL is not the phone number, it is the Call-ID, which is why you need to provide the information from the trace.

(Ideally you want a trace from the far side of the router, as the router may be changing these details.