Subject: Re: [dispatch] Fwd: New Version Notification for draft-procter-dispatch-outbound-discovery-00.txt

From: Michael Procter <[email-masked]>
Date: Tue, 2 Sep 2014 09:47:20 +0100

On 29 August 2014 23:01, Paul Kyzivat <[email-masked]> wrote:
>
> On 8/29/14 4:56 PM, Dale R. Worley wrote:
>>
>> How the phone, the registrar, and the edge proxy negotiate whether to
>> use Outbound is described in RFC 5626 section 4.2 -- that is, assuming
>> that everyone understands that *if* Outbound is to be used, *either*
>> the outbound-proxy-set is to be taken from DNS *or* the administrative
>> authority responsible for the DNS has configured the phone by some
>> other means.

This is a part that I don't think is defined.  I can't see a reading of RFC 5626
that supports the *either*/*or* part of your description.  Without a document
stating it, I am unsure whether everyone will share the same understanding!

>> (There is no need for additional negotiation, because how the
>> administrator of the phone has configured it already tells it where to
>> get the outbound-proxy-set.)

This might be key: I agree that you could configure a UA to do this,
in a similar
way to how you could simply configure the outbound-proxy-set in the first place.
Are you suggesting that by not configuring the outbound-proxy-set, you are
implicitly configuring the UA to use proxies derived from DNS SRV records?

> Dale - your proposal is that if a single registration receives an indication of
> outbound support, then we can infer that other servers from DNS can be
> used that way. That seems plausible. It is *possible* that it is inconsistent
> with deployed implementations of outbound.

One problem that this might cause is if a provider uses a low-priority
SRV record
as a canary.  If it sees any traffic, then a number of faults must
have occurred.
Using all SRV records as outbound proxies will obviously send REGISTER traffic
to the canary, and probably will result in call traffic too (from the
provider), reducing
the benefit of the canary.

I don't know how many providers use such a technique, but I thought having the
negotiation token was a small price to pay to eliminate this and any other
problems the changed behaviour might cause.

Michael

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 2 Sep 2014 15:19:34 -0400

Let me try to take things in order from "least controversial" to "most
controversial":

> From: Michael Procter <[email-masked]>
> 
> This is a part that I don't think is defined.  I can't see a reading
> of RFC 5626 that supports the *either*/*or* part of your
> description.  Without a document stating it, I am unsure whether
> everyone will share the same understanding!

I've already stated that I agree that there should be a document
stating the use of multiple SRV choices for selecting the targets for
multiple Outbound proxies.

However, I think the subject needs to be extended for the case where
the AOR domain name has no SRV records, but it does have multiple A or
AAAA records.  Multiple A/AAAA records are commonly used for
redundancy, and their use in Outbound seems natural.  (It's probably
already being done.)  In any case, it doesn't seem to require any
serious expansion of the software -- the RFC 3263 code is already
extracting a list of contact addresses for the domain name.

> One problem that this might cause is if a provider uses a
> low-priority SRV record as a canary.  If it sees any traffic, then a
> number of faults must have occurred.  Using all SRV records as
> outbound proxies will obviously send REGISTER traffic to the canary,
> and probably will result in call traffic too (from the provider),
> reducing the benefit of the canary.

This is an interesting problem and probably ought to be discussed in
the draft.  In theory, if the domain provides more SRV records than
(allowed number of redundant connections) + (allowance for proxies
that are unavailable), then the lowest-priority record will still
function properly as a canary, but its detection capability will be
diminished .  But there is no mechanism in RFC 5626 for the server(s)
to control the number of connections UAs establish.  (Although the
text of section 4.2.1 suggests that the number is likely to be limited
to the range 2 to 4.)

In regard to negotiating outbound support, the UA and the registrar go
through this sequence:

- the UA sends a REGISTER with reg-id in the Contact, and adds
  "Supported: outbound".

- The edge proxy adds a Path value containing its URI, with an ob URI
  parameter.

- the registrar verifies that edge proxy has indicated Outbound support, adds
  "Require: outbound" to its response.

Only when this is successful is the UA allowed to establish a second
flow.

