Groupe de travail Réseau	R. Sparks, Tekelec	
Request for Comments : 5589	A. Johnston, Ed.,Avaya	
BCP 149	D. Petrie, SIPez LLC	
Catégorie : Bonne pratiques actuelles		
Traduction Claude Brière de L'Isle	juin 2009	

Contrôle du transfert d'appel 
dans le protocole d'initialisation de session (SIP)

Statut de ce mémoire
Le présent document spécifie les bonnes pratiques actuelles de l'Internet pour la communauté de l'Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.
(La présente traduction incorpore les trois errata existants au 4/05/2020)

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de relire ces documents avec attention, car ils décrivent vos droits et obligations par rapport au présent document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent document décrit la fourniture des capacités de transfert d'appel dans le protocole d'initialisation de session (SIP, Session Initiation Protocol). Les extensions à SIP telles que REFER et Replaces sont utilisées pour fournir un certain nombre de services de transfert incluant le transfert aveugle, le transfert consultatif, et le transfert de participation. Le présent travail fait partie du cadre de commande d'appel SIP multipartie.
Table des matières
1. Généralités	2
2. Acteurs et rôles	2
3. Terminologie	2
4. Exigences	3
5. Utilisation de REFER pour réaliser un transfert d'appel	3
6. Transfert de base	4
6.1 Transfert réussi	4
6.2 Transfert avec réutilisation de dialogue	6
6.3 Échec de transfert	9
7. Transfert avec garde en consultation	10
7.1 Exposition de la cible du transfert	10
7.2 Protection de la cible du transfert	11
7.3 Transfert à participation	14
7.4. Récupération quand une des parties ne prend pas en charge REFER	16
7.5 Transfert avec participation quand l'URI Contact n'est pas connu pour acheminer sur un seul agent d'utilisateur	16
7.6 Transfert à semi participation	21
7.7 Repli de transfert à participation à un transfert de base	24
8. Transfert avec Referred-By	25
9. Transfert comme conférence ad hoc	28
10. Transfert avec plusieurs parties	30
11. Problèmes de transfert de passerelles	31
11.1 Contraindre des passerelles en épingle à cheveux à la même passerelle	31
11.2 Cas de l'éblouissement de passerelle consultative qui la rend aveugle	32
12. Considérations sur la sécurité	32
13. Remerciements	32
14. Références	32
14.1 Références normatives	32
14.2 Références pour information	33
Adresse des auteurs	33

 	1.	Généralités

Le présent document décrit la fourniture des capacités de transfert d'appel et ses exigences dans SIP [RFC3261]. Ce travail fait partie du cadre de commande d'appel multiparties [RFC5850].

Les mécanismes discutés ici sont en relation très étroite avec les transferts traditionnels, de base, et de garde pour consultation.

Le présent document détaille l'utilisation de la méthode REFER [RFC3515] et du champ d'en-tête Replaces [RFC3891] pour réaliser le transfert d'appel.

Un agent d'utilisateur (UA, agent d'utilisateur) qui prend pleinement en charge les mécanismes de transfert décrits dans le présent document prend en charge REFER [RFC3515] et Replaces [RFC3891] en plus de la [RFC3261]. Un agent d'utilisateur devrait utiliser un URI Contact pour satisfaire aux exigences du paragraphe 8.1.1.8 de la RFC 3261. Un agent d'utilisateur conforme prend en charge le champ d'en-tête Target-Dialog [RFC4538].

 	2.	Acteurs et rôles

Il y a trois acteurs dans un événement de transfert donné, dont chacun joue un des rôles suivants :

Transféré : la partie qui est transférée à la cible du transfert.

Transféreur : la partie qui initie le transfert.

Cible du transfert : la nouvelle partie introduite dans un appel avec le transféré.

Les rôles suivants sont utilisés pour décrire les exigences et scénarios de transfert :

Générateur : il souhaite passer un appel au receveur. Cet acteur est la source du premier INVITE d'une session, adressé à un facilitateur ou à un visionneur.

Facilitateur : reçoit un appel ou demande hors bande du générateur, établit un appel au réceveur à travers le visionneur, et connecte le générateur au receveur. Normalement, un facilitateur agit au nom du générateur.

Visionneur : reçoit un appel dont la destination ultime est le receveur et transfère l'appelant au receveur si approprié. Normalement, un visionneur agit au nom du receveur.

Receveur : la partie à laquelle le générateur est finalement connecté.

 	3.	Terminologie

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

 	4.	Exigences

1.	Toute partie à une session SIP doit être capable de transférer toute autre partie à cette session à tout moment de cette session.

2.	Le transféreur et le transféré ne doivent pas être retirés d'une session au titre d'une transaction de transfert. À première vue, l'exigence 2 peut sembler indiquer que l'expérience de l'utilisateur dans un transfert doit être significativement différente de ce qu'un utilisateur habituel de commutateur privé (PBX) ou de centrex attend. Comme le montrent les flux d'appels dans ce document, ce n'est pas le cas. Un client peut conserver l'expérience courante. En fait, sans cette exigence, certaines formes de l'expérience courante (sonnerie de rappel à l'échec du transfert, par exemple) seraient perdues.

3.	Le transféreur doit savoir si le transfert a réussi ou non.

4.	Le transféré doit être capable de remplacer un dialogue existant par un nouveau dialogue.

5.	Le transféreur et le transféré devraient indiquer leur prise en charge des primitives requises pour réaliser le transfert.

6.	Le transféreur devrait fournir à la cible du transfert et au transféré des informations sur la nature et les progrès de l'opération de transfert tentée. Pour satisfaire cette exigence, l'opération de transfert peut être modélisée comme une conférence ad hoc entre trois parties, comme expliqué à la Section 9.

 	5.	Utilisation de REFER pour réaliser un transfert d'appel

Un REFER [RFC3515] peut être produit par le transféreur pour causer la production d'un INVITE par le transféré à la cible du transfert. Noter que la réussite d'une transaction REFER ne termine pas la session entre le transféreur et le transféré. Si ces parties souhaitent terminer leur session, elles doivent le faire avec une demande BYE à la suite. Le support négocié entre le transféré et la cible du transfert n'est pas affecté par le support qui a été négocié entre le transféreur et le transféré. En particulier, le INVITE produit par le transféré aura le même corps de protocole de description de session (SDP, Session Description Protocol) que si le transféré avait initié cet INVITE de lui-même. De plus, la disposition des flux de supports entre le transféreur et le transféré n'est pas altérée par la méthode REFER.

Les agents peuvent altérer le support d'une session par une signalisation supplémentaire. Par exemple, ils peuvent utiliser les extensions SIP de garde de re-INVITE [RFC3261] ou de conférence décrites dans le cadre de conférence [RFC4353].

Pour effectuer le transfert, le transféreur et le transféré pourraient réutiliser un dialogue existant établi par un INVITE pour envoyer le REFER. Il en résulterait un seul dialogue partagé par deux utilisations -- un usage d'invite et un usage d'abonnement. Les flux d'appel pour cela sont montrés en détail au paragraphe 6.2. Cependant, l'approche décrite dans le présent document est d'éviter la réutilisation de dialogue. Le problème et les difficultés associés à la réutilisation de dialogue sont décrits dans la [RFC5057].

Les motifs de réutilisation du dialogue existant incluent :
1.	Il n'y a pas de moyen de s'assurer qu'un REFER sur un nouveau dialogue va atteindre le point d'extrémité particulier impliqué dans un transfert. De nombreux facteurs, incluant des détails de mise en œuvre et des changements d'acheminement de mandataires entre un INVITE et un REFER pourraient causer l'envoi du REFER au mauvais endroit. Envoyer le REFER le long du dialogue existant assure qu'il va bien au point d'extrémité auquel on est déjà en train de parler.
2.	La façon d'associer un usage invite existant à un REFER qui arrive sur un nouveau dialogue n'est pas claire, alors que ce qu'était l'association quand le REFER est arrivé sur le dialogue de l'usage d'INVITE était complètement évident.
3.	Il y a des problèmes avec l'autorisation de REFER hors dialogues. La politique d'autorisation pour REFER est dans la plupart des mises en œuvre portée sur la politique d'authorisation pour INVITE (qui est, dans la plupart des cas, fondée simplement sur "j'ai passé cet appel ou y ai répondu").

Les URI d'agent d'utilisateur mondialement acheminables (GRUU, Globally Routable UA URI) [RFC5627] peuvent être utilisés pour traiter le problème 1. Le problème 2 peut être traité en utilisant le champ d'en-tête Target-Dialog défini dans la [RFC4538].  Dans l'immédiat, cette solution du problème 2 permet à la politique d'autorisation de REFER existante d'être réutilisée par REFER (résolvant donc le problème 3).

Il en résulte que si le transféré prend en charge l'extension target-dialog et si le transféreur sait que l'URI Contact est acheminable en dehors du dialogue, le REFER DEVRAIT être envoyé dans un nouveau dialogue. Si la nature de l'URI Contact n'est pas connue ou si la prise en charge de l'extension target-dialog n'est pas connue, le REFER DEVRAIT être envoyé à l'intérieur du dialogue existant. Le transféré DOIT être prêt à recevoir un REFER soit à l'intérieur, soit à l'extérieur, d'un dialogue. Une façon dont un transféreur pourrait savoir qu'un URI Contact est acheminable en dehors d'un dialogue est par la validation (par exemple, l'envoi d'un OPTIONS et la réception de la réponse) ou si il satisfait aux propriétés décrites dans la spécification de GRUU [RFC5627].

Le présent document ne prescrit pas que les flux et les exemples soient précisément comme ils sont montrés, mais plutôt que les flux illustrent les principes des bonnes pratiques pour la caractéristique de transfert. Les flux d'appel représentent des exemples bien revus d'usage de SIP pour la mise en œuvre du transfert avec REFER, qui sont les bonnes pratiques actuelles selon le consensus de l'IETF.

Dans la plupart des exemples qui suivent, le transféreur est dans le domaine atlanta.exemple.com, le transféré dans biloxi.exemple.com, et la cible du transfert est dans le domaine chicago.exemple.com.

 	6.	Transfert de base

Le transfert de base consiste en ce que le transféreur fournisse le contact du transfert au transféré. Le transféré tente d'établir une session en utilisant ce contact et rapporte le résultat de cette tentative au transféreur. La relation de signalisation entre le transféreur et le transféré n'est pas terminée, de sorte que l'appel est récupérable si la cible du transfert ne peut pas être jointe. Noter que les informations de contact de la cible du transfert on été exposées au transféré. Le contact fourni peut être utilisé pour faire de nouveaux appels à l'avenir.

Les participants à un transfert de base DEVRAIENT indiquer la prise en charge des méthodes REFER et NOTIFY dans les champs d'en-tête Allow dans les messages INVITE, 200 OK à INVITE, et OPTIONS. Les participants DEVRAIENT aussi indiquer la prise en charge de Target-Dialog dans le champ d'en-tête Supported.

Les diagrammes ci-dessous montrent la première ligne de chaque message. La première colonne de la figure montre le dialogue utilisé dans ce message. Dans ces diagrammes, le support est géré par des prises de re-INVITE, mais d'autres mécanismes sont valides (mélant plusieurs flux de supports à l'UA ou utilisant les extensions de conférence, par exemple). Les détails de messages choisis sont montrés marqués comme message F1, F2, etc.

