12. Usage with SIP (Utilisation avec SIP)
12.1. Latency Guidelines (Directives de latence)
ICE nécessite qu'une série de vérifications de connectivité basées sur STUN aient lieu entre les points de terminaison. Ces vérifications commencent à partir du répondeur lors de la génération de sa réponse, et commencent à partir de l'offrant lorsqu'il reçoit la réponse. Ces vérifications peuvent prendre du temps, et à ce titre, la sélection des messages à utiliser avec les offres et les réponses peut affecter la latence perçue par l'utilisateur. Deux chiffres de latence sont d'un intérêt particulier. Ce sont le délai après décrochage (post-pickup delay) et le délai après numérotation (post-dial delay). Le délai après décrochage fait référence au temps entre le moment où un utilisateur "décroche le téléphone" et le moment où toute parole qu'il prononce peut être transmise à l'appelant. Le délai après numérotation fait référence au temps entre le moment où un utilisateur entre l'adresse de destination pour l'utilisateur et le début du retour d'appel en conséquence du démarrage réussi de la sonnerie du téléphone de la partie appelée.
Deux cas peuvent être considérés -- un où l'offre est présente dans l'INVITE initial et un où elle est dans une réponse.
12.1.1. Offer in INVITE (Offre dans l'INVITE)
Pour réduire les délais après numérotation, il est RECOMMENDED que l'appelant commence à rassembler des candidats avant d'envoyer réellement son INVITE initial. Cela peut être démarré sur des signaux de l'interface utilisateur indiquant qu'un appel est en attente, tels qu'une activité sur un clavier ou le décrochage du téléphone.
Si une offre est reçue dans une requête INVITE, le répondeur SHOULD commencer à rassembler ses candidats à la réception de l'offre, puis générer une réponse dans une réponse provisoire une fois qu'il a terminé ce processus. ICE exige qu'une réponse provisoire avec un SDP soit transmise de manière fiable. Cela peut être fait via le mécanisme existant d'accusé de réception de réponse provisoire (PRACK) [RFC3262] ou via une optimisation spécifique à ICE. Avec cette optimisation, les réponses provisoires contenant une réponse SDP qui commence le traitement ICE pour un ou plusieurs flux multimédias peuvent être envoyées de manière fiable sans RFC 3262. Pour ce faire, l'agent retransmet la réponse provisoire avec les temporisateurs de recul exponentiel décrits dans la RFC 3262. Les retransmissions MUST cesser à la réception d'une requête STUN Binding pour l'un des flux multimédias signalés dans ce SDP (car la réception d'une requête Binding indique que l'offrant a reçu la réponse) ou à la transmission de la réponse dans une réponse 2xx. Si l'agent pair est lite, il n'y aura jamais de requête STUN Binding. Dans un tel cas, l'agent MUST cesser de retransmettre le 18x après l'avoir envoyé quatre fois (ICE fonctionnera réellement même si le pair ne reçoit jamais le 18x ; cependant, l'expérience a montré que son envoi est important pour les intermédiaires et la traversée de pare-feu). Si aucune requête Binding n'est reçue avant la dernière retransmission, l'agent ne considère pas la session comme terminée. Malgré le fait que la réponse provisoire sera livrée de manière fiable, les règles régissant le moment où un agent peut envoyer une offre ou une réponse mise à jour ne changent pas par rapport à celles spécifiées dans la RFC 3262. Plus précisément, si l'INVITE contenait une offre, la même réponse apparaît dans tous les 1xx et dans la réponse 2xx à l'INVITE. Ce n'est qu'après l'envoi de ce 2xx qu'un échange offre/réponse mis à jour peut avoir lieu. Cette optimisation SHOULD NOT être utilisée si les deux agents prennent en charge PRACK. Notez que l'optimisation est très spécifique aux réponses provisoires portant des réponses qui démarrent le traitement ICE ; ce n'est pas une technique générale pour la fiabilité 1xx.
Alternativement, un agent MAY retarder l'envoi d'une réponse jusqu'au 200 OK ; cependant, cela entraîne une mauvaise expérience utilisateur et est NOT RECOMMENDED.
Une fois la réponse envoyée, l'agent SHOULD commencer ses vérifications de connectivité. Une fois que les paires de candidats pour chaque composant d'un flux multimédia entrent dans la liste valide, le répondeur peut commencer à envoyer des médias sur ce flux multimédia.
Cependant, avant ce point, tout média devant être envoyé vers l'appelant (tel que le SIP early media [RFC3960]) MUST NOT être transmis. Pour cette raison, les implémentations SHOULD retarder l'alerte de la partie appelée jusqu'à ce que les candidats pour chaque composant de chaque flux multimédia soient entrés dans la liste valide. Dans le cas d'une passerelle PSTN, cela signifierait que le message d'établissement dans le PSTN est retardé jusqu'à ce point. Cela augmente le délai après numérotation, mais a pour effet d'éliminer les "sonneries fantômes". Les sonneries fantômes sont des cas où la partie appelée entend le téléphone sonner, décroche, mais n'entend rien et ne peut pas être entendue. Cette technique fonctionne sans nécessiter de prise en charge ou d'utilisation de préconditions [RFC3312], car c'est une décision localisée. Elle a également l'avantage de garantir qu'aucun paquet de média ne sera coupé, de sorte que le délai après décrochage est nul. Si un agent choisit de retarder l'alerte locale de cette manière, il SHOULD générer une réponse 180 une fois que l'alerte commence.
12.1.2. Offer in Response (Offre dans la réponse)
En plus des utilisations où l'offre est dans un INVITE et la réponse dans la réponse provisoire et/ou 200 OK, ICE fonctionne avec des cas où l'offre apparaît dans la réponse. Dans de tels cas, qui sont courants dans le contrôle d'appel tiers [RFC3725], les agents ICE SHOULD générer leurs offres dans une réponse provisoire fiable (qui MUST utiliser la RFC 3262), et ne pas alerter l'utilisateur à la réception de l'INVITE. La réponse arrivera dans un PRACK. Cela permet au traitement ICE d'avoir lieu avant l'alerte, de sorte qu'il n'y a pas de délai après décrochage, au prix de délais d'établissement d'appel accrus. Une fois ICE terminé, l'appelé peut alerter l'utilisateur puis générer un 200 OK lorsqu'il répond. Le 200 OK ne contiendrait aucun SDP, car l'échange offre/réponse est terminé.
Alternativement, les agents MAY placer l'offre dans un 2xx à la place (auquel cas la réponse vient dans l'ACK). Lorsque cela se produit, l'appelé alertera l'utilisateur à la réception de l'INVITE, et les échanges ICE n'auront lieu qu'après la réponse de l'utilisateur. Cela a pour effet de réduire le délai d'établissement d'appel, mais peut entraîner des délais après décrochage substantiels et une coupure des médias.
12.2. SIP Option Tags and Media Feature Tags (Balises d'option SIP et balises de fonctionnalité multimédia)
La [RFC5768] spécifie une balise d'option SIP et une balise de fonctionnalité multimédia pour une utilisation avec ICE. Les implémentations ICE utilisant SIP SHOULD prendre en charge cette spécification, qui utilise une balise de fonctionnalité dans les enregistrements pour faciliter l'interopérabilité via des intermédiaires de signalisation.
12.3. Interactions with Forking (Interactions avec le forking)
ICE interagit très bien avec le forking. En effet, ICE résout certains des problèmes associés au forking. Sans ICE, lorsqu'un appel fourche et que l'appelant reçoit plusieurs flux multimédias entrants, il ne peut pas déterminer quel flux multimédia correspond à quel appelé.
Avec ICE, ce problème est résolu. Les vérifications de connectivité qui ont lieu avant la transmission des médias portent des fragments de nom d'utilisateur, qui sont à leur tour corrélés à un appelé spécifique. Les paquets multimédias ultérieurs qui arrivent sur la même paire de candidats que la vérification de connectivité seront associés à ce même appelé. Ainsi, l'appelant peut effectuer cette corrélation tant qu'il a reçu une réponse.
12.4. Interactions with Preconditions (Interactions avec les préconditions)
Les préconditions de qualité de service (QoS), qui sont définies dans la RFC 3312 [RFC3312] et la RFC 4032 [RFC4032], s'appliquent uniquement aux adresses de transport répertoriées comme cibles par défaut pour les médias dans une offre/réponse.
Si ICE modifie l'adresse de transport où les médias sont reçus, ce changement est reflété dans une offre mise à jour qui modifie la destination par défaut des médias pour correspondre à la sélection d'ICE. À ce titre, cela apparaît comme n'importe quel autre ré-INVITE, et est entièrement traité dans les RFC 3312 et 4032, qui s'appliquent sans tenir compte du fait que la destination des médias change en raison des négociations ICE se produisant "en arrière-plan".
En effet, un agent SHOULD NOT indiquer que les préconditions de QoS ont été remplies tant que les vérifications ne sont pas terminées et n'ont pas sélectionné les paires de candidats à utiliser pour les médias.
ICE a également des interactions (intentionnelles) avec les préconditions de connectivité [SDP-PRECON]. Ces interactions y sont décrites. Notez que les procédures décrites dans la section 12.1 décrivent leur propre type de "préconditions", bien qu'avec moins de fonctionnalités que celles fournies par les préconditions explicites dans [SDP-PRECON].
12.5. Interactions with Third Party Call Control (Interactions avec le contrôle d'appel tiers)
ICE fonctionne avec les flux I, III et IV tels que décrits dans [RFC3725]. Le flux I fonctionne sans que le contrôleur prenne en charge ou soit conscient d'ICE. Le flux IV fonctionnera tant que le contrôleur transmet les attributs ICE sans modification. Le flux II est fondamentalement incompatible avec ICE ; chaque agent se croira être le répondeur et ne générera donc jamais de ré-INVITE.
Les flux pour une opération continue, tels que décrits dans la section 7 de la RFC 3725, nécessitent un comportement supplémentaire des implémentations ICE pour être pris en charge. En particulier, si un agent reçoit un ré-INVITE en milieu de dialogue qui ne contient aucune offre, il MUST redémarrer ICE pour chaque flux multimédia et passer par le processus de collecte de nouveaux candidats. De plus, cette liste de candidats SHOULD inclure ceux actuellement utilisés pour les médias.