Información Técnica sobre VoIP (Voz sobre IP)
 
Foros *
TOP TEN VoIP
IP TV - HD TV
* Proximamente

IAX2 y el ancho de banda

Estudio de la anchura de banda IAX2 Juan Todd (jtodd @loligo.com)

Propósito: Para obtener una carta mejor del uso real de la anchura de banda por codec como “en–alambre visto” al usar el trunking IAX2 entre dos servidores de la telefonía del asterisco.

Una palabra de la advertencia Q: ¿Cualquiera tiene razones de no usar el Trunking? ¿Desventajas? A: El almacenador intermediario de la inquietud IAX2 (cuando está girado) no trabaja actualmente bien con el sstartto de Yourcall del trunking (trunk=yes en iax.conf)…….soundlike….éste:-)

Discusión: Más allá de los hilos de rosca en el asterisco-revelador y los asterisco-usuarios las listas han indicado que la manera óptima de ahorrar anchura de banda en llamadas múltiples a la misma destinación es utilizar IAX2 (versión 2 del intercambio del Inter-Asterisco) en el modo del “tronco”, que elimina gastos indirectos del IP en gran parte. Este trunking elimina los gastos indirectos del IP encontrados en corrientes individuales del IP de VoIP por los datos de pipelining RTP de llamadas múltiples en los solos paquetes (más grandes), así quitando la redundancia de los gastos indirectos del IP para cada corriente de RTP y más de cerca permitiendo el escalamiento de la anchura de banda en función de uso del codec en vez de una función de (uso del codec + IP de arriba.) por supuesto, este modo puede ser utilizado solamente si todas las llamadas están entre dos servidores específicos del asterisco, pero éste es con frecuencia el caso con situaciones de la peaje-evitación o entre dos sucursales donde hay un servidor del asterisco en cada localización.

Se han hecho las varias declaraciones en cuanto a las cuales el codec es el más eficiente en la anchura de banda limitada excedente del tráfico rodante. A menudo, estas declaraciones cotizarían el uso sí mismo del codec, y no incluirían los gastos indirectos IP e IAX2 que es vital en computar uso real de la anchura de banda entre dos puntos finales en el Internet - el uso teórico del codec simplemente que mide es escaso para costar y los propósitos del mundo real del aprovisionamiento.

Necesité cuantificar realmente estos números con las examinaciones “verdaderas” del en–alambre del tráfico para construir mi propia capacidad con cotizar estas figuras, como son preguntados con frecuencia mí por los clientes. Con este fin nunca había comparado los protocolos principales de lado a lado de cualquier manera formal. Así, en una mañana hermosa de sábado cuando debo haber estado afuera en el mercado del granjero o en mi bici, me senté adentro en una sala de ordenadores obscurecida y dije el “blah” varios cientos de veces en una grabación del teatro de la película.

Estos números pueden venir como ninguna sorpresa a los antes de quienes los han configurado, pero no he visto hasta ahora una comparación adosada mutuamente aquí, la fijo tan para tu examinación y mi mantenimiento de registros. Soy un autor firme de “no creo que todo que oyes” que aplica el doubly-so para las rumores del Internet, así que yo tuvo que probar estos codecs mismo para prevenir sorpresas groseras en el futuro. En armonía con ese alcohol, no debes creer mis números, y pruebas este las actualizaciones tú mismo y del poste a la lista para comprobar mis métodos y resultados con minuciosidad en un foro público.

Notas y métodos del experimento:

  • Las figuras crudas abajo son bidireccionales, significando que los números incluyen ambo tráfico entrante/saliente de la voz. Las figuras “cocinadas” se incluyen en paréntesis - los números crudos fueron divididos por dos y dados vuelta en los kbps para tu facilidad de la lectura. Los paquetes por el segundo no cocinado, y ése se deja como ejercicio al lector.
  • Los teléfonos eran Cisco 7960 dispositivos
  • Las llamadas eran bidireccionales con audio, usando la misma grabación en el lado del PSTN, y mi uso de la palabra “blah” hablado en varias ocasiones en los 7960 en una tarifa constante
  • Diagrama: 
