El protocolo SIP (Session Initiation Protocol) fue desarrollado por el grupo MMUSIC (Multimedia

Session Control) del IETF, definiendo una arquitectura de sealizacin y control para VoIP. Inicialmente fue
publicado en febrero del 1996 en la RFC 2543, ahora obsoleta con la publicacin de la nueva versin RFC
3261 que se public en junio del 2002.
El propsito de SIP es la comunicacin entre dispositivos multimedia. SIP hace posible esta
comunicacin 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 negociacin de las capacidades de los
participantes, tipo de codificacin, etc.)
SIP fue diseado de acuerdo al modelo de Internet. Es un protocolo de sealizacin extremo a extremo que
implica que toda la lgica es almacenada en los dispositivos finales (salvo el rutado de los mensajes SIP). El
estado de la conexin es tambin almacenado en los dispositivos finales. El precio a pagar por esta
capacidad de distribucin y su gran escalabilidad es una sobrecarga en la cabecera de los
mensajes producto de tener que mandar toda la informacin entre los dispositivos finales.
SIP es un protocolo de sealizacin a nivel de aplicacin para establecimiento y gestin de sesiones
con mltiples participantes. Se basa en mensajes de peticin y respuesta y reutiliza muchos conceptos de
estndares anteriores como HTTP y SMTP.

SIP soporta funcionalidades para el establecimiento y finalizacin de las sesiones multimedia:

localizacin, disponibilidad, utilizacin de recursos, y caractersticas de negociacin.
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 lgica que genera peticiones SIP y recibe respuestas a esas peticiones. Un
UAS es una entidad lgica que genera respuestas a las peticiones SIP.
Ambos se encuentran en todos los agentes de usuario, as permiten la comunicacin 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 acta como cliente y servidor con el propsito
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 ms prximas 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 divisin de una peticin en varias (forking), con la finalidad de la localizacin 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 reenvan mensajes.

- Registrar Server: es un servidor que acepta peticiones de registro de los usuarios y guarda la informacin
de estas peticiones para suministrar un servicio de localizacin y traduccin de direcciones en el dominio que
controla.
- Redirect Server: es un servidor que genera respuestas de redireccin a las peticiones que recibe. Este
servidor reencamina las peticiones hacia el prximo servidor.

La divisin de estos servidores es conceptual, cualquiera de ellos puede estar fsicamente una nica mquina,
la divisin de stos puede ser por motivos de escalabilidad y rendimiento.

SIP es un protocolo textual que usa una semntica semejante a la del protocolo HTTP. Los UAC realizan las
peticiones y los UASretornan respuestas a las peticiones de los clientes. SIP define la comunicacin a
travs de dos tipos de mensajes. Las solicitudes (mtodos) y las respuestas (cdigos de
estado) emplean el formato de mensaje genrico establecido en el RFC 2822 , que consiste en una lnea
inicial seguida de un o ms campos de cabecera (headers), una lnea vaca que indica el final de las
cabeceras, y por ltimo, el cuerpo del mensaje que es opcional.
- Mtodos SIP
Las peticiones SIP son caracterizadas por la lnea inicial del mensaje, llamada Request-Line, que contiene el
nombre del mtodo, el identificador del destinatario de la peticin (Request-URI) y la versin del protocolo SIP.
Existen seis mtodos bsicos SIP (definidos en RFC 254) que describen las peticiones de los clientes:
- INVITE: Permite invitar un usuario o servicio para participar en una sesin o para modificar parmetros en
una sesin ya existente.
- ACK: Confirma el establecimiento de una sesin.
- OPTION: Solicita informacin sobre las capacidades de un servidor.
- BYE: Indica la terminacin de una sesin.
- CANCEL: Cancela una peticin pendiente.
- REGISTER: Registrar al User Agent.
Sin embargo, existen otros mtodos adicionales que pueden ser utilizados, publicados en otros RFCs como
los mtodos INFO, SUBSCRIBER,etc.
A continuacin 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 (Cdigos de estado) SIP.
Despus de la recepcin e interpretacin del mensaje de solicitud SIP, el receptor del mismo responde con un
mensaje. Este mensaje, es similar al anterior, difiriendo en la lnea inicial, llamada Status-Line, que contiene la
versin de SIP, el cdigo de la respuesta (StatusCode) y una pequea descripcin (Reason-Phrase). El
cdigo de la respuesta est compuesto por tres dgitos que permiten
clasificar los diferentes tipos existentes. El primer dgito define la clase de la respuesta.
Codigo Clases
1xx - Mensajes provisionales.
2xx - Respuestas de xito.
3xx - Respuestas de redireccin.
4xx - Respuestas de fallo de mtodo.
5xx - Respuestas de fallos de servidor.
6xx - Respuestas de fallos globales.

