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(a)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
*From:* sr-users <sr-users-bounces(a)lists.kamailio.org> *On Behalf Of *Gerry
| Rigatta
*Sent:* Wednesday, July 22, 2020 8:58 PM
*To:* Kamailio (SER) - Users Mailing List <sr-users(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users