7960 (G.711) - > * (IAX2) - > Internet - > * (IAX2) - > T100P - > PSTN (PRI)
  • El número para “estimaba gastos indirectos del IP” fue obtenido restando (uso adicional del canal) (uso del solo canal.) de esto es posiblemente inexacto.
  • Servidor del asterisco que habla con los teléfonos del SIP: Asterisco CVS-06/27/03-07: 29: 29
  • Servidor del asterisco que habla con PRI: Asterisco CVS-05/26/03-15: 30: 05
  • El método obtenía las figuras la “tarifa - b - anfitrión my.iax2.host de f “y el ssh no portuario””
  • Todas las pruebas fueron hechas con el trunking IAX2 dado vuelta en (los “trunk=yes” en iax.conf para cada par)
  • Todas las pruebas fueron verificadas en el anfitrión alejado para el uso del codec apropiado durante llamadas
  • Todas las pruebas se realizaron sobre un minuto
  • Todas las medidas se realizaron dos veces, e hicieron un promedio
  • Las llamadas fueron permitidas terminar, entonces prueba comenzada para un minuto, después la prueba parada, y las llamadas fueron colgadas encima de (es decir la disposición de llamada y el desmontaje no fueron descompuestos en factores en ninguno de estos figuras, pero sospecho que no diferenciará)
  • Protocola no comprobado: G.723.1, adpcm, mp3, slinear
  • Cuando la anchura de banda que mide, “kilobit” es 1000 pedacitos por el segundo (no 1024) y un megabit es 1.000.000 pedacitos por segundo

Resultados de la prueba:

  • G.711 (ulaw)

una llamada: 164333.75 bps/94.26 pps (82.1 kbps) dos llamadas: 296171.60 bps/101.46 pps (148.0 kbps)

Así:

  • Para cada llamada adicional: 131837 BPS (65.9 kbps)
  • Est. IP/IAX2 de arriba (1 llamada): 32495 BPS (kbps 16.0)
  • Número crudo de llamadas por megabit: 15
  • ILBC: ver la nota abajo

una llamada: 56134.91 bps/67.45 pps (28.0 kbps) dos llamadas: 98679.11 bps/102.41 pps (49.3 kbps)

Así:

  • Para cada llamada adicional: 42544 BPS (21.2 kbps)
  • Est. IP/IAX2 de arriba (1 llamada): 13590 BPS (6.7 kbps)
  • Número crudo de llamadas por megabit: 47
  • G.729

una llamada: 60124.33 bps/101.26 pps (30.0 kbps) dos llamadas: 79496.23 bps/102.85 pps (39.7 kbps)

Así:

  • Para cada llamada adicional: 19372 BPS (9.6 kbps)
  • Est. IP/IAX2 de arriba (1 llamada): 40752 BPS (kbps 20.3)
  • Número crudo de llamadas por megabit: 103
  • G/M

una llamada: 70958.16 bps/102.13 pps (35.4 kbps) dos llamadas: 100455.23 bps/102.63 pps (50.2 kbps)

Así:

  • Para cada llamada adicional: 29497 BPS (kbps 14.7)
  • Est. IP/IAX2 de arriba (1 llamada): 41461 BPS (kbps 20.7)
  • Número crudo de llamadas por megabit: 68
  • LPC10

una llamada: 43855.44 bps/89.94 pps (21.9 kbps) dos llamadas: 56059.18 bps/100.81 pps (28.0 kbps)

Así: 

Para cada llamada adicional:       12203 BPS (6.1 kbps)  Est. IP/IAX2 de arriba (1 llamada):  31561 BPS (kbps 15.8)  Número crudo de llamadas por megabit: 164
  • (SPEEX):

una llamada: 74817.18 bps/101.06 pps (37.4 kbps) dos llamadas: 109692.68 bps/102.18 pps (54.8 kbps)

Así:

  • Para cada llamada adicional: 34875 BPS (kbps 17.4)
  • Est. IP/IAX2 de arriba (1 llamada): 39941 BPS (kbps 19.9)
  • Número crudo de llamadas por megabit: 57

