.config/Typora/draftsRecover/2019-6-3 SIP 012041.md

   1 # Session Initiation Protocol
   2
   3 El protocolo de inicio de sesión se convirtió en un sistema muy aceptado a nivel global a pesar de los criticismo que obtuvo debido a la forma en que se manejan los paquetes de estos, pues son muy redundantes y crean fragmentario de paquetes.
   4
   5 Uno de los aspectos mas importantes en este protocolo es su identificador universal, este identificador universal tiene el siguiente formato:
   6
   7 ```bash
   8 [SIP o SIPS]:usuario:contrasena@[hostname,FQDN o IP]:puerto;parametros?cabeceras
   9 ```
  10
  11 Estos URI tienen un formato fácilmente reconocible ya que funcionan muy parecido a los identificados que encontramos como son las URL o comandos de SSH, asi como estos también es posible omitir el usuario si este no es necesario.
  12
  13 ## 1. *SIP* Architecture
  14
  15 Los elementos que se utilizan en **SIP** pueden llegar a ser verdaderamente complejos, estos elementos pueden resumirse en un conjunto de ideas que, a pesar de no estar definidas completamente por el protocolo son necesarias para el correcto funcionamiento de este:
  16
  17 - User Agent (_UA_): Este es simplemente el equipo de comunicacion que utilizara el cliente, puede ser desde un telefono celular hasta una aplicacion en una computadora (o por que no, un telefono IP). Estos agentes tienen la peculiaridad de que a pesa que casi siempre vienen integrados dentro de una sola solucion suelen estar compuestos de dos partes logicas:
  18   - UAC, esta es la parte llamada cliente y es la parte que se encarga de hacer las peticiones.
  19   - UAS, esta es la parte servidor y es la encargada de poder responder a las peticiones que se le envian.
  20 - *UA* proxy: Este es un software encargado de separar logicamente areas en una red de ISP, es decir, separa los servicios de descubrimiento y se encargan de encontrar (En caso de ser Autoritativos) la direccion hacia la que un UA deberia enviar su peticion para llamar a algun otro UA en especifico.
  21 - Servicion de ubicacion: Es la base de datos en la cual el proxy puede encontrar el host especifico o UAS al que se quiera llamar en ese dominio. Esta informacion proviene de las registraciones que hacen los UAC en los registrar.
  22 - Registrar: es un servidor o proceso en que un UAC puede publicar su ubicacion. Es importante recordar que multiples usuarios se pueden registrar en la misma direccion fisica sin ningun problema.
  23 - Servidor de redireccion: Este es un proxy que tambien contiene informacion proveniente de los servicios de ubicacion.
  24
  25 Cuando se inicia una comunicación mediante SIP hay mensajes que van fuera de "dialogo", estos mensajes son mensajes como el INVITE o el OK, pero luego de que se inicia una conversación entonces los mensajes pasan a ser mas ligeros, pues ya se conoce quien es el que envía y su ID, esto hace la comunicación un poco mas eficiente. Existe una gran cantidad de mensajes con usos muy diferentes y entre ellos se encuentra por ejemplo el mensaje primero en enviarse, este es un INVITE que es para iniciar comunicación, este tiene la siguiente estructura:
  26
  27 ```json
  28 INVITE [URI destino][SIP x.x]
  29 Via: [SIP x.x][protocolo y direccion]
  30 Max-Forwards: num
  31 To: [Nombre destino] [URI destino]
  32 From: [Nombre procedencia][URI procedencia];tag=num
  33 Call-ID: [ID de llamada]
  34 CSeq: 314159 INVITE
  35 Contact: [URI de procedencia]
  36 Content-Type: application/sdp
  37 Content-Length: [sizeof del mensaje]
  38 [CRLF (linea en blanco)]
  39 ```
  40
  41 Es importante ver como ejemplo la forma en que normalmente ocurriría una llamada a un usuario que recién se registra y es que:
  42
  43 ![Registro y llamada](/home/josuer08/Downloads/Untitled Diagram.png)
  44
  45 ##  2. *SIP* Messages
  46
  47 Como ya pudimos ver con el ejemplo anterior los mensajes en SIP son altamente legibles, pues son como párrafos en los que cada linea es una cabecera que  inicia con un identificador.
  48
  49 A pesar de que los RFC identifican múltiples cosas que deben estar presentes siempre incluyen un formato general que deben seguir estos mensajes:
  50
  51 | Parte                         | Definicion                                                   |
  52 | ----------------------------- | ------------------------------------------------------------ |
  53 | Linea inicial                 | Este indica el método, la versión del protocolo y demás      |
  54 | Cabeceras                     | Todos estos dependen del mensaje a enviar y tienen un tipo y un valor. Siempre en lineas separadas cada cabecera |
  55 | Linea en blanco               | Este es un espaciador requerido por el estandar              |
  56 | Cuerpo del mensaje (opcional) | Las cabeceras de tipo de contenido y tamaño de contenido definen lo que habrá dentro de este campo |
  57
  58 Cada proxy que maneja un request agrega un header de tipo vía ~~la dirección donde se espera recibir una respuesta~~ de esta manera cuando el teléfono llamado envía una respuesta esta cadena de vias funciona como un sistema de enrutamiento para devolver el paquete por el mismo camino por el que ha llegado, eliminando asi la necesidad de una búsqueda DNS.
  59
  60 Este método es empleado por la clase mas simple de proxy, que solo tienen ese cometido, pero los autoritarios funcionan muy parecido a los routers, pues al recibir llamadas externas busca en su LS a quien debe enviar el mensaje.~~también existen proxies de "tenedor" que envían por múltiples caminos sus mensajes~~
  61
  62 ## 3. *SIP* Header Fields and Behaviors
  63
  64 En definitiva los UA pueden tener una enorme cantidad de capacidades diferentes que dependen de su software y hardware, esto se refleja en forma de colecciones y sets, siendo las colecciones la configuración actual y los set el total de las habilidades en un UA especifico, pudiendo cubrir esto desde los codecs de audio o vídeo hasta la capacidad de intercambiar o no texto plano. Es completamente importante saber que dos UA solo pueden operar entre ellos si hay partes de su set que se solapen, es decir, si estos tienen capacidades en común.
  65
  66 Hay montones de headers que tienen funciones especificas en dependencias de las capacidades de cada UA, esta lista es increíblemente extensa y algunos de estos ya han sido listados aca ariba como el VIA, FROM,TO,CONTENT-TYPE,CONTENT_LENGHT y otros muy comunes pueden ser por ejemplo el CSeq ~~un numero secuencial que va aumentando con el intercambio de mensajes~~ o incluso el Accept ~~Que se encarga de decir los formatos aceptados por un UA especifico.~~