¿por que?
 
En españa existe un concepto llamado precio de interconexión que fija la CMT (Comisión del mercado de Telecomunicaciones) por la cual cuando se realiza una llamada de un operador A (ej: Movistar) a otro operador B diferente (Ej: Vodafone) el operador A debe pagar al B una cantidad fija por minuto. Este coste nos lo tiene que repercutir a los clientes para no perder dinero.

En caso de que se llame desde el operador A al mismo operador A (ej: llamada entre dos movistar) no existe este coste y pueden ser mucho más agresivos en sus ofertas.

¿y como me puedo aprovechar de sus ofertas? ¿como puedo saber a que compañía pertenece un móvil? 

No es fácil saberlo. Para ello deberíamos saber el IMSI de cada telefono movil. (en realidad de la tarjeta SIM)  pero este es un concepto que las compañías no ofrecen. Ninguna compañía te dice a que operadora pertenece un móvil. Y la CMT no ha regulado este servicio que debería ser obligatorio. Yo no quiero saber el titular (protegido por la ley de protección de datos). Sólo quiero saber de que compañía es. No entiendo porque sólo los operadores móviles tienen acceso a esta información.

¿y que hago? ¿existe alguna forma de saberlo?

Pues en esta web www.queoperador.com te lo dicen.  Acierta más de un 99% de las veces. No detecta algunos operadores moviles virtuales tipo Pepephone, eroski o carrefour pero es realmente interesante para poder aprovecharnos de sus ofertas y por una vez no sentirnos tan timados y ganarles una pequeña batalla a las operadoras.

¿Para que sirve?

Normalmente las comunicaciones telefonicas, en general, todas las conversaciones humanas son “half-duplex”. Un interlocutor habla mientras el otro escucha. No sería necesario mandar los “silencios” de los interlocutores por la
línea puesto que no aportan ninguna información. Esteos algoritmos son capaces de detectar los silencios o la no actividad de la voz.

¿Que ventajas aporta?

Si somos capaces de detectar los silencios podemos no enviar esa información reduciendo el ancho de banda necesario para una conversación telefónica.

A pequeña escala puede parecer poco pero imaginad que tenemos un servicio de 100000 llamadas simultaneas. Con este sistema podemos reducir el tráfico RTP (tráfico de datos en tiempo real) a menos de la mitad lo que supone un importante ahorro en líneas y sistema.

Tras haber leído muchas veces y buscados esta información os pongo todo lo que yo he conseguido encontrar:

Respecto al retardo existe la referencia la ITU-T G.114 “Tiempo de transmisión en un sentido” que incluye el anexo “directrices sobre el tiempo de transmisión en un sentido para la transmisión del voz sobre el protocolo Internet” En general con muchas consideraciones consideran que no debe superar los 150 ms en un sentido.

Respecto al jitter pues es más dificil obtener una normativa. No conozco un documento oficial de la ITU o de la IETF que diga que el jitter tenga que ser inferior a tanto. Además hay varias formas de medir el jitter RFC 3550 o RFC 3611 . En general el jitter medido en los proveedores debería ser menor a 1 ms o 2 ms. A lo que hay que añadir el local, el del proveeedor de VoIP, etc.. luego dificil de calcular.

Yo prefiero quedarme con un dato y es que el jitter buffer no debe superar los 100 ms para no degradar la comunicación. Tampoco existe una RFC  de la ITU que lo diga pero está en muchos sitios por Internet. Este es el limite máximo que podemos darle al jitter buffer y supongo que estará basado en pruebas con usuarios.

http://www.voipforo.com/Telefonos/softphones.php

Pero y si necesito para hacer pruebas un softphone que funcione con H.323.

Os dejo una lista que algunos que funcionan también con protocolo H.323

- SJPhone. http://www.sjlabs.com/
- Yate. http://yate.null.ro/pmwiki/

Si usas SIP deberías abrir normalmente el puerto 5060 que es por donde van la señalización SIP.

Además debes abrir los puertos RTP para la voz y estos suelen cambiar un poquito.

Resumiendo
5060 — UDP (SIP)
16000 ~ 17000 — UDP (para RTP)

Pero lo mejor es que consultes a tu proveedor de Voip porque a veces los RTP pueden ser del 29000 al 29120, etc…

Si por el contarrio usas H.323 o incluso RADIUS para tarificación:

 H323 : 1719 y 1720
Si usas radius: 1812 y 1813

Esta herramienta es perfecta para simular la respuesta de nuestros equipos a los mensajes SIP que queramos construir. La podemos bajar en http://sipp.sourceforge.net/ y nos permite un montón de opciones. Incluido hacer un lanzamiento masivo de mensajes SIP para saber como se comporta nuestra máquina.

El funcionamiento consiste en crear escenarios medainte ficheros del tipo XML y una vez realizados podemos ejecutarlos. Pero mejor que lo intenteis vosotros mismos.

