[SR-Users] bug ? remap_503_500 breaks dialogs

Daniel-Constantin Mierla miconda at gmail.com
Thu Jul 23 09:51:51 CEST 2020 

Did the initial INVITE received the 200ok, the call is connected and
this is the case of a re-INVITE? In such case the dialog has to be
terminated by a BYE.

If the call is not established, so it is between initial INVITE and no
200ok was received, then the INVITE request did not contain the To-tag.
And what is done by Kamailio is valid as per email responses so far.

Maybe you can just send the ngrep output with all sip requests/replies
for this case and we can see exactly which scenario you talk about.

Cheers,
Daniel

On 23.07.20 09:41, Gerry | Rigatta wrote:
>>
>> 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.
>>
> As far as I read this is not correct. Also a provisional dialog is a
> dialog according to RFC3261. Only in the case that the request did not
> contain a to-tag the provisional messages may insert their own to-tags:
>
> "1xx and 2xx responses may be involved in the establishment of
>          dialogs.  When a request does not contain a To tag, the To tag
>          in the response is used by the UAC to distinguish multiple
>          responses to a dialog creating request.  A proxy MUST NOT
>          insert a tag into the To header field of a 1xx or 2xx response
>          if the request did not contain one.  A proxy MUST NOT modify
>          the tag in the To header field of a 1xx or 2xx response.”
> https://tools.ietf.org/html/rfc3261#page-111
>
> In any case, this bug is not a about provisional messages. The 500
> message terminates the dialog for the UAC (yate) and the UAC needs to
> be able to identify it. An UAC identifies the dialog by the call-id,
> local tag and remote tag.
>
>>>
>>>         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…"
>>>
>
>
>> On 23 Jul 2020, at 10:07, Daniel-Constantin Mierla <miconda at gmail.com
>> <mailto:miconda at gmail.com>> wrote:
>>
>> 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
>> _______________________________________________
>> 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
>
-- 
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/a764ca9a/attachment.htm>

More information about the sr-users mailing list