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

["Olle E. Johansson" <[e-mail]>]

> On 07 Jul 2016, at 03:27, Dale R. Worley <[e-mail]> wrote:
> 
> 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.

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