Oh yes! That would be AMAZING if that functionality could be added! I think I'm gonna poo my pants!
-----Original Message----- From: Greg Fausak [mailto:lgfausak@gmail.com] Sent: Fri 1/6/2006 11:06 AM To: users@openser.org Cc: Subject: [Users] Re: OpenSER and transport selection (SRV and NAPTR)
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@thursday.com _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users