A Continuacin, se incluye un ejemplo de un cdigo 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:1
92.168.0.101",
response="f69463b8d3efdb87c388efa9be1a1e63"
Una de las funciones de los servidores SIP es la localizacin de los usuarios y resolucin de nombres.
Normalmente, el agente de usuario no conoce la direccin 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 mquina.
usuario@direccin_ip, donde direccin_ip es la direccin IP del dispositivo.
nmero_telfono@gateway, donde el gateway permite acceder al nmero de telfono a travs de la red
telefnica pblica.
La solucin de identificacin de SIP, tambin 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 direccin IP, puerta y protocolo de transporte utilizado, o por los servidores para retornar una
respuesta al cliente en caso de que la peticin 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 diseada para anunciar informacin necesaria para los participantes y para
aplicaciones de multicast MBONE (Multicast Backbone). Actualmente, su uso est extendido para el anuncio y
la negociacin de las capacidades de una sesin multimedia en Internet.
Puesto que SDP es un protocolo de descripcin, los mensajes SDP se pueden transportar mediante distintos
protocolos con SIP, SAP, RTSP, correo electrnico con aplicaciones MIME o protocolos como HTTP. Como el
SIP, el SDP utiliza la codificacin del texto. Un mensaje del SDP se compone de una serie de lneas,
denominados campos, dnde los nombres son abreviados por una sola letra, y est en una orden requerida
para simplificar el anlisis. El SDP no fue diseado para ser fcilmente 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.

A continuacin se analizar detalladamente una llamada. En una llamada SIP hay varias transacciones
SIP. Una transaccin 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 transaccin esta el parmetro CSeq.

Usuario
A

Proxy SIP

Usuario B

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 envan una peticin
REGISTER, donde los campos from y to corresponden al usuario registrado. El servidor Proxy, que acta
como Register, consulta si el usuario puede ser autenticado y enva un mensaje de OK en caso positivo.
La siguiente transaccin corresponde a un establecimiento de sesin. Esta sesin consiste en una
peticin INVITE del usuario al proxy. Inmediatamente, el proxy enva un TRYING 100 para parar las
retransmisiones y reenva la peticin al usuario B. El usuario B enva un Ringing 180 cuando el telfono
empieza a sonar y tambin 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
parmetros (puertos, direcciones, codecs, etc.) establecidos en la negociacin mediante el protocolo SDP.
La ltima transaccin corresponde a una finalizacin de sesin. Esta finalizacin se lleva a cabo con
una nica peticin 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.

SIP (Session Initial Protocol): Protocolo creado por el IETF en 1999 para VoIP, control de
llamadas multimedia e implementacin de servicios telefnicos avanzados. Es bsicamente un
protocolo para la iniciacin, modificacin y terminacin de sesiones de comunicacin
multimedia entre usuarios.

El protocolo SIP (Session Initation Protocol), es un protocolo de iniciacin de sesin creado por
el grupo IETF para VoIP, para texto y sesiones multimedia,
El protocolo SIP es principalmente un protocolo de sealizacin de capa de aplicacin para la
iniciacin, modificacin y terminacin de sesiones de comunicacin multimedia entre usuarios.
Estas sesiones incluyen llamadas telefnicas por Internet, distribucin de datos multimedia y
conferencias multimedia.
Las capacidades de sealizacin que ofrece el protocolo SIP son:
Localizacin de los usuarios, lo que conlleva una movilidad
Gestin del conjunto de participantes: disponibilidad del usuario y determinacin de la voluntad
del receptor para participar en las comunicaciones.
Negociacin de la capacidad del usuario: Determinacin del medio y de sus parmetros
Gestin de la sesin: Descripcin de los componentes y de las caractersticas de las sesiones as
como la transferencia, modificacin y terminacin de la sesin desde el propio usuario.

