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
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/users