There are a number of ways that the SIP system can provide the
outbound-proxy-set to the UA:

- via DNS records

- via "manual" configuration (usually through a Web interface provided
  by the UA)

- via the profile delivery system (But I don't think this been defined.)

- via a vendor-defined configuration delivery system

It seems to me that in all of these cases except the first, the UA
will have already received specific information as to how it should
obtain its outbound-proxy-set (indeed, it will have already received
its outbound-proxy-set).  Which is why I don't see the need for a
specific indication to flow from the registrar to the UA; there is
only one case where the UA has not already been instructed.  When we
define a *second* mechanism in which the UA must actively obtain the
outbound-proxy-set, then we will need an indicator -- for the new
mechanism.

(It's possible that the situation doesn't work as simply in practice
as it does in theory.  In that case, can we present an example of the
difficulty?)

> Are you suggesting that by not configuring the outbound-proxy-set,
> you are implicitly configuring the UA to use proxies derived from
> DNS SRV records?

Yes -- because there is no other implicit mechanism for obtaining the
proxies.

> > Dale - your proposal is that if a single registration receives an
> > indication of outbound support, then we can infer that other
> > servers from DNS can be used that way. That seems plausible. It is
> > *possible* that it is inconsistent with deployed implementations
> > of outbound.

Well, I don't recall how the UA is supposed to behave if it makes one
Outbound registration and when attempting to make a second
registration, Outbound support fails.  My memory is that combination
isn't allowed to happen -- the UA is allowed to maintain one
registration without Outbound, or one or more registrations all of
which use Outbound.

> problems the changed behaviour might cause.

I guess I don't see this as "changed behavior" -- how else would UAs
behave in the past?  Or rather, what are the problematic examples that
we need to accommodate?

> From: Paul Kyzivat <[email-masked]>

> ISTM that the *minimum* that a UA needs to have configured for itself is 
> an AOR.
> 
> From the AOR it can derive a URI of the corresponding registrar by 
> removing the user part.
> 
> Are you assuming *that* is then what is used as the URI for the outbound 
> proxy set? Or are you assuming some other URI is configured, that is 
> expected to identify an outbound-proxy-set?

Unless the UA has been positively instructed in some manner, the only
way that it can obtain the outbound-proxy-set is by looking up the
domain name of the AOR.

> If the UA is starting with just an AOR, without any expectation of 
> whether the registrar supports outbound, then it is at least a bit 
> tricky. A registrar that doesn't support outbound isn't going to be 
> happy with multiple simultaneous registrations to multiple servers for 
> its domain.

True, but the registrar tells the UA whether it supports Outbound in
the response to the first REGISTER.  If the UA doesn't receive that
indication, it isn't supposed to register anot flow.

Dale

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Sep 2014 00:37:26 +0200

2014-08-27 23:34 GMT+02:00 Dale R. Worley <[email-masked]>:
> Certainly the functionality is needed.  But what I don't see is why
> the ordinary use of RFC 3263 and DNS SRV records does not suffice.
> That has been the practice in systems that I've seen:  You arrange for
> phones in the "outside universe" to see a set of SRV records that list
> the available edge proxies, and the phone attempts to establish one or
> more connections through one or more of the proxies.  This
> establishment "just happens" when the phone attempts to send its
> REGISTER to the DNS name of its SIP domain.

IMHO there is a problem here: outbound proxy != inbound proxy. For example:

- sip:[email-masked] and sip:[email-masked].

- If Alice wants to contact Bob she would perform a NAPTR/SRV DNS
stuff on biloxi.com so she will reach the inbound server (or one of
them) associated to Bob.

- But when Bob wants to register through an outbound proxy he needs
the address of the outbound proxy which may not be the same as the
inbound proxies for biloxi.com (those discovered by Alice via DNS
procedures).

Do I miss something?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 3 Sep 2014 11:26:44 -0400

> From: Iñaki Baz Castillo <[email-masked]>

> inbound proxies for biloxi.com (those discovered by Alice via DNS

I've never seen such a configuration, although that doesn't mean they
don't exist.

But if there is such a configuration, how does the UA find the proxies
it is supposed to use to register?  The only standardized mechanism is
through DNS, but we assume it does not give the correct result.

Dale

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 3 Sep 2014 16:05:08 +0000

Beside this potential asymmetry, I think the more fundamental scope issue
is that your AoR is associated with the administrative domain where you
register - but locating outbound proxies in various roaming-type scenarios
might have little to do with that administrative domain.

If solving for this were in scope, it would require a fairly generic
service discovery protocol. Like, for the network I am in, how do I
discover the necessary set of outbound proxy servers that will let
outbound traffic escape. In some cases, forming a TLS connection to my
home administrative domain will be enough. In others, I need to
interrogate the local network in some fashion to identify a local outbound
proxy. That could look like DHCP, or for DNS U-NAPTR (RFC4848), or a
toolbox of other options. I may need to chain from that local outbound
proxy to the outbound proxy of my administrative domain, too.

To the point of this thread, this is why this is all hand-wavy in RFC5626,
if I recall correctly. I don't think looking up your home administrative
domain in the DNS and finding the SRV records placed there for inbound
traffic would be likely to solve for the entire problem space, anyway.

Jon Peterson
Neustar, Inc.

On 9/3/14, 8:26 AM, "Dale R. Worley" <[email-masked]> wrote:

>_______________________________________________
>dispatch mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dispatch

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 3 Sep 2014 16:24:24 -0400

> From: "Peterson, Jon" <[email-masked]>

> outbound traffic escape.

This is getting close to what the "User Agent Profile Delivery" (RFC
6080) was trying to do.  But that never reached solidity.

> if I recall correctly.

IIRC, the UA profile delivery work was proceeding in parallel, which
is why 5626 avoided discussing the topic.

Dale

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 3 Sep 2014 22:42:58 +0000

You're right that config profiles were supposed to be a potential way of
learning about outbound proxies, and RFC6080 does have some text about
finding a local profile. I'm not sure I'd call it a robust mechanism - it
basically assumes that DHCP or static configuration is giving you a local
domain name (like via RFC3361 or at worst RFC2132), and then you subscribe
to the config profile at that domain - but if you can bootstrap from that,
you could use it to get a config profile from the local administrative
domain.

But to your solidity point: did anyone ever specify a config profile for
actually configuring outbound proxies? Or for anything else, really?
RFC6080 is probably another solution to consider for this problem space,
but as far as I can recall there'd still be work to do there.

Jon Peterson
Neustar, Inc.

---

From: Michael Procter <[email-masked]>
Date: Thu, 4 Sep 2014 11:00:30 +0100

Hi Dale,

Comments inline, although I've reordered things slightly!

> Yes -- because there is no other implicit mechanism for obtaining the

OK.  If I were to remove the 'obfromsrv' negotiation token from my
draft, would that make the draft a reasonable starting point for
defining this?

> AAAA records.

I was initially sceptical about going this far, but on reflection, I
think you are probably right.  The key part for me is that this is
only done when there are no SRV records.  In particular, I don't want
to expand SRV and then expand A/AAAA and register to everything that I
find.

> [Effect on a low priority SRV canary]
>
> the draft.

I will add a section discussing this, although I think it will
basically highlight the effect that you will see (registrations using
the canary record) rather than offer any solutions or workarounds.

> In regard to negotiating outbound support, the UA and the registrar go

Yes.  The sequence is unchanged and requires an initial successful
registration with the registrar indicating support before the
additional registrations can be made.

> only one case where the UA has not already been instructed.

One case I wanted to distinguish was when "manual configuration" was
intended, but the configuration had been erroneously omitted.  I can't
fix this case by adding a negotiation token anyway, so I think you
have convinced me.  I'll remove the token.

Regards,

Michael

---

From: Michael Procter <[email-masked]>
Date: Thu, 4 Sep 2014 11:00:36 +0100

> but as far as I can recall there'd still be work to do there.

I'm not aware of any outbound proxy config profile work, and I did try
to find traces of other work in this area before writing the draft.  I
am reluctant to make RFC6080 part of the solution given the current
small scope of the draft.  Indeed, given some of Dale's comments, the
draft is getting ever closer to describing a current practice rather
than defining new features.

Regards,

Michael

---

From: Simon Perreault <[email-masked]>
Date: Thu, 4 Sep 2014 08:11:42 -0400

On Thu, Sep 4, 2014 at 6:00 AM, Michael Procter <[email-masked]> wrote:
> I am reluctant to make RFC6080 part of the solution given the current

+1

That is the direction I would like seeing this go.

Thanks,
Simon

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 4 Sep 2014 15:08:10 -0400

> but as far as I can recall there'd still be work to do there.

There is a "profile data set" for "media policy" (which media are
allowed to be sent at what bandwidth).  It's RFC 6796.  But that's the
only profile data set that has made it to RFC.

draft-petrie-sipping-profile-datasets-05 section 6 gives Dan Petrie's
proposed list of profile datasets:

   6.  Candidate Data Sets

   The following sections name some of the candidate data sets that are
   or may be defined.  These data sets can be aggregated to form
   profiles appropriate to the capabilities of a user agent
   implementation.

   o  SIP Protocol Data Set: the lowest common denominator set of
      properties common to all SIP user agents of any capability.  A
      schema covering the elements of this data set can be found in
      [I-D.petrie-sipping-sip-dataset].
   o  Media Data Set: this data set contains media related policies.  A
      schema covering the elements of this data set can be found in
      [I-D.ietf-sipping-media-policy-dataset].
   o  Identity Data Set: AORs and lines (see
      [I-D.petrie-sipping-identity-dataset])
   o  HTTP Protocol Data Set: server settings.  Proxy for clients.
   o  NAT Traversal Data Set: settings for STUN, TURN etc.
   o  SIP Digit Maps Data Set:
      [I-D.petrie-sipping-voip-features-dataset]
   o  VoIP Features: [I-D.petrie-sipping-voip-features-dataset]
   o  Address Book:
   o  Buddy List:

draft-petrie-sipping-sip-dataset-03 provides an <outboundProxies>
element, but it seems to be used to carry a route set.  The intention
seems to be that any alternatives or redundancies will be specified in
the DNS records for the provided proxy name-addrs.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 4 Sep 2014 16:27:32 -0400

> draft, would that make the draft a reasonable starting point for

Yes -- I've always wanted to progress this, with the single objection
that "obfromsrv" is not needed.

> to expand SRV and then expand A/AAAA and register to everything that I

Let me explain how I look at this:  RFC 3263 defines a resolution
process which takes as input parts of a URI (SIP scheme vs. SIPS
scheme), hostport, and optional "transport" parameter), and produces as
output a sequence of contact addresses (IP address/port/protocol
triples).  A SIP agent then attempts the contact addresses in order in
order to send the message.  (The resolution process is responsible for
doing any randomization, as specified by SRV records or as implied by
other records.)

(And you can implement SIP transmission this way, as we did in the
sipX system.)

Within this context, I see the process of establishing Outbound flows
as a matter of going through the resolution output list in order until
the desired number of flows are established.  And within *that*
context, multiple A/AAAA records are just one source of alternative
contact addresses.

> have convinced me.  I'll remove the token.

I agree with that.

Dale

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 4 Sep 2014 23:40:36 +0000

>the DNS records for the provided proxy name-addrs.

Intuitively, I am still having a hard time accepting that the hosts one
advertises as the targets of inbound requests for a SIP domain would
necessarily be the hosts a user agent would need to discover to send
traffic out of that administrative domain. Again, we went down the config
profile path because it had an option to discover things associated with
the local network, not just the domain where you register, and I don't
hear anyone claiming you don't need to resolve that local network problem
if you want to discover outbound proxies.

But beyond that, the asymmetry question does still bother me too. Not that
I endorse unrighteous architectures along these lines, but my
understanding is that some SIP networks have ingress elements that enforce
policies at the network borders and do all sorts of mucking about with
signaling. Those are what you would advertise in your SRVs for such
networks (if anything). It seems unlikely to me that the interface of a
border controller you would advertise to the outside world is the same
interface that clients inside the network should use in an outbound Route
set. In many cases I imagine those interface are not in the same address
space, even.

Jon Peterson
Neustar, Inc.

---

From: Michael Procter <[email-masked]>
Date: Fri, 5 Sep 2014 16:32:18 +0100

> context, multiple A/AAAA records are just one source of alternative

OK - you have unconvinced me again!  I think I understand where you
are coming from, in that the normal 3263 resolution mechanism will
naturally yield a list of IP/port, regardless of which ones apply to
which SRV records.  However, I don't think it will give the results we
want in a few key cases.

In this problem, there are two ways to set up redundant services.  One
is to advertise multiple SRV records, and one is to advertise multiple
A/AAAA records.  I fully support the first way, and accept that the
second way is sometimes used.  However, the part I am not happy about
is that if a domain is set up with multiple SRV records, each of which
names a host with multiple A/AAAA records, then we should register to
each A/AAAA record separately.  I want to avoid the situation where a
UA limited to 2 (or 4, the number doesn't really matter) proxies in
the outbound-proxy-set ends up with a bunch of registrations all bound
to the same edge proxy.  I don't think it gives sufficient diversity,
and I don't think it matches the expectations of whoever set up the
SRV records.

To that end, if there are SRV records, I'd like to register to each
one once (and allow any multiple A/AAAA records to be used for routing
to that logical proxy).  However, if there are no SRV records, I can
see the merit of looking up multiple A/AAAA records to populate the
outbound-proxy-set instead.  Does that make sense to you?

I have updated the draft to reflect the removal of negotiation, but I
haven't added words about the use of multiple A/AAAA records yet,
since we haven't agreed what they should be.

Regards,

Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Sep 2014 12:19:31 -0400

Multiple A/AAAA records may well be for different interfaces on a single 
server. I don't think two interfaces on the same server would be good 
choices for multiple outbound connections. I'm not sure if that is one 
of the points Michael is making below or not.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 05 Sep 2014 12:33:01 -0400

> might have little to do with that administrative domain.

Certainly this is a factor in some environments.
I consider that out of scope for Michael's draft. Maybe it should 
mention that.

But there are also cases where there won't be any proxies from other 
administrative domains between UA and the registrar.

An interesting question is whether the servers resolved from the domain 
of the AOR are actually registrars, or are proxies leading to the 
registrar.

Another potential issue is the use of Service-Route during registration. 
Is there any way that it can be compatible with outbound?

	Thanks,
	Paul

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sun, 7 Sep 2014 17:08:54 +0000

Michael, 

Interesting draft. I have a small proposed change that might solve some of the problems that have been raised. 

In your current draft, the UA registering to example.net does a DNS SRV lookup of 

_sip._tcp.example.net

Instead of this, make a UA that implemented this draft do a SRV lookup of 

_sip-outbound._tcp.example.net

This separates the configuration of outbound proxies from other ways the the SIP SRV record is bing used for load balancing and reliability. Other than that, the draft would stay about the same. 

Cullen 

On Aug 26, 2014, at 8:10 AM, Michael Procter <[email-masked]> wrote:

> Dear all,
> 
> SIP Outbound (RFC5626) is a useful mechanism to allow User Agents to
> reliably communicate through NATs to proxies and registrars.  However,
> there is one part of the problem that isn't addressed: how do UAs
> discover the edge proxies to use?  The RFC leaves this to either
> static configuration or future discovery mechanisms.
> 
> I've written a draft which discusses a simple mechanism to help SIP
> User Agents discover SIP proxies for use with RFC5626 (SIP Outbound).
> As far as I am aware, there is currently no standard approach to this.
> It is my hope that by defining a simple mechanism, the overall
> deployment of SIP Outbound can be increased, with a corresponding
> increase in reliability and maintainability of SIP networks.
> 
> I welcome comments and feedback, not least about whether you agree
> that the problem exists and is worth solving!
> 
> Regards,
> 
> Michael
> 
> 
> ---------- Forwarded message ----------
> From:  <[email-masked]>
> Date: 4 July 2014 16:51
> Subject: New Version Notification for
> draft-procter-dispatch-outbound-discovery-00.txt
> To: Michael Procter <[email-masked]>
> 
> 
> 
> A new version of I-D, draft-procter-dispatch-outbound-discovery-00.txt
> has been successfully submitted by Michael Procter and posted to the
> IETF repository.
> 
> Name:           draft-procter-dispatch-outbound-discovery
> Revision:       00
> Title:          Automatic discovery of RFC 5626 Edge Proxies
> Document date:  2014-07-04
> Group:          Individual Submission
> Pages:          6
> URL:
> http://www.ietf.org/internet-drafts/draft-procter-dispatch-outbound-discovery-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-procter-dispatch-outbound-discovery/
> Htmlized:
> http://tools.ietf.org/html/draft-procter-dispatch-outbound-discovery-00
> 
> 
> Abstract:
>   [RFC5626] (commonly known as 'SIP outbound') defines mechanisms that
>   permit SIP (Session Initiation Protocol) UAs (User Agents) to
>   maintain multiple connections to a registrar or proxy via multiple
>   Edge Proxies, known as the outbound-proxy-set.  Discovering the URIs
>   that make up the outbound-proxy-set is left to configuration or
>   future discovery mechanisms.  This draft defines a simple discovery
>   mechanism that enables UAs to discover the URIs of all the Edge
>   Proxies in the outbound-proxy-set without requiring additional
>   configuration on the UA.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 8 Sep 2014 11:23:14 -0400

> and I don't think it matches the expectations of whoever set up the

My opinion is that one should not set up multiple SRV records with
host names that have multiple A/AAAA records; instead each SRV record
should generate only one address.  Otherwise, you get into situations
like this.

> to that logical proxy).

The difficulty with this rule is that it creates a way of converting a
domain name into an address list that is similar to, but not exactly
the same as, RFC 3263 resolution.

Indeed, to assure diversity, the situation is more complicated than
that.  Suppose there are two SRV records, one for each of two servers,
and each server has two A records, one for each of two interfaces on
two different networks.  Registering via two interfaces on the same
server is not diverse relative to serrvers, but is diverse relative to
the access network.  Worse, if both servers are in the same building,
there isn't diversity in regard to power supply and similar
infrastructure issues.  We'd really like to have some direct way to
identify "similarity" of contact addresses.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 8 Sep 2014 11:25:51 -0400

> From: "Cullen Jennings (fluffy)" <[email-masked]>
> 
> This separates the configuration of outbound proxies from other ways
> the the SIP SRV record is bing used for load balancing and
> reliability. Other than that, the draft would stay about the same. 

Which makes it straightforward to define a fallback to the current
behavior:  If *no* _sip-outbound records are found, use the _sip
records.

Dale

---

From: Michael Procter <[email-masked]>
Date: Tue, 9 Sep 2014 09:33:08 +0100

Hi Paul,

On 5 September 2014 17:33, Paul Kyzivat <[email-masked]> wrote:
> Another potential issue is the use of Service-Route during registration. Is
> there any way that it can be compatible with outbound?

>From a quick reading of RFC3608, I can't see any particular reason
that it would be incompatible with outbound.  As far as I can tell, a
Service-Route is expected to be used for new dialogs, and not to
modify how registrations are routed, so I don't think they interact.
Happy to be corrected by those more familiar with the mechanism
though.

Michael

---

From: Michael Procter <[email-masked]>
Date: Tue, 9 Sep 2014 09:33:25 +0100

Hi Cullen,

> This separates the configuration of outbound proxies from other ways the the SIP SRV record is bing used for load balancing and reliability. Other than that, the draft would stay about the same.

Thanks, Cullen.  I like this as it is very simple, and is only a minor
change from the current approach.  I was going to push back slightly,
because it does move us further from what appears to be a current
practice, but as Dale has already commented that he likes it, I am
happy to include it!

As you say, it offers a mechanism to separate the configuration, which
will hopefully address some of Jon's concerns.  In conjunction with
Service-Route as Paul mentions, it could also become the basis of a
useful model for SIP federation.  Whilst that isn't my immediate goal,
it is good to not rule that out.

Michael

---

From: Michael Procter <[email-masked]>
Date: Tue, 9 Sep 2014 09:33:37 +0100

Hi Dale,

> should generate only one address.  Otherwise, you get into situations

What about the case where a host advertises one A and one AAAA record,
which is not uncommon?  If the UA only supports two records in the
outbound-proxy-set, but also happens to be dual-stack, we have now
lost resilience.  I don't want to provide a mechanism that leads to
any myths about "disable IPv6 on your phone to make it more reliable".

> the same as, RFC 3263 resolution.

Yes, that is true.  But we are solving a problem that is similar to,
but not exactly the same as, RFC3263 resolution ;-)  Because we expect
the output of the resolution to be truncated somewhat (maybe first 2
results, maybe 4), we need the resolution to generate diversity first.
But RFC3263 essentially does a depth-first traversal of the SRV/A/AAAA
tree rather than breadth-first, and I think breadth-first will give us
the best chance of diversity in the first n results.

