Well, there are some requirements in the RFC 3261 about it (see below). But they are only SHOULD requirement.
It is probably difficult to solve it in a portable and general way, e.g. - [1](https://josephmuia.ca/2018-04-25-connected-udp-sockets-and-icmp-errors/) - [2](https://github.com/gnuradio/gnuradio/issues/1769) - [3](http://web.deu.edu.tr/doc/soket/) - part 5.4
I have nothing against to tracking this as a feature request, but only in case if somebody wants to start working on it.
```
8.1 UAC behaviour 8.1.3.1 Transaction Layer Errors
In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. [..] If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code.
18. Transports
18.2.2 Sending Responses [..] o Otherwise (for unreliable unicast transports), if the top Via has a "received" parameter, the response MUST be sent to the address in the "received" parameter, [..] If this fails, for example, elicits an ICMP "port unreachable" response, the procedures of Section 5 of [4] SHOULD be used to determine where to send the response.
18.4 Error Handling
Error handling is independent of whether the message was a request or response.
If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, or parameter problem errors SHOULD cause the transport layer to inform the transport user of a failure in sending. Source quench and TTL exceeded ICMP errors SHOULD be ignored.
If the transport user asks for a request to be sent over a reliable transport, and the result is a connection failure, the transport layer SHOULD inform the transport user of a failure in sending. ```