Protocolos VoIP

Hasta hoy en da ha habido una divisin clara entre dos tipos de redes: -Redes de voz, basadas en conmutacin de circuitos, por lo que se ocupa un circuito y el enrutamiento durante una comunicacin se realiza siempre por el mismo camino. Ej: Red ele!nica convencional -Redes de datos, basadas en conmutacin de paquetes, la in!ormacin se discretiza en paquetes y cada paquete puede viajar por caminos di!erentes.Ej: "nternet #ara poder mandar la in!ormacin por las redes de datos tipo "nternet basadas en conmutacin de paquetes es necesario adoptar unos protocolos que permitan transmitir y recuperar la in!ormacin. El problema con la tecnologa de conmutacin de circuitos es que requiere una significativa cantidad de ancho de banda o band$idth para cada llamada y el circuito no es empleado e!icientemente ya que emplea un canal durante toda la duracin de la llamada pero la mayora de las conversaciones tele!nicas est%n hechas de silencio &as redes de datos, por el contrario, slo transmiten in!ormacin cuando es necesario, aprovechando al m%'imo el ancho de banda y en la cual el retardo, la alteracin del orden de lle(ada o la p)rdida de paquetes no son un inconveniente, ya que en el sistema !inal se tiene una serie de procedimientos de recuperacin de la in!ormacin ori(inal* pero para la voz y el video estos factores son altamente influyentes, por lo tanto se requieren redes y protocolos que o!rezcan un alto (rado de +o, -calidad de servicio.. Voz sobre IP -/o"#. de!ine los sistemas de enrutamiento y los protocolos necesarios para la transmisin de conversaciones de voz a trav)s de "nternet, la cual es una red de conmutacin de paquetes basado en el protocolo 0#1"# para el envo de in!ormacin. 2ctualmente e'isten, principalmente, dos arquitecturas de /o"# para la transmisin de voz por "nternet que se utilizan de !orma abundante: SIP Session Initiation Protocol! ,"# son las si(las en in(l)s del #rotocolo para "nicio de ,esin, siendo un est%ndar desarrollado por el "E 3, identi!icado como R30 4567, 5885. ,"# es un protocolo de se9alizacin para establecer las llamadas y con!erencias en redes "#. El inicio de la sesin, cambio o t)rmino de la misma, son independientes del tipo de medio o aplicacin que se estar% usando en la llamada* una sesin puede incluir varios tipos de datos, incluyendo audio, video y muchos otros !ormatos "#$%$ H.454 !ue el primer est%ndar internacional de comunicaciones multimedia, que !acilitaba la conver(encia de voz, video y datos. 3ue inicialmente construido para las redes basadas en conmutacin de paquetes, en las cuales encontr su !ortaleza al inte(rarse con las redes "#, siendo un protocolo muy utilizado en /o"#.

&rquitectura SIP
El protocolo SIP Session Initiation Protocol! fue desarrollado por el grupo ''(SI) 'ultimedia Session )ontrol! del IE*+, de!iniendo una arquitectura de se9alizacin y control para /o"#. "nicialmente !ue publicado en !ebrero del 7::6 en la R30 5;<4, ahora obsoleta con la publicacin de la nueva versin R30 4567 que se public en junio del 5885. El propsito de SIP es la comunicacin entre dispositivos multimedia# SIP hace posible esta comunicacin gracias a dos protocolos que son R*P,R*)P y S-P#

El protocolo R*P se usa para transportar los datos de voz en tiempo real -i(ual que para el protocolo H.454, mientras que el protocolo ,=# se usa para la ne(ociacin de las capacidades de los participantes, tipo de codi!icacin, etc.. ,"# !ue dise9ado de acuerdo al modelo de "nternet. Es un protocolo de se9alizacin e'tremo a e'tremo que implica que toda la l(ica es almacenada en los dispositivos !inales -salvo el rutado de los mensajes ,"#.. El estado de la cone.in es tambi/n almacenado en los dispositivos finales . El precio a pa(ar por esta capacidad de distribucin y su (ran escalabilidad es una sobrecarga en la cabecera de los mensa0es producto de tener que mandar toda la in!ormacin entre los dispositivos !inales. SIP es un protocolo de se1alizacin a nivel de aplicacin para establecimiento y gestin de sesiones con m2ltiples participantes. ,e basa en mensajes de peticin y respuesta y reutiliza muchos conceptos de est%ndares anteriores como H # y ,> #.

)omponentes SIP
SIP soporta funcionalidades para el establecimiento y finalizacin de las sesiones multimedia3 localizacin4 disponibilidad4 utilizacin de recursos4 y caractersticas de negociacin# #ara implementar estas !uncionalidades, e'isten varios componentes distintos en ,"#. E'isten dos elementos !undamentales, los a(entes de usuario -?2. y los servidores. 5# (ser &gent (&!: consisten en dos partes distintas, el ?ser 2(ent 0lient -?20. y el ?ser 2(ent ,erver -?2,.. ?n ?20 es una entidad l(ica que (enera peticiones ,"# y recibe respuestas a esas peticiones. ?n ?2, es una entidad l(ica que (enera respuestas a las peticiones ,"#. 2mbos se encuentran en todos los a(entes de usuario, as permiten la comunicacin entre di!erentes a(entes de usuario mediante comunicaciones de tipo cliente-servidor. %# 6os servidores SIP pueden ser de tres tipos: - Pro.y 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 act@a como cliente y servidor con el propsito de establecer llamadas entre los usuarios. Este servidor tienen una !uncionalidad semejante a la de un #ro'y H # que tiene una tarea de encaminar las peticiones que recibe de otras entidades m%s pr'imas al destinatario. E'isten dos tipos de #ro'y ,ervers: ,tate!ull #ro'y y ,tateless #ro'y.

,tate!ull #ro'y: mantienen el estado de las transacciones durante el procesamiento de las peticiones. #ermite divisin de una peticin en varias -!orAin(., con la !inalidad de la localizacin en paralelo de la llamada y obtener la mejor respuesta para enviarla al usuario que realiz la llamada. ,tateless #ro'y: 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 re(istro de los usuarios y (uarda la in!ormacin de estas peticiones para suministrar un servicio de localizacin y traduccin de direcciones en el dominio que controla. - Redirect Server: es un servidor que (enera respuestas de redireccin a las peticiones que recibe. Este servidor reencamina las peticiones hacia el pr'imo servidor. &a divisin de estos servidores es conceptual, cualquiera de ellos puede estar !sicamente una @nica m%quina, la divisin de )stos puede ser por motivos de escalabilidad y rendimiento.

'ensa0es SIP

