Captulo III

H.323 - ITU El paraguas H.323, de la ITU, agrupa una serie de normas, mediante las cuales podemos transmitir: Voz Video Datos

Mediante un red LAN o llegado el caso la Internet.

H.323 - ITU H.323 esta formados por los siguientes elementos: Terminales Gateways (GW) Gatekeepers (GK) Multipoint Control Unit (MCU) Proxy H.323

Red H.323

De los cuales, segn la red, complejidad de la misma e interconexin, dispondremos de varios de estos elemento o solamente de los terminales.

Terminales - H.323 El terminal H.323 cumple la funciones de: Control del sistema Transmisin de la informacin Codificacin/decodificacin de audio y video Interfaz de Red Interfaz de Datos Manejo de la sealizacin

Cabe destacar que el terminal puede ser: una PC con el software correspondiente Un dispositivo de hardware dedicado O una mezcla de ambos.

En principio en el terminal se implementarn las siguientes funciones:

Terminales - H.323 Audio Codecs: unidad capaz de soportar la codificacin / decodificacin de los tipos de compresin segn: ITU serie G. ISO GSM

La codificacin / decodificacin de video depender de la aplicacin y para nuestro caso no es objeto de estudio

Terminales - H.323 Unidad de control de Sistema: encargada de implementar las funciones vitales de: Control de llamada (H.225) RAS (H.225) Control y transporte de medios H.245

Finalmente la interfaz de red, es la encargada del: armado y desarmado de paquetes adaptacin a red manejo de canales lgicos trfico UDP/TCP Multiplexacin de servicios

Gateway - H.323 La funcin como indica su nombre es la de proveer interconectividad entre dos redes tan dismiles como la red IP y la red de circuitos conmutados. El Gateway entonces ser necesario, en las redes que posean interconexin con la PSTN, RDSI y dems redes. En las cuales el Gateway cumplir las siguientes funciones:

Gateway - H.323

Gatekeeper - H.323 Sus principales funciones son las de: control de pre-llamada control de admisin conversin de direcciones administracin de zonas H.323.

Si bien el mismo tiene un importante papel en el H.323, el protocolo permite la conexin de dos terminales en forma extremo a extremo, prescindiendo del Gatekeeper.

Por lo tanto podemos decir que su presencia o no en la red depender principalmente de la envergadura de la misma. Su implemetacin tambin depender de las dimensiones y cantidad de nodos, pudiendo ser esta: Hardware especifico Software dentro del Terminal Software dentro del Gateway.

Gatekeeper - H.323

Multipoint Controller Unit H.323 Su funcin principal es la de soportar conferencias multipunto, tanto sean estas de voz, video o datos. En general el MCU se implementa en software integrandolo segn el caso en: Terminal Gateway Gatekeeper

El mismo esta compuesto por dos funciones principales: MP (Multipoint Processor) MC (Multipoint Controller)

El MP, se encarga del manejo tanto de voz, datos y video hacia los distintos destinos. El MC, es el encargado de gestionar los recursos y capacidades de cada punto de servicios.

Multipoint Controller Unit H.323

Proxy H.323 Al igual que el proxy standard, el Proxy H.323, brinda las siguientes funciones: Seguridad, concentrando el trfico H.323 Manejo del IP precedence de manera de lograr QOS. Manejo de nodos H.323 con direccionamiento privado.

Dicho elemento se encuentra generalmente en redes privadas con enlaces WAN y gran cantidad de terminales.

Sealizacin RAS Registration, Admission & Status (RAS), tal como su nombre lo indica, estas son las funciones principales y que forman parte del denominado control de pre-llamada. El RAS se utiliza en el dialogo con el Gatekeeper, dentro de una zona o entre zonas. Como podemos observar el RAS utliza el modo no seguro (UDP) para la conexin.

RAS - H.225.0 Las funciones del RAS, son: Registro Admisin Cambios en el Ancho de Banda Estado Procedimiento de liberacin

Dado que RAS utiliza UDP, se debe tener en cuenta los TimeOut y llegado el caso con la seal RIP, resetear los mismos.

La mensajera H.225.0 utiliza la sintaxis ASN.1. Los comandos se agrupan por funciones y segn la accin. A continuacin entraremos en detalle en cada una de las funcionalidades del RAS.

