6 Jan
2006
6 Jan
'06
7:06 p.m.
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:
--
Greg Fausak
greg(a)thursday.com
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
11 Jan
11 Jan
3:51 p.m.
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:
--
Greg Fausak
greg(a)thursday.com 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
6:47 p.m.
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,
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
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:
--
Greg Fausak
greg(a)thursday.com 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
6898
days inactive
6903
days old
2 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Greg Fausak