Subject: [sipcore] Happy Eyeballs: Handoff

From: [email-masked] (Dale R. Worley)
Date: Sun, 26 Jun 2016 22:55:41 -0400

This thread addresses the following requirements.  I consider these to
be part of the Happy Eyeballs problem because they are consequent to
inconsistent access to transit networks.  SIP has these problems,
while HTTP does not, because HTTP does not depend on continuity of
long-lasting connections.  (Thus, these issues are not addressed in
RFC 6555.)

    - 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 become available,
      the signaling and media should be rerouted via the other
      interface.

    - Similarly, if the external address of a NAT binding changes, the UA
      has, in effect, transitioned from using one interface to another.

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

Generally, loss of connectivity can be detected by loss of incoming
RTCP packets.  It looks like the expected RTCP interval is 5 seconds
or longer.  Intermittent loss of RTP due to network congestion is
likely, but we may have to consider detecting loss of RTP as an
indicator of loss of connectivity.  We have to consider both symmetric
loss of connectivity, in which traffic in both directions is lost
simultaneously, and asymmetric loss of connectivity, in which traffic
in one direction is lost while traffic in the other continues.

Restoring RTP (media) connectivity is straightforward once SIP
(signaling) connectivity is restored, by executing a re-INVITE to
renegotiate RTP listening ports, etc.

Restoring signaling connectivity

I can see two ways to restore SIP connectivity:  (1) sending re-INVITE
to perform a target refresh, changing the UA's target URI, and (2)
initiating a new dialog by sending an INVITE-with-Replaces to the
remote target URI in order to replace the dialog with a new dialog.

In either case, the UA should not attempt to modify/replace the dialog
before sending an OPTIONS request and receiving a response from the
new interface to the URI that will be targeted by the new INVITE.
(The round-trip OPTIONS ensures that there is two-way signaling
connectivity to the targeted URI.)  If the UA has more than one
interface that is still working, it probably needs to probe the target
URI using each interface (in parallel), because some URIs may not be
reachable from some interfaces.

Sending a re-INVITE is a good method if the UA knows that the first
URI in the route set can be reached from the UA's new address
(interface).  It seems to me that this will often not be the case,
particularly when handing off between a carrier mobile network and a
private WiFi network.

If the route set of the current dialog cannot be maintained, it is
possible to create an entirely new dialog by directing an
INVITE-with-Replaces to the remote target URI of the dialog.  In a
perfect world, the remote target URI is a GRUU, and the connectivity
of a new INVITE to the GRUU is assured.  Unfortunately there is no
guarantee that will work, either.

The difficulty is that all the UA knows about the dialog is the route
set, and there are no fixed conventions that allow the UA to extract
from the route set a URI that can be targeted by an INVITE/Replaces.
E.g., if the route set is:

    A: UA's target
    B: record route URI 1
    C: record route URI 2
    D: record route URI 3
    E: remote target

It's possible that URI C is the only publicly routable URI, and the
URI for the INVITE/Replaces should be E?Route=C&Route=D.

One possibility is probing each route URI with an OPTIONS request.
That may not be a reliable test if the URI contains an IP address,
especially if the address is in private-use space, as the UA may send
the OPTIONS request to a different server that has the same address.
Though probably if the URI contains a DNS name, then if the OPTIONS
succeeded, it probably reached the same server as the route URI
indicates.

Absent any system for indicating which URIs are publicly routable
(other than the "gr" parameter for GRUUs), we probably have to rely on
the fact that most SIP telephones execute transfers using
INVITE/Replaces requests that assume that the remote target URI that
they see is publicly routable.  As a consequence of this, SIP switches
perform machinations to ensure that the remote target URIs seen by
phones are publicly routable.

Assuming we can assume that remote target URIs are publicly routable,
then we can safely recommend that UAs always use INVITE/Replaces to
restore signaling.

Maintaining one's GRUU

Since we expect a UA to use a GRUU as its target URI so that remote
UAs can target the GRUU to reestablish signaling, a UA must ensure
that its GRUU routes to all the addresses by which it is reachable.
Generally, this means that the UA must update its registration
promptly whenever an interface becomes usable.

However, it looks like there may be some ugly consequences of
maintaining multiple mappings for a UA's GRUU -- how does a request
get routed to the GRUU, serially or parallely?  Can one use
"Request-Disposition: parallel" to force an OPTIONS request to fork
parallely to all of the contacts of a GRUU?  The executing UA does not
need to know which of the contacts of the remote UA were accessible
via the GRUU, but it does need to know quite promptly that some
contact of the remote UA is accessible via the GRUU.

OTOH, when the INVITE/Replaces is processed, we don't want it to be
delayed due to serial forking to contacts that are no longer
accessible, because the timeouts prescribed in SIP are long relative
to the time we want handouts to occur in.  But perhaps
"Request-Disposition: parallel" can be used here, as the first fork of
an INVITE/Replaces to reach a UA will be acted upon and generate a 200
response, and any later arrivals from other forks will receive 481
responses.

Glare

One risk of reestablishing the dialog is that both UAs might attempt
to reestablish the dialog at the same time.  If both UAs attempt to
re-INVITE at the same time, and the invites cross in transit, the
"glare" rules will require each UA to reject the other UA's re-INVITE,
back off, and resend, as described in RFC 3261 section 14.

If one or both UA uses INVITE/Replaces, various conflicts can occur.
It seems to me that the correct way to fix this is to treat the state
of "an INVITE/Replaces to revive the dialog is outstanding" as a
glare-creating condition that is handled the same way as "a re-INVITE
is outstanding".

Charging information

Ideally, if a handoff does not take the call outside the domain of a
single carrier, the carrier should be given enough information to
determine that the new dialog is a logical continuation of the old
dialog, so that it can combine the charging records of the two
dialogs.  In may cases, the carrier can probably determine from the
INVITE/Replaces that the new dialog is related to the old dialog.  But
should there be a rule that requires that the new dialog copy some
charging-related information from the old dialog?

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 27 Jun 2016 13:31:39 +0200

> On 27 Jun 2016, at 04:55, Dale R. Worley <[email-masked]> wrote:
> 

Responding about process issues:

I think we should separate our work with Happy Eyeballs from this work.
THis is something missing in Outbound that exist regardless of IPv6.
I think it including it in Happy Eyeballs will make it much harder to 
solve that particular problem - connection setup.

This is connection/flow resume - something that I agree we need to
look at. Switching flows in the middle of a dialog set up with outbound
is needed - as stated above, on multiple flows regardless of address
family. It could be going from mobile data to wifi, from one outbound
flow to a replacement flow (existing or new) or from IPv4 to IPv6,
since IPv4 was deemed to be slower in an ICE background check.

/O

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 27 Jun 2016 12:07:15 -0400

> solve that particular problem - connection setup.

It's not even limited to Outbound, either.

But yes, it probably can be profitably separated from Happy Eyeballs
itself.

Dale