RAS - Localizacin del GK Los terminales deben registrarse en el Gatekeeper para lo cual resulta indispensable la conexin con el mismo, la cual puede ser: Esttica, mediante la direccin IP del Gatekeeper. Dinmica, mediante la funcin de localizacin del Gatekeeper. Es muy comn por temas administrativos, evitar las definiciones estticas de direcciones IP, por lo cual dicha funcin es bastante empleada. Adems de brindar flexibilidad, recordemos que el Gatekeeper no es un elemento obligatorio dentro del H.323. El autodiscovery se realiza mediante UDP a la direccin 224.0.1.41 utilizando para el mismo el puerto 1718.

RAS - Localizacin del GK Mensajes de localizacin: GRQ (Gatekeeper request), es utilizado por el terminal para localizar el Gatekeeper, mediante multidifusin. GCF(Gatekeeper confirm), respuesta del GK, se devuelve direccin del canal RAS GRJ (Gatekeeper reject), el GK no acepta el registro.

En el GCF, en algunas ocasiones se puede pasar al terminal la direccin IP de gatekeepers alternativos.

RAS - Registro Dado que el Gatekeeper cumple la funcin de manejo de reas, es imprescindible para el GK conocer los nodos que de el dependen. La manera de brindar informacin al Gatekeeper, es mediante el proceso indispensable de registro de los terminales. El registro permite al Gatekeeper conocer no solo la direccin IP del elemento, sino tambin su alias, el cual ser del tipo: pcvoz@andescap.cl El registro se realiza en forma directa al canal RAS, dado que se supone que el terminal ya lo localiz previamente. La operacin se subdivide en: registracin desregistrarse

RAS - Registro Mensajes de registro: Registration request (RRQ) Registration Confirmation (RCF) Registration Rejection (RRJ)

Mensajes de baja de registro: Unregister Request (URQ) Unregister Confirm (UCF) Unregister Reject (URJ)

RAS - Localizacin de Terminal El mensaje es enviado al Gatekeeper con el nico dato que se tiene del terminal, en este caso puede ser: Alias. Pc1@andescap.cl Nmero E.164

Mensajes: Locate Request (LRQ) Locate Confirm (LCF) Locate Reject (LRJ)

El gatekeeper realizar una bsqueda en su tabla interna tratando de resolver el alias. La funcin especifica para dicha tarea es Locate, por lo tanto tendremos:

LRQ, permite obtener la resolucin de ms de una direccin E.164. LCF, la respuesta depender del tipo de conexin que se este usando.

RAS - Localizacin de Terminal LCF, IP del Gatekeeper, es porque se utiliza una conexin del tipo GKRCS LCF, IP del terminal, es porque se utiliza un conexin directa entre terminales.

RAS - Admisin de Terminal Los terminales deben ser admitidos por el Gatekeeper, el cual puede: aceptar la admisin rechazar la admisin

Mensajes: Admission Request (ARQ) Admission Confirm (ACF) Admission Reject (ARJ)

Una de las funciones de la admisin es la de regular el ancho de banda necesario para la conexin.

El ARQ es el paso previo a iniciar un llamado. Si el gatekeeper admite la conexin es porque dispone de capacidad como para manejarla y le entrega al Terminal el IP del Gateway o Gatekeeper de terminacin.

RAS - Estado de la conexin El gatekeeper debe obtener informacin sobre el estado de la conexin, dado que una vez iniciado el dilogo, el H225.0 no interviene. Dicho estado se puede obtener mediante dos tcnicas Pooling Reportes del terminal

Mensajes: Information Request (IRQ) Information Request Response (IRR)

Mientras el IRQ parte del Gatekeeper hacia el terminal, a intervalos regulares. IRR lo hace en sentido inverso, entregando al Gatekeeper informacin del estado del enlace.

RAS - Control de Ancho de Banda Si bien durante el proceso de admisin, el gatekeeper verifica la disponibilidad de ancho de banda y en base a esta admite o no la conexin, en algunos casos es necesario realizar modificaciones en el ancho de banda una vez establecida la conexin. Mensajes: Bandwith Request (BRQ) Bandwith Confirmation (BCF) Bandwith Reject (BRJ)

