Adding another comment from the mailing list:

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

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.