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