«

»

Imprimir esta Entrada

Protocolo SIP

Protocolo SIPSession Initiation Protocol (SIP o Protocolo de Inicio de Sesiones) es un protocolo desarrollado por el grupo de trabajo MMUSIC del IETF con la intención de ser el estándar para la iniciación, modificación y finalización de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz, mensajería instantánea, juegos en línea y realidad virtual.

La sintaxis de sus operaciones se asemeja a las de HTTP y SMTP, los protocolos utilizados en los servicios de páginas Web y de distribución de e-mails respectivamente. Esta similitud es natural ya que SIP fue diseñado para que la telefonía se vuelva un servicio más en Internet.

En noviembre del año 2000, SIP fue aceptado como el protocolo de señalización de 3GPP y elemento permanente de la arquitectura IMS (IP Multimedia Subsystem). SIP es uno de los protocolos de señalización para voz sobre IP, otro es H.323 y IAX actualmente IAX2.

Diseño del protocolo

El protocolo SIP fue diseñado por el IETF con el concepto de “caja de herramientas”, es decir, el protocolo SIP se vale de las funciones aportadas por otros protocolos, que da por hechas y no vuelve a desarrollar. Debido a este concepto, SIP funciona en colaboración con otros muchos protocolos. El protocolo SIP se concentra en el establecimiento, modificación y terminación de las sesiones, y se complementa entre otros con el SDP, que describe el contenido multimedia de la sesión, por ejemplo qué direcciones IP, puertos y códecs se usarán durante la comunicación. Es un protocolo de señalización. Se complementa con el RTP (Real-time Transport Protocol), portador del contenido de voz y vídeo que intercambian los participantes en una sesión establecida por SIP.

Otro concepto importante en su diseño es el de extensibilidad. Esto significa que las funciones básicas del protocolo, definidas en la RFC 3261, pueden ser extendidas mediante otras RFC (Requests for Comments) dotando al protocolo de funciones más potentes.

Las funciones básicas del protocolo incluyen:

  • Determinar la ubicación de los usuarios, aportando movilidad.
  • Establecer, modificar y terminar sesiones multipartitas entre usuarios.

El protocolo SIP adopta el modelo cliente-servidor y es transaccional. El cliente realiza peticiones (requests) que el servidor atiende y genera una o más respuestas (dependiendo de la naturaleza, método de la petición). Por ejemplo para iniciar una sesión el cliente realiza una petición con el método INVITE en donde indica con qué usuario (o recurso) quiere establecer la sesión. El servidor responde ya sea rechazando o aceptado esa petición en una serie de respuestas. Las respuestas llevan un código de estado que brindan información acerca de si las peticiones fueron resueltas con éxito o si se produjo un error. La petición inicial y todas sus respuestas constituyen una transacción.

Los servidores, por defecto, utilizan el puerto 5060 en TCP (Transmission Control Protocol) y UDP (User Datagram Protocol) para recibir las peticiones de los clientes SIP.

Aunque existen muchos otros protocolos de señalización para VoIP, SIP se caracteriza porque sus promotores tienen sus raíces en la comunidad IP y no en la industria de las telecomunicaciones. SIP ha sido estandarizado y dirigido principalmente por el IETF mientras que el protocolo de VoIP H.323 ha sido tradicionalmente más asociado con la Unión Internacional de Telecomunicaciones. Sin embargo, las dos organizaciones han promocionado ambos protocolos del mismo modo.

SIP es similar a HTTP y comparte con él algunos de sus principios de diseño: es legible por humanos y sigue una estructura de petición-respuesta. Los promotores de SIP afirman que es más simple que H.323. Sin embargo, aunque originalmente SIP tenía como objetivo la simplicidad, en su estado actual se ha vuelto tan complejo como H.323. SIP comparte muchos códigos de estado de HTTP, como el familiar ‘404 no encontrado’ (404 not found). SIP y H.323 no se limitan a comunicaciones de voz y pueden mediar en cualquier tipo de sesión comunicativa desde voz hasta vídeo o futuras aplicaciones todavía sin realizar.

 Arquitectura SIP

El propósito de SIP es la comunicación entre dispositivos multimedia. SIP hace posible esta comunicación gracias a dos protocolos que son RTP/RTCP y SDP.

El protocolo RTP se usa para transportar los datos de voz en tiempo real (igual que para el protocolo H.323, mientras que el protocolo SDP se usa para la negociación de las capacidades de los participantes, tipo de codificación, etc.)

