Subject: [sipcore] A couple of points on Happy Eyeballs

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Apr 2016 14:46:00 -0400

I think that Happy Eyeballs for SIP differs from Happy Eyeballs for HTTP
in three significant ways.  These facts have implications for the work
that needs to be done for SIP H.E.  It seems to me that these do not
require defining new mechanisms, but do add further considerations to
how H.E. is carried out.

A. There are few "opportunistic" connections in SIP, that is, where a
   device must talk to an address with no prior warning that it would
   need to do so.

   The consequence is that it's not likely to be valuable to define complex
   new features (e.g., how to send simultaneous redundant requests to
   multiple servers) to handle the case where the device has no existing
   flow to the destination.

B. In SIP, there will often be "idle flows", that is, flows that were
   established in the past but which have had no traffic for a
   considerable amount of time.

   If there are multiple flows to the destination that are idle, it will be
   desirable to test the flows to see which of them is still functioning
   before sending the request on one flow.  Testing can be done with
   an Outbound keep-alive (CR-LF or STUN), a transport keep-alive, a
   REGISTER request, or an OPTIONS request with Max-Forwards of 0.

C. In SIP, flows can be very long-lived, lasting for many days.

   If a device has cached a record that a target for a destination is
   unreachable and that target is preferred to the target that the device
   is now using, the target should be periodically re-tested to see if it
   has become reachable.

I believe that it is already known that a device should not cache
information obtained from DNS beyond the time-to-live recorded with the
information it received.  This ensures that a device will properly
refresh cached DNS information.

There is a question of whether there is any need for a device to rotate
its usage of several equal-weighted host names in SRV records.  E.g., if
only one host is responding when a large number of UAs start, then all
of their flows may be established with one host, leaving the others
idle.  If the UAs stay active for many days, traffic may remain
unbalanced for many days.  Should there be a requirement that devices
periodically reestablish their flows (and thus re-execute the SRV procedures)?

Discussion:

A. In regard to flows, it seems that almost all of them will fall into two
classes:

1. between a UA and its edge or home proxy

2. between two devices whose communication is administratively
   configured

Case 1 has all the problems of Happy Eyeballs, but the UA has the
advantage that it will register well in advance of participating in
calls, and during registration it can determine how to talk to the
proxy.  Almost all of the time, that communication choice will work for
subsequent INVITEs.

The solution to case 2 will likely be manually configured by an
administrator and so the device won't have to determine which apparent
targets are in fact reachable.

It is true that some SIP connections will be opportunistic.  For
instance, the sipX system implemented ISN dialing
(http://www.freenum.org/cookbook/), so dialing "890*1234" would route to
a phone at Nortel in Ottawa.  The proxy that forwarded that INVITE would
be contacting a server for nortel.ca that it had no established flow
with.  But that is a small minority of the traffic.

B. There will often be idle flows, flows that have been established and
are still thought to be active, but on which no message has passed for a
substantial time, and thus may no longer be active.  (My understanding is
that in HTTP idle connections are torn down relatively quickly.)

The commonness of idle flows means that we need a rapid way to test an
existing flow to determine if it's still active.  E.g., in the HTTP
case, H.E. races the establishment of an IPv4 TCP connection with the
establishment of an IPv6 TCP connection.  In a SIP case, both of these
connections may already exist, but the device can't be certain if either
of them is still working.  So it's useful to first send some sort of
test on each connection, and whichever one is proved active first is
used to send the request.

For a UA which wants to send a message to a proxy, if its registration
uses Outbound, then it can use a CR-LF or STUN keepalive as a probe of
the connection.  OTOH, if Outbound is being used, the UA may have been
sending keepalives frequently enough that the risk of failed flows is
low enough to ignore.

For a UA not using Outbound, it can either send an updated REGISTER
request or send an OPTIONS request with a Max-Forwards value of 0.

In other cases, the device is limited to sending an OPTIONS request or
using a transport-level keepalive request (if the transport has one).

C. H.E. specifies that a device should cache reachability information
about the alternative targets for a destination.  But a SIP registration
flow may well last long enough that the cached indication of the
non-reachability of an address no longer be correct.  So H.E. for SIP
should specify that if a device caches information that a preferred
address is not reachable, the device should periodically re-test the
address to see if it should be used in preference to the address the
device is currently using.

Dale