Conmutación de paquetes IP de Telecom - Parte 4

Escrito por leopedrini jueves, 22 de marzo de 2012 16:10:00 Categories: Curso
Valorar Este Contenido 0 Votos.

Y luego, finalmente llegamos a los protocolos de señalización NGN: SIP y SDP. La siguiente imagen fue extraída de RFC 3261 y da un ejemplo bastante bueno de un diálogo SIP entre dos usuarios, Alice y Bob.

Note: mi blog Smolka et Catervarii (que solo tiene contenido em portugues por lo momento).

 

Las entidades involucradas en el establecimiento de llamada se llaman User Agents (UA). UAs que soliciten los servicios se denominan User Agent clients (UAC), y los que atender las solicitudes se llaman User Agent Servers (UAS). Aunque el modo de funcionamiento básico es end-to-end, el modelo soporta el uso de servidores proxy intermedios, que funcionan como back-to-back user agents (B2BUA) passando solicitudes de un usuario a otro. En la figura el softphone de Alice y el teléfono SIP de Bob son los end-to-end User Agents, mientras que hay dos servidores proxy: atlanta.com y biloxi.com. Vinculando esto con lo que ya sabemos sobre IMS, podemos identificar el P-CSCF como un servidor proxy SIP, mientras que los equipos de usuario son las end-to-end UAs.

Citando la RFC 3261:

"SIP no hace prestación de servicios, pero SIP proporciona primitivas que se pueden utilizar para implementar diferentes servicios. Por ejemplo, SIP puede localizar a un usuario y entregarle un objeto opaco. Si esta primitiva se utiliza para ofrecer una descripción de la sesión del protocolo SDP, por ejemplo, los extremos pueden ponerse de acuerdo sobre los parámetros de una sesión. Si la misma primitiva es utilizada para entregar una foto de la persona que llama, así como la descripción de la sesión, un servicio de ‘identificación de llamada’ puede ser fácilmente implementado. Como muestra este ejemplo, una sola primitiva se utiliza típicamente para soportar varios servicios diferentes. "

Las primitivas SIP son:

  • REGISTER: Indica la dirección IP actual del UA y los Uniform Resource Identifiers (URI) para los que quiera recibir llamadas;
  • INVITAN: Se utiliza para establecer una sesión de comunicación entre UAs;
  • ACK: Confirma los intercambios de mensajes con respuestas fiables (ver más abajo);
  • PRACK (provisional ACK): Confirma los intercambios de mensajes con respuestas provisionales (ver más adelante). Esto se añadió en el RFC 3262;
  • OPCIONES: Solicitudes de información acerca de las capacidades de un servidor proxy SIP o UA, sin la creación de una llamada;
  • CANCEL: Cancela una petición pendiente;
  • BYE: Termina una sesión entre dos UAs.

Típicamente un mensaje SIP tiene que tener una respuesta. Como HTTP,  respuestas SIP están identificadas con números de tres dígitos. El dígito de la izquierda dice a qué categoría pertenece la respuesta:

  • Provisional (1xx): solicitud recibida y em procesamiento;
  • Éxito (2xx): solicitud fue recibida con éxito, entendida y aceptada;
  • Redirección (3xx): hay necesidade de medidas adicionales que deben adoptarse por el remitente para completar la solicitud;
  • Error de cliente (4xx): solicitud contiene sintaxis incorrecta o no se puede cumplir en el servidor/UA de destino;
  • Error de servidor (5xx): El servidor/UA de destino no hay cumplido una petición aparentemente válida;
  • Falla general (6xx): La solicitud no puede cumplirse en cualquier servidor/UA.

Citando la RFC 4566:

Una descripción de sesión SDP consta de un número de líneas de texto de la forma:

<tipo> = <valor>

donde <tipo> debe ser exactamente un carácter, sensible a mayúsculas y minúsculas, y <valor> es um texto estructurado cuyo formato depende de <tipo>. En general, <valor> debe ser un número de campos delimitados por un carácter de espacio o de uno string de formato libre, sensible a mayúsculas y minúsculas, a menos que un campo específico lo defina de otra manera. Los espacios en blanco, no deberán  ser usados a ambos lados del signo "=".

Una descripción de sesión SDP consiste en una sección de nivel de sesión seguido por cero o más secciones a nível de medios. La parte a nivel de sesión se inicia con una línea "v =" y sigue hasta la primera sección de  medios. Cada sección de medios comienza con una línea "m =" y continúa hasta la siguiente sección de medios o al final de la descripción de la sesión entera. En general, los valores de nivel de sesión son los valores por defecto para todos los médios, a menos que se sustituya por un valor equivalente a nivel de los medios. Algunas líneas en cada descripción son obligatorias y otras son opcionales, pero deben aparecer todas en el mismo orden en que aquí (el orden fijo mejora en gran medida la detección de errores y permite un analizador simple). Elementos opcionales se marcan con un "*".

 

He aquí un ejemplo de una descripción de sesión SDP:

 

Muy bien. Creo que eso es suficiente para entender cómo funciona la señalización NGN. Ahora es el momento de dar un paso hacia abajo en la pila TCP/IP, por lo que en nuestro próximo artículo vamos a empezar a hablar acerca de los protocolos de transporte, y entender cómo el API socket se utiliza para crear sesiones separadas sobre el servicio de los protocolos de transporte.

Au revoir, mes amis.