Subject: [sipcore] Very rough draft for remaining Happy Eyeballs work

From: [email-masked] (Dale R. Worley)
Date: Wed, 06 Jul 2016 21:27:01 -0400

I've submitted a very rough draft for the remaining Happy Eyeballs work:
    https://datatracker.ietf.org/doc/draft-worley-sipcore-dual-stack/

At this point, it is an attempt to record the state of the design
discussions for a number of topics which are part of -- or related to --
Happy Eyeballs for SIP.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 7 Jul 2016 10:13:57 +0200

> On 07 Jul 2016, at 03:27, Dale R. Worley <[email-masked]> wrote:
> 

Comments:

Abstract:
- I think we are targeting both 3263 and 3261. 3263 describes how to set up a list of server addresses to reach,
  while my impression is that 3261 describes more of the connection set up and connection handling. For server2server
  connections we touch RFC 5923 too. I would rephrase into

“RFC 3263 describes how to locate a list of addresses to contact for a given SIP URI and other document desribes how to
set up and maintain a working IP flow over the SIP transports. These procedures doesn’t handle situations where both
the SIP Ua that acts as a client and the server are connected to multiple IP address families. As seen in other protocols
this can lead to long delays in flow setup time, which leads to a bad user experience. In SIP it is especially critical to have
a short time used from call attempt to first signal - the busy or ring tone. This document describes how to implement
‘Happy Eyeballs’-like IP flow setups in the current set of transports used by the SIP protocol as well as additional client
procedures which improve the SIP user experience in many circumstances”

To requirements I would add:

- Solutions must be documented both for UA’s using SIP Outbound extensions, GRUU extensions and those that
  does not support these extensions.

The details about a probe and the note about OPTIONS doesn’t really belong in the terminology section. I wonder if
the PROBE also should be used for registration states, not just dialog states. We should also document that the probe
is ONLY used for non-connection-oriented protocols (read UDP).

In the solution I think we have to add a flow state somehow. For any given IP address/port target found by the DNS lookup
there’s a state - you have it between the lines - 
 - A. Working flow established and used
 - B. Working flow established and discarded (other flow preferred)
 - C. Not attempted to open flow
 - D. Flow failed, propation mode 

Seems like state B and D will need a timeout timer (as you point out). Yay for new timers! ;-)

I don’t understand why you let devices break the order implied by RFC 3263. The order is well defined
there. Do you mean that for a given HOST you may contact the targets in any order (or preferred: simultaneously).

Did you quote Roman right in 3.2? "One of the big problems with encrypted SIP traffic is that it gets
      modified by ALG. “

Seems to me that he wanted to say the opposite - non-encrypted SIP traffic is modified by ALGs.

/O

---

From: Brett Tate <[email-masked]>
Date: Fri, 8 Jul 2016 08:21:44 -0400

> I don’t understand why you let devices break the order
> implied by RFC 3263.  The order is well defined there.
> Do you mean that for a given HOST you may contact the
> targets in any order (or preferred: simultaneously).

I'm not sure what is meant by the current text.  However, RFC 3261 does
allow the application of a local policy.  Similarly, some vendors might find
it more appropriate to move previously non responsive locations to the end
of the list instead of just skipping them.

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Jul 2016 15:26:31 -0400

Starting to work on this message:

"Olle E. Johansson" <[email-masked]> writes:
> I don't understand why you let devices break the order implied by RFC
> 3263. The order is well defined there. Do you mean that for a given
> HOST you may contact the targets in any order (or preferred:
> simultaneously).

The idea is not only to allow devices to contact the targets in a
different order, but to give devices guidance on the best order to
contact targets.  This is useful in at least the case where a particular
target is known to be non-responsive; you want to postpone that target
until after you've tried targets that aren't know to be non-responsive.

And ideal system would be to be able to contact all targets
simultaneously, but there's no general way to prevent that from creating
multiple dialogs.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 13 Jul 2016 21:57:42 +0200

> On 13 Jul 2016, at 21:26, Dale R. Worley <[email-masked]> wrote:
> 
Hmm. That makes sense, but is that not allowed in the RFCs? 
(need to re-read, as always)
> simultaneously, but there's no general way to prevent that from creating
You have to be clear here. THere’s no way to preven that from
creating multiple dialogs in UDP. In TCP you can of course prevent
multiple dialogs by not sending anything once a connection is open,
just close it without any SIP message.

/O