Los rechazos pueden deberse a que no se encuentre disponible el ancho de banda solicitado. Uno de los motivos tpicos de requerimiento de cambio de ancho de banda es el cambio de codecs.

H.225.0

H.225 - Sealizacin de control de llamada El H.225 utiliza para el control de llamada los mensajes basados en la norma ITU Q.931. La conexin se realiza mediante TCP y se emplea el puerto 1720. El canal de sealizacin se puede manejar de dos maneras: Directo entre end points Enrutado al Gatekeeper

En el modo directo solamente el trfico H.225.0 llega al Gatekeeper.

H.225 - Sealizacin de control de llamada Mientras que el en modo enrutado, tambin conocido como GKRCS, la mensajera H.225 es manejada por el Gatekeeper. Mientras Q.931, brinda las funciones ms utilizadas, Q.932 permite el manejo de servicios adicionales. Tanto Q.931 y Q.932 utilizan mensajes del tipo ASN.1, lo cual dificulta su interpretacin por parte del usuario, uno de los puntos a favor de SIP, segn veremos ms adelante.

H.225 - Sealizacin de control de llamada Mensajes: SETUP, el mismo avisa hacia delante el intento de establecer un llamado, es generado por el extremo llamante hacia el end point o GK segn el caso. CALL PROCEEDING, es un mensaje hacia atrs, el cual da aviso al extremo llamante que se ha iniciado el proceso de llamada. ALERTING, mensaje hacia atrs, donde se avisa que el sonido de llamada se ha iniciado. CONNECT, mensaje hacia atrs, donde el extremo llamado avisa al extremo llamante que se acepta la llamada. RELEASE, es un mensaje generado por cualquiera de los extremos, en particular el que finalice la llamada, y

H.225 - Sealizacin de control de llamadaavisa al extremo opuesto la finalizacin de la misma. FACILITY, es un mensaje hacia delante que indica si la llamada se cursa o no a travs del Gatekeeper.

H.225 - Q.931

H.245 - Control Protocol Su funcin es la de establecer y controlar los canales lgicos para los servicios de: Voz Datos Video

y de requerimientos: Simtricos Asimtricos

El H.245 se encarga tambin del intercambio de capacidades, tanto sean conexiones: unidireccionales bidireccionales

El H.245 interviene en la negociacin de codecs La mensajera del H.245 es ASN.1 La conexin H.245 puede ser: Directa Va Gatekeeper

H.245 - Control Protocol Mensajes: Capability Exchange: se negocian los codecs, la norma soporta los Codecs tipo ITU, ISO y GSM. Round trip Delay: procedimiento mediante el cual se establece el retardo de la conexin.

H.245 - Control Protocol Logical Channel Signalling: apertura y cierra de canales lgicos. Master/Slave Termination: procedimiento en el cual se fija un extremo como maestro y el otro como esclavo.

RTP/CRTP/RTCP - Transporte RTP es el protocolo de transporte en tiempo real, sus principales funciones son: Identificar la carga til temporizacin del trfico secuenciamiento sincronizacin

RTP se transporta sobre UDP y su estructura se muestra a continuacin:

RTP es el protocolo ideal para el transporte sobre redes IP de trfico como voz y video, dado su alta sensibilidad al retardo y las variaciones del retardo.

RTP - Real-Time Transport Protocol Campos del RTP: V: versin del protocolo. Padding: indica si la carga contiene bits de relleno o no. X extension: duplica la extensin del header CC CSRC Count: 4 bits que indican la cantidad de identificadores CSRC que contiene el header M marker: equivale al MF de IP PT payload type: identificador de tipo de carga (7 bits) Secuence Number: contador que me permite identificar el orden de los paquetes RTP. TimeStamp: utiliza un reloj como base de tiempo y el valor indica el desfasaje entre el reloj y el primer byte del RTP.

RTP - Real-Time Transport Protocol SSRC: la fuente de sincronismo es identificada y el nombre es enviado en 32 bits. CSRC: se emplean en la multiplexacin, cada uno con 32 bits y se puede tener hasta 16 tems. Luego el campo de datos contendr el video o la voz comprimida a ser transportada en tiempo real. Si recordamos, que a su vez el RTP se monta en UDP y este a su vez en IP, tendremos:

