Protocolos de

Señalización
H.323 y SIP

© Dr. Ing. José Joskowicz 2013

Señalización
H.323

© Dr. Ing. José Joskowicz 2013

H.323

 Es un estándar “base” para las comunicaciones
de audio, video y datos a través de redes IP que
no proveen calidad de servicio garantizada
 La primera versión fue aprobada en 1996 por la
ITU.
 La versión 7 fue aprobada en diciembre de 2009
 Es parte de las recomendaciones H.32x (como
por ejemplo H.320 para ISDN y H.324 para la
PSTN)

© Dr. Ing. José Joskowicz 2013 3

Arquitectura de H.323

© Dr. Ing. José Joskowicz 2013 4

Componentes de H.323

 Terminales
 Gateways (“pasarelas”)
 Gatekeepers
 Multipoint Control Units (“Unidades de control
multipunto, para conferencias”)

© Dr. Ing. José Joskowicz 2013 5

José Joskowicz 2013 6 . y opcionalmente comunicaciones de video y datos. Terminales H.  Pueden ser equipos “stand alone” conectados directamente a la LAN. Ing. © Dr.323  Son los “telefonos multimedia IP”  Deben soportar comununicaciones de voz. o software de PC.

Terminal H.711.723. G.0 (Q.729 Video Codec RTP UDP Cámara H.245 IP Canal de Control señalización TCP H. Ing.728.931) Interfaces de Canal de RAS usuario H. G.263 RTCP Display Intrerfaz de datos Equipos de T.722.323 Audio Codec Micrófono G. G.120 datos Control Canal de control H.323 Alcance de H.0 © Dr. H.225. Parlante G. José Joskowicz 2013 7 .225.261.

