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

[Douglas Garstang]

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 at gmail.com] 
	Sent: Fri 1/6/2006 11:06 AM 
	To: users at 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 at thursday.com
	
	_______________________________________________
	Users mailing list
	Users at openser.org
	http://openser.org/cgi-bin/mailman/listinfo/users