SIP proviene de Session Initiation Protocol (Protocolo de inicio de sesión) es un protocolo de señalización para VoIP definido por la Internet Engineering Task Force (IETF) que permite el establecimiento, la liberación y la modificación de sesiones multimedia (RFC3261).
Este protocolo combina lo mejor de los protocolos HTTP (Hyper Text Transport Protocol ) y SMTP (Simple Mail Transport Protocol ), creando un modelo transaccional del tipo cliente/servidor (al estilo HTTP), identificando al cliente o servidor mediante el uso de un localizador de recursos uniforme o URL (Uniform Resource Locator), llamado URL SIP (Ejemplo: 6001@ 192.168.1.32 de Ekiga), parecido a una direccion E-mail.
Cada cliente (SIP, IAX, etc) o integrante de una red SIP es alcanzable a través de una dirección URL SIP, el proceso de autenticación se lleva a cabo mediante un conjunto de respuestas identificadas por un código digital, de forma similar a http. Por ejemplo, si el destinatario no puede ser ubicado, se envía como código de respuesta «404 Not Found».
Un requerimiento SIP está constituido de "headers" o cabeceras, al igual que un envió SMTP. Por lo tanto, concluimos que SIP también es un protocolo textual. Una vez que la sesión ha sido establecida, los participantes pueden intercambiar trafico de audio/video a través del protocolo RTP (Real-Time Transport Protocol).
SIP no es un protocolo de reserva de recursos, en consecuencia, no puede asegurar la calidad de servicio. Se trata de un protocolo de control de llamada y no de control del medio.
SIP tampoco es un protocolo de transferencia de fichero como "http", usado con el fin de transportar grandes volúmenes de datos. Ha sido concebido para transmitir mensajes de señalización cortos con el fin de establecer, mantener y liberar sesiones multimedia. Sin embargo mensajes cortos del tipo sms, no relativos a una llamada, pueden ser transportados por SIP.
Entidades SIP
Una red SIP está compuesta por las siguientes entidades:
- Servidor Proxy (Proxy Server): Recibe solicitudes de clientes que el mismo trata o las encamina hacia otros servidores después de haber realizado un tratamiento previo a dichas solicitudes.
- Servidor de Redireccionamiento (Redirect Server): Se trata de un servidor que acepta solicitudes SIP, traduce la dirección SIP de destino en una o varias direcciones de red y las devuelve al cliente. De manera contraria al Proxy Server, el Redirect Server no encamina las solicitudes SIP. En el caso de la devolución de una llamada, el Proxy Server tiene la capacidad de traducir el numero del destinatario recibido en el mensaje SIP, en un numero de reenvió de llamada y encaminar la llamada a este nuevo destino, y eso de manera transparente para el cliente de origen. Para el mismo servicio, el Redirect Server devuelve el nuevo número (numero de reenvió) al cliente de origen quien se encarga de establecer una llamada hacia este nuevo destino.
- Agente Usuario (User Agent) o "UA": Se trata de una aplicación sobre un equipo de usuario que emite y recibe solicitudes SIP. Se materializa por un software instalado sobre un « User Equipment » o UE : una PC, un teléfono IP o una estación móvil UMTS. (En nuestro el softphone).
- Registrador (Registrar): Se trata de un servidor que acepta las solicitudes SIP REGISTER. SIP dispone de una función de registro de usuarios. El usuario indica por un mensaje REGISTER emitido al Registrador, la dirección donde es localizable (dirección IP). El "Registrador" actualiza entonces una base de dato de localización. El registrador es una función asociada a un Proxy Server o a un Redirect Server. Un mismo usuario puede registrarse sobre distintas UA’s (user agents) SIP, en este caso, la llamada le será entregada sobre el conjunto de estas UAs.
SIP ha sido extendido con el fin de soportar numerosos servicios tales como presencia, mensajería instantánea (similar al servicio SMS en las redes móviles), transferencia de llamada, conferencia, servicios complementarios de telefonía, etc.
SIP ha sido elegido por el 3GPP para la arquitectura "IP Multimedia Subsystem" o "IMS" como protocolo para el control de sesión y el control de servicio. Actualmente, SIP está reemplazando a los protocolos "ISUP", utilizado para el control de llamada en la Red Telefónica Conmutada, y "INAP", utilizado para el control de servicio en la arquitectura Red Inteligente.
Métodos SIP
El RFC 3261 define seis solicitudes / requerimientos o métodos SIP.
El método "INVITE" es usado con el fin de establecer una sesión entre UAs. INVITE corresponde al mensaje ISUP IAM o al mensaje Q.931 SET UP y contiene las informaciones sobre el que genera la llamada y el destinatario así como sobre el tipo de flujos que serán intercambiados (voz, video,...).
Cuando un UA emite un INVITE recibe una respuesta final a la invitación (ejemplo: 200 OK), el confirma la recepción de esta respuesta por medio de un método "ACK". Una respuesta del tipo "busy" o "answer" es considerada como final mientras una respuesta tipo "ringing" significa que el destinatario ha sido avisado (respuesta provisoria).
El método "BYE" permite la liberación de una sesión anteriormente establecida. Corresponde al mensaje RELEASE de los protocolos ISUP y Q.931. Un mensaje BYE puede ser emitido por el que genera la llamada o el que la recibe.
El método "REGISTER" es usado por un UA con el fin de indicar al Registrar la correspondencia entre su dirección SIP y su dirección de contacto (ejemplo: dirección IP).
El método "CANCEL" es utilizado para pedir el abandono de la llamada en curso pero no tiene ningún efecto sobre una llamada ya aceptada. De hecho, solo el método “BYE” puede terminar una llamada establecida.
El método "OPTIONS" es utilizado para interrogar las capacidades y el estado de un User Agent o de un servidor. La respuesta contiene sus capacidades, ejemplo: idioma soportado o el hecho de que el UA este indisponible.
Respuestas SIP
Después de haber recibido e interpretado un requerimiento SIP, el destinatario de este requerimiento devuelve una respuesta SIP. Existen seis clases de respuestas:
- Clase 1xx : Información, el requerimiento ha sido recibido y está en curso de tratamiento
- Clase 2xx: Éxito, el requerimiento ha sido recibido, entendido y aceptado.
- Clase 3xx: Reenrutamiento, la llamada requiere otros procesamientos antes de poder determinar si puede ser realizada.
- Clase 4xx: Error requerimiento cliente, el requerimiento no puede ser interpretado por el servidor. El requerimiento tiene que ser modificado antes de ser reenviado.
- Clase 5xx: Error servidor, el servidor fracasa en el procesamiento de un requerimiento aparentemente valido.
- Clase 6xx: Fracaso global, el requerimiento no puede ser procesado por ningún servidor.