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.
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.
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.
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.
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.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task is now closed:
FS#53 - wrong TM response code
User who did this - Klaus Darilion (klaus3000)
Reason for closing: Not a bug
Additional comments about closing: stupid bug in my config, Kamailio works fine
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=53
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.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#53 - wrong TM response code
User who did this - Klaus Darilion (klaus3000)
http://sip-router.org/tracker/index.php?do=details&task_id=53
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.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#53 - wrong TM response code
User who did this - Klaus Darilion (klaus3000)
----------
Of course you are right. I had a bug in the config and looped another branch to the proxy again.
Really sorry for bothering you.
thanks
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=53#comment55
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.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#53 - wrong TM response code
User who did this - Andrei Pelinescu-Onciul (andrei)
----------
Yes, it did, but on the lo interface (that's why it's not in the ngrep dump).
First of all you can see that the INVITE forwarded back to 83.136.33.3:5200 it's on the second branch (branch number 1 and not 0):
Via: SIP/2.0/UDP 83.136.32.159;branch=z9hG4bK404.f2951c02.1 (note the .1 at the end)
Then looking at syslog.txt:
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30989]: INFO: <script>: 3df971d27197-l2satt3hm9s8@83-136-33-3 appending branch to gateway ...
.....
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30989]: INFO: <script>: main branch:
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30989]: INFO: <script>: $ru=sip:00123456@labs.nic.at
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30989]: INFO: <script>: $du=<null>
....
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30989]: INFO: <script>: additional branch 0:
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30989]: INFO: <script>: RURI=sip:klaus.darilion@83.136.33.3:5200;line=m3yhutkd
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30989]: INFO: <script>: DURI=sip:83.136.33.3:5200
Basically there are 2 branches and the main/first branch tries to send the invite to sip:00123456@labs.nic.at which will cause it to loop it back to the proxy (that's not probably what you want, either the uri is wrong, the dst uri is not set or you miss a forward gateway rule).
The proxy receives the INVTIE for sip:00123456@labs.nic.at, and the auth. fails (the credentials are probably removed in the script before forwarding, but even if they would not be removed they would be for klaus.darilion and not for 00123456):
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30990]: INFO: <script>: 3df971d27197-l2satt3hm9s8@83-136-33-3 authentication failed, wrong or missing credentials, challenging...
....
Mar 26 13:41:58 plaudertasche /usr/sbin/kamailio[30990]: DEBUG: sl [sl.c:318]: reply in stateless mode (sl)
Then the proxy will reply with 407 for the INV to sip:00123456@labs.nic.at, on the lo interface (that's why it's not in the ngrep dump).
In the end there are 2 responses for the INV transaction: the 407 and the 482 and the proxy chooses the 407.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=53#comment54
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.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has been re-opened:
FS#53 - wrong TM response code
User who did this - Andrei Pelinescu-Onciul (andrei)
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=53
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.