2. Caractersticas Principales
Las principales caractersticas que hacen que SIP se un protocolo en alza son:
Simplicidad: Est basado en texto para una implementacin y depuracin simples, utiliza
primitivas (mtodos y respuestas basadas en el modelo HTTP) para el establecimiento de
sesiones. No se definen servicios o funciones.
Escalabilidad y flexibilidad: Tiene funcionalidades Proxy, de redireccionamiento,
localizacin/registro que pueden residir en un nico servidor o en varios distribuidos.
Simplicidad de las URIs de usuario basadas en DNS.
No es necesario un control centralizado: Tiene un funcionamiento Peer to Peer de forma nativa.

58

 SIP ofrece todas las potencialidades y las caractersticas comunes de la telefona de Internet como:
llamada o transferencia de medios, conferencia de llamada y llamada en espera.
SIP funciona por encima de varios diversos protocolos del transporte.
El protocolo SIP posee una sintaxis similar a HTTP o SMTP, mediante el uso de URIs. Los
mtodos bsicos que implementa son: INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS.
Los mensajes se agrupan en transacciones y llamadas. Generalmente, el cuerpo de los mensajes
contiene descripciones de sesiones multimedia y los cdigos de respuesta similares a los de HTTP.
La localizacin de usuarios est basada en el DNS y posee cabeceras como mtodo de ampliacin.
Los mensajes consisten de encabezados y un cuerpo de mensaje. Los cuerpos de mensaje de SIP
para las llamadas telefnicas se definen en SDP- protocolo de descripcin de la sesin.
El SIP es un protocolo basado en texto que utiliza la codificacin Utf-8
Las aplicaciones SIP usan el puerto 5060 para ambos UDP y TCP. SIP puede utilizar otros
transportes
Puesto que SIP es un protocolo flexible, es posible agregar ms caractersticas y mantener la
interoperabilidad hacia atrs

3. Arquitectura y Elementos
La arquitectura del protocolo SIP est integrada en la infraestructura web y sigue bsicamente
un modelo cliente-servidor, reutilizando conceptos de otros servicios (web, correo, dns).Los
principales elementos que constituyen la arquitectura de este protocolo son:
Agentes de usuario:
Agentes de usuario clientes (UAC).
Agentes de usuario servidores (UAS).
Servidores:
Proxys, de registro y de redireccin.
Un Proxy Servidor es una aplicacin intermedia que acta tanto como servidor y cliente,
generando mensajes SIP a nombre del cliente que gener el mensaje original.
Los mensajes pueden ser respondidos o encaminados a otros servidores donde se encuentra la
localizacin actual del usuario
-Interpreta, re-escribe o traduce los mensajes antes de encaminarlos.

59

-Autentifica y autoriza a los usuarios para los servicios

