{"id":8514,"date":"2016-09-22T14:35:46","date_gmt":"2016-09-22T19:35:46","guid":{"rendered":"http:\/\/www.servervoip.com\/blog\/?p=8514"},"modified":"2019-06-07T09:27:32","modified_gmt":"2019-06-07T14:27:32","slug":"protocolos-de-nivel-de-red-para-voz-por-ip","status":"publish","type":"post","link":"http:\/\/www.servervoip.com\/blog\/protocolos-de-nivel-de-red-para-voz-por-ip\/","title":{"rendered":"Protocolos de nivel de red para voz por IP"},"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

Protocolo H.248\/MEGACO del UIT-T\/IETF <\/strong><\/p>\n

El protocolo H.248\/MEGACO tiene su origen en protocolos anteriores definidos por el Grupo Especial sobre Ingenier\u00eda de Internet (IETF), siendo el MGCP el m\u00e1s famoso de todos. Desde mayo de 1999, el IETF y la Comisi\u00f3n de Estudio 16 del UIT-T se pusieron de acuerdo para preparar una especificaci\u00f3n conjunta del protocolo H.248\/MEGACO la cual adoptar\u00edan las dos partes como especificaci\u00f3n com\u00fan. El presente anexo trata de los principios funcionales del protocolo H.248\/MEGACO, en adelante H.248.<\/p>\n

El protocolo H.248 consiste fundamentalmente en un modelo de conexi\u00f3n que ofrece una pasarela de medios (MG) al controlador de pasarela de medios (MGC); un conjunto de instrucciones que act\u00faan sobre los objetos de ese modelo; y una funci\u00f3n de agrupaci\u00f3n de instrucciones en transacciones.<\/p>\n

El modelo <\/strong><\/p>\n

El protocolo define un modelo de conexi\u00f3n de entidades l\u00f3gicas, u objetos, dentro de la MG que puede ser controlado por el MGC. En el modelo se utilizan dos abstracciones b\u00e1sicas: terminaci\u00f3n y contexto. Una terminaci\u00f3n es capaz de originar y recibir uno o varios medios. Un contexto es una asociaci\u00f3n entre un conjunto de terminaciones que constituyen una misma conferencia. Un contexto con m\u00e1s de dos terminaciones describe las propiedades de puenteo de conferencia.<\/p>\n

Las instrucciones <\/strong><\/p>\n

Un contexto es una asociaci\u00f3n entre varias terminaciones que describen una conferencia. La MGC utiliza la instrucci\u00f3n Add para a\u00f1adir una terminaci\u00f3n a un determinado contexto. Si no se especifica el contexto, la MG deber\u00e1 crear uno nuevo. Mediante la instrucci\u00f3n Subtract se elimina una terminaci\u00f3n de un contexto. Cuando se suprime la \u00faltima terminaci\u00f3n de un contexto, la MG lo destruye impl\u00edcitamente. La instrucci\u00f3n Move sirve para desplazar una terminaci\u00f3n de un contexto a otro. Una misma terminaci\u00f3n s\u00f3lo puede existir en un solo contexto simult\u00e1neamente.<\/p>\n

Transacciones <\/strong><\/p>\n

Las instrucciones entre el MGC y la MG se agrupan en transacciones, las cuales se identifican mediante un identificador de transacci\u00f3n. Una transacci\u00f3n consta de una o varias acciones, cada una de las cuales consta de una serie de instrucciones cuya ejecuci\u00f3n se limita a un solo contexto. Sin embargo, no es necesario especificar el identificador de contexto para una determinada acci\u00f3n cuando \u00e9sta implica una modificaci\u00f3n de una terminaci\u00f3n que no pertenece a un contexto (instrucci\u00f3n Modify), o cuando el MGC solicita a la MG que cree un nuevo contexto (instrucci\u00f3n Add de la primera terminaci\u00f3n).<\/p>\n

Lotes <\/strong><\/p>\n

La especificaci\u00f3n H.248 da ejemplos de casos pr\u00e1cticos de aplicaci\u00f3n del protocolo para el control de ciertas categor\u00edas de MG. Sin embargo, el fundamento que permite la aplicaci\u00f3n universal del protocolo (es decir, que un MGC de un fabricante A pueda controlar una MG de un fabricante B sin que sea necesaria la validaci\u00f3n conjunta de los dos productos) parece residir en la ampliaci\u00f3n de lotes. Los lotes permiten al fabricante de MG incluir en \u00e9sta funciones espec\u00edficas de gesti\u00f3n de sus terminaciones y las MG \u00abanuncian\u00bb estas capacidades al MGC en respuesta a la instrucci\u00f3n Audit H.248.<\/p>\n

Protocolo BICC del UIT-T <\/strong><\/p>\n

En julio de 2001, la UIT anunci\u00f3 la finalizaci\u00f3n del segunda serie de protocolos de control de llamada independiente del portador (BICC), lo que permite la transici\u00f3n de las redes actuales basadas en sistemas p\u00fablicos de conmutaci\u00f3n generales a redes de pr\u00f3xima generaci\u00f3n basadas en servidores. El BICC ha sido dise\u00f1ado utilizando las \u00faltimas t\u00e9cnicas de dise\u00f1o de redes, basadas en una arquitectura servidor, intermediario y pasarela de medios, y permite explotar todos los servicios que se ofrecen a trav\u00e9s de redes de conmutaci\u00f3n de circuitos, ATM e IP, incluidas las redes inal\u00e1mbricas, sin limitar la introducci\u00f3n en el futuro de aplicaciones y servicios innovadores multimodo y multimedios.<\/p>\n

Numeraci\u00f3n electr\u00f3nica (ENUM)<\/strong><\/p>\n

La norma ENUM, descrita en la RFC2916 del IETF, define un protocolo y una arquitectura basada en el sistema de nombres de dominio (DNS) de Internet, que permite obtener una correspondencia entre los n\u00fameros de tel\u00e9fono E.164 y los identificadores de servicio de llamada, con un orden de prioridad (correo electr\u00f3nico, URL del sitio en la Red, direcci\u00f3n SIP de un servidor de telefon\u00eda IP, correo vocal, otros n\u00fameros de tel\u00e9fono, etc.). Por consiguiente, mediante el protocolo ENUM es posible encontrar las diferentes direcciones de un usuario a partir de un simple n\u00famero de tel\u00e9fono. El usuario final puede personalizar la manera en que desea ser localizado a partir de un solo n\u00famero E.164. Resulta f\u00e1cil a\u00f1adir o modificar esa informaci\u00f3n adicional sin cambiar el n\u00famero de acceso empleado. Por lo tanto, el protocolo ENUM se considera una pasarela t\u00e9cnica que garantiza la correspondencia entre Internet y la red de telecomunicaciones conmutada, que permite el interfuncionamiento de las dos.<\/p>\n

El protocolo ENUM y la utilizaci\u00f3n de mecanismos DNS no causan problemas t\u00e9cnicos que impidan el funcionamiento correcto de servicios basados en esta funcionalidad. No obstante, la capacidad de la arquitectura DNS centralizada y jer\u00e1rquica para aceptar peticiones generadas por los servicios que requieren el transporte de informaci\u00f3n en tiempo real y de gran calidad tendr\u00e1 que ser determinada en cada nivel de la arquitectura DNS, en funci\u00f3n de la carga y el nivel de disponibilidad que exija cada servicio. Para encontrar el nombre DNS a partir de un n\u00famero de tel\u00e9fono E.164, la norma RFC2916 requiere ejecutar los siguientes pasos:<\/p>\n

Tomado de: https:\/\/www.itu.int\/ITU-D\/cyb\/publications\/2003\/IP-tel_report-es.pdf<\/p>\n

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

\n

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

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