Que se passe-t-il lorsque quelqu’un essaie de vous rappeler sur FaceTime après que vous avez changé d’opérateur en profitant de la portabilité du numéro ? Rien. Enfin… ça ne fonctionne pas. Du moins ce fil de discussion, sur les forums d’Apple, le laisse-t-il à penser assez sérieusement. Le souci peut être (assez) facilement corrigé : Réglages > Général > Réinitialiser > Réinitialiser tous les réglages. C’est violent – de nombreux paramètres doivent être rétablis manuellement, comme les fonds d’écran (du lot, ce sont les moindres) – mais c’est efficace. Surtout, ces aléas laissent à penser qu’Apple a déployé, pour supporter FaceTime, un système pas très éloigné d’un authentique IMS. [Un article de la KB d'Apple évoque les éventuels soucis avec la portabilité du numéro]
Comme le détaille Lina Mroueh, dans un document d’avril 2006 dédié à l’étude des procédures d’enregistrement et d’établissement de session en IMS, la mise en relation de l’appelant et de l’appelé nécessite la connaissance d’un identifiant dit privé de l’appelé par une base de données dédiée (la HSS; l’équivalent dans l’IMS de la HLR des réseaux mobiles) au sein de l’IMS, base de donnée chargée de faire le lien entre identité(s) publique(s) de l’utilisateur (connu(es) de ses correspondants) et identité privée (unique, connue de l’IMS et du terminal de l’utilisateur). Las, seul un nouveau de type de carte SIM – l’ISIM (pour IMS Subscriber Identity Module) – est censé savoir générer et manipuler cette identité privée. Et, pour l’heure, avec nos terminaux 3G, nous nous contentons d’USIM. Mais voilà, rétro-compatiblité oblige, un IMS doit pouvoir se contenter de ce que lui donne une USIM. Du coup, il utilise l’IMSI, qui identifie un abonné sur un réseau GSM/UMTS et qui est stocké sur la carte SIM/USIM, en guise d’identifiant privé.
Et, justement, que se passe-t-il en cas de portage du numéro ? L’abonné conserve son numéro de téléphone mobile mais… change d’opérateur et, au passage, de carte à puce ainsi, donc, que d’IMSI. Si FaceTime s’appuie effectivement sur un IMS, il n’y retrouve plus ses ouailles : il cherche à joindre l’utilisateur par son numéro de téléphone mobile (une identité publique) mais, dans la base de données de l’IMS d’Apple, ce numéro est encore associé à l’ancien IMSI, celui de la carte USIM du précédent opérateur mobile… La mise en relation est impossible jusqu’à ce que le destinataire dont le numéro a été porté se ré-enregistre auprès de l’IMS d’Apple (en faisant croire à son iPhone que cela n’a jamais été le cas; donc en effaçant les réglages) pour lui fournir, au passage, son nouvel IMSI. Ce lien semble confirmé par l’expérience d’un utilisateur allemand, relatée sur les forums de discussion d’Apple, disposant de cartes SIM jumelles.
Accessoirement, cela expliquerait la rumeur selon laquelle « les serveurs d’Apple reçoivent des messages à chaque fois que deux personnes sont connectées via FaceTime » (des messages pouvant d’ailleurs n’être liés qu’à la connexion SIP entre correspondants). Et enfin qu’un SMS soit envoyé par l’iPhone 4 quelque part au Royaume-Uni (!) lors de l’activation de FaceTime; un processus qui permet à Apple d’obtenir un identifiant privé du terminal [un procédé dont je me demande d'ailleurs s'il n'est pas couvert par un brevet T-Mobile déposé en avril 2007 et publié en avril... 2010].
Un lien de parenté clair entre FaceTime et iChat

Merci à cet anonyme, collaborant à un obscur site Web nommé MacGé, pour la petite séance d'expérimentation avec FaceTime
Alors, avec FaceTime, Apple a-t-il largement anticipé la 4G, ou certains des travaux liés aux réseaux de téléphonie mobile de demain ont-ils simplement inspiré une partie de l’architecture de son service de vidéoconférence ? La question reste entière… mais le sujet suscite manifestement un certain intérêt. Et justement, tant Apple – indirectement – que l’examen des trames échangées lors d’une communication FaceTime indiquent un lien de parenté étroit entre le système de vidéo conférence de l’iPhone 4 et… iChat, de Mac OS X.
Tout d’abord, une partie de la signalisation associée à FaceTime semble reposer sur le protocole XMPP/Jabber : Apple recommande de laisser ouvert le port TCP 5223, utilisé par ce protocole, pour utiliser FaceTime derrière un pare-feu – en fait, il n’est utilisé que pour une séquence de push à partir de serveurs dédiés chez Apple.
Surtout, le User-Agent déclaré lors d’un appel FaceTime (et dans toutes les échanges SIP) est Viceroy 1.4/GK… Viceroy est le User-Agent d’iChat qui, accessoirement, utilise SIP les appels audio et vidéo. L’autre information à retirer de l’examen des trames échangées, c’est que, pour l’essentiel, les échanges entre l’iPhone 4 et les serveurs d’Apple pour l’établissement d’un appel Facetime se font en HTTP/HTTPS; une fois la communication établie, les échanges entre correspondants se font directement, avec SIP, sans intermédiaire (et ça marche très bien, y compris sur un NAT imbriqué dans un premier NAT !), et rien n’indique qu’ils soient chiffrés.


« Et enfin qu’un SMS soit envoyé par l’iPhone 4 quelque part au Royaume-Uni (!) lors de l’activation de FaceTime »
L’iphone recois, et non pas envois un SMS.. ca change la donne
@Michael : l’iPhone commence par en envoyer un, semble-t-il : http://www.macbidouille.com/news/2010/06/25/facetime-et-sms
http://www.reddit.com/r/apple/comments/cj20w/so_it_turns_out_you_need_text_messaging_to_use/
Après, il en reçoit un.
>L’autre information à retirer de l’examen des trames échangées, c’est que,
>pour l’essentiel, les échanges entre l’iPhone 4 et les serveurs d’Apple pour
> l’établissement d’un appel Facetime se font en HTTP/HTTPS; une fois la
> communication établie, les échanges entre correspondants se font
> directement, avec SIP, sans intermédiaire (et ça marche très bien, y compris
> sur un NAT imbriqué dans un premier NAT !), et rien n’indique qu’ils soient
>chiffrés.
Bonjour, il faut relire le classiques avant de se lancer dans les analyse.
1) SIP ne fait que etablir une session, il gère pas les échange une fois la connections établie. Donc, no, les échanges entre correspondant se font pas directement avec SIP, jamais.
2) SIP tourne dans un server, toujour. Probablement, dans ces cas, chez Apple.
3) SIP utilise HTTP/HTTPS comme transport, donc les trames échangés en HTTP/HTTPS que vous avez observé entre le iPhone et Apple sont probablement des échanges SIP.
4) Si vous avez des actions Skype, il est le moment de le vendre. (je rigole).
Bappo
Attention: l’article de KB Apple donne une solution qui ne comporte pas
la réinitialisation du iPhone.
l’article de la KB suggère la réinitialisation, vers la fin – « if you are still experiencing trouble… »
@Bappo: désolé pour l’abus de langage concernant SIP – nous sommes bien d’accord, il n’est là que pour permettre l’établissement de la communication. Néanmoins, vous vous trompez sur un point : SIP n’utilise pas HTTP/HTTPS « comme transport »… je vous invite à retourner aux « classiques ».
Du coup, non, les trames échangées avec les serveurs Apple, en HTTP/HTTPS (essentiellement HTTPS, d’ailleurs, sur le très classique port TCP 443) n’ont rien à voir avec SIP. Sinon que ces échanges (auprès de serveurs Apple aux noms d’ailleurs assez explicites; vous en conviendrez après avoir examiné quelques trames dans le cadre d’une communication FaceTime) doivent permettre d’obtenir l’identifiant nécessaire à l’envoi de la requête SIP INVITE au destinataire.
Ou plutôt de lancer les requêtes STUN relatives à la gestion du NAT. SIP n’intervient qu’une fois que ces échanges sont terminés; c’est là que survient l’INVITE. Les échanges SIP se font là très classiquement. SDP intervient avec l’INVITE pour décrire les possibilités d’échange (codecs audio/video, mais pas trace de demande de chiffrement). On le retrouve dans le 200OK. D’après les attributs décrits via SDP à l’INVITE, différents niveaux de qualité audio seraient prévus, avec de l’AAC, du G.722, du PCM et de l’iLBC pour les codecs. Reste que, dans le 200OK, je n’ai pour l’instant vu que de l’AAC à 22kHz
Petite subtilité : les échanges SIP se font de pair à pair (et en clair); le passage par les serveurs d’Apple semble donc ne servir au terminal appelant que pour obtenir les informations nécessaires à l’entrée en relation avec le terminal destinataire. Pour mémoire, SIP n’a pas impérativement besoin d’une architecture centralisée pour fonctionner; surtout, les échanges capturés à coup de Wireshark montrent bien que les deux terminaux impliqués dans l’échange SIP communiquent directement l’un avec l’autre, sans intermédiaire. En particulier l’entête SIP Via ne fait aucune référence à une adresse IP autre que celle du correspondant initiateur de l’appel.
Après, la communication s’établit avec RTP/AVP (et RTCP pour la supervision de la qualité de la communication); toujours en pair-à-pair.
Accessoirement, je vous invite, pour en avoir le coeur net, à retourner sur les pages du blog d’Arjun, iConverged, qui continue de mener l’enquête sur FaceTime. Dans la foulée, j’ajoute une capture d’écran de Wireshark pour vous permettre de mieux vous rendre compte.