VoIP en profundidad: Una introducción al protocolo SIP 1 parte

en Redes LAN e Inalambricas
TU PANEL DE CONTROL:
REGISTRAR
Wilkinsonpc Tienda Productos Servicios Recursos Gratuitos - Gratis Soporte Comunidad
Foros Qubitaria Ayuda de los Foros
Retroceder   Foros Comunidad : Hardware y Electronica : Redes LAN e Inalambricas
Redes LAN e Inalambricas Redes LAN e Inalambricas Todo sobre Redes LAN e Inalambricas. Proveedores de servicio, aplicativos, voIP. Bluetooth, Wi-Fi y todo lo Wireless.

VoIP en profundidad: Una introducción al protocolo SIP 1 parte

Compartir

En el último tramo de VoIP, nos fijamos en las principales razones por SIP se ha convertido en un protocolo ampliamente adoptado, pero dejamos los detalles de funcionamiento interno del protocolo es bastante vaga. Este artículo profundizar en la manera en Session Initiation Protocol (SIP) las obras, y debería servir como un buen punto de partida para aprender realmente SIP. Si no lo ha hecho, le animamos a leer el artículo anterior, aunque no es un requisito previo. En esta introducción se incluye también las extensiones SIP y los cambios más recientes, por lo que da una visión completa del estado actual del protocolo, y no sólo la base, subyacente RFC.

Session Initiation Protocol (SIP) es un protocolo de señalización VoIP. Como su nombre indica, tiene todo que ver con el establecimiento de las sesiones, lo que significa que tiene la responsabilidad de iniciar una sesión después de marcar un número (o doble clic, en algunos casos). Como tal, el papel de SIP también incluye el mantenimiento de registros de usuarios con un servidor, la definición de período de sesiones de enrutamiento, manejo de varias situaciones de error, y, por supuesto, modificar y demoler sesiones.

Vamos a presentar esta introducción en dos partes. En la primera parte, nos centraremos en las capas de base SIP. Estas capas permiten la creación de una red de servidores SIP. En el próximo artículo, vamos a ir por el camino uno se comunica teléfono con el resto del mundo a través de esta red de servidores, basados en las capas misma fundación.
SIP Fundaciones
Estructura del mensaje:

SIP comparte la estructura del mensaje mismo como HTTP y RTSP. Como resultado, la mayor parte de la descripción de texto que aquí se ajustan a esos protocolos. Cada mensaje es una petición o una respuesta. Todos los mensajes están basados en texto y tener la siguiente forma:

* Primera línea
Encabezados *
* La línea vacía
* Cuerpo Facultativo

La primera línea es diferente de una petición y una respuesta. primera línea con una petición usa el siguiente formato:

<method (request type)> <URI (address/resource)> <version>

Por ejemplo, la primera línea de una solicitud SIP pueden ser:

sip REGISTRO: SIP/2.0 arstechnica.com

Una respuesta viene en forma de:

<version> <code> phrase> <reason

La versión es la misma en todos los mensajes. El código es un valor de 3-dígitos, y la frase de las razones podría ser el texto que describe la naturaleza de la respuesta. Una primera línea correcta en la respuesta podría ser:

SIP/2.0 200 OK

Es fácil de escanear los primeros caracteres de un mensaje para detectar si se trata de una solicitud o una respuesta ("/" no es un carácter válido para el campo método, por tanto, incluso un analizador genérico puede diferenciar una solicitud de una respuesta).

Luego vienen las cabeceras del mensaje. Algunos encabezados contienen información vital y por lo tanto son obligatorias, pero las cabeceras son opcionales. Cada encabezado tiene un nombre y un valor, y algunos tienen parámetros. Por ejemplo:

Contacto: sip: [email protected]; Expires = 2000

Contacto es el nombre de encabezado, sip: [email protected] es el valor, y que expira = 2000 es un parámetro. Otros parámetros pueden aparecer separadas por punto y coma.

