STAS PAC V2...STAS ± Portail API Contact Edition Aout 2016 STAS PAC V2 .1 (Service PAC pour NR IP)...

1/47

STAS – Portail API Contact

Edition Aout 2016

STAS PAC V2.1 (Service PAC pour NR IP)

Spécification Technique d'Accès aux Services du

Portail API Contact V2.1

(version « C+S » - 2015)

Version du 30/06/2015

© Copyright 2014 – Domaine Stratégique Orange Applications for Business La communication de ce document est soumise à l’autorisation d’Orange Business Services

2/47


Edition Aout 2016

SOMMAIRE AVERTISSEMENT .............................................................................................................................................. 4

1 Introduction .............................................................................................................................................. 4 1.1 But du document .................................................................................................................................... 4 1.2 Terminologie, glossaire .......................................................................................................................... 4

2 Les services des Numéros Contact concernés ....................................................................................... 5 2.1 Les services concernés .......................................................................................................................... 5 2.2 Conditions d'utilisation des services ....................................................................................................... 5 2.3 Description des services ......................................................................................................................... 7

2.3.1 Service changement de tarif en cours de communication ................................................................. 7

2.3.2 Services reroutage en aveugle et reroutage accompagné ................................................................. 7 2.3.3 Service Commande Possibilité ........................................................................................................... 9

2.4 L'accès aux services ............................................................................................................................ 10

3 Utilisations des Web Services côté client .............................................................................................. 11 3.1 WSDL - Le contrat d’interface entre le client et le serveur ................................................................... 11 3.2 Pré-requis environnement applicatif pour l’accès à l'API du PAC ........................................................ 12 3.3 Exigences de sécurité pour l’accès aux services web du PAC ............................................................ 13 3.4 Modalités pour Mise en place d'un accès au PAC ............................................................................... 13

3.4.1 Le mot de passe client pour le PAC .................................................................................................. 14

3.4.2 La référence d'appel ......................................................................................................................... 14

3.4.3 Les alias ............................................................................................................................................. 14

4 Requêtes d'accès aux services du PAC ................................................................................................ 16 4.1 La gestion des erreurs .......................................................................................................................... 16 4.2 Gestion des connexions ....................................................................................................................... 16

5 Description des Web Services ............................................................................................................... 17 5.1 ChangementTarifExt............................................................................................................................. 17

5.1.1 Requête ............................................................................................................................................. 17 5.1.2 Réponse ............................................................................................................................................ 17

5.1.3 Codes retour ..................................................................................................................................... 18 5.2 reroutageAveugle et reConnect ............................................................................................................ 18

5.2.1 reroutageAveugle .............................................................................................................................. 18 5.2.2 reConnect .......................................................................................................................................... 21

5.3 reroutageAccompagne, reroutageAccompagneSup, demandeEtatRerAccSup, demandeEtatFinalRerAccSup, vaEtVient et reConnect ............................................................................... 22

5.3.1 reroutageAccompagne ..................................................................................................................... 22 5.3.2 reroutageAccompagneSup ............................................................................................................... 24 5.3.3 demandeEtatRerAccSup ................................................................................................................... 27

5.3.4 demandeEtatFinalRerAccSup ........................................................................................................... 28 5.3.5 vaEtVient ........................................................................................................................................... 29 5.3.6 reConnect .......................................................................................................................................... 30

5.4 informationsAppel ................................................................................................................................. 32

5.4.1 Requête ............................................................................................................................................. 32 5.4.2 Réponse ............................................................................................................................................ 32

5.4.3 Codes retour ..................................................................................................................................... 33

ANNEXE 1: Les erreurs générées par le PAC .................................................................................................. 34 Les erreurs de type http. ................................................................................................................................ 34 Les erreurs de type fault. ............................................................................................................................... 34

ANNEXE 2: Fichiers WSDL ............................................................................................................................... 35 Web Service changementTarifExt ................................................................................................................. 35 Web Services reroutageAveugle et reConnect ............................................................................................. 36


3/47


Edition Aout 2016

Web Services reroutageAccompagne, reroutageAccompagneSup, demandeEtatRerAccSup, demandeEtatFinalRerAccSup, vaEtVient et reConnect ............................................................................... 39 Web Service informationsAppel .................................................................................................................... 45 Exemple de requête SOAP ............................................................................................................................ 46


4/47


Edition Aout 2016

AVERTISSEMENT Cette documentation décrit les modalités et paramètres d'accès associés aux services des Numéros Contact activés via le Portail API Contact (PAC) par les clients d'Orange Business Services. Orange Business Services se réserve le droit de préciser contractuellement, au moment de la signature du contrat d'abonnement au service considéré, les limitations éventuelles et paramètres non disponibles.

1 Introduction

1.1 But du document

Ce document présente les services de Changement de tarif1, Reroutage et Commande Possibilité activés par les clients des numéros Contact via le Portail API Contact, PAC, et décrit l’ensemble des conditions à satisfaire par le client pour accéder au service dans les domaines suivants :

Conditions d'utilisation du service ;

L'accès aux services du PAC ;

Caractéristiques et paramètres d'invocation des services.

Cette version des STAS sur serveur PAC couvre tout le périmètre fonctionnel accessible via le PAC. Les destinataires de cette documentation sont donc les équipes traitant des cas clients des services des Numéros Contact, ainsi que les développeurs, éditeurs de logiciel, intégrateurs de services qui pourront intervenir lors de l'intégration des services.

1.2 Terminologie, glossaire

NDS Numéro de Désignation Supplémentaire GTX Groupe de TaXation ITX Indication de TaXation IUU Information d'Usager à Usager Mnémonique Nom abrégé d'un service NA Numéro d’appel (n° spécial composé par l’appelant, soit le numéro appelé) NR Numéro de Réception NR IP Numéro de Réception en ToIP (Telephony over IP) PAC Portail API Contact PBX de PABX, Private Automatic Branch eXchange RTC Réseau Téléphonique Commuté RI Réseau Intelligent (offrant les services Numéros Contact) SOAP Simple Object Acces Protocol HTTP Hypertext Transfer Protocol XML Extensible Markup Language WSDL Web Services Description Language WSP Web Services Provider WSC Web Services Consumer

1 NB : en C+S ce service n’est plus utilisé que pour l’Annonce Tarifaire Personnalisée Interruptible (ATPi).


5/47


Edition Aout 2016

2 Les services des Numéros Contact concernés

2.1 Les services concernés

Le portail API Contact permet d'accéder en environnement IP à un ensemble de services offerts par Orange Business Services à ses clients titulaires de Numéros Contact dans le domaine de la relation client, à savoir :

Annonce Tarifaire Personnalisée Interruptible (via une commande « Changement de tarif en cours de communication ») ;

Reroutage en aveugle ;

Reroutage accompagné ;

Commande Possibilité.

2.2 Conditions d'utilisation des services

Les services, tels que présentés dans ce document, sont offerts par le réseau d'Orange via le Portail API Contact. Le rôle du portail est d'offrir aux clients d'Orange Business Services une interface unique d'accès à différents services associés aux solutions de relation client d'Orange. Le PAC fait donc office d'intermédiaire entre les clients et les différentes plates-formes de services d'Orange.


6/47


Edition Aout 2016

Pour l'accès aux services concernés, objets de ce document, les clients doivent:

avoir souscrit à une offre Contact et avoir souscrit aux options commerciales correspondant aux services décrits ci-dessous (cf. §2.3) ;

disposer d'un accès Internet permettant de joindre l'URL du PAC ;

disposer des équipements qui implémentent l'interface d'accès au PAC (SOAP sur HTTPS) ;

être capables de traiter le champ NDS ou IUU du protocole d'accès au réseau téléphonique. Ces champs sont utilisés pour transmettre l'information permettant d'identifier un appel vis-à-vis du réseau (information appelée « référence d’appel »).

Réseau Téléphonique

Internet

WSC (Site client)

PBX Poste agent

Appelant

WSP (PAC)

Infrastructure Orange

Plates-formes services


7/47


Edition Aout 2016

2.3 Description des services

2.3.1 Service changement de tarif en cours de communication

En C+S ce service n’est plus utilisé que pour l’Annonce Tarifaire Personnalisée Interruptible (ATPi). Les autres fonctionnalités de ce service sont inactives. Dans le service Annonce Tarifaire Personnalisée Interruptible (ATPi), le SVI client demande au RI le passage en taxation suite à interruption de l’annonce tarifaire personnalisée, via une commande « Changement de tarif en cours de communication », avec une valeur d’ ITX fixée à 255.

Le service de changement de tarif en cours de communication est activé via le Web Service changementTarifExt.

2.3.2 Services reroutage en aveugle et reroutage accompagné

2.3.2.1 Introduction

Dans la suite de ce document, on appellera :

Service rerouteur : le service initiateur du reroutage ; Service rerouté : le service ou numéro d'annuaire vers lequel est effectué le reroutage ; Reroutage aveugle : la fonctionnalité de transfert de l’appelant sans dialogue préalable du service

rerouteur avec le service rerouté ; Reroutage accompagné : la fonctionnalité de transfert de l’appelant avec dialogue préalable entre le

service rerouteur et le service rerouté. Remarque : il est également possible d'effectuer le reroutage vers un numéro d'annuaire.

Le service de reroutage en aveugle est activé via les Web Services reroutageAveugle et reConnect (pour le rétro-appel).

Le service de reroutage accompagné est activé via les Web Services reroutageAccompagne, reroutageAccompagneSup, demandeEtatRerAccSup, demandeEtatFinalRerAccSup, vaEtVient et reConnect.

2.3.2.2 Services offerts par le reroutage

Reroutage simple

Le reroutage simple peut être de deux types :

Reroutage aveugle (le service rerouteur demande la mise en relation entre l’appelant et le service rerouté, sans dialogue préalable du service rerouteur avec ce service) ;

Reroutage accompagné (le service rerouteur demande à être mis en relation avec le service rerouté, puis commande la mise en relation entre l’appelant et le service rerouté par raccrochage).

Le reroutage (aveugle ou accompagné) d'un service vers un autre est initialisé par le rerouteur au moyen du Web Service approprié. La désignation du service rerouté dans cette commande peut être faite de quatre manières différentes :

