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
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:
Hope this helps.
On Wed, 22 Jul 2020 at 21:08, Henning Westerholt <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
From: sr-users <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>
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 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
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
-- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla