15 Dec
2005
15 Dec
'05
10:59 a.m.
Hi,
Initially I intended to submit a feature request for
OpenSER functionality similar to t_relay_to_udp,
t_relay_to_tcp but WITHOUT the need to specify the
destination IP address and port.
My reasoning was to let the new functions do exactly
what t_relay() does but in addition force the DNS SRV
query for a specific transport (udp, tcp, or tls).
Seeing the roadmap for 1.1 I realized that NAPTR solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for _sips._tcp.mydomain.org, if this
fails to query for _sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
15 Dec
15 Dec
11:36 a.m.
What you propose clearly break RFC 3263 "Locating SIP Servers".
I would prefer staying inside compliancy.......
Samuel.
2005/12/15, Joachim Fabini <Joachim.Fabini(a)tuwien.ac.at>at>:
Hi,
Initially I intended to submit a feature request for
OpenSER functionality similar to t_relay_to_udp,
t_relay_to_tcp but WITHOUT the need to specify the
destination IP address and port.
My reasoning was to let the new functions do exactly
what t_relay() does but in addition force the DNS SRV
query for a specific transport (udp, tcp, or tls).
Seeing the roadmap for 1.1 I realized that NAPTR solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for _sips._tcp.mydomain.org, if this
fails to query for _sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:46 a.m.
HI Joachim,
you are right - when the NAPTR support will be added, I plan to cumulate
all t_relayxxxx() functions in a single one like:
t_relay("[proto:]host[:port]")
lack of proto or port will trigger NAPTR or SRV lookups.
regards,
bogdan
Joachim Fabini wrote:
Hi,
Initially I intended to submit a feature request for
OpenSER functionality similar to t_relay_to_udp,
t_relay_to_tcp but WITHOUT the need to specify the
destination IP address and port.
My reasoning was to let the new functions do exactly
what t_relay() does but in addition force the DNS SRV
query for a specific transport (udp, tcp, or tls).
Seeing the roadmap for 1.1 I realized that NAPTR solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for _sips._tcp.mydomain.org, if this
fails to query for _sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:53 a.m.
Hi Bogdan,
you are right - when the NAPTR support will be added,
I plan
to cumulate
all t_relayxxxx() functions in a single one like:
t_relay("[proto:]host[:port]")
lack of proto or port will trigger NAPTR or SRV lookups.
Hmmh, host must be optional, too. That's the situation
when you really need DNS NAPTR/DNS SRV lookup.
Any idea when first versions of NAPTR-support will be
available?
Thanks,
best regards
--Joachim
Joachim Fabini wrote:
Hi,
Initially I intended to submit a feature request for
OpenSER functionality similar to t_relay_to_udp,
t_relay_to_tcp but WITHOUT the need to specify the
destination IP address and port.
My reasoning was to let the new functions do exactly
what t_relay() does but in addition force the DNS SRV
query for a specific transport (udp, tcp, or tls).
Seeing the roadmap for 1.1 I realized that NAPTR solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for _sips._tcp.mydomain.org, if this
fails to query for _sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1:14 p.m.
Hi Joachim,
the host (like name) is mandatory - if no port and no proto is given,
you will use the host name (sip.com) to do NAPTR lookup to get the
supported protos and than SRV lookup to get the machine name and port.
if only the port is missing, only SRV lookup will be done to get the
machine name and port.
if only proto is missing, it will be assumed UDP and normal (A record)
DNS lookup performed.
time? hard to say...until the next release anyhow...
regards,
bogdan
Joachim Fabini wrote:
Hi Bogdan,
you are right - when the NAPTR support will be
added, I plan
to cumulate
all t_relayxxxx() functions in a single one like:
t_relay("[proto:]host[:port]")
lack of proto or port will trigger NAPTR or SRV lookups.
Hmmh, host must be optional, too. That's the situation
when you really need DNS NAPTR/DNS SRV lookup.
Any idea when first versions of NAPTR-support will be
available?
Thanks,
best regards
--Joachim
Joachim Fabini wrote:
>Hi,
>
>Initially I intended to submit a feature request for
>OpenSER functionality similar to t_relay_to_udp,
>t_relay_to_tcp but WITHOUT the need to specify the
>destination IP address and port.
>My reasoning was to let the new functions do exactly
>what t_relay() does but in addition force the DNS SRV
>query for a specific transport (udp, tcp, or tls).
>
>Seeing the roadmap for 1.1 I realized that NAPTR solves
>part of this problem. Is there already any estimation
>when NAPTR implementation will be available in OpenSER?
>
>I intentionally said "part of the problem" because
>NAPTR delegates the decision on the transport to the
>destination DNS. But: our own proxy might also be
>required to control the selected transport.
>It seems to me quite flexible to implement a
>proxy-hosted NAPTR emulation and specify the list
>of requested protocols, e.g.
>t_relay_to_transport("tls","tcp",0)
>specifies that t_relay should firstly generate a
>SRV DNS query for _sips._tcp.mydomain.org, if this
>fails to query for _sip._tcp.mydomain.org and then
>give up - if I don't want UDP.
>
>This saves one DNS query (NAPTR) and enables a proxy
>to control what protocols it uses for contacting the
>next hop.
>
>Finally, I believe that the interface to t_relay_naptr()
>(or whatever the naptr relaying will be called) should
>support selection of desired protocols, e.g.
>t_relay_to_naptr("tls", "tcp", "udp") where entries
>can be left empty to indicate that this transport is
>not desired. The argument order might even overrule
>the NAPTR response transport ranking - finally we
>connect and thus decide on what transport we prefer... ;)
>
>Any comments warmly welcome,
>best regards
>--Joachim
>
>
>
>_______________________________________________
>Users mailing list
>Users(a)openser.org
>http://openser.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
16 Dec
16 Dec
11:02 a.m.
Hi Bogdan,
the host (like name) is mandatory - if no port and no
proto is given,
you will use the host name (sip.com) to do NAPTR lookup to get the
supported protos and than SRV lookup to get the machine name and port.
if only the port is missing, only SRV lookup will be done to get the
machine name and port.
if only proto is missing, it will be assumed UDP and normal
(A record) DNS lookup performed.
Hmmh, seems to me that there's a slight misunderstanding
here. The new function should imho also replace the current
t_relay() - from the user's point of view this means for me:
route the message statefully to the next hop.
The user does not need to (and can not, except he does
the RFC3263 resolution manually) specify a destination
proxy - OpenSER should be able to determine it according
to the SIP DNS resolution rules (RFC 3263).
So my point of view: if no host is passed, OpenSER uses
the destination URI to query the DNS (NAPTR) to determine
what protocol the destination proxy prefers (Samuel made
the correct point in his email, RFC 3263 states that the
destination proxy must decide on the protocol to use)
and then must do the SRV record and possibly A record
lookup for the correct host to contact.
time? hard to say...until the next release anyhow...
Doesn't sound too optimistic if we need it in the next
three months, right?... ;)
Thanks,
best regards
--Joachim
19 Dec
19 Dec
5:29 p.m.
Hi Joachim,
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?
regards,
bogdan
Joachim Fabini wrote:
Hi Bogdan,
the host (like name) is mandatory - if no port and
no proto is given,
you will use the host name (sip.com) to do NAPTR lookup to get the
supported protos and than SRV lookup to get the machine name and port.
if only the port is missing, only SRV lookup will be done to get the
machine name and port.
if only proto is missing, it will be assumed UDP and normal
(A record) DNS lookup performed.
Hmmh, seems to me that there's a slight misunderstanding
here. The new function should imho also replace the current
t_relay() - from the user's point of view this means for me:
route the message statefully to the next hop.
The user does not need to (and can not, except he does
the RFC3263 resolution manually) specify a destination
proxy - OpenSER should be able to determine it according
to the SIP DNS resolution rules (RFC 3263).
So my point of view: if no host is passed, OpenSER uses
the destination URI to query the DNS (NAPTR) to determine
what protocol the destination proxy prefers (Samuel made
the correct point in his email, RFC 3263 states that the
destination proxy must decide on the protocol to use)
and then must do the SRV record and possibly A record
lookup for the correct host to contact.
time? hard to say...until the next release
anyhow...
Doesn't sound too optimistic if we need it in the next
three months, right?... ;)
Thanks,
best regards
--Joachim
6:02 p.m.
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:46 p.m.
Hi Joachim,
I meant t_reply() will keep its behaviour as looking into URI for the
destination - but it will incorporate the NAPTR lookup.
to response also to on earlier question, regarding the timing - I say 3
months are more than enough ;).
regards,
bogdan
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
15 Dec
15 Dec
12:41 p.m.
Joachim Fabini wrote:
Hi,
Initially I intended to submit a feature request for
OpenSER functionality similar to t_relay_to_udp,
t_relay_to_tcp but WITHOUT the need to specify the
destination IP address and port.
My reasoning was to let the new functions do exactly
what t_relay() does but in addition force the DNS SRV
query for a specific transport (udp, tcp, or tls).
Hi Joachim!
Maybe you can get a workaround using add_uri_param:
http://openser.org/docs/modules/1.0.x/uri.html#AEN118
add_uri_param("transport=tcp");
The t_relay should use TCP. A problem might be if there is already a
transport parameter.
I guess you can avoid this by do not changing the request URI but the
destination URI (overrides the request URI). E.g. an example from Bogdan:
avp_write("sip:openser.org;transport=tls","i:11");
avp_pushto("$duri","i:11");
Probably you have to use regexp to copy the existing RURI into an AVP,
strip the existing transport parameter, add the new one, and write it
into the DURI.
regards
klaus
Seeing the roadmap for 1.1 I realized that NAPTR
solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for _sips._tcp.mydomain.org, if this
fails to query for _sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
16 Dec
16 Dec
11:10 a.m.
Hi Klaus,
Maybe you can get a workaround using add_uri_param:
http://openser.org/docs/modules/1.0.x/uri.html#AEN118
add_uri_param("transport=tcp");
The solution is interesting. I see a slight problem
because we want to use tcp in the core and udp in the
access - basically the last proxy on the path must
rewrite the URI again to udp. But if the originating
client inserted already tcp... hmmmh...
The t_relay should use TCP. A problem might be if
there is already a
transport parameter.
I guess you can avoid this by do not changing the request URI but the
destination URI (overrides the request URI). E.g. an example
from Bogdan:
avp_write("sip:openser.org;transport=tls","i:11");
avp_pushto("$duri","i:11");
Probably you have to use regexp to copy the existing RURI
into an AVP, strip the existing transport parameter, add
the new one, and write it into the DURI.
The d-uri approach sounds promising. I'll go through the
scenario to see if there's some problem that I do not find
at first glance.
Thanks for your help,
best regards
--Joachim
regards
klaus
Seeing the roadmap for 1.1 I realized that NAPTR
solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for _sips._tcp.mydomain.org, if this
fails to query for _sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6726
days inactive
6730
days old
10 comments
4 participants
participants (4)
-
Bogdan-Andrei Iancu -
Joachim Fabini -
Klaus Darilion -
samuel