Forum OVHUnivers TelecomTéléphonie CTI Convergence Téléphonie Informatique Je me permet de réagir. J'avais également rencontrer ce problème quelque soit le mode de transfert. Le support était incapable de m'expliquer pourquoi. La tonalité marchait uniquement si j'appelais le SVI depuis un numéro OVH, une ligne externe supprimait obligatoirement le Ring back tone. / Ps N'oublie pas de prévoir un signal far_end_disconnect pour lever les problèmes de ligne occupée, fin d'appel etc si tu essaies avec le mode bridge plutot que le mode blind pour débugger, peut être y'a t'il des problèmes d'établissement de connexion mais j'en doute... Bonjour, J'ai trouvé un grand intérêt à la solution proposée par Isu_ utilisant un SVI pour intercepter les appels. J'ai donc implémenté l'ensemble et testé sur mon téléphone, et dans l'ensemble çà fonctionne bien, à un détail prêt Lorsqu'on appelle le numéro du SVI, on entant une première sonnerie avant d'arriver sur le SVI, normal. Là, mon premier script appelle par un submit un script PHP qui stocke l'appel et renvoi un form de transfert vers le numéro réel, et le téléphone se met à sonner. Le problème est que la tonalité de retour d'appel Ring back tone pendant que le téléphone sonne est muette une fois sur deux ... donc on a une première sonnerie, le SVI décroche, puis plus rien ... J'ai changé à peu prêt toutes les options, sans succès ... Je suis même preneur d'avoir pourquoi pas une musique, ou autre Pour info, je suis en transfer blind pour profiter du répondeur intégré Merci de vos idées ! Voilà les VXML Mon premier scriptCelui renvoyé par Loup Artic27/11/2010, 16h39Du moment que le serveur n'envoi rien au client, on peut dire que du coup le client idle. Donc oui ça ne prendra pas de ressource côté client. Après il faut bien que le client reçoive le push, donc il bouffera légèrement des ressources pour maintenir une écoute et/ou un programme en idle. Si bien fait, cela ne se voit même pas. Envoyé par Loup Artic Oui, c'est justement le serveur qui envoi au client. Donc ça ne consomme pas de ressources coté client? Loup Artic27/11/2010, 15h39Oui, c'est justement le serveur qui envoi au client. C'est bien une solution de push que je voudrais mettre en oeuvre... Dans le push, le client n'est justement pas en permanence entrain de solliciter le serveur en attente de quelque chose... C'est bien ça? L'inconvénient du web est qu'il faut un serveur push qui alerte le navigateur en cas d'appel. Si un script ajax interroge toutes les secondes pour récupérer des infos, ça va bouffer des ressources ! Il faut que je regarde à quoi ressemble l'interface jabber Si tu veux voir les primitives correspondant au protocole XMPP Utilisé notamment par Jabber , utilise XMPPHP, c'est une librairie assez sympa, restreinte mais efficace à utiliser et assez suffusante pour un usage modéré j'avais rencontré des problèmes en utilisant les autres avec le serveur Jabber d'OVH Gaston_Phone26/11/2010, 19h54C'est intéressant ton idée. Il va falloir que je suive cela de près. Après si tu veux via navigateur, j'pense qu'effectivement de l'Ajax est inévitable mais celà dépend de ton usage. Mais le traitement derrière reste le même. Le navigateur pour un CTI correspond selon moi à une interface qui doit permettre de réaliser des tâches depuis l'info recue, Jabber lui correspond plus à une fonctionnalité de notifications. Pour les notifications l'avantage de Jabber reste au niveau de sa portabilité Un petit coup de connexion sur un Iphone pour voir les notifications d'appels reçus... Les possibilités sont illimitées D'ailleurs si j'me souviens bien la mise en page accepte certaines balises HTML Tu avais donc fais le choix de jabber pour remonter les informations. J'aurais préféré les remonter dans un navigateur... Il faut que je regarde à quoi ressemble l'interface jabber.... C'est peut être une solution... Merci Personnellement j'avais réalisé un tel système via unSVI et un script PHP faisant la remontée de fiche sur le poste appelé en question. Cette fiche contenait le nom, prenom , adresse , numéro de fax et un lien GoogleMaps de géolocalisation du client appelant en récupérant toutes les infos sur un annuaire et en "parsant" le résultat. Le tout était uniquement basé sur le numéro de l'appelant. Toutes ces informations étaient envoyées par Message instantané Jabber Une sorte d' MSN Open Source dont OVH fourni des serveurs d'envoi . C'était plutôt cool, réactif et facilement modulable. Attention cependant,il faut optimiser à fond le traitement de ton PHP et prévoir des échapatoires Tant que ta page php n'a pas fini son traitement, l'appelant a un petit blanc dans le combiné. Mais au final t'obtiens des délais imperceptibles si bien réalisés de l'ordre de Tu peux donc envisager facilement, la création d'un log d'appel, des interractions avec une BdD ... sans problème A noter cependant Attention cependant à la taille de la BdD Bonjour, Je souhaiterais mettre en place une appli qui permette d'afficher dans un navigateur le n° d'un appel entrant en temps réel. La suite des développements serait d'attaquer une base de données pour permettre d'afficher les informations liées à ce n° entrant. J'imagine qu'il y aura de l'ajax dans la boucle avec l'utilisation des API OVH... La question d'ailleurs ne repose pas sur la récupération du n° appelant apr les API, mais bien sur la façon de traiter cette information pour qu'elle apparaisse en temps réel sur un écran. Quels sont les outils que vous conseilleriez pour mettre en place ce développement ? Par avance merci