Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt

From: <[email-masked]>
Date: Tue, 2 May 2006 13:45:17 +0300

Hi Jeroen,

I am sorry that I have not been able to respond your suggestions
before. I have been rather busy with my other assignment recently
(and will continue so probably in next 1-2 weeks).

I hope to be able to study your proposals within 2-3 weeks and
tell if I find them feasible (or more feasible than those mechanisms
that my I-D currently uses). This far you are only person who has
expressed a strong concern about the DNS NAPTR record scalability
while some others have been happy with the solution I proposed.
So I would be grateful of the others to tell if they have similar
worries, in order to estimate which way would be the best to go.

What comes to the TXT records, I do not have any information about
how widely they are currently supported. 15 years ago they were
not, according to RFC 1123 that says:

                 The TXT and WKS RR types have not been widely used by
                 Internet sites; as a result, an application cannot rely
                 on the the existence of a TXT or WKS RR in most
                 domains. 

Is this already obsolete ? Do everyone agree that TXT records could
now safely be used for the SIP Outbound discovery solution ?

Regards,

Erkki

>-----Original Message-----
>From: ext Jeroen van Bemmel [mailto:[email-masked]] 
>Sent: 22.April.2006 12:02
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); [email-masked]
>Subject: Re: [Sip] I-D 
>ACTION:draft-koivusalo-sip-outbound-discovery-00.txt 
>
>Erkki,
>
>Another possibility: http://www.dns-sd.org/ServiceTypes.html lists the 
>following TXT keys defined for the "sip" service (amongst others):
>
>sip             Session Initiation Protocol, signalling 
>protocol for VoIP
>                  registrar     SIP registrar (see RFC3261)
>                  proxy         SIP proxy (see RFC3261)
>                  natproxy      SIP proxy for NATed clients
>                  outproxy      outbound SIP proxy (see RFC3261)
>                  stunserver    STUN server DNS name or IP address
>                [Further TXT record keys may be added in the future.]
>
>We could define a new TXT record key, say "outbound", and 
>return that along 
>with the result of a SRV lookup. In other words: use DNS-SD 
>(http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt) for 
>the purpose 
>of outbound proxy discovery
>
>Regards,
>
>jeroen
>
>----- Original Message ----- 
>From: "Jeroen van Bemmel" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Friday, April 21, 2006 7:43 PM
>Subject: Re: [Sip] I-D 
>ACTION:draft-koivusalo-sip-outbound-discovery-00.txt
>
>
>> Erkki,
>>
>> To me the draft too easily discards the "this is not 
>scalable" argument. 
>> It really is not scalable, and stacking features on DNS like 
>this feels 
>> wrong.
>>
>> RFC2915 hints at an alternative approach in the description 
>of the usage 
>> of the "U" flag: "[...] there may be applications that use 
>NAPTR to also 
>> lookup aspects of URIs". You could use a regular expression 
>including a 
>> flag that denotes outbound support.
>>
>> Regards,
>>
>> Jeroen
>>
>> ----- Original Message ----- 
>> From: <[email-masked]>
>> To: <[email-masked]>
>> Sent: Friday, April 21, 2006 1:34 PM
>> Subject: RE: [Sip] I-D 
>> ACTION:draft-koivusalo-sip-outbound-discovery-00.txt
>>
>>
>> Hi,
>>
>>>I made up two proposals based on DNS for the UA to find
>>>out proxies supporting outbound within the domain of SIP
>>>AOR of the user or the domain got from DHCP ...
>>>
>>>I am now planning to put together an I-D for those proposals
>>>as an update to RFC 3263. It may take some time, but hopefully
>>>not too long.
>>
>> The promised I-D is now available:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>> Title : Discovering Proxies Supporting SIP Outbound
>> Author(s) : E. Koivusalo
>> Filename : draft-koivusalo-sip-outbound-discovery-00.txt
>> Pages : 17
>> Date : 2006-4-20
>>
>>   This document describes modifications to DNS procedures used to
>>   resolve a SIP Uniform Resource Identifier (URI) into the 
>IP address,
>>   port, and transport protocol of the next hop to contact.  These
>>   modifications enable the SIP User Agent to discover those proxies,
>>   within the domain of the SIP URI, that support SIP extensions
>>   described in draft-ietf-sip-outbound document.  The introduced
>>   mechanisms update behavior defined in RFC 3263.
>>
>>
>> A URL for this Internet-Draft is:
>> 
>http://www.ietf.org/internet-drafts/draft-koivusalo-sip-outboun
>d-discove
>> ry-00.txt
>>
>> I would appreciate for anyone interested to review this spec
>> and provide me with comments.
>>
>> Regards,
>>
>> Erkki
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments on the application of sip
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments on the application of sip 
>
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 2 May 2006 19:51:22 +0200

Hi Erkki,