Conclusiones: lpc10 es el ganador claro para el uso económico de la anchura de banda. Sin embargo, la calidad de la voz es en robótico-sonar lateral, y puede no ser aceptable para los usuarios que están contando con algo cerca de peaje-calidad. Las llamadas son perfectamente comprensibles, pero los matices se pierden con este codec. Éste era el único codec que tenía ediciones significativas de la calidad que valieron el mencionar en este estudio; otros codecs tienen diversos grados de la calidad de sonido, pero sus diferencias son bastante de menor importancia que no son relevantes al alcance de esta examinación. Que siendo dicho sobre calidad de la llamada, hay ciertamente una compensación a conseguir ~164 llamadas en un megabit, que es extremadamente impresionante.

G.729 es el siguiente lo más mejor posible de un punto de vista de la anchura de banda, y el uso adicional previsto del canal está muy cerca de la anchura de banda cotizada del uso del codec G.729 - ~9.6kbps en cada dirección. El codec más eficiente siguiente sería G/M en 14.7kbps, y tercero sería Speex en 17.4kbps.

Sorprendían algo las figuras de arriba IP/IAX2 para ILBC - son casi una mitad el de algunos otros protocolos. Probé ese número particular tres veces de cerciorarse de que no hice ninguna errores, y todas las pruebas estaban dentro del 3% de uno a, de modo que sea un resultado inesperado pero constante. Por supuesto, mi método para obtener estas figuras de arriba estimadas IP/IAX2 puede ser inadecuado - doy la bienvenida a comentarios sobre el método usado para estimar esos números.

{Comentario de A sobre los gastos indirectos para el iLBC: si me no confunden, el iLBC utiliza los marcos 30millisecond. Con la frecuencia del tronco del defecto 20millisecond, hay solamente 2/3rds de un bastidor que se enviará en cada intervalo del trunkfreq. Tan sobre el 1/3o del tronco los paquetes no tienen que ser enviados en todos. O, mirándolo una diversa manera, 60msec del audio se puede enviar usando solamente 2 sistemas de jefes de iax/ip, mientras que otros codecs necesitarían 3 sistemas de jefes de iax/ip. Tan hay por lo menos algo de la diferencia - Steve Davies}

