Hello,
I've updated the "New in version 5.4.0" document in our wiki. It is again an impressive list!
* In this development period (started October 2019) almost 1500 commits have been added to the repository * 5 new modules have been added (pv_headers, kafka, secsipid, systemdops, dlgs) * Over 70 modules have been extended, many of them substantially (dispatcher, pv, tls, presence etc..) * Countless bugfixes and documentation extensions/fixes have been added as well * Many refactorings, extensions and architectural improvements were done in Kamailio core, tooling and modules
You'll find the full details at the usual place: https://www.kamailio.org/wiki/features/new-in-5.4.x
Many thanks to everybody that contributed to the Kamailio project.
Cheers,
Henning
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.comhttps://gilawa.com/
Hello,
thanks for taking time to do it, really appreciated!
Cheers, Daniel
On 09.07.20 14:01, Henning Westerholt wrote:
Hello,
I’ve updated the “New in version 5.4.0” document in our wiki. It is again an impressive list!
- In this development period (started October 2019) almost 1500 commits have been added to the repository
- 5 new modules have been added (pv_headers, kafka, secsipid, systemdops, dlgs)
- Over 70 modules have been extended, many of them substantially (dispatcher, pv, tls, presence etc..)
- Countless bugfixes and documentation extensions/fixes have been added as well
- Many refactorings, extensions and architectural improvements were done in Kamailio core, tooling and modules
You’ll find the full details at the usual place: https://www.kamailio.org/wiki/features/new-in-5.4.x
Many thanks to everybody that contributed to the Kamailio project.
Cheers,
Henning
--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com https://gilawa.com/
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Henning Westerholt writes:
- 5 new modules have been added (pv_headers, kafka, secsipid,
- systemdops, dlgs)
Could not find many of these on page:
https://kamailio.org/docs/modules/devel/
-- Juha
Hi Juha,
yes, this overview pages are not autogenerated. I will add the missing there this evening as well.
Cheers,
Henning
Hello,
we discussed couple of time to put such files on a git repo, to make it easier for others to update them ... maybe I get time for them this summer.
Cheers, Daniel
On 14.07.20 12:49, Henning Westerholt wrote:
Hi Juha,
yes, this overview pages are not autogenerated. I will add the missing there this evening as well.
Cheers,
Henning
-- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com
-----Original Message----- From: sr-dev sr-dev-bounces@lists.kamailio.org On Behalf Of Juha Heinanen Sent: Tuesday, July 14, 2020 12:37 PM To: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Cc: Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org Subject: [sr-dev] [SR-Users] new in upcoming Kamailio 5.4.0
Henning Westerholt writes:
- 5 new modules have been added (pv_headers, kafka, secsipid,
- systemdops, dlgs)
Could not find many of these on page:
https://kamailio.org/docs/modules/devel/
-- Juha
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Kamailio (SER) - Development Mailing List sr-dev@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
done - I've also added the appropriate scripts for the html auto-generation for this branch.
Cheers,
Henning
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
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.comhttps://gilawa.com/
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? 12https://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
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@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 newto_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@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 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@skalatan.de mailto: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 -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com <https://gilawa.com/> *From:* sr-users <sr-users-bounces@lists.kamailio.org <mailto: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 <mailto: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<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@lists.kamailio.org <mailto: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
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@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 https://tools.ietf.org/html/rfc3261#section-21.5.4
[2] https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4 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@skalatan.de mailto: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
--
Henning Westerholt – https://skalatan.de/blog/ https://skalatan.de/blog/ Kamailio services – https://gilawa.com https://gilawa.com/
From: sr-users <sr-users-bounces@lists.kamailio.org mailto: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 mailto: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 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@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@gmail.com mailto:miconda@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@skalatan.de mailto: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 -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com <https://gilawa.com/> *From:* sr-users <sr-users-bounces@lists.kamailio.org <mailto: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 <mailto: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<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@lists.kamailio.org <mailto: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 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Hi Daniel,
thanks for looking into this.
The initial INVITE does not have a to-tag but there is an intermediate session progress with a to-tag. See grep below.
The RFC does not distinguish between established or provisional dialogs when it comes to the handling of the to-tags. If there is a to-tag it must not be changed by the Proxy. Clearly that must be so because the to-tag is used by the UAC to identify the call.
Best Gerry
IP addresses are changed in below dialog for security reasons
U 7.7.23.109:5060 -> 11.22.17.24:5060 #5 INVITE sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 19. .P-Asserted-Identity: tel:+4867777777..Via: SIP/2.0/UDP 7.7.23.109:5060 ;rport;branch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7 8.47.203.109>;tag=540342132..To: <sip:111100791456321475@13.23.9.94:5060
..Call-ID: 1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: nulltech.
.Contact: sip:004867777777@7.7.23.109:5060..Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported: 100rel..Content-T ype: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 1595505 273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23.109..t=0 0..m=audi o 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpm ap:101 telephone-event/8000.. # U 11.22.17.24:5060 -> 7.7.23.109:5060 #6 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 78.47. 203.109:5060;rport=5061;branch=z9hG4bK1682611991;received=7.7.23.109..Fr om: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <s ip:111100791456321475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.10 9..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/linux))..Content-Length: 0.... # U 11.22.17.24:5060 -> 13.23.9.94:5060 #7 INVITE sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Record-Route: <si p:11.22.17.24:5060;lr=on>..Max-Forwards: 18..P-Asserted-Identity: tel:+ 4867777777..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37 b7feb047b6707c5fb8a298d36fc.0..Via: SIP/2.0/UDP 7.7.23.109:5060;received =7.7.23.109;rport=5061;branch=z9hG4bK1682611991..From: "004867777777" < sip:004867777777@7.7.23.109>;tag=540342132..To: <sip:111100791456321475 @13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109..CSeq: 1 INVITE..Us er-Agent: nulltech..Contact: sip:004867777777@7.7.23.109:5060..Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported : 100rel..Content-Type: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 1595505273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23 .109..t=0 0..m=audio 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap: 0 PCMU/8000..a=rtpmap:101 telephone-event/8000.. # U 13.23.9.94:5060 -> 11.22.17.24:5060 #8 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d 4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Via: SIP/2.0 /UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=z9hG4bK168 2611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "00371673360 58" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563 21475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109..CSeq: 1 INVIT E..User-Agent: Ravetel SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: <sip:1111007 91456321475@13.23.9.94:5060>..Content-Length: 0.... # U 13.23.9.94:5060 -> 11.22.17.24:5060 #9 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 11.22.17.24:5060;branch= z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Vi a: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch= z9hG4bK1682611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "0 04867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:103 000791456321475@13.23.9.94:5060>;tag=as6d86b4e8..Call-ID: 1279305029@78. 47.203.109..CSeq: 1 INVITE..User-Agent: Ravetel SIP proxy..Allow: INVITE, A CK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replac es..Contact: sip:111100791456321475@13.23.9.94:5060..Content-Type: app lication/sdp..Content-Length: 235....v=0..o=root 714 714 IN IP4 136.243.29. 94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101 ..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/ 8000..a=fmtp:101 0-16..a=ptime:20..a=sendrecv.. # U 11.22.17.24:5060 -> 7.7.23.109:5060 #10 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 7.7.23.109:5060;received= 7.7.23.109;rport=5061;branch=z9hG4bK1682611991..Record-Route: <sip:116.2 02.187.204:5060;lr=on>..From: "004867777777" <sip:004867777777@7.7.23. 109>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6 d86b4e8..Call-ID: 1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: <sip:111100791456321475@136.24 3.29.94:5060>..Content-Type: application/sdp..Content-Length: 235....v=0..o =root 714 714 IN IP4 13.23.9.94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/800 0..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=ptime:20..a=sendre cv.. #
U 13.23.9.94:5060 -> 11.22.17.24:5060 #39 SIP/2.0 503 Service Unavailable..Via: SIP/2.0/UDP 11.22.17.24:5060;bran ch=z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24. .Via: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;bran ch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7.7.23.10 9>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d8 6b4e8..Call-ID: 1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, N OTIFY, INFO..Supported: replaces..X-Asterisk-HangupCause: Call Rejected..X- Asterisk-HangupCauseCode: 21..Content-Length: 0.... # U 11.22.17.24:5060 -> 13.23.9.94:5060 #40 ACK sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 18..Vi a: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37b7feb047b6707c5 fb8a298d36fc.0..From: "004867777777" sip:004867777777@7.7.23.109;tag =540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d86b4e8. .Call-ID: 1279305029@7.7.23.109..CSeq: 1 ACK..Content-Length: 0.... # U 11.22.17.24:5060 -> 7.7.23.109:5060 #41 SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214 75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: 1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l inux))..Content-Length: 0.... # U 11.22.17.24:5060 -> 7.7.23.109:5060 #42 SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214 75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: 1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l inux))..Content-Length: 0.... #
On 23 Jul 2020, at 10:51, Daniel-Constantin Mierla miconda@gmail.com wrote:
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 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@gmail.com mailto:miconda@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 https://tools.ietf.org/html/rfc3261#section-21.5.4
[2] https://tools.ietf.org/html/draft-hilt-sip-correction-503-01#section-4 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@skalatan.de mailto: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
--
Henning Westerholt – https://skalatan.de/blog/ https://skalatan.de/blog/ Kamailio services – https://gilawa.com https://gilawa.com/
From: sr-users <sr-users-bounces@lists.kamailio.org mailto: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 mailto: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 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@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.com http://www.asipto.com/ www.twitter.com/miconda http://www.twitter.com/miconda -- www.linkedin.com/in/miconda http://www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla https://www.paypal.me/dcmierla
Hello,
just to add to the RFC quoted below: this is referring to 1xx or 2xx responses. But later on, in the section, the RFC seems to be quite clear:
If the only response that was received is a 503, the proxy SHOULD generate a 500 response and forward that upstream.
A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag.
Cheers,
Henning
From: sr-users sr-users-bounces@lists.kamailio.org On Behalf Of Gerry | Rigatta Sent: Thursday, July 23, 2020 2:41 PM To: miconda@gmail.com Cc: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Subject: Re: [SR-Users] bug ? remap_503_500 breaks dialogs
Hi Daniel,
thanks for looking into this.
The initial INVITE does not have a to-tag but there is an intermediate session progress with a to-tag. See grep below.
The RFC does not distinguish between established or provisional dialogs when it comes to the handling of the to-tags. If there is a to-tag it must not be changed by the Proxy. Clearly that must be so because the to-tag is used by the UAC to identify the call.
Best Gerry
IP addresses are changed in below dialog for security reasons
U 7.7.23.109:5060 -> 11.22.17.24:5060 #5 INVITE sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 19. .P-Asserted-Identity: tel:+4867777777..Via: SIP/2.0/UDP 7.7.23.109:5060 ;rport;branch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7 8.47.203.109>;tag=540342132..To: <sip:111100791456321475@13.23.9.94:5060
..Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: nulltech.
.Contact: sip:004867777777@7.7.23.109:5060..Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported: 100rel..Content-T ype: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 1595505 273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23.109..t=0 0..m=audi o 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpm ap:101 telephone-event/8000.. # U 11.22.17.24:5060 -> 7.7.23.109:5060 #6 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 78.47. 203.109:5060;rport=5061;branch=z9hG4bK1682611991;received=7.7.23.109..Fr om: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <s ip:111100791456321475@13.23.9.94mailto:111100791456321475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.10mailto:1279305029@7.7.23.10 9..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/linux))..Content-Length: 0.... # U 11.22.17.24:5060 -> 13.23.9.94:5060 #7 INVITE sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Record-Route: <si p:11.22.17.24:5060;lr=on>..Max-Forwards: 18..P-Asserted-Identity: tel:+ 4867777777..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37 b7feb047b6707c5fb8a298d36fc.0..Via: SIP/2.0/UDP 7.7.23.109:5060;received =7.7.23.109;rport=5061;branch=z9hG4bK1682611991..From: "004867777777" < sip:004867777777@7.7.23.109>;tag=540342132..To: <sip:111100791456321475 @13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Us er-Agent: nulltech..Contact: sip:004867777777@7.7.23.109:5060..Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported : 100rel..Content-Type: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 1595505273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23 .109..t=0 0..m=audio 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap: 0 PCMU/8000..a=rtpmap:101 telephone-event/8000.. # U 13.23.9.94:5060 -> 11.22.17.24:5060 #8 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d 4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Via: SIP/2.0 /UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=z9hG4bK168 2611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "00371673360 58" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563 21475@13.23.9.94mailto:21475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 INVIT E..User-Agent: Ravetel SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: <sip:1111007 91456321475@13.23.9.94mailto:91456321475@13.23.9.94:5060>..Content-Length: 0.... # U 13.23.9.94:5060 -> 11.22.17.24:5060 #9 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 11.22.17.24:5060;branch= z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Vi a: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch= z9hG4bK1682611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "0 04867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:103 000791456321475@13.23.9.94mailto:000791456321475@13.23.9.94:5060>;tag=as6d86b4e8..Call-ID: 1279305029@78. 47.203.109..CSeq: 1 INVITE..User-Agent: Ravetel SIP proxy..Allow: INVITE, A CK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replac es..Contact: sip:111100791456321475@13.23.9.94:5060..Content-Type: app lication/sdp..Content-Length: 235....v=0..o=root 714 714 IN IP4 136.243.29. 94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101 ..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/ 8000..a=fmtp:101 0-16..a=ptime:20..a=sendrecv.. # U 11.22.17.24:5060 -> 7.7.23.109:5060 #10 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 7.7.23.109:5060;received= 7.7.23.109;rport=5061;branch=z9hG4bK1682611991..Record-Route: <sip:116.2 02.187.204:5060;lr=on>..From: "004867777777" <sip:004867777777@7.7.23. 109>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6 d86b4e8..Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: <sip:111100791456321475@136.24 3.29.94:5060>..Content-Type: application/sdp..Content-Length: 235....v=0..o =root 714 714 IN IP4 13.23.9.94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/800 0..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=ptime:20..a=sendre cv.. #
U 13.23.9.94:5060 -> 11.22.17.24:5060 #39 SIP/2.0 503 Service Unavailable..Via: SIP/2.0/UDP 11.22.17.24:5060;bran ch=z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24. .Via: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;bran ch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7.7.23.10 9>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d8 6b4e8..Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, N OTIFY, INFO..Supported: replaces..X-Asterisk-HangupCause: Call Rejected..X- Asterisk-HangupCauseCode: 21..Content-Length: 0.... # U 11.22.17.24:5060 -> 13.23.9.94:5060 #40 ACK sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 18..Vi a: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37b7feb047b6707c5 fb8a298d36fc.0..From: "004867777777" sip:004867777777@7.7.23.109;tag =540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d86b4e8. .Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 ACK..Content-Length: 0.... # U 11.22.17.24:5060 -> 7.7.23.109:5060 #41 SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214 75@13.23.9.94mailto:75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l inux))..Content-Length: 0.... # U 11.22.17.24:5060 -> 7.7.23.109:5060 #42 SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214 75@13.23.9.94mailto:75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: 1279305029@7.7.23.109mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l inux))..Content-Length: 0.... #
On 23 Jul 2020, at 10:51, Daniel-Constantin Mierla <miconda@gmail.commailto:miconda@gmail.com> wrote:
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.
12https://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@gmail.commailto:miconda@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@skalatan.demailto: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
-- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.comhttps://gilawa.com/
From: sr-users <sr-users-bounces@lists.kamailio.orgmailto: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.orgmailto: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? 12https://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@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com/
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comhttp://www.asipto.com/
www.twitter.com/micondahttp://www.twitter.com/miconda -- www.linkedin.com/in/micondahttp://www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
Hello,
I am not sure what variant you want to advocate with this message/excerpt from RFC, but it is about "forwarded response to a **request that contains a To tag**", and the request (the initial INVITE) has no To tag.
For replies corresponding to requests within dialog, the to-tag has to be preserved and I think kamailio does it even if it has to generate a reply (e.g., timeout on re-INVITE routing).
Cheers, Daniel
On 23.07.20 14:53, Henning Westerholt wrote:
Hello,
just to add to the RFC quoted below: this is referring to 1xx or 2xx responses. But later on, in the section, the RFC seems to be quite clear:
If the only
response that was received is a 503, the proxy SHOULD generate
a 500 response and forward that upstream.
A proxy MUST NOT modify the To tag in any forwarded response to
a request that contains a To tag.
Cheers,
Henning
*From:*sr-users sr-users-bounces@lists.kamailio.org *On Behalf Of *Gerry | Rigatta *Sent:* Thursday, July 23, 2020 2:41 PM *To:* miconda@gmail.com *Cc:* Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org *Subject:* Re: [SR-Users] bug ? remap_503_500 breaks dialogs
Hi Daniel,
thanks for looking into this.
The initial INVITE does not have a to-tag but there is an intermediate session progress with a to-tag. See grep below.
The RFC does not distinguish between established or provisional dialogs when it comes to the handling of the to-tags. If there is a to-tag it must not be changed by the Proxy. Clearly that must be so because the to-tag is used by the UAC to identify the call.
Best Gerry
IP addresses are changed in below dialog for security reasons
U 7.7.23.109:5060 -> 11.22.17.24:5060 #5
INVITE sip:111100791456321475@13.23.9.94:5060 sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 19.
.P-Asserted-Identity: tel:+4867777777..Via: tel:+4867777777..Via: SIP/2.0/UDP 7.7.23.109:5060
;rport;branch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7
8.47.203.109>;tag=540342132..To: <sip:111100791456321475@13.23.9.94:5060
>..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: nulltech.
.Contact: sip:004867777777@7.7.23.109:5060..Allow: ACK, INVITE, BYE,
CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported: 100rel..Content-T
ype: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 1595505
273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23.109..t=0 0..m=audi
o 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpm
ap:101 telephone-event/8000..
#
U 11.22.17.24:5060 -> 7.7.23.109:5060 #6
SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 78.47.
203.109:5060;rport=5061;branch=z9hG4bK1682611991;received=7.7.23.109..Fr
om: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <s
ip:111100791456321475@13.23.9.94 mailto:111100791456321475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.10 mailto:1279305029@7.7.23.10
9..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/linux))..Content-Length:
0....
#
U 11.22.17.24:5060 -> 13.23.9.94:5060 #7
INVITE sip:111100791456321475@13.23.9.94:5060 sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Record-Route: <si
p:11.22.17.24:5060;lr=on>..Max-Forwards: 18..P-Asserted-Identity: tel:+
4867777777..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37
b7feb047b6707c5fb8a298d36fc.0..Via: SIP/2.0/UDP 7.7.23.109:5060;received
=7.7.23.109;rport=5061;branch=z9hG4bK1682611991..From: "004867777777" <
sip:004867777777@7.7.23.109 sip:004867777777@7.7.23.109>;tag=540342132..To: <sip:111100791456321475
@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Us
er-Agent: nulltech..Contact: sip:004867777777@7.7.23.109:5060..Allow:
ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported
: 100rel..Content-Type: application/sdp..Content-Length: 209....v=0..o=yate
1595505273 1595505273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23
.109..t=0 0..m=audio 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:
0 PCMU/8000..a=rtpmap:101 telephone-event/8000..
#
U 13.23.9.94:5060 -> 11.22.17.24:5060 #8
SIP/2.0 100 Trying..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d
4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Via: SIP/2.0
/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=z9hG4bK168
2611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "00371673360
58" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563
21475@13.23.9.94 mailto:21475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVIT
E..User-Agent: Ravetel SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE,
REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: <sip:1111007
91456321475@13.23.9.94 mailto:91456321475@13.23.9.94:5060>..Content-Length: 0....
#
U 13.23.9.94:5060 -> 11.22.17.24:5060 #9
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=
z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Vi
a: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=
z9hG4bK1682611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "0
04867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:103
000791456321475@13.23.9.94 mailto:000791456321475@13.23.9.94:5060>;tag=as6d86b4e8..Call-ID: 1279305029@78.
47.203.109..CSeq: 1 INVITE..User-Agent: Ravetel SIP proxy..Allow: INVITE, A
CK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replac
es..Contact: sip:111100791456321475@13.23.9.94:5060..Content-Type: app
lication/sdp..Content-Length: 235....v=0..o=root 714 714 IN IP4 136.243.29.
94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101
..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/
8000..a=fmtp:101 0-16..a=ptime:20..a=sendrecv..
#
U 11.22.17.24:5060 -> 7.7.23.109:5060 #10
SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 7.7.23.109:5060;received=
7.7.23.109;rport=5061;branch=z9hG4bK1682611991..Record-Route: <sip:116.2
02.187.204:5060;lr=on>..From: "004867777777" <sip:004867777777@7.7.23.
109>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6
d86b4e8..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet
el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE,
NOTIFY, INFO..Supported: replaces..Contact: <sip:111100791456321475@136.24
3.29.94:5060>..Content-Type: application/sdp..Content-Length: 235....v=0..o
=root 714 714 IN IP4 13.23.9.94..s=session..c=IN IP4 13.23.9.94..t=0
0..m=audio 10454 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/800
0..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=ptime:20..a=sendre
cv..
#
U 13.23.9.94:5060 -> 11.22.17.24:5060 #39
SIP/2.0 503 Service Unavailable..Via: SIP/2.0/UDP 11.22.17.24:5060;bran
ch=z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24.
.Via: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;bran
ch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7.7.23.10
9>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d8
6b4e8..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet
el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, N
OTIFY, INFO..Supported: replaces..X-Asterisk-HangupCause: Call Rejected..X-
Asterisk-HangupCauseCode: 21..Content-Length: 0....
#
U 11.22.17.24:5060 -> 13.23.9.94:5060 #40
ACK sip:111100791456321475@13.23.9.94:5060 sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 18..Vi
a: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37b7feb047b6707c5
fb8a298d36fc.0..From: "004867777777" sip:004867777777@7.7.23.109;tag
=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d86b4e8.
.Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 ACK..Content-Length: 0....
#
U 11.22.17.24:5060 -> 7.7.23.109:5060 #41
SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport=
5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777"
sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214
75@13.23.9.94 mailto:75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID:
1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l
inux))..Content-Length: 0....
#
U 11.22.17.24:5060 -> 7.7.23.109:5060 #42
SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport=
5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777"
sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214
75@13.23.9.94 mailto:75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID:
1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l
inux))..Content-Length: 0....
#
On 23 Jul 2020, at 10:51, Daniel-Constantin Mierla <miconda@gmail.com <mailto:miconda@gmail.com>> wrote: 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@gmail.com <mailto:miconda@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@skalatan.de <mailto: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 -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com <https://gilawa.com/> *From:* sr-users <sr-users-bounces@lists.kamailio.org <mailto: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 <mailto: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 <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@lists.kamailio.org <mailto: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 <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Funding: https://www.paypal.me/dcmierla _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com/> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> Funding: https://www.paypal.me/dcmierla
Hello,
there is no call at that moment, it is a routing-in-progress for the initial INVITE. The proxy can cancel the outgoing branch that returned the 183, send to another target address (e.g., call hunting scenario) which comes back with another 183 and different to-tag, or if the second target does not send any reply, then proxy generates itself a 408 reply -- just to give an example of a possible valid scenario.
So, the To-tag is used to identify requests within an established dialog or to terminate a proxy-created branch in early phase. It is not used to match the reply for initial INVITE transaction -- for that purpose the branch parameter of first via should be used by calling UA.
A call is terminated by a BYE and there to-tag matters indeed. But a transaction is not identified by using to-tag.
Cheers, Daniel
On 23.07.20 14:41, Gerry | Rigatta wrote:
Hi Daniel,
thanks for looking into this.
The initial INVITE does not have a to-tag but there is an intermediate session progress with a to-tag. See grep below.
The RFC does not distinguish between established or provisional dialogs when it comes to the handling of the to-tags. If there is a to-tag it must not be changed by the Proxy. Clearly that must be so because the to-tag is used by the UAC to identify the call.
Best Gerry
IP addresses are changed in below dialog for security reasons
U 7.7.23.109:5060 -> 11.22.17.24:5060 #5 INVITE sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 19. .P-Asserted-Identity: tel:+4867777777..Via: SIP/2.0/UDP 7.7.23.109:5060 ;rport;branch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7 8.47.203.109>;tag=540342132..To: <sip:111100791456321475@13.23.9.94:5060 >..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: nulltech. .Contact: sip:004867777777@7.7.23.109:5060..Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported: 100rel..Content-T ype: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 1595505 273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23.109..t=0 0..m=audi o 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpm ap:101 telephone-event/8000.. # U 11.22.17.24:5060 -> 7.7.23.109:5060 #6 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 78.47. 203.109:5060;rport=5061;branch=z9hG4bK1682611991;received=7.7.23.109..Fr om: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <s ip:111100791456321475@13.23.9.94 mailto:111100791456321475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.10 mailto:1279305029@7.7.23.10 9..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/linux))..Content-Length: 0.... # U 11.22.17.24:5060 -> 13.23.9.94:5060 #7 INVITE sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Record-Route: <si p:11.22.17.24:5060;lr=on>..Max-Forwards: 18..P-Asserted-Identity: tel:+ 4867777777..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37 b7feb047b6707c5fb8a298d36fc.0..Via: SIP/2.0/UDP 7.7.23.109:5060;received =7.7.23.109;rport=5061;branch=z9hG4bK1682611991..From: "004867777777" < sip:004867777777@7.7.23.109>;tag=540342132..To: <sip:111100791456321475 @13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Us er-Agent: nulltech..Contact: sip:004867777777@7.7.23.109:5060..Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, PRACK, INFO..Supported : 100rel..Content-Type: application/sdp..Content-Length: 209....v=0..o=yate 1595505273 1595505273 IN IP4 7.7.23.109..s=SIP Call..c=IN IP4 7.7.23 .109..t=0 0..m=audio 28610 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap: 0 PCMU/8000..a=rtpmap:101 telephone-event/8000.. # U 13.23.9.94:5060 -> 11.22.17.24:5060 #8 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d 4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Via: SIP/2.0 /UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch=z9hG4bK168 2611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "00371673360 58" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563 21475@13.23.9.94 mailto:21475@13.23.9.94:5060>..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVIT E..User-Agent: Ravetel SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: <sip:1111007 91456321475@13.23.9.94 mailto:91456321475@13.23.9.94:5060>..Content-Length: 0.... # U 13.23.9.94:5060 -> 11.22.17.24:5060 #9 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 11.22.17.24:5060;branch= z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24..Vi a: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;branch= z9hG4bK1682611991..Record-Route: sip:11.22.17.24:5060;lr=on..From: "0 04867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:103 000791456321475@13.23.9.94 mailto:000791456321475@13.23.9.94:5060>;tag=as6d86b4e8..Call-ID: 1279305029@78. 47.203.109..CSeq: 1 INVITE..User-Agent: Ravetel SIP proxy..Allow: INVITE, A CK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replac es..Contact: sip:111100791456321475@13.23.9.94:5060..Content-Type: app lication/sdp..Content-Length: 235....v=0..o=root 714 714 IN IP4 136.243.29. 94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101 ..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:101 telephone-event/ 8000..a=fmtp:101 0-16..a=ptime:20..a=sendrecv.. # U 11.22.17.24:5060 -> 7.7.23.109:5060 #10 SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 7.7.23.109:5060;received= 7.7.23.109;rport=5061;branch=z9hG4bK1682611991..Record-Route: <sip:116.2 02.187.204:5060;lr=on>..From: "004867777777" <sip:004867777777@7.7.23. 109>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6 d86b4e8..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO..Supported: replaces..Contact: <sip:111100791456321475@136.24 3.29.94:5060>..Content-Type: application/sdp..Content-Length: 235....v=0..o =root 714 714 IN IP4 13.23.9.94..s=session..c=IN IP4 13.23.9.94..t=0 0..m=audio 10454 RTP/AVP 8 0 101..a=rtpmap:8 PCMA/8000..a=rtpmap:0 PCMU/800 0..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=ptime:20..a=sendre cv.. # U 13.23.9.94:5060 -> 11.22.17.24:5060 #39 SIP/2.0 503 Service Unavailable..Via: SIP/2.0/UDP 11.22.17.24:5060;bran ch=z9hG4bK58d4.f1e37b7feb047b6707c5fb8a298d36fc.0;received=11.22.17.24. .Via: SIP/2.0/UDP 7.7.23.109:5060;received=7.7.23.109;rport=5061;bran ch=z9hG4bK1682611991..From: "004867777777" <sip:004867777777@7.7.23.10 9>;tag=540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d8 6b4e8..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..User-Agent: Ravet el SIP proxy..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, N OTIFY, INFO..Supported: replaces..X-Asterisk-HangupCause: Call Rejected..X- Asterisk-HangupCauseCode: 21..Content-Length: 0.... # U 11.22.17.24:5060 -> 13.23.9.94:5060 #40 ACK sip:111100791456321475@13.23.9.94:5060 SIP/2.0..Max-Forwards: 18..Vi a: SIP/2.0/UDP 11.22.17.24:5060;branch=z9hG4bK58d4.f1e37b7feb047b6707c5 fb8a298d36fc.0..From: "004867777777" sip:004867777777@7.7.23.109;tag =540342132..To: sip:111100791456321475@13.23.9.94:5060;tag=as6d86b4e8. .Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 ACK..Content-Length: 0.... # U 11.22.17.24:5060 -> 7.7.23.109:5060 #41 SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214 75@13.23.9.94 mailto:75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l inux))..Content-Length: 0.... # U 11.22.17.24:5060 -> 7.7.23.109:5060 #42 SIP/2.0 500 Service Unavailable..Via: SIP/2.0/UDP 7.7.23.109:5060;rport= 5061;branch=z9hG4bK1682611991;received=7.7.23.109..From: "004867777777" sip:004867777777@7.7.23.109;tag=540342132..To: <sip:1111007914563214 75@13.23.9.94 mailto:75@13.23.9.94:5060>;tag=95329101123423eab1637e9ad490b3a6-9d3c..Call-ID: 1279305029@7.7.23.109 mailto:1279305029@7.7.23.109..CSeq: 1 INVITE..Server: kamailio (5.2.3 (x86_64/l inux))..Content-Length: 0.... #
On 23 Jul 2020, at 10:51, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> wrote:
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@gmail.com mailto:miconda@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@skalatan.de mailto: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 -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com <https://gilawa.com/> *From:* sr-users <sr-users-bounces@lists.kamailio.org <mailto: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 <mailto: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<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@lists.kamailio.org <mailto: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 _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org mailto: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
-
Daniel-Constantin Mierla -
Gerry | Rigatta -
Henning Westerholt -
Juha Heinanen -
M S