Algunos encabezados puede aparecer sólo una vez en un mensaje, y algunos pueden aparecer varias veces. Un sistema similar al uso de múltiples cabeceras es para separar cada valor de parámetro con una coma. Algunos encabezados tienen una forma compacta para que el nombre del encabezado es más corta. Por ejemplo, puede usar la "m" en lugar de "Contacto".

Después de la última cabecera, hay una línea en blanco seguida del cuerpo del mensaje. El cuerpo puede ser cualquier cosa, incluso la información binaria. El encabezado Content-Type especifica el tipo de cuerpo del mensaje. Con el fin de conocer la longitud del cuerpo, tiene que ver el encabezado Content-Length. (Si el tipo de transporte es UDP, a continuación, el encabezado Content-Length no es obligatoria. Se trata, sin embargo, obligatorio para TCP). Uno de los usos comunes del cuerpo es encapsular el protocolo de negociación de comunicación en el mensaje SIP.

Eso es más o menos lo que necesita saber para entender la estructura básica de la SIP. Es bastante sencillo, y cualquiera que ya está familiarizado con los protocolos que tener una estructura similar se sentirá como en casa. Por supuesto, todavía tenemos que entender lo que significa este texto y lo que un dispositivo SIP debe hacer con los mensajes que envía y recibe.
Tipos de transporte

De forma predeterminada, los mensajes SIP se envían en el puerto 5060 si están sin encriptar. Los mensajes cifrados se envían a través del puerto 5061. Se puede especificar un puerto que no sea el predeterminado en la dirección SIP y reemplazar este valor por defecto.

SIP mandatos de apoyo tanto para UDP y TCP, pero puede funcionar con éxito en prácticamente cualquier tipo de transporte. Se define un comportamiento diferente al de transporte sólo cuando las características específicas del transporte obliga a hacerlo. Por ejemplo, UDP no garantiza la entrega, por lo que retransmite los mensajes SIP. En TCP, la retransmisión es en realidad innecesaria (y confusa), así que nadie debe retransmitir un mensaje. En su mayor parte, excepto la capa de transacción (se detalla en la siguiente sub-sección), casi sin cambios el otro componente de su comportamiento a causa del transporte.

De hecho, como SIP opera hop-by-hop (los clientes no suelen comunicarse directamente, sino más bien usar proxies a lo largo de la ruta de señalización para enviar y recibir mensajes), cada salto podría cambiar el tipo de transporte. Así, un cliente puede recibir un mensaje a través de TCP, incluso si el mensaje original fue enviado a través de UDP. independencia SIP tipo de transporte permite la posibilidad de definir nuevos tipos de transporte que no se incluyeron en la propia SIP se definió en primer lugar. Por ejemplo, RFC 4158 es un muy corto RFC que define SIP sobre SCTP.

Para los transportes basados en conexión (por ejemplo, TCP y SCTP), el estado de las conexiones se mantiene. Las conexiones se mantienen abiertos y volver a utilizar para ahorrar tiempo y recursos. La recomendación es mantener una conexión abierta durante al menos 32 segundos después del último mensaje, pero en la práctica es definido por la aplicación. Porque no hay límite definido para el número de diferentes mensajes SIP que se puede enviar en una conexión, dos de estos dispositivos como apoderados por lo general tienen una o muy pocas conexiones entre ellas.
NAT vs VoIP

Uno de los principales retos que los protocolos de VoIP han encontrado y SIP no es una excepción, es la existencia de dispositivos NAT. NATs varias direcciones IP por lo general agregada (en muchos casos dentro de una red privada) para algunas direcciones IP externa, la cartografía de tráfico diferentes a diferentes direcciones IP a los diferentes puertos. (Esta es una descripción muy simplista de NATs; de hecho hay varias maneras de NAT puede funcionar, pero esto es muy común que es fácil de describir). El fin de trazar las direcciones diferentes a la propiedad intelectual y los puertos, NAT generalmente mantienen una tabla de asignación dinámica. Si el tráfico de 172.16.1.1 con el puerto 5060 se asigna a una dirección IP pública con el puerto 10000, el NAT mantendrá esta asignación, siempre que haya un flujo de paquetes desde esa dirección. Si se detiene el flujo, la NAT se eliminará esta asignación después de un período de tiempo configurable para permitir a otro interno y un puerto IP para usar la IP externa y la combinación de puerto.

