Subject: Re: [sipcore] Outline of Happy Eyeballs for SIP

From: [email-masked] (Dale R. Worley)
Date: Tue, 01 Mar 2016 11:54:39 -0500

Paul Kyzivat <[email-masked]> writes:
> I only skimmed this, but ISTM that the use of proxy-require with a new 
> option will make this nearly undeployable.

Let me explain the proposal more clearly.  The critical point is that it
is an *upward-compatible* way of sending simultaneous requests while
eliminating merged requests.  This is important for supporting Happy
Eyeballs with minimal delays to destinations that a device does not
maintain flows with.

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, with particular
modifications to support merged requests:

    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>

The "group" parameter in the Route header indicates that this request is
part of a group.  The value of the group parameter indicates two
successive Via headers.  The branch parameter of the Via header indexed
by that value (counting from the bottom, starting with 1) indicates the
identity of this request within the group.  The branch parameter of the
next Via header down indicates the identity of the group.

If the target does not understand the group extension, it simply ignores
all these parameters.

In either case, the target deletes the Route header before forwarding
the request.

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

    INVITE sip:biloxi.example.com SIP/2.0
    Proxy-Require: group
----^^^^^^^^^^^^^^^^^^^^
    Route: <sip:[fd5a::0101]>;group=2
----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    Via: SIP/2.0/UDP [fd5a::1000];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>

This request is similar to the previous one, but it had a unique branch
parameter and includes "Proxy-Require: group".

If the second target (which is presumably the same devide as the first
target) does not implement the group extension, it rejects this request
with a 420 error.  The sending device will then postpone using this
target unless and 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 the group extension.

If the second target *does* implement the group 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).  Detecting whether or not another request has
already been processed is straightforward because it can search for an
ongoing transaction whose *second* branch parameter is the same as the
second branch parameter of this request.

If the second target processes this request, it deletes the the Route
header and the Proxy-Require header (per the specification of the
"group" extension) before forwarding the request.

This scheme has the advantage of minimizing the amount of state that the
devices need to maintain, which makes implementation much easier than,
say, SIP Outbound.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2016 12:35:32 -0500

Comment at end.

>      Route: <sip:10.5.0.10>;group=2

My concern is that *every* proxy on the path needs to support the 
'group' option for the second message to be successful. Not just the the 
one nearest the target. That makes it a high bar.

Otherwise what you describe does seem quite clever.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 02 Mar 2016 14:22:11 -0500

> one nearest the target. That makes it a high bar.

I believe that is not the case.  The Proxy-Require is inserted by the
sending device that we are describing, but it is *removed* by the
receiving device at the end of the hop.  At least, that's what I

> "group" extension) before forwarding the request.

Am I overlooking something?

>      Via: SIP/2.0/UDP [fd5a::1000];branch=z9hG4bKnashds8.2;group

When IPv6 addresses appear as the transport address in a Via header,
they do *not* appear inside [...].  [...] is only added when the IPv6
address appears as part of a SIP URI.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 14:41:58 -0500

> Am I overlooking something?

This assumes that the proxy that needs to do the merging is the next 
hop. Why is that the case? Couldn't there be intermediate proxies?

If that isn't a concern then I am less concerned.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 2 Mar 2016 14:58:13 -0500

Hi,

> When IPv6 addresses appear as the transport address in
> a Via header, they do *not* appear inside [...].
> [...] is only added when the IPv6 address appears as
> part of a SIP URI.

Using the brackets within Via's sent-by is correct; however the brackets
would not be added as part of Via's received parameter value.

The following ABNF is from RFC 3261 (some aspects were changed by RFC
5954).

Via               =  ( "Via" / "v" ) HCOLON via-parm *(COMMA via-parm)
via-parm          =  sent-protocol LWS sent-by *( SEMI via-params )
via-params        =  via-ttl / via-maddr
                     / via-received / via-branch
                     / via-extension
via-received      =  "received" EQUAL (IPv4address / IPv6address)
sent-by           =  host [ COLON port ]
host             =  hostname / IPv4address / IPv6reference
IPv6reference  =  "[" IPv6address "]"
IPv6address    =  hexpart [ ":" IPv4address ]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 Mar 2016 11:56:39 -0500

> would not be added as part of Via's received parameter value.

Argh, yes, my mistake.  (I forgot that sent-by is a *host*, not an
address.  Despite that many, many SIP devices can't handle a host name
for a sent-by.)

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 03 Mar 2016 12:13:50 -0500

> If that isn't a concern then I am less concerned.

I'm assuming that the Happy Eyeballs case is one where all of the target
addresses go to the same device, or to one of a set of tightly-coupled
devices.  In that sort of situation, the merging can be done at the
target(s), and the Proxy-Require device works.

Originally, I looked at the merging problem in the context of having
multiple routes to a distant destination, with intermediate proxies.
E.g., A wants to send two copies of a request to C, one copy via B1 and
one copy via B2.  The best solution I've found for that case is to send:

    Route: <sip:B1;lr>
    Route: <sip:C;lr>;group=2

    INVITE sip:biloxi.example.com SIP/2.0
    Route: <sip:B2;lr>
    Route: <sip:C;lr>;group=2
    Route: <sip:0.0.0.0;lr>
    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>

In this version of the mechanism, when either request arrives at C, it
sees the group parameter on its Route header, which notifies it to
examine the indicated Via headers.  If C does not support the group
mechanism, it does not know to ignore and delete the "Route:
<sip:0.0.0.0;lr>" header, so that copy of the request will error out.
If C does support the group mechanism, it deletes "Route:
<sip:0.0.0.0;lr>" and either responds 495 or routes the request to
bilozi.example.com.

In either version, the copies of the request have to be routed to a
merge point that can correlate all SIP requests that arrive and remove
duplicates.  I'm trying to figure out whether it's possible to remove
that restriction, and instead depend on/allow further downstream devices
to notice the group parameter on the Vias to detect pairs of requests
that come from different branches of a split.  If I am lucky (and I
don't think I am), this could all be put into the merged requests logic
for UASs.

Also, "lr" should be a header field parameter, not a URI parameter.  Too
late to change that, though.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 08 Mar 2016 14:11:04 -0500

> <sip:0.0.0.0;lr>" and either responds 495 or routes the request to

It looks like the proper thing to do is use a different address than
0.0.0.0.  I think we would want to allocate an address from the
192.0.0.0/24 special-purpose block (RFC 5735,
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1).
The next available address seems to be 192.0.0.10.  That changes the
example message to:

Probably the 10.0.0.0/24 addresses should be changed to one of the
documentation blocks, e.g., 192.0.2.0/24.

     INVITE sip:biloxi.example.com SIP/2.0
     Route: <sip:B2;lr>
     Route: <sip:C;lr>;group=2
     Route: <sip:192.0.0.10;lr>
     Via: SIP/2.0/UDP 192.0.2.10;branch=z9hG4bKnashds8.2;group
     Via: SIP/2.0/UDP 192.0.2.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>

Dale