[Users] OpenSER and transport selection (SRV and NAPTR)

Joachim Fabini Joachim.Fabini at tuwien.ac.at
Mon Dec 19 18:02:42 CET 2005


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






More information about the sr-users mailing list