Subject: [v6ops] Happy Eyeballs and SIP

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Mar 2011 10:40:20 +0100

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.

Regards,
/Olle

Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07

---

From: <[email-masked]>
Date: Mon, 7 Mar 2011 13:51:48 +0100

Dear Olle,

For the SIP case, if you don't need connectivity checks (e.g., closed networks, which is in France the majority of SIP traffic) you can just use the ALTC attribute defined in http://tools.ietf.org/html/draft-boucadair-mmusic-altc-01.

In case connectivity checks are needed, a variant of the happy eyeballs for SIP (called Happy Eardrums) has been proposed in http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but still you need to be sure you IPv4 connectivity is working ;-).

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Olle E. Johansson
Envoyé : lundi 7 mars 2011 10:40
À : [email-masked]
Objet : [v6ops] Happy Eyeballs and SIP

Hi!

Regards,
/Olle

Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Mar 2011 10:03:29 -0500

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

A 30-second timeout when starting an http connection isn't a good user experience either, so it could be argued that your objection is not SIP-specific… :)

---

From: Javier Ubillos <[email-masked]>
Date: Mon, 07 Mar 2011 16:37:00 +0100

> A 30-second timeout when starting an http connection isn't a good user experience either, so it could be argued that your objection is not SIP-specific… :)

Why are you guys discussing delays over 4s? The draft (IIRC) states
400ms as a maximum delay.

// Javier

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Mar 2011 07:37:21 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Olle E. Johansson
> Sent: Monday, March 07, 2011 1:40 AM
> To: [email-masked]
> Subject: [v6ops] Happy Eyeballs and SIP
> 
> Hi!
> 
> 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.

-d

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Mar 2011 20:58:54 +0100

> In case connectivity checks are needed, a variant of the happy eyeballs for SIP (called Happy Eardrums) has been proposed in http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but still…
Thanks for the reply! I will look into these documents to learn more. If I have any questions, is it ok to mail you?

Best regards,
/Olle

> Ref: http://tools.ietf.org/html/draft-ietf-sipping-v6-transition-07

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Mar 2011 21:06:11 +0100

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

Cheers,
/O

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Mar 2011 15:26:03 -0500

> As far as I know ICE handles media, but not the signalling. But I may be misunderstanding something.

You're right. Dual-stack for signalling is handled by sip-outbound.

This is a gold mine:
http://tools.ietf.org/html/draft-ietf-sipping-v6-transition

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Mar 2011 22:48:20 +0100

> http://tools.ietf.org/html/draft-ietf-sipping-v6-transition

SIP-outbound is between the UA and the first proxy/b2bua, right?

So if Edvina.net's proxy calls viagenie's proxy - can't we stumble on the same issue there?
My proxy can't handle open connections to all proxys I might be able to call... ;-)

Sorry for being persistant, but I have a feeling we're not done yet. I'd like to be convinced about the opposite :-)

So far, the responses I get on SIP/IPv6 migration point to Turn, SIP outbound and ICE. Most of the UA's and proxys I'm using haven't got that set of solutions. It will take time until we get there. Maybe IPv6 can add more pressure on developers to implement these new functions. I am afraid they will quickly install b2bua's or SBCs to handle the issue instead and then we're back two steps instead of moving forward...

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 7 Mar 2011 23:03:39 +0100

> For the SIP case, if you don't need connectivity checks (e.g., closed networks, which is in France the majority of SIP traffic) you can just use the ALTC attribute defined in http://tools.ietf.org/…
That is a simple fix for the media issue - and something I think developers can easily implement. We still have the issue with signalling and registrations.
> In case connectivity checks are needed, a variant of the happy eyeballs for SIP (called Happy Eardrums) has been proposed in http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but still…
Will look at this tomorrow... :-)

Thanks for the ALTC proposal. I am a bit hesitant to the ICE/TURN/SIP-outbound combo, it will take a long time to convince developers and the market to implement that package... 

/O

---

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Mar 2011 15:45:35 -0800

> From: Olle E. Johansson [mailto:[email-masked]]
> Sent: Monday, March 07, 2011 12:06 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [v6ops] Happy Eyeballs and SIP
> 
> 
> 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.

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

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 8 Mar 2011 07:58:30 +0100

> 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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Mar 2011 23:12:27 -0800

...
> That's good stuff, Dan.

I didn't write it, but we expect to get that into -01 of happy eyeballs.
Afterall, the problem is not confined to just HTTP clients.

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

That is relying on the matching Call-IDs to be perceived as a 
simple re-transmit by the receiving side.  I imagine most of 
the time one of them would be discarded, but we really want
"the right one" to be discarded -- presumably, the IPv4 one
should be discarded (assuming it went through a NAT44 or NAT64,
consuming state).

This is something we should bring over to one of the SIP working 
groups, probably SIPCORE, to consider.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Mar 2011 23:53:51 -0800

> Sent: Monday, March 07, 2011 2:04 PM
> To: [email-masked]
> Cc: [email-masked]
> > For the SIP case, if you don't need connectivity checks (e.g., closed
> networks, which is in France the majority of SIP traffic) you can just
> use the ALTC attribute defined in http://tools.ietf.org/html/draft-
> boucadair-mmusic-altc-01.
> That is a simple fix for the media issue - and something I think
> developers can easily implement. We still have the issue with
> signalling and registrations.
> >
> > In case connectivity checks are needed, a variant of the happy
> eyeballs for SIP (called Happy Eardrums) has been proposed in
> http://tools.ietf.org/html/draft-wing-dispatch-v6-migration-00 but
> still you need to be sure you IPv4 connectivity is working ;-).
> Thanks for the ALTC proposal. I am a bit hesitant to the ICE/TURN/SIP-
> outbound combo, it will take a long time to convince developers and the
> market to implement that package...

