Re: [v6ops] Happy Eyeballs and SIP

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

8 mar 2011 kl. 00.45 skrev Dan Wing:

>> -----Original Message-----
>> From: Olle E. Johansson [mailto:[e-mail]]
>> Sent: Monday, March 07, 2011 12:06 PM
>> To: Dan Wing
>> Cc: [e-mail]
>> Subject: Re: [v6ops] Happy Eyeballs and SIP
>> 
>> 
>> 7 mar 2011 kl. 16.37 skrev Dan Wing:
>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf
>>>> Of Olle E. Johansson
>>>> Sent: Monday, March 07, 2011 1:40 AM
>>>> To: [e-mail]
>>>> Subject: [v6ops] Happy Eyeballs and SIP
>>>> 
>>>> Hi!
>>>> 
>>>> Has anyone considered the issues covered in the happy-eyeballs draft
>>>> for SIP?
>>>> 
>>>> A 19 or 32 second time out when placing a call is not a good user
>>>> experience... I think this applies to SIP over TCP, and possibly
>> also
>>>> needs to be handled for UDP.
>>>> I don't see this handled in the draft for IPv6 transition in the
>>>> Session Initiation Protocol (soon-to-be RFC 6157)
>>>> 
>>>> Seems like the scope of the happy eyeballs draft is HTTP, so the
>>>> question is if this should be expanded or if we need other drafts
>> for
>>>> other protocols.
>>> 
>>> ICE (RFC5245) resolves the problem perfectly, and is the plan-of-
>> record for
>>> how to support the transition to IPv6 for SIP
>>> (draft-ietf-sipping-v6-transition).  ICE does connectivity checks, so
>> it
>>> figures out if IPv4 or IPv6 (or UDP, or TCP) is working between two
>> peers,
>>> and uses that path.  ICE can be performed while the phone is ringing,
>> so
>>> does not delay call set up.  ICE was one of the inspirations for
>> Happy
>>> Eyeballs.
>>> 
>>> There is resistance to ICE because of (a) its complexity and (b) a
>>> perception that "IPv6 works fine on my network", which has fostered
>> the
>>> creation of several other solutions, including an idea we nicknamed
>> "Happy
>>> Eardrums", draft-wing-dispatch-v6-migration, which we have since
>> abandoned.
>>> ICE does more, and it does a better job.
>> 
>> Thanks for the feedback.
>> 
>> Please tell me how Ice solves the issue of a phone calling a SIP domain
>> with both A and AAAA records for the first selected host.
>> The proxy or the UA will try to contact first over one connection, time
>> out after T1*64 and then maybe retry.
>> 
>> As far as I know ICE handles media, but not the signalling. But I may
>> be misunderstanding something.
> 
> You're right, ICE is just about media.  I didn't realize you were asking
> about SIP signaling -- most folks don't worry themselves with the SIP
> signaling.
> 
> Yes, we need to do Happy Eyeballs for the SIP signaling.  I have 
> engaged our internal XMPP experts for doing Happy Eyeballs with
> XMPP, which wants to avoid the delay to connect to your instant
> messaging server when you join a new network (e.g., open the 
> laptop).
> 
> I have text which we plan to incorporate into -01 which discusses
> how to do Happy Eyeballs with an SRV service, such as XMPP.  This
> would apply equally to SIP, which also uses SRV (RFC3263).
> 
> Current outline is this:
> 
>    For the purposes of this section, "client" is defined as the
>    entity initiating the connection.
> 
>    For protocols which support DNS SRV[xxxx], the client
>    performs the IN SRV query (e.g. IN SRV
>    _xmpp-client._tcp.example.com) as normal.  The client MUST
>    perform the following steps:
> 
>    1. Sort all SRV records according to priority (lowest
>       priority first)
>    2. Process all of the SRV targets of the same priority with a
>       weight greater than 0:
>    2.1. Perform A/AAAA queries for each SRV target in parallel,
>         as described in [SECTION x.1.]
>    2.2. Connect to the IPv4/IPv6 addresses
>    2.3. If at least one connection succeeds, stop processing
>         SRV records
>    3. If there is no connection, process all of the SRV targets
>       of the same priority with a weight of 0, as per steps 2.1
>       through 2.3 above
>    4. Repeat steps 2.1 through 2.3 for the next priority,
>       until a connection is established or all SRV records
>       have been exhausted
>    5. If there is still no connection, fallback to using
>       the domain (e.g. example.com), following steps 2.1
>       through 2.3 above
> 
>    It is RECOMMENDED, but not required, for the client to
>    cache the winning connection's address information and
>    reuse it on subsequent connections. If a significant
>    network event occurs (e.g. network interface is
>    activated/deactivated, IP address changes), the client MUST
>    forget the cached address information and perform all of
>    the steps from above. The definition of "significant
>    network event" is intentionally vague.
> 
> I believe that's the sort of thing you're looking for?
> 

That's good stuff, Dan. I will look through it and come back after I cleared my thoughts. I've been discussing using SRV for showing my preference of address family, which impacts also single stack clients. Your algorithm seems to work there too. The question in that case is that some UAs fail the connection attempt if they can't find records matching their address family for the top priority SRV records - they do not proceed to the next level.

In SIP we also have UDP, which is a different issue that requires a solution.

If I transmit two UDP messages - one over IPv4 and one over IPv6, hopefully the other side gets both and sees one as a simple retransmit.
The UA will get one or two answers and stick with the one that responded first and just forget the other one. I don't see an issue with this
behaviour from the server side - do you?

Regards,
/O