Formato del mensaje

El formato del mensaje SIP se compone de tres bloques, línea de inicio, cabecera y cuerpo del mensaje. La línea de inicio y las cabeceras tratan de definir el mensaje mientras que el cuerpo lleva los datos de señalización a intercambiar entre ambos extremos. Generalmente, en IMS, se utiliza el formato del protocolo SDP para la descripción de la sesión en el cuerpo del mensaje SIP.

4.1.1.5.1.

Línea de inicio

La línea de inicio, dependiendo si se trata de un mensaje de petición o de respuesta se conoce como ‘request-line’ o ‘status –line’

La línea de petición (‘request-line’) está formada por el nombre del método, la ‘request- URI’, que indica el destinatario, y la versión del protocolo que se está empleando. Para la versión del protocolo hasta ahora siempre se señala SIP/2.0

La línea de estado (‘status-line’), que aparece con los mensajes de respuesta SIP, presenta un formato que comienza con la versión del protocolo (SIP/2.0) y la respuesta

Universidad Politécnica de Madrid -35 - SIP. Recordamos que la respuesta SIP está formada por el indicador numérico según la clase y el texto.

Ejemplos de estas líneas serían:

INVITE sip:[email protected] SIP/2.0, como línea de petición. SIP/2.0 200 OK, como línea de estado.

4.1.1.5.2.

Cabecera

Según se define en la RFC 2822, el formato que presenta la cabecera del protocolo es:

<headre_name>:<header_value>

Donde <header_name> indica el nombre de la cabecera seguido del valor de la misma, <header_value>. Es posible que existan varias cabeceras con el mismo <header_name> dentro de un mismo mensaje SIP, cambiando el campo valor. Los campos más significativos dentro de la cabecera se describen a continuación:

• Via: en este campo se indican los servidores ‘proxy’ por los que salta una petición SIP. Esta información es necesaria para el retorno del mensaje respuesta a dicha petición. Presenta el siguiente formato:

Via:SIP/2.0/<transport><address>:<port>;branch=<ID>

Donde:

o <transport> indica el protocol se transporte utilizado.

o <address> indica la dirección IP que envía en mensaje.

o <port> hace referencia al puerto enpleado en el envío.

o <branh> identifica la transación. Siempre comienza por los caracteres ‘z9hG4bK’

• To: mediante este campo de la cabecera conocemos la dirección SIP URI o

TEL URL del receptor. Esta información se utiliza en la fase de registro y en otras aplicaciones pero no como parámetro de enrutamiento. Puede presentar una cadena de caracteres (“Name”) previa a la dirección URI como información adicional. También puede aparecer una etiqueta (“Tag”) como método de identificación de mensaje. Por tanto, presenta la forma:

Universidad Politécnica de Madrid -36 - Un ejemplo podría ser: To: “Eva” sip:[email protected]

• From: al igual que ‘To’, mediante ‘From’ se identifica la SIP URI o TEL URL del

emisor, manteniendo el mismo formato, con la diferencia que en este caso el parámetro ‘tag’ es opcional.

• Call-ID:

Este campo contiene una identificación única de la sesión. El formato es el siguiente: Call-ID: <identifier>@<domain>

Donde:

o <identifier> es un número hexadecimal

o <domain> se representa con la dirección IP del servidor de dominio que

lo genera

• Cseq: campo que permite conocer la petición a la que va vinculada una

respuesta SIP. Contiene el número de la secuancia y el nombre del método, con el siguiente formato:

Cseq: <seq_number><method>

• Max-Forwards: indica el número máximo de saltos permitido para el mensaje

SIP. Su valor de inicio es el valor máximo asignado y decrementa su valor pòr cada salto.

• Contact: alamacena las URIs en las cuales es posible localizar al UA. El

formato ue presenta es:

Contact: “Name” <URI>=<optional_parameter>, donde el parámetro opcional presenta información adicional, generalmente relacionado con la validez temporal de la petición.

• Record-Route: almacena la dirección del proxy SIP que inserta la cabecera

mientras se hace el enrutamiento de la petición. De esta forma queda registrado por dónde tienen que pasar las siguientes peticiones que se creen dentro del mismo diálogo.

Además de estos parámetros de cabecera, cuando los mensajes SIP contienen descriptores de sesión en el cuerpo del mensaje, se utilizan las cabeceras:

Universidad Politécnica de Madrid -37 -

• Content-type: indica el tipo de descrptor del cuerpo del mensaje. En IMS,

generalmente se utiliza el protocolo SDP, indicándose del modo ‘application/sdp’

• Content-Lenght: indica el número de octetos del cuerpo del mensaje.

4.1.1.5.3.

Cuerpo del mensaje

El cuerpo del mensaje contiene la información que se intercambian los dos extremos en la comunicación. Gracias a la información de la línea de inicio y la cabecera es posible la comunicación extremo a extremo. Además, en la cabecera es donde se indica el tipo de mensaje que se está enviando, y su formato. En IMS, el más utilizado es SDP, que ya veremos más adelante. La información relativa al tipo de formato y la longitud del cuerpo del mensaje (en octetos) se indica en la cabecera mediante los campos ‘Content-Type’ y ‘Content-Lenght’ que hemos mencionado en el anterior apartado.

Como está definido en la RFC 2045 emplea el formato descrito por MIME, el cual permite que el cuerpo del mensaje conste de varias partes cada una con un formato distinto, lo cual vendría especificado en la cabecera de la siguiente forma:

Content-Type: multipart/mixed; boundary = ‘delimiter’

Donde ‘boundary’ es un parámetro que indica la frontera entre las partes del mensaje.

4.1.2. SDP

El protocolo de texto SDP (‘Session Description Protocol’) fue definido por el grupo de estandarización IETF y está definido en la RFC 2327. Se trata de un protocolo destinado a la descripción de los parámetros que son necesarios para la notificación, el inicio y establecimiento de una sesión multimedia. Al igual que SIP, es transparente el protocolo de transporte que se esté utilizando en cada instante.

La descripción de la sesión que realiza SDP consiste en una serie de líneas de texto con la forma <type>=<value., donde el campo denominado ‘tipo’ (<type>) es un único

Universidad Politécnica de Madrid -38 - carácter y ‘valor’ (<value>) puede estar formado por dos parámetros, que en este caso se separarían por un espacio en blanco. Sin embargo, no se permite el espacio en blanco entre los parámetros ‘type’ y ‘value’ y el carácter ‘=’.

De modo genérico, para describir una sesión SDP emplea en orden estricto una serie de datos:

• Descriptores de nivel de sesión: este tipo de descriptor es obligatorio, y

muestra detalles relacionados con todo el conjunto de la sesión y los flujos de datos.

• Descriptores de tiempo: indican el comienzo y finalización para la sesión.

• Descriptores de media: son opcionales, y se centran en detalles que aplican

sobre el flujo de datos de media.

Además, es importante notar que pueden existir varios descriptores de media dentro de una misma sesión.