,"# es un protocolo te'tual que usa una sem%ntica semejante a la del protocolo H #. &os ?20 realizan las peticiones y los ?2, retornan respuestas a las peticiones de los clientes. SIP define la comunicacin a trav/s de dos tipos de mensa0es# 6as solicitudes m/todos! y las respuestas cdigos de estado! emplean el !ormato de mensaje (en)rico establecido en el R30 5B55 , que consiste en una lnea inicial se(uida de un o m%s campos de cabecera -headers., una lnea vaca que indica el !inal de las cabeceras, y por @ltimo, el cuerpo del mensaje que es opcional. 7 '/todos SIP &as peticiones ,"# son caracterizadas por la lnea inicial del mensaje, llamada Request-&ine, que contiene el nombre del m)todo, el identi!icador del destinatario de la peticin -Request-?R". y la versin del protocolo ,"#. E'isten seis m)todos b%sicos ,"# -de!inidos en R30 5;<. que describen las peticiones de los clientes: - I8VI*E: #ermite invitar un usuario o servicio para participar en una sesin o para modi!icar par%metros en una sesin ya e'istente. - &)9: 0on!irma el establecimiento de una sesin. - :P*I:8: ,olicita in!ormacin sobre las capacidades de un servidor. - ;<E: "ndica la terminacin de una sesin. - )&8)E6: 0ancela una peticin pendiente. - RE=IS*ER: Re(istrar al ?ser 2(ent. ,in embar(o, e'isten otros m)todos adicionales que pueden ser utilizados, publicados en otros R30s como los m)todos "C3D, ,?E,0R"EER,etc. 2 continuacin un ejemplo real de mensaje del metodo REF", ER: Via: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG b!6 6 6 100000000b "c52#6c00000#1200000$0" %ont&nt'(&n)th: 0 %ontact: *+ip:20000,192.168.0.100:5060%a..'ID: /D9080"8'029D' 001'9511'02525/90553 ,192.168.0.100 %S&4: "6 5/GIS6/5 2ro7: *+ip:20000,192.168.0.101-;ta)=9100"" "309" 8a9'2or:ar#+: 30 6o: *+ip:20000,192.168.0.101U+&r'0)&nt: S;phon&/1.60.289a <S; (ab+= 0>thorization: Di)&+t >+&rna7&=?20000?@r&a.7=?192.168.0.101?@nonc&=? "c52&9#29"13c0b$1$885b9aa$$1522#9"c3692? @>ri=?192.168.0.101?@r&+pon+&=?$69 6"b8#"&$#b83c"88&$a9b&1a1&6"? 7 Respuestas )digos de estado! SIP# =espu)s de la recepcin e interpretacin del mensaje de solicitud ,"#, el receptor del mismo responde con un mensaje. Este mensaje, es similar al anterior, di!iriendo en la lnea inicial, llamada ,tatus-&ine, que contiene la versin de ,"#, el cdi(o de la respuesta -,tatusG0ode. y una peque9a descripcin -Reason#hrase.. El cdi(o de la respuesta est% compuesto por tres d(itos que permiten clasi!icar los di!erentes tipos e'istentes. El primer d(ito de!ine la clase de la respuesta. )odigo )lases 5.. 7 'ensa0es provisionales# %.. 7 Respuestas de /.ito# $.. 7 Respuestas de redireccin# >.. 7 Respuestas de fallo de m/todo# ?.. 7 Respuestas de fallos de servidor# @.. 7 Respuestas de fallos globales# 2 0ontinuacin, se incluye un ejemplo de un cdi(o de respuesta. Int&rn&t Protoco.@ Src 0##r: 192.168.0.101 <192.168.0.101=@ D+t 0##r: 192.168.0.100 <192.168.0.100= U+&r Data)ra7 Protoco.@ Src Port: 5060 <5060=@ D+t Port: 5060 <5060= S&++ion Initiation Protoco. Stat>+'(in&: SIP/2.0 200 A! Stat>+'%o#&: 200 5&+&nt PacB&t: 2a.+& /ia: ,"#15.81?=#

