dimanche 28 juin 2009

Le codec G711 20ms

Dans quelques semaines un opérateur bien connu va proposer en France une offre VOIP reposant sur l'utilisant au niveau des liens wan du codec G711 20ms en remplacement de G729a 40ms je vous propose aujourd'hui de faire un zoom sur cette façon de coder les flux téléphonique.


Rappel pour dimensionner un lien wan on associe un codec avec un taux d'échantillonnage par paquet dans notre cas la valeur étant de 20ms.


En téléphonie numérique G711 échantillonne un signal 8000 fois par seconde. Chaque échantillons étant constitué de 8 éléments binaires (bits) soit pour une seconde 8000 octets soit 64Kbits.


La perte d'un paquet voix correspondant à 1s n'étant pas acceptable pour un utilisateur on transmet plus régulièrement des des paquets de données dans notre cas toutes les 20ms soit 50 paquets par seconde.


Chaque paquet est de ce fait constitué de 160 octets (8000/50) de données dites utiles.


Pour transmettre celui ci sur un réseau IP nous construisons un paquet IP ou datagramme pour se faire on ajoute les entêtes RTP, UP et IP soit un overhead de 40 octets.


La bande passante nécessaire étant fonction de la technique de transmission on obtient les valeurs ci dessous :

Frame Relay : 82 Kbits /s

Ethernet : 96;8 Kbits /s

ATM : 106 Kbits /s


A noter que sur un support SDSL ( ATM) il faut 5 fois plus de bande passante que celle requise par l'utilisation du codec G729a 40ms.





dimanche 21 juin 2009

Trunking et sécurité

Au cours des derniers jours de nombreux acteurs ont publiés des articles concernant la sécurité en environnement Voip: Matt Brunk confronté à une baisse de qualité de service nous indique comment pour identifier l'origine du dysfonctionnement son opérateur a eu recours au logiciel : WireShark (Ethereal).


Mark Collier en réponse a cet article précise que pour lui les principales attaques sont de type Toll Fraud et DOS.


Sipera Systems nous indique qu'avec la crise économique nous assistons à une augmentation des vulnérabilités Toll Fraud.

Ce type de vulnérabilité permet à des utilisateurs non autorisés utilisant les les vulnérabilités des systèmes VOIP de téléphoner gratuitement.


L'utilisation de trunk H323 ou SIP est elle une source de vulnérabilité ?


Aujourd'hui pour écouler les appels hors de la zone IPBX les entreprises utilisent généralement les services proposés par des opérateurs télécom. La connectivité avec le gatekeeper s'effectue via des trunks H323. Celle avec les IMS ou les softswitchs via des trunks SIP.


Alors que les architectures constructeurs permettent de sécuriser la signalisation via TLS et les flux conversationnels (SRTP) il n'est actuellement pas possible d'échanger des données encryptées avec les opérateurs. Tout simplement parce qu'il serait trop complexe par exemple en TLS de gérer le certificat X509 échangés avec chaque client.

Les flux conversationnels quant à eux sont encryptés hop by hop c'est a dire entre l'équipement client le SBC opérateur et non jusqu'aux gateways opérateur PSTN.


La sécurité repose alors sur les mécanismes intégrés aux architectures : firewalls, IDS/IPS et SBC à condition que la configuration de ces différents éléments soit réalisée correctement. La sécurité est intégrée aux offres qui nous sont proposées.


Aujourd'hui mettre en place du trunking avec un opérateur nécessite de lui faire entièrement confiance.




lundi 15 juin 2009

L'interopérabilité SIP

Pendant mes formations je mets en avant les avantages engendrés par l'utilisation de SIP comme protocole de signalisation au sein d'une solution de téléphonie. Véritable Esperanto de la signalisation l'utilisation de celui-ci est censé favorisé l'interopérabilité des différentes solutions de communication unifiées.


L'article SIP Interopérability why is it so hard to achieve ? posté par Alan Percy dans le blog No Jitter expose bien la situation actuelle.


La RFC 3261 qui décrit le protocole est selon lui beaucoup trop ouverte. Il est possible de ce fait de développer une signalisation SIP conforme à la norme bien qu'étant incompatible avec celle d'un autre fabricant.


Le protocole utilisé pour le transport des données peut lui aussi être fonction du fournisseur. Alors que la majorité des IPBX travaillent en SIP over UDP Microsoft lui utilise SIP over TCP.


Ces particularités si personnes n'intervient pour ajouter un peu de normalisation font et feront le bonheur des constructeurs. Cisco propose déjà son traducteur le CUBE (Cisco Unified Border Element). A moins que lacés de gérer la complexité les clients ne décident d'opter pour une solution tout en un de type OCS2007

mardi 9 juin 2009

La version R5.1B Aastra

Aastra vient de faire évoluer la version logicielle de sa solution TOIP 5000. La version R5.1B c'est son nom propose une solution innovante de DECT/IP au moment ou d'autre constructeur optent plutôt pour des solutions de type WIFI.


L'architecture repose sur un serveur Open Mobility Manager assurant la gestion de 1 à 256 bornes et au maximum 4000 terminaux.


Installé sur le site central il est capable de gérer des bornes sur des sites déportés.


De nouveaux terminaux sont désormais disponibles : 5610, 5620, 5630.


A noter la possibililité de consulter sur son mobile DECT l'annuaire A5000 ainsi que leur administration via la solution de gestion de parc 7450.








dimanche 7 juin 2009

Tout savoir sur la securité XOIP

Si comme moi vous vous intéressez à la sécurité en environnement VOIP je vous recommande la lecture de ce livre.

Il aborde les différentes menaces tant au niveau des protocoles que des équipements.

A noter deux importants chapitres un consacré aux SBC (session border controller) et l'autre aux lawful interception ( écoutes legales).

Cet ouvrage est disponible à la librairie Eyrolles 75005 Paris