SIP fue diseñado de acuerdo al modelo de Internet. Es un protocolo de señalización extremo a extremo que implica que toda la lógica es almacenada en los dispositivos finales (salvo el rutado de los mensajes SIP). El estado de la conexión es también almacenado en los dispositivos finales. El precio a pagar por esta capacidad de distribución y su gran escalabilidad es una sobrecarga en la cabecera de los mensajes producto de tener que mandar toda la información entre los dispositivos finales.

SIP es un protocolo de señalización a nivel de aplicación para establecimiento y gestión de sesiones con múltiples participantes. Se basa en mensajes de petición y respuesta y reutiliza muchos conceptos de estándares anteriores como HTTP y SMTP.

Componentes del Protocolo SIP

SIP soporta funcionalidades para el establecimiento y finalización de las sesiones multimedia: localización, disponibilidad, utilización de recursos, y características de negociación.

Para implementar estas funcionalidades, existen varios componentes distintos en SIP. Existen dos elementos fundamentales, los agentes de usuario (UA) y los servidores.

1. User Agent (UA): consisten en dos partes distintas, el User Agent Client (UAC) y el User Agent Server (UAS). Un UAC es una entidad lógica que genera peticiones SIP y recibe respuestas a esas peticiones. Un UAS es una entidad lógica que genera respuestas a las peticiones SIP.

Ambos se encuentran en todos los agentes de usuario, así permiten la comunicación entre diferentes agentes de usuario mediante comunicaciones de tipo cliente-servidor.

2. Los servidores SIP pueden ser de tres tipos:

– Proxy Server: retransmiten solicitudes y deciden a qué otro servidor deben remitir, alterando los campos de la solicitud en caso necesario. Es una entidad intermedia que actúa como cliente y servidor con el propósito de establecer llamadas entre los usuarios. Este servidor tienen una funcionalidad semejante a la de un Proxy HTTP que tiene una tarea de encaminar las peticiones que recibe de otras entidades más próximas al destinatario. Existen dos tipos de Proxy Servers: Statefull Proxy y Stateless Proxy.

  • Statefull Proxy: mantienen el estado de las transacciones durante el procesamiento de las peticiones. Permite división de una petición en varias (forking), con la finalidad de la localización en paralelo de la llamada y obtener la mejor respuesta para enviarla al usuario que realizó la llamada.
  • Stateless Proxy: no mantienen el estado de las transacciones durante el procesamiento de las peticiones, únicamente reenvían mensajes.

– Registrar Server: es un servidor que acepta peticiones de registro de los usuarios y guarda la información de estas peticiones para suministrar un servicio de localización y traducción de direcciones en el dominio que controla.

– Redirect Server: es un servidor que genera respuestas de redirección a las peticiones que recibe. Este servidor reencamina las peticiones hacia el próximo servidor.

La división de estos servidores es conceptual, cualquiera de ellos puede estar físicamente una única máquina, la división de éstos puede ser por motivos de escalabilidad y rendimiento.

 Mensajes SIP

SIP es un protocolo textual que usa una semántica semejante a la del protocolo HTTP. Los UAC realizan las peticiones y los UAS retornan respuestas a las peticiones de los clientes. SIP define la comunicación a través de dos tipos de mensajes. Las solicitudes (métodos) y las respuestas (códigos de estado) emplean el formato de mensaje genérico establecido en el RFC 2822 , que consiste en una línea inicial seguida de un o más campos de cabecera (headers), una línea vacía que indica el final de las cabeceras, y por último, el cuerpo del mensaje que es opcional.

– Métodos SIP
Las peticiones SIP son caracterizadas por la línea inicial del mensaje, llamada Request-Line, que contiene el nombre del método, el identificador del destinatario de la petición (Request-URI) y la versión del protocolo SIP. Existen seis métodos básicos SIP (definidos en RFC 254) que describen las peticiones de los clientes:

INVITE: Permite invitar un usuario o servicio para participar en una sesión o para modificar parámetros en una sesión ya existente.
ACK: Confirma el establecimiento de una sesión.
OPTION: Solicita información sobre las capacidades de un servidor.
BYE: Indica la terminación de una sesión.
CANCEL: Cancela una petición pendiente.
REGISTER: Registrar al User Agent.