I agree that ICE is a big pill to swallow.  (If we're talking only
IPv4/IPv6 selection, though, TURN is not part of that equation.)

However, industry experience with IPv6 on the Internet shows that
we cannot rely on the "we both have an IPv6 address, therefore we
have connectivty" assumption.  There are IPv6 islands (on purpose
or on accident) which are permanent or temporary (failure of a 
link or a router), and because IPv4 is predominant the IPv6 failure
is not immediately noticed or corrected -- but impacts users
that support IPv6.

-d

> > IMPORTANT.Les informations contenues dans ce message electronique y
> compris les fichiers attaches sont strictement confidentielles
> > Si vous avez recu ce message par erreur ou s il ne vous est pas
> destine, veuillez immediatement le signaler  a l expediteur et effacer
> ce message
> > A ce titre, le Groupe France Telecom decline toute responsabilite
> notamment s il a ete altere, deforme ou falsifie.
> > IMPORTANT.This e-mail message and any attachments are strictly
> confidential and may be protected by law. This message is
> > If you have received this message in error, or are not the named
> recipient(s), please immediately notify the sender and delete this e-
> mail message.
> > Since e-mail messages may not be reliable, France Telecom Group shall
> not be liable for any message if modified, changed or falsified.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 8 Mar 2011 10:55:53 +0100

> groups, probably SIPCORE, to consider.

I would say that it's up to the UA and not the server to discard. The server needs to handle it  as a normal retransmit and respond.

Agree that we need to take it over to the SIP side. Thanks all for answering and participating!

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 8 Mar 2011 10:58:42 +0100

> IPv4/IPv6 selection, though, TURN is not part of that equation.)
Turn is part of the whole IPv6 migration scenario according to the soon-to-become-RFC.
> is not immediately noticed or corrected -- but impacts users
Fully agree - that's why I'm insisting on the happy eyeballs approach :-)

More info about IPv6 and SIP on http://edvina.net/sipv6 and http://www.facebook.com/sipv6 for those who wants to follow, help or point out my mistakes in thoughts! I appreciate all feedback.

Cheers
/O

---

---

From: <[email-masked]>
Date: Tue, 8 Mar 2011 11:12:38 +0100

Dear Olle,

Thank you for the link.

You might mention also the following:

* IPv6 IP ABNF is not correct. Rules defined in RFC3986 should be used instead for encoding IPv6 address in SIP URI.
* For the comparison of SIP URIs enclosing an IPv6 address, the rules defined in RFC3261 are broken; you need use those in RFC5954
* SIP Proxy Servers can not rely on the AoC to determine the IP capabilities of the SIP UA. A candidate solution is documented in http://tools.ietf.org/html/draft-boucadair-dispatch-ipv6-atypes-00.
* IPv6 SIP Torture Tests are documented in RFC5118. 

For other points, we can discuss this offline.

Cheers,
Med 

-----Message d'origine-----
De : Olle E. Johansson [mailto:[email-masked]] 
Envoyé : mardi 8 mars 2011 10:59
À : Dan Wing
Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Objet : Re: [v6ops] Happy Eyeballs and SIP

Cheers
/O

---

---

From: Tom Taylor <[email-masked]>
Date: Sun, 13 Mar 2011 19:11:01 -0400

Mind, altc has been rejected by RAI area. The official solution is to 
use ICE or ICE Lite.

On 07/03/2011 7:51 AM, [email-masked] wrote:
> networks, which is in France the majority of SIP traffic) you can
> just use the ALTC attribute defined in
> http://tools.ietf.org/html/draft-boucadair-mmusic-altc-01.
>
> Cheers, Med
> -----Message d'origine----- De : [email-masked]
> [mailto:[email-masked]] De la part de Olle E. Johansson
> Envoyé : lundi 7 mars 2011 10:40 À : [email-masked] Objet : [v6ops]
> Happy Eyeballs and SIP
>
> Hi!
>
> 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)
>
> Regards, /Olle
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> et peuvent etre protegees par la loi. Ce message electronique est
> destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
> destine, veuillez immediatement le signaler  a l expediteur et
> effacer ce message et tous les fichiers eventuellement attaches.
> Toute lecture, exploitation ou transmission des informations
> contenues dans ce message est interdite. Tout message electronique
> est susceptible d alteration. A ce titre, le Groupe France Telecom
> decline toute responsabilite notamment s il a ete altere, deforme ou
> falsifie. De meme, il appartient au destinataire de s assurer de l
> absence de tout virus.
>
> confidential and may be protected by law. This message is intended
> only for the named recipient(s) above. If you have received this
> message in error, or are not the named recipient(s), please
> immediately notify the sender and delete this e-mail message. Any
> unauthorized view, usage or disclosure ofthis message is prohibited.
>  _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: <[email-masked]>
Date: Mon, 14 Mar 2011 10:54:06 +0100

Dear Tom,

To be more accurate, there is no formal decision as a result of the discussion related to this topic (available at: http://www.ietf.org/mail-archive/web/mmusic/current/msg07958.html).

Cheers,
Med