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

From: Michael Procter <[email-masked]>
Date: Tue, 26 Aug 2014 15:10:33 +0100

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: Wed, 27 Aug 2014 17:34:22 -0400

> From: Michael Procter <[email-masked]>

> that the problem exists and is worth solving!

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.

That is, no extra functionality is needed if the phone supports SRV
records per RFC 3263.  (And we specify with the system that the phones
must support SRV records.)

Dale

---

From: Michael Procter <[email-masked]>
Date: Thu, 28 Aug 2014 08:52:00 +0100

HI Dale,

Thanks for your comments.

> REGISTER to the DNS name of its SIP domain.

My understanding of RFC 3263 is that in this scenario, a phone attempts to
maintain only one registration, and subsequent re-registrations may be
directed randomly between the SRV targets (following priority and weighting
rules).  This is consistent with the behaviour of a number of vendors' UAs
that I see.

I agree that using the list of advertised SRV targets as a list of
outbound-proxies should work, and that is the basic approach used in the
draft.  As far as I am aware, there is currently no document describing
this approach, which is why I wrote the draft.

Best regards,

Michael

---

From: Simon Perreault <[email-masked]>
Date: Thu, 28 Aug 2014 08:18:24 -0400

On Thu, Aug 28, 2014 at 3:52 AM, Michael Procter <[email-masked]> wrote:
> draft.  As far as I am aware, there is currently no document describing this
> approach, which is why I wrote the draft.

Does anyone well versed in IETF lore remember why this seemingly
obvious approach was not defined in RFC 5626? It appears too easy, and
things are never easy with SIP...

Simon

---

From: Michael Procter <[email-masked]>
Date: Thu, 28 Aug 2014 14:53:54 +0100

On Thu, Aug 28, 2014 at 1:18 PM, Simon Perreault <[email-masked]>
wrote:

> this

Interestingly, draft-jennings-sipping-outbound-01[0] contains a paragraph:

   A UA that needs to establish multiple flows needs a way to use DNS to
   select candidate addresses for the formation of flows.  The
   recommended way to do this is to look at the DNS records resulting
   from the algorithm described in RFC 3263 [3] and select distinct
   addresses from the target set.

But the next revision (draft-ietf-sip-outbound-00[1]) removes this and has
a changelog comment of:

   Changed to use a configured set of backup proxies instead of playing
   DNS games to try and figure out what backup proxies to use.

I have searched both the sip and sipping list archives over the relevant
timeframe (Feb 2005 to July 2005) and can't find any mention of the change.
 The minutes of the sip meeting at IETF62[2] contain no reference to this
part either.

The conclusion I draw is that it was removed keep things simple, given that
at the time the config framework was almost complete and would provide a
general solution to all these configuration issues.  Maybe someone else can
remember if there were other questions raised at the time?

Regards,

Michael

[0] http://www.ietf.org/archive/id/draft-jennings-sipping-outbound-01.txt
[1] http://tools.ietf.org/id/draft-ietf-sip-outbound-00.txt
[2] http://www.ietf.org/proceedings/62/sip.html

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Aug 2014 14:35:01 -0400

Michael,

Thanks for bringing this up. Were it to be adopted, it seems clear to me 
that it would be handled within sipcore. I'm happy to discuss it on the 
sipcore list, and if there is interest, we can probably bypass dispatch.

More inline.

On 8/28/14 3:52 AM, Michael Procter wrote:
> On Wed, Aug 27, 2014 at 10:34 PM, Dale R. Worley <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> My understanding of RFC 3263 is that in this scenario, a phone attempts
> to maintain only one registration, and subsequent re-registrations may
> be directed randomly between the SRV targets (following priority and
> weighting rules).  This is consistent with the behaviour of a number of
> vendors' UAs that I see.
>

IMO the validity of using alternatives from the SRV lookup in parallel 
for concurrent registrations is questionable. ISTM it is at least 
outside the intended usage.

Using explicit negotiation for doing so, as this draft proposes, is one 
way clear that up.

I have considered another way of achieving this end:

- the UA starts with the To-Uri it wants to register to:
   say sip:example.com
- the UA uses that to form an initial REGISTER request.
   The same URI becomes the R-URI. The REGISTER is set up
   consistent with RFC5626.
- the R-URI is resolved "normally" according to 3263, and
   the request is sent.
- the server that is reached notes that the request wants
   to use 5626, but has been received with the "default"
   R-URI. It decides that redundant registration is desired.
- the server responds with a 3xx containing contacts of
   redundant registrars or proxies to the registrar.
   This could be either 302 (moved temporarily) if redundant
   registrars are desired, or 305 (use proxy) if the goal
   is to use redundant proxies to a common registrar.
- For a 302 response, the UA then retries the request with
   multiple redundant registrations using contacts from the
   302 in To-URI and R-URI.
- For a 305 response, the UA then retries the request with
   multiple redundant registrations, with the old To-URI,
   but with a URIs from the 305 Contact either as the R-URI
   or in a Route header.

One issue with this approach arises if TLS is being used, because the 
contacts in the 3xx must be different from the original R-URI. (3261: a 
client processing 3xx class responses MUST NOT add any given URI to the 
target set more than once.) This can be expensive in TLS setup. I think 
it can be avoided with care. The original servers can have multiple srv 
records - (e.g., both registrar.example.net and registrar-1.example.net) 
that resolve to the same IP address. With proper credential management 
the same connection should be usable for both.

But this mechanism is certainly more complex, both to set up and to use, 
than what Michael has proposed.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 29 Aug 2014 16:56:32 -0400

> From: Michael Procter <[email-masked]>

> rules).  This is consistent with the behaviour of a number of vendors' UAs

I've looked at Outbound (RFC 5626) a bit, but am no expert.  I've
always thought that if a phone supported Outbound, it would do so by
taking the top SRV choice and sending a REGISTER.  If the registrar
responded indicating it supported Outbound, the phone would take
successive SRV choices to establish additional flows.

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 approach, which is why I wrote the draft.

I think that what I see is that there is no need for a new negotiation
mechanism, because the mechanisms of RFC 5626 already work.  But there
*is* a need to describe the use of SRV records to provide the
outbound-proxy-set -- it's "obvious" and understood, but not actually
documented.

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

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 29 Aug 2014 18:01:28 -0400

> get the outbound-proxy-set.)

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?

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.

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. I 
suspect there are few enough of those that we can just ask.

	Thanks,
	Paul