Hi Bogdan,
indeed, there was a misunderstanding :) .t_relay() with no param will be kept with the current functionality. Or you suggest to be able to specify only a different proto or port from the RURI?
I did not yet find the primitive which is supposed to statefully relay and do the following: 1. NAPTR query on the transport to use PLUS 2. _exactly_ what t_relay() does now for the transport returned by the NAPTR query.
You say that t_relay() is kept with the current functionality. Does this mean no NAPTR, or will t_relay() be extended to use NAPTR before SRV/A query? If the latter then everything is OK.
Otherwise we have the alternatives:
t_relay() -> Stateful relaying according to destination address using the incoming transport (no NAPTR). t_relay_to() -> Stateful relaying to a specific host (you said that <host> is mandatory here) using NAPTR to determine the transport.
To summarize: My point is that none of these two primitives covers the case when the message is to be relayed to the next hop based only on the destination address _and_ using the transport selected by the destination proxy (determined via NAPTR query).
Except if either a) t_relay() does NAPTR or b) the host parameter in t_relay_to() is optional.
--Joachim