Chacun des flux ci-dessous montre le dialogue entre le transféreur et le transféré qui reste connecté (en garde) durant le processus REFER. Bien que cela donne la plus grande souplesse pour la récupération en cas de défaillance, ce n'est pas nécessaire. Si l'agent du transféreur ne souhaite pas participer au reste du processus REFER et n'a pas l'intention d'aider à la récupération en cas de défaillance du transfert, il pourrait émettre un BYE au transféré aussitôt que la transaction REFER s'achève. Ce flux est parfois appelé "transfert sans participation" ou "transfert aveugle".

La Figure 1 montre un transfert quand le transféré utilise un GRUU et prend en charge l'extension target-dialog et l'indique au transféreur. Par suite, le transféreur envoie le REFER en dehors du dialogue INVITE. Le transféré est capable de confronter le REFER au dialogue existant en utilisant le champ d'en-tête Target-Dialog dans le REFER qui fait référence au dialogue existant.

 	6.1	Transfert réussi
             Transféreur           Transféré         Cible du transfert
                  |          INVITE F1 |                    |
        dialogue1 |<-------------------|                    |
                  |          200 OK F2 |                    |
        dialogue1 |------------------->|                    |
                  |            ACK     |                    |
        dialogue1 |<-------------------|                    |
                  |  INVITE (garde)    |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |  ACK               |                    |
        dialogue1 |------------------->|                    |
                  |  REFER F3 (Cible-Dialogue:1)            |
        dialogue2 |------------------->|                    |
                  |  202 Accepté       |                    |
        dialogue2 |<-------------------|                    |
                  | NOTIFY (100 en essai) F4                |
        dialogue2 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue2 |------------------->|                    |
                  |                    |  INVITE F5         |
        dialogue3 |                    |------------------->|
                  |                    |  200 OK            |
        dialogue3 |                    |<-------------------|
                  |                    |  ACK               |
        dialogue3 |                    |------------------->|
                  |  NOTIFY (200 OK) F6|                    |
        dialogue2 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue2 |------------------->|                    |
                  |  BYE               |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |                    |             BYE    |
        dialogue3 |                    |<-------------------|
                  |                    |             200 OK |
        dialogue3 |                    |------------------->|

Figure 1 : Flux d'appels de transfert de base

F1 INVITE Transféré -> transféreur
INVITE sips:transferor@atlanta.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...

F2 200 OK Transféreur -> Transféré
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.exemple.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...

F3 REFER Transféreur -> Transféré
REFER sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
Refer-To: <sips:transfertarget@chicago.exemple.com>
Target-Dialog: 090459243588173445;local-tag=7553452;remote-tag=31kdl4i3k
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Length: 0

F4 NOTIFY Transféré -> Transféreur
NOTIFY sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...

SIP/2.0 100 Trying

F5 INVITE Transféré -> Cible du transfert
INVITE sips:transfertarget@chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
CSeq: 521 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...

F6 NOTIFY Transféré -> Transféreur
NOTIFY sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...

SIP/2.0 200 OK

 	6.2	Transfert avec réutilisation de dialogue
Dans ce scénario, le transféreur ne connaît pas les propriétés de l'URI Contact du transféré ou ne sait pas si le transféré prend en charge le champ d'en-tête Target-Dialog. Par suite, le REFER est envoyé à l'intérieur du dialogue INVITE.

            Transféreur           Transféré          Cible du transfert
                  |         INVITE F1  |                    |
        dialogue1 |<-------------------|                    |
                  |         200 OK F2  |                    |
        dialogue1 |------------------->|                    |
                  |            ACK     |                    |
        dialogue1 |<-------------------|                    |
                  |  INVITE (garde)    |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |  ACK               |                    |
        dialogue1 |------------------->|                    |
                  |  REFER F3          |                    |
        dialogue1 |------------------->|                    |
                  |  202 Accepté       |                    |
        dialogue1 |<-------------------|                    |
                  | NOTIFY (100 en essai) F4                |
        dialogue1 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue1 |------------------->|                    |
                  |                    |  INVITE F5         |
        dialogue2 |                    |------------------->|
                  |                    |  200 OK            |
        dialogue2 |                    |<-------------------|
                  |                    |  ACK               |
        dialogue2 |                    |------------------->|
                  |  NOTIFY (200 OK) F6|                    |
        dialogue1 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue1 |------------------->|                    |
                  |  BYE               |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |                    |             BYE    |
        dialogue2 |                    |<-------------------|
                  |                    |             200 OK |
        dialogue2 |                    |------------------->|

Figure 2 : Transfert avec réutilisation de dialogue

F1 INVITE Transféré -> Transféreur
INVITE sips:transferor@atlanta.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Content-Type: application/sdp
Content-Length: ...

F2 200 OK Transferor -> le transféré
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.exemple.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...

F3 REFER Transféreur -> Transféré
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:transferee@biloxi.exemple.com>;tag=7553452
From: <sips:transferor@atlanta.exemple.com>;tag=31kdl4i3k
Call-ID: 090459243588173445
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Refer-To: <sips:transfertarget@chicago.exemple.com>
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Length: 0

F4 NOTIFY Transféré -> Transféreur
NOTIFY sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29888 INVITE
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...

SIP/2.0 100 en essai

F5 INVITE Transféré -> cible du transfert
INVITE sips:transfertarget@chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
CSeq: 521 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Content-Type: application/sdp
Content-Length: ...

F6 NOTIFY Transféré -> Transféreur
NOTIFY sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29889 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...

SIP/2.0 200 OK

 	6.3	Échec de transfert
Ce paragraphe montre des exemples d'échecs de tentatives de transfert. Après l'échec du transfert, le transféreur relève le transféré de la mise en garde et reprend la session.

 	6.3.1	Cible occupée
            Transféreur           Transféré         Cible du transfert
                  |                    |                    |
                  |            INVITE  |                    |
        dialogue1 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue1 |------------------->|                    |
                  |            ACK     |                    |
        dialogue1 |<-------------------|                    |
                  |  INVITE (garde)    |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |  ACK               |                    |
        dialogue1 |------------------->|                    |
                  |  REFER (Cible-Dialogue:1)               |
        dialogue2 |------------------->|                    |
                  |  202 Accepté       |                    |
        dialogue2 |<-------------------|                    |
                  | NOTIFY (100 essai) |                    |
        dialogue2 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue2 |------------------->|                    |
                  |                    |  INVITE            |
        dialogue3 |                    |------------------->|
                  |                    |  486 Occupé ici    |
        dialogue3 |                    |<-------------------|
                  |                    |  ACK               |
        dialogue3 |                    |------------------->|
                  | NOTIFY (486 Occupé ici)                 |
        dialogue2 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue2 |------------------->|                    |
                  |  INVITE (unhold)   |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |  ACK               |                    |
        dialogue1 |------------------->|                    |
                  |  BYE               |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |

Figure 3 : Échec du transfert - cible occupée

 	6.3.2	La cible du transfert ne répond pas
             Transféreur           Transféré         Cible du transfert
                  |            INVITE  |                    |
        dialogue1 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue1 |------------------->|                    |
                  |            ACK     |                    |
        dialogue1 |<-------------------|                    |
                  |  INVITE (garde)    |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |  ACK               |                    |
        dialogue1 |------------------->|                    |
                  |  REFER             |                    |
        dialogue2 |------------------->|                    |
                  |  202 Accepté       |                    |
        dialogue2 |<-------------------|                    |
                  | NOTIFY (100 essai) |                    |
        dialogue2 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue2 |------------------->|                    |
                  |                    |  INVITE            |
        dialogue3 |                    |------------------->|
                  |                    |  180 Sonnerie      |
        dialogue3 |                    |<-------------------|
                  |          (le transféré se fatigue d'atttendre)
                  |                    |  CANCEL            |
        dialogue3 |                    |------------------->|
                  |                    |  200 OK (CANCEL)   |
        dialogue3 |                    |<-------------------|
                  |                 487 Demande annulée (INVITE)
        dialogue3 |                    |<-------------------|
                  |                    |  ACK               |
        dialogue3 |                    |------------------->|
                  |    NOTIFY (487 Demande annulée)         |
        dialogue2 |<-------------------|                    |
                  |            200 OK  |                    |
        dialogue2 |------------------->|                    |
                  |  INVITE (levée de garde)                |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |
                  |  ACK               |                    |
        dialogue1 |------------------->|                    |
                  |  BYE               |                    |
        dialogue1 |------------------->|                    |
                  |  200 OK            |                    |
        dialogue1 |<-------------------|                    |

Figure 4 : Échec de transfert - la cible ne répond pas

 	7.	Transfert avec garde en consultation

Le transfert avec garde en consultation implique une session entre le transféreur et la cible du transfert avant que le transfert ait réellement lieu. Ceci est mis en œuvre avec la mise en garde et le transfert SIP comme décrit ci-dessus.

Un bon dispositif pour le transféreur est de faire savoir à la cible que la session se destine à un transfert. Comme beaucoup d'UA donnent le nom d'affichage dans le champ d'en-tête From à l'utilisateur, une consultation INVITE pourrait contenir une chaîne disant "consultation entrante du transféreur avec l'intention de transférer le transféré", où les noms d'affichage du transféreur et du transféré sont inclus dans la chaîne.

 	7.1	Exposition de la cible du transfert
Le transféreur place le transféré en garde, établit un appel avec la cible du transfert pour les alerter du transfert qui est sur le point de se faire, termine la connexion avec la cible du transfert, puis procède au transfert comme ci-dessus. Cette variante peut être utilisée pour donner une expérience similaire à celle attendue par les utilisateurs courants de PABX et Centrex.
Pour améliorer (espérons le) la clarté de l'exposé, les transactions non REFER ont été concentrées dans un indicateur avec la flèche montrant la direction de la demande.

             Transféreur           Transféré         Cible du transfert
                  |                    |                    |
        dialogue1 | INVITE/200 OK/ACK  |                    |
                  |<-------------------|                    |
        dialogue1 | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
        dialogue2 | INVITE/200 OK/ACK  |                    |
                  |---------------------------------------->|
        dialogue2 | BYE/200 OK         |                    |
                  |---------------------------------------->|
        dialogue3 | REFER              |                    |
                  |------------------->|                    |
        dialogue3 | 202 Accepté        |                    |
                  |<-------------------|                    |
        dialogue3 | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
        dialogue3 |            200 OK  |                    |
                  |------------------->|                    |
        dialogue4 |                    |  INVITE/200 OK/ACK |
                  |                    |------------------->|
        dialogue3 | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
        dialogue3 |            200 OK  |                    |
                  |------------------->|                    |
        dialogue1 | BYE/200 OK         |                    |
                  |------------------->|                    |
        dialogue4 |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 5 : Transfert avec mise en garde pour consultation - exposant la cible du transfert
 	7.2	Protection de la cible du transfert
Le transféreur place le transféré en garde, établit un appel avec la cible du transfert et ensuite inverse les rôles, transférant la cible originale du transfert au transféré d'origine. Ceci présente l'avantage de cacher les informations sur la cible originale du transfert au transféré original. D'un autre côté, l'expérience du transféré est différente des systèmes courants. Le transféré est effectivement "rappelé" par la cible du transfert.

Un des problèmes de cette très simple mise en œuvre d'une cible qui protège le transfert est que le transféré reçoit un nouvel appel de la cible du transfert. Sauf si l'agent du transféré a une façon fiable d'associer ce nouvel appel à celui qu'il a déjà avec le transféreur, il va devoir alerter sur ce nouvel appel par une autre apparition. Si cela, ou quelque autre information non reconnue de style appel en attente, n'est pas disponible, le transféré peut se retrouver être obligé d'envoyer un "Occupé ici" à la cible du transfert, empêchant effectivement le transfert. Il y a de nombreuses façons de fournir cette corrélation. Les paramètres de dialogue pourraient être fournis directement comme paramètres d'en-tête dans l'URI Refer-To, par exemple. Le mécanisme Replaces [RFC3891] utilise cette approche et résoud élégamment ce problème.

Pour le flux ci-dessous, dialogue1 signifie identifiant de dialogue 1, et comporte les paramètres de l'en-tête Replaces pour le dialogue 1. Dans la [RFC3891], ce sont Call-ID, To-tag, et From-tag.

Noter que l'agent du transféré émet un BYE à l'agent du transféreur comme conséquence immédiate du traitement de l'en-tête Replaces.

Le transféreur sait que le transféré et la cible du transfert prennent tous deux en charge l'en-tête Replaces d'après l'en-tête de remplacement Supported: contenu dans la réponse 200 OK porvenant de l'un et l'autre.

Dans ce scénario, le transféré utilise un GRUU comme URI Contact pour les raisons exposées au paragraphe 6.3.

Noter que les conventions utilisées dans le document "Messages d'essais de résistance" [RFC4475] sont réutilisées, spécialement l'étiquette <allOneLine>.

             Transféreur           Transféré         Cible du transfert
                  |                    |                    |
      dialogue1   | INVITE/200 OK/ACK F1 F2                 |
                  |<-------------------|                    |
      dialogue1   | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
      dialogue2   | INVITE/200 OK/ACK F3 F4                 |
                  |---------------------------------------->|
      dialogue2   | INVITE (hold)/200 OK/ACK                |
                  |---------------------------------------->|
      dialogue3   | REFER (Cible-dialogue:2,                |
                  |  Refer-To:sips:transféré?Remplace=1) F5 |
                  |---------------------------------------->|
      dialogue3   | 202 Accepté        |                    |
                  |<----------------------------------------|
      dialogue3   | NOTIFY (100 essai) |                    |
                  |<----------------------------------------|
      dialogue3   |                    |            200 OK  |
                  |---------------------------------------->|
      dialogue4   | INVITE (Remplace:dialogue1)/200 OK/ACK F6
                  |                    |<-------------------|
      dialogue1   | BYE/200 OK         |                    |
                  |<-------------------|                    |
      dialogue3   | NOTIFY (200 OK)    |                    |
                  |<----------------------------------------|
      dialogue3   |                    |            200 OK  |
                  |---------------------------------------->|
      dialogue2   | BYE/200 OK         |                    |
                  |---------------------------------------->|
                  |  (le transféré et la cible conversent)  |
      dialogue4   |                    |  BYE/200 OK        |
                  |                    |------------------->|

Figure 6 : Transfert protégeant la cible du transfert

F1 INVITE Transféré -> Transféreur
INVITE sips:transferor@atlanta.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...

F2 200 OK Transféreur -> Transféré
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.exemple.com>;tag=31431
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...

F3 INVITE Transféreur -> Cible du transfert
INVITE sips:transfertarget@chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: replaces
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=384i32lw3>
Content-Type: application/sdp
Content-Length: ...

F4 200 OK Cible du transfert -> Transféreur
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnas432;received=192.0.2.1
To: <sips:transfertarget@chicago.exemple.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958>
Content-Type: application/sdp
Content-Length: ...

F5 REFER Transféreur -> Cible du transfert
REFER sips:482n4z24kdg@chicago.exemple.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958>
From: <sips:transferor@atlanta.exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
<allOneLine>
Refer-To: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha
?Replaces=090459243588173445%3Bto-tag%3D7553452%3Bfrom-tag%3D31431>
</allOneLine>
Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Length: 0

F6 INVITE Cible du transfert -> Transféré
INVITE sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS client.chicago.exemple.com;branch=z9hG4bKnaslu84
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
From: <sips:transfertarget@chicago.exemple.com>;tag=341234
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Contact: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958>
Replaces: 090459243588173445;to-tag=7553452;from-tag=31431
Content-Type: application/sdp
Content-Length: ...

 	7.3	Transfert à participation
Le transféreur place le transféré en garde, établit un appel avec la cible du transfert pour l'alerter du transfert imminent, place la cible en garde, puis procède au transfert en utilisant un champ d'en-tête Replaces avec échappement dans l'en-tête Refer-To. C'est un autre service couramment attendu des utilisateurs de PABX et Centrex.

L'URI Contact de la cible du transfert DEVRAIT être utilisé par le transféreur comme URI Refer-To, sauf si l'URI est suspect ou connu pour n'être pas acheminable en dehors du dialogue. Autrement, l'adresse d'enregistrement (AOR, Address Of Record) de la cible du transfert DEVRAIT être utilisée. C'est-à-dire qu'on devrait utiliser le même URI que le transféreur a utilisé pour établir la session avec la cible du transfert. Dans le cas où l'INVITE déclenché serait acheminé à un agent d'utilisateur différent de la cible du transfert, le champ d'en-tête Require: replaces DEVRAIT être utilisé dans l'INVITE déclenché. (C'est pour empêcher qu'un agent d'utilisateur incorrect qui ne prend pas en charge Replaces ignore les Replaces et réponde à l'INVITE sans une correspondance de dialogue.)

Il est possible que l'acheminement de mandataire/service puisse empêcher l'INVITE déclenché d'atteindre le même agent d'utilisateur. Si cela se produit, l'INVITE déclenché va échouer avec une erreur de fin de temporisation, 403, 404, etc.. Le transféré PEUT alors réessayer le transfert avec l'URI Refer-To réglé à l'URI Contact.

             Transféreur           Transféré         Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK F1 F2                 |
                  |<-------------------|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE/200 OK/ACK F3 F4                 |
                  |---------------------------------------->|
       dialogue2  | INVITE (garde)/200 OK/ACK               |
                  |---------------------------------------->|
       dialogue3  | REFER (Cible-dialogue:1,                |
                  | Refer-To:sips:TransferTarget?Replaces=2) F5
                  |------------------->|                    |
       dialogue3  | 202 Accepté        |                    |
                  |<-------------------|                    |
       dialogue3  | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue4  |        INVITE (Replaces:dialog2)/200 OK/ACK F6
                  |                    |------------------->|
       dialogue2  | BYE/200 OK         |                    |
                  |<----------------------------------------|
       dialogue3  | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue1  | BYE/200 OK         |                    |
                  |------------------->|                    |
       dialogue4  |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 7 : Flux d'appel de transfert à participation

F1 INVITE Transféré -> Transféreur
INVITE sips:transferor@atlanta.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...

F2 200 OK Transféreur -> Transféré
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
To: <sips:transferor@atlanta.exemple.com>;tag=31431
From: <sips:transferee@biloxi.exemple.com>;tag=7553452
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...

F3 INVITE Transféreur -> Cible du transfert
INVITE sips:transfertarget@chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: replaces
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=384i32lw3>
Content-Type: application/sdp
Content-Length: ...

F4 200 OK Cible du transfert -> Transféreur
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnas432;received=192.0.2.1
To: <sips:transfertarget@chicago.exemple.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 592435881734450904
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu
Contact: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958>
Content-Type: application/sdp
Content-Length: ...

F5 REFER Transféreur -> Transféré
REFER sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
Require: tdialog
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958?
Replaces=592435881734450904%3Bto-tag%3D9m2n3wq%3Bfrom-tag3D763231>
</allOneLine>
Target-Dialog: 090459243588173445;local-tag=7553452 ;remote-tag=31431
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Length: 0

F6 INVITE Transféré -> Cible du transfert
INVITE sips:482n4z24kdg@chicago.exemple.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958>
From: <sips:transferee@biloxi.exemple.com>;tag=954
Call-ID: kmzwdle3dl3d08
CSeq: 41 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Replaces: 592435881734450904;to-tag=9m2n3wq;from-tag=763231
Content-Type: application/sdp
Content-Length: ...

 	7.4.	Récupération quand une des parties ne prend pas en charge REFER
Si la protection ou l'exposition de la cible du transfert n'est pas un souci, il est possible de réaliser un transfert avec mise en garde de consultation quand seuls le transféreur et une des autres parties prennent en charge REFER. Noter qu'une réponse 405 "Méthode non admise" pourrait être retournée à la place de la réponse 501 "Non mis en œuvre".

             Transféreur           Transféré         Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK  |                    |
                  |<-------------------|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE/200 OK/ACK  |                    |
                  |---------------------------------------->|
       dialogue2  | INVITE (garde)/200 OK/ACK               |
                  |---------------------------------------->|
       dialogue3  | REFER (Cible-Dialogue:1,                |
                  |  Refer-To:sips:TransferTarget?Replaces=2)
                  |------------------->|                    |
       dialogue3  | 501 Non mis en œuvre                    |
                  |<-------------------|                    |
       dialogue4  | REFER (Refer-To:sips:transfered?Replaces=dialog1)
                  |---------------------------------------->|
       dialogue4  | 202 Accepté        |                    |
                  |<----------------------------------------|
       dialogue4  | NOTIFY (100 essai) |                    |
                  |<----------------------------------------|
       dialogue4  |                    |            200 OK  |
                  |---------------------------------------->|
       dialogue5  |             INVITE (Replaces:dialog1)/200 OK/ACK
                  |                    |<-------------------|
       dialogue4  | NOTIFY (200 OK)    |                    |
                  |<----------------------------------------|
       dialogue4  |                    |            200 OK  |
                  |---------------------------------------->|
       dialogue1  | BYE/200 OK         |                    |
                  |<-------------------|                    |
       dialogue2  | BYE/200 OK         |                    |
                  |---------------------------------------->|
       dialogue5  |                    |  BYE/200 OK        |
                  |                    |------------------->|

Figure 8 : Récupération quand une des parties ne prend pas en charge REFER

 	7.5	Transfert avec participation quand l'URI Contact n'est pas connu pour acheminer sur un seul agent d'utilisateur
C'est une exigence de la RFC 3261 qu'un URI Contact soit acheminble mondialement même en dehors du dialogue. Cependant, du fait des agents d'utilisateurs de la RFC 2543 et de certaines architectures (traversée de NAT/pare-feu, mandataires de visionnage, passerelles de couche application (ALG, Application Layer Gateway), etc.) ce ne sera pas toujours le cas. Il en résulte que la méthode du transfert avec participation montré aux figures 6, 7, et 8 NE DEVRAIT être utilisé QUE si l'URI Contact est connu comme étant acheminable en dehors du dialogue.

La Figure 9 montre un scénario où l'URI Contact de la cible du transfert n'est pas acheminable en dehors du dialogue, de sorte que l'INVITE déclenché est envoyé à l'AOR de la cible du transfert.

         Transféreur         Transféré    Mandataire      Cible du
              |                  |        visionneur     transfert
              |                  |             |             |
    dialogue1 | INVITE/200 OK/ACK|             |             |
              |<-----------------|             |             |
    dialogue1 | INVITE (garde)/200 OK/ACK      |             |
              |----------------->|             |             |
    dialogue2 | INVITE/200 OK/ACK F1 F2        |             |
              |--------------------------------|------------>|
    dialogue2 | INVITE (garde)/200 OK/ACK                    |
              |--------------------------------|------------>|
    dialogue1 | REFER (Refer-To:sips:TargetAOR               |
              |         ?Replaces=dialog2&Require=replaces) F3
              |----------------->|             |             |
    dialogue1 | 202 Accepté      |             |             |
              |<-----------------|             |             |
    dialogue1 | NOTIFY (100 essai)             |             |
              |<-----------------|             |             |
    dialogue1 |          200 OK  |             |             |
              |----------------->|             |             |
    dialogue4 |INVITE (Replaces:dialog2,Require:replaces)/200 OK/ACK F6
              |                  |------------>|------------>|
    dialogue2 | BYE/200 OK       |             |             |
              |<-------------------------------|<------------|
    dialogue1 | NOTIFY (200 OK) F7             |             |
              |<-----------------|             |             |
    dialogue1 |          200 OK  |             |             |
              |----------------->|             |             |
    dialogue1 | BYE/200 OK       |             |             |
              |----------------->|             |             |
    dialogue3 |                  |             |  BYE/200 OK |
              |                  |<------------|-------------|

Figure 9 : Flux d'appel de transfert averc participation avec un URI Contact non connu pour être mondialement acheminable

F1 INVITE Transféreur -> Cible du transfert
INVITE sips:transfertarget@chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bK76
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferor@pc33.atlanta.exemple.com>
Content-Type: application/sdp
Content-Length: ...

F2 200 OK Cible du transfert -> Transféré
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnas432;received=192.0.2.1
To: <sips:transfertarget@chicago.exemple.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transfertarget@client.chicago.exemple.com>
Content-Type: application/sdp
Content-Length: ...

F3 REFER Transféreur -> Transféré
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.exemple.com>;tag=a6c85cf
From: <sips:transferor@atlanta.exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:transfertarget@chicago.exemple.com?Replaces=
090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
<allOneLine>
Contact: <sips:transferor@pc33.atlanta.exemple.com>
Content-Length: 0

F4 INVITE Transféré -> Cible du transfert
INVITE sips:transfertarget@chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=954
Call-ID: 20482817324945934422930
CSeq: 42 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Require: replaces
Content-Type: application/sdp
Content-Length: ...

F5 NOTIFY Transféré -> Transféreur
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>;tag=1928301774
From: <sips:transferee@biloxi.exemple.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 76 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=98873867
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...

SIP/2.0 200 OK

La Figure 10 montre le cas d'une défaillance dans lequel l'URI AOR échoue à joindre la cible du transfert. Par suite, le transfert est réessayé avec l'URI Contact, et il réussit.

Noter qu'il n'est tout de même pas garanti que le point d'extrémité correct sera atteint, et le résultat de ce second REFER pourrait aussi échouer. Dans ce cas, le transféreur pourrait se replier sur un transfert sans participation ou abandonner entièrement le transfert. Comme deux REFER sont envoyés au sein du dialogue qui créé deux abonnements distincts, le transféré utilise le paramètre 'id' dans le champ d'en-tête Event pour distinguer les notifications pour les deux abonnements.

          Transféreur        Transféré     Mandataire     Cible du
              |                  |          visonneur     transfert
              |                  |             |             |
    dialogue1 | INVITE/200 OK/ACK|             |             |
              |<-----------------|             |             |
    dialogue1 | INVITE (garde)/200 OK/ACK      |             |
              |----------------->|             |             |
    dialogue2 | INVITE/200 OK/ACK F1 F2        |             |
              |--------------------------------|------------>|
    dialogue2 | INVITE (garde)/200 OK/ACK                    |
              |--------------------------------|------------>|
    dialogue1 | REFER (Refer-To:sips:TargetAOR?              |
              |       Replaces=dialog2&Require=replaces) F3  |
              |----------------->|             |             |
    dialogue1 | 202 Accepté      |             |             |
              |<-----------------|             |             |
    dialogue1 | NOTIFY (100 essai)             |             |
              |<-----------------|             |             |
    dialogue1 |          200 OK  |             |             |
              |----------------->|             |             |
    dialogue3 |                  |INVITE (Replaces:dialog2,  |
              |                  | Require:replaces)/403/ACK |
              |                  |------------>|             |
    dialogue1 | NOTIFY (403 Interdit) F4       |             |
              |<-----------------|             |             |
    dialogue1 |          200 OK  |             |             |
              |----------------->|             |             |
    dialogue1 |REFER(Refer-To:sips:TargetContact?Replaces=dialog2) F5
              |----------------->|             |             |
    dialogue1 | 202 Accepté      |             |             |
              |<-----------------|             |             |
    dialogue1 | NOTIFY (100 essai)             |             |
              |<-----------------|             |             |
    dialogue1 |          200 OK  |             |             |
              |----------------->|             |             |
    dialogue4 |                INVITE (Replaces:dialog2)/200 OK/ACK F6
              |                  |------------>|------------>|
    dialogue2 | BYE/200 OK       |             |             |
              |<-------------------------------|<------------|
    dialogue1 | NOTIFY (200 OK) F7             |             |
              |<-----------------|             |             |
    dialogue1 |          200 OK  |             |             |
              |----------------->|             |             |
    dialogue1 | BYE/200 OK       |             |             |
              |----------------->|             |             |
    dialogue3 |                  |             |  BYE/200 OK |
              |                  |<------------|-------------|

Figure 10 : Fux d'appels de transfert avec participation avec URI Contact non acheminable et échec d'AOR

F1 INVITE Transféreur -> Cible du transfert
INVITE sips:transfertarget@chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bK76
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferor@pc33.atlanta.exemple.com>
Content-Type: application/sdp
Content-Length: ...

F2 200 OK Cible du transfert -> Transféré
SIP/2.0 200 OK
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnas432;received=192.0.2.1
To: <sips:transfertarget@chicago.exemple.com>;tag=9m2n3wq
From: <sips:transferor@atlanta.exemple.com>;tag=763231
Call-ID: 090459243588173445
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transfertarget@client.chicago.exemple.com>
Content-Type: application/sdp
Content-Length: ...

F3 REFER Transféreur -> Transféré
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.exemple.com>;tag=a6c85cf
From: <sips:transferor@atlanta.exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 REFER
<allOneLine>
Refer-To: <sips:transfertarget@chicago.exemple.com?Replaces=
   090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Contact: <sips:transferor@pc33.atlanta.exemple.com>
Content-Length: 0

F4 NOTIFY Transféré -> Transféreur
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>;tag=1928301774
From: <sips:transferee@biloxi.exemple.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=314159
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...

SIP/2.0 403 Interdit

F5 REFER Transféreur -> Transféré
REFER sips:transferee@192.0.2.4 SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bKnashds9
Max-Forwards: 70
To: <sips:transferee@biloxi.exemple.com>;tag=a6c85cf
From: <sips:transferor@atlanta.exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:transfertarget@client.chicago.exemple.com?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq
   %3Bfrom-tag%3D763231>
</allOneLine>
Contact: <sips:transferor@pc33.atlanta.exemple.com>
Content-Length: 0

F6 INVITE Transféré -> Cible du transfert
INVITE sips:transfertarget@client.chicago.exemple.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnaslu82
Max-Forwards: 70
To: <sips:transfertarget@chicago.exemple.com>
From: <sips:transferee@biloxi.exemple.com>;tag=954
Call-ID: 20482817324945934422930
CSeq: 42 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Contact: <sips:transferee@192.0.2.4>
Replaces: 090459243588173445;to-tag=9m2n3wq;from-tag=763231
Content-Type: application/sdp
Content-Length: ...

F7 NOTIFY Transféré -> Transféreur
NOTIFY sips:transferor@pc33.atlanta.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.exemple.com>;tag=1928301774
From: <sips:transferee@biloxi.exemple.com>;tag=a6c85cf
Call-ID: a84b4c76e66710
CSeq: 76 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Event: refer;id=314160
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...

SIP/2.0 200 OK

Pour empêcher ce scénario de se produire, la cible du transfert DEVRAIT utiliser un URI Contact acheminable en dehors du dialogue, qui résulerait en le flux d'appels de la Figure 7.

 	7.6	Transfert à semi participation
Dans tous les flux de prise de consultation ci-dessus, le transféreur peut décider de terminer sa tentative de contact de la cible du transfert avant que la session soit établie. Le plus fréquemment, ce sera la fin du scénario, mais dans certaines circonstances, le transféreur peut souhaiter procéder à l'action de transfert. Par exemple, le transféreur peut souhaiter achever le transfert en sachant que le transféré va finir par parler au service vocal de messagerie de la cible du transfert. Certains systèmes de PABX prennent en charge cette caractéristique, parfois appelé "transfert à semi participation", qui est effectivement un hybride entre un transfert à pleine participation et un transfert sans participation. Un flux d'appels est montré à la Figure 11. Dans ce flux, l'agent d'utilisateur du transféreur continue le transfert comme un transfert avec participation même après que le transféreur a raccroché. Noter que le support doit être exécuté sur la cible du transfert à la réponse -- autrement, la cible peut raccrocher et l'opération de transfert résultante va échouer.

             Transféreur           Transféré         Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK F1 F2                 |
                  |<-------------------|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE             |                    |
                  |---------------------------------------->|
       dialogue2  |                    |       180 Sonnerie |
                  |<----------------------------------------|
     Le transféreur raccroche mais veut que le transfert continue
     L'agent d'utilisateur continue l'opération de transfert|
                  |                    |                    |
       dialogue2  |                    |           200 OK   |
                  |<----------------------------------------|
       dialogue2  | ACK                |                    |
                  |---------------------------------------->|
       dialogue2  | Support exécuté pour empêcher la cible de raccrocher
                  |========================================>|
       dialogue3  | REFER (Target-Dialog:1,                 |
                  |  Refer-To:sips:TransferTarget?Replaces=2)
                  |------------------->|                    |
       dialogue3  | 202 Accepté        |                    |
                  |<-------------------|                    |
       dialogue3  | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue4  |             INVITE (Replaces:dialog2)/200 OK/ACK
                  |                    |------------------->|
       dialogue2  | BYE/200 OK         |                    |
                  |<----------------------------------------|
       dialogue3  | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue1  | BYE/200 OK         |                    |
                  |------------------->|                    |
       dialogue4  |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 11 : Flux d'appel recommandé de transfert à semi participation

Deux autres flux d'appels de transfert à semi participation possibles sont montrés aux Figures 12 et 13. Cependant, ces flux d'appels ne sont PAS RECOMMANDÉS à cause de conditions de compétition. Dans ces deux flux, quand le transféreur raccroche, il tente de revenir au transfert sans participation en envoyant un CANCEL à la cible. Il peut en résulter deux conditions de compétition. Une est que la cible réponde en dépit du CANCEL et le transfert sans participation résulant échoue. Cette condition de compétition peut être éliminée par le transféreur qui attendra pour envoyer le REFER jusqu'à ce que la réponse 487 soit retournée de la cible. Au lieu d'une réponse 487, un 200 OK peut être retourné pour indiquer que la cible a répondu à l'appel de consultation. Dans ce cas, le flux d'appels de la Figure 13 doit être suivi. Dans ce flux, le transféreur doit exécuter un support d'une certaine sorte à la cible pour l'empêcher de raccrocher, sinon, le transfert échouera. C'est-à-dire que la personne à la cible du transfert va entendre un silence depuis qu'il a répondu (message F1) jusqu'à ce que le transfert s'achève (F3 et ils vont parler au transféré sanf si un support est exécuté (F2)).

La seconde condition de compétition se produit dans la Figure 12 si la cible du transfert est "décrochée" après la réception du CANCEL et le retour de la 487. Il peut en résulter une réponse 486 Occupé ici au transfert.sans participation.

Le flux d'appels recommandé de la Figure 11 n'utilise pas CANCEL et ne subit donc pas ces conditions de compétition.

             Transféreur           Transféré           Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK  |                    |
                  |<-------------------|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE                                  |
                  |---------------------------------------->|
       dialogue2  | 180 Sonnerie                            |
                  |<----------------------------------------|
                  |                                         |
                  |  Le transféreur abandonne l'attente     |
                  |                                         |
       dialogue2  | CANCEL                                  |
                  |---------------------------------------->|
       dialogue2  | 200 OK                                  |
                  |<----------------------------------------|
       dialogue2  | 487 Demande terminée                    |
                  |<----------------------------------------|
       dialogue2  | ACK                                     |
                  |---------------------------------------->|
       dialogue3  | REFER (Target-Dialog:1) F3              |
                  |------------------->|                    |
       dialogue3  | 202 Accepté        |                    |
                  |<-------------------|                    |
       dialogue3  | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue4  |                INVITE/200 OK/ACK        |
                  |                    |------------------->|
       dialogue3  | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue1  | BYE/200 OK         |                    |
                  |------------------->|                    |
       dialogue4  |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 12 : Flux d'appel de transfert à semi participation comme transfert aveugle (non recommandé)

             Transféreur           Transféré           Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK  |                    |
                  |<-------------------|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE                                  |
                  |---------------------------------------->|
       dialogue2  | 180 Sonnerie                            |
                  |<----------------------------------------|
                  |                                         |
                  |Le transféreur abandonne l'attente mais  |
                  |     la cible répond                     |
       dialogue2  | CANCEL                                  |
                  |---------------------------------------->|
       dialogue2  | 200 OK (CANCEL)                         |
                  |<----------------------------------------|
       dialogue2  | 200 OK (INVITE) F1                      |
                  |<----------------------------------------|
       dialogue2  | ACK                                     |
                  |---------------------------------------->|
       dialogue2  | INVITE (garde)/200 OK/ACK               |
                  |---------------------------------------->|
                  |Tonalités ou support exécuté pour éviter |
                  |      le silence F2                      |
                  |========================================>|
       dialogue1  |REFER (Refer-To:sips:TransferTarget      |
                  |                      ?Replaces=dialog2) |
                  |------------------->|                    |
       dialogue1  | 202 Accepté        |                    |
                  |<-------------------|                    |
       dialogue1  | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
       dialogue1  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue3  |         INVITE (Replaces:dialog2)/200 OK/ACK F3
                  |                    |------------------->|
       dialogue2  | BYE/200 OK         |                    |
                  |<----------------------------------------|
       dialogue1  | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
       dialogue1  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue1  | BYE/200 OK         |                    |
                  |------------------->|                    |
       dialogue3  |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 13 : Flux d'appels de transfert à semi participation comme transfert à participation (non recommandé)

 	7.7	Repli de transfert à participation à un transfert de base
Dans ce flux, une tentative de transfert avec participation échoue de sorte que le transféreur se replie sur le transfert de base.

Le flux d'appels de la Figure 14 montre l'utilisation de Require: replaces dans le INVITE envoyé par le transféreur à la cible du transfert dans lequel l'intention du transféreur au moment de l'envoi du INVITE à la cible du transfert était de réaliser un transfert avec participation. Comme la cible ne prend pas en charge Replaces, le INVITE est rejeté avec une réponse 420 Mauvaise extension, et le transféreur passe immédiatement du transfert avec participation au transfert de base.

             Transféreur           Transféré         Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK  |                    |
                  |<-------------------|                    |
       dialogue1  |   OPTIONS/200 OK   |                    |
                  |------------------->|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE (Require:replaces)               |
                  |---------------------------------------->|
       dialogue2  |                420 Mauvaise extension   |
                  |<----------------------------------------|
       dialogue2  |    ACK                                  |
                  |---------------------------------------->|
       dialogue1  | REFER (Refer-To:sips:TransferTarget)    |
                  |------------------->|                    |
       dialogue1  |    202 Accepté     |                    |
                  |<-------------------|                    |
       dialogue1  | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
       dialogue1  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue3  |                    |  INVITE/200 OK/ACK |
                  |                    |------------------->|
       dialogue1  | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
       dialogue1  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue1  | BYE/200 OK         |                    |
                  |------------------->|                    |
       dialogue3  |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 14 : Repli de transfert à participation à un transfert de base en utilisant Require:replaces

La Figure 15 montre l'utilisation de OPTIONS quand le transféré et la cible du transfert n'indiquent pas explicitement la prise en charge de la méthode REFER et des champs d'en-tête Replaces dans les champs d'en-tête Allow et Supported et le transféreur n'avait pas l'intention d'effectuer un transfert avec participation quand le INVITE à la cible a été envoyé. Dans le dialogue1, le transféreur détermine, en utilisant OPTIONS, que le transféré ne prend pas en charge REFER et Replaces. Par suite, le transféreur commence le transfert avec participation en plaçant le transféré en garde et en appelant la cible du transfert. En utilisant un OPTIONS dans le dialogue2, le transféreur détermine que la cible ne prend en charge ni REFER ni Replaces, rendant un transfert avec participation impossible. Le transféreur termine alors le dialogue2 en envoyant un BYE puis envoie un REFER au transféré en utilisant l'URI AOR de la cible du transfert.

             Transféreur           Transféré            Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK  |                    |
                  |<-------------------|                    |
       dialogue1  |   OPTIONS/200 OK   |                    |
                  |------------------->|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE/200 OK/ACK  |                    |
                  |---------------------------------------->|
       dialogue2  | OPTIONS/200 OK     |                    |
                  |---------------------------------------->|
       dialogue2  |    BYE/200 OK      |                    |
                  |---------------------------------------->|
       dialogue3  |REFER (Target-Dialog:1,                  |
                  |          Refer-To:sips:TransferTarget)  |
                  |------------------->|                    |
       dialogue3  |    202 Accepté     |                    |
                  |<-------------------|                    |
       dialogue3  | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue4  |                    |  INVITE/200 OK/ACK |
                  |                    |------------------->|
       dialogue3  | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue1  | BYE/200 OK         |                    |
                  |------------------->|                    |
       dialogue4  |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 15 :  Repli de transfert à participation à un transfert de base

 	8.	Transfert avec Referred-By

Dans les exemples précédents, la cible du transfert n'a pas d'informations définitives sur la partie qui a initié le transfert, ou, dans certains cas, même qu'un transfert a lieu. Le mécanisme Referred-By [RFC3892] fournit le moyen au transféreur de donner au transféré la possibilité de faire savoir à la cible du transfert quelle partie a initié le transfert.

L'approche la plus simple et la moins sûre implique juste l'inclusion du champ d'en-tête Referred-By dans le REFER, qui est alors copié dans le INVITE déclenché. Cependant, un mécanisme plus sûr impliquant le jeton de sécurité Referred-By, qui est généré et signé par le transféreur et passé dans un corps de message au transféré puis à la cible du transfert.

Le flux d'appels de la Figure 16 montre le champ d'en-tête Referred-By et le corps dans le REFER F5 et le INVITE déclenché en F6. Noter que la signature des extensions de messagerie Internet sécurisée multiobjets (S/MIME, Secure/Multipurpose Internet Mail Extensions) n'est pas montrée dans l'exemple ci-dessous. Les conventions utilisées dans le document "messages d'essai de résistance SIP" [RFC4475] sont réutilisés, en particulier les étiquettes <hex> et <allOneLine>.

             Transféreur           Transféré            Cible du transfert
                  |                    |                    |
       dialogue1  | INVITE/200 OK/ACK F1 F2                 |
                  |<-------------------|                    |
       dialogue1  | INVITE (garde)/200 OK/ACK               |
                  |------------------->|                    |
       dialogue2  | INVITE/200 OK/ACK F3 F4                 |
                  |---------------------------------------->|
       dialogue2  | INVITE (garde)/200 OK/ACK               |
                  |---------------------------------------->|
       dialogue3  | REFER (Target-Dialog:1, Referred-By:Transferor,
                  |  Refer-To:sips:TransferTarget?Replaces=2) F5
                  |------------------->|                    |
       dialogue3  | 202 Accepté        |                    |
                  |<-------------------|                    |
       dialogue3  | NOTIFY (100 essai) |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue4  |        INVITE (Replaces:dialog2,        |
                  |         Referred-By:Transferor )/200 OK/ACK F6
                  |                    |------------------->|
       dialogue2  | BYE/200 OK         |                    |
                  |<----------------------------------------|
       dialogue3  | NOTIFY (200 OK)    |                    |
                  |<-------------------|                    |
       dialogue3  |            200 OK  |                    |
                  |------------------->|                    |
       dialogue1  | BYE/200 OK         |                    |
                  |------------------->|                    |
       dialogue4  |                    |         BYE/200 OK |
                  |                    |<-------------------|

Figure 16 : Flux d'appels de transfert avec participation avec Referred-By

F5 REFER Transféreur -> Transféré
REFER sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.exemple.com;branch=z9hG4bK392039842
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.exemple.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 REFER
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958
   ?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Supported: gruu, replaces, tdialog
Require: tdialog
Referred-By: <sips:transferor@atlanta.exemple.com>;cid="20398823.2UWQFN309shb3@atlanta.exemple.com"
Target-Dialog: 592435881734450904;local-tag=9m2n3wq;remote-tag=763231
Contact: <sips:4889445d8kjtk3@atlanta.exemple.com;gr=723jd2d>
Content-Type: multipart/mixed; boundary=unique-boundary-1
Content-Length: ...

--unique-boundary-1
Content-ID: <20398823.2UWQFN309shb3@atlanta.exemple.com>

Content-Length: 2961
Content-Type: multipart/signed;protocol="application/pkcs-7-signature";micalg=sha1;
                boundary="----590F24D439B31E08745DEF0CD9397189"

------590F24D439B31E08745DEF0CD9397189
Content-Type: message/sipfrag

Date: Thu, 18 Sep 2003 13:07:43 GMT
<allOneLine>
Refer-To: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958
?Replaces=090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sips:transferor@atlanta.exemple.com>;cid="20398823.2UWQFN309shb3@atlanta.exemple.com"

------590F24D439B31E08745DEF0CD9397189
Content-Type: application/pkcs-7-signature; name="smime.p7s"

Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"

<hex>3082088806092A864886F70D010702A082087930820875020101310B300906052B0E03021A050030

. . . (Signature non montrée)

8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B42838896679089AAD95767F</hex>

------590F24D439B31E08745DEF0CD9397189--

--unique_boundary-1

F6 INVITE Transféré -> Cible du transfert
INVITE sips:482n4z24kdg@chicago.exemple.com;gr=8594958 SIP/2.0
Via: SIP/2.0/TLS referee.exemple;branch=z9hG4bKffe209934aac
To: <sips:482n4z24kdg@chicago.exemple.com;gr=8594958>
From: <sips:transferee@biloxi.exemple.com>;tag=2909034023
Call-ID: fe9023940-a3465@referee.exemple
CSeq: 889823409 INVITE
Max-Forwards: 70
Contact: <sips:3ld812adkjw@biloxi.exemple.com;gr=3413kj2ha>
Referred-By: <sips:transferor@atlanta.exemple.com>
      ;cid="20398823.2UWQFN309shb3@atlanta.exemple.com"
Replaces:090459243588173445;to-tag=9m2n3wq;from-
tag=76323
Require: replaces
Supported: gruu, replaces, tdialog
Content-Type: multipart/mixed; boundary=my-boundary-9
Content-Length: ...

--my-boundary-9
Content-Type: application/sdp

Content-Length: 156

v=0
o=referee 2890844526 2890844526 IN IP4 referee.exemple
s=Session SDP
c=IN IP4 referee.exemple
t=0 0
 m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

--my-boundary-9
Content-Length: 2961
Content-Type: multipart/signed;protocol="application/pkcs-7-signature";micalg=sha1;
                boundary="----590F24D439B31E08745DEF0CD9397189"

------590F24D439B31E08745DEF0CD9397189
Content-Type: message/sipfrag

Date: Thu, 18 Sep 2003 13:07:43 GMT

<allOneLine>
Refer-To: <sips:transfertarget@chicago.exemple.com;
Replaces=090459243588173445%3Bto-tag%3D9m2n3wq%3Bfrom-tag%3D763231&Require=replaces>
</allOneLine>
Referred-By: <sips:transferor@atlanta.exemple.com>;cid="20398823.2UWQFN309shb3@atlanta.exemple.com"

------590F24D439B31E08745DEF0CD9397189
Content-Type: application/pkcs-7-signature; name="smime.p7s"
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename="smime.p7s"

<hex>3082088806092A864886F70D010702A082087930820875020101310B300906052B0E03021A050030

. . .  (Signature non montrée)

8E63D306487A740A197A3970594CF47DD385643B1DC49FF767A3D2B42838896679089AAD95767F</hex>

------590F24D439B31E08745DEF0CD9397189--

--my-boundary-9--

 	9.	Transfert comme conférence ad hoc

Dans ce flux, montré à la Figure 17, Bob n'a pas participé au transfert de Alice à Carol. Afin de tenir Alice et Carol pleinement informées toutes deux de la nature et de l'état de l'opération de transfert, Bob agit comme point de focalisation [RFC4579] et héberge une conférence ad hoc impliquant Alice, Bob, et Carol. Alice et Carol s'abonnent au paquetage de conférence [RFC4575] du point de focalisation de Bob, qui leur permet de savoir l'état exact de l'opération. Après l'achèvement de l'opération de transfert, Bob supprime la conférence.

Ce flux d'appels satisfait à l'exigence 6 de la Section 4. Les messages NOTIFY qui se rapportent au paquetage refer sont indiqués comme "NOTIFY (refer)", tandis que les NOTIFY qui se rapportent au paquetage Conference Info sont indiqués par "NOTIFY (Conf-Info)".

Noter que tout type de transfert à semi-participation dans lequel il y a mélange de supports ou relais pourrait être mis en œuvre en utilisant ce modèle. En plus de simplement mélanger, le point de focalisation pourrait introduire des signaux de support supplémentaires comme une tonalité de sonnerie simulée ou des annonces en garde pour améliorer l'expérience de l'utilisateur.

   Alice                  Bob                 Carol
      |                    |                    |
      | INVITE             |                    |
      |------------------->|                    |
      |   180 Sonnerie     |                    |
      |<-------------------|                    |
      |     200 OK         |                    |
      |<-------------------|                    |
      |        ACK         |                    |
      |------------------->|                    |
      |        RTP         |                    |
      |<==================>|                    |
      |                    |                    |
   Bob place Alice en garde et commence à agir comme point de focalisation
      |                    |                    |
      | INVITE (garde) Contact:Conf-ID;isfocus  |
      |<-------------------|                    |
      |    200 OK          |                    |
      |------------------->|                    |
      |        ACK         |                    |
      |<-------------------|                    |
      |                    |                    |
      | Alice s'abonne au paquetage conférence  |
      |                    |                    |
      | SUBSCRIBE sip:Conf-ID                   |
      |------------------->|                    |
      |     200 OK         |                    |
      |<-------------------|                    |
      | NOTIFY (Conf-Info) |                    |
      |<-------------------|                    |
      |     200 OK         |                    |
      |------------------->|                    |
      |                    |                    |
      | Bob commence l'opération de consultation|
      |                    |                    |
      |INVITE Require:replaces Contact:Conf-ID;isfocus
      |                    |------------------->|
      |                    |   180 Sonnerie     |
      |                    |<-------------------|
      |                    |     200 OK         |
      |                    |<-------------------|
      |                    |       ACK          |
      |                    |------------------->|
      |                    |        RTP         |
      |                    |<==================>|
      |                    |                    |
      | Carol s'abonne au paquetage conférence  |
      |         - apprend que Bob est en garde  |
      |                    |                    |
      |                    |SUBSCRIBE sip:Conf-ID
      |                    |<-------------------|
      |                    |      200 OK        |
      |                    |------------------->|
      |                    | NOTIFY (Conf-Info) |
      |                    |------------------->|
      |                    |      200 OK        |
      |                    |<-------------------|
      |                    |                    |
      | Alice apprend que Bob parle à Carol     |
      |                    |                    |
      | NOTIFY (Conf-Info) |                    |
      |<-------------------|                    |
      |     200 OK         |                    |
      |------------------->|                    |
      |                    |  INVITE (garde)    |
      |                    |------------------->|
      |                    |      200 OK        |
      |                    |<-------------------|
      |                    |      ACK           |
      |                    |------------------->|
      |                    |                    |
      | Alice apprend que Carol est en garde    |
      |                    |                    |
      | NOTIFY (Conf-Info) |                    |
      |<-------------------|                    |
      |     200 OK         |                    |
      |------------------->|                    |
      |                    |                    |
      |   Bob commence l'opération de transfert |
      |                    |                    |
      |     REFER Refer-To: Carol               |
      |<-------------------|                    |
      |     202 Accepté    |                    |
      |------------------->|                    |
      | NOTIFY (Refer)     |                    |
      |------------------->|                    |
      |     200 OK         |                    |
      |<-------------------|                    |
      |  INVITE Replaces:B-C Contact:Alice      |
      |---------------------------------------->|
      |                 200 OK                  |
      |<----------------------------------------|
      |                   ACK                   |
      |---------------------------------------->|
      |                    RTP                  |
      |<=======================================>|
      |                    |       BYE          |
      |                    |<-------------------|
      |                    |      200 OK        |
      |                    |------------------->|
      | NOTIFY (Refer)     |                    |
      |------------------->|                    |
      |     200 OK         |                    |
      |<-------------------|                    |
      |                    |                    |
      | Bob termine la conférence  ad hoc       |
      |                    |                    |
      |       BYE          |                    |
      |<-------------------|                    |
      |     200 OK         |                    |
      |------------------->|                    |
      |                    | NOTIFY (Conf-Info) |
      |                    |------------------->|
      |                    |      200 OK        |
      |                    |<-------------------|
      | NOTIFY (Conf-Info) |                    |
      |<-------------------|                    |
      |     200 OK         |                    |
      |------------------->|                    |

Figure 17 : Transfert avec participation comme conférence ad hoc

 	10.	Transfert avec plusieurs parties

Dans l'exemple montré à la Figure 18, le générateur passe un appel au facilitateur qui atteint le visionneur à travers le visionneur. Les informations de contact du visionneur sont exposées au facilitateur et au générateur. Cet exemple est fourni seulement pour éclairer la sémantique de la méthode REFER, et il ne devrait pas être utilisé comme concept d'une mise en œuvre.

       Générateur   Facilitateur Visionneur   Visionneur
      |            |            |          |
   1  |INVITE/200 OK/ACK        |          |"joins Fred pour moi !"
      |----------->|            |          |   "Tout de suite !"
   2  |INVITE (garde)/200 OK/ACK|          |
      |<-----------|            |          |
   2  |            |INVITE/200 OK/ACK      |"J'ai un appel
      |            |----------->|          | de Marie pour Fred"
   2  |            |INVITE (garde)/200 OK/ACK "garde la ligne s'il te plait"
      |            |<-----------|          |
   3  |            |            |INVITE/200 OK/ACK
      |            |            |--------->|"Vous avez un appel
      |            |            |          |de Mary"
      |            |            |          |  "Mets la en ligne"
   3  |            |            |INVITE (garde)/200 OK/ACK
      |            |            |--------->|
   4  |            |REFER       |          |
      |            |<-----------|          |
   4  |            |202 Accepté |          |
      |            |----------->|          |
   4  |            |NOTIFY (100 essai)     |
      |            |----------->|          |
   4  |            |200 OK      |          |
      |            |<-----------|          |
   5  |            |INVITE/200 OK/ACK      |
      |            |---------------------->|"C'est Fred"
   4  |            |NOTIFY (200 OK)        | "Mets toi en garde pour Mary"
      |            |----------->|          |
   4  |            |200 OK      |          |
      |            |<-----------|          |
   2  |            |BYE/200 OK  |          |
      |            |<-----------|          |
   3  |            |            |BYE/200 OK|
      |            |            |--------->|
   5  |            |INVITE (garde)/200 OK/ACK
      |            |---------------------->|
   6  |REFER       |            |          |
      |<-----------|            |          |
   6  |202 Accepté |            |          |
      |----------->|            |          |
   6  |NOTIFY (100 essai)       |          |
      |----------->|            |          |
   6  |200 OK      |            |          |
      |<-----------|            |          |
   7  |INVITE/200 OK/ACK        |          |
      |----------------------------------->| "Hey Fred"
   6  |NOTIFY (200 OK)          |          |    "Hello Mary"
      |----------->|            |          |
   6  |200 OK      |            |          |
      |<-----------|            |          |
   1  |BYE/200 OK  |            |          |
      |<-----------|            |          |
   5  |            |BYE/200 OK  |          |
      |            |---------------------->|
   7  |BYE/200 OK  |            |          |
      |<-----------------------------------| "À plus tard"

Figure 18 : Exemple de transfert avec plusieurs parties

 	11.	Problèmes de transfert de passerelles

Dans SIP, une passerelle agit comme un agent d'utilisateur. Il en résulte que toute la discussion et les flux d'appels précédants s'appliquent également bien aux passerelles comme points d'extrémité SIP natifs. Cependant, il y a quelques problèmes spécifiques des passerellles qui sont documentés dans cette section. Bien que cette discussion se concentre sur les cas communs qui impliquent les passerelles du réseau téléphonique public commuté (RTPC) des situations similaires existent pour d'autres passerelles, telles que les passerelles H.323/SIP.

 	11.1	Contraindre des passerelles en épingle à cheveux à la même passerelle
Pour illustrer comment une situation d'épingle à cheveux peut se produire dans un transfert, considérons cet exemple. Le dialogue d'appel d'origine est établi avec le transféré qui réside sur le côté RTPC d'une passerelle SIP. Le transféreur est un téléphone SIP entièrement dans l'espace IP. La cible du transfert est aussi sur le côté RTPC d'une passerelle SIP. Après l'achèvement du transfert, (qu'il soit avec participation ou aveugle) le transféré est dans un appel avec la cible du transfert (tous deux sur le côté RTPC d'une passerelle). Il est souvent désirable de retirer la ou les passerelles de la boucle. Ceci n'est vraisemblablement possible que si les deux branches de la cible d'appel sont sur la même passerelle. Avec les deux branches sur la même passerelle, on peut être capable d'invoquer un transfert analogue sur le côté RTPC. L'appel cible n'impliquera alors pas la passerelle.

Le problème est donc de comment donner au mandataire assez d'informations pour qu'il sache acheminer l'appel à la même passerelle. Avec un seul appel simple qui fait une épingle à cheveux, la branche entrante et la branche sortante ont le même dialogue. Le mandataire devrait avoir assez d'informations pour optimiser l'acheminement.

Dans le scénario de transfert consultatif, il est souhaitable de contraindre le INVITE consultatif à sortir de la même passerelle que l'appel original à transférer. Cependant, il n'y a pas de moyen de mettre en rapport la consultation avec l'appel original. Dans le cas consultatif, le INVITE de l'appel cible inclut l'en-tête Replaces, qui contient les informations de dialogue qui peuvent être utilisées pour le rapporter à la consultation. Cependant, il n'y a pas d'informations qui mettent en rapport l'appel cible avec l'original.

Dans le scénario de transfert aveugle, il est souhaitable de contraindre l'appel cible à passer par la même passerelle que l'appel original. Cependant, le même problème existe car le dialogue cible ne peut pas être mis en rapport avec le dialogue original.

Dans l'un et l'autre scénario de transfert, il peut être souhaitable de pousser l'opération de transfert sur le côté non SIP de la passerelle. On peut supposer que ce n'est pas possible à moins que les deux branches sortent de la même passerelle. Si la passerelle prend en charge plus d'un groupe de circuits, il peut aussi être nécessaire d'avoir toutes les branches sur le même groupe de circuits afin d'effectuer le transfert sur le côté non SIP de la passerelle.

Les solutions à ces questions spécifiques de passerelle pourraient impliquer de nouvelles extensions de SIP à l'avenir.

 	11.2	Cas de l'éblouissement de passerelle consultative qui la rend aveugle
Dans le cas du transfert consultatif qui devient aveugle, il y a un problème d'une sorte d'éblouissement. Le transféreur initie la consultation INVITE, le transféreur s'impatiente et raccroche, créant une transition à un transfert aveugle. La cible du transfert sur la passerelle (connectée par un commutateur RTPC à une seule ligne ou un téléphone analogique sans intelligence) sonne. L'utilisateur répond au téléphone juste après la réception du CANCEL par la cible du transfert. Le REFER et l'INVITE pour l'appel cible sont envoyés. Le transféré tente d'établir l'appel sur le côté RTPC, mais obtient soit une réponse d'occupation, soit atterrit dans la boîte vocale de l'usager car celui-ci a le combiné en main et il est donc décroché.

C'est un autre exemple de condition de compétition que peut causer ce flux d'appels. Le comportement recommandé est d'utiliser l'approche décrite au paragraphe 7.6.

 	12.	Considérations sur la sécurité

Les flux de transfert d'appel montrés dans le présent document sont mis en œuvre en utilisant les primitives de commande d'appel REFER et Replaces de SIP. À ce titre, les considerations de sécurité détaillées dans les documents REFER [RFC3515] et Replaces [RFC3891] DOIVENT être suivies ; elles sont résumées dans les deux alinéas qui suivent. Le présent document traite la question de la protection de l'URI d'adresse d'enregistrement d'une cible de transfert aux paragraphes 7.1 et 7.2.

Toute demande REFER DOIT être correctement authentifiée et autorisée en utilisant les mécanismes SIP standard ou sinon les appels peuvent être capturés. Un agent d'utilisateur peut utiliser sa politique locale ou une intervention humaine pour décider d'accepter ou non un REFER. En générant des réponses NOTIFY fondées sur le résultat de la demande déclenchée, il faut apporter un grand soin à la construction du corps de message/sipfrag pour s'assurer qu'aucune information confidentielle n'est révélée.

Un INVITE qui contient un champ d'en-tête Replaces DEVRAIT n'être accepté que si il a été correctement authentifié et autorisé en utilisant les mécanismes SIP standard, et si le demandeur est autorisé à effectuer un remplacement de dialogue. Un soin particulier est nécessaire si le dialogue remplacé utilise des flux de support suppémentaires par rapport au dialogue original. Dans ce cas, l'utilisateur DOIT autoriser l'ajout des nouveaux flux de supports dans un remplacement de dialogue. Par exemple, on pourrait utiliser le même mécanisme que pour autoriser l'ajout d'un flux de supports dans un re-INVITE.

 	13.	Remerciements

Le présent document est un produit de la collaboration du groupe de travail SIP. Merci à Rohan Mahy de sa contribution sur l'utilisation de Replaces dans les transferts.

 	14.	Références
 	14.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC3261]	J. Rosenberg et autres, "SIP : Protocole d'initialisation de session", juin 2002. (Mise à jour par 3265, 3853, 4320, 4916, 5393, 6665, 8217, 8760)