Sin embargo, existen otros métodos adicionales que pueden ser utilizados, publicados en otros RFCs como los métodos INFO, SUBSCRIBER,etc.

A continuación un ejemplo real de mensaje del metodo REGISTER:


Via: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG4bK646464100000000b43c52d6c00000d1200000f03
Content-Length: 0
Contact: <sip:20000@192.168.0.100:5060>
Call-ID: ED9A8038-A29D-40AB-95B1-0F5F5E905574@192.168.0.100
CSeq: 36 REGISTER
From: <sip:20000@192.168.0.101>;tag=910033437093
Max-Forwards: 70
To: <sip:20000@192.168.0.101>
User-Agent: SJphone/1.60.289a (SJ Labs)
Authorization: Digest username=”20000″,realm=”192.168.0.101″,nonce=”43c52e9d29317c0bf1f885b9aaff1522d93c7692″
,uri=”192.168.0.101″,response=”f69463b8d3efdb87c388efa9be1a1e63″

– Respuestas (Códigos de estado) SIP.

Después de la recepción e interpretación del mensaje de solicitud SIP, el receptor del mismo responde con un mensaje. Este mensaje, es similar al anterior, difiriendo en la línea inicial, llamada Status-Line, que contiene la versión de SIP, el código de la respuesta (Status–Code) y una pequeña descripción (Reason-Phrase). El código de la respuesta está compuesto por tres dígitos que permiten clasificar los diferentes tipos existentes. El primer dígito define la clase de la respuesta.

Codigo Clases
1xx – Mensajes provisionales.
2xx – Respuestas de éxito.
3xx – Respuestas de redirección.
4xx – Respuestas de fallo de método.
5xx – Respuestas de fallos de servidor.
6xx – Respuestas de fallos globales.

A Continuación, se incluye un ejemplo de un código de respuesta.

Internet Protocol, Src Addr: 192.168.0.101 (192.168.0.101), Dst Addr:
192.168.0.100 (192.168.0.100)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol
Status-Line: SIP/2.0 200 OK
Status-Code: 200
Resent Packet: False

Via: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG4bK646464100000000b43c52d6c00000d1200000f03
Content-Length: 0
Contact: <sip:20100@192.168.0.100:5060>
Call-ID: ED9A8038-A29D-40AB-95B1-0F5F5E905574@100.100.100.16
CSeq: 36 REGISTER
From: <sip:20000@192.168.0.101>;tag=910033437093
Max-Forwards: 70
To: <sip:20000@192.168.0.101:5060>
Authorization: Digest username=”20100″,realm=”192.168.0.101“,nonce=”43c52e9d29317c0bf1f885b9aaff1522d93c7692”,uri=”sip:192.168.0.101“,
response=”f69463b8d3efdb87c388efa9be1a1e63”

Mensajes de error SIP

A continuación se muestran los errores que se pueden producir en los mensajes SIP de manera más detallada explicando la causa concreta del error:

Como se ha indicado anteriormente corresponde con las respuestas de la clase:

  • 4xx – Respuestas de fallo de método.
  • 5xx – Respuestas de fallos de servidor.
  • 6xx – Respuestas de fallos globales.

Estos errores se corresponden con los mensajes de error Q.931 o DSS1 y suponen el mapeo de los eventos SIP con lós códigos de error de la RTC (Red telefónica conmutada)