Indeed, the extend of support for TEXT records or DNS-SD remains to be 
determined also for me. Apparently the IETF once had a workinggroup for this 
(http://www.zeroconf.org/) but apparently they felt that their work was 
finished several years ago.

I think we all agree that "a DNS-based solution" is required/acceptable. Now 
all that remains is to work out the details.

Perhaps someone could do a quick test on a current DNS server, to see how 
difficult it is to add a TEXT record, and what a client would get?

Regards,

Jeroen

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 02, 2006 12:45 PM
Subject: RE: [Sip] I-D ACTION:draft-koivusalo-sip-outbound-discovery-00.txt

Hi Jeroen,

Regards,

Erkki

---

From: Dean Willis <[email-masked]>
Date: Tue, 2 May 2006 13:33:19 -0500

text records are almost universally supported, as they're quire easy  
to add in a bind config file.

However, most hosting-company front ends do not allow one to add  
them. For example, Network Solutions Inc. doesn't let one add TXT,  
SRZ, PTR, NAPTR, or anything else -- just A records, MX records, and  
CNAME records.

As far as conventions for actually USING the content of text records  
being widely deployed, well, that's a new one on me.

Said in Texan: "I ain't never seen nothing like that before, nosiree!"

--
Dean

On May 2, 2006, at 12:51 PM, Jeroen van Bemmel wrote:

> Hi Erkki,
>
> Indeed, the extend of support for TEXT records or DNS-SD remains to  
> be determined also for me. Apparently the IETF once had a  
> workinggroup for this (http://www.zeroconf.org/) but apparently  
> they felt that their work was finished several years ago.
>
> I think we all agree that "a DNS-based solution" is required/ 
> acceptable. Now all that remains is to work out the details.
>
> Perhaps someone could do a quick test on a current DNS server, to  
> see how difficult it is to add a TEXT record, and what a client  
> would get?
>
> Regards,
>
> Jeroen
>
>
> ----- Original Message ----- From: <[email-masked]>
>> ----- Original Message ----- From: "Jeroen van Bemmel"  
>> <[email-masked]>
>>> ----- Original Message ----- From: <[email-masked]>
>>> To: <[email-masked]>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 02 May 2006 12:56:53 -0700

> SRZ, PTR, NAPTR, or anything else -- just A records, MX records, and  

As far as I've seen, the use of TXT records doesn't seem to be a source of
major hardship for either SPF or DKIM. I'm certain that Dean is right
about these providers, but there is some pressure on them given the above.

> being widely deployed, well, that's a new one on me.

Lots of people use them right now with SPF/SID and DK/DKIM.

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. Like for example, do not put them at the
top of the domain, knowing what your expectations are for wildcarding (DNS
wildcards do not work the way you would hope), etc.

       Mike

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 3 May 2006 00:39:57 +0200

Erkki,

> difficult it is to add a TEXT record, and what a client would get?

I just picked up the latest version of BIND for Windows 
(http://www.isc.org/index.pl?/sw/bind/), browsed around for configuration 
options, and managed to get the following (see appendix)

Here I included several options to signal outbound support (in the zone 
config file, showing only UDP here):
1 - TXT outbound   ; appears in example.com domain
2 - @ IN NAPTR 120  10 "u"   "SIP+E2U" "!^.*$!sip:example.com;outbound" .
3 - @ IN NAPTR 110  50  "s"  "SIP+D2U"      ""  _sipo._udp.example.com.
4 - @ IN NAPTR 110  50  "s"  "SIP+D2U"      ""  _ob._sip._udp.example.com.
5 - @ IN NAPTR 150  50  "s"  "SIP-O+D2U"      ""  _sip._udp.example.com.
6 - _outbound IN NAPTR 100  50  "s"  "SIP+D2U"      "" 
_sip._udp.example.com.

I briefly considered a seventh option - adding an 'o' to the flags - but 
discarded that as inappropriate

Interestingly, for NAPTR queries Bind also returns the corresponding SRV 
records in 'additional' records. This means that one query gives both. You 
could probably tweak a DNS server to output TXT records when a NAPTR query 
is performed, but this won't happen out of the box. A query for 'ANY' type 
of record also returns both, but drawback is then that the answer becomes 
large (with many irrelevant entries, and switching to TCP)

You could use ENUM-style rewrite rules to indicate support for outbound (2). 
However, this would require a second lookup (unless the IP address + port 
were used in the rewrite expression, which has other drawbacks). Moreover, 
it is unclear how the client should proceed after the first lookup.

That leaves us with (3)-(6), (5) being described in the draft currently.
The _underscore syntax are really only conventions for DNS names, RFC3263 
defines "_sip" and "_sips", RFC2782 (SRV) defines "_udp" and "_tcp".

"_sipo" (and "_sipso") or "_ob._sip(s)" would fit in with the RFC3263 lookup 
process as follows:
1) Select transport based on NAPTR service fields with values "SIP+D2X" and 
"SIPS+D2X"
2) Determine Port and IP (for those proxies supporting outbound)

Furthermore, this will also work for domains that do not use NAPTR: the 
convention of RFC3263 to use "_sip" and "_sips" for SRV lookup would be 
extended with "_sipo" and "_sipso", or "_ob._sip(s)" . The number of NAPTR 
records would however still double, and also additional SRV records are 
needed here

Finally, the last option is perhaps the simplest one: adopt the convention 
to prepend "_outbound." to the domain name, and do a NAPTR lookup on that. 
This basically puts outbound selection before transport selection, so the 
process in RFC3263 would become:
0) Determine if you want / need outbound
1) Select transport
2) Determine IP + port

