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

[Bogdan-Andrei Iancu]

Hi Joachim,

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

to response also to on earlier question, regarding the timing -  I say 3 
months are more than enough ;).

regards,
bogdan

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
>
>
>  
>