> identify "similarity" of contact addresses.

Quite a few of those assumptions are not true for many systems.  And
because of that, I don't think we can have some direct way to identify
address similarity from the UA's perspective.  The only people who
will know the answers to the issues you raise are the people running
that network.  The best way I know of them communicating that
information is to publish it in the DNS.  SRV records advertise a
bunch of hosts, all of which can provide the service we need.  This
seems like a good fit for advertising how to establish multiple
diverse flows for that service.

Michael

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 5 Sep 2014 11:53:00 -0400

> It seems unlikely to me that the interface of a

That's true, but you're likely to have split DNS in regard to the SIP
domain; UAs inside the domain's network will see a different
resolution for the domain name than UAs outside the domain's network.

The question is whether the interface that clients *outside* the
domain's network use to register for the domain is going to be the
same as the interface that the domain wants to advertise to the
outside world for incoming calls.  In all the cases I've seen, they
are the same.

With a full configuration profile system, the UA could be told "the
addresses to use for registering an AOL for this domain" independently
of the RFC 3263 resolution of the domain name.  (But that doesn't seem
to be defined yet.)

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 10 Sep 2014 16:27:05 -0400

> the best chance of diversity in the first n results.

"depth-first"  Yes, ugh, especially regarding A/AAAA records for the
same host name.