-Implementa polticas de encaminamiento.
-Hay dos tipos de Proxy Server:
Outbound Proxy: Permite simplificar la administracin de los usuarios de un dominio, aplica
polticas, tarifica, etc.
Inbound Proxy: Permite independizar al usuario del dispositivo que utiliza y de su localizacin.
Un mismo servidor puede funcionar como Proxy saliente o entrante de un dominio.
Las invitaciones de SIP son usadas para crear sesiones y llevan las descripciones de la sesin
que permiten que los participantes convengan en un sistema de tipos de medios
Un Servidor de redireccin es un agente de usuario servidor (UAS) que genera respuestas a las
peticiones que recibe, ordenando al cliente entrar en contacto con un sistema alterno de URIs. En
algunas arquitecturas puede ser deseable reducir la carga de los servidores Proxy que son
responsables de las peticiones de encaminamiento, y mejorar la robustez del recorrido de los
mensajes de sealizacin, mediante redirecciones.
La redireccin permite que los servidores enven la informacin de encaminamiento para una
peticin como respuesta al cliente, de tal modo quitndose del camino de los subsiguientes
mensajes para una transaccin mientras que ayudan en la localizacin del blanco de la peticin.
Cuando el autor de la peticin recibe el cambio de direccin, enviar una nueva peticin basada en
la URI (s) que ha recibido. Propagando URIs desde el ncleo de la red hacia sus extremos, el
cambio de direccin permite obtener una escalabilidad considerable en la red.
Un servidor de registro es un servidor que acepta peticiones de tipo REGISTER y pone la
informacin que recibe de esas peticiones en el servicio de localizacin para el dominio que maneja
(IP + Puerto) ya que los usuarios pueden tener mltiples localizaciones. Normalmente es el mismo
servidor que el Proxy.
El protocolo SIP permite implementar dos tipos de movilidad diferentes:
La movilidad personal donde el usuario puede ser alcanzado en un dispositivo cualquiera,
registrndose en el servidor de registro.
La movilidad propia al protocolo IP (VPN).
El registro permite mantener las localizaciones actuales del usuario de manera dinmica. Se
basa en la localizacin actual. El servidor Proxy encaminar las llamadas al destino. SIP ofrece

60

la capacidad de descubrimiento. Si un usuario desea iniciar una sesin con otro usuario, el SIP
debe descubrir el host actual en el cual el usuario de destinacin es accesible. Este proceso de
descubrimiento es logrado por elementos de la red SIP tales como servidores proxy y servidores de
redireccin que son los responsables de recibir una peticin, determinar dnde enviarla basados en
el conocimiento de localizacin de usuarios, y despus enviarla all. Para hacer esto, los elementos
de la red SIP consultan un servicio abstracto conocido como servicio de localizacin, que
proporciona los mapeos de direccin para un dominio particular. stos mapeos de direcciones
mapean SIP URIs entrantes.
Las principales desventajas que conlleva el uso de este protocolo son:
Problemas de Red: La utilizacin de un canal PtP para el streaming de audio RTP plantea
numerosos problemas a nivel de red: NAT routers, firewall, etc.
Interoperabilidad con PSTN: El protocolo H.323 ofrece mayores ventajas.

The Session Initiation Protocol (SIP) is an application-layer signaling-control protocol

used to establish, maintain, and terminate multimedia sessions. Multimedia sessions
include Internet telephony, conferences, and other similar applications involving such
media as audio, video, and data.
You can use SIP invitations to establish sessions and carry session descriptions. SIP
supports unicast and multicast sessions as well as point-to-point and multipoint calls.
You can establish and terminate communications using the following five SIP facets:
user location, user capability, user availability, call setup, and call handling.
SIP, on which Request For Comments (RFC) 2543 is based, is a text-based protocol that
is part of the overall Internet Engineering Task Force (IETF) multimedia architecture.
The IETF also includes the Resource Reservation Protocol (RSVP; RFC 2205), Real-Time
Transport Protocol (RTP; RFC 1889), Real-Time Streaming Protocol (RTSP; RFC 2326),
Session Announcement Protocol (SAP; internet draft), and SDP (Session Description
Protocol; RFC 2327). SIP's functions are independent, however, so it does not depend
on any of these protocols. It is important to note that SIP can operate in conjunction
with other signaling protocols, such as H.323.
Internet Protocol (IP) telephony is still being developed and will require additional
signaling capabilities in the future. The extensibility of SIP enables such development of
incremental functionality. SIP message headers are versatile, and you can register
additional features with the Internet Assigned Numbers Authority (IANA). SIP message
flexibility also enables elements to construct advanced telephony services, including
mobility type services.
As of the writing of this chapter, the IETF has not yet ratified SIP, so this chapter
focuses on the basics of SIP and does not discuss extensibility or services. The following
issues are covered in this chapter:
SIP overviewComponents, addressing, and invitations
MessagesHeaders, requests, and responses
Basic operationProxy and redirect server operation

