Annonce

On peut être passionné par la téléphonie et prendre soin de soi : "Faites du sport, faites du vélo" est la devise du site d'e-commerce lancé par l'un des auteurs de Panoramisk : bikeo. Si vous faites du vélo, que ce soit en ville, sur la route ou sur les chemins plus accidentés, n'hésitez pas à aller faire un petit tour sur www.bikeo.fr pour vos prochains achats verts.
En plus leur plate-forme de téléphonie utilise Asterisk, comme quoi on peut la convergence est une réalité.

12 questions before moving to IP telephony

Pages: 1 2 3 4 5 6 7 8 9 10 11 12

2- Is your IP network ready for voice?

When talking about IP telephony, IP could be thought as negligible part since well known by many people. But voice quality is highly dependent to data network quality.

In order to reach an acceptable voice quality level, it is important to limit the number of loosed frame on the data network¹ (ie less than 1% for example - one frame generally transport 20ms of voice information) and a limited jitter. On the local network, most of the time using switches at 100Mbps or higher, it is relatively easy to reach good results, on the WAN it is different.

Computer application tend to use more and more bandwidth since file format are richer and interactivity is a key feature to most new application². For example we could have high impact when using electronic mail to send a big file, like a presentation, to a large user group. Since some messaging systems are using a push technology, all users desktop will download the same email at roughly the same time, this could create a burst on the network that can impact some voice conversation happening at the same time.

We usually try to separate various traffic directly at the network level, even on the local one. We can do this at the Ethernet level (OSI layer 2), using a way to give priority to the RTP traffic³ with 802.1p/802.1Q for example or any vendor specific feature. If the LAN is composed of multiple segments, the routers will have to take care of the voice traffic as well. In the IP world we are talking about giving priority based on the ToS/DSCP/Diffserv field or through some more complex solution like RSVP or traffic engineering.

Most of networking equipment available on the market are able to provide QoS based on this kind of options, but one should understand these well prior putting these in place, be able to configure equipment accordingly and monitor the behavior and the voice quality in order to adapt the configurations.

A more complex task is providing voice quality over long distant links. When talking about the WAN, we can agree on the fact bandwidth is lower than on the LAN, therefor we can encounter congestion. We have to keep in mind that a phone call is a real-time application using a small amount of bandwidth⁴, but the IP network is shared between all application. It is now mandatory to provide voice traffic with a higher chance to arrive at destination in order for the calls to be audible and comfortable. This is really true when one of both communication way is congested by some other IP traffic (like during a file transfer for example). Be careful when using meshed network with asymmetrical bandwidth, like Frame Relay or IP-MPLS, where the bandwidth at the hub site could be higher than at the spokes one. When a file transfer is performed from the hub to the spoke, hub will not be congested but the spoke could; at this level it is too late to perform some shaping. The hub should take care of the QoS even in non congestion period, this is what we generally call “traffic engineering”.