Re: [v6ops] Happy Eyeballs and SIP

["Dan Wing" <[e-mail]>]

> -----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?

-d