{"id":8034,"date":"2016-09-09T13:53:30","date_gmt":"2016-09-09T18:53:30","guid":{"rendered":"http:\/\/www.servervoip.com\/blog\/?p=8034"},"modified":"2019-06-07T11:33:53","modified_gmt":"2019-06-07T16:33:53","slug":"proceso-de-llamada-en-h-323","status":"publish","type":"post","link":"http:\/\/www.servervoip.com\/blog\/proceso-de-llamada-en-h-323\/","title":{"rendered":"Proceso de llamada en h.323"},"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

A continuaci\u00f3n se muestra el proceso que se debe de seguir para la conexi\u00f3n de dos terminales (desde que una terminal busca a su respectivo GK hasta la finalizaci\u00f3n de la llamada) asumiendo que existe un GK dentro de una zona H.323. <\/p>\n

Etapa 1.- Descubrimiento del gatekeeper. <\/p>\n

\u2022\tLa terminal env\u00eda un mensaje multicast (a varios gatekeepers seleccionados entre varios) llamado Gatekeeper Request para preguntar por su respectivo GK.
\n\u2022\tUno o m\u00e1s gatekeepers responden con un Gatekeeper Confirm que es una confirmaci\u00f3n donde indican su disposici\u00f3n a ser el gatekeeper primario de dicha terminal junto con su direcci\u00f3n de transporte de su respectivo canal RAS.
\n\u2022\tCuando la terminal recibe su Gatekeeper Confirm elige cu\u00e1l es su GK y se suscribir\u00e1 con \u00e9l, v\u00e9ase figura 2.6. En caso de no recibir ninguna confirmaci\u00f3n se retransmite el Gatekeeper Request tras un intervalo determinado de tiempo (en caso de no aceptar el gatekeeper la petici\u00f3n de suscripci\u00f3n enviar\u00e1 un Gatekeeper Reject rechaz\u00e1ndolo). <\/p>\n

\"Etapa

Etapa 1 del proceso de llamada<\/p><\/div>\n

Etapa 2.- Registro de la terminal <\/p>\n

\u2022\tUna vez que una terminal se suscribe a un GK se ha unido a una zona.
\n\u2022\tAhora se procede al registro, para esto se env\u00eda una petici\u00f3n de registro llamado Registration Request al GK a trav\u00e9s de su direcci\u00f3n de transporte del canal RAS (direcci\u00f3n IP y puerto).
\n\u2022\tLa terminal recibir\u00e1 un mensaje de confirmaci\u00f3n, ya sea aceptando su registro de llamado Registration Confirmation o deneg\u00e1ndolo llamado Registration Reject.
\n\u2022\tCon el registro el GK asigna un \u201calias\u201d s\u00f3lo a una direcci\u00f3n de transporte.
\n\u2022\tSe puede dar el caso de que una terminal quiera cancelar el registro, y para \u00e9sto env\u00eda un mensaje de cancelaci\u00f3n al GK, este \u00faltimo contestar\u00e1 con una confirmaci\u00f3n y viceversa. <\/p>\n

Etapa 3.- Localizaci\u00f3n de la terminal <\/p>\n

\u2022\tPara obtener la informaci\u00f3n necesaria para establecer contacto con una terminal, se env\u00eda un mensaje Location Request (petici\u00f3n de localizaci\u00f3n) con el \u201calias\u201d de la terminal que se busca.
\n\u2022\tEl respectivo GK donde est\u00e1 registrada dicha terminal responder\u00e1 al que mando la petici\u00f3n (ya sea un gatekeeper o terminal) con un mensaje llamado Location Confirmation (confirmaci\u00f3n de localizaci\u00f3n) con la informaci\u00f3n solicitada. Si el GK no tiene registrado el \u201calias\u201d buscado contestar\u00e1 con un mensaje llamado Location Reject (renuncia de localizaci\u00f3n) <\/p>\n

Etapa 4.- Establecimiento de la llamada <\/p>\n

\u2022\tEn cuanto el gatekeeper responde con un Location Confirmation, la terminal llamante establecer\u00e1 una conexi\u00f3n TCP con el terminal llamado utilizando la informaci\u00f3n (direcci\u00f3n IP y puerto) recibida del gatekeeper a trav\u00e9s del mensaje Location Confirmation.
\n\u2022\tLa terminal llamante en cuanto recibe la conexi\u00f3n TCP se conectar\u00e1 con su GK a trav\u00e9s del canal RAS solicitando permiso para contestar, de obtener el permiso, la terminal llamante aceptar\u00e1 la conexi\u00f3n y a trav\u00e9s del canal H.225.0 enviar\u00e1 la direcci\u00f3n IP y puerto donde establecer el canal H.245(a trav\u00e9s de una conexi\u00f3n TCP) para la negociaci\u00f3n de par\u00e1metros y control de la comunicaci\u00f3n. <\/p>\n

\u2022El canal RAS es utilizado tambi\u00e9n para transmisi\u00f3n de mensajes de admisi\u00f3n, cambios de ancho de banda y estado, estos mensajes son intercambiados entre la terminal y el gatekeeper para llevar un buen control.
\n\u2022\tAntes de que inicie la llamada, el mensaje Admisions Request especifica el ancho de banda requerido, en este caso el gatekeeper puede reducirlo enviando un mensaje Admisions Confirm con su medida de ancho de banda.
\n\u2022\tDurante el transcurso de la llamada si se desea cambiar el ancho de banda se usa el mensaje Bandwidth Change Request, este \u00faltimo puede ser enviado por el gatekeeper o la terminal. <\/p>\n

Etapa 5.- Intercambio y capacidades <\/p>\n

\u2022\tSelecciona un MCU como maestro para administrar las conferencias. Una vez que la llamada esta iniciada H.245 es el encargado del cambio y de las negociaciones de los par\u00e1metros (codificador a utilizar, puertos, n\u00famero de muestras por trama, etc.)
\n\u2022\tUna vez que se han negociado adecuadamente los par\u00e1metros se abren o cierran nuevos canales l\u00f3gicos para la transmisi\u00f3n de medios (audio, video y datos)
\n\u2022\tPara llevar un control de conferencias, H.245 desarrolla un modelo de env\u00edo de datos entre las terminales. Una vez obtenida esta informaci\u00f3n, la conexi\u00f3n puede ser finalizada ya que no ser\u00e1 necesario intercambiar m\u00e1s par\u00e1metros a trav\u00e9s de este canal. <\/p>\n

Etapa 6.- Intercambio de informaci\u00f3n audiovisual <\/p>\n

\u2022\tAqu\u00ed se tiene como objetivo llevar un control de calidad de los flujos de informaci\u00f3n recibida por el otro extremo de la comunicaci\u00f3n.
\n\u2022\tAmbas terminales establecen canales de informaci\u00f3n para el transporte de medios a trav\u00e9s de RTP\/UDP\/IP y canales de control para los canales de realimentaci\u00f3n a trav\u00e9s de RTCP\/UDP\/IP. <\/p>\n

Etapa 7.- Terminaci\u00f3n de la llamada <\/p>\n

\u2022\tLas terminales H.323 deben de enviar las primitivas de finalizaci\u00f3n de llamada a trav\u00e9s del canal H.245 para informarse quien finalizar\u00e1 con \u00e9l envi\u00f3 de la primitiva y con esto provocar el cierre del canal H.245. <\/p>\n

\u2022 Una vez hecho lo anterior se le debe informar al GK mediante un env\u00edo de mensaje por el canal RAS llamado Disengage Request, as\u00ed se le permite al GK liberar recursos y atender otras terminales para comenzar con el mismo proceso ya mencionado, en la figura 2.7 se puede ver el proceso general de una llamada con H.323 <\/p>\n

Tomado de:
\nP\u00e9rez, E. (2014). Utilizaci\u00f3n de la tecnolog\u00eda voz sobre IP dentro de una red (tesis de pregrado). Universidad Nacional Aut\u00f3noma de M\u00e9xico, M\u00e9xico, D.F.
\nFuente:
\nhttp:\/\/www.ptolomeo.unam.mx:8080\/xmlui\/bitstream\/handle\/132.248.52.100\/5779\/tesis.pdf?sequence=1<\/p>\n

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

\n

DataCenter VoIP<\/h2>\n

Los edificios que alojan a los servidores en Europa y Estados Unidos son los centros de datos m\u00e1s ecol\u00f3gicos y fueron construidos como idea de almac\u00e9n de datos. La ubicaci\u00f3n estrat\u00e9gica en Europa central y en Estados Unidos son las ventajas principales.<\/p>\n

Los Data Centers est\u00e1n perfectamente situados para garantizar conexiones r\u00e1pidas a todos los territorios de Europa y Am\u00e9rica para que todos los clientes se beneficien de la mejor calidad en el servicio brindado. Por otra parte, el edificio que est\u00e1 situado en Europa se encuentra en una de las zonas m\u00e1s ricas de agua subterr\u00e1nea, lo que abre la posibilidad a ServerVoIP de realizar un innovador, ecol\u00f3gico y \u00fanico sistema de refrigeraci\u00f3n de forma natural.<\/p>\n

\"datacenter<\/a>
\n