Evento SIP
Valor decimal (DSS1)
Valor hexadecimal (DSS1)
Valor transmitido en el canal D
Detalle
400 Bad request
127
7f
ff
Interworking, unspecified
401 Unauthorized
57
39
b9
Bearer capability not authorized
402 Payment required
21
15
95
Call rejected
403 Forbidden
57
39
b9
Bearer capability not authorized
404 Not found
1
01
81
Unallocated (unassigned) number
405 Method not allowed
127
7f
ff
Interworking, unspecified
406 Not acceptable
127
7f
ff
Interworking, unspecified
407 Proxy authentication required
21
15
95
Call rejected
408 Request timeout
102
66
e6
Recover on Expires timeout
409 Conflict
41
29
a9
Temporary failure
410 Gone
1
01
81
Unallocated (unassigned) number
411 Length required
127
7f
ff
Interworking, unspecified
413 Request entity too long
127
7f
ff
Interworking, unspecified
414 Request URI (URL) too long
127
7f
ff
Interworking, unspecified
415 Unsupported media type
79
4f
cf
Service or option not available
420 Bad extension
127
7f
ff
Interworking, unspecified
480 Temporarily unavailable
18
12
92
No user response
481 Call leg does not exist
127
7f
ff
Interworking, unspecified
482 Loop detected
127
7f
ff
Interworking, unspecified
483 Too many hops
127
7f
ff
Interworking, unspecified
484 Address incomplete
28
1c
9c
Address incomplete (invalid number format)
485 Address ambiguous
1
01
81
Unallocated (unassigned) number
486 Busy here
17
11
91
User busy
487 Request cancelled
127
7f
ff
Interworking, unspecified
488 Not acceptable here
127
7f
ff
Interworking, unspecified
500 Internal server error
41
29
a9
Temporary failure
501 Not implemented
79
4f
cf
Service or option not implemented
502 Bad gateway
38
26
a6
Network out of order
503 Service unavailable
63
3f
bf
Service or option unavailable
504 Gateway timeout
102
66
e6
Recover on Expires timeout
505 Version not implemented
127
7f
ff
Interworking, unspecified
580 Precondition Failed
47
2f
af
Resource unavailable, unspecified
600 Busy everywhere
17
11
91
User busy
603 Decline
21
15
95
Call rejected
604 Does not exist anywhere
1
01
81
Unallocated (unassigned) number
606 Not acceptable
58
3a
ba
Bearer capability not presently available

Cabecera SIP

Las cabeceras se utilizan para transportar información necesaria a las entidades SIP. A continuación, se detallan los campos:

– Via: Indica el transporte usado para el envío e identifica la ruta del request, por ello cada proxy añade una línea a este campo.
– From: Indica la dirección del origen de la petición.
– To: Indica la dirección del destinatario de la petición.
– Call-Id: Identificador único para cada llamada y contiene la dirección del host. Debe ser igual para todos los mensajes dentro de una transacción.
– Cseq: Se inicia con un número aleatorio e identifica de forma secuencial cada petición.
– Contact : Contiene una (o más) dirección que pueden ser usada para contactar con el usuario.
– User Agent: Contiene el cliente agente que realiza la comunicación.

Message Header
Via: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG4bK646464100000007343c52679000020a600000e45
Content-Length: 0
Call-ID: 911D32E5-EEDF-4572-B0B2-61B294636E88@192.168.0.100
CSeq: 1 ACK
From: “Prueba”<sip:20000@miasterisk.com>;tag=8922404614682
Max-Forwards: 70
Route: <sip:20001@192.168.0.1>
To: <sip:20001@miasterisk.com>;tag=as0a27b928
User-Agent: SJphone/1.60.289a (SJ Labs)
Contact: <sip:20100@192.168.0.100:5060>;expires=3600

 

Direccionamiento SIP

Una de las funciones de los servidores SIP es la localización de los usuarios y resolución de nombres. Normalmente, el agente de usuario no conoce la dirección IP del destinatario de la llamada, sino su e-mail.

Las entidades SIP identifican a un usuario con las SIP URI (Uniform Resource Identifiers) definido en el RFC 2396. Una SIP URI tiene un formato similar al del e-mail, consta de un usuario y un dominio delimitado por una @, como muestra los siguientes casos:

usuario@dominio, donde dominio es un nombre de dominio completo.
usuario@equipo, donde equipo es el nombre de la máquina.
usuario@dirección_ip, donde dirección_ip es la dirección IP del dispositivo.
número_teléfono@gateway, donde el gateway permite acceder al número de teléfono a través de la red telefónica pública.

La solución de identificación de SIP, también puede ser basada en el DNS descrito en el RFC 3263, donde se describen los procedimientos DNS utilizados por los clientes para traducir una SIP URI en una dirección IP, puerta y protocolo de transporte utilizado, o por los servidores para retornar una respuesta al cliente en caso de que la petición falle.

Protocolo SDP – SIP

El protocolo SDP (Session Description Protocol) RFC 2327 se utiliza para describir sesiones multicast en tiempo real, siendo útil para invitaciones, anuncios, y cualquier otra forma de inicio de sesiones.

La propuesta original de SDP fue diseñada para anunciar información necesaria para los participantes y para aplicaciones de multicast MBONE (Multicast Backbone). Actualmente, su uso está extendido para el anuncio y la negociación de las capacidades de una sesión multimedia en Internet.