No additional SRVs needed here, and this does not change transport selection 
(while "SIP-O+D2U" does). When the domain does not support outbound, a 
second lookup is needed (without _outbound) but you might be able to combine 
those 2 queries in 1 DNS NAPTR request

Regards,

jeroen

Appendix: dig output
---------------------
C:\WINDOWS\SYSTEM32\dns\bin>dig -t NAPTR example.com
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.2 <<>> -t NAPTR example.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1704
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 1, ADDITIONAL: 8

;; QUESTION SECTION:
;example.com.                   IN      NAPTR

;; ANSWER SECTION:
example.com.            3600    IN      NAPTR   150 50 "s" "SIP-O+D2U" "" 
_sip._udp.example.com.
example.com.            3600    IN      NAPTR   160 50 "s" "SIP-O+D2T" "" 
_sip._tcp.example.com.
example.com.            3600    IN      NAPTR   170 50 "s" "SIPS-O+D2T" "" 
_sips._tcp.example.com.
example.com.            3600    IN      NAPTR   50 50 "s" "SIPS+D2T" "" 
_sips._tcp.example.com.
example.com.            3600    IN      NAPTR   90 50 "s" "SIP+D2T" "" 
_sip._tcp.example.com.
example.com.            3600    IN      NAPTR   100 50 "s" "SIP+D2U" "" 
_sip._udp.example.com.
example.com.            3600    IN      NAPTR   110 50 "s" "SIP+D2U" "" 
_sipo._udp.example.com.
example.com.            3600    IN      NAPTR   111 50 "s" "SIP+D2T" "" 
_sipo._tcp.example.com.
example.com.            3600    IN      NAPTR   111 50 "s" "SIP+D2U" "" 
_ob._sip._udp.example.com.
example.com.            3600    IN      NAPTR   120 10 "u" "SIP+E2U" 
"!^.*$!sip:example.com\;outbound" .

;; AUTHORITY SECTION:
example.com.            3600    IN      NS      host.example.com.

;; ADDITIONAL SECTION:
sipx.example.com.       3600    IN      A       127.0.0.1
outbound.sip.example.com. 3600  IN      A       127.0.0.1
_sips._tcp.example.com. 3600    IN      SRV     300 1 5061 sipx.example.com.
_sip._tcp.example.com.  3600    IN      SRV     200 1 5060 sipx.example.com.
_sip._udp.example.com.  3600    IN      SRV     100 1 5060 sipx.example.com.
_sipo._udp.example.com. 3600    IN      SRV     100 1 5060 sipx.example.com.
_sipo._tcp.example.com. 3600    IN      SRV     200 1 5060 sipx.example.com.
_ob._sip._udp.example.com. 3600 IN      SRV     120 1 5060 
outbound.sip.example.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 03 00:14:57 2006
;; MSG SIZE  rcvd: 846

C:\WINDOWS\SYSTEM32\dns\bin>dig -t ANY example.com
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.2 <<>> -t ANY example.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1004
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 8

;; QUESTION SECTION:
;example.com.                   IN      ANY

;; ANSWER SECTION:
example.com.            3600    IN      NAPTR   111 50 "s" "SIP+D2U" "" 
_ob._sip._udp.example.com.
example.com.            3600    IN      NAPTR   120 10 "u" "SIP+E2U" 
"!^.*$!sip:example.com\;outbound" .
example.com.            3600    IN      NAPTR   150 50 "s" "SIP-O+D2U" "" 
_sip._udp.example.com.
example.com.            3600    IN      NAPTR   160 50 "s" "SIP-O+D2T" "" 
_sip._tcp.example.com.
example.com.            3600    IN      NAPTR   170 50 "s" "SIPS-O+D2T" "" 
_sips._tcp.example.com.
example.com.            3600    IN      NAPTR   50 50 "s" "SIPS+D2T" "" 
_sips._tcp.example.com.
example.com.            3600    IN      NAPTR   90 50 "s" "SIP+D2T" "" 
_sip._tcp.example.com.
example.com.            3600    IN      NAPTR   100 50 "s" "SIP+D2U" "" 
_sip._udp.example.com.
example.com.            3600    IN      NAPTR   110 50 "s" "SIP+D2U" "" 
_sipo._udp.example.com.
example.com.            3600    IN      NAPTR   111 50 "s" "SIP+D2T" "" 
_sipo._tcp.example.com.
example.com.            3600    IN      TXT     "outbound"
example.com.            3600    IN      SOA     host.example.com. 
unused-email.example.com. 1 10800 3600 6048
example.com.            3600    IN      NS      host.example.com.

;; ADDITIONAL SECTION:
sipx.example.com.       3600    IN      A       127.0.0.1
outbound.sip.example.com. 3600  IN      A       127.0.0.1
_sips._tcp.example.com. 3600    IN      SRV     300 1 5061 sipx.example.com.
_sip._tcp.example.com.  3600    IN      SRV     200 1 5060 sipx.example.com.
_sip._udp.example.com.  3600    IN      SRV     100 1 5060 sipx.example.com.
_sipo._udp.example.com. 3600    IN      SRV     100 1 5060 sipx.example.com.
_sipo._tcp.example.com. 3600    IN      SRV     200 1 5060 sipx.example.com.
_ob._sip._udp.example.com. 3600 IN      SRV     120 1 5060 
outbound.sip.example.com.

;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 03 00:15:07 2006
;; MSG SIZE  rcvd: 916

C:\WINDOWS\SYSTEM32\dns\bin>dig -t NAPTR _outbound.example.com

; <<>> DiG 9.3.2 <<>> -t NAPTR _outbound.example.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 984
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;_outbound.example.com.         IN      NAPTR

;; ANSWER SECTION:
_outbound.example.com.  3600    IN      NAPTR   100 50 "s" "SIP+D2U" "" 
_sip._udp.example.com.

;; AUTHORITY SECTION:
example.com.            3600    IN      NS      host.example.com.

;; ADDITIONAL SECTION:
sipx.example.com.       3600    IN      A       127.0.0.1
_sip._udp.example.com.  3600    IN      SRV     100 1 5060 sipx.example.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 03 00:28:01 2006
;; MSG SIZE  rcvd: 165

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 3 May 2006 12:01:50 +0200

> discarded that as inappropriate

I also found RFC3958 (http://www.ietf.org/rfc/rfc3958.txt) which provides 
another alternative, but at a higher level. In retrospect, if RFC3263 would 
have followed RFC3958, we might have had
@ IN NAPTR 150  50  "s"  "VoIP:sipOu"      ""  _sip._udp.example.com.

The "+D2U" syntax refers to a resolution service according to RFC2915 (like 
E2U for ENUM and I2L, I2C, ... for URI resolution, see 
http://rfc.net/rfc2483.html), apparently it means "Domain to UDP" which 
seems odd. OTOH, the case for protocols with multiple transports seems 
underspecified in RFC2915. Ah well, guess we'll have to live with it.

Having explored all these options, I have personally come to the conclusion 
that there are 2 choices:
A) "SIP-O+D2U" which is not that bad, given what we currently have. If we 
specify it in the draft as "SIP-O+X", where "X" is any SIP transport mapping 
(current or future), then this is a reasonable approach
B) TXT outbound, associated with particular SRV records.

The other alternatives are considered "name hacks" (RFC3958).

To support case (B), we could use the flags field. RFC2915 says "DNS servers 
MAY interpret these flags and values and use that information to include 
appropriate SRV and A,AAAA, or A6 records in the additional information 
portion of the DNS packet.  Clients are encouraged to check for additional 
information but are not required to do so." (Section 2)

Therefore, I propose to define a new "t" flag to mean that TXT records are 
to be included in response to the query. A client could then do a NAPTR 
query as is. It can then do a SRV query, and scan the additional records for 
outbound support. The TXT records should not be global for the domain, but 
specific to each SRV record (i.e. per server). All of this can be realized 
with a minor change to DNS server configuration (benefit: no duplication of 
NAPTR records) and the server itself (to interpret the "t" flag). Note that 
Bind will return both NAPTR records and SRV records in the first query, if 
TXT records are added then the client only needs 1 roundtrip.

I feel (B) is more appropriate because outbound support is really a 
per-server property, not a per-domain property. Furthermore, once we have 
this it can also be used for other (future) features one might want to 
discover about servers.

Do we need to specify anything for SRV-only clients? If so, I think the 
draft should recommend that domains define "_ob._sip._udp.example.com" SRV 
records, such that the RFC3263 case of "no NAPTR records" can be supported.

Regards,

jeroen

---

From: Aki Niemi <[email-masked]>
Date: Thu, 04 May 2006 14:32:14 +0300

ext Dean Willis wrote:
> 
> 
> text records are almost universally supported, as they're quire easy to
> add in a bind config file.
>  
> However, most hosting-company front ends do not allow one to add them.
> For example, Network Solutions Inc. doesn't let one add TXT, SRZ, PTR,
> NAPTR, or anything else -- just A records, MX records, and CNAME records.

Just to give one more datapoint, my DNS provider allows TXT as well as
SRV (and AAAA of course ;), but not NAPTR. Since NAPTR is not strictly
needed in SIP, I haven't found myself complaining too much. And BTW, my
web-hosting != my DNS provider.

There are, of course, other even free DNS providers that do allow full
access to zone files, but clearly mileage varies with this one.

Cheers,
Aki

---

From: <[email-masked]>
Date: Tue, 23 May 2006 10:49:25 +0300

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

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 May 2006 11:03:21 +0300

>    with a single DNS query the UA would get all the needed

this is definitely a valuable feature.

 >    which is the desired outcome.

this is mandatory feature.  if txt records cannot be made to provide
separation of servers to these two classes, then they are not an
acceptable choice.

 >    way of using DNS. 

in practice, we can get rid of sips-o.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 23 May 2006 23:44:03 +0200

Hi Erkki,

Technically, I believe we could make both approaches work. Personally I find 
the TXT associated with SRV approach more intuitive, because 'outbound 
support' to me is a property of individual servers. You could also define 
'outbound support' as a service supported by a farm of proxies (which is 
basically what you do with the NAPTR approach). For a single property both 
are more or less equivalent, but if you consider that in the future we may 
want to add a second property 'X' (and third 'Y' and fourth 'Z') then the 
TXT approach seems easier to extend, and thus more future proof.

In a situation where you would have one domain serving NAPTR records 
pointing to SRV records in another domain, if you associate outbound support 
with NAPTR records it would imply that changes in the server park require 
DNS configuration changes in both domains. Not sure how common such a setup 
is, but on paper this type of referential integrity seems cumbersome to 
maintain.

>From a technical perspective, surely we can come up with solutions for all 
of the (-) points mentioned below. For example, you could assign a lower 
priority to SRV records with an associated TXT record indicating that the 
server supports outbound, and have clients interpret outbound support as a 
'+2' bonus to the weight (some people might consider this a 'hack' 
though...)

Regards,

Jeroen

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 23, 2006 9:49 AM
Subject: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR or 
TXT records ?

Hi !

A. NAPTR records

B. TXT records

Regards,

Erkki

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 24 May 2006 08:36:06 +0200

On Tuesday 23 May 2006 09:49, [email-masked] wrote:
...
> or another.

I hum loudly against TXT. The extendibility others have talked about 
will surely lead to a great mess, IMO.

Maybe it isn't so unreasonable to define new values for NAPTR service, 
since the old ones are for SIP and the new ones are for SIP+STUN+more  
service? If it is, then perhaps the idea with DNS based provisioning of 
outbound SIP service isn't a good idea after all...

/Fredrik

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 24 May 2006 09:40:31 +0200

Fredrik,

I tend to agree with you - TXT could very well become a can of wurms here

Going back to the original problem: we wanted to have a way to discover 
outbound support. One scenario is that a client discovers a SIP outbound 
proxy through a DHCP option, resulting in an IP address or a DNS hostname.

One thing to note here is that current clients in general don't have a way 
to lookup or prefer proxies with specific features. For example, they cannot 
choose RFC3261 proxies over non-RFC3261 proxies; they do not know in advance 
whether the discovered host(s) perform loose routing. For loose routing this 
is not a big problem; a client adds a 'lr' parameter anyway, and if it turns 
out to be a non-RFC3261 proxy, it will find out through the Record-Route 
header (or Path or Service-Route). And there are more cases like this (e.g. 
RFC3329 support, privacy services, ...)

My suggestion for TXT was rooted in the expectation that we'll soon find 
ourselves with a need for discovery of other features too. The proposed 
NAPTR approach does not offer this. On the other hand, like Fredrik 
indicates - there is a danger of 'a great mess'

Consider the following 2 options:
A) Use the hostname / IP discovered through DHCP as a key for DNS lookup
B) Extend the DHCP options used for SIP server discovery, to contain more 
than only the hostname

A) What if we would simply take the DNS name (or IP address) discovered 
through DHCP, and feed it to a new NAPTR service - say H2U, for 
hostname-to-URI. This could perform a similar rewrite as DNS ENUM does, and 
return a sip: URI including flag parameters that indicate supported features 
(like 'lr' for loose routing, and 'ob' for outbound support).

So for example: through DHCP client discovers 'proxy.example.com' and does a 
NAPTR lookup
$ORIGIN proxy.example.com.sip.dhcp.
 IN NAPTR 100 10 "u" "sip+H2U"  "!^.*$!sip:proxy.example.com;lr;ob!"

>From this point on, things would be the same as if this URI had been 
provisioned manually.

B) What seems to be causing this pain in the first place, is the limitations 
imposed by current DHCP options. Therefore another approach could be to 
define a new or extended DHCP option, supporting more than just the IP 
address or hostname (i.e. include outbound support flag there, and 
preferrably some mechanism for future options).

Regards,
Jeroen

----- Original Message ----- 
From: "Fredrik Thulin" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 24, 2006 8:36 AM
Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR 
orTXT records ?

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 24 May 2006 10:08:30 +0200

On Wednesday 24 May 2006 09:40, Jeroen van Bemmel wrote:
> Going back to the original problem: we wanted to have a way to
> discover outbound support. One scenario is that a client discovers a
> SIP outbound proxy through a DHCP option, resulting in an IP address
> or a DNS hostname.

First, remember that there are at least two kinds of outbound proxys.

  1) The one required by the network you are visiting (wifi hotspot, 
     hotel network etc.). The name of this outbound proxy can only 
     reasonably be found through SIP DHCP options, I'd agree.

  2) The one of your own home network. When I'm travelling, I would like 
     to avoid using the visited networks outbound proxy if at all 
     possible, but I _would_ like to register with my own proxys 
     directly so that I can get some reasonable security through TLS to 
     proxys whose certificate I trust.

You seem to be talking mostly about the first scenario, and I mostly 
about the second. I just want to bring them both forward to make sure 
we don't forget the requirements of others than ourselves.

> One thing to note here is that current clients in general don't have
> a way to lookup or prefer proxies with specific features.
...

Well put.

...
> A) Use the hostname / IP discovered through DHCP as a key for DNS
> lookup B) Extend the DHCP options used for SIP server discovery, to
> contain more than only the hostname

SIP DHCP can only tell you the hostname of the visited networks outbound 
service, not your home domains proxy providing SIP outbound service.

> B) What seems to be causing this pain in the first place, is the
> limitations imposed by current DHCP options.

No, not for my requirement (see above). For my requirement, the problem 
seems to be how to locate the outbound proxy, and determine if it 
supports STUN on the SIP port, without first having to contact the 
ordinary SIP servers for my home domain (it.su.se) and send them a 
REGISTER that results in a 3xx response, or a 2xx response with some 
Supported: headers or similar.

/Fredrik

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 24 May 2006 10:32:52 +0200

> Supported: headers or similar.

This to me sounds as if we need something like "callerprefs for outbound 
proxies / registrars"

Something like:

REGISTER sip:example.com
Accept-Proxy: *;extensions="outbound"

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 24 May 2006 12:02:46 +0300

> B) Extend the DHCP options used for SIP server discovery, to contain more 

DHCP mechanisms are not a replacement of DNS based discovery.  discover
need to work no matter where i connect my phone to.  also, think about
residential users behind a simple dsl modem/nat/dhcp server device.  it
would be difficult to somehow auto-configure it.

 > limitations imposed by current DHCP options.

it is not only limitations of options. see above.

-- juha

---

From: <[email-masked]>
Date: Fri, 26 May 2006 13:30:20 +0300

Hi,

What comes to the approach to use DNS for automatically discovering
the proxies supporting SIP Outbound:

>One thing to note here is that current clients in general 
>don't have a way to lookup or prefer proxies with specific features. 

I would challenge this by claiming that before draft-ietf-sip-outbound
the clients did not have any strong reason to do so. But my opinion 
is that the strong reason has emerged with SIP Outbound, which is
essential to enable the UA to traverse NAT to use any feature of SIP.

>My suggestion for TXT was rooted in the expectation that we'll 
>soon find ourselves with a need for discovery of other features too.

> outbound SIP service isn't a good idea after all...

In my understanding SIP Outbound (with its additional STUN support
multiplexed to SIP port) is such a major discontinuity point, that
will not happen every day. From RFC 3261 onwards in my opinion there
is no other SIP extension that would be as essential for the UAs.
So to traverse NATs, the UA would simply need to find a proxy to 
support SIP Outbound, rather than to opt using any proxy it finds 
but to restrain itself to use features defined in
draft-ietf-sip-outbound.

Does anyone have a different opinion on this basic assumption ?

---

Revisiting the requirements we have for SIP Outbound autodiscovery,
unfortunately I do not think either of Jeroen's solutions A) or B) would
be the right way to go.

Argument against B) was already given by Fredrik and Juha: it is
not only about resolving the domain name returned by the DHCP
(for a visited network) but also finding the outbound proxy
(of the home network) supporting SIP Outbound, by a UA that 
is only configured with the AOR of the user. The proxy should 
be found based on the hostname within the AOR, nothing to do
with DHCP in that case, even if the solution must also cover
the DHCP based proxy discovery, too.

Argument against A) is that different servers should be selected
when the very same domain name (domain of the AOR of a user) is
resolved for two different purposes:

1 When the user tries to find an outbound proxy (supporting SIP
  Outbound for NAT traversal) based on his/her own AOR: should
  result those servers the service provider would like his own
  clients to use as outbound proxies (with STUN keepalive support).
  -> The UA when trying to register and set up a flow would
     perform a specific discovery for servers supporting
     SIP Outbound

2 When clients of other service providers try to reach the user
  and are resolving the AOR of the user: should result those
  servers the service provider would like external users to use 
  when contacting the domain (no need for STUN keepalive support).
  -> The UA or proxy trying to access a domain would perform
     a conventional RFC 3263 processing for the AOR and find
     the corresponding servers (possibly not supporting SIP Outb)

I can not see how in the NAPTR H2U rewrite solution we would
get two different results (proxy farms) for resolving the same 
AOR. If the aim would be to use the NAPTR H2U only for case 1
(registration based on the AOR), I would find it strange to
require to use those rewrites only to indicate servers with SIP
Outbound support, in any other way than to do it with a name
hack (e.g. to resolve the name as "ob.example.com" etc.).

Also I think even this recent suggestion is not aligned with 

> Accept-Proxy: *;extensions="outbound"

This would not prevent the UA to blindly try to register via
several proxies, to check if any of them would support SIP
Outbound, rather than discovering those having the support
needed, as part of resolving the URI. Or like Fredrik has put it:

> supports STUN on the SIP port, WITHOUT FIRST having to contact the

So as a conclusion, for a feasible solution point of view,
we still only have the NAPTR "SIP-O" and TXT records proposed
and no clear concensus of which one to use. For now, I feel
that without extra input on the subject, I probably will keep
the next version of the I-D on using  NAPTR "SIP-O". Risks with
TXT records seem rather high for the moment.

Regards,

Erkki

>Sent: 24.May.2006 10:41
>To: Fredrik Thulin; Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]
>Subject: Re: [SIP] draft-koivusalo-sip-outbound-discovery to 
>rely on NAPTR orTXT records ?
>
>Fredrik,
>
>discover

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 26 May 2006 13:59:15 +0300

> is no other SIP extension that would be as essential for the UAs.

i share this opinion and would like to get sip working group's focus on
getting outbound and its discovery rfcs out as soon as possible.

-- juha

---

From: [email-masked]
Date: Fri, 26 May 2006 22:21:43 +0200

Hi Erkki,
> essential to enable the UA to traverse NAT to use any feature of SIP.

In other words, you agree with what I say above, but stipulate that until outbound there was no real need for it 
either. So then the question is: is there a need for something generic, or will something that only works for 
outbound suffice? 

I can think of several SIP features that could benefit from a discovery capability: SIP Identity, SIP Privacy 
(RFC3323), Security Mechanism agreement (RFC3329) to name a few (and perhaps proxies that will support 
the new to-be-defined SIPS security model). 

I understand Juha when he says "focus on outbound + discovery now". On the other hand, from the discussion 
so far I also sense that we haven't got all the requirements clear yet. My fear is that we'll end up with something 
that sort of works for outbound, but breaks as soon as we stumble upon a next 'discontinuity point' (say, 
SIPSEC) that UACs also consider as 'critical'. Then how would they go about discovering a proxy that supports 
outbound + SIPSEC?

I don't have the solution, but my gut feeling is that neither NAPTR SIP-O nor TXT records will do us much good in 
the long run. Ultimately we will need a SIP-based mechanism here.

As for the next version of the discovery draft: I think a section on the requirements that we're trying to meet (and 
also those that we're not) would be good. 

Regards,

Jeroen

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 27 May 2006 09:15:19 +0300

[email-masked] writes:

 > Then how would they go about discovering a proxy that supports 
 > outbound + SIPSEC?

i cannot imagine a situation where my some of my domain's outbound
proxies would support SIPSEC and some not.

 > As for the next version of the discovery draft: I think a section on
 > the requirements that we're trying to meet (and 

what outbound requirements we don't know about that would warrant
delaying the document?

-- juha

---

From: [email-masked]
Date: Sat, 27 May 2006 10:08:15 +0200

> proxies would support SIPSEC and some not.

Perhaps for the same reasons that some proxies would support outbound, and some not

> what outbound requirements we don't know about that would warrant

For example: section 3.4 in ountbound-03 on edge proxies, do we need to support such a deployment?
The current solution helps to locate the home registrar / proxy, but not edge proxies

Regards,
Jeroen

---

From: <[email-masked]>
Date: Mon, 29 May 2006 10:43:49 +0300

Hi,

>In other words, you agree with what I say above, but stipulate 
>that until outbound there was no real need for it either. 

You have understood me more or less correctly.

>So then the question is: is there a need for something 
>generic, or will something that only works for 
>outbound suffice? 

I would also prefer to have a generic solution if it would be
readily available. However that does not seem to be the case.
DNS TXT records appear to be even too generic while new service
types for NAPTR records limited to scale the solution towards
any new combination of services.

Promoting the NAPTR technique would rely on the assumption of
that another technique would probably have to be used to solve 
any similar problems in the future.

>I can think of several SIP features that could benefit from a 
>discovery capability: SIP Identity, SIP Privacy 
>(RFC3323), Security Mechanism agreement (RFC3329) to name a 
>few (and perhaps proxies that will support 

However I restate my opinion that SIP Outbound is a problem
with an exceptional significance. While the features you mentioned
above would benefit from a discovery capability, SIP Outbound has
a few properties that make the discovery capability essential:

- It is practically a precondition for a UA to use SIP at all
  in the environments where UA is behind a NAT. In those cases
  the UA could not just opt using the proxy it discovers even if
  it would not support SIP Outbound.

- For reliability point of view SIP Outbound suggests the UA to
  set up two different flows towards two different proxies, 
  which makes the discovery problem even more complex.

- SIP Outbound relies on multiplexing SIP and STUN protocols
  to the same port, which in my opinion is really a new type
  of service, rather than an extension to an existing protocol.

>I don't have the solution, but my gut feeling is that neither 
>NAPTR SIP-O nor TXT records will do us much good in 

Relying on SIP based mechanisms has a few problems:

1. It would introduce extra round-trips as the UA would need to
   blindly try if the proxy found by RFC 3263 rules would support
   SIP Outbound or not. If not, then the number of further round-
   trips would depend on whether the contacted proxy is able or
   is not able to redirect the UA towards another proxy.

2. If the UA aims to set up two flows towards two different proxies,
   it would make the round-trips easily to double. Furthermore I can
   not imagine how the proxies could make sure that they would not 
   redirect the second flow towards the very same proxy with which
   the UA already has set up the first flow.

>As for the next version of the discovery draft: I think a 
>section on the requirements that we're trying to meet (and 

I agree this would be a good idea, based on the various comments
given to the first version of the I-D on this mailing list. I try
to elaborate the reqs for the next version.

Regards,

Erkki 

>From: ext [email-masked] [mailto:[email-masked]] 
>Sent: 26.May.2006 23:22
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]
>Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to 
>In other words, you agree with what I say above, but stipulate 
>that until outbound there was no real need for it 
>either. So then the question is: is there a need for something 
>generic, or will something that only works for 
>outbound suffice? 
>
>I can think of several SIP features that could benefit from a 
>discovery capability: SIP Identity, SIP Privacy 
>(RFC3323), Security Mechanism agreement (RFC3329) to name a 
>few (and perhaps proxies that will support 
>I understand Juha when he says "focus on outbound + discovery 
>now". On the other hand, from the discussion 
>so far I also sense that we haven't got all the requirements 
>clear yet. My fear is that we'll end up with something 
>that sort of works for outbound, but breaks as soon as we 
>stumble upon a next 'discontinuity point' (say, 
>SIPSEC) that UACs also consider as 'critical'. Then how would 
>they go about discovering a proxy that supports 
>outbound + SIPSEC?
>
>I don't have the solution, but my gut feeling is that neither 
>NAPTR SIP-O nor TXT records will do us much good in 
>As for the next version of the discovery draft: I think a 
>section on the requirements that we're trying to meet (and

---

From: <[email-masked]>
Date: Mon, 29 May 2006 12:40:20 +0300

Hi,

>we need to support such a deployment?

I suppose so.

>proxy, but not edge proxies

Why not ? I think it does. The starting point for the procedures
described in sip-outbound-discovery is this:

   The procedures here are invoked when a UA needs to send a request via
   a proxy supporting SIP Outbound and has a SIP or SIPS (secure SIP)
   URI of the proxy without port, transport or maddr parameters as the
   next hop.

Thus it only requires the UA to have a URI mapped to those edge proxies
available. The UA may get this URI in several different ways (which are
not in scope of this I-D but could be listed within the new requirements
section to make this relation explicit):

1. The UA has been configured with the specific URI (the URI to be
   used to find the outbound proxy) that will be resolved into the 
   addresses of the edge proxies (either in the home or another 
   domain, depending on the network configuration).

2. The UA uses the AOR of the user to locate the edge proxies which 
   belong to the home domain.

3. The UA uses DHCP to locate edge proxies belonging to a visited
   domain.

Regards,

Erkki

>Sent: 27.May.2006 11:08
>To: Juha Heinanen
>Cc: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); [email-masked]; [email-masked]
>section on

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 29 May 2006 20:38:56 +0200

Erkki,

see inline

Regards,
Jeroen

[JvB] OK, so then you have found an edge proxy that supports outbound. How 
do you then ensure that this edge proxy forwards the REGISTER to a registrar 
that also supports outbound?

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 May 2006 21:19:48 -0700

> proxies would support SIPSEC and some not.

Again agreeing with Juha and generalizing somewhat to ...  I can't  
imagine a situation where the set of proxies a UA would directly  
connect for registration of a single AOR would have significantly  
different properties or capabilities.

---

From: <[email-masked]>
Date: Tue, 30 May 2006 08:43:45 +0300

Hi,

>do you then ensure that this edge proxy forwards the REGISTER 
>to a registrar that also supports outbound?

The registrar is the one in the home domain of the user.

If I understand your question correctly the issue is that
if the UA is able to automatically discover (in a visited
network) that local proxies support SIP Outbound and consequently
start using those extensions even if neither registrar or proxies
in the home domain would not support SIP Outbound ? Yes, this
could cause a kind of problem so that in the registrar the backup
registration would override the primary registration.

However if it causes the network to route all incoming requests
via the backup flow, I do not still think it would make the
communication from/to the UA to fail. But if this is something
to be prevented, then I assume the solution would be to define
a flag to the UA which indicates whether the registrar supports
outbound or not. I did not have any plans to make automatic
discovery for that, but WG members can tell their opinion on
this.

Regards,

Erkki

>Sent: 29.May.2006 21:39
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); [email-masked]
>Cc: [email-masked]; [email-masked]

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 30 May 2006 08:05:27 +0200

Erkki,

I am not sure if this is something your draft should address; my point was 
that we don't have all the requirements clear and explicit yet. It is fine 
with me if you state "I did not have any plans to make automatic discovery 
for that", it's just that it would be good to make that explicit in the 
draft

Regards,

Jeroen

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 30, 2006 7:43 AM
Subject: RE: [SIP] draft-koivusalo-sip-outbound-discovery to rely on NAPTR 
orTXT records ?

Hi,

Regards,

Erkki

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 29 May 2006 23:36:35 -0700

>> to a registrar that also supports outbound?

I view it as there are two likely case at this point
case 1) the "home" proxies/registrar support outbound
case 2) the "home" proxies/registrar don't support outbound

In case 1 - you sent it to them and things work

In case 2 - you send it to them and they ignore the reg-id and things  
work as well as they do today which is less than optimal but the best  
we can do when the domain of your AOR does not support outbound.