Subject: [sipcore] Happy Eyeballs: Outbounde

From: [email-masked] (Dale R. Worley)
Date: Wed, 29 Jun 2016 21:35:24 -0400

This thread is to explore "outbound" issues.  As I have them, the
requirements are:

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

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

It's clear to me that the problem is *solvable*, because existing SIP
systems do handle the client-side NAT problem.  E.g., the open-source
sipX system has full client-side NAT support.  That scheme doesn't
require SIP Outbound support in the client at all.  NAT support is
triggered by the client's requests arriving from an address that is
different than what is specified in the request.  Support is
implemented by manipulating the client's behavior, rewriting
requests/responses to substitute IP addresses, and providing
(essentially) a TURN server to relay media.

As far as I can remember, sipX's NAT support is recorded and
implemented in the standard registration/redirect database.  However,
NAT support does depend on forcing the client to re-register
frequently enough to be assured that the NAT mapping is not released.
Since processing re-registrations is by far the bulk of the signaling
traffic even without NAT support, this is not a trivial change.

My expectation is that almost all commercial SIP systems have NAT
support of this sort.

One difference between this sort of NAT support and Outbound is that
NAT support is done only at the registrar/proxy; if there is a
separate edge proxy, it only passes UDP messages and can easily be
stateless.  This might be a significant factor in very large
deployments.

Perhaps a significant problem with Outbound is that it has to be
implemented in both the phone and the switch, leading to a network
effect problem.

At this point, it seems to me that we need to get a better
understanding of what people are doing in the market to deal with NATs
and find out why they don't use Outbound.  (Since Outbound is the
standard method, I would think it has a strategic advantage in the
technological competition.)

Dale

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Jun 2016 18:42:32 -0400

Few observations:

1. There is a significant number of end points, such as Polycom phones,
that do support SIP outbound.

2. The most efficient way for the client to keep the NAT hole open is to
send STUN based keep alive messages. They are widely supported. For
instance OpenSIPS supports via Stun Module.

3. For server, the most efficient way to keep the NAT hole open is to send
OPTIONS or NOTIFY requests to the client. This is much more efficient then
registrations with small timeouts.

4. Registration server which has an in-memory database for current
registrations can be fairly efficient in reducing number of back-end DB
updates due to registrations and subscriptions with small timeouts. It is
not going to be stateless, but its state does not need to be replicated and
would automatically recover on the stand-by server on the next registration
or subscription request from the client.

5. One of the big problems with encrypted SIP traffic is that it gets
modified by ALG. For a lot of hosted PBX providers avoiding the need to
troubleshoot customer routers is a bigger incentive to deploy TLS then user
privacy.

Regards,

_____________
Roman Shpount

On Wed, Jun 29, 2016 at 9:35 PM, Dale R. Worley <[email-masked]> wrote:

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