Par le Numéro d'Appel (dit NA) d'un service ; Par le nom abrégé (dit Mnémonique) d'un service ; Par un numéro d'annuaire ou un numéro de service spécial (autre service RI) ; Par un Numéro de Réception (dit NR) défini pour le NA du service rerouteur.


8/47


Edition Aout 2016

Si le service rerouté a souscrit au service "Commande possibilité" il pourra obtenir (via l'utilisation du Web Service correspondant) les informations permettant de savoir :

Qu'il s'agit d'un appel à la suite d'un reroutage ; Quel est le service rerouteur.

Il pourra également obtenir des données facultatives complémentaires (contexte de l’appel, données en retour, origine de l’appel, information de marquage). En reroutage accompagné, le transfert effectif de l’appelant s’effectue par raccrochage du rerouteur. Ce transfert peut être éventuellement anticipé (raccrochage pendant la phase d’établissement du rerouté). Dans ce cas, le rerouteur sera éventuellement rappelé par le PCS et remis en relation avec l’appelant en cas d’échec. En fonction du service RI utilisé, le transfert anticipé (raccrochage du rerouteur pendant la phase d’établissement du rerouté) peut aussi être utilisé en reroutage aveugle. Dans ce cas, le rerouteur sera éventuellement rappelé par le PCS et remis en relation avec l’appelant en cas d’échec. Reroutage simple et va-et-vient

Suite à une demande de reroutage accompagné, le service rerouteur se retrouve en conversation avec le service rerouté, l’appelant étant mis en garde durant ce dialogue. Le service rerouteur peut alors envoyer une demande de va-et-vient (via l'utilisation du Web Service correspondant) afin de reprendre la conversation avec l’appelant, le service rerouté étant alors mis en garde durant ce dialogue. Cette demande de va-et-vient peut être utilisée plusieurs fois par le service rerouteur et lui permet donc de passer alternativement d'une communication avec le service rerouté à une communication avec l'appelant. Le correspondant qui n’est plus en conversation avec le service rerouteur est alors mis en garde dans le réseau. Le va-et-vient n’est disponible que suite à une demande de reroutage accompagné, après passage en conversation avec le service rerouté. Reroutage simple et retro-appel

Suite à une demande de reroutage accompagné, le service rerouteur se retrouve en conversation avec le service rerouté, l’appelant étant mis en garde durant ce dialogue. Le service rerouteur peut alors envoyer une demande de retro-appel (via l'utilisation du Web Service correspondant) afin de reprendre la conversation avec l’appelant, le service rerouté étant alors libéré. Le retro-appel peut aussi être utilisé avant le décrochage du service rerouté, pour mettre fin à la tentative de reroutage (en cas de réponse trop longue du service rerouté) et effectuer éventuellement une autre demande de reroutage aveugle ou accompagné. En fonction du service RI utilisé, le retro-appel peut aussi être utilisé en reroutage aveugle. Dans ce cas, il ne peut l’être qu’avant le décrochage du service rerouté, pour mettre fin à la tentative de reroutage (en cas de réponse trop longue du service rerouté) et effectuer éventuellement une autre demande de reroutage aveugle ou accompagné. Reroutage arrière

Le reroutage arrière, est un sous-ensemble du reroutage simple, il permet à un service rerouté de revenir au service rerouteur précédent, et à lui seul, sans avoir besoin de l'indiquer explicitement dans la demande de reroutage aveugle ou accompagné. Ainsi ce retour implicite vers le service d'origine s'en trouve facilité. Ce mode simplifié conserve par ailleurs la possibilité de transmettre des données de contexte. Reroutage retour

Le service rerouteur peut indiquer, dans sa demande de reroutage aveugle ou accompagné, qu'il souhaite que l'appel soit envoyé vers un troisième service, suite à la communication appelant-rerouté. Pour cela, le rerouteur doit renseigner le paramètre NASRetour en retour de la demande de reroutage (aveugle ou accompagné) avec le NA du service choisi. Ce paramètre est mémorisé par le RI, et, au raccrochage du rerouté, il effectue un reroutage aveugle implicite (c'est à dire sans avoir reçu une nouvelle demande de reroutage) vers le service désigné. Le troisième service peut être le service d'origine. Dans ce cas, le reroutage retour se comporte comme le reroutage arrière, mais à l'initiative du rerouteur, et non du rerouté.


9/47


Edition Aout 2016

Reroutage avec transmission de données de contexte

Dans sa demande de reroutage aveugle ou accompagné, le service rerouteur peut fournir des données de contexte qui peuvent être récupérées par le service rerouté via l'utilisation du Web Service correspondant au service "Commande possibilité". Ce transfert d'informations peut avoir pour objet de communiquer au rerouté les circonstances du reroutage, afin de qualifier l'appel. Par exemple, dans le cas du reroutage vers un service de télépaiement, les données de contexte peuvent représenter le montant à payer par l'utilisateur. Reroutage avec mémorisation de données en retour

Le service rerouteur peut transmettre avec sa demande de reroutage aveugle ou accompagné des données en retour. Ces dernières sont stockées par le RI pendant la phase d’un seul reroutage. Ces données ainsi mémorisées seront retournées au service rerouteur via l'utilisation du Web Service correspondant au service "Commande possibilité", si le service rerouté revient vers le service rerouteur :

Soit par un reroutage explicite (reroutage simple aveugle ou accompagné) ; Soit par un reroutage implicite (reroutage arrière aveugle ou accompagné, ou reroutage retour).

Cette fonctionnalité permet aux services d'assurer une continuité logique entre les différentes phases du dialogue du rerouteur avec l'utilisateur. Un tel mécanisme peut permettre au service rerouteur d'accueillir l'utilisateur à l'endroit où il se trouvait dans le service avant le reroutage. Reroutage en cascade

Le rerouté peut, suite à sa mise en relation avec l’appelant, demander que la communication soit transférée vers un autre service, différent du rerouteur initial. On parle ainsi de reroutage en cascade. Le dernier service rerouté peut lui-même effectuer aussi un reroutage aveugle ou accompagné vers un autre service et ainsi de suite jusqu’à N reroutages en cascade (N étant fonction du service RI utilisé). Les deux modes, aveugle ou accompagné, peuvent être enchaînés indifféremment lors de reroutages en cascade. Ce type de reroutage offre les mêmes possibilités qu'un reroutage simple (aveugle ou accompagné). Dans sa demande de reroutage, le service rerouteur peut indiquer au RI qu'il interdit au rerouté le reroutage en cascade. Alors dans ce cas, si le rerouté envoie au RI une demande de reroutage vers un service autre que le précédent rerouteur, le PCS refusera cette demande.

2.3.3 Service Commande Possibilité

Le service Commande Possibilité permet à l'appelé B de recevoir des informations concernant le contexte de l'appel en cours :

Numéro du service appelé ; Numéro du service appelant ; Données de contexte (uniquement dans le cas du Reroutage, pour permettre au rerouteur de

transmettre des informations au rerouté) ; Données en retour (uniquement dans le cas du Reroutage) ; Information de marquage : cette information permet de détecter les appels directs sur les Numéros de

Réception.

Le service Commande Possibilité est activé via le Web Service informationsAppel. A noter qu’en mode Web Service, la transmission de ces informations se fait en réponse à une requête du client. Un cas d’usage peut illustrer ce fonctionnement : un client souhaite interdire les appels directs sur un site de réception en ToIP (la transmission du n° du service appelé dans la signalisation est alors indisponible). Lorsqu’un appel est présenté, le client peut faire une requête « informationAppel » et vérifier ainsi qu’il ne s’agit pas d’un appel direct sur le NR.


10/47


Edition Aout 2016

2.4 L'accès aux services

L'accès aux services offerts par le PAC se fait via des services web, Web Services, que le PAC met à disposition des clients suivant un modèle client-serveur. Ces Web Services ont été définis suivant le protocole SOAP et les clients y accèdent via un mécanisme de requête/réponse. Les requêtes et réponses échangées entre le Client et le PAC sont encodées en format XML selon le protocole SOAP puis transmises sur HTTPS. L'accès aux services est limité aux clients ayant été préalablement inscrits sur le PAC et pour lesquels l'autorisation d'accès a été accordée. Chaque client a un identifiant et un mot de passe qui sont envoyés dans l'entête https de chaque requête, ainsi toute demande de service est liée à un client.


11/47


Edition Aout 2016

3 Utilisations des Web Services côté client Les informations nécessaires pour la création des requêtes et l'interprétation des réponses entre le client et le PAC sont spécifiées dans un fichier WSDL (Web Service Description Layer). Chaque Web Service dispose de son propre fichier WSDL, fourni en annexe de ce document. En ce qui concerne les échanges liées à l'utilisation des Web Services le dispositif du client qui émet des requêtes depuis le site Client est considéré comme un WSC (Web Service Consumer) et le PAC, serveur qui fournit les Web Services, est considéré comme un WSP (Web Service Provider).

3.1 WSDL - Le contrat d’interface entre le client et le serveur

Le WSDL décrit notamment les méthodes exposées du Web Service, les paramètres entrants et sortants de chaque méthode ainsi que son URL d’accès. Ci-dessous un extrait du WSDL pour la méthode d'exemple nomWebService :

1. la méthode avec ses paramètres et les messages en entrée, sortie et erreur :

<wsdl:operation name="nomWebService" parameterOrder="in0 in1 in2"> <wsdl:input message="intf:nomWebServiceRequest" name="nomWebServiceRequest"/> <wsdl:output message="intf:nomWebServiceResponse" name="nomWebServiceResponse"/> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException"/> </wsdl:operation>

2. le détail des messages et ses paramètres : <wsdl:message name="nomWebServiceRequest"> <wsdl:part name="in0" type="tns1:Alias"/> <wsdl:part name="in1" type="tns1:RefAppel"/> <wsdl:part name="in2" type="tns1:Parametre3"/> </wsdl:message>

3. le détail des paramètres : <complexType name="Alias"> <sequence> <element name="alias" nillable="true" type="xsd:string"/> </sequence> </complexType> <complexType name="Response"> <sequence> <element name="codeRetour" nillable="true" type="xsd:string"/> <element name="description" nillable="true" type="xsd:string"/> <element name="idRequete" nillable="true" type="xsd:string"/> </sequence> </complexType> Remarque importante : les paramètres fonctionnellement facultatifs sont déclarés comme "nillable". Néanmoins, ceci ne signifie pas qu’ils peuvent être omis des requêtes. Même en cas de non utilisation "fonctionnelle", ils devront être inclus dans les requêtes, sans valeur associée.


12/47


Edition Aout 2016

4. l’ URL d’accès : <wsdl:service name="nomService"> <wsdl:port binding="impl:contactSoapBinding" name="contact"> <wsdlsoap:address location=

"https://portailapicontact.orange-business.com/pac-server/services/contact"/> </wsdl:port> </wsdl:service> Voir les fichiers WSDL complets en annexe.

3.2 Pré-requis environnement applicatif pour l’accès à l'API du PAC

Les fichiers WSDL fournis permettent de générer les classes/proxys implémentant les appels aux Web Services du PAC. Cette implémentation est à la charge du client. Le WSC devra avoir accès à l'URL du service fourni par le WSP, https://portailapicontact.orange-business.com/pac-server/services/contact, à travers d'Internet. L'accès sera fait par https sur le port 443. Pour certains environnements n'offrant pas la possibilité de faire tourner un moteur Web Services ou n'ayant pas d'accès à Internet, le client peut choisir de développer un applicatif intermédiaire de médiation (proxy) entre l'applicatif client et le WSP. Ce cas de figure (composant intermédiaire de médiation) peut également être mis en œuvre pour réaliser un accès centralisé au WSP par plusieurs applicatifs clients (cf. schéma ci-dessous). C’est alors cet applicatif intermédiaire qui jouera le rôle de WSC.

Figure 1 : Mise en œuvre d'un serveur de médiation pour accès au WSP

Serveur de médiation

WSC

WSP

Applicatif client 1

Applicatif client 2

Internet


13/47


Edition Aout 2016

3.3 Exigences de sécurité pour l’accès aux services web du PAC

Des mécanismes de protection permettant de garantir l'authentification, la confidentialité, l'intégrité du contenu et le respect de la vie privée, qui sont des exigences essentielles du point de vue d'Orange Business Services, sont mis en œuvre pour l'accès par les applicatifs clients externes au PAC via son API Web Service. 1. Authentification

Orange Business Services utilise un système d'Authentification par certificat serveur et mécanisme d'authentification BASIC du protocole HTTP. Le certificat permet d'assurer l'identité du serveur et l'authentification BASIC du protocole HTTP, celle du client. Le mécanisme BASIC HTTP consiste à protéger l'accès au PAC par un identifiant client et un mot de passe propre à chaque client. Ces données sont systématiquement positionnées dans l'en-tête http de chaque requête envoyée par le WSC au WSP. Elles permettent d'identifier de façon unique le WSC vis-à-vis du WSP.

2. Confidentialité Les données échangées sur Internet entre le WSC et le WSP ne circulent pas en clair. Le dialogue est chiffré et s'effectue en HTTPS basé sur TLS (Transport Layer Security).

3. Intégrité du contenu Le protocole de communication TLS vérifie l’intégrité des données transmises et assure que les données ne soient pas corrompues.

3.4 Modalités pour Mise en place d'un accès au PAC

Lors de la configuration d'un accès aux services web du PAC pour un client, les éléments suivants sont mis en place.

Un identifiant de compte client PAC et un mot de passe sont remis au client et/ou au partenaire intégrateur ainsi que les paramètres d'accès et les spécifications techniques d'accès au service, STAS. Ces identifiants permettent au WSC de s'authentifier auprès du WSP. Si le client le souhaite il pourra demander (au travers de son bon de commande) la génération de plusieurs alias permettant, entre autres, d'identifier les requêtes de ses différents WSC.


14/47


Edition Aout 2016

3.4.1 Le mot de passe client pour le PAC

Pour tout client accédant au PAC il lui est fourni par l’administration des ventes (via le compte-rendu de livraison) un identifiant de client et un mot de passe qu’il utilise dans toutes les requêtes échangées entre le WSC et le WSP. Pour assurer un niveau de sécurité optimal Orange Business Services encourage vivement ses clients à changer leur mot de passe régulièrement, tous les 6 mois par exemple, ou lorsqu'ils ont des craintes concernant la confidentialité du mot de passe. Le changement du mot de passe se fait en s’adressant à l’ADV et n’est pas facturé. Lorsque le nouveau mot de passe lui est communiqué le client a 30 jours pour effectuer tous ses changements ; pendant cette période l'ancien mot de passe ainsi que le nouveau sont valables ; après ces 30 jours, l’ancien mot de passe devient inactif. Le client ne pourra pas choisir son identifiant client ni son mot de passe qui seront assignés et générés par Orange Business Services.

3.4.2 La référence d'appel

Pour chaque appel concernant un numéro Contact utilisant le PAC (et selon le paramétrage adéquat des NA/NR) une référence est générée par le RI et acheminée dans la signalisation téléphonique jusqu’au site de réception de l’appel. Cette référence permet d'identifier de façon unique l'appel et devra être renseignée par le WSC dans le champ referenceAppel de chaque requête émise vers le WSP concernant cet appel. Le client doit choisir la façon de recevoir cette référence :

Dans le NDS (Numéro de désignation secondaire) : dans ce cas, le n° appelant qui est habituellement contenu dans ce champ est remplacé par cette référence et n’est plus transmis ;

Dans l’IUU : lorsque cette option est choisie, le système de commutation privé reçoit dans le message d'établissement d'appel, la référence d'appel dans l'élément d’information IUU. La récupération et le codage de ce champ d'information peut dépendre du type de service de terminaison du client, et doit donc être étudiée lorsque souhaitée.

Des restrictions techniques pour l’utilisation du NDS et/ou de l’IUU peuvent exister selon les offres d’accès téléphonique du client. Se renseigner auprès de l’ingénieur technico-commercial pour connaître ces restrictions.

3.4.3 Les alias

Les alias sont des identifiants permettant de différencier les différents sites du client qui vont envoyer les requêtes vers le PAC, ou des groupes de NR, ou encore un groupe de NA. La configuration précise doit être adaptée en fonction de l'architecture et des besoins du client. Ces alias sont donnés par le client (qui peut donc adapter la granularité à son organisation des flux) et ils seront au nombre maximum de 15 alias par NA. Le nom de l’alias doit correspondre à une chaîne de caractères non vide et composé uniquement des caractères [A-Z], [a-z], [0-9] ou ‘-‘, et il ne doit pas commencer par ‘-‘. Sa longueur maximum est de 40 caractères. Par défaut, si le client ne choisit pas d’alias, un alias unique lui est automatiquement octroyé. Deux exemples illustrant l'intérêt de l'utilisation des alias sont présentés ci-dessous. Cas 1 : un client monosite utilise le reroutage sur son centre d'appel. Ce centre d'appel reçoit des flux de 3 NA. Tout agent du centre d'appel traite les appels en provenance des 3 NA (pas de spécialisation des agents pas NA). Le client implémente son WSC pour que l'alias envoyé dans chaque requête dépende du NA concerné par l'appel en cours (les alias sont par exemple : NA1, NA2, NA3).


15/47


Edition Aout 2016

Si, pour une raison quelconque, les demandes de reroutage effectuées pour les appels reçus sur un des NA connaissent un fort taux d'échec, les agents n'étant pas spécialisés par NA, le client pourra juste signaler que "un grand nombre de demandes de reroutages échoue". Grâce à l'utilisation des alias, Orange Business Services pourra détecter rapidement que le problème ne concerne qu'un seul des 3 NA, investiguer sur sa configuration, et donc diagnostiquer et régler le problème. Cas 2 : un client multi-site utilise différents alias caractérisant ses différents équipements WSC émettant des requêtes. Si un disfonctionnement affecte un de ses WSC et produit un nombre considérable de requêtes erronées s’apparentant à du « spamming », Orange Business Services pourra bloquer les requêtes venant de ce WSC sans affecter le traitement des requêtes des autres WSC (identifiés par leurs alias) qui fonctionnent correctement.


16/47


Edition Aout 2016

4 Requêtes d'accès aux services du PAC Pour chaque demande de service le WSC doit envoyer une requête https au WSP. Dans le corps de cette requête on trouve la demande de service encodée en format XML selon le protocole SOAP, tel que défini dans le fichier WSDL. Cette requête contient tous les paramètres permettant d'identifier le client et l'appel et permettant d'offrir le service.

SOAP WSC WSP Plate-forme

services

Requête

Requête

Réponse Réponse

SOAP

Propriétaire

Orange

Chgt de tarif

Chgt de tarif

Chaque fois que le WSC émet une requête vers le WSP elle reste en attente bloquante sur la réponse du WSP. Cette réponse contient le résultat du traitement de la demande de service et un identifiant de requête.

4.1 La gestion des erreurs

Les erreurs générées par le WSP sont remontées au WSC :

Via des codes d'erreur HTTP dans les cas de problèmes d’accès au service demandé (service inconnu, échec authentification,…) ;

Via des FAULT dans les cas de non respect du contrat d’interface (paramètre obligatoire non

renseigné…) ou d’impossibilité de rendre le service (pas de session avec la plate-forme de services…). Ces FAULT contiennent au minimum une description de l’erreur rencontrée et un code d’erreur.

Le type d’erreurs remontées est décrit en annexe. Remarque : FAULT est un mécanisme intégré à SOAP, équivalent aux exceptions Java. Les FAULT sont envoyés dans le corps du message SOAP de réponse vers le client.

4.2 Gestion des connexions

Les clients accèdent au serveur PAC via une liaison IP sur laquelle sont transmises des requêtes et réponses HTTPS.


17/47


Edition Aout 2016

5 Description des Web Services Dans ce document on différencie les notions de service et Web Service. Les services, tels que présentés en paragraphe §2, concernent les fonctionnalités offertes par le Réseau Intelligent (RI) à travers les offres Contact. Les Web Services concernent les requêtes envoyées par le WSC vers le WSP pour activer ces fonctionnalités. Ci-dessous la correspondance service / Web Service :

Service de changement de tarif en cours de communication2 activé via le Web Service changementTarifExt ;

Service de reroutage en aveugle activé via les Web Services reroutageAveugle et reConnect (pour le rétro-appel) ;

Service de reroutage accompagné activé via les Web Services reroutageAccompagne, reroutageAccompagneSup, demandeEtatRerAccSup, demandeEtatFinalRerAccSup, vaEtVient et reConnect ;

Service Commande Possibilité activé via le Web Service informationsAppel.

5.1 ChangementTarifExt

Ce Web Service permet au client de demander la modification du tarif appelant appliqué à une communication sans reroutage (l'invocation du service de changement de tarif en cours de communication n'implique ni modification de l'appelant ni modification de l'appelé). La réponse reçue par le client contiendra le résultat du traitement de la demande effectué par le PAC vers la plate-forme de services. L'identifiant de la requête envoyée par le serveur PAC vers la plate-forme de services est aussi renseigné dans la réponse.

5.1.1 Requête

Paramètre Description O/F *

aliasClient Identifiant de l'alias client faisant la demande F

referenceAppel Référence de l'appel concerné par la demande (telle que fournie par le réseau)

O

palierTarifaire Nouveau code de tarif (ITX) à appliquer : 255 pour l’ATPi O

* O/F : Obligatoire/Facultatif

5.1.2 Réponse

Paramètre Description O/F

codeRetour Résultat de la demande de changement de tarif O

description Description du codeRetour O

idRequete Identifiant de la requête à laquelle le message compte rendu fait référence O

La liste des codes retour et leurs descriptions sont détaillés dans le paragraphe suivant.

2 En C+S, ce service n’est plus utilisé que pour l’ATPi


18/47


Edition Aout 2016

5.1.3 Codes retour

Code retour Description

1100 Changement de tarif en succès

1111 Changement de tarif refusé par la plate-forme de services : droits non-conformes

1112 Changement de tarif refusé par l'appelant

1113 Changement de tarif refusé pour une autre cause

1114 Changement de tarif refusé par la plate-forme de services : nombre maximum de changements de tarif atteint

1115 Changement de tarif refusé par la plate-forme de services : tarif non autorisé

1120 Problème de communication avec la plate-forme de services

1121 Changement de tarif refusé par la plate-forme de service : référence ne correspondant à aucun appel existant

1126 Changement de tarif refusé par la plate-forme de service : autre cause

1199 Changement de tarif refusé par la plate-forme de service : autre cause

Précisions : En C+S, ce service n’est plus utilisé que pour l’ATPi (Annonce Tarifaire Personnalisée Interruptible), avec l’ITX 255.

5.2 reroutageAveugle et reConnect

Les Web Services reroutageAveugle et reConnect sont nécessaires pour activer les différentes fonctionnalités liées au service de reroutage aveugle. L'utilisation de l'un ou l'autre dépend de l'état de l'appel et de l'action requise : voir paragraphes suivants pour plus de détails.

5.2.1 reroutageAveugle

Ce Web Service permet au client de demander la mise en relation entre l'appelant et un service (ou numéro d'annuaire) rerouté, sans dialogue préalable du client avec le rerouté. La réponse reçue par le client contiendra le résultat du traitement de la demande effectué par le PAC vers la plate-forme de services. L'identifiant de la requête envoyée par le serveur PAC vers la plate-forme de services est aussi renseigné dans la réponse.


19/47


Edition Aout 2016

5.2.1.1 Requête




O

palierTarifaire Code de tarif à appliquer (sans objet en C+S) F

destination Destination du reroutage O

donneesContexteHEXA Données de contexte en format hexadécimal (informations transférées au rerouté)

F

donneesContexteASCII Données de contexte en format ASCII (informations transférées au rerouté)

F

NASretour NA en retour (utilisé pour le reroutage retour) F

donneesContexteRetour Données de contexte en retour (informations transférées au rerouteur)

F

typeTaxation Spécifie le type de taxation à appliquer au demandeur : inopérant en C+S

F

reroutageCascadeInterdit Spécifie si le reroutage en cascade est interdit F

POSSIBILITESinterdite Spécifie si la commande POSSIBILITES est interdite F

transmissionIdentiteRestreinte Spécifie si la transmission de l'identité de l'appelant est autorisée

F

Informations complémentaires sur certains paramètres : Paramètre destination : Le contenu peut être :

Soit un numéro téléphonique dans les cas suivants : o reroutage vers un NA ; o reroutage vers un numéro d'annuaire ou un service spécial ; o reroutage vers un autre NR du même NA ;

soit le mnémonique du service appelé (caractères alphanumériques). Si le paramètre est vide dans la demande de reroutage, il s’agit d’un reroutage arrière (dans ce cas, le type de reroutage sera le premier : reroutage vers un autre NA) : le PCS effectue un reroutage vers le rerouteur précédent. L'appel du service rerouteur est fait conformément aux paramètres du reroutage précédent (données en retour) et aux paramètres caractéristiques du service (transmission de l’origine de l’appel, etc.). Cette demande de reroutage arrière est acceptée par le PCS, même si le rerouteur précédent a interdit le reroutage en cascade dans sa demande de reroutage. Le service rerouté peut également transmettre des données de contexte. Paramètre typeTaxation : Ce paramètre peut prendre les valeurs :

0 : taxation contrôlée par le service rerouteur; 1 : taxation définie par le service-réseau.

NB : ce paramètre devient inopérant en C+S : il n’y a plus de modulation tarifaire en cours d’appel. Le tableau ci-dessous précise les traitements effectués par le RI en fonction de la valeur de ce paramètre et du type (déterminé par le RI) de destination de reroutage : typeTaxation Type de la

destination du reroutage

Traitements sur la taxation

'0' – taxation définie par le service rerouteur

NA Pas de changement de tarif (équivalent au reroutage indéfini vers NA – type 5)


NR Pas de changement de tarif (équivalent au reroutage indéfini vers NR – type 5,6,7)

'0' – taxation définie par le N° Pas de changement de tarif


20/47


Edition Aout 2016

service rerouteur d'annuaire (équivalent au reroutage indéfini vers N° d'annuaire – type 5)


Service spécial

Pas de changement de tarif (équivalent au reroutage indéfini vers Service Spécial – type 5)

'1' – taxation définie par le service réseau

NA En C+S : pas de changement de tarif (équivalent au reroutage vers un NA - type 1)

1' – taxation définie par le service réseau

NR En C+S : pas de changement de tarif (équivalent au reroutage vers N° annuaire – type 3)


N° d'annuaire

En C+S : pas de changement de tarif (équivalent au reroutage vers N° annuaire - type 3)


N° spécial En C+S : pas de changement de tarif (équivalent au reroutage vers service spécial – type 3)

Paramètre reroutageCascadeInterdit : Ce paramètre peut prendre les valeurs :

0 : reroutage en cascade autorisé; 1 : reroutage en cascade interdit.

Si ce paramètre est présent avec la valeur 1, toute demande de reroutage du service rerouté vers un service autre que le reroutage arrière vers le service rerouteur sera refusée. Seul le reroutage vers le service rerouteur est autorisé. Paramètre POSSIBILITESinterdite : Ce paramètre peut prendre les valeurs :

0 : service "commande possibilité" autorisé; 1 : service "commande possibilité" interdit.

Un NA qui a droit au service "commande possibilité" peut l’interdire pour un reroutage non transparent (ainsi que les suivants). Cette interdiction est maintenue en cas de reroutages non transparents en cascade (droits délégués par le précédent rerouteur). Lorsqu'il est utilisé pour les autres types de reroutage, le paramètre est ignoré. Paramètre transmissionIdentiteRestreinte : Ce paramètre peut prendre les valeurs :

0 : transmission; 1 : pas de transmission.

Un NA qui a droit à la transmission de l’identité appelant (sous forme de numéro, de département, ou d'indicatif pays) peut l'interdire pour un reroutage non transparent (ainsi que les suivants). Cette interdiction est maintenue en cas de reroutages non transparents en cascade (droits délégués par le précédent rerouteur). De même, un NA possédant la transmission de l'identité appelant sous forme de numéro peut réduire cette transmission au format département ou indicatif pays pour un reroutage non transparent (ainsi que les suivants). Cette interdiction est maintenue en cas de reroutages non transparents en cascade (droits délégués par le précédent rerouteur). Lorsqu'il est utilisé pour les autres types de reroutage, le paramètre est ignoré.

5.2.1.2 Réponse


codeRetour Résultat de la demande de reroutage O





21/47


Edition Aout 2016

5.2.1.3 Codes retour


1200 Reroutage aveugle en succès

1201 Echec reroutage aveugle : échec réseau

1202 Echec reroutage aveugle : occupation

1203 Echec reroutage aveugle : non réponse

1205 Echec reroutage aveugle : raccrochage appelant


1221 Reroutage aveugle refusé par la plate-forme de service : référence ne correspondant à aucun appel existant

1222 Reroutage aveugle refusé par la plate-forme de service : droits non-conformes

1223 Reroutage aveugle refusé par la plate-forme de service : reroutage en cascade non autorisé par le rerouteur

1224 Reroutage aveugle refusé par la plate-forme de service : numéro de téléphone non valide

1225 Reroutage aveugle refusé par la plate-forme de service : NA ou mnémonique inconnu

1226 Reroutage aveugle refusé par la plate-forme de service : autre cause

1299 Reroutage aveugle refusé par la plate-forme de service : autre cause

5.2.2 reConnect

Ce Web Service permet au client, dans le cadre d'un reroutage aveugle, de mettre fin à la tentative de reroutage avant le décrochage du service rerouté (fonction rétro-appel). La réponse reçue par le client contiendra le résultat du traitement de la demande effectué par le PAC vers la plate-forme de services. L'identifiant de la requête envoyée par le serveur PAC vers la plate-forme de services est aussi renseigné dans la réponse.

5.2.2.1 Requête




O

5.2.2.2 Réponse


codeRetour Résultat de la demande de reConnect O






1500 Reconnect en succès


1521 Reconnect refusé par la plate-forme de service : référence ne correspondant à aucun appel existant

1522 Reconnect refusé par la plate-forme de service : droits non-conformes

1526 Reconnect refusé par la plate-forme de service : autre cause



22/47


Edition Aout 2016

5.3 reroutageAccompagne, reroutageAccompagneSup, demandeEtatRerAccSup, demandeEtatFinalRerAccSup, vaEtVient et reConnect

Les Web Services reroutageAccompagne, reroutageAccompagneSup, demandeEtatRerAccSup, demandeEtatFinalRerAccSup, vaEtVient et reConnect sont nécessaires pour activer les différentes fonctionnalités liées au service de reroutage accompagné. L'utilisation de l'un ou l'autre dépend de l'état de l'appel et de l'action requise : voir paragraphes suivants pour plus de détails.

5.3.1 reroutageAccompagne

Ce Web Service permet au client appelé (B) de demander l'établissement d'un double appel vers un usager C (l'appelant A étant mis en garde), puis de mettre en relation l’appelant A avec l’usager C.

La réponse reçue par le client contiendra le résultat du traitement de la demande effectué par le PAC vers la plate-forme de services. L'identifiant de la requête envoyée par le serveur PAC vers la plate-forme de services est aussi renseigné dans la réponse.

5.3.1.1 Requête


AliasClient Identifiant de l'alias client faisant la demande F


O

Destination Destination du reroutage O

palierTarifaire Code de tarif à appliquer : sans objet en C+S F


F


F

NASretour NA en retour F


F

typeTaxation Spécifie le type de taxation à appliquer au demandeur : devient inopérant en C+S

F




F



soit le mnémonique du service appelé (caractères alphanumériques). Si le paramètre est vide dans la demande de reroutage, il s’agit d’un reroutage arrière (dans ce cas, le type de reroutage sera le premier : reroutage vers un autre NA) : le PCS effectue un reroutage vers le rerouteur précédent. L'appel du service rerouteur est fait conformément aux paramètres du reroutage précédent (données en retour) et aux paramètres caractéristiques du service (transmission de l’origine de l’appel, etc.). Cette demande de reroutage arrière est acceptée par le PCS, même si le rerouteur précédent a interdit le


23/47


Edition Aout 2016

reroutage en cascade dans sa demande de reroutage. Le service rerouté peut également transmettre des données de contexte. Paramètre typeTaxation : Ce paramètre peut prendre les valeurs :


NB : ce paramètre devient inopérant en C+S : il n’y a plus de modulation tarifaire en cours d’appel. Paramètre reroutageCascadeInterdit : Ce paramètre peut prendre les valeurs :






Un NA, qui a droit à la transmission de l’identité appelant (sous forme de numéro, de département, ou d'indicatif pays), peut l'interdire pour un reroutage non transparent (ainsi que les suivants). Cette interdiction est maintenue en cas de reroutages non transparents en cascade (droits délégués par le précédent rerouteur). De même, un NA possédant la transmission de l'identité appelant sous forme de numéro peut réduire cette transmission au format département ou indicatif pays pour un reroutage non transparent (ainsi que les suivants). Cette interdiction est maintenue en cas de reroutages non transparents en cascade (droits délégués par le précédent rerouteur). Lorsqu'il est utilisé pour les autres types de reroutage, le paramètre est ignoré.

5.3.1.2 Réponse


codeRetour Résultat de la demande de reroutage accompagné O




24/47


Edition Aout 2016




1300 Reroutage accompagné : appel du rerouté en succès

1301 Echec reroutage accompagné : échec réseau

1302 Echec reroutage accompagné : occupation

1303 Echec reroutage accompagné : non réponse

1305 Echec reroutage accompagné : raccrochage appelant


1321 Reroutage accompagné refusé par la plate-forme de service : référence ne correspondant à aucun appel existant

1322 Reroutage accompagné refusé par la plate-forme de service : droits non-conformes

1323 Reroutage accompagné refusé par la plate-forme de service : reroutage en cascade non autorisé par le rerouteur

1324 Reroutage accompagné refusé par la plate-forme de service : numéro de téléphone non valide

1325 Reroutage accompagné refusé par la plate-forme de service : NA ou mnémonique inconnu

1326 Reroutage accompagné refusé par la plate-forme de service : autre cause


5.3.2 reroutageAccompagneSup

Ce Web Service permet, comme le Web Service reroutageAccompagne, au client appelé (B) de demander l'établissement d'un double appel vers un usager C (l'appelant A étant mis en garde), puis de mettre en relation l’appelant A avec l’usager C. L’utilisation de ce Web Service permet en outre de demander par la suite l’état du traitement du reroutage accompagné par le PCS, via l’utilisation des Web Services demandeEtatRerAccSup et demandeEtatFinalRerAccSup.



25/47


Edition Aout 2016

5.3.2.1 Requête


AliasClient Identifiant de l'alias client faisant la demande F


O

Destination Destination du reroutage O

maxSuiviConv Durée maximale de suivi de conversation F

palierTarifaire Code de tarif à appliquer (sans objet en C+S) F


F


F

NASretour NA en retour F


F

typeTaxation Spécifie le type de taxation à appliquer au demandeur (inopérant en C+S)

F




F



soit le mnémonique du service appelé (caractères alphanumériques), dans le cas : o reroutage vers un service par mnémonique.

Si le paramètre est vide dans la demande de reroutage, il s’agit d’un reroutage arrière (dans ce cas, le type de reroutage sera le premier : reroutage vers un autre NA) : le PCS effectue un reroutage vers le rerouteur précédent. L'appel du service rerouteur est fait conformément aux paramètres du reroutage précédent (données en retour) et aux paramètres caractéristiques du service (transmission de l’origine de l’appel, etc.). Cette demande de reroutage arrière est acceptée par le PCS, même si le rerouteur précédent a interdit le reroutage en cascade dans sa demande de reroutage. Le service rerouté peut également transmettre des données de contexte. Paramètre maxSuiviConv : Ce paramètre permet de déterminer la durée pendant laquelle le PAC va superviser et garder en mémoire l’état du reroutage accompagné après décroché du service rerouté, et répondra à une demande d’état (en cours ou final) de ce reroutage. Si le reroutage accompagné se termine par un échec (code retour autre que 1300) le PAC arrêtera de superviser l’état de celui-ci dès qu’il aura envoyé la réponse. Toute demande d’état (en cours ou final) reçue après l’envoi de cette réponse donnera lieu à un échec (cf. §5.3.3 et §5.3.4). Si le reroutage accompagné se termine en succès (code retour 1300), alors le PAC continuera de superviser l’état de son déroulement pendant la durée (en secondes) spécifiée dans le paramètre maxSuiviConv. Ce paramètre est facultatif : en cas d’absence, la valeur utilisée par défaut par le PAC est 30s. Si le paramètre est renseigné, sa valeur doit être un entier compris entre 1 et 90.


26/47


Edition Aout 2016

Paramètre typeTaxation : Ce paramètre peut prendre les valeurs :


NB : ce paramètre devient inopérant en C+S : il n’y a plus de modulation tarifaire en cours d’appel. Paramètre reroutageCascadeInterdit : Ce paramètre peut prendre les valeurs :






Un NA qui a droit à la transmission de l’identité appelant (sous forme de numéro, de département, ou d'indicatif pays) peut l'interdire pour un reroutage non transparent (ainsi que les suivants). Cette interdiction est maintenue en cas de reroutages non transparents en cascade (droits délégués par le précédent rerouteur). De même, un NA possédant la transmission de l'identité appelant sous forme de numéro peut réduire cette transmission au format département ou indicatif pays pour un reroutage non transparent (ainsi que les suivants). Cette interdiction est maintenue en cas de reroutages non transparents en cascade (droits délégués par le précédent rerouteur). Lorsqu'il est utilisé pour les autres types de reroutage, le paramètre est ignoré.

5.3.2.2 Réponse


codeRetour Résultat de la demande de reroutage accompagné O






1300 Reroutage accompagné : appel du rerouté en succès

1301 Echec reroutage accompagné : échec réseau

1302 Echec reroutage accompagné : occupation

1303 Echec reroutage accompagné : non réponse


27/47


Edition Aout 2016


1305 Echec reroutage accompagné : raccrochage appelant


1321 Reroutage accompagné refusé par la plate-forme de service : référence ne correspondant à aucun appel existant

1322 Reroutage accompagné refusé par la plate-forme de service : droits non-conformes

1323 Reroutage accompagné refusé par la plate-forme de service : reroutage en cascade non autorisé par le rerouteur

1324 Reroutage accompagné refusé par la plate-forme de service : numéro de téléphone non valide

1325 Reroutage accompagné refusé par la plate-forme de service : NA ou mnémonique inconnu



5.3.3 demandeEtatRerAccSup

Ce Web Service permet au client de demander l’état instantané d’un reroutage accompagné dont il a auparavant fait la demande via une requête du Web Service reroutageAccompagneSup. La réponse reçue par le client contiendra l’information de l’état du reroutage accompagné Sup au moment du traitement de la requête.

5.3.3.1 Requête



referenceAppel Référence de l'appel pour lequel la demande de reroutage accompagné dont on veut connaitre l’état a été faite

O

5.3.3.2 Réponse


codeRetour Résultat de la demande d’état courant d’un reroutage accompagné sup O






1900 Reroutage accompagné terminé : transfert effectif

1901 Reroutage accompagné terminé : raccrochage appelant

1902 Reroutage accompagné terminé : déconnecté par le rerouté

1903 Reroutage accompagné toujours en cours – phase intermédiaire

1904 Echec du reroutage accompagné

1905 Reroutage accompagné toujours en cours – phase initiale

1921 Référence d’appel ne correspondant à aucun reroutage accompagné en cours

Informations complémentaires les codes retours : Code retour 1900 : ce code signifie que le reroutage accompagné a donné lieu à réponse du service destinataire et que le rerouteur a complété le reroutage, et donc que l’appelant a été mis en relation avec le destinataire.


28/47


Edition Aout 2016

Code retour 1901 : ce code signifie que le reroutage accompagné a donné lieu à réponse du service destinataire du reroutage, mais que l’appelant a raccroché avant que le rerouteur ne termine le transfert ou ne décide de l’annuler par envoi d’un reConnect. Code retour 1902 : ce code signifie que le reroutage accompagné a donné lieu à réponse du service destinataire du reroutage puis que le rerouteur a repris la conversation avec l’appelant (via l’utilisation du Web Service reConnect). Code retour 1903 : ce code retour signifie que le reroutage accompagné a donné lieu à réponse du service destinataire du reroutage, mais que le rerouteur est toujours en communication avec celui-ci, ou avec le demandeur suite à l’utilisation du Web Service vaEtVient (les éventuels basculements du rerouteur entre A et C ne sont pas supervisés par le PAC). Code retour 1904 : ce code retour signifie que le reroutage accompagné a échoué, quel que soit le type d’échec. Le détail de l’échec n’est pas fourni car il est déjà envoyé dans la réponse à la demande de reroutage accompagné. Code retour 1905 : ce code retour signifie que le reroutage accompagné est en cours et n’a donné lieu ni à un échec ni à réponse du service destinataire. En pratique cela signifie que l’appel vers le service destinataire est en cours d’établissement ou en phase de sonnerie. Code retour 1921 : ce code est envoyé lorsque la référence d’appel fournie ne correspond à aucun reroutage accompagné actuellement supervisé par le PAC. Ceci peut se produire :

Si aucune requête de reroutage accompagné Sup n’a effectivement été émise pour cette référence; Si une requête a été émise mais que le reroutage a échoué et que le PAC a déjà envoyé la réponse à la

requête; Si une requête a été émise et que le reroutage a été un succès, mais que la durée écoulée depuis le

décroché du service destinataire du reroutage est supérieure au paramètre maxSuiviConv associé à la requête de reroutage accompagné Sup.

5.3.4 demandeEtatFinalRerAccSup

Ce Web Service permet au client de demander l’état final d’un reroutage accompagné dont il a auparavant fait la demande via une requête du Web Service reroutageAccompagneSup. La réponse reçue par le client contiendra l’information de l’état final du reroutage accompagné Sup. La réponse du PAC peut être immédiate ou différée selon les cas : Elle sera immédiate dans les cas suivants :

Le PAC ne supervise pas de reroutage accompagné associé à la référence d’appel fournie en paramètre ;

Le PAC supervise un reroutage accompagné associé à la référence d’appel fournie en paramètre et son état final est déjà connu.

Elle sera différée si le PAC supervise un reroutage accompagné associé à la référence d’appel fournie en paramètre dont l’état final n’est pas encore connu. Le §5.3.4.3 explicite les différents cas d’usages associés aux codes retours envoyés.

5.3.4.1 Requête



referenceAppel Référence de l'appel pour lequel la demande de reroutage accompagné dont on veut connaitre l’état final a été faite

O

5.3.4.2 Réponse


codeRetour Résultat de la demande d’état final d’un reroutage accompagné sup O


29/47


Edition Aout 2016







1800 Etat final : transfert effectif

1801 Etat final : raccrochage appelant

1802 Etat final : déconnecté par le rerouté

1803 Reroutage accompagné toujours en cours

1804 Etat final : échec du reroutage accompagné

1821 Référence d’appel ne correspondant à aucun reroutage accompagné en cours

Informations complémentaires les codes retours : Code retour 1800 : ce code signifie que le reroutage accompagné a donné lieu à réponse du service destinataire et que le rerouteur a complété le reroutage, et donc que l’appelant a été mis en relation avec le destinataire. Code retour 1801 : ce code signifie que le reroutage accompagné a donné lieu à réponse du service destinataire du reroutage, mais que l’appelant a raccroché avant que le rerouteur ne termine le transfert ou ne décide de l’annuler par envoi d’un reConnect. Code retour 1802 : ce code signifie que le reroutage accompagné a donné lieu à réponse du service destinataire du reroutage puis que le rerouteur a repris la conversation avec l’appelant (via l’utilisation du Web Service reConnect). Code retour 1803 : ce code retour signifie que le reroutage accompagné a donné lieu à réponse du service destinataire du reroutage et qu’après le nombre de secondes correspondant à maxSuiviConv le reroutage était toujours dans un état intermédiaire. Code retour 1804 : ce code retour signifie que le reroutage accompagné a échoué, quel que soit le type d’échec. Le détail de l’échec n’est pas fourni car il est déjà envoyé dans la réponse à la demande de reroutage accompagné. Code retour 1821 : ce code est envoyé lorsque la référence d’appel fournie ne correspond à aucun reroutage accompagné actuellement supervisé par le PAC. Ceci peut se produire :

Si aucune requête de reroutage accompagné Sup n’a effectivement été émise pour cette référence; Si une requête a été émise mais que le reroutage a échoué et que le PAC a déjà envoyé la réponse à la

requête; Si une requête a été émise et que le reroutage a été un succès, mais que la durée écoulée depuis le

décroché du service destinataire du reroutage est supérieure au paramètre maxSuiviConv associé à la requête de reroutage accompagné Sup.

5.3.5 vaEtVient

Ce Web Service permet au client appelé (B), dans le cadre d'un reroutage accompagné, d'effectuer un va-et-vient, c’est-à-dire, de passer alternativement d'une conversation avec l'usager C à une conversation avec l'appelant A (l'autre correspondant étant mis en garde).


30/47


Edition Aout 2016


5.3.5.1 Requête




O

5.3.5.2 Réponse


codeRetour Résultat de la demande de vaEtVient. O






1400 Va et vient : requête envoyée à la plate-forme de service


1421 Va et Vient refusé par la plate-forme de service : référence ne correspondant à aucun appel existant

1422 Va et Vient refusé par la plate-forme de service : droits non-conformes

1426 Va et Vient refusé par la plate-forme de service : autre cause

1499 Va et Vient refusé par la plate-forme de service : autre cause

5.3.6 reConnect

Ce Web Service permet au client (B), dans le cadre d'un reroutage accompagné, d'effectuer un retro-appel, c’est-à-dire, de libérer l'usager C (pour être reconnecté avec l’appelant A). La réponse reçue par le client contiendra le résultat du traitement de la demande effectué par le PAC vers la plate-forme de services. L'identifiant de la requête envoyée par le serveur PAC vers la plate-forme de services est aussi renseigné dans la réponse.

5.3.6.1 Requête




O

5.3.6.2 Réponse


codeRetour Résultat de la demande de reConnect O





31/47


Edition Aout 2016



1500 Reconnect en succès


1521 Reconnect refusé par la plate-forme de service : référence ne correspondant à aucun appel existant

1522 Reconnect refusé par la plate-forme de service : droits non-conformes




32/47


Edition Aout 2016

5.4 informationsAppel

Ce Web Service permet au client de demander des informations concernant le contexte de l'appel en cours : par exemple le NA appelant, l'origine géographique de l'appel, etc. La réponse reçue par le client contiendra le résultat du traitement de la demande effectué par le PAC vers la plate-forme de services, ainsi que les informations du contexte de l'appel en cours. L'identifiant de la requête envoyée par le serveur PAC vers la plate-forme de services est aussi renseigné dans la réponse.

5.4.1 Requête




O

5.4.2 Réponse


codeRetour Résultat de la demande d'informations d'appel O


idRequete Identifiant de la requête à laquelle le message compte rendu fait référence

O

origineGeographique Origine géographique de l'appelant F

NDSappelant Numéro de Désignation Supplémentaire de l'appelant F


F

informationUsagerUsager Information Usager à Usager F

donnesContexteASCII Données de contexte en format ASCII (informations transférées au rerouté)

F


F

NASappele Numéro du service appelé F

NASappelant Numéro du service rerouteur F

autorisationModifTax Spécifie si la modification de taxation est autorisée ou non F

NDIappele Numéro de Désignation de l'Installation de l'appelé F

marquageReroutage Spécifie si l'appel est passé par le RI F

Informations complémentaires sur certains paramètres : Paramètre origineGeographique : Il contient l'origine géographique de l'appel (paramètre caractéristique du service). Le contenu est le suivant :

soit le numéro du département (appelant national) ; soit le numéro téléphonique de l’appelant (uniquement national) ; soit le code pays/opérateur (cas d'un NA international) ; soit l'indicatif du pays (cas d'un appelant international).

Paramètre NDSappelant : Il contient le NDS (n° de désignation supplémentaire) de l'appelant, lorsque celui-ci a été renseigné par son installation terminale (en cas d'absence de NDS, le NDI n'est pas transmis à sa place dans ce paramètre) et lorsque sa divulgation est autorisée.


33/47


Edition Aout 2016

Paramètre autorisationModifTax : Il contient une information fournie par le RI, qui permet d'informer le serveur que l'appel provient d'un opérateur gérant ou non la modification de tarification en cours de communication. Seul le premier caractère de la chaîne est significatif :

"Y" : modification de taxation autorisée ; "N" : modification de taxation non autorisée.

A noter qu’actuellement, le RI ne transmet l’information que si (comme pour la transmission dans la SUP) l’opérateur ne gère pas le changement de tarif. NB : ce paramètre devient obsolète en C+S : il n’y a plus de modulation tarifaire en cours d’appel.

5.4.3 Codes retour


1600 Informations d'appel fournies


1621 Informations d'appel refusées par la plate-forme de service : référence ne correspondant à aucun appel existant

1622 Informations d'appel refusées par la plate-forme de service : droits non-conformes

1626 Informations d'appel refusées par la plate-forme de service : autre cause

1699 Informations d'appel refusées par la plate-forme de service : autre cause


34/47


Edition Aout 2016

ANNEXE 1: Les erreurs générées par le PAC Ce chapitre décrit uniquement les erreurs fonctionnelles générées par le PAC.

Les erreurs de type http.

Les problèmes d’authentification et autorisation entraînent la levée d’une erreur http par le PAC :

Description de l’erreur Code erreur

Client inconnu 401

Mot de passe incorrect 401

Le statut du client ne lui permet pas de faire des appels de services 401

Le service demandé par le client n’est pas autorisé pour ce client 401

Remarques : Ces codes erreur font référence aux codes http des réponses envoyées au client. Dans ces cas il n'y a

pas de message SOAP de réponse car l'accès au service n'a pas été possible. Ce tableau n’est pas exhaustif car tous les codes d’erreurs http sont susceptibles d’être remontés par

le WSP. N’apparaissent dans ce tableau que les cas liés à des développements métier spécifiques au PAC.

Les erreurs de type fault.

En cas de problème lors du traitement de la requête SOAP (non respect du contrat d’interface ou impossibilité de rendre le service) un message de réponse http avec le code de retour 500 (Erreur Interne de Servlet) est envoyé au client. Dans le corps du message http on trouve un message SOAP contenant l'élément Fault qui précise le type d'erreur. Les erreurs de type Fault levées par le PAC sont :

Description de l’erreur Code erreur Commentaire

Paramètre(s) obligatoire(s) d’appel d’un service non renseigné(s)

1 La description de l’erreur doit contenir la liste des paramètres obligatoires non renseignés

Pas de session plate-forme de service disponible

2

La référence d’appel ne permet pas d’identifier la plate-forme de service à atteindre

7

La taille de la référence d'appel est incorrecte

8

L’alias est inconnu pour ce client 9

Le statut de l’alias ne lui permet pas de faire des appels de services

10

Un des paramètres renseigné a un format incorrect

11

Paramètres incohérents 15

Erreur interne serveur 100


35/47


Edition Aout 2016

ANNEXE 2: Fichiers WSDL Ce chapitre liste les fichiers WSDL correspondant à chaque Web Service. Remarque importante : les paramètres fonctionnellement facultatifs sont déclarés comme "nillable". Néanmoins, ceci ne signifie pas qu’ils peuvent être omis des requêtes. Même en cas de non utilisation "fonctionnelle", ils devront être inclus dans les requêtes, sans valeur associée.

Web Service changementTarifExt

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="urn:francetelecom.com/pac" xmlns:apachesoap="http://xml.apache.org/xml-

soap" xmlns:impl="urn:francetelecom.com/pac-impl" xmlns:intf="urn:francetelecom.com/pac" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns1="http://domain.business.server.pac.francetelecom.com" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:types> <schema targetNamespace="http://domain.business.server.pac.francetelecom.com"

xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://schemas.xmlsoap.org/soap/encoding/" /> <complexType name="Alias"> <sequence> <element name="alias" nillable="true" type="xsd:string" />

</sequence> </complexType>

<complexType name="RefAppel"> <sequence> <element name="refAppel" nillable="true" type="xsd:string" />


<complexType name="PalierTarifaire"> <sequence> <element name="codeTarifaire" nillable="true" type="xsd:string" />


<complexType name="RequestFailureException"> <sequence> <element name="codeErreur" nillable="true" type="xsd:string" /> <element name="idRequete" nillable="true" type="xsd:string" />


<complexType name="Response"> <sequence> <element name="codeRetour" nillable="true" type="xsd:string" /> <element name="description" nillable="true" type="xsd:string" /> <element name="idRequete" nillable="true" type="xsd:string" />

</sequence> </complexType> </schema> </wsdl:types>

<wsdl:message name="RequestFailureException"> <wsdl:part name="fault" type="tns1:RequestFailureException" />

</wsdl:message>


36/47


Edition Aout 2016

<wsdl:message name="changementTarifExtResponse"> <wsdl:part name="changementTarifExtReturn" type="tns1:Response" />

</wsdl:message> <wsdl:message name="changementTarifExtRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" /> <wsdl:part name="in2" type="tns1:PalierTarifaire" />

</wsdl:message> <wsdl:portType name="ContactTarificationV2"> <wsdl:operation name="changementTarifExt" parameterOrder="in0 in1 in2"> <wsdl:input message="intf:changementTarifExtRequest" name="changementTarifExtRequest" /> <wsdl:output message="intf:changementTarifExtResponse" name="changementTarifExtResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />

</wsdl:operation> </wsdl:portType>

<wsdl:binding name="contactSoapBinding" type="intf:ContactTarificationV2"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="changementTarifExt"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="changementTarifExtRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:francetelecom.com/pac" use="encoded" /> </wsdl:input>

<wsdl:output name="changementTarifExtResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

namespace="urn:francetelecom.com/pac" use="encoded" /> </wsdl:output>

<wsdl:fault name="RequestFailureException"> <wsdlsoap:fault encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" name="RequestFailureException"

namespace="urn:francetelecom.com/pac" use="encoded" /> </wsdl:fault> </wsdl:operation> </wsdl:binding>

<wsdl:service name="ContactService"> <wsdl:port binding="impl:contactSoapBinding" name="contact"> <wsdlsoap:address location="https://portailapicontact.orange-business.com/pac-server/services/contact" />

</wsdl:port> </wsdl:service> </wsdl:definitions>

Web Services reroutageAveugle et reConnect

<wsdl:definitions targetNamespace="urn:francetelecom.com/pac" xmlns:apachesoap="http://xml.apache.org/xml-



xmlns="http://www.w3.org/2001/XMLSchema">


37/47


Edition Aout 2016

<import namespace="http://schemas.xmlsoap.org/soap/encoding/" /> <complexType name="Alias"> <sequence> <element name="alias" nillable="true" type="xsd:string" />




<complexType name="NumeroTelephone"> <sequence> <element name="numero" nillable="true" type="xsd:string" />




<complexType name="DonneesContexteHexa"> <sequence> <element name="donnees" nillable="true" type="xsd:string" />


<complexType name="DonneesContexteAscii"> <sequence> <element name="donnees" nillable="true" type="xsd:string" />


<complexType name="NASRetour"> <sequence> <element name="NASRetour" nillable="true" type="xsd:string" />


<complexType name="DonneesContexteRetour"> <sequence> <element name="donnees" nillable="true" type="xsd:string" />


<complexType name="TypeTaxation"> <sequence> <element name="typeTaxation" nillable="true" type="xsd:string" />


<complexType name="ReroutageCascadeInterdit"> <sequence> <element name="reroutageCascadeInterdit" type="xsd:boolean" />


<complexType name="POSSIBILITESinterdite"> <sequence> <element name="possibilitesInterdite" type="xsd:boolean" />


<complexType name="TransmissionIdentiteRestreinte"> <sequence>


38/47


Edition Aout 2016

<element name="transmissionIdentiteRestreinte" type="xsd:boolean" /> </sequence> </complexType>






</wsdl:message> <wsdl:message name="reroutageAveugleRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" /> <wsdl:part name="in2" type="tns1:NumeroTelephone" /> <wsdl:part name="in3" type="tns1:PalierTarifaire" /> <wsdl:part name="in4" type="tns1:DonneesContexteHexa" /> <wsdl:part name="in5" type="tns1:DonneesContexteAscii" /> <wsdl:part name="in6" type="tns1:NASRetour" /> <wsdl:part name="in7" type="tns1:DonneesContexteRetour" /> <wsdl:part name="in8" type="tns1:TypeTaxation" /> <wsdl:part name="in9" type="tns1:ReroutageCascadeInterdit" /> <wsdl:part name="in10" type="tns1:POSSIBILITESinterdite" /> <wsdl:part name="in11" type="tns1:TransmissionIdentiteRestreinte" />

</wsdl:message> <wsdl:message name="reroutageAveugleResponse"> <wsdl:part name="reroutageAveugleReturn" type="tns1:Response" />

</wsdl:message> <wsdl:message name="reConnectRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" />

</wsdl:message> <wsdl:message name="reConnectResponse"> <wsdl:part name="reConnectReturn" type="tns1:Response" />

</wsdl:message> <wsdl:portType name="ContactReroutageAveugle"> <wsdl:operation name="reroutageAveugle" parameterOrder="in0 in1 in2 in3 in4 in5 in6 in7 in8 in9 in10 in11"> <wsdl:input message="intf:reroutageAveugleRequest" name="reroutageAveugleRequest" /> <wsdl:output message="intf:reroutageAveugleResponse" name="reroutageAveugleResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />

</wsdl:operation> <wsdl:operation name="reConnect" parameterOrder="in0 in1"> <wsdl:input message="intf:reConnectRequest" name="reConnectRequest" /> <wsdl:output message="intf:reConnectResponse" name="reConnectResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />


<wsdl:binding name="contactSoapBinding" type="intf:ContactReroutageAveugle">


39/47


Edition Aout 2016

<wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="reroutageAveugle"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="reroutageAveugleRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="reroutageAveugleResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"



namespace="urn:francetelecom.com/pac" use="encoded" /> </wsdl:fault> </wsdl:operation>

<wsdl:operation name="reConnect"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="reConnectRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="reConnectResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"






Web Services reroutageAccompagne, reroutageAccompagneSup, demandeEtatRerAccSup, demandeEtatFinalRerAccSup, vaEtVient et reConnect

<?xml version="1.0" encoding="UTF-8" ?> <wsdl:definitions targetNamespace="urn:francetelecom.com/pac" xmlns:apachesoap="http://xml.apache.org/xml-


<wsdl:types>


40/47


Edition Aout 2016

<schema targetNamespace="http://domain.business.server.pac.francetelecom.com" xmlns="http://www.w3.org/2001/XMLSchema">

<import namespace="http://schemas.xmlsoap.org/soap/encoding/" /> <complexType name="Alias"> <sequence> <element name="alias" nillable="true" type="xsd:string" />




<complexType name="NumeroTelephone"> <sequence> <element name="numero" nillable="true" type="xsd:string" />


<complexType name="MaxSuiviConv"> <sequence> <element name="maxSuiviConv" nillable="true" type="xsd:string" />




<complexType name="DonneesContexteHexa"> <sequence> <element name="donnees" nillable="true" type="xsd:string" />


<complexType name="DonneesContexteAscii"> <sequence> <element name="donnees" nillable="true" type="xsd:string" />


<complexType name="NASRetour"> <sequence> <element name="NASRetour" nillable="true" type="xsd:string" />


<complexType name="DonneesContexteRetour"> <sequence> <element name="donnees" nillable="true" type="xsd:string" />


<complexType name="TypeTaxation"> <sequence> <element name="typeTaxation" nillable="true" type="xsd:string" />


<complexType name="ReroutageCascadeInterdit"> <sequence> <element name="reroutageCascadeInterdit" type="xsd:boolean" />



41/47


Edition Aout 2016

<complexType name="POSSIBILITESinterdite"> <sequence> <element name="possibilitesInterdite" type="xsd:boolean" />


<complexType name="TransmissionIdentiteRestreinte"> <sequence> <element name="transmissionIdentiteRestreinte" type="xsd:boolean" />






<wsdl:message name="vaEtVientRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" />

</wsdl:message> <wsdl:message name="RequestFailureException"> <wsdl:part name="fault" type="tns1:RequestFailureException" />

</wsdl:message> <wsdl:message name="ReroutageAccompagneResponse"> <wsdl:part name="ReroutageAccompagneReturn" type="tns1:Response" />

</wsdl:message> <wsdl:message name="vaEtVientResponse"> <wsdl:part name="vaEtVientReturn" type="tns1:Response" />

</wsdl:message> <wsdl:message name="ReroutageAccompagneRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" /> <wsdl:part name="in2" type="tns1:NumeroTelephone" /> <wsdl:part name="in3" type="tns1:PalierTarifaire" /> <wsdl:part name="in4" type="tns1:DonneesContexteHexa" /> <wsdl:part name="in5" type="tns1:DonneesContexteAscii" /> <wsdl:part name="in6" type="tns1:NASRetour" /> <wsdl:part name="in7" type="tns1:DonneesContexteRetour" /> <wsdl:part name="in8" type="tns1:TypeTaxation" /> <wsdl:part name="in9" type="tns1:ReroutageCascadeInterdit" /> <wsdl:part name="in10" type="tns1:POSSIBILITESinterdite" /> <wsdl:part name="in11" type="tns1:TransmissionIdentiteRestreinte" />

</wsdl:message> <wsdl:message name="reConnectRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" />

</wsdl:message> <wsdl:message name="reConnectResponse"> <wsdl:part name="reConnectReturn" type="tns1:Response" />


42/47


Edition Aout 2016

</wsdl:message> <wsdl:message name="reroutageAccompagneSupRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" /> <wsdl:part name="in2" type="tns1:NumeroTelephone" /> <wsdl:part name="in12" type="tns1:MaxSuiviConv" /> <wsdl:part name="in3" type="tns1:PalierTarifaire" /> <wsdl:part name="in4" type="tns1:DonneesContexteHexa" /> <wsdl:part name="in5" type="tns1:DonneesContexteAscii" /> <wsdl:part name="in6" type="tns1:NASRetour" /> <wsdl:part name="in7" type="tns1:DonneesContexteRetour" /> <wsdl:part name="in8" type="tns1:TypeTaxation" /> <wsdl:part name="in9" type="tns1:ReroutageCascadeInterdit" /> <wsdl:part name="in10" type="tns1:POSSIBILITESinterdite" /> <wsdl:part name="in11" type="tns1:TransmissionIdentiteRestreinte" />

</wsdl:message> <wsdl:message name="reroutageAccompagneSupResponse"> <wsdl:part name="reroutageAccompagneSupReturn" type="tns1:Response" />

</wsdl:message> <wsdl:message name="demandeEtatFinalRerAccSupRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" />

</wsdl:message> <wsdl:message name="demandeEtatFinalRerAccSupResponse"> <wsdl:part name="demandeEtatFinalRerAccSupReturn" type="tns1:Response" />

</wsdl:message> <wsdl:message name="demandeEtatRerAccSupRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" />

</wsdl:message> <wsdl:message name="demandeEtatRerAccSupResponse"> <wsdl:part name="demandeEtatRerAccSupReturn" type="tns1:Response" />

</wsdl:message> <wsdl:portType name="ContactReroutageAccompagne"> <wsdl:operation name="ReroutageAccompagne" parameterOrder="in0 in1 in2 in3 in4 in5 in6 in7 in8 in9 in10 in11"> <wsdl:input message="intf:ReroutageAccompagneRequest" name="ReroutageAccompagneRequest" /> <wsdl:output message="intf:ReroutageAccompagneResponse" name="ReroutageAccompagneResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />

</wsdl:operation> <wsdl:operation name="vaEtVient" parameterOrder="in0 in1"> <wsdl:input message="intf:vaEtVientRequest" name="vaEtVientRequest" /> <wsdl:output message="intf:vaEtVientResponse" name="vaEtVientResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />

</wsdl:operation> <wsdl:operation name="reConnect" parameterOrder="in0 in1"> <wsdl:input message="intf:reConnectRequest" name="reConnectRequest" /> <wsdl:output message="intf:reConnectResponse" name="reConnectResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />

</wsdl:operation> <wsdl:operation name="reroutageAccompagneSup" parameterOrder="in0 in1 in2 in12 in3 in4 in5 in6 in7 in8 in9

in10 in11"> <wsdl:input message="intf:ReroutageAccompagneSupRequest" name="ReroutageAccompagneSupRequest" /> <wsdl:output message="intf:ReroutageAccompagneSupResponse" name="ReroutageAccompagneSupResponse"

/> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />

</wsdl:operation> <wsdl:operation name="demandeEtatFinalRerAccSup" parameterOrder="in0 in1">


43/47


Edition Aout 2016

<wsdl:input message="intf:demandeEtatFinalRerAccSupRequest" name="demandeEtatFinalRerAccSupRequest" />

<wsdl:output message="intf:demandeEtatFinalRerAccSupResponse" name="demandeEtatFinalRerAccSupResponse" />

<wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" /> </wsdl:operation>

<wsdl:operation name="demandeEtatRerAccSup" parameterOrder="in0 in1"> <wsdl:input message="intf:demandeEtatRerAccSupRequest" name="demandeEtatRerAccSupRequest" /> <wsdl:output message="intf:demandeEtatRerAccSupResponse" name="demandeEtatRerAccSupResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />


<wsdl:binding name="contactSoapBinding" type="intf:ContactReroutageAccompagne"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="ReroutageAccompagne"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="ReroutageAccompagneRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="ReroutageAccompagneResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"




<wsdl:operation name="vaEtVient"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="vaEtVientRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="vaEtVientResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"




<wsdl:operation name="reConnect"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="reConnectRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="reConnectResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"



namespace="urn:francetelecom.com/pac" use="encoded" /> </wsdl:fault>


44/47


Edition Aout 2016

</wsdl:operation> <wsdl:operation name="reroutageAccompagneSup"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="ReroutageAccompagneSupRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="ReroutageAccompagneSupResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"




<wsdl:operation name="demandeEtatFinalRerAccSup"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="demandeEtatFinalRerAccSupRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="demandeEtatFinalRerAccSupResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"




<wsdl:operation name="demandeEtatRerAccSup"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="demandeEtatRerAccSupRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="demandeEtatRerAccSupResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"







45/47


Edition Aout 2016

Web Service informationsAppel

<wsdl:definitions targetNamespace="urn:francetelecom.com/pac" xmlns:apachesoap="http://xml.apache.org/xml-



xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://schemas.xmlsoap.org/soap/encoding/" /> <complexType name="Alias"> <sequence> <element name="alias" nillable="true" type="xsd:string" />






<complexType name="ResponseInfo"> <complexContent> <extension base="tns1:Response"> <sequence> <element name="NASappelant" nillable="true" type="xsd:string" /> <element name="NASappele" nillable="true" type="xsd:string" /> <element name="NDIappele" nillable="true" type="xsd:string" /> <element name="NDSappelant" nillable="true" type="xsd:string" /> <element name="autorisationModifTax" nillable="true" type="xsd:string" /> <element name="donneesContexteASCII" nillable="true" type="xsd:string" /> <element name="donneesContexteHEXA" nillable="true" type="xsd:string" /> <element name="donneesContexteRetour" nillable="true" type="xsd:string" /> <element name="informationUsagerUsager" nillable="true" type="xsd:string" /> <element name="marquageReroutage" nillable="true" type="xsd:string" /> <element name="origineGeographique" nillable="true" type="xsd:string" />

</sequence> </extension> </complexContent> </complexType>



46/47


Edition Aout 2016



</wsdl:message> <wsdl:message name="informationAppelResponse"> <wsdl:part name="informationAppelReturn" type="tns1:ResponseInfo" />

</wsdl:message> <wsdl:message name="informationAppelRequest"> <wsdl:part name="in0" type="tns1:Alias" /> <wsdl:part name="in1" type="tns1:RefAppel" />

</wsdl:message> <wsdl:portType name="ContactInformationsAppel"> <wsdl:operation name="informationAppel" parameterOrder="in0 in1"> <wsdl:input message="intf:informationAppelRequest" name="informationAppelRequest" /> <wsdl:output message="intf:informationAppelResponse" name="informationAppelResponse" /> <wsdl:fault message="intf:RequestFailureException" name="RequestFailureException" />


<wsdl:binding name="contactSoapBinding" type="intf:ContactInformationsAppel"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="informationAppel"> <wsdlsoap:operation soapAction="" /> <wsdl:input name="informationAppelRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"


<wsdl:output name="informationAppelResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"






Exemple de requête SOAP

Requête de changement de tarif avec les paramètres :

Alias = "alias" ;

ReferenceAppel = "123456" ;

PalierTarifaire = "123".

Orange, Société Anonyme au capital de 10 640 226 396€78, rue Olivier de Serres 75015 Paris - RCS Paris 380 129 866


47/47 STAS Service Numéro Contact

Edition Aout 2016

<?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body>

<ns1:changementTarifExt soapenv:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ xmlns:ns1="urn:francetelecom.com/pac"> <in0 href="#id0"/> <in1 href="#id1"/> <in2 href="#id2"/>

</ns1:changementTarifExt> <multiRef id="id0" soapenc:root="0"

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:Alias" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="http://domain.business.server.pac.francetelecom.com"> <alias xsi:type="xsd:string">alias</alias>

</multiRef> <multiRef id="id2" soapenc:root="0"

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns3:PalierTarifaire" xmlns:ns3="http://domain.business.server.pac.francetelecom.com" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> <codeTarifaire xsi:type="xsd:string">123</codeTarifaire>

</multiRef> <multiRef id="id1" soapenc:root="0"

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns4:RefAppel" xmlns:ns4="http://domain.business.server.pac.francetelecom.com" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"> <refAppel rsi:type="xsd:string">123456</refAppel>

</multiRef> </soapenv:Body>

</soapenv:Envelope>

STAS PAC V2...STAS ± Portail API Contact Edition Aout 2016 STAS PAC V2 .1 (Service PAC pour NR IP)...

Documents

Transcript of STAS PAC V2...STAS ± Portail API Contact Edition Aout 2016 STAS PAC V2 .1 (Service PAC pour NR IP)...