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:[EMAIL PROTECTED]
Sent: Fri 1/6/2006 11:06 AM
To: [email protected]
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
[EMAIL PROTECTED]
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