RTP - Real-Time Transport Protocol Si analizamos la eficiencia de dicha configuracin tendremos: Header: 20 Bytes, IP 8 Bytes, UDP 12 Bytes, RTP 40 Bytes, total Header

Lo cual nos da una eficiencia muy baja, del orden del 33% Resulta ilgico emplear 40 bytes de encabezado para transportar solamente 20 bytes de informacin til. La solucin aparece con la compresin de encabezado, de manera de aumentar la eficiencia, disminuir los retardos y dems.

Datos: 20 Bytes, salida de la paquetizacin.

CRTP CRTP, compressed Real Time protocol. Logra optimizar el tamao del header, llevandolo a 2-4 bytes. Lo cual representa un cambio fundamental para la utilizacin de interfaces lentas y una sustancial reduccin de velocidad de la misma, pasando de: 24 Kb/s (IP+UDP+RTP) 9,6 Kb/s (CRTP)

RTCP - Real-Time Transport Control Protocol RTCP enva a todos los participantes en forma peridica, paquetes de control, mediante los cuales se monitorea, identifica y controla la entrega de datos. Dichos paquetes se multiplexan en UDP con el resto del trfico, mediante el uso de distintos puertos, por convencin: RTP acta en puerto par RTCP en impar ms alto

RTCP es el encargado de proveer informacin sobre la calidad del transporte de informacin. Las fuentes RTP se identifican mediante el llamado nombre cannico (CNAME) Dado que RTCP aporta datos estadsticos sobre las conexiones RTP, esta informacin debe reducirse a lo estrictamente necesario, de manera de no producir congestin.

RTCP - Real-Time Transport Control Protocol Paquetes RTCP: SR sender report: transmisin y recepcin de estadsticas desde los participantes. RR receive report: recepcin de estadsticas desde participantes que no son fuentes activas SDES source description: se enva el CNAME

BYE: indica fin de participacin APP: aplicaciones experimentales.

H.323 - Llamado mediante gatekeeper

H.323 - Llamado a travs del gatekeeper

SIP - Session Initiation Protocol SIP o protocolo de inicio de sesin, propone el establecimiento mantenimiento finalizacin