{Observar el comentario de A sobre el comentario y el iLBC antedichos. La explicación antedicha es bonita mucho en blanco. Qué sucede realmente es éste:

El Trunking ocurre cada 20 milisegundos. los paquetes del iLBC se envían cada 30 milisegundos

Así, solamente cada otro sistema de paquetes del iLBC es trunked (eg. en 60ms, 120ms, 180ms, el etc) cuando la transmisión del ilBC coincide con el trunking IAX2. La mitad de los paquetes gozará (?) trunking, mientras que la otra mitad no. Para el caso de 2 llamadas, la mitad de la transmisión estará en los jefes 2x, mientras que la otra mitad estará en los jefes 1x. En promedio, la transmisión incurrirá en el coste de jefes de 3/2 x. Gráficamente:

Cantidad de jefes del IP en el caso de 2 llamadas para el iLBC con el trunking IAX2

(cociente de los jefes del IP al 1 caso de la llamada) 2| |_| 0| | 0 veces 30 60 90 120 180 210 240 300 (milisegundos) del |_| del |_| del |_| del _ 1| del _ del _ del _ del _

Por lo tanto las ecuaciones que utilizan los datos antedichos estarán realmente: 28.0 kb/s = 3/2*headers + codec 49.3 kb/s = 2*headers + 2*codec

¡Solucionando simultáneamente, vemos que 6.7kb/s es realmente el 1/2 los jefes! Y el IP de arriba según ése los datos es tan realmente 13.4kb/s. Esto compara favorable con el valor teórico de 12.7kb/s. Estos gastos indirectos más bajos del IP se relacionan directamente con la frecuencia más baja de la transmisión. Puesto que se transmite solamente 2/3 de tantos paquetes (una vez cada 30ms opuesto una vez a cada 20ms), los gastos indirectos deben ser 2/3 de un codec similar con períodos de la transmisión 20ms (eg. comparado a G.729, 2/3 x 20.3kb/s = 13.53kb/s, que compara otra vez favorable con la figura de la prueba de 13.4kb/s)

Y podemos recolectar tan el siguiente de los datos:

  • ILBC:

una llamada: 56134.91 bps/67.45 pps (28.0 kbps) dos llamadas: 98679.11 bps/102.41 pps (49.3 kbps)

Así:

  • Para cada llamada adicional: 42544 BPS (kbps 14.6)
  • Est. IP/IAX2 de arriba (1 llamada): 13590 BPS (kbps 13.4)
  • Número crudo de llamadas por megabit: 67

También no se indica si estos resultados consideran los efectos de la detección de la actividad de la voz (y de la supresión del silencio que resulta). Aunque el asterisco sí mismo no lo apoya en este tiempo (28/3/05) el teléfono puede inmóvil hacer esto dando por resultado una anchura de banda más baja en una dirección. También, en el futuro el asterisco apoyará VAD: rolleyes:. [Enchufe desvergonzado: Yo también un consultor. Enviarme (herman.webley@blitzllc.com) para los detalles.]

Advertencias: Tenía solamente dos teléfonos con los cuales a la prueba, y solamente una cantidad de tiempo limitada. Una prueba más exacta sería alcanzada poniendo muchas más líneas en un tronco y mirando el pedacito-por-segundo crecimiento del tronco IAX2 - dos llamadas no son probablemente suficientes examinar uso verdadero de la anchura de banda en cualquier cosa con excepción de una manera general. El más interesante ser mirar el crecimiento del uso del canal LPC10, como se suponen para ser solamente 2.4kbps, que podrían dar lugar posiblemente a muchos más canales por megabit si las figuras de arriba permanecen áspero igual con más canales agregados. El número 6.1 para LPC10 se parece un pedacito alto, dado que el uso cotizado es 2.4kbps.

Referencias:

Enchufe desvergonzado: Soy un consultor, y me plazco hacer esta clase de trabajo para desarrollar más lejos tus productos o despliegues de los sistemas de VoIP/del asterisco. Enviarme (jtodd@loligo.com) para los detalles.

Enchufe desvergonzado - con el Info útil: Agregaré también un enchufe shamless, también hago VoIP y la red que consultan y puedo ser alcanzado en trixterNOSPAM@0xdecafbad.com. Ahora para la información útil. Tener presente enmarcar de la capa del acoplamiento que se utiliza también. La atmósfera (qué la mayor parte de el uso de las espinas dorsales de Internet) tiene 53 células fijadas octeto. Hay 5 octetos de jefes. Solamente un paquete puede existir en un grupo de células (un grupo es 1 o más célula hasta que se envía el paquete entero). Esto significa que si intentas enviar un paquete del IP de 80 octetos sobre un acoplamiento de la atmósfera será tajada en 2 células de la atmósfera con 16 octetos de acolchado. Éste es el solamente 83% eficiente. Adjusing tu tamaño de muestra puedes encontrar que tu rendimiento de procesamiento puede ser aumentado porque transfieres datos más útiles y menos acolchado. Hacer que tu tamaño de muestra demasiado pequeño y tú tenéis muchos de IP de arriba, hacerlo demasiado grande y pueden causar problemas con calidad de la llamada (pensar en un almacenador intermediario de la inquietud 30ms y los tamaños de muestra 30ms, en efecto no tienes ningún almacenador intermediario de la inquietud porque se reordenen los paquetes biselan, canto de la inquietud sean controlados, etc). Su un equilibrio fino, pero algo de considerar. Aunque no utilizas la atmósfera que lo hacen las espinas dorsales de Internet a menudo, así que éste es algo que puede hacer transferencias levemente más rápidas y una eficacia mejor de la red. El DSL, E1, el T1, el SMDS, OC1, OC3, OC12 etc todo utilizan generalmente la atmósfera, tan su absolutamente común.

JT

Ver también

  • Marcar con asterisco la anchura de banda
  • Consumición de la anchura de banda
  • Codecs
  • Canales del asterisco IAX
  • Asterisco | FAQ | extremidades y trucos