{"id":6358,"date":"2016-08-10T15:03:26","date_gmt":"2016-08-10T20:03:26","guid":{"rendered":"http:\/\/www.servervoip.com\/blog\/?p=6358"},"modified":"2019-06-11T08:19:44","modified_gmt":"2019-06-11T13:19:44","slug":"sipsession-initiation-protocol","status":"publish","type":"post","link":"http:\/\/www.servervoip.com\/blog\/sipsession-initiation-protocol\/","title":{"rendered":"SIP(Session Initiation Protocol)"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n
\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n
\n
<\/div>\n <\/div>\n <\/div>\n<\/div>\n
\n <\/span>\n <\/div>\n<\/div>\n

Session Initiation Protocol<\/strong><\/p>\n

Session Initiation Protocol (SIP o Protocolo de Inicio de Sesiones) es un protocolo desarrollado por el grupo de trabajo MMUSIC del IETF con la intenci\u00f3n de ser el est\u00e1ndar para la iniciaci\u00f3n, modificaci\u00f3n y finalizaci\u00f3n de sesiones interactivas de usuario donde intervienen elementos multimedia como el video, voz, mensajer\u00eda instant\u00e1nea, juegos en l\u00ednea y realidad virtual.<\/p>\n

La sintaxis de sus operaciones se asemeja a las de HTTP y SMTP, los protocolos utilizados en los servicios de p\u00e1ginas Web y de distribuci\u00f3n de e-mails respectivamente. Esta similitud es natural ya que SIP fue dise\u00f1ado para que la telefon\u00eda se vuelva un servicio m\u00e1s en Internet.<\/p>\n

En noviembre del a\u00f1o 2000, SIP fue aceptado como el protocolo de se\u00f1alizaci\u00f3n de 3GPP y elemento permanente de la arquitectura IMS (IP Multimedia Subsystem). SIP es uno de los protocolos de se\u00f1alizaci\u00f3n para voz sobre IP, otros, por ejemplo, son H.323 e IAX2.<\/p>\n

[rev_slider captions]
\n[rev_slider ServerVoip]
\n <\/p>\n

\n

Funcionamiento del protocolo<\/strong><\/p>\n

El protocolo SIP permite el establecimiento de sesiones multimedia entre dos o m\u00e1s usuarios. Para hacerlo se vale del intercambio de mensajes entre las partes que quieren comunicarse.<\/p>\n

Agentes de usuario<\/strong>
\nLos usuarios, que pueden ser seres humanos o aplicaciones de software,nota 1 utilizan para establecer sesiones lo que el protocolo SIP denomina \u00abAgentes de usuario\u00bb. Estos no son m\u00e1s que los puntos extremos del protocolo, es decir son los que emiten y consumen los mensajes del protocolo SIP. Un videotel\u00e9fono, un tel\u00e9fono, un cliente de software (softphone) y cualquier otro dispositivo similar es para el protocolo SIP un agente de usuario. El protocolo SIP no se ocupa de la interfaz de estos dispositivos con el usuario final, s\u00f3lo se interesa por los mensajes que estos generan y c\u00f3mo se comportan al recibir determinados mensajes.
\nLos agentes de usuario se comportan como clientes (UAC: User Agent Clients) y como servidores (UAS: User Agent Servers). Son UAC cuando realizan una petici\u00f3n y son UAS cuando la reciben. Por esto los agentes de usuario deben implementar un UAC y un UAS.
\nAdem\u00e1s de los agentes de usuario existen otras entidades que intervienen en el protocolo, estos son los servidores de registro o registrar, los proxy y los redirectores. A continuaci\u00f3n se describe su finalidad.<\/p>\n

Servidores de registro o Registrar<\/strong><\/p>\n

El protocolo SIP permite establecer la ubicaci\u00f3n f\u00edsica de un usuario determinado, esto es, en qu\u00e9 punto de la red est\u00e1 conectado. Para ello se vale del mecanismo de registro. Este mecanismo funciona como sigue:
\nCada usuario tiene una direcci\u00f3n l\u00f3gica que es invariable respecto de la ubicaci\u00f3n f\u00edsica del usuario. Una direcci\u00f3n l\u00f3gica del protocolo SIP es de la formausuario@dominio es decir tiene la misma forma que una direcci\u00f3n de correo electr\u00f3nico. La direcci\u00f3n f\u00edsica (denominada \u00abdirecci\u00f3n de contacto\u00bb) es dependiente del lugar en donde el usuario est\u00e1 conectado (de su direcci\u00f3n IP). Cuando un usuario inicializa su terminal (por ejemplo conectando su tel\u00e9fono o abriendo su software de telefon\u00eda SIP) el agente de usuario SIP que reside en dicho terminal env\u00eda una petici\u00f3n con el m\u00e9todo REGISTER a un Servidor de Registro (Registro en ingl\u00e9s), informando a qu\u00e9 direcci\u00f3n f\u00edsica debe asociarse la direcci\u00f3n l\u00f3gica del usuario. El servidor de registro realiza entonces dicha asociaci\u00f3n (denominada binding). Esta asociaci\u00f3n tiene un per\u00edodo de vigencia y si no es renovada, caduca. Tambi\u00e9n puede terminarse mediante un desregistro. La forma en que dicha asociaci\u00f3n es almacenada en la red no es determinada por el protocolo SIP, pero es vital que los elementos de la red SIP accedan a dicha informaci\u00f3n.<\/p>\n

Servidores proxy y de redirecci\u00f3n<\/strong><\/p>\n

Para encaminar un mensaje entre un agente de usuario cliente y un agente de usuario servidor normalmente se recurre a los servidores.3 Estos servidores pueden actuar de dos maneras:
\n1.\tComo Proxy, encaminando el mensaje hacia destino,
\n2.\tComo Redirector (Redirect) generando una respuesta que indica al originante la direcci\u00f3n del destino o de otro servidor que lo acerque al destino.
\nLa principal diferencia es que el servidor proxy queda formando parte del camino entre el UAC y el (o los) UAS, mientras que el servidor de redirecci\u00f3n una vez que indica al UAC c\u00f3mo encaminar el mensaje ya no interviene m\u00e1s.
\nUn mismo servidor puede actuar como Redirector o como Proxy dependiendo de la situaci\u00f3n.<\/p>\n

Servidor de localizaci\u00f3n<\/strong><\/p>\n

Un servidor de localizaci\u00f3n, simplemente da informaci\u00f3n acerca de donde puede estar el cliente al que se quiere llamar para as\u00ed poder localizarlo.<\/p>\n

Casos t\u00edpicos de servidores<\/strong><\/p>\n

Un conjunto de usuarios que pertenecen a una compa\u00f1\u00eda o proveedor de servicios de comunicaciones, conforman un dominio. Este dominio, que se indica en una direcci\u00f3n SIP despu\u00e9s del car\u00e1cter \u00ab@\u00bb es normalmente atendido por un servidor (o m\u00e1s de uno). Este servidor recibe las peticiones hacia sus usuarios. Este servidor ser\u00e1 el encargado de determinar la direcci\u00f3n f\u00edsica del usuario llamado. Un servidor que recibe las peticiones destinadas a un dominio espec\u00edfico es denominado servidor entrante (Inbound Server).
\nEs habitual tambi\u00e9n, que exista un servidor que reciba las peticiones originadas por los usuarios de un dominio hacia otros dominios. Este recibe el nombre de Servidor Saliente (Outbound Server).
\nUn agente de usuario normalmente encamina todos sus pedidos hacia un servidor de su propio dominio. Es este quien determina (por sus propios medios o vali\u00e9ndose de otros servidores) las ubicaciones de los usuarios que son llamados por el agente de usuario en cuesti\u00f3n.<\/p>\n

Formato de los mensajes<\/strong><\/p>\n

Los mensajes que se intercambian en el protocolo SIP pueden ser peticiones o respuestas.
\nLas peticiones tienen una l\u00ednea de petici\u00f3n, una serie de encabezados y un cuerpo.
\nLas respuestas tienen una l\u00ednea de respuesta, una serie de encabezados y un cuerpo.
\nEn la l\u00ednea de petici\u00f3n se indica el prop\u00f3sito de la petici\u00f3n y el destinatario de la petici\u00f3n.
\nLas peticiones tienen distintas funciones. El prop\u00f3sito de una petici\u00f3n est\u00e1 determinado por lo que se denomina el M\u00e9todo (Method) de dicha petici\u00f3n, que no es m\u00e1s que un identificador del prop\u00f3sito de la petici\u00f3n. En la RFC 3261 se definen los m\u00e9todos b\u00e1sicos del protocolo. Existen otros m\u00e9todos definidos en extensiones al protocolo SIP.
\nEn la l\u00ednea de respuesta se indica el c\u00f3digo de estado de la respuesta, que es un n\u00famero que indica el resultado del procesamiento de la petici\u00f3n.
\nLos encabezados de peticiones y respuestas se utilizan para diversas funciones del protocolo relacionadas con el encaminamiento de los mensajes, autenticaci\u00f3n de los usuarios, entre otras. La extensibilidad del protocolo permite crear nuevos encabezados para los mensajes agregando de esta manera funcionalidad.
\nEl cuerpo de los mensajes es opcional y se utiliza entre otras cosas para transportar las descripciones de las sesiones que se quieren establecer, utilizando la sintaxis del protocolo SDP.<\/p>\n

Flujo de establecimiento de una sesi\u00f3n<\/strong><\/p>\n

El flujo habitual del establecimiento de una sesi\u00f3n mediante el protocolo SIP es el siguiente (en este ejemplo todos los servidores act\u00faan como proxy):
\nUn usuario ingresa la direcci\u00f3n l\u00f3gica de la persona con la que quiere comunicarse, puede indicar al terminal tambi\u00e9n la caracter\u00edstica de la sesi\u00f3n que quiere establecer (voz, voz y video, etc.), o estas pueden estar impl\u00edcitas por el tipo de terminal del que se trate. El agente de usuario SIP que reside en el terminal, actuando como UAC env\u00eda la petici\u00f3n (en este caso con el m\u00e9todo INVITE) al servidor que tiene configurado. Este servidor se vale del sistema DNS para determinar la direcci\u00f3n del servidor SIP del dominio del destinatario. <\/p>\n

El dominio lo conoce pues es parte de la direcci\u00f3n l\u00f3gica del destinatario. Una vez obtenida la direcci\u00f3n del servidor del dominio destino, encamina hacia all\u00ed la petici\u00f3n. El servidor del dominio destino establece que la petici\u00f3n es para un usuario de su dominio y entonces se vale de la informaci\u00f3n de registro de dicho usuario para establecer su ubicaci\u00f3n f\u00edsica. <\/p>\n

Si la encuentra, entonces encamina la petici\u00f3n hacia dicha direcci\u00f3n. El agente de usuario destino si se encuentra desocupado comenzar\u00e1 a alertar al usuario destino y env\u00eda una respuesta hacia el usuario origen con un c\u00f3digo de estado que indica esta situaci\u00f3n (180 en este caso). La respuesta sigue el camino inverso hacia el usuario origen. <\/p>\n

Cuando el usuario destino finalmente acepta la invitaci\u00f3n, se genera una respuesta con un c\u00f3digo de estado (el 200) que indica que la petici\u00f3n fue aceptada. La recepci\u00f3n de la respuesta final es confirmada por el UAC origen mediante una petici\u00f3n con el m\u00e9todo ACK (de Acknowledgement), esta petici\u00f3n no genera respuestas y completa la transacci\u00f3n de establecimiento de la sesi\u00f3n.<\/p>\n

Normalmente la petici\u00f3n con el m\u00e9todo INVITE lleva un cuerpo donde viaja una descripci\u00f3n de la sesi\u00f3n que quiere establecer, esta descripci\u00f3n es realizada con el protocolo SDP. En ella se indica el tipo de contenido a intercambiar (voz, video, etc.) y sus caracter\u00edsticas (c\u00f3decs, direcciones, puertos donde se espera recibirlos, velocidades de transmisi\u00f3n, etc.). Esto se conoce como \u00aboferta de sesi\u00f3n SDP\u00bb. La respuesta a esta oferta viaja, en este caso, en el cuerpo de la respuesta defnitiva a la petici\u00f3n con el m\u00e9todo INVITE. La misma contiene la descripci\u00f3n de la sesi\u00f3n desde el punto de vista del destinatario. Si las descripciones fueran incompatibles, la sesi\u00f3n debe terminarse (mediante una petici\u00f3n con el m\u00e9todo BYE).<\/p>\n

Al terminar la sesi\u00f3n, que lo puede hacer cualquiera de las partes, el agente de usuario de la parte que termin\u00f3 la sesi\u00f3n, actuando como UAC, env\u00eda hacia la otra una petici\u00f3n con el m\u00e9todo BYE. Cuando lo recibe el UAS genera la respuesta con el c\u00f3digo de estado correspondiente.
\nSi bien se ha descrito el caso de una sesi\u00f3n bipartita, el protocolo permite el establecimiento de sesiones multipartitas. Tambi\u00e9n permite que un usuario est\u00e9 registrado en diferentes ubicaciones pudiendo realizar la b\u00fasqueda en paralelo o secuencial entre todas ellas.<\/p>\n

Tomado de: https:\/\/es.wikipedia.org\/wiki\/Session_Initiation_Protocol<\/p>\n

Emprendiendo en la Telefon\u00eda por Internet<\/h2>\n

\"empresa-de-telefonia-voip\"<\/a>
\n