15 Dec
2005
15 Dec
'05
2: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
>
>
>
>
>