Messages

Ah, j'ai trouvé le souci, le contenu du mail en mode texte est correct, mais le contenu en mode HTML est incorrect.

Du coup ce sera corrigé en début de semaine prochaine, mais vous pouvez regarder le contenu du mail en mode "texte" pour avoir les informations d'ici-là.

C'est censé être corrigé depuis lundi soir, ça m'épate que ça re-surgisse comme ça. 

@thedark, pouvez-vous me faire parvenir le message complet en MP (avec les entêtes SMTP, en particulier les entêtes Received, que je puisse confirmer quel serveur a fait la manip)?

Pour vérifier la tarification d'un numéro spécial, la référence officielle est http://www.infosva.org/

De mémoire on avait dû l'enlever parce que ça faisait que certaines personnes pensaient que la ligne était en dérangement.

J'ai ouvert un ticket en interne pour que mes collègues pensent à mettre une option lors d'une révision du panel téléphonique.

@graphisketch Ça restera complètement optionnel, c'est dans l'esprit de permettre aux personnes intéressées de contrôler leurs coûts.

@adonf Ce n'est pas lié spécifiquement aux mobiles, c'est juste que la demande initiale sur le forum était pour la durée des appels mobiles donc c'est l'exemple qu'a repris Raphaël.

La section sur l'API CouchDB a été mise à jour (les problèmes sont corrigés, avec une API un peu différente).

Du coup tout devrait fonctionner comme décrit dans la doc.

J'ai ajouté une fonctionnalité pour faciliter l'accès à la messagerie vocale + testé (& le cas échéant corrigé) la plupart des fonctionnalités:

• Accès à la messagerie vocale fonctionne
• Accès via l'API REST à la configuration fonctionne
• Authentification via numéro de téléphone + PIN fonctionne

Du coup mis à part les fonctions décrites en bas du document dans la section "API CouchDB" pour l'accès à la configuration, tout le reste devrait marcher.

La documentation mise à jour est au même endroit: https://gitlab.k-net.fr/shimaore/plastic-sound/blob/master/README.md

J'ai aussi ouvert une section pour rapporter les éventuels problèmes sur cette API: https://gitlab.k-net.fr/shimaore/plastic-sound/issues

Toujours en vac ?

Haha, non, mais toujours pas eu le temps de finir de tester, et je sais en particulier que l'API CouchDB décrite tout en bas du document ne fonctionne pas encore.
En tout cas la doc est ici: https://gitlab.k-net.fr/shimaore/plastic-sound
S.

Soit dit en passant, le plus simple est de ne pas mettre de port, sur tous les domaines k-net il y a ce qu'il faut pour que les téléphones puissent trouver le numéro de port tout seuls.

Par contre sur certains modèles il faut dire de faire la recherche, je pense aux SPA par exemple où il faut cocher la case qui dit "SRV" et celle qui dit "auto-prefix" ou qqch comme ça. Sur les gigaset c'est normalement automatique à partir du moment où il n'y a pas de numéro de port.

J'ai eu quelques surprises en commençant à écrire la documentation pour les API téléphonie, du coup il faudra que je fasse des mises-à-jour en rentrant de vacances pour que ça soit utilisable. Désolé!

En attendant, et si vous voulez vous occuper le mois de juillet, j'ai commencé un projet sur les plans de numérotation internationaux https://github.com/shimaore/numbering-plans
Pour l'instant il y a (surprise..!) la France (+33), la Suisse (+41), l'amérique du nord (+1) ... Il y en a plein d'autres à faire si ça vous tente, une liste complète est sur https://www.itu.int/oth/T0202.aspx?parent=T0202

C'est peu technique, ça ne demande pas de savoir programmer, c'est surtout comprendre les documents des régulateurs nationaux qui peut s'avérer "intéressant"...
Pensez à vous mettre dans la liste des "contributors" https://docs.npmjs.com/files/package.json#people-fields-author-contributors si vous soumettez une participation!

Afin de permettre aux notifications de messagerie vocale (MWI) de parvenir jusqu'aux téléphones, j'ai déployé cette semaine un service de présence sur les serveurs.  Le service précédent, qui utilisait les "unsollicited NOTIFY", ne fonctionnait pas pour tous les téléphones: la plupart des téléphones rejetaient les messages de notification. Ce nouveau service, qui utilise le modèle "PUBLISH/SUBSCRIBE", permet aux téléphones de s'enregistrer auprès des serveurs pour obtenir les notifications, et du coup les serveurs savent comment transmettre les notifications correctement.

Il est possible par contre que ça ne fonctionne pas d'office avec tous les modèles -- par exemple sur un vieux téléphone IP Linksys que j'ai testé, il a fallu que je configure le champ "Voice Mail Server" avec le numéro de téléphone `@` le domaine. Si vous avez des informations sur différents modèles n'hésitez pas à les publier.

PS: Un peu technique, mais pour vérifier que votre configuration fonctionne, si vous êtes équipé d'un sniffer: les paquets échangés entre le téléphone ou ATA et le serveur commencent par un message SUBSCRIBE. Le premier message SUBSCRIBE reçoit une réponse 407 (comme le premier message REGISTER quand le téléphone s'inscrit sur le serveur). Le deuxième message SUBSCRIBE doit recevoir une réponse 200 OK. Ensuite le serveur enverra des messages NOTIFY avec le champ "Event: message-summary" de temps en temps, et le téléphone doit y répondre avec 200 OK.

Your account is currently set up for your equipment to be managed by our provisioning servers, not manually configured.
If you configure your own equipment you should ask our support to provide you with a "nomade" account; that account will be on a.phone.

Et pendant que j'ai votre attention... J'ai aussi travaillé sur la mise à disposition d'API pour que des développeurs externes puissent interagir avec le softswitch SIP en écrivant du code pour navigateur web (front-end). A priori ça permettrait d'écrire des applications web ou mobile qui gèrent la messagerie vocale (genre "messagerie visuelle"), notifient pour les appels entrants, modifient certains des éléments de configuration d'une ligne, des choses comme ça; pour vous donner une idée les API sont CouchDB/PouchDB, Socket.IO, et un peu de REST/JSON (je n'ai pas encore fait de librairie JavaScript pour intégrer tout ça, je viens juste d'y penser ). L'idée est que des applications postées publiquement (sur github / gitlab / etc.) peuvent être intégrées dans les services mis à disposition de tous (sur un serveur k-net) pour vous permettre de gagner un peu de visibilité. S'il y a des développeurs que ça intéresse, faites-moi signe.

Pas mal de changements internes depuis mon dernier poste — la plupart concernent un nouveau service pour lequel je suis en train d'écrire la doc utilisateur et qui devrait donc être disponible bientôt — mais une nouveauté qui est disponible pour tout le monde est la possibilité de faire suivre les messages vocaux (via le 123) à un autre client k-net (appuyez sur la touche 4 pendant la lecture d'un message).

J'ai oublié de poster l'info, mais ça a été corrigé depuis.