Por último decir que está disponible en varios sistemas operativos como Windows o Linux.

TCP es un protocolo de transporte orientado a conexión y UDP es un protocolo de transporte no orientado a conexión.

Según el último draft de SIP (RFC 3261 en su punto 18 http://www.ietf.org/rfc/rfc3261.txt) se dice:

All SIP elements MUST implement UDP and TCP.SIP elements MAY
implement other protocols.

Making TCP mandatory for the UA is a substantial change from RFC
2543.  It has arisen out of the need to handle larger messages,
which MUST use TCP, as discussed below.Thus, even if an element
never sends large messages, it may receive one and needs to be
able to handle them.

Es decir cualquier dispositivo SIP debiera obligatoriamente poder trabajar con los dos protocolos.

En la actualidad esto no es posible y si bien el 100 % de ellos trabajan actualmente con UDP sólo el 82 % son capaces de hacerlo sobre TCP (datos de Abril de 2007- Conferencia SIPit 20 http://www1.ietf.org/mail-archive/web/sip/current/msg18959.html)

¿Pero que ventajas y desventajas hay entre utilizar SIP sobre TCP o sobre UDP cuando sea posible?

SIP sobre UDP:
UDP es un protocolo más simple y sencillo y no está orientado a conexión. Es más tolerante a problemas de lí­nea y utiliza por lo general menos ancho de banda. Produce menos retrasos y delays y los bufferes a utilizar en los dispositivos son menores.  Es dí­ficil implentar medidas de seguridad sobre UDP y por tanto es más vulnerable a ataques. Además presenta más problemas para atravesar routers que usen NAT. En un principio todos los fabricantes de software y hardware SIP implementaron SIP sobre UDP.

SIP sobre TCP:
TCP es un protocolo más robusto y complicado ya que está orientado a conexión. Es menos tolerante a problemas de lí­nea pero permite una rápida retransmisión cuando se detecta un fallo. Además permite gestionar mejor el control de la congestión y la fragmentación de paquetes. Permite gestionar paquetes de tamaño más elevado y por ello actualmente en algunos casos es imperioso su uso. Permite implentar medidas de seguridad para evitar ataques a las transmisiones. (seguridad frente a spoofing). No todos los dispositivos SIP lo implementan aunque cada dí­a el % de los equipos que lo implementan es mayor.

Mi recomendación es usar SIP sobre TCP siempre que sea posible y no tengamos problemas muy especificos (Ej: ancho de banda limitado) o la necesidad de retrasos extremadamente pequeños en los establecimientos (que no suele ser el caso). El problema es que aún no todos los dispositivos hardware y software lo implementan aunque en un futuro muy cercano seguro que lo harán.

Destacar que si vamos marcando los números de uno en uno el sistema va encaminando la llamada a medida que vamos marcando. (Esto se puede observar si marcamos por ejemplo el prefijo 602 en España que actualmente no está asignado y la red ya nos indica sin marcar más números que ese número no existe). Por eso al marcar dí­gito a dígito parece que hay menos retardo.

Por último, decir que he echado un vistazo al PDD que ofrecen otros proveedores de VoIP que ofrecen terminación de llamadas a móviles en España, y sus valores (cuando los dan que no es tampoco muy frecuente) suelen estar entre 6-10 segundos.

Hoy hablaré de un programa que se llama sipsak. EL programa es muy sencillo y lo podéis descargar en www.sipsak.org : Funciona desde la lí­nea de comandos de MS-DOS.

Para poder ver todas las opciones simplemente teclear “sipsak” en la lí­nea de comandos y veréis todas sus posibilidades.

Un ejemplo útil de para que lo he utilizado yo es para saber si los equipos de VoIP están funcionando. Para ello hago una especie de “Ping SIP”; lo que hago es enviar con el programa un mensaje OPTIONS al servidor de VoIP y si este contesta con un mensaje de OK es que el servidor SIP funciona OK. En caso contrario algo va mal en la máquina.

El comando que utilizo es “sipsak -vvv -s sip:usuario@direccionIP”

El programa tiene más opciones como podréis comprobar vosotros mismos pero se queda un poco corto para testear cosas más complicadas.

Para ello utilizo habitualmente otro del que hablaré más adelante llamado SIPs y que me gusta aún más porque ofrece un montón de posibilidades.

http://www.oxid.it/ca_um/index.html

Es un sniffer llamado Cain & Abel que permite capturar y grabar las conversaciones de VoIP que circulan por una red de Área local. Es decir podemos “espiar” a la gente de una red de área local que utiliza VoIP.

Esto nos da una idea del nivel de seguridad que hoy en dí­a tienen las comunicaciones por VoIP. El programa es capaz de decodificar bastantes codecs y poder grabar las conversaciones en archivos .wav que luego podemos escuchar.

Para más detalles de los codec que decodifica y del modo de funcionamiento del programa os dejo un enlace http://www.oxid.it/ca_um/topics/voip.htm