sr-dev

sr-dev@lists.kamailio.org

4 participants
45462 discussions

[tracker] Comment added: Received replies should get higher preference than locally generated ones
by sip-router 27 Mar '10

27 Mar '10

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.

1 0

[tracker] Comment added: Received replies should get higher preference than locally generated ones
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

[tracker] Comment added: Received replies should get higher preference than locally generated ones
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

[tracker] Comment added: Received replies should get higher preference than locally generated ones
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

[tracker] Task changed: Received replies should get higher preference than locally generated ones
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

[tracker] Comment added: Received replies should get higher preference than locally generated ones
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

[tracker] Task closed: inconsitent config.mak for different targets
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

[tracker] Comment added: inconsitent config.mak for different targets
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

[tracker] Task opened: Received replies should get higher preference than locally generated ones
by sip-router 26 Mar '10

26 Mar '10

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Alex Hermann (axlh) Attached to Project - sip-router Summary - Received replies should get higher preference than locally generated ones Task Type - Bug Report Category - tm Status - Assigned Assigned To - Andrei Pelinescu-Onciul Operating System - All Severity - Medium Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - In the current version, the reply with the highest priority (lowest response code) gets forwarded. At least in a situation with DNS based failover this can be unwanted. When I have 2 hosts in a failover situation and the first is offline, a local 408 is generated. If the 2nd host responds with a higher response-code, the 408 gets forwarded. If the 2nd branch responds, it would be more logical to forward it, as it has information on the callee. If the callee responds 603, the upstream proxy or caller may want to do failover based on that code. If it always received 408, this is impossible. Suggested fix: forward the highest priority _received_ response. optionally, make this behaviour configurable. Standards complicance: the rfc's talk about _forwarding_ the highest priority response. This implies it should have been _received_ by the proxy. A proxy should only 'invent' replies if there are no other options left. 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.

1 0

[tracker] Assignee added: Received replies should get higher preference than locally generated ones
by sip-router 26 Mar '10

26 Mar '10

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.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev