MRCPv2 es la abreviatura de Media Resource Control Protocol Version 2 (MRCPv2).Este artículo traduce RFC6787 sección 4.2.Administración de canales de control de recursos
4.2 Gestión de canales de control de recursos gestión de canales de control de recursos
El cliente necesita un canal de control de recursos MRCPv2 independiente ( Canal de control de recursos ) para controlar cada recurso de procesamiento de medios en la conversación SIP.
Las cadenas de identificación de canal únicas identifican estos canales de control de recursos. Un identificador de canal es una cadena inequívoca difícil de adivinar seguida de una "@" y luego una etiqueta de cadena que especifica el tipo de recurso . El servidor genera el identificador del canal y debe asegurarse de que no entre en conflicto con los identificadores de cualquier otro canal MRCP actualmente asignado por el servidor. MRCPv2 define los siguientes tipos de recursos de procesamiento de medios registrados en la IANA. Se pueden agregar tipos de recursos adicionales y sus métodos/eventos asociados y máquinas de estado como se describe en la Sección 13 a continuación.
| Tipo de recurso | Descripción del recurso | Descrito en |
|---|---|---|
| reconocimiento de voz | Reconocedor de voz | Sección 9 |
| dtmfrecog | Reconocedor DTMF | Sección 9 |
| sintetizador de voz | Sintetizador de voz | Sección 8 |
| basicsynth | Sintetizador básico | Sección 8 |
| hablarverificar | Verificación del orador | Sección 11 |
| grabadora | Grabadora de voz | Sección 10 |
Tabla 1: Tipos de recursos
Una transacción SIP INVITE o re-INVITE y el intercambio de oferta/respuesta SDP que lleva contiene una línea " m= " que describe el canal de control de recursos que se asignará . Debe haber una línea SDP " m= " para cada recurso MRCPv2 utilizado en una sesión .
La línea " m= " DEBE tener un campo de tipo de medio " aplicación " y un campo de tipo de transporte " TCP/MRCPv2 " o " TCP/TLS/MRCPv2 ".
El campo de número de puerto de la línea " m=" DEBE contener el puerto "drop" (puerto TCP 9) del protocolo de transporte en el SDP proporcionado por el cliente , y DEBE contener el puerto de escucha TCP en el servidor en la respuesta SDP. Luego, los clientes pueden establecer una conexión TCP o TLS con ese puerto del servidor, o compartir una conexión establecida con ese puerto.
El siguiente ejemplo
m=aplicación 9 TCP/MRCPv2 1
Dado que MRCPv2 permite que varias sesiones compartan la misma conexión TCP, varias líneas " m=" en un solo documento SDP PUEDEN compartir el mismo valor de campo de puerto; los servidores MRCPv2 NO DEBEN suponer que existe una relación entre los recursos que usan el mismo puerto .
Los recursos de MRCPv2 no usan los campos de puerto o formato de la línea " m= " para distinguirlos de otros recursos que usan el mismo canal. El cliente DEBE especificar el identificador de tipo de recurso en el atributo de recurso asociado con la línea de control " m= " proporcionada por el SDP. El servidor DEBE responder con el identificador de canal completo (incluido el identificador de tipo de recurso y la cadena inequívoca difícil de adivinar) en el atributo " canal " asociado con la línea de control " m= " de la respuesta SDP . Para mantener la compatibilidad con versiones anteriores con el uso de SDP heredado, el campo de formato de la línea " m = " DEBE tener un valor de "1" elegido arbitrariamente.
El siguiente ejemplo
m=aplicación 32416 TCP/MRCPv2 1 # El último 1
a=canal:32AECB234338@speechsynth #Channel-Identifier es 32AECB234338
Cuando un cliente desea agregar recursos de procesamiento de medios a una sesión, emite una nueva oferta SDP en una solicitud SIP Re-Invite de acuerdo con el procedimiento de RFC 3264 [RFC3264]. El intercambio de oferta/respuesta SDP transportado por esta transacción SIP contiene una o más líneas de control adicionales " m= " para nuevos recursos asignados a la sesión.
El servidor asigna recursos (si están disponibles) cuando ve la nueva línea " m= " y responde con la línea de control " m= " correspondiente en la respuesta SDP incluida en la respuesta SIP . Si no hay nuevos recursos disponibles, la nueva INVITACIÓN recibirá un mensaje de error y el procesamiento de medios existente que estaba en curso antes de la nueva INVITACIÓN continuará como antes. No es posible asignar más de un recurso de cada tipo. Si un cliente solicita múltiples recursos de cualquier tipo, el servidor DEBE comportarse como si los recursos de ese tipo (más allá del primer recurso) no estuvieran disponibles.
Los clientes y servidores MRCPv2 que utilizan TCP como protocolo de transporte DEBEN utilizar los procedimientos especificados en RFC 4145 [RFC4145] para establecer una conexión TCP, teniendo en cuenta las consideraciones descritas aquí.
De manera similar, los clientes y servidores MRCPv2 que usan TCP/TLS como protocolo de transporte DEBEN usar el procedimiento especificado en RFC 4572 [RFC4572] para configurar una conexión TLS, teniendo en cuenta las consideraciones descritas aquí.
El atributo a=setup, como se especifica en RFC 4145 [RFC4145], DEBE estar "activo" para ofertas de clientes y " pasivo " para respuestas de servidores MRCPv2.
El siguiente ejemplo de cliente
a=setup:active
El siguiente ejemplo de servidor
a=setup:passive
El atributo a=conexión debe tener el valor "nuevo" en la primera línea de control " m= " del cliente al servidor MRCPv2. Las líneas de control posteriores "m=" proporcionadas desde el cliente al servidor MRCP pueden contener "nuevas" o "existentes", dependiendo de si el cliente desea establecer por separado una nueva conexión o compartir una conexión existente . Si el cliente especifica un valor de "nuevo", el servidor DEBE responder con un valor de " nuevo ". Si el cliente especifica un valor de " existente ", el servidor DEBE responder. Los valores legales en la respuesta son " existente " si el servidor prefiere compartir una conexión existente, y " nuevo " en caso contrario. En este último caso, el cliente deberá iniciar una nueva conexión de transporte.
El siguiente ejemplo de cliente
a=conexión:existente
Según RFC 3264 [RFC3264], cuando un cliente desea liberar recursos de esta sesión, emite una nueva oferta de SDP en la que el puerto de línea de control "m=" DEBE establecerse en 0 .
Este SDP propone enviar una solicitud de reinvitación en SIP. Esto libera el identificador y los recursos MRCPv2 asociados. Un servidor NO DEBE cerrar una conexión TCP o TLS si actualmente se comparte entre múltiples canales MRCP. Un cliente o servidor finaliza una conexión cuando se liberan todos los canales MRCP que podrían compartir la conexión y/o finaliza el cuadro de diálogo SIP asociado.
El siguiente ejemplo de cliente
m=aplicación 0 TCP/MRCPv2 1 # El 0 detrás de la aplicación identifica el puerto que se va a eliminar
Cuando un cliente desea finalizar la sesión completa y todos sus recursos, debe emitir una solicitud SIP BYE para cerrar la sesión SIP.
Esto desasignará todos los canales de control y los recursos asignados en la sesión.
Todos los servidores deben ser compatibles con TLS. Un servidor puede usar TCP sin TLS en un entorno controlado (por ejemplo, no en la Internet pública) donde ambos nodos están dentro de un rango protegido, por ejemplo, para evitar el acceso al servidor MRCP desde nodos remotos fuera del rango controlado. Ofrecido por el cliente vía SDP para seleccionar el transporte que desea utilizar para la sesión MRCPv2.
Con las excepciones mencionadas anteriormente, cuando se usa TCP, la línea " m= " DEBE cumplir con RFC4145 [RFC4145], que describe el uso de SDP para transportes orientados a conexión. Cuando se usa TLS, la línea SDP "m=" del flujo de control debe cumplir con Medios orientados a la conexión sobre TLS (COMEDIA) [RFC4572], que especifica el uso de SDP para establecer un transporte seguro orientado a la conexión sobre TLS.