SIP Overview
This section describes the basic functionality and key elements of SIP. The two
components in a SIP system are user agents and network servers. Calling and called
parties are identified by SIP addresses; parties need to locate servers and users. SIP
transactions also are covered as part of this overview.

User Agents
User agents are client end-system applications that contain both a user-agent client
(UAC) and a user-agent server (UAS), otherwise known as client and server,
respectively.
ClientInitiates SIP requests and acts as the user's calling agent.
ServerReceives requests and returns responses on behalf of the user; acts as
the user-called agent.

Network Servers
Two types of SIP network servers exist: proxy servers and redirect servers. Functional
examples of these servers are provided in the section "Basic Operation of SIP," later in
this chapter.
Proxy serverActs on behalf of other clients and contains both client and server
functions. A proxy server interprets and can rewrite request headers before
passing them on to other servers. Rewriting the headers identifies the proxy as
the initiator of the request and ensures that replies follow the same path back to
the proxy instead of the client.

180

 Redirect serverAccepts SIP requests and sends a redirect response back to the
client containing the address of the next server. Redirect servers do not accept
calls, nor do they process or forward SIP requests.

Addressing
SIP addresses, also called SIP Universal Resource Locators (URLs), exist in the form of
users @ hosts. Similar to e-mail addresses, a SIP URL is identified by user@host. The
user portion of the address can be a user name or telephone number, and the host
portion can be a domain name or network address. You can identify a user's SIP URL by
his or her e-mail address. The following example depicts two possible SIP URLs:
sip:ciscopress@cisco.com
sip:4085262222@171.171.171.1

Locating a Server
A client can send a SIP request either directly, to a locally configured proxy server, or to
the IP address and port of the corresponding SIP URL. Sending a SIP request directly is
relatively easy, as the end-system application knows the proxy server. Sending a SIP
request in the second manner is somewhat more complicated, for the following
reasons:
The client must determine the IP address and port number of the server for which
the request is destined.
If the port number is not listed in the requested SIP URL, the default port is 5060.
If the protocol type is not listed in the request SIP URL, the client must first
attempt to connect using User Datagram Protocol (UDP) and then Transmission
Control Protocol (TCP).
The client queries the Domain Name System (DNS) server for the host IP address.
If it finds no address records, the client is unable to locate the server and cannot
continue with the request.

SIP Transactions
After addressing is resolved, the client sends one or more SIP requests and receives
one or more responses from the specified server. All the requests and responses
associated with this activity are considered part of a SIP transaction. For simplicity and
consistency, the header fields in all request messages match the header fields in all
response messages.
You can transmit SIP transactions in either UDP or TCP. In the case of TCP, you can carry
all request and response messages related to a single SIP transaction over the same
TCP connection. You also can carry separate SIP transactions between the two entities
over the same TCP connection. If you use UDP, the response is sent to the address
identified in the header field of the request.

Locating a User
The called party might move from one to several end systems over time. He or she
might move from the corporate local-area network (LAN) to a home office connected
through his or her Internet service provider (ISP), or to a public Internet connection
while attending a conference, for example. Therefore, for location services, SIP needs
to accommodate the flexibility and mobility of IP end systems. The locations of these
end systems might be registered with the SIP server or with other location servers

outside the scope of SIP. In the latter case, the SIP server stores the list of locations
based on the outside location server that is returning multiple host possibilities.
The action and result of locating a user depends on the type of SIP server being used. A
SIP redirect server simply returns the complete list of locations and enables the client
to locate the user directly. A SIP proxy server can attempt the addresses in parallel until
the call is successful.

181 Unsupported

Contact

Organization

CSeq

Priority

Warning

Content-Encoding

Authorization

Allow

Accept-Encoding

Content-Length

Contact

Proxy-Authenticate

Accept-Language

Content-Type

Hide

Retry-After

Call-ID

Max-Forwards

Server

Date

Proxy-Authorization

WWW-Authenticate

Encryption

Proxy-Require

Expires

Route

From

Require

Record-Route

Response-Key

Timestamp

Subject

To

User-Agent

Via