Subject: [sipcore] Happy Eyeballs issues

From: [email-masked] (Dale R. Worley)
Date: Tue, 23 Feb 2016 12:08:13 -0500

It seems to me that there are two major issues to be discussed in
Happy Eyeballs for SIP:

1) The sender is allowed to contact the targets in a different order
than is specified by RFC 3263 (including simultaneously contacting
targets).

This decision can be based on (a) network diversity (if an IPv6
contact failed, it might be wise to try an IPv4 contact next) and (b)
the past history of contacting these targets.

To what degree should reordering be specified, and should it be
permitted/recommended/required?

2) Handling the potential for multiple copies of a request to arrive
at a destination via one or more of these strategies:

a) Enhance the merged requests logic to reliably detect and eliminate
duplicates.

b) Use only connection-based protocols, waiting for connection
establishment before sending a request.

c) Use OPTIONS to probe connectivity before sending a request.

Dale

---

From: Brett Tate <[email-masked]>
Date: Wed, 24 Feb 2016 10:42:58 -0500

Hi,

Concerning number 1, reordering should still be allowed based upon local
policy (RFC 3261 section 8.1.2) which might include availability (RFC 3263
section 2).  I currently don't have a strong opinion about discussing
reordering within the draft.  I assume that the draft would discuss or
reference some of the things mentioned within RFC 6555 section 4 with
potential SIP related adjustments.

Mid-dialog requests may also be a source of interoperability issues.  RFC
3261 is somewhat vague about detecting merged requests within dialog.
Thus some devices return 500 (or other failure response) instead of 482
during a merged request situation.  I don't recall if there are any
devices that allow merged requests to be processed without detecting
merged request and without rejecting the non-incremented cseq.

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of Dale R.
Worley
> Sent: Tuesday, February 23, 2016 12:08 PM
> To: [email-masked]
> Subject: [sipcore] Happy Eyeballs issues
>
> It seems to me that there are two major issues to be discussed in Happy
> Eyeballs for SIP:
>
than is
> specified by RFC 3263 (including simultaneously contacting targets).
>
> This decision can be based on (a) network diversity (if an IPv6 contact
> failed, it might be wise to try an IPv4 contact next) and (b) the past
> history of contacting these targets.
>
> 2) Handling the potential for multiple copies of a request to arrive at
a
> destination via one or more of these strategies:
>
establishment
> before sending a request.
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 26 Feb 2016 11:54:01 +0100

> On 23 Feb 2016, at 18:08, Dale R. Worley <[email-masked]> wrote:
> 
Does RFC 3263 really specify an order for *ONE* host that has
multiple address records?

> permitted/recommended/required?
Sorry, this text confused me. Are you using “contact” as “Contact:” header in SIP
or in the role of a target as a result of a DNS lookup?

> c) Use OPTIONS to probe connectivity before sending a request.
Which will delay a call much more… 

Let’s agree that we have a solution for connection-oriented protocols.

For UDP, should we really add proxy-merge stuff? Using SIP Outbound
lets a device discover working flows at registration time, then the calls
will not be delayed. It’s an existing solution that we just need to 
recommend. The other way is for the service to separate DNS SRV
records so there’s no dual stack hosts for UDP.

Adding new merge rules will take a long time. Using what we already have
is a faster move. :-)

We may have to look into some requirements in SIP outbound to make it
easier to swallow for developers, but that’s a different topic that I will try
to approach in a separate mail.

/O

---

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

> multiple address records?

If a host name has multiple A/AAAA records, then 3263 does not prescribe
an ordering.

> Sorry, this text confused me. Are you using "contact" as "Contact:" header in SIP

I meant "target address".

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 29 Feb 2016 17:44:54 +0100

> On 26 Feb 2016, at 22:26, Dale R. Worley <[email-masked]> wrote:
> 
Then we’re back to 2782. I discussed exactly this in the meeting with two
guys from the IETF DNS directorate. We concluded that 2782 is very open
for simultaneous connections, like Happy Eyeballs. It states that all addresses
found for a name (that you understand/support) shall be contacted before you move to the next name in your list,
not any order.

So we should be fine.

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