problema de VoIP se debe a que son los protocolos de señalización minimalista como sea posible en términos de tráfico. Con el fin de permitir que el resto del mundo para localizar un dispositivo, el dispositivo registra por primera vez por el envío de una petición REGISTER. Una respuesta de la aceptación de este registro de inscripción por lo general le dirá al dispositivo que su registro es válido por un largo tiempo, con mayor frecuencia de una hora.

Ahora, supongamos que un NAT se encuentra entre el cliente y el servidor. Cuando la solicitud se envía REGISTRO, los mapas NAT IP interna del dispositivo y el puerto a una externa. Cuando la respuesta se envía de vuelta, el NAT tiene la cartografía propia de la investigación original y el puerto. Si el cliente no envía los paquetes al servidor (por ejemplo, no realizar una llamada), el NAT puede quitar la asignación que creó durante el registro. El resultado de este escenario es que las llamadas entrantes no puede llegar al cliente. El servidor proxy recibe la solicitud para el cliente registrado no puede llegar a la dirección IP interna, sin la asignación de NAT.

Es debido a este problema NAT que RFC 5626 se introdujo. Este RFC define las técnicas que un cliente puede usar para mantener la asignación de NAT. Introduce el concepto de un flujo que debe ser mantenido por el cliente registrarse. El cliente envía dos líneas vacías (retorno de carro y avance de línea, o CRLF) en el flujo orientado a la conexión (TCP y SCTP), y espera recibir del servidor de una sola línea vacía como una respuesta. Para la conexión, menos transporte, el cliente mantiene el flujo mediante el uso de STUN (definido por el RFC 5389).
Compartir
  #1  
Creado: 31-Mar-2010, a las 23:16 Vistas: 8232
Categoria: Redes LAN e Inalambricas
Creado por: svyatoslav svyatoslav está desconectado (29-March-2010 | Colombia | 1.618 Mensajes.)
 

Etiquetas
parte, profundidad, protocolo, sip, voip


Temas Similares
» Intel acelera la introducción de los Atom Dual-Core. 0
» Vulnerabilidad descubierta en el protocolo WiFi WPA2 0
» Introduccion a los sistemas virtualizados 0
» El Reciclaje de la Corteza Terrestre a Gran Profundidad 0
» Cómo y Cuándo las Placas Tectónicas Se Hunden a Gran Profundidad 0
» Vulnerabilidad en protocolo Chrome de Firefox 0
» Nueva vulnerabilidad en QuickTime y el protocolo RTSP 0
» Vulnerabilidad en protocolo FTP de Opera (PASV) 0
» Vulnerabilidad en protocolo RTSP de Apple QuickTime 0
» Falsificación de PIN en el protocolo Bluetooth 0


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Ir al Foro


» ComuniDAD
Inicio
Noticias de Actualidad
Apuntes, Monografias y Tareas
Telefonia, Celulares, TV, GPS, ISP, PDA
Programas Windows, Mac, Linux, etc.
Hardware, Electronica y Redes
Diseño Web y Programacion
Internet y Grandes Portales
Juegos, Consolas y Emuladores
Multimedia, Diseño y Animaciones
Peliculas, Series, Musica, Trailers, Videos, Parodias
Seguridad y Spyware
Salud, Bienestar, Familia y Esparcimiento
Economia, Negocios y Asuntos Legales
Hoteles, Viajes y Turismo
Mundo a Motor [Motos, Autos, etc]
Foros Generales (OFF TOPIC)
Calendario de Eventos
Administracion ComuniDAD



Ultimos Temas


La franja horaria es GMT -5. Ahora son las 04:17.


2010 ©
Powered by : vBulletin® Versión 3.8.8 Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
Sitemap 1 - Sitemap 2 - Sitemap 3 - Sitemap 4