[sr-dev] git:master: modules/rr: if outbound request is outgoing, do nothing outbound

[Juha Heinanen]

Juha Heinanen writes:

  > modules/rr: if outbound request is outgoing, do nothing outbound
  >   specific in loose_route()

> i don't know if this was the proper fix, but at least my test cases now
> work ok.

except if outbound request is incoming like this ack:

ACK sip:0x179a610 at 192.98.102.10:55798;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.98.102.10:53004;rport;branch=z9hG4bKPj9f087cbc-a2ab-460d-8001-97a7b3ab930f
Max-Forwards: 70
From: sip:jh at test.fi;tag=e3963acf-9b21-417a-82ac-0bdd28c0280f
To: sip:test at test.fi;tag=b713d95a6b46ec02
Call-ID: 72b66689-a3ba-4240-af7d-be7891cdde58
CSeq: 27851 ACK
Route: <sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr>
Route: <sip:/eWzbwNo9LE2pQLAYmYUE8TAYmYK2fY=@192.98.102.20;transport=tcp;lr>
Content-Length:  0

i get to syslog:

Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: calling loose_route() on route <<sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr>>
Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: rr [loose.c:525]: "incoming" request found. Using flow-token for routing
Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: rr [loose.c:794]: process_outbound returned <1>
Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: rr [loose.c:800]: Topmost route URI: 'sip:192.98.102.10:48018;transport=tcp' is me
Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: ru/du = <sip:0x179a610 at 192.98.102.10:55798;transport=tcp>/<sip:192.98.102.10:48018;transport=tcp>
Apr 19 16:13:47 siika /usr/sbin/sip-proxy[24859]: INFO: Routing in-dialog ACK <sip:0x179a610 at 192.98.102.10:55798;transport=tcp> from <sip:jh at test.fi> to <sip:192.98.102.10:48018;transport=tcp>

as result, proxy sends ack back to the ua that sent it.

also the record-route header added by outbound proxy to the invite
is strange:

Route: <sip:/RhTFGTFRK1L8wLAYmYKE8TAYmYKu5I=@192.98.102.10:5070;transport=tcp;lr>

ip address is ok, but port is not the one that the proxy uses to talk
with UAs.  as consequence, when the ua that sent the invite sends ack,
it is sending it to wrong port.

-- juha