sr-dev

sr-dev@lists.kamailio.org

44307 discussions

[tracker] Comment added: Extending TM timeout/408 handling

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#55 - Extending TM timeout/408 handling User who did this - Iñaki Baz Castillo (ibc) ---------- Another possible solution: 3) Generate local 503 if fr_timer expires. According to RFC 3261 there are two posibilities if the transport layer fails: - Timeout, no response, so 408 is locally generaged. - Transport error so 503 is locally generated. Transport error can occur in both TCP and UDP: - In TCP means that the TCP connection failed. - In UDP means that the UAC received a ICMP indicating "UDP port 5060 unreachable". The transport error for UDP is not handled by TM as it doesn't rely on the received ICMP. Also it seems that such ICMP mechanism is not interoperable between different TCP/IP stacks. Anyhow, I would suggest that when fr_timer expires (in UDP) a locally generated 503 could make sense. Why not? If there is no response at all for a transaction then there is some kind of network issue or perhaps the remote server is down/congested. 503 seems suitable for me, even if RFC 3261 doesn't state it. PS: As far as I know, other SIP stacks uses internal codes (like 7XX) to indicate such kind of errors (transport error, transport timeout...). I think something like that is a real need even if RFC 3261 didn't consider it (as they didn't consider NAT). ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=55#comment64 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Task opened: Extending TM timeout/408 handling

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Iñaki Baz Castillo (ibc) Attached to Project - sip-router Summary - Extending TM timeout/408 handling Task Type - Bug Report Category - tm Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Low Priority - Low Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Hi, let's suppose the following case: SR receives an INVITE and performs serial or parallel forking to gw1 and gw2. Three cases: case a) - gw1 replies 480. - gw2 replies 408. case b) - gw1 replies 480. - gw2 replies 180 and fr_inv_timer expires so a local 408 is generated. case c) - gw1 replies 480. - gw2 replies nothing and fr_timer expires so a local 408 is generated. In any case, after the transaction fails I handle the winning response in failure_route in which I get a 408. But there is no way to determine which of the above 3 cases took place. For cases "a" and "b" the 408 could be a good choice (also the 480) but in case "c" I'd strongly prefer using the 480. But there is no way, in failure_route, to determine if our case is "a", "b" or "c". A non reliable pseudo-workaround is setting a transaction flag(RINGIN_RECEIVED) so when inspecting the 408 in failure_route we can "determine" if fr_timer expired (case "c") or not (cases "a" or "b"). This is not reliable as the flag could be set by other branch in which 1XX was received. Possible solutions: 1) When TM chooses the winning response it must give lowest priority to locally generated 408 if such 408 was raised by fr_timer expiration, so for the above cases the winning response would be: a) 408 b) 408 c) 480 or: 2) When fr_timer expires a new status code is locally generated, i.e. 478 "No response received at all". Such code would have lowest priority. Opinions? More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=55 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Assignee added: Extending TM timeout/408 handling

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#55 - Extending TM timeout/408 handling User who did this - Iñaki Baz Castillo (ibc) http://sip-router.org/tracker/index.php?do=details&task_id=55 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Iñaki Baz Castillo (ibc) ---------- Andrei, IMHO what you suggest it's reasonable and would cover most of the needs. However I still consider special the 408 handling (local-fr_time, local-fr_inv_timer, received) so I will open a new report for it. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment63 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Andrei Pelinescu-Onciul (andrei) ---------- Alex, If you still want this (and something like in the example above is not enough) I could add it (it would be quite easy and it would take less time then all the comments I wrote so far :-)), but I would need a volunteer for the docs (examples a.s.o.). It would be some config option for adjusting the priority of local replies, taking into account that a lower value means a higher priority and the built-in values are: 6xx - 1000+xx, 3xx - 3000+xx , 4xx - 4000 + f4(xx), 5xx - 5000 +xx , where f4(xx) = xx if (401, 415, 420, 484) and 100+xx otherwise (so setting it to 200 would make a local 4xx loose over any received 4xx, but still win over a remote 5xx, while setting it to 2000 will make it loose also over a received 5xx). Some clarification: I'm not the main author of tm, I'm the tm maintainer together with Miklos (in sr/ser/k) and I also wrote/changed a significant part of it (so I could be the main contributor). The original authors (10 years ago) were Bogdan Iancu and Jiri Kuthan (in alphabetical order). Right now in terms of authorship per line in the current tm (sr/ser/k 3.0), the situation looks like: #1 8167 35.73% Andrei Pelinescu-Onciul #2 4886 21.38% Jiri Kuthan #3 3517 15.39% Jan Janak #4 2020 8.84% Miklos Tirpak #5 1493 6.53% Bogdan-Andrei Iancu #6 893 3.91% Bogdan Pintea #7 820 3.59% Daniel-Constantin Mierla #8 385 1.68% Tomas Mandys #9 199 0.87% Vaclav Kubart #10 172 0.75% Raphael Coeffic #11 118 0.52% oej #12 64 0.28% Juha Heinanen #13 36 0.16% Ovidiu Sas #14 32 0.14% Michal Matyska #15 24 0.11% Nils Ohlmeier #16 19 0.08% Maxim Sobolev #17 8 0.04% Andreas Heise (generated using git-blame-stats with -M and -C -C -C which should detect moved and copied lines) Standard disclaimers about not detecting trivial changes, whitespace changes and the relevance of the number of lines do apply :-) ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment62 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Andrei Pelinescu-Onciul (andrei) ---------- Iñaki, First a clarification: there are only 3 local replies that might be selected by sr over some reply received from downstream: 408 (timeout), 503 (a request retransmission failed) and 487 (can win only for and E2E CANCEL and only if cancel_b_method is set to a non-default value). The send error replies are never preferred (e.g. a 477 will be used as a reply only if send on _all_ the branches failed, which means that there is no other reply). The priority for the replies is: 6xx (note that by default they are special case, but even if the rfc 6xx cancel everything behaviour is disabled, they are still preferred), 3xx, 4xx, 5xx. From the 4xx replies the order is 401, 407, 415, 420, 484 and then the other 4xx (in ascending order). Now regarding the 408 & 480 example: yes, 408 will be selected. While it's debatable which is more useful (between one not responding and one temporarily unavailable with a possible Retry-After), I don't think that this is related to the local reply priority problem, but to which reply should win between a 408 and 480 in general (we already prioritize 401, 407, 415, 420 an 484 over any other 4xx, we could extend it to 480 or make the priority of 4xx configurable). Regarding the 503 & 408: this is at best an workaround for a very particular case. Even so, how would the 500 that you will get from ser, help you upstream more then a 408? How could you tell that it's a result of a gw 503 and not an internal ser error? If you need specific workarounds, why don't you do them in the failure route (don't you have to use it anyway to override the 500 you will get normally for a winning 503?) ? E.g.: (override local timeout if 503 received on some branch) if (t_branch_timeout()) { # we are in the failure route due to a timeout if (t_grep_status(503)) { # but we received a 503 on some branch t_reply(599, "a gw returned 503"); } } ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment61 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Alex Hermann (axlh) ---------- Andrei, Iñaki already showed some real-world examples. I had specifically mentioned the "standard compliance" sentence because i know there has been some discussion about some issue like this before. Nothing in the rfc's says that an 'invented' response code should have preference. The given examples amplify this analysis. IMHO a response from the callee is always 'more important' than an automatically generated reply, unless it is specifically generated by the proxy's administrator (this does not include 'artificial' responses created by the proxy software without consent of its administrator). Andrei, even if you don't agree, some users of SR have needs that require other behaviour from SR than what you prefer. As the main author of the tm module, you probably know SR's tm at its best. Would you please consider implementing a possibility to obtain the requested behaviour from SR. Make it configurable if you really feel it goes against the standards. Otherwise, please indicate how i can recognize a faked reply in the t_pick_branch function. The comments in this function already suggest that faked replies don't get accounted for, but real world experience shows otherwise. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment60 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Iñaki Baz Castillo (ibc) ---------- Other example. Unfortunatelly sometimes PSTN gateways reply 503 when there is some network or routing issue in the PSTN leg (I see them all the days). Even worse is the fact that sometimes such 503 comes after some seconds of ringing (180/183). So: - Parallel forking to gw1 and gw2. - gw1 is not reachable and TM generates a timeout (so a local 408). - gw2 rings for some seconds (180) and later replies 503. IMHO the winning reply should be 503 (so 500 finally as per RFC 3261). But I expect that TM would choose 408. The main problem here is the 408 treatment. Even if RFC 3261 states that a fr_timer timeout generates a 408, it's clear that such 408 should be different as is the 408 is locally generated after fr_inv_timeout (with 1XX response received in the branch) or if the 408 has been received from upstream. Definitely I think that a fr_timer timeout should generate some other "internal" code rather than 408 (i.e. 492 or whatever). This means: "server unreachable, no response received at all". And such code should have the lowest priority when choosing the final response, even if other codes are 5XX (if they are 5XX received from upstream). Note that SR already does something similar when a transport layer occurs in TCP. Theorically (as per RFC 3261) TM should generate a 503, but TM generates a local 477. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment59 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Comment added: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#54 - Received replies should get higher preference than locally generated ones User who did this - Iñaki Baz Castillo (ibc) ---------- Let me a question: - Parallel forking to gw1 and gw2. - gw1 is not reachable and TM generates a timeout (so a local 408). - gw2 replies 480. IMHO it's clear that 480 should be chosen. But would it be? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment58 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

[tracker] Task changed: Received replies should get higher preference than locally generated ones

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#54 - Received replies should get higher preference than locally generated ones User who did this: Andrei Pelinescu-Onciul (andrei) Task Type: Bug Report -> Feature Request Severity: Medium -> Low More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

14 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev