draft-koivusalo-sip-outbound-discovery to rely on NAPTR orTXT records ?

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.

> 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...

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

the expectations that I and Fredrik have for the solution:

> 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"

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:

> 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.

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

>-----Original Message-----
>From: ext Jeroen van Bemmel [mailto:jbemmelzonnet.nl] 
>Sent: 24.May.2006 10:41
>To: Fredrik Thulin; Koivusalo Erkki
(Nokia-TP-MSW/Helsinki)
>Cc: sipietf.org
>Subject: Re: [SIP]
draft-koivusalo-sip-outbound-discovery to 
>rely on NAPTR orTXT records ?
>
>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" <ftit.su.se>
>To: <Erkki.Koivusalonokia.com>
>Cc: <sipietf.org>
>Sent: Wednesday, May 24, 2006 8:36 AM
>Subject: Re: [SIP]
draft-koivusalo-sip-outbound-discovery to 
>rely on NAPTR 
>orTXT records ?
>
>
>> On Tuesday 23 May 2006 09:49, Erkki.Koivusalonokia.com
wrote:
>> ...
>>> So I would like to get your comments or 'hum'
for one option
>>> 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
>>
>> _______________________________________________
>> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip 
>
>

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Erkki.Koivusalonokia.com writes:

 > 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.

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

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Hi Erkki,
> 
> 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.
> 

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








_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

jbemmelzonnet.nl 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 
 > also those that we're not) would be good. 

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

-- juha

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Citeren Juha Heinanen <jhtutpro.com>:

> jbemmelzonnet.nl 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.
> 

Perhaps for the same reasons that some proxies would support
outbound, 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 
>  > also those that we're not) would be good. 
> 
> what outbound requirements we don't know about that
would warrant
> delaying the document?

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



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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 
>the new to-be-defined SIPS security model). 

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 
>the long run. Ultimately we will need a SIP-based
mechanism here.

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 
>also those that we're not) would be good. 

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 

>-----Original Message-----
>From: ext jbemmelzonnet.nl [mailto:jbemmelzonnet.nl] 
>Sent: 26.May.2006 23:22
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: ftit.su.se; sipietf.org
>Subject: RE: [SIP]
draft-koivusalo-sip-outbound-discovery to 
>rely on NAPTR orTXT records ?
>
>Hi Erkki,
>> 
>> 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.
>> 
>
>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
>
>
>
>
>
>
>
>

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

 
Hi,

>For example: section 3.4 in ountbound-03 on edge
proxies, do 
>we need to support such a deployment?

I suppose so.

>The current solution helps to locate the home registrar
/ 
>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


>-----Original Message-----
>From: ext jbemmelzonnet.nl [mailto:jbemmelzonnet.nl] 
>Sent: 27.May.2006 11:08
>To: Juha Heinanen
>Cc: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); sipietf.org;
ftit.su.se
>Subject: RE: [SIP]
draft-koivusalo-sip-outbound-discovery to 
>rely on NAPTR orTXT records ?
>
>Citeren Juha Heinanen <jhtutpro.com>:
>
>> jbemmelzonnet.nl 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.
>> 
>
>Perhaps for the same reasons that some proxies would
support 
>outbound, 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 
>>  > also those that we're not) would be good. 
>> 
>> what outbound requirements we don't know about
that would warrant
>> delaying the document?
>
>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
>
>
>

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

On May 26, 2006, at 11:15 PM, Juha Heinanen wrote:

>
>> 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.

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. 

_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip