Universidad de Buenos Aires Facultad de Ingeniería - Departamento de Electrónica Seminario: Aspectos Avanzados de Redes de Computadoras- 66.48/66.66 2º Cuatrimestre 2006 Trabajo Práctico Nº3 Monografía Protocolo MGCP Alumnos: Luis Alberto Hevia 74158 Juan Pablo Poujade 78737 Tomás Hernán Peyré 82371 Profesores: Ing. Marcelo Utard Ing. Pablo Ronco Sr. Javier Bozzuto
MGCP Introducción Los Media Gateways Control Protocols surgen de la necesidad de intercomunicar las redes IP con los servicios de telefonía tradicionales y de poder soportar un despliegue a gran escala de sistemas de VoIP. En telefonía tradicional, la señalización (D-channel) y la voz (B-Channel) son transportadas independientemente. En las redes de VoIP, van a ser necesarios dos tipos de Gateways, los Gateways de señalización y los Gateways de voz/multimedia. Los de señalización van a ser los encargados de traducir la información del D-Channel a señalización VoIP, como SIP o H.323. Y los Media Gateways, van a ser los encargados de adaptar voz y video entre el B-Channel y, por ejemplo, paquetes RTP. Los Media Gateways Controller, Call Agents o Softswitch van a ser los encargados de controlar los Media Gateways, haciendo uso de los protocolos de control de Gateways. Los MGCP posibilitan el control del flujo de datos en forma remota, durante su transito entre la red IP y la red de telefonía tradicional. Figura 1 Media Gateway Controller, Call Agent o Softswitch Los Media Gateways Controllers realizan principalmente las siguientes funciones: Control de llamada. Identificación del tráfico H.323. Limitación del tráfico H.323 sobre la LAN y WAN. Generación de archivos CDR (Call Details Records) para la facturación. Inserta calidad de servicio (QoS) e implementa políticas de seguridad. Página 2 de 20
Se usa una estructura master/slave, donde el Media Gateway Controller es el master server y uno o más Media Gateways son slave clients, a diferencia de SIP o H.323 donde la relación entre las entidades es peer-to-peer. Otra diferencia es que SIP y H.323 son protocolos de señalización que se encargan de establecer y controlar las llamadas, mientras que los protocolos MGCP definen como va a ser el flujo de datos y establecen el ruteo o camino entre la red IP y las demás redes. Beneficios El desdoblamiento de la estructura de los gateways reduce los problemas de manejo/supervisión (management) y expansión. Manejo: Los media gateways pueden ser pequeños y de bajo costo, requiriendo una configuración y management mínimo. Los Media Gateways Controllers controlan los Media Gateways, permitiendo una supervisión centralizada. Escalabilidad: Un MGC puede soportar varios MG, para una ampliación solo es necesaria la instalación de un nuevo MG. Orígenes Los protocolos de control de Media Gateways son inherentes a IP, actualmente los más conocidos son MGCP y Megaco/H.248. Otros protocolos de control son el Skinny, de Cisco, SGCP (simple gateway control protocol) e IPDC (Internet Protocol Device Control) En los comienzos, MGCP era una combinación de SGCP con IPDC, fue desarrollado y es mantenido por Softswitch Consortium and PacketCable. Megaco/H.248 fue desarrollado para satisfacer varios requerimientos que no eran debidamente contemplados en MGCP. Conceptualmente Megaco/H.248 es una evolución de MGCP, sin embargo la implementación es diferente y no son directamente compatibles. El modelo MGCP MGCP describe una arquitectura de control de llamadas, donde la inteligencia se encuentra fuera de los Gateways, y es realizada externamente por sistemas de control, los Media Gateway Controller o Call Agent. Estos sistemas de control deberán sincronizarse con los gateways, enviando comandos a todos los gateways bajo su control. No se define un mecanismo para sincronizar los sistemas de control entre sí. MGCP es esencialmente, un protocolo con una estructura master/slave, donde los Gateways solo van a ejecutar los comandos enviados por los MGC. Los Gateways solo van a realizar las funciones de conversión de voz y video, y generar un camino RTP entre los extremos de la comunicación. MGCP le informa al Gateway la dirección IP, el puerto UDP y los perfiles de RTP. El control de calidad de servicio, QoS está integrado en el Gateway o en el Media Gateway Controller. Los mensajes MGCP viajan sobre UDP/IP. Página 3 de 20
MGCP implementa un modelo de conexionado compuesto por Endpoints y Connections. Endpoints Un Endpoint es una representación lógica de una entidad física o virtual, como un teléfono analógico o un canal en una línea T1 o E1. Los Endpoints van a ser fuente o destino datos. Los endpoints reales van a requerir la instalación de algún tipo de hardware, mientras que los virtuales solo requerirán software. Un Gateway con una interface conectada a la PSTN es un endpoint físico, una interface conectada a un servidor de audio o video, es un endpoint virtual. Un endpoint puede generar eventos y señalización, un teléfono sonando es una señalización, mientras que colgar o descolgar el teléfono es un evento. Cuando sucede un evento en un teléfono real, asociado a un endpoint, el Media Gateway lo detecta y notifica al Media Gateway Controller del suceso, entonces el Media Gateway Controller cambiará su estado y actuará según sea necesario. Tipos de Endpoints: Digital Channel (DS0) Línea analógica Announcement server access point Interactive Voice Response access point Conference bridge access point Packet Relay ATM trunk side interface La identificación de un Endpoint esta compuesta por dos partes, el nombre de dominio del Gateway al que esta conectado el Endpoint y el nombre que le asigno el Gateway. (nombre-local@dominio) Por ejemplo para una línea analógica conectada a un Gateway se recomienda usar aaln/#, (Analog Access Line, y # es el número de port RJ11) de la misma manera para Digital Trunks, se utiliza ds. Conecctions Un endpoint puede mantener más de una conexión, las conexiones pueden ser punto a punto o multipunto. Una conexión punto a punto vincula dos endpoints, una vez establecida esa asociación para ambos endpoints la transferencia de datos puede comenzar. Los endpoints pueden estar en gateways distintos o en el mismo gateway. Las conexiones pueden ser establecidas sobre diversos tipos de redes de transporte, por ejemplo, RTP y UDP sobre redes IP, AAL sobre ATM. Página 4 de 20
Figura 2- A,B,C,D son endpoints Comandos MGCP Existen nueve comandos. Comando EndpointConfiguration CreateConnection ModifyConnection DeleteConnection NotificationRequest Notify AuditEndpoint AuditConnection RestartInProgress Código EPCF CRCX MDCX DLCX RQTN NTFY AUEP AUCX RSIP El Call Agent puede enviar un Endpoint Configuration a un Gateway, especificando por ejemplo el tipo de codificación que se espera desde un endpoint. EndpointConfiguration(EndpointId, [BearerInformation]) EndpointID es el nombre del endpoint en el Gateway. BearerInformation define como va a ser la codificación de los datos enviados y recibidos El Call Agent puede enviar Notification Request, a un Gateway, especificando que eventos debe vigilar. Como por ejemplo que alguien descuelgue el teléfono, o si recibe el tono de un fax.. Este comando también puede ser usado como Signal Request, que incluye el Ringing para hacer sonar un teléfono, el tono de ocupado, el ring back, tono de espera. NotificationRequest(EndpointId, [NotifiedEntity,] [RequestedEvents,] Página 5 de 20
RequestIdentifier, [DigitMap,] [SignalRequests,] [QuarantineHandling,] [DetectEvents,] [encapsulated EndpointConfiguration]) NotifiedEntity, se utiliza si se desea cambiar a que Call Agent se debe avisar. En el caso de que no se encuentre especificado, la respuesta será enviada al ultimo NotifiedEntity que se halla recibido, y si no fue enviado anteriormente se responde al Call Agent que genero el RQNT. RequestedEvents, es la lista de eventos que el Gateway debe monitorear, por ejemplo, el tono de fax, o el off-hook. RequestIdentifier, para poder identificar el RQNT. SignalRequests, contiene una o mas señales que el Gateway debe generar en el endpoint. QuarantineHandling, especifica como deben tratarse los eventos que fueron detectados por el Gateway antes del arribo del RQNT, pero que aún no han sido notificados al Call Agent. Por ejemplo si son procesados o si se los descarta, si se los envía todos juntos o en forma secuencial. DetectEvents, sirve para especificar eventos que deben ser detectados pero no notificados. Cada evento tiene asociada una o mas acciones, las acciones pueden ser: Notificar del evento en forma inmediata Swap Audio (para llamada en espera, un endpoint con mas de una conexión) Acumular los eventos en un buffer, peor no enviar el aviso. Acumular los dígitos presionados según el digit-map. Mantener la señal activa. Ignorar el evento. Procesar el NTRQ. Se puede especificar una acción particular para cada evento. Los eventos y las señales se encuentran agrupados en paquetes, según los tipos de endpoints. Por ejemplo, el paquete L, va a agrupar a todos los eventos y señales asociados a un endpoint que represente una línea analógica. Para identificar un evento va a ser necesario definir el grupo y luego separado por una barra el evento. Por ejemplo l/hu representa el evento hung up en una línea analógica. Package Generic Media Package DTMF Package MF Package Trunk Package Line Package Handset Emulation Package RTP Package Network Access Server Package Announcement Server Package Script Package Name G D M T L H R N A Script Paquetes Básicos Página 6 de 20
Según su duración temporal, las señales están clasificadas en tres tipos: Las On/Off (OO), una vez aplicadas, perduran hasta que sean apagadas. Las de Time-Out (TO), perduran hasta que son apagadas, o cuando ha transcurrido un lapso de tiempo determinado. Las Brief (BR), la duración es muy corta. Símbolo Definición E S Duración adsi Adsi dysplay BR vmwi visual message waiting indicator OO hd Off hock X hu On hock X hf Flash hock X aw Answer tone X OO bz Busy tone TO 30 seg ci Caller-Id BR wt Waiting tone TO 30 seg wt1,wt2,wt3 Alternative waiting tone dl Dial tone TO 16 seg mwi Message waiting indicator TO 16 seg nbz Network Busy x OO ro Recorder Tone TO 30 seg rg Ringing TO 180 seg R0,r1,r2 Distinctive Ringing TO 180 seg rs Ringsplash BR p Prompt Tone x BR e Error Tone x BR sl Stutter dialtone TO 16 seg v Alerting Tone OO y Recorder Warning Tone OO sit SIT Tone z Calling Card Service Tone OO oc Report on completion x ot Off hock warning tone TO Indefinidamente S(###) Distinctive tone pattern x BR of Report failure x Tabla con los eventos y señales pertenecientes al paquete Line. El Gateway va a usar el comando Notify, para informar al Call Agent que ha ocurrido alguno de los eventos que estaba monitoreando. Notify(EndpointId, [NotifiedEntity,] RequestIdentifier, ObservedEvents) El Call Agent puede usar el comando Create Connection para crear una conexión que termine en un Endpoint asociado a un Gateway. Página 7 de 20
Este comando tiene asociados los siguientes parámetros: Call ID Endpoint ID Local/Remote Connection Description o Método de codificación (G.711, G.726), se listan los codecs de compresión disponibles en el endpoint, en orden de preferencia. o Ancho de banda dedicado, incluye el payload y los headers. No debe contradecirse con los codecs, si se especifica un codec, el Gateway lo puede usar aunque consuma más ancho de banda, si sucede esto no se va a reportar como un error. o Tipo de servicio o Cancelación de eco, normalmente se usa la cancelación de eco, pero puede ser necesario no hacerlo en alguna conexión. o Supresión de silencios, puede ser necesario cancelar esta opción, por ejemplo si se esta utilizando un modem. o Control de ganancia, para esta opción, también puede darse el caso de que sea necesario cancelarla. Puede configurarse en automatic, o en una cantidad x de decibeles, por defecto la ganancia es 0. o Uso del servicio RSVP (Resource Reservation Service), el Call Agent puede pedirle al Gateway que use network resource reservation para la conexión. o Encriptación, el Call Agent puede solicitar la encriptación. o Packetized Period (el período de los paquetes debe ser acorde con el frame size del codec) o Tipo de red Modos o Send (usado para el envió de avisos) o Receive (usado para recibir los avisos) o Send/Receive (uso normal durante llamada) o Inactive o Conference o Data o Loopback El Gateway responde al Create Connection con un session description que incluye la información necesaria, dirección IP, puerto UDP, codecs disponibles, etc, útil para la configuración del endpoint en el otro extremo de la conexión. CreateConnection(CallId, EndpointId, [NotifiedEntity,] [LocalConnectionOptions,] Mode, [{RemoteConnectionDescriptor SecondEndpointId}, ] [Encapsulated NotificationRequest,] [Encapsulated EndpointConfiguration]) Página 8 de 20
CallId, este parámetro se utiliza para identificar la llamada o sesión a la que pertenece la conexión, no afecta el manejo de las conexiones por parte del Gateway, pero se utiliza para generar reportes y accounting. SecondEndpointId, se utiliza cuando la conexión que se quiere establecer es entre dos endpoints que dependen del mismo Gateway. Cuando se incluye este parámetro se crean dos conexiones independientes entres si. Las conexiones solo van a poder ser activadas cuando se halla recibido el Remote Connection Descriptor. Después de recibir un Create Connection sin el parámetro Remote Connection Descriptor, el Gateway se encuentra en una situación ambigua, porque exporto el parámetro Local Connection Descriptor, y ya esta en condiciones de recibir paquetes, pero como aún no recibió el Remote Connection Descriptor del otro Gateway no sabe si lo que recibe fue autorizado por el Call Agent. Esto provoca dos situaciones riesgosas, ignorar datos importantes o escuchar datos inútiles. Con la opción Mode se configura esto, si tiene el valor ReceiveOnly, acepta lo que llegue y lo reenvía al endpoint. Si esta en Inactive, o Loopback rechaza todo lo recibido. También se puede incluir un RQNT y un EPCF, que son ejecutados simultáneamente con la creación de la conexión. Por ejemplo se puede incluir un RQNT para que el teléfono comience a sonar. Si se incluye alguna de estas opciones, para que el comando sea exitoso deben poder cumplirse tanto el CRCX como el RQNT/EPCF. No tiene sentido hacer sonar el teléfono si el Gateway no pudo crear la conexión. El Call Agent puede usar el comando Modify Connection para cambiar los parámetros asociados a una conexión establecida previamente, o para completar la información necesaria para establecerla. Por ejemplo se pueden cambiar los codecs usados, o la dirección IP y puerto UDP si la llamada es desviada, cambiar el tipo de codificación, activar o desactivar la supresión de eco, cambiar el modo, etc. ModifyConnection(CallId, EndpointId, ConnectionId, [NotifiedEntity,] [LocalConnectionOptions,] [Mode,] [RemoteConnectionDescriptor,] [Encapsulated NotificationRequest,] [Encapsulated EndpointConfiguration]) Similar al Create Connection. El Call Agent puede usar el comando Delete Connection para dar por terminada una conexión. También puede ser usado por el Gateway para informar al Call Agent que no puede seguir manteniendo activa la conexión, por ejemplo porque ya no tiene los recursos asociados a la conexión, o el endpoint ya no es capaz o no desea enviar o recibir datos. Página 9 de 20
Si es enviado por el Call Agent DeleteConnection(CallId, EndpointId, ConnectionId, [NotifiedEntity,] [Encapsulated NotificationRequest,] [Encapsulated EndpointConfiguration Se lo puede usar para terminar con varias conexiones en forma simultanea. DeleteConnection( CallId, EndpointId) Para terminar todas las conexiones asociadas a una llamada que terminen en un edpoint. DeleteConnection( EndpointId) Para terminar todas las conexiones que terminen en un edpoint. Si se está realizando multicast, las conexiones pueden ser terminadas en forma individual e independiente. Si la conexión es unicast, el DLCX debe ser enviado a ambos Gateways. En respuesta al comando DLCX, el Gateway devuelve una lista de parámetros con las estadísticas de la conexión, por ejemplo, numero de paquetes enviados, recibidos, perdidos, cantidad de octetos enviado, recibidos y perdidos, jitter, y delay de la transmisión. También pueden incluirse un RQNT y un EPCF. Si el DeleteConnection es enviado por el Gateway DeleteConnection(CallId, EndpointId, ConnectionId, ReasonCode, Connection-parameters) Donde Reason Code, es un string que comienza con un código numérico que identifica la razón, y puede estar seguido de una descripción textual de la causa. También envía los parámetros que hubiese enviado si el DeleteConnection lo hubiese enviado Call Agent. El Call Agent puede usar el comando Audit Endpoint para conocer el estado de un endpoint. AuditEndPoint(EndpointId, [RequestedInfo]) La información que puede ser requerida es la siguiente: RequestedEvents, los evetos que está monitoreando el endpoint y las acciones asociadas. DigitMap, el digitmap que está usando el endpoint. Página 10 de 20
SignalRequests, las señales Time-Out que se encuentran aun activas, las señales On/Off activas y cualquier señal Brief que este pendiente. Las señales de Time-Out que caducaron y las Brief en ejecución no se incluyen. RequestIdentifier, el identificador del ultimo RQNT recibido. QuarantineHandling, el ultimo recibido. DetectEvents, la lista de eventos detectados en quarantine mode. NotifiedEntity, el Call Agent al que se debe informar actualmente. ConnectionIdentifiers, lista de identificadores de conexiones que se encuentren activas en el endpoint. ObservedEvents, lista de eventos detectados por el Gateway. Solo va a incluir los eventos solicitados en los RQNT. EventStates, cual es el estado para los eventos que puedan tener un estado asociado. BearerInformation, el ultimo valor recibido. RestartReason, el valor enviado en el último RestartInProgress indicando funcionamiento completo. RestartDelay ReasonCode PackageList, lista de los paquetes soportados por el endpoint. MaxMGCPDatagram, el tamaño máximo de datagrama que puede recibir el endpoint, en bytes. Capabilities, similar al LocalConnectionOptions. El Call Agent puede usar el comando AuditConnection para conocer el estado de una conexión AuditConnection(EndpointId, ConnectionId, RequestedInfo) La información que puede ser requerida es la siguiente: CallId NotifiedEntity LocalConnectionOptions Mode RemoteConnectionDescriptor LocalConnectionDescriptor ConnectionParameters Si se envía un AuditConnection sin solicitar información, y el endpoint es válido, el Gateway solo va a chequear la existencia de la conexión. El Gateway puede usar el comando Restart In Progress para informar al Call Agent que el Gateway o uno o más de los Endpoints que maneja están fuera de servicio o que están nuevamente en servicio. RestartInProgress(EndPointId, RestartMethod, [RestartDelay,] [ReasonCode]) Página 11 de 20
RestartMethod, los tipos posibles son: Graceful, el endpoint va a estar fuera de servicio dentro de un tiempo específico. Las conexiones existentes todavía no son afectadas, pero el Call Agent deberá intentar establecer nuevas conexiones y terminar las que se encuentren activas. Forced, fuera de servicio en forma abrupta, se pierden todas las conexiones existentes. Restart, el endpoint va a estar nuevamente en servicio después de un determinado restarting delay. No existen conexiones activas. Disconnected, el endpoint se encuentra desconectado y se está intentando restablecer la comunicación. Cancel Graceful, para cancelar un Graceful. RestartDelay, tiempo en segundos, se utiliza en el graceful, restart y disconnected. En Gracefull representa el tiempo en el cual se dará de baja el endpoint. En restart, el tiempo en el cual el endpoint estará nuevamente en servicio. Y en Disconnected el tiempo que lleva desconectado. Opcionalmente se puede enviar un código identificando la razón del restart. Con estos comandos el Call Agent puede dar las instrucciones a un Gateway para la creación de una conexión, terminada en un Endpoint que tiene asociado, y permiten que se le informe de cualquier evento que pueda suceder en un Endpoint. Todos los comandos deben recibir un ack, que va a tener un código según el resultado del comando. Para iniciar una comunicación usando protocolo MGCP En este caso la conexión se establecerá entre dos Endpoints, que están asociados a dos Gateways controlados por el mismo Call Agent. 1. El Call Agent envía un RQTN (Notification Request) del evento descolgar teléfono. 2. Cuando se descuelga el teléfono, el Gateway le envía un Notify al Call Agente informándole del evento. 3. El Call Agent envía un RQTN, funcionando como Signal Request para dar el tono en el teléfono, y como Notification Request, para pedir el digitmap, ya que puede ser un número de teléfono, un código de acceso o un número de tarjeta de crédito. El Gateway, no envía cada dígito por separado, los guarda en un buffer y los envía todos juntos para generar menos tráfico. Como el Gateway no puede conocer cual es la cantidad de dígitos debe acumular antes de enviarlos, el Call Agent le pasa un digitmap. Un ejemplo de un digitmap, (0T 00T xxxx 91xxxxxxxxxxx) 0T Operadora local, 00T Operadora, xxxx interno, 91xxxxxxxxxx para llamadas larga distancia. 4. El Gateway envía los dígitos marcados NTFY(digits). 5. El Call Agent le pide al segundo Gateway que cree una conexión con el Endpoint (CRCX). El Gateway reserva recursos para esa conexión según las instrucciones del Call Agent, puede ser que el Call Agent especifique todos los parámetros o que le dé libertad al Gateway para decidir que usar. También se envía un RQNT del off hook. EL Gateway tiene que confirmar que pudo reservar los recursos, ACK(SDP). Página 12 de 20
Figura 3 6. El Call Agent le pide al primer Gateway que también cree una conexión. Además envía un RQNT del on hook. El Gateway responde el ACK(SDP) 7. Se envía un MDCX con el Remote Session Descriptor del otro endpoint, esto se hace para tratar que las dos conexiones tengan parámetros similares, también se envía la instrucción ringback tone. 8. Cuando atienden, el Gateway notifica con un NTFY al Call Agent. Que luego envía un MDCX, y un RQNT, cambia al modo send/recv, y agrega el monitoreo del hook flash (simula un off-hook/on-hook/off-hook, se utiliza para conferencias o para realizar un nuevo llamado) 9. Se envía un RQNT del on hook y hook flash al otro Gateway. Una vez recibido el último ACK se encuentra establecida la comunicación entre los endpoints. Para terminar la comunicación: 1. Alguno de los endpoints cuelga el teléfono, entonces se genera un NTFY del evento. 2. El Call Agent envía un DLCX para terminar la conexión. Tambiénse envía un RQNT del off hook.. 3. Luego le envía un DLCX al otro Gateway. Además se les envía un RQNT del off hook. Página 13 de 20
4. Cuando el segundo endpoint cuelga, se envía un NTFY, y luego de recibir el ACK se da por terminada la comunicación. Cuando los endpoints se encuentran en Gateways manejados por Call Agents distintos, estos intercambian información usando protocolos como el SIP, para sincronizar la creación de las conexiones en los dos endpoints. Cuando ambos endpoints se encuentran en el mismo Gateway, la conexión puede ser establecida con un único Create Connection, que incluye el nombre del segundo endpoint en lugar del Remote Connection Descriptor. Las conexiones van a estar identificadas por un número hexadecimal, de largo máximo 32 caracteres, que es generado por el Gateway Ejemplos de los comandos Un comando esta compuesto por: El header, conteniendo una línea con la identificación del comando, el identificador de transacción para correlacionar comandos y respuestas, el endpoint destino y la versión del protocolo MGCP. Las líneas de parámetros, compuestas por un parámetro y un valor asociado. Parámetro BearerInformation CallId Capabilities ConnectionId ConnectionMode ConnectionParameters DetectEvents DigitMap EventStates LocalConnectionOptions MaxMGCPDatagram NotifiedEntity ObservedEvents PackageList QuarantineHandling ReasonCode RequestedEvents RequestedInfo RequestIdentifier ResponseAck RestartDelay RestartMethod SecondConnectionId SecondEndpointId SignalRequests SpecificEndPointId RemoteConnectionDescriptor Código B C A I M P T D ES L MD N O PL Q E R F X K RD RM I2 Z2 S Z RC Página 14 de 20
LocalConnection Descriptor Parámetros Posibles LC CreateConnection (CRCX) Códigos de las opciones de LocalConnectionOption: a: Método de codificación b: Ancho de banda dedicado, en kilobits por segundo. t: Tipo de servicio. e: Cancelación de eco, seguido de on u off s: Supresión de silencios, seguido de on u off gc: Control de ganancia, el valor puede ser auto, o un numero que indica la ganancia en db. r: Uso del servicio RSVP, seguido de g para guaranteed service, cl para controlled load, o be para best effort. k:encriptación. p: Packetized Period, en milisegundos. nt: Tipo de red, seguido de IN para Internet, ATM o LOCAL. CRCX 1204 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 L: p:10, a:pcmu M: recvonly CRCX: Create Connection 1204: identificador de transacción. aaln/1@rgw-2567.whatever.net: EndpointID C: A3C47F21456789F0 : CallID L: p:10, a:pcmu :Opciones de LocalConnetionOptions, p:10 periodo de paquetes de 10ms, y codec PCMU. (mu-law) M: recvonly : mode de la conexión, receive only. Este es similar, pero se incluye el RQNT CRCX 1205 aaln/1@rgw-2569.whatever.net MGCP 1.0 C: A3C47F21456789F0 L: p:10, a:pcmu M: sendrecv X: 0123456789AD R: L/hd S: L/rg NotificationRequest (RQNT) Este NTRQ va a hacer sonar el teléfono y va a monitorear el off hock RQNT 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0 N: ca@ca1.whatever.net:5678 X: 0123456789AC R: l/hd(n) S: l/rg RQTN: Request Notification Página 15 de 20
1201: es el identificador del RQNT aaln/1@rgw-2567.whatever.net: EndpointID, endpoint aaln/1 en el GW rgw-2567, de whatever.net. MGCP 1.0: versión del protocolo. X: 0123456789AC, RequestIdentifier. N: ca@ca1.whatever.net:5678: es el valor de Notified Entity, el puerto puede especificarse, por defecto MGCP usa el 2427. R: l/hd(n): R de Requested Event, perteneciente al paquete line, hd Off Hock, motirorear si descuelgan el teléfono. S: l/rg : S de Signal Request, ringing. Notify (NTFY) Este NTFY informa del off-hock y los 12 dígitos que se presionaron posteriormente. NTFY 2002 aaln/1@rgw-2567.whatever.net MGCP 1.0 N: ca@ca1.whatever.net:5678 X: 0123456789AC O: L/hd,D/9,D/1,D/2,D/0,D/1,D/8,D/2,D/9,D/4,D/2,D/6,D/6 NTFY: Notify. 2002: identificador del NTFY. N: aaln/1@rgw-2567.whatever.net: endpoint que generó el NTFY. X: 0123456789AC, identificador del RQNT que originó el NTFY. O: L/hd, D/9... : eventos observados. L/hd es el off-hook, y D/9 corresponde al primer digito del digit map. ModifyConnection (MDFY) MDCX 1209 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8 N: ca@ca1.whatever.net M: sendrecv MDCX: Modify connection. 1209: identificador transacción. C: A3C47F21456789F0 : CallID I: FDE234C8 : ConnectionID N: ca@ca1.whatever.net : CallAgent al que se le deberá informar desde ahora. M: sendrecv, se cambia al modo send/receive. Página 16 de 20
DeleteConnection (DLCX) Desde el Call Agent DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8 Desde el Gateway DLCX 1210 aaln/1@rgw-2567.whatever.net MGCP 1.0 C: A3C47F21456789F0 I: FDE234C8 E: 900 - Hardware error P: PS=1245, OS=62345, PR=780, OR=45123, PL=10, JI=27, LA=48 Se incluyen la razón del DeleteConnection y las estadísticas de la comunicación. AuditEndpoint (AUEP) El Call Agent le pregunta al Gateway que endpoints tiene asociados. AUEP 1200 *@rgw-2567.whatever.net MGCP 1.0 En este caso el CallAgent pregunta por las opciones disponibles en un endpoint. AUEP 1201 aaln/1@rgw-2567.whatever.net MGCP 1.0 F: A F: A, Requested Info, All. La respuesta seria de la siguiente 200 1201 OK A: a:pcmu, p:10-100, e:on, s:off, v:l;s, m:sendonly; recvonly;sendrecv;inactive;netwloop;netwtest A: a:g729, p:30-90, e:on, s:on, v:l;s, m:sendonly; recvonly;sendrecv;inactive;confrnce;netwloop En este ejemplo se pregunta por determinados parámetros del endpoint AUEP 2002 aaln/1@rgw-2567.whatever.net MGCP 1.0 F: R,D,S,X,N,I,T,O,ES La respuesta va a ser 200 2002 OK R: L/hu,L/oc(N),D/[0-9](N) D: S: L/vmwi(+) X: 0123456789B1 N: [128.96.41.12] I: 32F345E2 T: G/ft O: L/hd,D/9,D/1,D/2 ES: L/hd Página 17 de 20
Restart In Progress En le primer ejemplo es del tipo graceful, con un RestarDelay de 300 segundos. RSIP 1200 aaln/1@rgw-2567.whatever.net MGCP 1.0 RM: graceful RD: 300 En este ejemplo el Gateway informa que todos sus endpoints van a entrar en servicio en 0 segundos, es decir, todos se encuentran en funcionamiento. RSIP 1204 *@rgw-2567.whatever.net MGCP 1.0 RM: restart RD: 0 Implementaciones tradicionales / habituales Trunking gateways Durante una llamada o conferencia, de audio o video, se transmiten dos flujos de datos, la señalización para establecer el llamado, y los datos de voz o video. El flujo de datos solo comienza a ser transmitido luego de que se ha establecido la conexión entre las partes. Debido a la diferencia en la forma de manejar la señalización y los datos existentes entre PSTN y VoIP, existe la necesidad de asegurar la coherencia de las comunicaciones entre ambas redes. Los Trunking Gateways son los encargados de esto. Figura 4 Signaling Gateway (SG) se ubica entre las redes IP y PSTN, para extraer y normalizar las señales de la PSTN a señalización VoIP. El Signaling Gateway trabaja en conjunto con un Softswitch para traducir la señalización a un protocolo de VoIP específico, como por ejemplo SIP o H.323. El Softswich también funciona como un MGC, que controla un Trunking Gateway asociado. El Trunking Gateway es un Media Gateway capaz de transportar datos entre el Channel-B de la PSTN y (paquetes) RTP. El Softswitch, trabajando como MGC, indica al Trunking Gateway que Channel- B esta conectado a que flujo RTP, y también puede indicarle como codificar los datos. Por ejemplo cuando un teléfono IP llama y alguien atiende, un flujo de datos es enviado hacia el Channel-B de la red PSTN. Como el Signaling Gateway no puede manejar los paquetes RTP, son enviados al Trunking Gateway. El Trunking Gateway es el encargado de adecuarlos al Channel-B Página 18 de 20
de la PSTN. El Softswitch y el Trunking Gateway se comunican usando protocolos como el MGCP o Megaco/H.248. Gateways Residenciales Es un dispositivo ubicado en el borde/frontera de una red, intercomunicando una red hogareña con una conexión de banda ancha. Usualmente también funcionan como routers, hub o módem brindando acceso a Internet. También pueden brindar una solución práctica para VoIP, ya que teléfonos analógicos pueden ser reciclados y usados como teléfonos IP, reduciendo costos. Usualmente, los proveedores de Internet controlan los Residencial Gateways. Un Residencial Gateway puede ser considerado como un Media Gateway controlado por un Media Gateway Controller en una estructura cliente/servidor. Esta estructura les resulta atractiva a los proveedores, ya que les da el control que necesitan. Figura 5 Conferencing Bridges Figura 6 Página 19 de 20
Otra implementación importante donde se utiliza MGCP es en bridges para conferencias de audio y video. Los bridges de video tambien son llamados Multipoint Conferencing Unit (MCU) Un conferencing bridge permite conectar a tres o más participantes en una conferencia. Además del seteo y control de la llamada, el conferencing bridge va a ser el encargado de asegurar la calidad de la comunicación. Normalmente tiene una arquitectura formada por un ente controlador y uno o más servidores de audio y video. A la entidad controldora se la llama Multipoint Controller (MC), que va a manejar el setup y control de la comunicación. Los Gateways de audio y video son llamados Multipoint Processors (MP). Va a ser el encargado de combinar las señales de voz entrantes y enviarlas nuevamente por los canales RTP. La comunicación entre ambos el MC y el MP se realiza utilizando MGCP. Página 20 de 20