Subject: [sipcore] Remaining Happy Eyeballs work

From: [email-masked] (Dale R. Worley)
Date: Fri, 08 Apr 2016 21:39:41 -0400

I believe that we can make a clean list of the work that remains for
Happy Eyeballs in SIP.  (This is taken from from slide 4 of my
presentation at the meeting,
https://www.ietf.org/proceedings/95/slides/slides-95-sipcore-1.pdf)

- Recommend SIP Outbound (RFC 5626) between UAs and edge proxies
[everybody thinks that using SIP Outbound is the in-principle best solution]

- Allow devices to change the target order prescribed by RFC 3263/2782
  using the Happy Eyeballs rules:
     - Prefer targets with existing flows
     - Deprecate targets known to be non-responsive
     - Prefer targets with different address family than
       a non-responsive address family
     - May simultaneously initiate flows with multiple targets

- Reduce client transaction timeouts:
    Timer B and Timer F are currently 64*T1, which defaults to 32 seconds

- A solution is needed for simple UDP, either
     - a simple mechanism to maintain UDP flow state, or
     - a way to send simultaneous redundant requests to multiple addresses

The messy 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 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.  Certainly, a substantial fraction of the UAs tested
in the latest SIPit do not support TCP, TLS, or Outbound, showing that
there is substantial market acceptance of simple-UDP-only UAs.

There are a number of decidedly different ways that this need might be
satisfied.  The ones that I can think of are:

- documenting a suitable subset of SIP Outbound (if one exists)

- a lightweight SIP/DTLS (the cryptographic setup creates a flow)

- a mechanism to send simultaneous redundant requests to multiple
  addresses without causing problems with merged requests

It would also be helpful if the NAT binding of a UA behind a NAT could
change without causing existing dialogs or transactions to fail.

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 11 Apr 2016 09:37:32 +0200

> On 09 Apr 2016, at 03:39, Dale R. Worley <[email-masked]> wrote:
> 
Based on previous discussions about why very few are implementing a full,
two flow Outbound solution we may need to draft an “Outbound Simple” with
only one flow. This is in my opinion what’s outlined in the latest SIP Connect
draft, without any IETF document to support it. Proper TLS usage will require
this too, so it may be time to do that anyway.

>     - May simultaneously initiate flows with multiple targets
- Maybe a preference for flows with different address families (brainstorming)

> - documenting a suitable subset of SIP Outbound (if one exists)
According to several emails people talk about “the relevant parts of Outbound
that is implemented” - but no one has documented the relevant parts… (see above)

> - a lightweight SIP/DTLS (the cryptographic setup creates a flow)
I think this is a good idea.
>  addresses without causing problems with merged requests
While this is interesting, I think it will take a very long time to get implementations.
There are many SIP extensions that solve good problems, but have not
gotten implemented in a majority of the SIP stacks because they don’t
solve current business problems. 
> change without causing existing dialogs or transactions to fail.
THat’s a missing part of SIP. Outbound only handles dialog set-up,
but not failures in-dialog or failover in-dialog. The work on mobility
with TURN helps media and maybe SIP should document a similar
solution. 

Based on this discussion I see ideas for several different pieces of work
- 1.Happy Eyeballs for SIP
- 2.SImple Outbound 
- 3.Merge Request avoidance
- 4.SIP dialog retargeting with Outbound involvement

In order to focus, can we do Happy eyeballs without having to do all four?
I personally think that we can separate out 3 and 4, but am afraid that 2 can’t be
avoided.

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 11 Apr 2016 10:44:47 -0400

>   addresses without causing problems with merged requests

Another possibility is:

- the registration message flow from the UA is sufficient to keep the
  cached reachability information up to date

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 11 Apr 2016 16:49:50 +0200

> On 11 Apr 2016, at 16:44, Dale R. Worley <[email-masked]> wrote:
> 
…and how is that different from SIP outbound simple (SOS) ?

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 11 Apr 2016 13:50:50 -0400

"Olle E. Johansson" <[email-masked]> writes:
> two flow Outbound solution we may need to draft an "Outbound Simple" with
> only one flow. This is in my opinion what's outlined in the latest SIP Connect

I re-read parts of RFC 5626.  I'm not sure that there's much benefit to
be obtained from one-flow Outbound beyond what can be obtained from an
ordinary registration.  Indeed, an ordinary registration is a
verification that a particular address for the domain is reachable.  I
wonder if that is sufficient for Happy Eyeballs purposes?

> - Maybe a preference for flows with different address families (brainstorming)

Yes...  There are a number of variations on the idea that an address's
address family can be taken into account.  Perhaps we need broad wording
to cover this topic broadly.

> I think this is a good idea.

I think so, too, but mostly as a matter of privacy, rather than for
Happy Eyeballs.

> THat's a missing part of SIP. Outbound only handles dialog set-up,

That could become a complicated piece of work.  Is there a perceived
need for it?

> In order to focus, can we do Happy eyeballs without having to do all
> four?  I personally think that we can separate out 3 and 4, but am
> afraid that 2 can't be avoided.

We could add

5.SIP/DTLS

As for 2, we need to assess the benefits of Simple Outbound over
ordinary registration.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Apr 2016 17:24:03 -0400

> wonder if that is sufficient for Happy Eyeballs purposes?

My impression is that people are using registration as sufficient 
evidence to use the resulting "flow" for outbound calls. That of course 
doesn't mean much for UDP, but it does for TCP with or without TLS. But 
such is not formally allowed.

One of the key points of outbound is for "safe" connection reuse. For 
that, "simple" (one flow) outbound would be useful. And it would also be 
useful with SIP over DTLS.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 12 Apr 2016 09:53:25 +0200

> On 11 Apr 2016, at 19:50, Dale R. Worley <[email-masked]> wrote:
> 
The main part is that the server may reuse the connection instead of the contact
url. If a client connects to a server using TLS the server needs a way to set
up a flow in the other direction. Without Outbound the server needs to set up
a new connection to the client and the client will need a TLS cert. Many servers
actually use this form of connection reuse today (like Kamailio) but it is not
documented anywhere.

> Indeed, an ordinary registration is a
We need a working flow in the direction from the server to the client.
The client sets it up at registration and the server reuse it.
THat’s outbound.
> to cover this topic broadly.
We need to check the latest BCP from the IPv6ops guys. It’s been a moving
target. From start it was “ALWAYS prefer IPv6” but then it’s become admin
settable if I remember right. Happy Eyeballs give IPv6 a head start, but connection
setup no longer a serial process, it’s a parallell process.
> That could become a complicated piece of work.  Is there a perceived
More and more with mobile to wifi handover. It’s been discussed many times
at SIPit and other meetings of SIP developers.

> As for 2, we need to assess the benefits of Simple Outbound over
It’s a matter of being able to reuse an existing flow in two directions.
You can see a long discussion about this on the SIP Forum techwg
mailing list. In my view, their current document describes what we 
want to do, but I can’t find it documented in any RFC but outbound.
There’s a large resistance against referring to outbound, so yes, we
need a SImple Outbound that at least documents the current practise.

/O

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 12 Apr 2016 11:36:55 -0400

"Olle E. Johansson" <[email-masked]> writes:
> ...and how is that different from SIP outbound simple (SOS) ?

Well, it's already implmented, basically.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 12 Apr 2016 13:54:18 -0400

"Olle E. Johansson" <[email-masked]> writes:
> More and more with mobile to wifi handover. It's been discussed many times

Ah, yes, that's the use case.

I've been outlining a solution for re-addressing.  So far what I have
is:

- The UA detects that the previous address may be no longer functioning
  by the loss of RTP.  (Loss of RTCP actually, since the dialog may be
  on-hold.)  This can happen within maybe 10 seconds, if the default
  RTCP interval of 5 seconds is used.

- The UA sends a STUN request to a STUN server near its edge proxy to
  determine if its address has changed.  The STUN respond contains the
  UA's current public address.  Assuming that the public address has
  changed:

- The UA reregisters, using Outbound with the current address (at the
  UA's interface), which will be recorded by the registrar with the UA's
  current public address.  Since Outbound is being used, this
  registration replaces the UA's previous registration.  This rebinds
  the UA's GRUU to the current address, so that the dialog's route set
  remains valid.

- The UA then does a re-INVITE cycle to correct the session's RTP
  addresses.

That seems like it would work.  The slowest part of the process is
detecting the changeover, but if the process was triggered by the
lower-level networking code deciding to change which interface is
preferred, the adjustments could be made before the old address stops
working.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 12 Apr 2016 14:09:09 -0400

> useful with SIP over DTLS.

For UDP, the registration *is* sufficient evidence that a particular
address can be used to contact the edge proxy, and since there is no
connection, the flow can be reused legitimately.

The limitation is that the registration proved connectivity only at the
moment of registration, not at the moment of call initiation.  What is
the risk that an address that the UA could register to is not
unreachable?  If that risk is high enough, the UA needs a way to rapidly
fail over to another destination address.

The difficulty with single-flow Outbound is that the proxy/registrar
still have to implement the full array of Outbound behaviors.  Those
behaviors aren't that complicated, but the description in the RFC is
daunting.  (Only 2/3 of proxy/registrars at the last SIPit supported
Outbound.)

(Oddly, it seems to me that the registrar is not allowed to limit the
number of registered flows for a single UA -- If the registrar wants to
limit the number of flows, it has to reject a REGISTER with a specific
error code so that the UA doesn't keep trying to reestablish the failed
flow, and there is no such error code.)

In regard to SIP/DTLS, as long as the DTLS state is not updated by the
passage of ordinary packets, it isn't a connection, it's just a
transport (or we can define it as such!), and can be reused without
special arrangements in the same way UDP can be.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Tue, 12 Apr 2016 14:23:44 -0400

> preferred, the adjustments could be made before the old address stops

Few corrections/clarifications:

- If you are using SIP outbound, you more often detect IP address change
via SIP Keep-Alive timeout. Also, your signaling path might not be the same
as media. For instance if you are using ICE with hosted PBX, a lot of RTP
traffic is local to the office, but the signaling is going to central
server.

- You can detect new local IP address by running the registration and
looking at received and rport parameters in VIA.

- UDP Edge Proxy is typically configured to either use symmetric SIP
signaling (i.e. overwrite remote IP:Port from contact resolution with
IP:Port from which registration was received). TCP/TLS Edge proxy will
typically reuse the existing flow.  This works much better then using STUN
to determine the client public IP, since it saves the round trip and gives
the proxy an indication that the client is behind NAT vs public IP. If you
see STUN used for anything except SIP UDP Keep-Alive or ICE, it typically
means it is used for a wrong purpose and something will break.

- What happens to transactions in progress when IP changes? Specifically
what happens to an outstanding INVITE transaction which can take a long
time to complete? In solutions that we developed, if there is transaction
in progress, client will resend the the last request when connection is
re-established in attempt to recover the transaction.

- We also normally run transactions running over TCP or TLS with UDP
re-transmit timers to deal with situations where TCP connection gets torn
down and does not provide a clear indication that message was not
delivered. This also simplifies proxy process for request received over TCP
or TLS and forwarded to UDP.

- Request re-transmits update remote and rport values for transaction. This
allows transaction recovery when connection is reestablished.

Regards,
_____________
Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 12 Apr 2016 20:47:25 +0200

> On 12 Apr 2016, at 17:36, Dale R. Worley <[email-masked]> wrote:
> 

Yes, but not documented - the problem is how the server
reach the client using the contact URI. The contact doesn’t
always follow the actual flow, so we’re ending up with two 
TCP or TLS flows. SIP outbound flow reuse is what most
people use here - but as far as I know, it’s not documented.

For dual stack/Happy Eyeballs from UDP we can use outbound
to make the decision about address family when we have time - at registration
time. When that decision is made and proven, we can continue to 
use that flow and NOT have to make a new happy eyeballs-like discovery
for each SIP request sent over that flow. This means that we
simplify quite a lot and do not affect call setup time. 

How the SIP UA makes a decision and connection test can be
discussed - send two different REGISTER with different contacts,
two with two contacts (one per address family) or one at a time,
that’s just a few suggestions. We won’t have a merge problem
and can suggest something that is not too had to implement.

In this case outbound is used to maintain a relationship between
registration state and flow use. If an INVITE (or another transaction) 
fails, the UA will have to re-start flow setup. For any SIP transaction,
there needs to be at least one proven flow.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 12 Apr 2016 21:08:47 +0200

> On 12 Apr 2016, at 20:09, Dale R. Worley <[email-masked]> wrote:
> 
SO the big question is what the diff between SOutbound and Outbound
is. Can we remove some of these behaviours with a one-legged
SOutbound? Make it easier? We’re looking for something like XMPP
behaviour. You have a working flow that starts with a registration.
If there’s no flow established, no party sends any requests in any
direction. I know that XMPP doesn’t have UDP and see my previous
email for some ideas on UDP behaviour.
> flow, and there is no such error code.)
Hmm. Interesting. We haven’t been able to test outbound with any flows
at SIPit, so that problem is beyond the current testing scope :-)

> special arrangements in the same way UDP can be.

I think we need a special thread for DTLS/udp. There’s some
very interesting stuff one can do there. 

/O