192.168.0.100:;868*rport*branchHz:hF<bI6<6<6<788888888b<4c;5d6c88888d7588888!84 0ontent-&en(th: 8 0ontact: Jsip:58788K192.168.0.100:;868L 0all-"=: E=:2B84B-25:=-<82E-:;E7-83;3;E:8;;M<K788.788.788.76 0,eq: 46 REF", ER 3rom: Jsip:58888K192.168.0.101L*ta(H:78844<4M8:4 >a'-3or$ards: M8 o: Jsip:58888K192.168.0.101:;868L 2uthorization: =i(est usernameHN58788N,realmHN192.168.0.101N,nonceHN<4c;5e:d5:47Mc8b!7!BB;b:aa!!7;55d:4cM6:5N,uriHNs ip:192.168.0.101N, responseHN!6:<64bBd4e!dbBMc4BBe!a:be7a7e64N

'ensa0es de error SIP

2 continuacin se muestran los errores que se pueden producir en los mensajes ,"# de manera m%s detallada e'plicando la causa concreta del error: 0omo se ha indicado anteriormente corresponde con las respuestas de la clase: <'' - Respuestas de !allo de m)todo. ;'' - Respuestas de !allos de servidor. 6'' - Respuestas de !allos (lobales. Estos errores se corresponden con los mensajes de error +.:47 o =,,7 y suponen el mapeo de los eventos ,"# con ls cdi(os de error de la R 0 -Red tele!nica conmutada. Evento SIP >AA ;ad request >A5 (nauthorized >A% Payment required >A$ +orbidden >A> 8ot found >A? 'ethod not alloBed >A@ 8ot acceptable >AC Pro.y authentication required >AD Request timeout >AE )onflict >5A =one >55 6ength required >5$ Request entity too long >5> Request (RI (R6! too long >5? (nsupported media type >%A ;ad e.tension >DA *emporarily unavailable >D5 )all leg does not e.ist >D% 6oop detected >D$ *oo many hops Valor decimal -SS5! 75M ;M 57 ;M 7 75M 75M 57 785 <7 7 75M 75M 75M M: 75M 7B 75M 75M 75M Valor Valor he.adecimal transmitido -etalle -SS5! en el canal M! 4: 7; 4: 87 M! M! 7; 66 5: 87 M! M! M! <! M! 75 M! M! M! !! b: :; b: B7 !! !! :; e6 a: B7 !! !! !! c! !! :5 !! !! !! "nter$orAin(, unspeci!ied Eearer capability not authorized 0all rejected Eearer capability not authorized ?nallocated -unassi(ned. number "nter$orAin(, unspeci!ied "nter$orAin(, unspeci!ied 0all rejected Recover on E'pires timeout emporary !ailure ?nallocated -unassi(ned. number "nter$orAin(, unspeci!ied "nter$orAin(, unspeci!ied "nter$orAin(, unspeci!ied ,ervice or option not available "nter$orAin(, unspeci!ied Co user response "nter$orAin(, unspeci!ied "nter$orAin(, unspeci!ied "nter$orAin(, unspeci!ied

>D> &ddress incomplete >D? &ddress ambiguous >D@ ;usy here >DC Request cancelled >DD 8ot acceptable here ?AA Internal server error ?A5 8ot implemented ?A% ;ad gateBay ?A$ Service unavailable ?A> =ateBay timeout ?A? Version not implemented ?DA Precondition +ailed @AA ;usy everyBhere @A$ -ecline @A> -oes not e.ist anyBhere @A@ 8ot acceptable

5B 7 7M 75M 75M <7 M: 4B 64 785 75M <M 7M 57 7 ;B

7c 87 77 M! M! 5: <! 56 4! 66 M! 5! 77 7; 87 4a

:c B7 :7 !! !! a: c! a6 b! e6 !! a! :7 :; B7 ba

2ddress incomplete -invalid number !ormat. ?nallocated -unassi(ned. number ?ser busy "nter$orAin(, unspeci!ied "nter$orAin(, unspeci!ied emporary !ailure ,ervice or option not implemented Cet$orA out o! order ,ervice or option unavailable Recover on E'pires timeout "nter$orAin(, unspeci!ied Resource unavailable, unspeci!ied ?ser busy 0all rejected ?nallocated -unassi(ned. number Eearer capability not presently available

)abecera SIP
6as cabeceras se utilizan para transportar informacin necesaria a las entidades SIP. 2 continuacin, se detallan los campos: 7 Via: "ndica el transporte usado para el envo e identi!ica la ruta del request, por ello cada pro'y a9ade una lnea a este campo. 7 +rom: "ndica la direccin del ori(en de la peticin. 7 *o: "ndica la direccin del destinatario de la peticin. 7 )all7Id: "denti!icador @nico para cada llamada y contiene la direccin del host. =ebe ser i(ual para todos los mensajes dentro de una transaccin. 7 )seq3 ,e inicia con un n@mero aleatorio e identi!ica de !orma secuencial cada peticin. 7 )ontact : 0ontiene una -o m%s. direccin que pueden ser usada para contactar con el usuario. 7 (ser &gent: 0ontiene el cliente a(ente que realiza la comunicacin. 8&++a)& C&a#&r Via: SIP/2.0/UDP 192.168.0.100:5060;rport;branch=z9hG b!6 6 6 100000003" "c52639000020a600000& 5 %ont&nt'(&n)th: 0 %a..'ID: 911D"2/5'//D2' 532'1012'61129 6"6/88,192.168.0.100 %S&4: 1 0%! 2ro7: ?Pr>&ba?*+ip:20000,7ia+t&ri+B.co7-;ta)=8922 0 61 682 8a9'2or:ar#+: 30 5o>t&: *+ip:20001,192.168.0.16o: *+ip:20001,7ia+t&ri+B.co7-;ta)=a+0a23b928 U+&r'0)&nt: S;phon&/1.60.289a <S; (ab+= %ontact: *+ip:20100,192.168.0.100:5060-;&9pir&+="600

-ireccionamiento SIP

?na de las !unciones de los servidores ,"# es la localizacin de los usuarios y resolucin de nombres. Cormalmente, el a(ente de usuario no conoce la direccin "# del destinatario de la llamada, sino su email. 6as entidades SIP identifican a un usuario con las SIP (RI (niform Resource Identifiers! definido en el R+) %$E@. ?na ,"# ?R" tiene un !ormato similar al del e-mail, consta de un usuario y un dominio delimitado por una K, como muestra los si(uientes casos: usuarioKdominio, donde dominio es un nombre de dominio completo. usuarioKequipo, donde equipo es el nombre de la m%quina. usuarioKdireccinOip, donde direccinOip es la direccin "# del dispositivo. n@meroOtel)!onoK(ate$ay, donde el (ate$ay permite acceder al n@mero de tel)!ono a trav)s de la red tele!nica p@blica. 6a solucin de identificacin de SIP4 tambi/n puede ser basada en el -8S descrito en el R+) $%@$4 donde se describen los procedimientos -8S utilizados por los clientes para traducir una SIP (RI en una direccin IP4 puerta y protocolo de transporte utilizado4 o por los servidores para retornar una respuesta al cliente en caso de que la peticin falle#

Protocolo S-P 7 SIP

El protocolo S-P Session -escription Protocol! R+) %$%C se utiliza para describir sesiones multicast en tiempo real4 siendo 2til para invitaciones4 anuncios4 y cualquier otra forma de inicio de sesiones# &a propuesta ori(inal de ,=# !ue dise9ada para anunciar in!ormacin necesaria para los participantes y para aplicaciones de multicast >EDCE ->ulticast EacAbone.. 2ctualmente, su uso est% e'tendido para el anuncio y la ne(ociacin de las capacidades de una sesin multimedia en "nternet. #uesto que ,=# es un protocolo de descripcin, los mensajes ,=# se pueden transportar mediante distintos protocolos con ,"#, ,2#, R ,#, correo electrnico con aplicaciones >">E o protocolos como H #. 0omo el ,"#, el ,=# utiliza la codi!icacin del te'to. ?n mensaje del ,=# 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 simpli!icar el an%lisis. El ,=# no !ue dise9ado para ser !%cilmente e'tensible. 6a 2nica manera de ampliar o de agregar nuevas capacidades al S-P es definir un nuevo atributo# Sin embargo4 los atributos desconocidos pueden ser ignorados# En la tabla siguiente podemos observar todos los campos# ipo =escripcin Dbli(atorio / /ersin del protocolo -obli(atorio. o "denti!icador -obli(atorio. , Combre de sesin -obli(atorio. " "n!ormacin de la sesin -obli(atorio. ? ?R" de la descripcin e =ireccin de correo p C@mero de tel)!ono 0 "n!ormacin de cone'in b 2ncho de banda P iempo de correccin I 0lave de encriptacin a 2tributos iempo de sesin-,tart y stop. -obli(atorio. R iempo de repeticin m "n!ormacin del protocolo de transporte-media. -obli(atorio. S&++ion D&+cription Protoco. V&r+ion <D=: 0 A:n&r/%r&ator@ S&++ion I# <o=: %i+co'SIPU0 26 25 12 "" IE IP 192.168.0.100 A:n&r U+&rna7&: %i+co'SIPU0 S&++ion ID: 26 25 S&++ion V&r+ion: 12 ""

A:n&r E&t:orB 6Fp&: IE A:n&r 0##r&++ 6Fp&: IP A:n&r 0##r&++: 192.168.0.100 S&++ion Ea7& <+=: SIP %a.. %onn&ction In$or7ation <c=: IE IP 192.168.0.100 %onn&ction E&t:orB 6Fp&: IE %onn&ction 0##r&++ 6Fp&: IP %onn&ction 0##r&++: 192.168.0.100 6i7& D&+cription@ actiD& ti7& <t=: 0 0 S&++ion Start 6i7&: 0 S&++ion Stop 6i7&: 0 8&#ia D&+cription@ na7& an# a##r&++ <7=: a>#io 13""8 56P/0VP 0 8 18 101 8&#ia 6Fp&: a>#io 8&#ia Port: 13""8 8&#ia Proto: 56P/0VP 8&#ia 2or7at: I6U'6 G.311 P%8U 8&#ia 2or7at: I6U'6 G.311 P%80 2or7at: I6U'6 G.329 8&#ia 2or7at: 101 8&#ia 0ttrib>t& <a=: rtp7ap:0 P%8U/8000 8&#ia 0ttrib>t& <a=: rtp7ap:8 P%80/8000 8&#ia 0ttrib>t& <a=: rtp7ap:18 G329/8000 8&#ia 0ttrib>t& <a=: rtp7ap:101 t&.&phon&'&D&nt/8000 8&#ia 0ttrib>t& <a=: $7tp:101 0'15

E0emplo )omunicacin SIP

2 continuacin se analizar% detalladamente una llamada. En una llamada SIP hay varias transacciones SIP. ?na transaccin ,"# se realiza mediante un intercambio de mensajes entre un cliente y un servidor. 0onsta de varias peticiones y respuestas y para a(ruparlas en la misma transaccin esta el par%metro 0,eq.
Usuario A Proxy SIP Usuario B

Q 6as dos primeras transacciones corresponden al registro de los usuarios. &os usuarios deben re(istrarse para poder ser encontrados por otros usuarios. En este caso, los terminales envan una peticin REF", ER, donde los campos !rom y to corresponden al usuario re(istrado. El servidor #ro'y, que act@a como Re(ister, consulta si el usuario puede ser autenticado y enva un mensaje de DI en caso positivo. Q 6a siguiente transaccin corresponde a un establecimiento de sesin. Esta sesin consiste en una peticin "C/" E del usuario al pro'y. "nmediatamente, el pro'y enva un RR"CF 788 para parar las retransmisiones y reenva la peticin al usuario E. El usuario E enva un Rin(in( 7B8 cuando el tel)!ono empieza a sonar y tambi)n es reenviado por el pro'y hacia el usuario 2. #or ultimo, el DI 588 corresponde a aceptar la llamada -el usuario E descuel(a.. Q En este momento la llamada estF establecida4 pasa a funcionar el protocolo de transporte R*P con los par%metros -puertos, direcciones, codecs, etc.. establecidos en la ne(ociacin mediante el protocolo ,=#. Q 6a 2ltima transaccin corresponde a una finalizacin de sesin. Esta !inalizacin se lleva a cabo con una @nica peticin ERE enviada al #ro'y, y posteriormente reenviada al usuario E. Este usuario contesta con un DI 588 para con!irmar que se ha recibido el mensaje !inal correctamente.

:b0etivo "#$%$
"#$%$ fue dise1ado con un ob0etivo principal3 Proveer a los usuarios con tele7conferencias que tienen capacidades de voz4 video y datos sobre redes de conmutacin de paquetes# &as continuas investi(aciones y desarrollos de H.454 si(uen con la misma !inalidad y, como resultado, H.454 se convierte en el est%ndar ptimo para cubrir esta clase de aspectos. 2dem%s, H.454 y la conver(encia de voz, video y datos permiten a los proveedores de servicios prestar esta clase de !acilidades para los usuarios de tal !orma que se reducen costos mientras mejora el desempe9o para el usuario. El est%ndar !ue dise9ado espec!icamente con los si(uientes objetivos: S Easarse en los est%ndares e'istentes, incluyendo H.458, R # y +.:47 S "ncorporar al(unas de las ventajas que las redes de conmutacin de paquetes o!recen para transportar datos en tiempo real. S ,olucionar la problem%tica que plantea el envo de datos en tiempo real sobre redes de conmutacin de paquetes. &os dise9adores de H.454 saben que los requisitos de la comunicacin di!ieren de un lu(ar a otro, entre usuarios y entre compa9as y obviamente con el tiempo los requisitos de la comunicacin tambi)n cambian. =ados estos !actores, los dise1adores de "#$%$ lo definieron de tal manera que las empresas que manufacturan los equipos pueden agregar sus propias especificaciones al protocolo y pueden definir otras estructuras de estFndares que permiten a los dispositivos adquirir nuevas clases de caractersticas o capacidades#

)omponentes "#$%$
"#$%$ establece los estFndares para la compresin y descompresin de audio y vdeo4 asegurando que los equipos de distintos fabricantes se intercomuniquen# 2s, los usuarios no se tienen que preocupar de cmo el equipo receptor act@a, siempre y cuando cumpla este est%ndar. #or ejemplo, la (estin del ancho de banda disponible para evitar que la &2C se colapse con la comunicacin de audio y vdeo tambi)n est% contemplada en el est%ndar, esto se realiza limitando el n@mero de cone'iones simult%neas. ambi)n la norma "#$%$ hace uso de los procedimientos de se1alizacin de los canales lgicos

contenidos en la norma "#%>?, en los que el contenido de cada uno de los canales se de!ine cuando se abre. Estos procedimientos se proporcionan para !ijar las prestaciones del emisor y receptor, el establecimiento de la llamada, intercambio de in!ormacin, terminacin de la llamada y como se codi!ica y decodi!ica. #or ejemplo, cuando se ori(ina una llamada tele!nica sobre "nternet, los dos terminales deben ne(ociar cual de los dos ejerce el control, de manera tal que slo uno de ellos ori(ine los mensajes especiales de control. (n punto importante es que se deben determinar las capacidades de los sistemas4 de forma que no se permita la transmisin de datos si no pueden ser gestionados por el receptor# 0omo se ha visto, este est%ndar de!ine un amplio conjunto de caractersticas y !unciones, al(unas son necesarias y otras opcionales. #ero el H.454 de!ine mucho m%s que las !unciones, este est%ndar de!ine los si(uientes componentes m%s relevantes: G *erminal G =ateHay G =ateIeeper G (nidad de )ontrol 'ultipunto G )ontrolador 'ultipunto G Procesador 'ultipunto G Pro.y "#$%$ 1. Terminal (n terminal "#$%$ es un e.tremo de la red que proporciona comunicaciones bidireccionales en tiempo real con otro terminal "#$%$4 gateBay o unidad de control multipunto ')(!# Esta comunicacin consta de se9ales de control, indicaciones, audio, ima(en en color en movimiento y 1o datos entre los dos terminales. 0on!orme a la especi!icacin, un terminal H.454 puede proporcionar slo voz, voz y datos, voz y vdeo, o voz, datos y vdeo. (n terminal "#$%$ consta de las interfaces del equipo de usuario4 el cdec de video4 el cdec de audio4 el equipo telemFtico4 la capa "#%%?4 las funciones de control del sistema y la interfaz con la red por paquetes# a# Equipos de adquisicin de informacin : Es un conjunto de c%maras, monitores, dispositivos de audio -micr!ono y altavoces. y aplicaciones de datos, e inter!aces de usuario asociados a cada uno de ellos. b# )dec de audio3 odos los terminales deber%n disponer de un cdec de audio, para codi!icar y decodi!icar se9ales vocales -F.M77., y ser capaces de transmitir y recibir ley 2 y ley T. ?n terminal puede, opcionalmente, ser capaz de codi!icar y decodi!icar se9ales vocales. El terminal H.454 puede, opcionalmente, enviar m%s de un canal de audio al mismo tiempo, por ejemplo, para hacer posible la di!usin de 5 idiomas. c# )dec de video3 En los terminales H.454 es opcional. d# )anal de datos3 ?no o m%s canales de datos son opcionales. #ueden ser unidireccionales o bidireccionales. e# Retardo en el trayecto de recepcin3 "ncluye el retardo a9adido a las tramas para mantener la sincronizacin, y tener en cuenta la !luctuacin de las lle(adas de paquetes. Co suele usarse en la transmisin sino en recepcin, para a9adir el retardo necesario en el trayecto de audio para, por ejemplo, lo(rar la sincronizacin con el movimiento de los labios en una videocon!erencia. f# (nidad de control del sistema3 #roporciona la se9alizacin necesaria para el !uncionamiento adecuado del terminal. Est% !ormada por tres bloques principales: 3uncin de control H.5<;, !uncin de se9alizacin de llamada H.55; y !uncin de se9alizacin R2,.

S 2>nciGn #& contro. C.2 5: ,e utiliza el canal l(ico de control H.5<; para llevar mensajes de control e'tremo a e'tremo que ri(e el modo de !uncionamiento de la entidad H.454. ,e ocupa de ne(ociar las capacidades -ancho de banda. intercambiadas, de la apertura y cierre de los canales l(icos y de los mensajes de control de !lujo. En cada llamada, se puede transmitir cualquier n@mero de canales l(icos de cada tipo de medio -audio, video, datos. pero solo e'istir% un canal l(ico de control, el canal l(ico 8. H 2>nciGn #& +&Ia.izaciGn #& .a ..a7a#a C.225: ?tiliza un canal l(ico de se9alizacin para llevar mensajes de establecimiento y !inalizacin de la llamada entre 5 puntos e'tremos H.454. El canal de se9alizacin de llamada es independiente del canal de control H.5<;. &os procedimientos de apertura y cierre de canal l(ico no se utilizan para establecer el canal de se9alizacin. ,e abre antes del establecimiento del canal de control H.5<; y de cualquier otro canal l(ico. #uede establecerse de terminal a terminal o de terminal a (ateAeeper. H 2>nciGn #& contro. 50S <5&)i+tro@ 0#7i+iGn@ Sit>aciGn=: ?tiliza un canal l(ico de se9alizacin R2, para llevar a cabo procedimientos de re(istro, admisin, situacin y cambio de ancho de banda entre puntos e'tremos -terminales, (ate$ay... y el (ateAeeper. ,lo se utiliza en zonas que ten(an un (ateAeeper. El canal de se9alizacin R2, es independiente del canal de se9alizacin de llamada, y del canal de control H.5<;. &os procedimientos de apertura de canal l(ico H.5<; no se utilizan para establecer el canal de se9alizacin R2,. El canal de se9alizacin R2, se abre antes de que se establezca cualquier otro canal entre puntos e'tremos H.454. g# )apa "#%%?3 ,e encar(a de dar !ormato a las tramas de video, audio, datos y control transmitidos en mensajes de salida hacia la inter!az de red y de recuperarlos de los mensajes que han sido introducidos desde la inter!az de red. 2dem%s lleva a cabo tambi)n la alineacin de trama, la numeracin secuencial y la deteccin1correccin de errores. h# Interfaz de red de paquetes3 Es espec!ica en cada implementacin. =ebe proveer los servicios descritos en la recomendacin H.55;. Esto si(ni!ica que el servicio e'tremo a e'tremo !iable -por ejemplo, 0#. es obli(atorio para el canal de control H.5<;, los canales de datos y el canal de se9alizacin de llamada. El servicio de e'tremo a e'tremo no !iable -?=#, "#U. es obli(atorio para los canales de audio, los canales de video y el canal de R2,. Estos servicios pueden ser d@ple' o smple' y de unicast o multicast dependiendo de la aplicacin, las capacidades de los terminales y la con!i(uracin de la red. 2. Gateway ?n (ate$ay H.454 es un e'tremo que proporciona comunicaciones bidireccionales en tiempo real entre terminales H.454 en la red "# y otros terminales o (ate$ays en una red conmutada. En (eneral, el propsito del (ate$ay es re!lejar transparentemente las caractersticas de un e'tremo en la red "# a otro en una red conmutada y viceversa. 3. Gatekeeper El (ateAeeper es una entidad que proporciona la traduccin de direcciones y el control de acceso a la red de los terminales H.454, (ate$ays y >0?s. El (ateAeeper puede tambi)n o!recer otros servicios a los terminales, (ate$ays y >0?s, tales como (estin del ancho de banda y localizacin de los (ate$ays. El FateAeeper realiza dos !unciones de control de llamadas que preservan la inte(ridad de la red corporativa de datos. &a primera es la traslacin de direcciones de los terminales de la &2C a las correspondientes "# o "#U, tal y como se describe en la especi!icacin R2,. &a se(unda es la (estin del ancho de banda, !ijando el n@mero de con!erencias que pueden estar d%ndose simult%neamente en la &2C y rechazando las nuevas peticiones por encima del nivel establecido, de manera tal que se (arantice ancho de banda su!iciente para las aplicaciones de datos sobre la &2C. El FateAeeper proporciona todas las !unciones anteriores para los terminales, Fate$ays y >0?s, que est%n re(istrados dentro de la denominada Pona de control H.454. 2dem%s de las !unciones anteriores, el FateAeeper realiza los si(uientes servicios de control:

S 0ontrol de admisiones: El (ateAeeper puede rechazar aquellas llamadas procedentes de un terminal por ausencia de autorizacin a terminales o (ate$ays particulares de acceso restrin(ido o en determinadas !ranjas horarias. S 0ontrol y (estin de ancho de banda: #ara controlar el n@mero de terminales H.454 a los que se permite el acceso simult%neo a la red, as como el rechazo de llamadas tanto entrantes como salientes para las que no se dispon(a de su!iciente ancho de banda. S Festin de la zona: &leva a cabo el re(istro y la admisin de los terminales y (ate$ays de su zona. 0onoce en cada momento la situacin de los (ate$ays e'istentes en su zona que encaminan las cone'iones hacia terminales R00. 4. MCU &a ?nidad de 0ontrol >ultipunto est% dise9ada para soportar la con!erencia entre tres o m%s puntos, bajo el est%ndar H.454, llevando la ne(ociacin entre terminales para determinar las capacidades comunes para el proceso de audio y vdeo y controlar la multidi!usin. 5. CONTROLADOR MULTI UNTO ?n controlador multipunto es un componente de H.454 que provee capacidad de ne(ociacin con todos los terminales para llevar a cabo niveles de comunicaciones. ambi)n puede controlar recursos de con!erencia tales como multicastin( de vdeo. El 0ontrolador >ultipunto no ejecuta mezcla o conmutacin de audio, vdeo o datos. !. ROC"#ADOR MULTI UNTO ?n procesador multipunto es un componente de H.454 de hard$are y so!t$are especializado, mezcla, conmuta y procesa audio, vdeo y 1 o !lujo de datos para los participantes de una con!erencia multipunto de tal !orma que los procesadores del terminal no sean pesadamente utilizados. El procesador multipunto puede procesar un !lujo medio @nico o !lujos medio m@ltiples dependiendo de la con!erencia soportada. $. RO%& '.323 ?n pro'y H.454 es un servidor que provee a los usuarios acceso a redes se(uras de unas a otras con!iando en la in!ormacin que con!orma la recomendacin H.454.El #ro'y H.454 se comporta como dos puntos remotos H.454 que envan mensajes call G set up, e in!ormacin en tiempo real a un destino del lado se(uro del !ire$all.

Pila de protocolos "#$%$

2 continuacin se e'plican los protocolos m%s si(ni!icativos para H.454: - R*P,R*)P Real7*ime *ransport Protocol , Real7*ime *ransport )ontrol Protocol! #rotocolos de transporte en tiempo real que proporcionan servicios de entre(a punto a punto de datos. - R&S Registration4 &dmission and Status!3 ,irve para re(istrar, control de admisin, control del ancho de banda, estado y descone'in de los participantes. - "%%?#A3 #rotocolo de control de llamada que permite establecer una cone'in y una descone'in. - "#%>?3 #rotocolo de control usado en el establecimiento y control de una llamada. En concreto presenta las si(uientes !uncionalidades: 7. "ntercambio de capacidades: &os terminales de!inen los cdecs de los que disponen y se lo comunican al otro e'tremo de la comunicacin. 5. 2pertura y cierre de canales l(icos: &os canales de audio y video H.454 son punto a punto y unidireccionales. #or lo tanto, en !uncin de las capacidades ne(ociadas, se tendr%n que crear como mnimo dos de estos canales. Esto es responsabilidad de H.5<;. 4. 0ontrol de !lujo cuando ocurre al(@n tipo de problema. <. >ultitud de otras peque9as !unciones.

- J#E$53 -=i(ital ,ubscriber ,i(nallin(. Este protocolo se de!ine para la se9alizacin de accesos R=," b%sico. - RSVP -Resource Re,er/ation #rotocol.: #rotocolo de reserva de recursos en la red para cada !lujo de in!ormacin de usuario - *#5%A3 &a recomendacin .758 de!ine un conjunto de protocolos para con!erencia de datos Entre los codecs que recomienda usar la norma H.454 se encuentran principalmente: G =#C553 =e los m@ltiples cdecs de audio que pueden implementar los terminales H.454, este es el @nico obli(atorio. ?sa modulacin por por pulsos codi!icados -#0>. para conse(uir tasas de bits de ;6Ibps y 6<Ibps. G "#%@5y "#%@$3 &os dos cdecs de video que propone la recomendacin H.454. ,in embar(o, se pueden usar otros.

Se1alizacin "#$%$
6a funcin de se1alizacin estF basada en la recomendacin "#%%?4 que especifica el uso y soporte de mensa0es de se1alizacin J#E$5,JE$%. &as llamadas son enviadas sobre 0# por el puerto 7M58. ,obre este puerto se inician los mensajes de control de llamada +.:47 entre dos terminales para la cone'in, mantenimiento y descone'in de llamadas. 6os mensa0es mFs comunes de +.:471+.:45 usados como mensa0es de se1alizacin "#$%$ son: 7 Setup# Es enviado para iniciar una llamada H.454 para establecer una cone'in con una entidad H.454. Entre la in!ormacin que contiene el mensaje se encuentra la direccin "#, puerto y alias del llamante o la direccin "# y puerto del llamado. 7 )all Proceeding# Enviado por el FateAeeper a un terminal advirtiendo del intento de establecer una llamada una vez analizado el n@mero llamado. 7 &lerting# "ndica el inicio de la !ase de (eneracin de tono. 7 )onnect# "ndica el comienzo de la cone'in. 7 Release )omplete. Enviado por el terminal para iniciar la descone'in. 7 +acility. Es un mensaje de la norma +.:45 usado como peticin o reconocimiento de un servicio suplementario. 2>nciGn #& contro. C.2 5 E6 canal de control "#%>? es un con0unto de mensa0es &S8#5 usados para el establecimiento y control de una llamada. ?nas de las caractersticas que se intercambian m%s relevantes son: Q 'asterSlave-etermination 'S-!. Este mensaje es usado para prevenir con!lictos entre dos terminales que quieren iniciar la comunicacin. =ecide qui)n actuar% de >aster y qui)n de ,lave. Q *erminal)apabilitySet *)S!# >ensaje de intercambio de capacidades soportadas por los terminales que intervienen en una llamada. Q :pen6ogical)hannel :6)!# >ensaje para abrir el canal l(ico de in!ormacin contiene in!ormacin para permitir la recepcin y codi!icacin de los datos. 0ontiene la in!ormacin del tipo de datos que ser% transportados. Q )lose6ogical)hannel )6)!. >ensaje para cerrar el canal l(ico de in!ormacin

E0emplo "#$%$
2 continuacin se analizar% detalladamente una llamada. En una llamada H.454 hay varias !ases como se indica en el si(uiente (r%!ico y varios protocolos cada uno de un color.

?na llamada H.454 se caracteriza por las si(uientes !ases: 5# ES*&;6E)I'IE8*: - En esta !ase lo primero que se observa es que uno de los terminales se registra en el gateIeeper utilizando el protocolo R2, -Re(istro, admisin y estado. con los mensajes 2R+ y 203. - #osteriormente utilizando el protocolo H.55; -que se utiliza para establecimiento y liberacin de la llamada. se manda un mensa0e de SE*(P para iniciar una llamada "#$%$. Entre la in!ormacin que contiene el mensaje se encuentra la direccin "#, puerto y alias del llamante o la direccin "# y puerto del llamado. - El terminal llamado contesta con un )&66 PR:)EE-I8= advirtiendo del intento de establecer una llamada. - En este momento el se(undo terminal tiene que re(istrarse con el (ateAeeper utilizando el protcolo R2, de manera similar al primer terminal 7 El mensaje &6ER*I8= indica el inicio de la fase de generacin de tono# 7 R por @ltimo ):88E)* indica el comienzo de la cone.in. %# SEK&6IL&)IM8 -E ):8*R:6 7 En esta !ase se abre una negociacin mediante el protocolo "#%>? control de conferencia! , el intercambio de los mensajes -peticin y respuesta. entre los dos terminales establecen qui)n ser% master y qui)n slave, las capacidades de los participantes y codecs de audio y video a utilizar. )omo punto final de esta negociacin se abre el canal de comunicacin-direcciones "#, puerto.. &os principales mensajes H.5<; que se utilizan en esta !ase son: Q *erminal)apabilitySet *)S!# >ensaje de intercambio de capacidades soportadas por los terminales que intervienen en una llamada. Q :pen6ogical)hannel :6)!# >ensaje para abrir el canal l(ico de in!ormacin que contiene in!ormacin para permitir la recepcin y codi!icacin de los datos. 0ontiene la in!ormacin del tipo de datos que ser% transportados. $# &(-I: &os terminales inician la comunicacin y el intercambio de audio -o video. mediante el protocolo R #1R 0#. ># -ES):8ENIM8 7 En esta !ase cualquiera de los participantes activos en la comunicacin puede iniciar el proceso de !inalizacin de llamada mediante mensa0es )lose6ogical)hannel y EndSession)omand de "#%>?# - #osteriormente utilizando "#%%? se cierra la cone.in con el mensa0e RE6E&SE ):'P6E*E - #or @ltimo se liberan los registros con el gateIeeper utilizando mensajes del protocolo R2,:

&rquitectura I&N
El protocolo I&N se corresponde con Inter7&sterisI eNchange protocol. 0omo indica su nombre fue dise1ado como un protocolo de cone.iones VoIP entre servidores &sterisI aunque hoy en da tambi)n sirve para cone'iones entre clientes y servidores que soporten el protocolo. 6a versin actual es I&N% ya que la primera versin de "2U ha quedado obsoleta Es un protocolo dise9ado y pensado para su uso en cone'iones de /o"# aunque puede soportar otro tipo de cone'iones -por ejemplo video. 6os ob0etivos de I&N son: -'inimizar el ancho de banda usado en las transmisiones de control y multimedia de /o"# -Evitar problemas de 8&* -Cet$orA 2ddress ranslation. -,oporte para transmitir planes de marcacin Entre las medidas para reducir el ancho de banda cabe destacar que "2U o "2U5 es un protocolo binario en lu(ar de ser un protocolo de te'to como ,"# y que hace que los mensajes usen menos ancho de

banda. #ara evitar los problemas de C2 el protocolo "2U o "2U5 usa como protocolo de transporte ?=#, normalmente sobre el puerto <;6:,-el "2U7 usaba el puerto ;846., y tanto la in!ormacin de se9alizacin como los datos viajan conjuntamente -a di!erencia de ,"#. y por tanto lo hace menos proclive a problemas de C2 y le permite pasar los routers y !ire$alls de manera m%s sencilla.

'ensa0es I&N
#ara poder entender el protocolo "2U vamos a ver un ejemplo del !lujo de datos de una comunicacin "2U5:

?na llamada "2U o "2U5 tiene tres !ases: 2. Establecimiento de la llamada El terminal 2 inicia una cone'in y manda un mensaje Nne$N. El terminal llamado responde con un NacceptN y el llamante le responde con un N2cAN. 2 continuacin el terminal llamado da las se9ales de Nrin(in(N y el llamante contesta con un NacAN para con!irmar la recepcin del mensaje. #or @ltimo, el llamado acepta la llamada con un Nans$erN y el llamante con!irma ese mensaje. E. +lu0o de datos o flu0o de audio ,e mandan los !rames > y 3 en ambos sentidos con la in!ormacin vocal. &os !rames > son mini-!rames que contienen solo una cabecera de < bytes para reducir el uso en el ancho de banda. &os !rames 3 son !rames completos que incluyen in!ormacin de sincronizacin. Es importante volver a resaltar que en "2U este !lujo utiliza el mismo protocolo ?=# que usan los mensajes de se9alizacin evitando problemas de

C2 . 0. 6iberacin de la llamada o descone'in &a liberacin de la cone'in es tan sencillo como enviar un mensaje de Nhan(upN y con!irmar dicho mensaje.

+rames o tipos de tramas

&os mensajes o tramas que se envian en "2U5 son binarios y por tanto cada bit o conjunto de bits tiene un si(ni!icado. 0omo hemos indicado anteriormente e'isten dos tipos de mensajes principalmente: &! *ramas + o +ull +rames &a particularidad de las tramas o mensajes 3 es que deben ser respondidas e'plcitamente. Es decir cuando un usuario manda a otro una trama 3 -!ull !rame. el receptor debe contestar con!irmando que ha recibido ese mensaje. Estas tramas son las @nicas que deben ser respondidas e'plcitamente. 2 continuacin ponemos el !ormato binario de una trama 3 o !ull !rame de "2U5.

El si(ni!icado de cada uno de los campos es el si(uiente: - + : ?n bit que indica si la trama es 3 -!ull !rame. o no. #ara que sea 3 o !ull !rame debe estar puesta a 7. - Source )all 8umber 7 82mero de llamada de origen : 7; bits que indenti!ican la conversacin de ori(en ya que puede haber varias comunicaciones multiple'adas por la misma lnea. - R : Eit de retransmisin. ,e pone a uno cuando la trama es retransmitida. - -estination )all 8umber 7 82mero de llamada destino : lo mismo que el de ori(en pero para identi!icar el destino. - *imestamp o sello de tiempo - #ara marcar el tiempo en cada paquete - :Seqno 7 sec# de salida : C@mero de secuencia de salida con B bits. 0omienza en 8 y se va incrementandose cada mensaje. - ISeqno 7 sec# de entrada : &o mismo para la entrada. - +rame *ype 7 tipo de trama :"ndica la clase de trama de que se trata - ): #uesto a 8 indica que el campo subclase debe tomarse como M bits -un solo mensaje.: #uesto a 7 indica que el campo subclase se obtiene con 7< bits -dos mensajes consecutivos.. - Subclass 7 subclase - ,ubclase del mensaje. - -ata 7 -atos : datos que se envan en !ormato binario. ;! *ramas ' o 'ini +rames &as tramas > o mini !rames para mandar la in!ormacin con la menor in!ormacin posible en la cabecera. Estas tramas no tienen porque ser respondidas y si al(una de ellas se pierde se descarta sin m%s.

El !ormato binario de las tramas > o mini !rames es el si(uiente:

El si(ni!icado de los campos es similar al de las tramas 3 o !ull !rame. En este caso el bit + estF puesto a A y el sello de tiempo o imestamp est% truncado y solo tiene 76 bits para ali(erar la cabecera. ,on los clientes los que deben encar(arse de llevar un timestamp de 45 bits si lo desean y para sincronizarlo mandar una trama 3.

+rames + o +ull +rame

El campo ype 3rame o tipo de trama de las tramas 3 junto con el campo subclase determinan la !uncin del paquete que se est% enviado o recibiendo y sirven por tanto como se9alizacin de control. El campo ype 3rame esta !ormado por B bits -7 byte. y los principales valores que puede tomar se muestran en la si(uiente tabla: *abla 5# Posibles valores del campo O*ype +rameO de las tramas + o +ull +rame
Valor Otype frameO -escripcin -etalles

88888887 AAAAAAA% 88888884 AAAAAAA> 8888888; AAAAAAA@ 8888888M 8888888B 8888888:

= >3 -atos de voz =atos de video )ontrol Co usado )ontrol I&N e'to "ma(en H >&

,irve para enviar d(itos = >3 El campo subclase indica el tipo de codec de audio que se utiliza seg2n la tabla % El campo subclase indica el tipo de codec de video que se utiliza 'ensa0es de control de sesin# Sirve para controlar el estado de los dispostivos finales# El campo subclase indica el tipo concreto de mensa0e de control seg2n tabla $# 'ensa0es de control del protocolo I&N# =estiona las interacciones necesarias entre los dispositivos finales# El campo subclase indica el tipo concreto de mensa0e de control seg2n tabla >#

*abla %# Significado de los valores del campo subclase para +rame *ype P OA.A%O datos de voz!

Valor subclase *ype +rame PA.A%!

-escripcin codec que se utiliza en la conversacin!

8'8887 8'8885 8'888< 8'888B 8'88B8 8'8788 8'8588 8'8<88

F.M54.7 F,> F.M77 u -u-la$. F.M77 a -a-la$. &#078 F.M5: ,pee' i&E0

*abla $# Significado de los valores del campo subclase para +rame *ype P OA.A>O control!
Valor subclase *ype +rame PA.A>!

-escripcin

-etalles

8'87 8'85 8'84 8'8< 8'8; 8'8B 8'8e

Han(up Rin( Rin(in( -rin(bacA. 2ns$er Eusy 0ondition 0on(estion 0ondition 0all #ro(ress

&a llamada se ha col(ado El tele!ono esta sonando Respuesta El usuario est% ocupado E'iste con(estin #ro(reso de la llamada

*abla ># Significado de los valores del campo subclase para +rame *ype P OA.A@O control I&N!
Valor subclase -escripcin *ype +rame PA.A?!

-etalles

8'87 8'85 8'84 8'8< 8'8; 8'86 8'8M 8'8B 8'8: 8'8a 8'8b

CEV #"CF #DCF 20I H2CF?# REWE0 200E# 2? HRE+ 2? HRE# "C/2& &2FR+

"niciar una nueva llamada Enviar un pin( Responder un pin( Respuesta a!irmativa "nicio de descone'in Rechazo 2ceptacin #eticin de autenticacin Respuesta de autenticacin &&amada no v%lida #eticin de &a(

8'78 8'77 8'75 8'74 8'7< 8'7; 8'76 8'7M 8'7B 8'7: 8'7a

REFREW REFRE& /C2I =#RE+ =#RE# ="2& URE+ U0C U200 URE2=R URE&

=ene(acin de re(istro &iberacin de re(istro #eticin de retransmisin #eticin de dialplan Respuesta de dialplan >arcado #eticin de trans!erencia 0one'in de trans!erencia 2ceptacin de trans!erencia rans!erencia preparad &iberacin de trans!erencia

8'8c 8'8d 8'8e 8'8!

&2FR# REFRE+ REF2? H REF20I

Respuesta de &a( #eticin de re(istro 2utenticacin de re(istro 20I de re(istro

8'7b 8'7c 8'7d 8'58 8'57

UREW +?E&0H ?C+?E&0H >V" ?C,?##DR

Rechazo de trans!erencia #arar transmisin de audio 0ontinuar transmisin de audio "ndicador de mensaje en espera >ensaje no soportado

I&N vs SIP 7 comparacin entre I&N y SIP

"2U !ue creado por >arA ,pencer -tambi)n creador de 2sterisI. para paliar una serie de problemas o incovenientes que se encontr al utilizar ,"# en /o"# y que pens que deba ser mejorado. &as principales di!erencias ente "2U y ,"# son las si(uientes:
7 &ncho de banda#

I&N utiliza un menor ancho de banda que ,"# ya que los mensa0es son codificados de forma binaria mientras que en SIP son mensa0es de te.to. 2simismo, I&N intenta reducir al mF.imo la informacin de las cabeceras de los mensajes reduciendo tambi)n el ancho de banda - 8&* En "2U la se9alizacin y los datos via0an con0untamente con lo cual se evitan los problemas de 8&* que frecuentemente aparecen en SIP. En ,"# la se9alizacin y los datos viajan de manera separada y por eso aparecen problemas de C2 en el !lujo de audio cuando este !lujo debe superar los routers y !ire$alls. ,"# suele necesitar un servidor , ?C para estos problemas
7 Estandarizacin y uso

SIP es un protocolo estandarizado por la IE*+ hace bastante tiempo y que es ampliamente implementado por todos los fabricantes de equipos y softBare. I&N est% aun siendo estandarizado y es por ello que no se encuentra en muchos dispositivos e.istentes en el mercado#
7 (tilizacin de puertos

I&N utiliza un solo puerto >?@E! para mandar la informacin de se1alizacin y los datos de todas sus llamadas. #ara ello utiliza un mecanismo de multiple'in o NtrunAin(N. SIP4 sin embargo utiliza un puerto ?A@A! para se1alizacin y % puertos R*P por cada cone.in de audio -como mnimo 4 puertos.. #or ejemplo para 788 llamadas simultaneas con ,"# se usaran 588 puertos -R #. m%s el puerto ;868 de se9alizacin. "2U utilizara slo un puerto para todo -<;6:.
7 +lu0o de audio al utilizar un servidor

En SIP si utilizamos un servidor la se9alizacin de control pasa siempre por el servidor pero la informacin de audio flu0o R*P! puede via0ar e.tremo a e.tremo sin tener que pasar necesariamente por el servidor SIP. En I&N al viajar la se9alizacin y los datos de !orma conjunta todo el trFfico de audio debe pasar obligatoriamente por el servidor I&N . Esto produce una aumento en el uso del ancho de banda que deben soportar los servidores I&N sobretodo cuando hay muchas llamadas simulataneas.
7 :tras funcionalidades

I&N es un protocolo pensado para /o"# y transmisin de video y presenta funcionalidades interesantes como la posibilidad de enviar o recibir planes de marcado dialplans! que resultan muy interesante al usarlo conjuntamente con servidores 2sterisA. SIP es un protocolo de proposito general y podra transmitir sin dificultad cualquier informacin y no slo audio o video#

H454 es el protocolo m%s de!inido pero adolece de cierta !alta de !le'ibilidad . ,"# est% menos de!inido pero es m%s !%cil de inte(rar, X+ue protocolo (anar% al !inalY. Es di!icil de decir pero dependera de la aplicacin que cada uno quiera desarrollar. -,"# es m%s !acil de implementar aunque los conceptos de H.454 son mejores..

"#$%$

SIP

2rquitectura

H.454 cubre casi todos los servicios como capacidad de intercambio,control de con!erencia , se9alizacin basica, calidad de servicio, re(istro, servicio de descubrimiento y m%s.

,"# es modular y cubre la se9alizacin b%sica, la localizacin de usuarios y el re(istro. Dtras carctersticas se implementan en protocolos separados. ?2 ,ervidores ," ,=#

0omponentes

erminal1Fate$ay FateAeeper

#rotocolos

R2,1+.:47 H.5<;

3uncionalidades de control de llamada rans!erencia de llamada -0all rans!er. E'pedicin de llamada -0all 3or$ardin(. enencia de llamada -0all Holdin(. &lamada estacionada1reco(ida -0all #arAin(1#icAup. &&amada en espera -0all Vaitin(. "ndicacin de mensaje en espera ->essa(e Vaitin( "ndication. "denti!icacin de nombre -Came "denti!ication. erminacin de llamada con subscriptor ocupado -0all 0ompletion on Eusy ,ubscriber. D!recimiento de llamada -0all D!!er. "ntrusin de llamada -0all "ntrusion. ,i ,i ,i ,i ,i ,i ,i ,i ,i ,i H.454 las divide en los protocolos H.<;8, R2,, H.5<; y +.:47 )aractersticas &vanzadas ,enalizacin multicast ->ulticast ,i(nalin(. ,i, requiere localizacin -&R+. y descubrimiento autom%tico del (ateAeeper -FR+.. ,i, a trav)s de pausa de la tercera parte y reenrutando se(@n esta de!inido en H.454. ?n ,i, ejemplo, a trav)s de mensajes de (rupo "C/" Es. ,i ,i ,i ,i ,i Co Co ,i Co Co

0ontrol de la llamada de un tercero - hird-party 0all 0ontro.l

,i, se(@n se describe en los borradores -=ra!ts. del protocolo.

control m%s so!isticado se de!ine en el standard de las series H.<;8.' . 0on!erencia #inchar para llamar -0licA !or =ial. Escalabilidad C@mero amplio de dominios -&ar(e Cumber o! =omains. &a intencin inicial de H.454 !ue el soporte de &2Cs, por lo que est% pensado para el direccionamiento de redes amplias. El concepto de zona !ue a9adido para acomodar este direccionamiento amplio. &os procedimientos son de!inidos por localizacin de usuarios a trav)s de nombres de email. El ane'o F de!ine la comunicacin entre dominios administrativos, describiendo los metodos para resolucin de direcciones, autorizacin de acceso y el reporte entre dominios administrativos. En las busquedas multidominio no hay !ormas sencillas de detectar bucles. &a deteccin de bucles se puede realizar a trav)s del campo N#ath/alueN pero introduce problemas relativos a la escalabilidad. El control de llamadas en se implementa de una manera sin estado. ?n (ate$ay usa los mensajes de!inidos en H.55; para ayudar al (ateAeeper en el balanceo de car(a de los (ate$ays implicados. ,"# soporta de manera inherente direccionamientos de %reas. 0uando muchos servidores est%n implicados en una llamada ,"# usa un al(oritmo similar a EF# que puede ser usado en una manera sin estado evitando problemas de escalabilidad. &os ,"# Re(istrar y servidores de redireccin !ueron dise9ados para soportar localizacin de usuarios. ,i ,i ,i ,i

Fran cantidad de llamadas -&ar(e Cumber o! 0alls.

El control de llamadas en se implementa de una manera sin estado. ,"# soporta escalabilidad n a n entre ?2s y servidores. ,"# necesita menos ciclos de 0#? para (enerar mensajes de se9alizacin #or lo tanto, teoricamente un servidor puede manejar m%s transacciones. ,"# ha especi!icado un m)todo de balanceado de car(a basado en el mecanismo de traslacin =C, ,R/. 0on estado o sin estado. ?na llamada

Estado de la cone'in

0on estado o sin estado.

,"# es independiente de la e'istencia de una cone'in en la capa de transporte, pero sin embar(o la se9alizacin de llamadas tiene que ser terminada e'plicitamente. "nternationalizacin ,i, H.454 usa ?nicode -E>#,trin( con 2,C.7. para al(una in!ormacin te'tual -h454-id., pero (eneralmente tiene pocos parametros te'tuales ,i, ,"# usa ?nicode -",D 786<6-7., codi!icado como ? 3-B, para todas las cadenas de te'to, permitiendo todos los caracteres para nombres, mensajes y parametros. ,"# provee metodos para la indicacin del idioma y pre!erencias del idioma. ,"# soporta autenti!icacin de llamante y llamado mediante mecanismos H #. 2utenticacin cripto(r%!ica y encriptacin son soportados salto a salto por ,,&1 ,& pero ,"# puede usar cualquier capa de transporte o cualquier mecanismo de se(uridad de H #, como ,,H o ,-H #. 0laves para encriptacin multimedia se o!recen usando ,=#. ,,& soporta autenticacin sim)trica y asim)trica. ,"# tambi)n de!ine autenticacin y encriptacin !inal usando #F# o ,1>">E. En ,"#, una nueva versin puede descartar caractersticas que no van a ser soportadas m%s. Esto consi(ue reducir el tama9o del cdi(o y la complejidad del protocolo , pero hace perder cierta compatibilidad entre versiones. ,"# no prevee nin(una (ua de interoperabilidad

Seguridad

=e!ine mecanismos de se(uridad y !acilidades de ne(ociacin mediante H.54;, puede usar ,,& para se(uridad en la capa de transporte.

Interoperabilidad entre versiones

&a compatibilidad hacia at%s de H.454 permite que todas las implementaciones basadas en di!erentes versiones de H.454 sean !%cilmente inte(rables.

Implementacin de la Interoperabilidad

H.454 provee una (ua de implementacin, que clari!ica el standard y ayuda a la interoperabilidad entre

di!erentes implementaciones.

+acturacin

"ncluso con el modelo de llamada directa H.454, la posibilidad de !acturar la llamada no se pierde porque los puntos !inales reportan al (ateAeeper el tiempo de inicio y !inalizacin de la llamada mediante el protocolo R2,.

,i un pro'y ,"# quiere reco(er in!ormacin de !acturacin no tiene otra opcin que revisar el canal de se9alizacin de manera constante para detectar cuando se completa la llamada. "ncluso as, las estadsticas est%n ses(adas porque la se9alizacin de la llamada puede tener retardos. ,"# soporta cualquier codec "2C2-re(istered -es una caracterstica hererada. o cualquier codec cuyo nombre sea de mutuo acuerdo.

)odecs

H.454 suporta cualquier codec, estandarizado o propietario, no slo codecs " ?- , por ejemplo codecs >#EF o F,>. >uchos !abricaantes soportan codecs propietarios a trav)s de 2,C.7 que es equivalente en ,"# a Ncdi(os privados de mutuo acuerdoN 0ualquier codec puede ser se9alizado a trav)s de la caracterstica Feneric0apability a9adida en H.454v4. ?n (ateAeeper H.454 puede controlar la se9alizacin de la llamada y puede bi!urcar a cualquier n@mero de dispositivos simultaneamente. 3iable -Reliable. o no !iable -unreliable., ej., 0# o ?=#. &a mayora de las entidades H.454 usan transporte !iable - 0#. para se9alizacin.

;ifurcacin de llamadas )all +orIing!

?n pro'y ,"# puede controlar la se9alizacin de la llamada y puede bi!urcar a cualquier n@mero de dispositivos simultaneamente.

Protocolo de transporte

3iable -Reliable. o no !iable -unreliable., ej., 0# o ?=#. &a mayora de las entidades ,"# usan transporte no !iable -?=#. para se9alizacin. ,"# codi!ica los mensajes en !ormato 2,0"", adecuado para que lo puedan leer los humanos.

)odificacin de mensa0es 'essage Encoding!

H.454 codi!ica los mensajes en un !ormato binario compacto adecuado para cone'iones de (ran ancho de banda. >ecanismos de se9alizacin !le'ibles, incluyendo ?R&s y n@meros E.76<.

-ireccionamiento &ddressing!

,"# slo entiende direcciones del estilo ?R&.

Intercone.in Red *elefnica P2blica PS*8 InterBorIing!

H.454 toma prestado de la red tele!nica p@blica protocolos como +.:47 y est% por tanto bien adecuada para la inte(racin. ,in embar(o, H.454 no emplea la analo(a a tecnolo(a de conmutacin de circuitos de red tele!nica p@blica de ,"#. H.454 es totalmente una red de conmutacin de paquetes. El como los controles deben implementarse en la arquitectura H.454 est% bien reco(ido en el est%ndar. ,i, los (ateAeepers pueden detectar bucles mirando los campos N0all"denti!ierN y Ndestination2ddressN en los mensajes de procesamiento de la llamada. 0ombinando ambos se pueden detectar bucles

,"# no tiene nada en com@n con la red tele!nica p@blica y esa se9alizacin debe ser NsimuladaN en ,"#. ,"# no tiene nin(una arquitectura que describa cmo deben implementarse los controles.

-eteccin de bucles 6oop -etection!

,i, el campo N/iaN de la cabecera de los mensajes ,"# !acilita el proceso. ,in embar(o, este campo N/iaN puede (enerar complejidad en los al(oritmos de deteccin de bucles y se pre!iere usar la cabecera N>a'3or$ardsN para limitar el n@mero de saltos y por tanto los bucles. ; -,e9alizacin de llamada, 5 R #, and 5 R 0#.. ,"# no soporta protocolos de vdeo como .758 y no tiene nin(@n protocolo para control de la con!erencia.

Puertos mnimos para una llamada VoIP

; -,e9alizacin de llamada, 5 R #, and 5 R 0#.. H.454 suporta todo tipo de con!erencia de vdeo y datos. &os procedimientos permiten control de la con!erencia y sincronizacin de los streams de audio y vdeo,

)onferencias de vdeo y datos