Subject: [sipcore] Happy Eyeballs: Requirements

From: [email-masked] (Dale R. Worley)
Date: Mon, 20 Jun 2016 17:28:57 -0400

Getting back involved here:

I've gone over the discussions, and I think I can extract a good
statement of the requirements we need to satisfy for Happy Eyeballs in
practice.  Perhaps some of these can be extracted as seperate work
items, but they all are closely related.  Some of them can be solved
fairly simply, but I think some will involve significant new work.  The
major item that is outside its scope is signaling privacy.

Needless to say, copious comments are invited.  I'll send further
messages outlining what I think are the state of solutions for various
items.

- Solve the "happy eyeballs" problem for INVITE, i.e., if a
  destination URI is advertised with both multiple targets (IPv4 and
  IPv6 or otherwise), but connectivity to only one target exists,
  usually message transmission will not be delayed unacceptably, and in
  particular, not by a full timeout as prescribed in 3261.

Note that the solution may be decidedly different based on the
transport protocol(s) for the targets.

There is uncertainty about whether adding an RTT to signaling times is
acceptable.  For example, in practice RTT on the overall Internet is
less than 1/2 second, and that is an acceptable delay in call setup
times under ordinary circumstances.

- The solution must approximate 3263, in that if several targets are
  specified by *different* SRV records and are reachable over a long
  period of time, the relative traffic shares sent to them must be
  compatible with the priorities and weights of the SRV records.  (If
  they are alternatives that are *not* derived from different SRV
  records, the solution is unconstrained regarding relative traffic
  shares.)

- The solution should be as compatible with SIP Outbound as practicable.

The difficult part of this is "the solution for simple UDP (i.e., not
using SIP Outbound)".  There is a strong perception that in systems
where an edge proxy services 10^5 or 10^6 UAs that only
UDP-without-Outbound has a low enough per-flow overhead to be
workable.  The important requirements for simple UDP seem to be:

- The per-UA state in the edge proxy must be no larger than about what
  is kept for a registration.

- The update rate of the per-UA state in the edge proxy must be no
  larger than about the update rate for a registration.

It is perceived that TCP, TLS, and even UDP-with-Outbound do not meet
these requirements.  A substantial fraction of the UAs tested in the
latest SIPit do not support TCP, TLS, or Outbound, showing that there
is substantial market presence of simple-UDP-only UAs.

It is possible that a "Simple Outbound" can be defined that provides
the needed part of the functionality of Outbound at a sufficiently low
overhead and complexity that it meets these requirements.  If so, it
is desirable that it be conceptually and operationally
upward-compatible with Outbound.

- Deal with the handoff problem, i.e., when the call (signaling and
  media) are being sent over one interface, and that interface becomes
  unavailable, but another interface has been available, the signaling
  and media should be rerouted via the other interface.

  - The primary requirement is that the signaling path is
    reestablished, i.e., the call is not dropped.  It may take several
    seconds for signaling flow to be reestablished.

  - The media flow should be interrupted for only a "short" period of
    time so the user does not assume that the call has been dropped.
    2 seconds seems a reasonable target.

- Clients behind client-side NATs must be fully supported.

- In particular, if the external address of a NAT binding changes, the
  UA must be able to recover, with the same requirements as an
  interface handoff.

- Signaling privacy (e.g., "SIP over DTLS") is not in scope.

Dale