> I don't think we can have some direct way to identify address
> similarity from the UA's perspective.  The only people who will know
> the answers to the issues you raise are the people running that
> network.  The best way I know of them communicating that information
> is to publish it in the DNS.  SRV records advertise a bunch of
> hosts, all of which can provide the service we need.  This seems
> like a good fit for advertising how to establish multiple diverse
> flows for that service.

You're convincing me.

Especially if we set up new rules for the "_sip-outbound" records.
For them, we can explicitly specify that all addresses generated from
one SRV record are to be considered "similar", and that the UA should
establish no two of its flows to "similar" transport addresses.  That
would not even be changing previous specifications, because there
hasn't been an explicit specification of how the UA is to select its
flow destinations.

We might want to also say that the UA should not establish two flows
to similar transport addresses, even if that entails not establishing
the configured number of flows.  (Because there wouldn't be an added
reliability from doing so.)

Hmmm, we have to worry about the fact that there usually are
_sip._tcp.domain and _sip._udp.domain SRV records which are
essentially duplicates of each other.  Ditto for _sips records.
Perhaps the real index of "similarity" of _sip-outbound SRV records is
"having the same target value" rather than "being the same record"?

Since the domain can establish separate DNS records for SIP Outbound
targets, this has little impact on how a domain's existing SRV records
are configured.

Would we want to extend the new rules to the situation where there are
no _sip-outbound records, and the UA is using the _sip records?  Given
the "A/AAAA records for a host name" case, we probably want to.

Another point:  How does this interact with NAPTR records?  They are
theoretically the first point of reference for resolving a domain
name.  But I've never used them, so I don't know how this issue
interacts with them.

Dale