Subject: [sipcore] Outline of Happy Eyeballs for SIP

From: [email-masked] (Dale R. Worley)
Date: Fri, 26 Feb 2016 17:02:49 -0500

This is an outline I've assembled for a Happy Eyeballs solution.  I've
not compared it with RFC 6555, though, which will probably reveal some
more items to include.

Also, I haven't looked at mid-dialog request issues.

In practice, we may need to adjust/subset SIP Outbound to encourage
implementors to use it.  That is probably best done in another draft,
though.

Discussion is requested!

I. When UAs communicate with their base proxies, it is recommended
that they use SIP Outbound.

II. RFC 3363/draft-ietf-sipcore-dns-dual-stack prescribes how a
device determines a series of target addresses at which to contact a
SIP URI.  A device is permitted to change the order in which target
addresses are contacted:

    A. An address to which the device has a connection may be contacted
    before other addresses.  (E.g., if the device is using SIP Outbound.)

    B. An address which did not respond when the device contacted it
    in the past may be postponed after an address which did respond,
    or for which the device has no information.

    C. Two or more addresses may be contacted simultaneously rather than
    sequentially if provisions are made to avoid merged requests:

	1. If both addresses use a connection-oriented protocol, for
	one of the addresses, the request is not sent until sending
	the request to the other address has failed.  In particular,
	connections to both addresses may be initiated simultaneously,
	but the request cannot be sent on the one connection until
	sending the request on the other connection has failed.

	2. The mechanism described in IV is used to avoid merged requests.

    D. As always, based on local policy.

III. Careful revision of the timeouts involved:

I haven't looked into this.  Bogdan says:

    When comes to timers, from my experience, having the B timer to the 
    default values (64xT1) it is not something acceptable in real platform - 
    as you mentioned, the user experience will be a disaster in this case.

    For TCP -> use small timeouts for connect ; for UDP and generic SIP -> 
    use small B timer . With these setting, the switching between 2 
    destination (A or AAA) will be relative fast.

IV. Detecting merged requests in proxies - the "group" extension.

The group extension is used to allow a device to send simultaneous
redundant UDP requests to multiple addresses.  (This mechanism is a
special case of a mechanism I've been designing, so some of the details
are determined by constraints that are not from this use case.)

Assume the device is sending this request that it received:

    INVITE sip:biloxi.example.com SIP/2.0
    Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983
    Max-Forwards: 20
    To: Bob <sip:biloxi.example.com>
    From: Alice <sip:atlanta.example.com>;tag=1928301774
    Call-ID: a84b4c76e66710
    CSeq: 314159 INVITE
    Contact: <sip:atlanta.example.com>

To the "first" target, 10.5.0.10, it sends this request:

    INVITE sip:biloxi.example.com SIP/2.0
    Route: <sip:10.5.0.10>;group=2
----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.1;group
------------------------------------------------------^^^^^^
    Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983
    Max-Forwards: 19
    To: Bob <sip:biloxi.example.com>
    From: Alice <sip:atlanta.example.com>;tag=1928301774
    Call-ID: a84b4c76e66710
    CSeq: 314159 INVITE
    Contact: <sip:atlanta.example.com>

If this request is successfully received by 10.5.0.10, then it will be
processed normally, since the Route header will be deleted by that
device.

Simultaneously, to the "second" target, 10.5.0.20, it sends this request:

    INVITE sip:biloxi.example.com SIP/2.0
    Proxy-Require: group
----^^^^^^^^^^^^^^^^^^^^
    Route: <sip:10.5.0.20>;group=2
----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Via: SIP/2.0/UDP 10.0.1.10;branch=z9hG4bKnashds8.2;group
------------------------------------------------------^^^^^^
    Via: SIP/2.0/UDP 10.0.1.123;branch=z9hG4bK77ef4c2312983
    Max-Forwards: 19
    To: Bob <sip:biloxi.example.com>
    From: Alice <sip:atlanta.example.com>;tag=1928301774
    Call-ID: a84b4c76e66710
    CSeq: 314159 INVITE
    Contact: <sip:atlanta.example.com>

If the second target does not implement this extension, it rejects
this request with a 420 error.  The sending device will then postpone
using this target until the request to the first target fails, at
which time it will send a request like the request to the first
target, or a request which does not use this extension.

If the second target *does* implement this extension, it understands
that the two requests are "equivalent", in that processing either one
has "equivalent effect" (from the user's point of view), and that it
should accept and process one of them and reject the other with an
error (495 Grouping).

We assume that by administrative control, if any targets of a SIP URI
implement the "group" extension, then all of them do, and their
processing is coordinated such that exactly one request of a group is
processed.  Of course, this is trivially true if all of the targets
are addresses of the same device.

A target device detects that a request falls into a group by the
presence of the "group" field parameter in a Route header (which
specifies its address).  The group parameter designates a Via header,
counting from the last Via header as number 1.  The branch parameter
of this header tells the identify of the request within the group; two
requests that are received with the same value of this branch
parameter are duplicates caused by the network.  The branch parameter
of the next Via header tells the identity of the group.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Feb 2016 17:33:28 -0500

I only skimmed this, but ISTM that the use of proxy-require with a new 
option will make this nearly undeployable.

	Thanks,
	Paul

On 2/26/16 5:02 PM, Dale R. Worley wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 29 Feb 2016 18:19:13 +0100

> On 26 Feb 2016, at 23:02, Dale R. Worley <[email-masked]> wrote:
> 
I really think that bullet 1 should separate connection oriented transport
from the rest, which is UDP… :-)

Then we’ll focus on UDP, because that’s our problem.
> that they use SIP Outbound.
Always, but especially Outbound will solve issues for UDP.
>    before other addresses.  (E.g., if the device is using SIP Outbound.)
s/connection/flow/
>    sequentially if provisions are made to avoid merged requests:
Again, this only applies to UDP.
> 	sending the request on the other connection has failed.
No, with Happy Eyeballs you determine which connection to use
*BEFORE* sending any request. So this is only needed for connection-less
transports.
>    D. As always, based on local policy.
We should only point to the relevant RFCs for how to prefer one address family
before another, not add to the list of proposals.
>    destination (A or AAA) will be relative fast.
For connection-oriented protocols, this is already covered by Happy Eyeballs.
For UDP, I don’t see how this is specific to the problem at hand.
I must have missed something. We want to avoid serial failover,
not speed it up.

>    Route: <sip:10.5.0.10>;group=2
I would be happy if this was separate work, not part of this draft.

The migration to IPv6 needs to be easy, and asking for dual simultaneous
connections over TCP/TLS is big enough for many implementations. Implementing
a whole new proxy merge scheme in the same document will in my view make it as
ignored as SIP outbound currently is… I would prefer is this document was based
on as much existing documents as possible so it can be fast-tracked.

I think UDP can survive by 
a) recommending SIP outbound - setting up a working flow *before* the call
and/or
b) recommending server side DNS SRV separation, one prio per address family,
    no dual stack hosts for UDP

This is stuff that can be implemented quickly and can be tested at SIPit this fall.
A new merge extension may be tested at SIPit two or four years from now…
Sorry for not being optimistic…

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Feb 2016 15:37:05 -0500

> Sorry for not being optimistic…

Why do we need to have a solution for UDP?

ISTM it is generally understood that UDP for sip was a mistake, or 
perhaps just a tactical optimization in the early days. And now we are 
encouraging widespread of TLS too. Why would we want to ask people to 
commit additional development resources to patching up UDP issues?

So why don't we treat this as yet another reason to deprecate UDP, or at 
least treat it with benign neglect?

This will give people one more nudge to move on.

	Thanks,
	Paul