sr-dev March 2010

sr-dev@lists.kamailio.org

24 participants
359 discussions

[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, 1 month

[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, 1 month

[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, 1 month

[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, 1 month

[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, 1 month

[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, 1 month

[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 disagree. From the 4xx replies the reply which provides the most information is forwarded (using the rfc suggested list: 401, 407, 415, 420, and 484 are higher priority then any other 4xx). If the downstream uses another reply then its reply is not important enough :-) You example with 603 is wrong, a 6xx will _always_ be preferred (so you would always get the 6xx). However I don't see what failover one could do when it receives a 6xx, so I assume you meant 503. Even if this is the case, according to the rfc if the final response is 503 it should be changed into 500 (this is automatically done in tm), so you won't have any failover upstream. What you propose could be done inside the same reply class (e.g. if you get a local 408 and remote 410, prefer the remote 410), but going across classes (e.g. prefer remote 5xx to local 4xx) IMHO doesn't make sense (a local send failure or timeout is much more informative then a remote 5xx). Maybe if you could provide an example when it would help (but note that 6xx are always preferred and 503 is changed into 500)? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=54#comment57 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, 1 month

[tracker] Task closed: inconsitent config.mak for different targets

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#50 - inconsitent config.mak for different targets User who did this - Andrei Pelinescu-Onciul (andrei) Reason for closing: Not a bug Additional comments about closing: Misspelled cfg_target in the make cfg command line. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=50 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, 1 month

[tracker] Comment added: inconsitent config.mak for different targets

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#50 - inconsitent config.mak for different targets User who did this - Andrei Pelinescu-Onciul (andrei) ---------- The problem is that in your centos style example you misspelled cfg_target (you use cfg-target instead of cfg_target). Since cfg_target is not set, a default is built using $(prefix)/$(cfg_dir). ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=50#comment56 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, 1 month

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

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#54 - Received replies should get higher preference than locally generated ones User who did this - Alex Hermann (axlh) 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, 1 month

← Newer
1
2
3
4
5
6
7
8
9
...
36
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2010