SIP es parte del conjunto de normas del IETF, orientadas a VoIP. SIP (RFC 2543) RSVP (RFC 2205) RTP/RTCP (RFC 1889) RTSP (RFC 2326) SAP (RFC SDP (RFC 2327)

de sesiones multimedia, tanto sean estas de voz, video o datos. SIP es la propuesta del IETF, la cual rivaliza con la norma H.323 SIP esta orientado a llamadas punto a punto y multipunto.

SIP es un protocolo que surge de internet, empleando mensajes de texto, direcciones URL y dems.

SIP - Session Initiation Protocol Las redes SIP constan de 2 elementos bsicos: UA user agent NS network Server

Y los servidores de red, estn conformados por: Proxy server Redirect server Registrars servers Location servers

Dividiendo a la red en dos, un elemento en el terminal del cliente y otro en la red. A su vez estos se pueden subdividir en: UAC User Agent Client UAS User Agent Server

Empezaremos con la descripcin de cada uno, su funcin en la red y posible localizacin.

UA - User Agents Los UA, o Agentes de Usuario, son aplicaciones presentes en los puntos extremos, los mismos pueden ser implementados en software, hardware o una mezcla de ambos.

UA - User Agents UAS: unidad encargada de recibir las peticiones, en el usuario llamado.

UAC: es el organismo encargado de iniciar la transaccin SIP, del usuario llamante.

Proxy Server El Proxy Server se caracteriza por poseer ambas funciones, la de cliente y servidor a la vez, dado que en muchos casos recibe trafico y luego debe iniciarlo hacia otro destino. El Proxy server es una de la s partes esenciales en la arquitectura SIP de cierto volumen. Su implementacin varia desde Software a Hardware dedicado. LA IETF recomienda en la RFC 2543, la utilizacin de la siguiente sintaxis en el nombre de los proxy servers: sip.andescap.cl

El Proxy Server puede mantener transacciones tanto sobre UDP como TCP, permitiendo la sesin con los User Agents.

Redirect Server El servidor de redireccionamiento cumple la funcin de mantener actualizado la base de datos con la localizacin de cada usuario. Esto permite que el usuario se mueva a lo largo de la red e inclusive pasar a distintas redes y en el momento deseado poder redireccionar la llamada a la ultima direccin informada. El Servicio de redirect apunta a las Funcionalidades a Futuro, en la cual se integran las redes y se utiliza SIP como protocolo general entre ellas. A diferencia del Proxy server, el servidor de redireccin, no acepta llamadas, ni procesa peticiones SIP, se limita a entregar al cliente la direccin a donde redireccionar la peticin SIP.

Registrars Servers / Location Server Los Registrars Servers, cumplen las siguientes funciones: permiten a los usuarios registrar su presencia el servidor maneja los pedidos de registro ofrece servicios de localizacin

En general forman parte de los proxy server o redirect server

Direccionamiento SIP Direccionamiento en entornos SIP: en los end points se utiliza el URL SIP, con el formato: usuario @ host El campo usuario puede estar conformado por el nombre o nmero de telfono. El campo host, puede contener el nombre del dominio o su direccin IP. Para el caso de los servidores, como ya vimos se recomienda nombrarlos: sip.andescap.cl

fede@andescap.cl 37142871@andescap.cl fede@17.35.123.245

Hallazgo del Proxy Server El terminal SIP, debe establecer contacto con el proxy server,para lo cual, segn la recomendacin, este se inicia como UDP. Nos encontramos ante dos posibles escenarios: El terminal posee la direccin IP del Proxy Server, cargada en forma esttica. El terminal desconoce la direccin del Proxy Server.

En el primer caso, la sesin se inicia directamente, sin otro particular. En el segundo caso es necesario descubrir la direccin IP, para lo cual se procede de la siguiente manera: envo UDP al puerto 5060 se consulta con el DNS, para obtener el IP del Host.

Transaccin SIP En caso de no obtener resultados mediante el UDP, se pasa a TCP.

Una vez obtenido la direccin del Proxy Server, se puede iniciar la transaccin SIP. La transaccin puede realizarse tanto mediante UDP como TCP, si bien lo standard es utilizar UDP como primer medida.

En transacciones UDP, se utiliza la direccin del header de la peticin En TCP se mantiene la conexin mientras dure la transaccin.

Transacciones SIP Mensajes SIP: Request (peticiones) Response (respuestas)

Denominando peticiones a los mensajes iniciados por los clientes y respuestas a los que enva el servidor. La estructura del mensaje es idntica al HTTP, utilizando campos con texto, lo cual facilita su interpretacin.

El header de los mensajes se los agrupa en 4 tipos, segn su aplicacin, los cuales aparecen en la siguiente tabla:

SIP Mensajes

De los cuales podemos rescatar los campos ms utilizados, como ser: To, From, Via, Call-ID, Content Type & Length, Expires, Route, etc. Algunos de los cuales explicaremos a continuacin.

SIP Mensajes Campos del encabezado: To: receptor de la peticin From: quien enva la peticin Expires: fecha y hora en que el mensaje expira. Content Length: tamao en bytes del mensaje. Via: indica ruta tomada por el mensaje

Call-ID: identificador de usuario Cseq: se incrementa el numero de manera de diferenciar los mensajes del mismo Call-ID

SIP - Request Message Mediante este tipo de mensaje los User Agents y el Proxy server pueden localizar, invitar y administrar una llamada. Existen seis mtodos para el INVITE los cuales son: request BYE ACK OPTIONS CANCEL REGISTER

INVITE: el usuario o servicio es invitado a participar de una sesin. ACK: es la tpica respuesta al invite. OPTIONS: se consultan las posibilidades disponibles por agentes y servidores. BYE: se emplea como preaviso de liberacin de la llamada. CANCEL: se emplea para cancelar peticiones en curso.

SIP - Request Message REGISTER: se el mtodo empleado por los user agents para registrar informacin til, correspondiente a la localizacin en los servidores SIP.

SIP - Response Message Las respuestas se agrupan en dos tipos: provisionales, las cuales indican a la parte emisora que la peticin esta en curso. Finales, las cuales indican la finalizacin de la peticin y el estado resultante.

1XX2XX 3XX 4XX 5XX 6XX

InformationalSuccess Redirection Client error Server Error Global Error

A fines didcticos, podemos agrupar las mismas en:

SIP - Response Message Siendo la tabla completa:INFORMATIONAL 100 Trying 180 Ringing 181 Call Is Being Forwarded 182 Queued SUCCESS 200 OK REDIRECTION 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 303 See Other 305 Use Proxy 380 Alternative Service CLIENT ERROR 400 Bad Request 401 Unauthorized 402 Payment Required 403 Forbidden 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 410 Gone 411 Length Required 413 Request Message Body Too Large 414 Request-URI Too Large 415 Unsupported Media Type 420 Bad Extension 480 Temporarily Not Available 481 Transaction Does Not Exist 482 Loop Detected 483 Too Many Hops 484 Address Incomplete 485 Ambiguous 486 Busy Here SERVER ERROR 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 504 Gateway Timeout 505 SIP Version Not Supported GLOBAL FAILURE 600 Busy Everywhere 603 Decline 604 Does Not Exist Anywhere 606 Not Acceptable

SIP - Llamado mediante Proxy Server

SIP - Llamado mediante Redirect Server

H.323 vs SIP La comparacin entre ambos se puede hacer desde varios aspectos, como ser: Performance Compatibilidad Requerimientos del equipo Anlisis, Traceo y Debbugin Funcionalidades Mercado

Segn la performance, podemos decir que: H.323, requiere mayor cantidad de mensajes entre entidades SIP reduce substancialmente el trafico de control entre entidades As como tambin la drstica reduccin en pasos para el establecimiento de una conexin entre SIP y H.323.

Tratando en todos ellos de obtener parmetros equivalentes que permitan una real valoracin y comparacin entre ambos.

H.323 vs SIP Segn la compatibilidad, si bien no hay compatibilidad entre ambos, se habla de interoperabilidad, lo cual requiere la implementacin de ambos. La mayora de los productos H.323 incorporan SIP Algunos productos SIP no soportan H.323 esto se justifica con la siguiente comparacin.

Segn requerimientos al equipo: H.323, exige un cdigo de mayor tamao, mayor potencia en el CPU, mayor capacidad de memoria. SIP, reduce sensiblemente el cdigo, optimizando el CPU y minimizando la capacidad de memoria.

H.323 vs SIP Desde el punto de vista del anlisis, traceo y Debbugin, podemos decir que: H.323 utiliza el ASN.1, haciendo menos entendible al humano la mensajera y complicando el instrumental necesario. SIP, emplea campos de texto, permitiendo no solo una mejor comprensin, sino tambin herramientas ms sencillas.

Segn las funcionalidades soportadas: Ambos soportan gran cantidad de funcionalidades, siendo equiparables en este rubro.

Todos estas razones y algunas ms que escapan a nuestro anlisis, permiten justificar una tendencia en los mercados, en la cual se observa:

H.323 vs SIP

De lo visto podemos afirmar que a futuro, SIP tiende a imponerse a H.323, y por el momento hay gran interoperabilidad en las plataformas existentes.

H.323 vs SIP La brecha entre SIP y H.323, se reduce con las distintas versiones del H.323. Una de las mayores diferencias, lo que respecta a la complejidad de H.323 se intenta solucionar con el modo Fast Call, el cual empieza a ser comparable con SIP.

MGCP - Media Gateway Control Protocol El MGCP es la propuesta del IETF, el cual surge de la implemetacin conjunta de otros dos protocolos: SGCP + IPDC = MGCP Es el protocolo por excelencia para el manejo y control de llamadas entre el Gateway y las redes externas (PSTN, ISDN, GSM, etc) Por lo tanto su implementacin es necesaria solo si se desea conectividad entre VoIP y redes externas. Desde el punto de vista funcional, debemos separar al Gateway en dos bloques funcionales: MGC, media gateway controller MG, media gateway

MGCP - Media Gateway Control Protocol MGC ser la unidad encargada de la conversin de sealizacin necesaria entre las dos redes, as como tambin de manejar los MG a su cargo, dado que un MGC puede controlar ms de un MG. En el MG se dispondr de todo el hardware necesario para realizar la: compresin/descompresin adaptacin conversin TDM / IP y viceversa.

El MGC recibe comnmente en el mercado el nombre de SoftSwitch Mientras que al MG, dependiendo el uso y volumen de conexiones se lo puede encontrar como: Access gateway Residential gateway

MGCP - comandos Comandos MGCP: CreateConnection. ModifyConnection. DeleteConnection. NotificationRequest. Notify. AuditEndpoint. AuditConnection. RestartInProgress. Call Agent (MGC) Los comandos estn compuestos por un encabezado de comando y una descripcin de sesin (opcional) Dado que los mensajes se envan mediante UDP, estos pueden perderse, para lo cual resulta indispensable el campo identificador de transaccin, el cual es un numero dentro del rango 1 a 999.999.999

MGCP en conexin POTS sobre IP

Gateway - Softswitch

MGCP - SIP, internetworking

Evolucin a MEGACO / H.248 La estructura distribuida en MG, MGC y SG, fue planteada originalmente por ETSI (Typhon). Estructura sobre la cual tanto IETF e ITU, realizaron trabajos sobre esta base. IETF, propuso el MGCP en su RFC 2705, el cual evoluciona luego en lo que hoy conocemos como MEGACO - RFC3015. Mientras la ITU, presenta en el mercado el H.248. Pero esta vez el trabajo en conjunto de ambos, da como resultado lo que en el mercado se lo conoce como:

MEGACO / H.248

Fax sobre IP El inconveniente en la transmisin de fax sobre IP, se presenta con: compresin cancelacin de eco retardos y dems

El servicio de FAX via la PSTN fue definido por la ITU, en las normas: T.30 T.4

Haciendo imposible el envo de fax como si se tratara de una conversacin.

T.30 define el hadshake, mensajes, velocidades y dems.

Fax sobre IP T.4 se ocupa de todo lo referente al contenido de la hoja a enviar, formato, resolucin, escaneo, etc. La solucin de Fax sobre IP se brinda mediante dos modalidades: Transmisin transparente Decodificacin y reenvo.

Fax sobre IP Transmisin transparente El Media Gateway detecta el tono de envo del fax. Se avisa al MGC de la intencin de envo Este enva un cambio en la conexin a ambos MGs se pasa a G.711 se anula la cancelacin de eco

Decodificacin y Reenvo: El Media Gateway detecta el tono de envo del fax. Nuevamente se cuenta con dos modalidades: Tiempo real (T.38) Extraccin y reenvo

Permitiendo enviar la seal lo ms similar posible a la original.

Fax sobre IP Extraccin y reenvo: Se emula en forma local (MG) el fax remoto, implementando T.30 y T.4 Una vez obtenida la informacin, se enva el fax via E-mail, en forma de attach hacia el Media Gateway remoto Luego el MG emular el terminal T.30 - T.4 enviando finalmente el fax a destino.

Tiempo Real (T.38) modalidad elegida por H.323 La seal analgica recibida es demodulada en el MG Se arman paquetes segn la informacin a enviar indicadores: control datos: informacin

Dichos paquetes se envan segn: UDP --> UDPTL TCP --> directa

Fax sobre IP

DTMF sobre IP La utilizacin de tonos DTMF dentro de la conversacin es cada vez mayor, como ejemplos: IVR accesos codificados consulta en bancos recoleccin de mensajes etc. Al igual que la seal de fax, los tonos DTMF se vuelven indetectables ante los procesos de compresin/descompresin. Original Comprimido Lo cual requiere un tratamiento especial de los mismos. Para lo cual se presentan dos alternativas: RTP/G.711 RTP/RFC 2833

Compresin del DTMF

DTMF sobre IP RTP/G.711 El Media Gateway, cambia el codec a G.711, de manera de evitar la deformacin de dichos pulsos. La informacin se enva mediante RTP Luego en el otro extremo sern convertidos en forma transparente.

RTP/RFC 2833 El Media Gateway detecta y decodifica en forma local los tonos. Los mismos son insertados en el RTP, pero no como tono digitalizados, sino como informacin decodificada. Se enva bsicamente, el cdigo detectado, duracin del mismo y nivel de recepcin.

DTMF sobre IP La informacin recibida en el extremo, es decodificada y enviada al generador de tonos El mismo se encargar de generarlos e intercalarlo con el trafico de voz, de manera de lograr una emulacin transparente hacia el usuario.

DTMF sobre RTP (segn RFC 2833)