Hi !
I have finally got some time to study the SIP Outbound
autodiscovery further based on the comments given to the
I-D. The choice betweeen DNS NAPTR and TXT records seems
to be a difficult one. The two options proposed are as
follows:
A. Define new values for NAPTR service field as
"SIP-O+D2X",
where X will be replaced with a letter indicating
transport
protocol. Service "SIP-O" means support for
SIP Outbound,
while "SIPS-O" indicates additional TLS/SIPS
URI support.
B. Associate DNS TXT records with the SRV records for
servers
supporting SIP Outbound. Those TXT records would contain
a
value like "sip-outbound" when server
supports SIP Outbound.
Further on define a new "t" flag for SRV
records to give a
hint to the server to return all related TXT record as
additional information.
The benefits (+) and drawbacks (-) of these solutions seem
to
be as follows:
A. NAPTR records
+ When responding to one NAPTR query the DNS server
typically returns
not only the NAPTR records but also the related SRV and
address
records as the NAPTR and SRV RFCs already suggest doing
so. Thus
with a single DNS query the UA would get all the needed
information.
+ Using different NAPTR service types for SIP Outbound
would make it
straightforward for an operator to divide its servers to
two farms:
Servers with SIP Outbound to be used by clients of the
service
provider and servers without SIP Outbound to be used by
external
UAs. As the external UAs would NOT need SIP Outbound,
when they
resolve the SIP URI of callee in the conventional (RFC
3263) way,
the result would be those servers without SIP Outbound
support,
which is the desired outcome.
- Both the UA and DNS server would have to support NAPTR
RRs, which
is not always the case currently. Some DNS service
providers do not
allow NAPTR RRs and the UA support is not always there.
- The number of NAPTR service types for SIP would double
(from current
five to ten) and as indicated in RFC 3486, this is not a
scalable
way of using DNS. If in the future yet another
combination would be
needed to double the number of NAPTR service types for
SIP, then
there would be 20 types, which sounds excessive.
B. TXT records
+ There are no combinatorial problems by introducing new
flags into
TXT records, since any new flag is just another text
string to be
added amongst the others.
+ Adding TXT RR support for UAs does not seem a very
challenging task,
whether or not the UA already supports NAPTR RRs.
- There is no built-in way for the service provider to
prevent the
clients
of other service providers to resolve SIP URIs to proxies
supporting
SIP Outbound (aimed to be used only by the local clients
as outbound
proxies for NAT traversal).
- If the server does not understand or obey the new
"t" flag of SRV
RR, then the UA has to separately query the TXT records
for every
SRV record it tries to use. This might lead to N x TXT RR
queries
before the SIP server has finally been located.
- Both the UA and DNS server would have to support TXT RRs,
however
even those are not allowed by some DNS service providers
even if
the servers might already support those almost
universally.
For the pure technical point of view I am currently slightly
inclined towards using TXT records, but NAPTR also has its
advantages.
However I am worried about the fact that TXT records are
almost too "general purpose" and I am not aware
of any
other standarized solutions relying only on TXT records:
- SPF uses TXT records only as a fallback solution in case
where the DNS server does not yet support SPF records,
the same seems to apply to DKIM RRs. However for SIP
Outbound, defining new RR types for one single boolean
flag is not a feasible solution.
- For DNS-SD there is only an expired I-D and there seems
to be no movement to get it approved as an RFC.
Also this kind of comments would make me doubt if the
solution
based on TXT records is eventually acceptable (even if the
use
of TXT records in SIP Outbound case would be
straightforward):
> A word of caution: use of TXT records will get you an
> earful from the IAB. The entire area is a huge tangle
> and you need to be extremely cautious about how you use
> TXT records.
So I would like to get your comments or 'hum' for one
option
or another. I have already prepared a second version of the
I-D with a new way of using SRV records to find the target
host for the backup flow, based on the comments received
for this subject. Now the final issue before publishing
this edition is whether to use NAPTR and TXT records to
indicate support for SIP Outbound.
Regards,
Erkki
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|