Re: [sipcore] Happy Eyeballs for SIP

["Olle E. Johansson" <[e-mail]>]

> On 15 Feb 2016, at 20:50, Jonathan Lennox <[e-mail]> wrote:
> 
> 
>> On Feb 12, 2016, at 5:10 PM, Olle E. Johansson <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> On 12 Feb 2016, at 20:58, Dale R. Worley <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Is anyone considering writing up the actual use of Happy Eyeballs in a
>>> SIP context?
>>> 
>>> Does anyone have any practical experience or suggestions for what HE in
>>> SIP would be?
>> 
>> After discussing this for many years with many people this is my conclusion:
>> 
>> For connection oriented protocols - just point to existing RFC for happy eyeballs.
>> 
>> For UDP we have no solution, period. The only way is to handle this in DNS SRV
>> and have separate priorities for IPv4 and IPv6 in the order the service likes.
>> This is why we have tested DNS SRV with dual stacks in many SIPits and written the draft about 
>> dual stack issues - many IPv4 only clients crashed or failed when the first SRV priority
>> did not have IPv4 addresses at all. They also crashed when IPv6 was in various headers,
>> as documented in https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-03 <https://tools.ietf.org/html/draft-klatsky-dispatch-ipv6-impact-ipv4-03>
> 
> Most of these problems are going to be true for TCP IPv6 too, aren’t they? Happy Eyeballs doesn’t make the problem worse.  If there are buggy implementations out there, this is something that you’re presumably either going to have to have the implementers fix, or else clean up with SBCs.
Oh yeah, these problems are for locating SIP servers, the stuff you do when you
build a list. It applies to all, but is critical for UDP.

> 
>> One has to remember that the IPv4 and IPv6 address for a dual stack server may lead
>> to different servers, thus sending a UDP message at the same time to both may cause
>> multiple transactions and all kinds of interesting side effects. (Hadriel Kaplan reminded
>> me of this).
>> 
>> So the documentation on Happy Eyeballs in sip is pretty short: Don’t try this with UDP.
>> Solve the problem another way. (in fact, move to TCP/TLS as soon as you can :-) )
>> 
>> If someone has a cool solution to this UDP issue - preferably without loosing one round trip -
>> I would be more than happy to hear it!
> 
> The “may lead to different servers” issue is under the control of the person setting up the SRV records for the SIP server, though.
Yes. The reason I brought it up is that many proposals for solving this for UDP has failed
on exactly that case.

> 
> So it should be possible, I think, to say that you can set up DNS records for UDP happy eyeballs only if either 1) you personally can handle merged request detection for all requests to a target, or 2) you are a pure 3261 proxy and also can guarantee that there are no B2BUAs (that modify From tag, Call-ID, or CSeq) or Gateways downstream of you.  If this is the case, then forking the SIP request to the v4 and v6 addresses would accomplish happy eyeballs.
> 
> I don’t know if this is a large enough subset of SIP environments to be interesting, though.
I personally don’t think we should go down that road. We end up in discussions about multiple edge proxies with SIP outbound and without outbound and a large number of variations to SIP platform architectures. There are so many ways one can fail, even though there is a possibility of finding something that works. We may write “there may be other solutions to this problem, but this is our recommendation” to avoid falling into that can of worms.

What we can state is that finding the fastest network path by using something like Happy Eyeballs connection testing does not work over UDP.  

To handle UDP and dual stack clients and servers, we need to use DNS or other configuration methods. For UDP without outbound, the server side manages preferences in DNS. For UDP using SIP outbound a discovery method for edge proxys may configure one IPv4 edge proxy and one IPv6 edge proxy. Using one service DNS name with A and AAAA records will lead to problems. Animals (including cute kittens) may be harmed.

/O :-)