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:t...@test.tutpro.com> Apr 14 12:29:48 siika /usr/sbin/sip-proxy[10042]: INFO: INVITE <sip:t...@test.tutpro.com> by <j...@test.tutpro.com> as <sip:j...@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:t...@test.tutpro.com> is to local user <t...@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:t...@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:t...@test.tutpro.com> Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: ru before calling t_relay() is <sip:t...@test.tutpro.com> Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9982]: INFO: Routing INVITE to contact <sip:t...@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:t...@test.tutpro.com> by <sip:j...@test.tutpro.com> is from Proxy Itself Apr 14 12:29:48 siika /usr/sbin/sip-proxy[9990]: INFO: INVITE <sip:t...@test.tutpro.com> is to local user <t...@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 _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