[RFC3515]	R. Sparks, "Méthode Refer du protocole d'initialisation de session (SIP)", avril 2003. (MàJ par RFC8217)

[RFC3891]	R. Mahy, B. Biggs, R. Dean, "En-tête "Replaces" du protocole d'initialisation de session (SIP)", septembre 2004. (P.S.)

[RFC3892]	R. Sparks, "Mécanisme Referred-by du protocole d'initialisation de session (SIP)", septembre 2004. (MàJ par RFC8217

[RFC4538]	J. Rosenberg, "Autorisation de demande par identification de dialogue dans le protocole d'initialisation de session (SIP)", juin 2006. (P.S.)

 	14.2	Références pour information

[RFC4353]	J. Rosenberg, "Cadre pour les conférences avec le protocole d'initialisation de session (SIP)", février 2006. (Information)

[RFC4475]	R. Sparks et autres, "Messages d'essais de résistance du protocole d'initialisation de session (SIP)", mai 2006. (Info.)

[RFC4575]	J. Rosenberg et autres, "Paquetage d'événement du protocole d'initialisation de session (SIP) pour l'état Conference", août  2006. (P.S.)

[RFC4579]	A. Johnston, O. Levin, "Commande d'appel du protocole d'initialisation de session (SIP) – Conférence pour agents d'utilisateur", août 2006. (BCP0119)

[RFC5057]	R. Sparks, "Usages de dialogues multiples dans le protocole d'initialisation de session", novembre 2007. (Information)

[RFC5627	J. Rosenberg, "Obtension et utilisation des URI d'agent d'utilisateur mondialement acheminable (GRUU) dans le protocole d'initialisation de session (SIP)", octobre 2009. (P. S.)

[RFC5850]	R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, "Cadre de la commande d'appel et de l'utilisation multi parties pour le protocole d'initialisation de session (SIP)", mai 2010. (Information)

 	Adresse des auteurs

Robert Sparks	Alan Johnston (editor)	Daniel Petrie	
Tekelec	Avaya	SIPez LLC	
17210 Campbell Road	St. Louis, MO	Arlington, MA  02476	
Suite 250	USA	US	
Dallas, Texas  75252		téléphone : +1 617 273 4000	
	alan@sipstation.com 	dan.ietf@SIPez.com 	
mél : RjS@nostrum.com 		URI : http://www.SIPez.com/