Daniel-Constantin Mierla writes:
Print $ru before the function that creates the
transaction (t_relay() or
t_newtran() in config) and see if they are the same for the two cases.
If yes, then you have to look inside tm code for this event route -- I
am not the developer of this features, perhaps Hugh (iirc) can share
more on what he wanted to achieve. Maybe it is what he needed, although
my expectation would be different, so at least a config option should be
introduced to select between the two behaviours.
this is what i got. when invite comes from uac, t_newtran() is called
before authorization:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: ru before calling t_newtran() is
<sip:test@test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: INVITE
<sip:test@test.tutpro.com> by <jh(a)test.tutpro.com> as
<sip:jh@test.tutpro.com> from <192.98.102.30> is authorized
then proxy figures out that the request is for registered local aor,
does lookup and after that calls t_relay() on contact uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: INVITE
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: ru before calling t_relay() is
<sip:test@192.98.102.30:5054>
before request is sent out, branch route is executed (that also sets
branch-failure route):
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
uas replies with 488 and branch-failure route is executed, where $ru is aor
not contact uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Got 488 response to
<sip:test@test.tutpro.com>
after append_branch() and t_relay() in branch-failure route, request
gets routed back to proxy according to aor in r-uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Relaying to
<sip:test@test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: ru before calling t_relay() is
<sip:test@test.tutpro.com>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Routing INVITE to contact
<sip:test@test.tutpro.com> to proxy itself
then proxy gets the request from itself and determines that request is
to local registered aor:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: INVITE
<sip:test@test.tutpro.com> by <sip:jh@test.tutpro.com> is from Proxy Itself
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: INVITE
<sip:test@test.tutpro.com> is to local user <test(a)test.tutpro.com>
during this iteration, t_newtrans() call is skipped, because there is no
authorization (which could take some time). instead, after lookup
t_relay() is called directly (on contact uri like during the first iteration):
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: ru before calling t_relay() is
<sip:test@192.98.102.30:5054>
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: Routing INVITE
<sip:test@192.98.102.30:5054> to contact
$ru before t_relay() is thus exactly the same contact uri as it was
during the first iteration.
but by magic this time when uas replies with 488, $ru in branch-failure
route is not aor, but contact uri:
Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9980]: INFO: Got 488 response to
<sip:test@192.98.102.30:5054>
the only difference between these two iterations is that during the
second iteration, t_newtrans() is not called before t_relay().
-- juha