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

[Greg Fausak]

Hi guys,

Is anyone working on this?
I'd like to help anyway I can.

-g

On Jan 6, 2006, at 12:06 PM, Greg Fausak wrote:

> Howdy guys,
>
> I completely missed this thread.
> How is this going?
>
> I just read the roadmap which indicates NAPTR lookup
> is on the list.  I've been maintaining NAPTR and SRV records
> looking forward to the day when t_relay() forwards using NAPTR (and
> SRV).  Does that mean that the t_relay() will maintain the state,  
> slogging
> through the NAPTR/SRV records appropriately, without me having
> to do additional logic???  Specifically, I'm keen on the SRV serial  
> forking.
>
> -g
>
>
>
>
> 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
>>>
>>>
>>>
>>>
>>
> --
> Greg Fausak
> greg at thursday.com