225. Ing.245  Describe los mensajes y procedimientos para abrir y cerrar canales lógicos para audio. José Joskowicz 2013 8 .0)  Protocolo de control de conexiones (similar a ISDN)  RAS  Registration/Admission/Status: Protocolo de comunicacion con el Gatekeeper  RTP / RTCP  Real-Time Protocol / Real-Time Control Protocol : Protocolo que define los procedimientos para manejar datos de tiempo real © Dr. video y datos.931 (H. Estándares de Control  H. y para realizar el control de las comunicaciones  Q.

Gateways  Realiza funciones de interconexión entre sistemas H.323 y sistemas de otro tipo (por ejemplo redes ISDN o PSTN) © Dr. Ing. José Joskowicz 2013 9 .

Ing. José Joskowicz 2013 10 .323 © Dr.  Funciones de control:  Traducción de “direcciones”  Gerenciamiento del ancho de banda  Ruteo de llamadas H. Gatekeeper  Actúa como “punto central” de las llamadas de una determinada zona (como “PBX virtual”).

gateways. José Joskowicz 2013 11 . MCUs)  Control de Ancho de banda  Manejo del ancho de banda permitido para cada servicio y/o terminal © Dr. Funciones obligatorias de Gatekeepers  Traducción de direcciones  De números de teléfonos o nombres a direcciones de red  Control de Admisión  Autorización de uso a los diversos dispositivos (terminales. Ing.

Funciones opcionales de Gatekeepers  Autorización de llamadas  Control de llamadas (con fines administrativos - costos)  Control de la señalización  Otras funciones. José Joskowicz 2013 12 . de acuerdo a criterios de los fabricantes © Dr. Ing.

Ing.245 entre los terminales  MP: Multipoint Processors  Encargado de “mezclar” y procesar audio video y/o datos © Dr. Multipoint Control Units  Soporta conferencias entre 3 o más puntos  Consiste de:  MC: Multipoint Controller  Encargado de la señalización H. José Joskowicz 2013 13 .

donde el audio y video es enviado por cada terminal a todos los otros (utiliza MC y no MP)  Hibridas  Conjuga los modos anteriores © Dr. Tipos de conferencias  Centralizadas  UtilizaMCU para centralizar el control y contenido de la conferencia (dispone de MC y MP centralizado). La comunicación es siempre punto a punto  Descentralizadas  Utilizan la tecnología de “Multicast”. José Joskowicz 2013 14 . Ing.

José Joskowicz 2013 15 . Ing.323 © Dr.Esquema de un MCU en H.

José Joskowicz 2013 16 .H.323 en el modelo OSI © Dr. Ing.

Ing.Direct Call © Dr. José Joskowicz 2013 17 .

Ing.Direct Call © Dr. José Joskowicz 2013 18 .

Ing.Direct Call © Dr. José Joskowicz 2013 19 .

Ing. José Joskowicz 2013 20 .Direct Call © Dr.

Ing. José Joskowicz 2013 21 .Gatekeeper Routed © Dr.

Ing.Gatekeeper Routed © Dr. José Joskowicz 2013 22 .

José Joskowicz 2013 23 .Gatekeeper Routed © Dr. Ing.

Gatekeeper Routed © Dr. Ing. José Joskowicz 2013 24 .

José Joskowicz 2013 25 . Fast Connect  Con este procedimiento el terminal que origina una llamada pude proponer un conjunto de canales de medios para su inmediata apertura en el mensaje de establecimiento (setup) H. lo que permite encapsular mensajes de apertura de canales de medios H.225  Se utiliza el campo “fastStart”.245 (openLogicalChannel) © Dr. Ing.

Ing.Ejemplo de captura H.323 © Dr. José Joskowicz 2013 26 .

José Joskowicz 2013 . Ing.Señalización SIP © Dr.

era una red experimental montada sobre la Internet. Ing. futura o ya establecida. RFC 3261-3266 © Dr. como un componente del “Mbone” (Multicast Backbone)  El Mbone. Uno de sus componentes esenciales era un mecanismo para invitar a usuarios a escuchar una sesión multimedia. José Joskowicz 2013 28 . para la distribución de contenido multimedia. dando origen oficial al protocolo SIP (Session Initiaton Protocol)  SIP tiene sus orígenes a fines de 1996. SIP  En marzo de 1999 es aprobado el RFC 2543. Básicamente un “protocolo de inicio de sesión” (SIP).  En junio de 2002. por el grupo de estudio MMUSIC (Multiparty Multimedia Session Control ) del IETF. seminarios y conferencias de la IETF. incluyendo charlas. el RFC 2543 fue reemplazado por un conjunto de nuevas recomendaciones.

http://www. proxies  Reutilizar el código HTTP  Textual. sencillo de implementar y depurar © Dr.org  Reutilizar la tecnología de Internet:  URLs. “Filosofía” de SIP  Estándar de Internet  Promocionado por IETF . Ing. José Joskowicz 2013 29 . DNS.ietf.

 A diferencia de H. El destino recibe el “Request”. José Joskowicz 2013 30 . y lo contesta con el correspondiente “Response”. Mensajería SIP  La mensajería SIP está basada en el esquema “Request” – “Response” de HTTP. Ing. y por lo tanto fáciles de interpretar  Para iniciar una sesión se envía un mensaje de “Request” a una contraparte de destino. © Dr. todos los mensajes son de texto plano.323.

Ing.4 SIP/2.0 180 Ringing G.2.2.4 INVITE sip:nancy@192. José Joskowicz 2013 31 .2 To: sip:nancy@192.2.2.0 100 Trying Medios SDP: 180 Ringing SIP/2.0:5060 Finalización de la 200 OK llamada SIP/2.168.4 100 Tryinig SIP/2.0 200 OK © Dr.729 Flujo de datos RTP Video MPEG-1 BYE BYE sip:nancy@192.168.2.4 SIP/2. Ejemplo de una llamada SIP “peer to peer” sip:manuel@192.2.729sip:nancy@192.729 Establecimiento MPEG-I Video SIP/2.0 INVITE con SDP From: sip:manuel@192.0 200 OK de 200 OK con SDP la llamada Medios SDP: ACK ACK G.2.168.4 SIP/2.0:5060 MPEG-I Video RTP Audio G.168.168.168.2 sip:nancy@192.168.

Usually sent to a Proxy Server to cancel searches REGISTER Used by client to register a particular address with the SIP server SUBSCRIBE Used to request status or presence updates from the presence server NOTIFY Used to deliver information to the requestor or presence “watcher. Ing.0 Método Descripción INVITE A session is being requested to be setup using a specified media ACK Message from client to indicate that a successful response to an INVITE has been received OPTIONS A Query to a server about its capabilities BYE A call is being released by either party CANCEL Cancels any pending requests. SIP Requests  Los mensajes de “Request” tiene el formato:  <Método> <URL> <SIP-Version>  Ejemplo: INVITE sip:nancy@fing.” © Dr.com SIP/2. José Joskowicz 2013 32 .

SIP Requests Método Descripción REFER Used to referring the remote user agent to a web page or another URI MESSAGE Used to transport instant messages (IM) using SIP UPDATE Used to modify the state of a session without changing the state of the dialog INFO Used by a user agent to send call signaling information to another user agent with which it has an established media session PRACK Provisional ACK. Ing. Used to acknowledge receipt of reliably transported provisional responses (1xx) © Dr. José Joskowicz 2013 33 .

Ing. 4xx Client Error – Request contains bad syntax or cannot be fulfilled at this server. SIP Responses  Las respuestsa SIP son del estilo HTTP:  <SIP-Version> < Status-Code> <Reason>  Ejemplo: SIP/2. © Dr. 6xx Global Failure – Request is invalid at any server.0 404 Not Found Respuesta Descripción 1xx Informational – Request received. (100 Trying 180 Ringing 181 Call is Being Forwarded …) 2xx Success – Action was successfully received. continuing to process request. understood and accepted. José Joskowicz 2013 34 . 5xx Server Error – Server failed to fulfill an apparently valid request. (200 OK ) 3xx Redirection – Further action needs to be taken in order to complete the request.

103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 © Dr.branch=z9hG4bK776asdhds Max-Forwards: 70 To: Pepe <sip:pepe@fing.tag=1928301774 Call-ID: a84b4c76e66710@pc33.montevideo.com>. Ejemplo: INVITE INVITE sip:pepe@fing.montevideo.com> Content-Type: application/sdp Content-Length: 142 v=0 o=AGarcia 2890844526 2890842807 IN IP4 126.com> From: Alicia <sip:alicia@abc.0/UDP pc33.16.101. José Joskowicz 2013 35 .64.com CSeq: 314159 INVITE Cabezal Contact: <sip:alicia@pc33.0 Via:SIP/2.montevideo.4 s=Phone Call c=IN IP4 100.com:5060. Ing.com SIP/2.102.

com> Content-Type: application/sdp Content-Length: 142 v=0 o=AGarcia 2890844526 2890842807 IN IP4 126.com SIP/2.com:5060.4 s=Phone Call Cuerpo SDP c=IN IP4 100.0/UDP pc33.16.101.montevideo.com CSeq: 314159 INVITE Contact: <sip:alicia@pc33.com>.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 © Dr.montevideo. Ejemplo: INVITE INVITE sip:pepe@fing. José Joskowicz 2013 36 .branch=z9hG4bK776asdhds Max-Forwards: 70 To: Pepe <sip:pepe@fing.com> From: Alicia <sip:alicia@abc.64.montevideo.tag=1928301774 Call-ID: a84b4c76e66710@pc33.102.0 Via:SIP/2. Ing.

0/UDP pc33. Cabezal  Tienen un formato del tipo Campo: Valor  Via: SIP/<version>/<transporte> hostname:port.montevideo.com:5060.branch=<transaction numer> Via:SIP/2. Ing.branch=z9hG4bK776asdhds  Max-Forwards: <numero>  To: <dirección SIP>  From: <dirección SIP> © Dr. José Joskowicz 2013 37 .

Perez <pepe@fing.1 © Dr. Cabezal Direcciones SIP:  Utiliza el formato de URLs de Internet  Uniform Resource Locators  El formato general es nombre@dominio  Ejemplos:  sip:pepe@fing.uy  sip:Jose . Ing.1.64.uy.uy>  sip:+598-2-7110978@fing.com.com. José Joskowicz 2013 38 .com.M.user=phone  sip:guest@10.

Cabezal  Call-ID: <numero>@<Host>  CSeq: <numero> <metodo>  Contact: <dirección SIP>  Content-Type: <tipo de contenido y formato del cuerpo>  Content-Length: <largo del cuerpo> © Dr. Ing. José Joskowicz 2013 39 .

y se diferencian mayúsculas de minúsculas  El formato de <valor> depende del <tipo> al que corresponda © Dr. Ing. José Joskowicz 2013 40 . Cuerpo SDP  El formato de cada renglón de SDP es <tipo>=<valor>  <tipo> es siempre un único carácter.

Cuerpo SDP  Versión del protocolo (v)  Origen (o) o=<username> <session id> <version> <network type> <address type> <address>  Nombre de la sesión (s)  Datos de la conexión (c) c=<network type> <address type> <connection address>  Medios (m) m=<media> <port> <transport> <fmt list> © Dr. Ing. José Joskowicz 2013 41 .

SIP Clients and Servers  SIP utiliza una arquitectura cliente / servidor  Elementos:  SIP User Agents (Teléfonos SIP)  SIP Servers  SIP Gateways:  Hacia la PSTN para interconectar el “mundo” SIP al “mundo” TDM  Hacia H. Ing.323 para realizar interoperabilidad en el “mundo” IP  Clientes – Origina mensajes  Servidores – Responden a los mensajes o los redireccionan © Dr. José Joskowicz 2013 42 .

2  Entidades lógicas SIP:  User Agents  User Agent Client (UAC): Inician requerimientos SIP  User Agent Server (UAS): Retornan respuestas SIP  Network Servers  Registrar: Acepta registraciones de clientes  Proxy: Decide el próximo salto y redirecciona el requerimiento  Redirect: Envía la dirección del próximo salto al cliente  Location: Servidor de búsqueda  Presence: Servidor de presencia © Dr. SIP Clients and Servers . José Joskowicz 2013 43 . Ing.

Ejemplos con Proxy Server © Dr. José Joskowicz 2013 44 . Ing.

José Joskowicz 2013 45 . Ing.Tel A SIP Tel B SIP Server SIP Invite 0 ms Invite 100 Trying 50 ms 100 Trying 180 Ringing 100 ms 180 Ringing 200 OK(Answer) 10000 ms 200 OK 10050 ms ACK ACK Both way Audio 195000 ms Bye Bye 200 OK 200 OK 195050 ms © Dr.

Ing. José Joskowicz 2013 46 .Ejemplos con Redirect Server © Dr.

com.com © Dr.fing.com.com 1 RS ACK 2 C INVITE sip:pepe@ucla.com 3 UAS 180 Ringing 200 OK ACK Media Stream Media Stream host.com 200 OK INVITE sip:pepe@fing.uy server.fing.ucla.uy 302 Moved sip:pepe@ucla.uy sip. José Joskowicz 2013 47 . Ejemplos con Redirect Server SIP SIP SIP User Agent Redirect User Agent Client Server Server REGISTER pepe@ucla. Ing.com.

José Joskowicz 2013 48 . Ing.© Dr.

323 SIP Standard de ITU RFC de IETF Primera versión de 1996 Primer RFC de 1999 Originalmente diseñado para Originalmente diseñado para establecer comunicaciones multimedia sobre redes sesiones Mensajes con representación binaria Mensajes con representación textual Protocolos complejos Protocolos simples Basado en Q.SIP H. en aumento © Dr.323 . Comparación H.931 (ISDN) No basado en protocolos telefónicos Utiliza RTP y RTCP Utiliza RTP y RTCP Amplia difusión. José Joskowicz 2013 49 . pero disminuyendo Amplia difusión. Ing.

© Dr. Ing. José Joskowicz 2013 50 .

Muchas Gracias! Ing. José Joskowicz © Dr. José Joskowicz 2013 . Ing.