[sr-dev] git:master: siputils: added new function is_first_hop()

2013-06-08 Thread Juha Heinanen
daniel, is_first_hop() readme has this on replies: For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching it (to avoid detecting in case of local loops). Note that it does not detect spirals, which can have the condition for replies

[sr-dev] git:master: siputils: added new function is_first_hop()

2013-06-08 Thread Juha Heinanen
it came to my mind that if sip ua runs on the same host as sip proxy (which is very common in test environments at least) then it seem that is_first_hop does not work for replies. it may not be a good idea to introduce this function for replies if it has such a hole. -- juha

Re: [sr-dev] git:master: siputils: added new function is_first_hop()

2013-06-08 Thread Daniel-Constantin Mierla
Hello, On 6/8/13 8:55 AM, Juha Heinanen wrote: daniel, is_first_hop() readme has this on replies: For incoming SIP replies, it means that top Record-Route URI is 'myself' and source address is not matching it (to avoid detecting in case of local loops). Note that it does not detect

Re: [sr-dev] git:master: siputils: added new function is_first_hop()

2013-06-08 Thread Daniel-Constantin Mierla
On 6/8/13 8:59 AM, Juha Heinanen wrote: it came to my mind that if sip ua runs on the same host as sip proxy (which is very common in test environments at least) then it seem that is_first_hop does not work for replies. it may not be a good idea to introduce this function for replies if it has

Re: [sr-dev] git:master: siputils: added new function is_first_hop()

2013-06-08 Thread Juha Heinanen
Daniel-Constantin Mierla writes: The check is on ip, port and protocol, if ua is on same host, it will use a different port. It is similar situation with record-routing and UA on same host. Without port matching of 'myself', then contact of UA which appears as R-URI in subsequent requests

[sr-dev] negative values in branch picking priority - integer overflow

2013-06-08 Thread Jasmin Schnatterbeck
Hi, I think I discovered a bug in t_pick_branch, lines 1194 if (get_prio(inc_code, rpl)get_prio(best_s, rpl)) { ... 1210get_prio(t-uac[b].last_received, rpl)get_prio(best_s, rpl) ) the second argument of get_prio() does ALWAYS corresponds to the branch b, which is iterated

[sr-dev] bug in t_pick_branch for FAKED_REPLY?

2013-06-08 Thread Jasmin Schnatterbeck
Hi, for a local reply (e.g. 408 on request timeout with dns failover) t_should_relay_response() and t_pick_branch() is called - which uses t_reply.c 1190 rpl = t-uac[b].reply; to check for FAKED_REPLY in get_prio(). But (that's the problem), this does not work for the

[sr-dev] [tracker] Task opened: DNS failover bugs

2013-06-08 Thread sip-router
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Jasmin Schnatterbeck (jasmin) Attached to Project - sip-router Summary - DNS failover bugs Task Type - Bug Report Category - Core Status - Unconfirmed Assigned To -