Hi Bogdan,

I meant t_reply() will keep its behaviour as looking into URI for the destination - but it will incorporate the NAPTR lookup.

Great - this answers my question.

to response also to on earlier question, regarding the timing

• I say 3 months are more than enough ;).

Excellent.

Many thanks for your help (and patience ;) --Joachim

Joachim Fabini wrote:

...

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