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

[Bogdan-Andrei Iancu]

Hi Greg,

sorry for delay - I hope that the NAPTR lookup will be in place in the 
next 2-3 weeks....

regards,
bogdan

Greg Fausak wrote:

> 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
>
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>