Re: [sr-dev] [kamailio/kamailio] tm remap_503_500 breaks dialogs (#2405)

The SIP code 503 is tricky in the sense that i can indicate either server maintenance or server overload. In both cases it can send Retry-After header and any subsequent requests from same source are ignored for the duration of Retry-After interval. [1]. Additionally RFC3261 and RFC3263 define that transport failures (generally due to fatal ICMP errors in UDP and connection failures in TCP) should be treated as 503 response. [2]. So in all above cases, it is most likely that dialog does not establishes at all and 503 response is treated similar to stateless response. Therefore, a to-tag can be added/replaced before sending it to UAC. Theoretically, kamailio should check and use to-tag from 503 response when converting it to 500 response and only create new to-tag if it is absent. References: [1] https://tools.ietf.org/html/rfc3261#section-21.5.4 [2] https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4