[SR-Users] bug ? remap_503_500 breaks dialogs

[Daniel-Constantin Mierla]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200723/4f1ab236/attachment.htm>