Puesto que SDP es un protocolo de descripción, los mensajes SDP se pueden transportar mediante distintos protocolos con SIP, SAP, RTSP, correo electrónico con aplicaciones MIME o protocolos como HTTP. Como el SIP, el SDP utiliza la codificación del texto. Un mensaje del SDP se compone de una serie de líneas, denominados campos, dónde los nombres son abreviados por una sola letra, y está en una orden requerida para simplificar el análisis. El SDP no fue diseñado para ser fácilmente extensible.

La única manera de ampliar o de agregar nuevas capacidades al SDP es definir un nuevo atributo. Sin embargo, los atributos desconocidos pueden ser ignorados. En la tabla siguiente podemos observar todos los campos.

Tipo Descripción Obligatorio

V Versión del protocolo (obligatorio)
o Identificador (obligatorio)
S Nombre de sesión (obligatorio)
I Información de la sesión (obligatorio)
U URI de la descripción
e Dirección de correo
p Número de teléfono
C Información de conexión
b Ancho de banda
Z Tiempo de corrección
K Clave de encriptación
a Atributos
T Tiempo de sesión(Start y stop) (obligatorio)
R Tiempo de repetición
m Información del protocolo de transporte(media) (obligatorio)

Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): Cisco-SIPUA 26425 12433 IN IP4
192.168.0.100
Owner Username: Cisco-SIPUA
Session ID: 26425
Session Version: 12433
Owner Network Type: IN
Owner Address Type: IP4
Owner Address: 192.168.0.100
Session Name (s): SIP Call
Connection Information (c): IN IP4 192.168.0.100
Connection Network Type: IN
Connection Address Type: IP4
Connection Address: 192.168.0.100
Time Description, active time (t): 0 0
Session Start Time: 0
Session Stop Time: 0
Media Description, name and address (m): audio 17338 RTP/AVP 0 8 18 101
Media Type: audio
Media Port: 17338
Media Proto: RTP/AVP
Media Format: ITU-T G.711 PCMU
Media Format: ITU-T G.711 PCMA
Format: ITU-T G.729
Media Format: 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15

 

Ejemplo Comunicación SIP

A continuación se analizará detalladamente una llamada. En una llamada SIP hay varias transacciones SIP. Una transacción SIP se realiza mediante un intercambio de mensajes entre un cliente y un servidor. Consta de varias peticiones y respuestas y para agruparlas en la misma transacción esta el parámetro CSeq.

Ejemplo de protocolo SIP

Las dos primeras transacciones corresponden al registro de los usuarios. Los usuarios deben registrarse para poder ser encontrados por otros usuarios. En este caso, los terminales envían una petición REGISTER, donde los campos from y to corresponden al usuario registrado. El servidor Proxy, que actúa como Register, consulta si el usuario puede ser autenticado y envía un mensaje de OK en caso positivo.

La siguiente transacción corresponde a un establecimiento de sesión. Esta sesión consiste en una petición INVITE del usuario al proxy. Inmediatamente, el proxy envía un TRYING 100 para parar las retransmisiones y reenvía la petición al usuario B. El usuario B envía un Ringing 180 cuando el teléfono empieza a sonar y también es reenviado por el proxy hacia el usuario A. Por ultimo, el OK 200 corresponde a aceptar la llamada (el usuario B descuelga).

En este momento la llamada está establecida, pasa a funcionar el protocolo de transporte RTP con los parámetros (puertos, direcciones, codecs, etc.) establecidos en la negociación mediante el protocolo SDP.

La última transacción corresponde a una finalización de sesión. Esta finalización se lleva a cabo con una única petición BYE enviada al Proxy, y posteriormente reenviada al usuario B. Este usuario contesta con un OK 200 para confirmar que se ha recibido el mensaje final correctamente.

17,201 total views, 7 views today



!!! AYUDANOS A MANTENER ESTE SITIO ACTIVO…!!!

Si piensas que te hemos ayudado y merecemos tu apoyo. !!! GRACIAS !!!

Cuando lo hagas tendras acceso inmediato a la documentacion en formato PDF para que la descargues. Encontraras tambien otros tutoriales mas avanzados no publicados en el sitio. Si no puedes o no quieres, no hay problema igual tendras acceso a toda la informacion publicada en este sitio.

!!CLICK AQUI.!! para ver Tutoriales a descargar

!!! GRACIAS POR TU DONACION !!!






Enlace permanente a este artículo: http://elastixtech.com/protocolo-sip/

Deja un comentario