Indeed, at this stage there is no dialog established and there can be many To-tags in 1xx provisional responses (eg, a parallel forking scenario) -- the to-tag of the dialog has to be taken from 200ok.
This parameter is probably to have a shortcut of doing:
failure_route[REMAP503] {
if(t_check_status("503")) {
t_reply("500", "Server error"); exit;
}
Being like the server application is generating the 500 (so using own tag), instead of forwarding the 503. Not a bug, but if anyone is willing to add an option to allow re-using the to-tag from received reply, I am fine with it.
Anyhow, even if this would be fixed, I am wondering how yate is going to work in parallel/serial forking scenarios where different to-tags flow for a while and the final failure response can have any to-tag, including a new one (e.g., from a device not sending any 1xx or again from kamailio (e.g., when last target doesn't reply at all)).
Cheers, Daniel
On 23.07.20 06:08, M S wrote:
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
Hope this helps.
On Wed, 22 Jul 2020 at 21:08, Henning Westerholt <hw@skalatan.de mailto:hw@skalatan.de> wrote:
Hello, Apparently, this is the way the code works: t_reply.c: if (relayed_code==503 && tm_remap_503_500){ /* replace a final 503 with a 500: * generate a "FAKE" reply and a new to_tag (for easier * debugging)*/ Lets see if maybe others can comment as well. Otherwise you could just open an issue on our tracker, it is probably not that hard to change this. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com <https://gilawa.com/> *From:* sr-users <sr-users-bounces@lists.kamailio.org <mailto:sr-users-bounces@lists.kamailio.org>> *On Behalf Of *Gerry | Rigatta *Sent:* Wednesday, July 22, 2020 8:58 PM *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org>> *Subject:* [SR-Users] bug ? remap_503_500 breaks dialogs Hi, I am using Kamailio 5.2. Apparently the remapping of 503 to 500 codes in the tm module does also change the to-tag. This behaviour breaks dialogs with yate and therefore calls hang and the 503 remains unacknowledged. After disabling the 503 to 500 remapping with modparam("tm", "remap_503_500", 0) all works fine again. Changing the to-tag in a dialog seems to contradict RFC3261, or do I see this wrongly? 12<https://tools.ietf.org/html/rfc3261#section-12>Dialogs A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag…" Thanks for looking into this. Gerry _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users