[Introducción al protocolo MRCPv2] Encabezados de mensajes genéricos

MRCPv2 es la abreviatura de Media Resource Control Protocol Version 2 (MRCPv2).Este artículo traduce RFC6787 sección 6.2.Encabezados de mensajes genéricos

6.2 Encabezados de mensajes genéricos

Todos los campos de encabezado de MRCPv2, incluidos los encabezados genéricos definidos en las siguientes subsecciones y los campos de encabezado específicos de recursos definidos más adelante, siguen el mismo formato general que se indica en la Sección 3.1 de RFC 5322 [RFC5322].

Cada campo de encabezado consta de un nombre seguido de dos puntos (":") y un valor. Los nombres de los campos de encabezado no distinguen entre mayúsculas y minúsculas. El valor puede estar precedido por cualquier número de LWS (espacios en blanco lineales), pero se prefiere un solo SP (espacio).

Los campos de encabezado pueden abarcar varias líneas utilizando al menos un SP o HT (pestaña horizontal) antes de cada línea adicional.

   generic-field  = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *LWS field-content *( CRLF 1*LWS field-content)
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

El contenido del campo no incluye ningún LWS inicial o final (es decir, espacios en blanco lineales que aparecen antes del primer carácter que no es un espacio en blanco de un valor de campo o después del último carácter que no es un espacio en blanco de un valor de campo). Dicho LWS inicial o final se puede eliminar sin cambiar la semántica del valor del campo.
Cualquier LWS que ocurra entre los contenidos del campo se puede reemplazar con un solo SP antes de interpretar el valor del campo o reenviar el mensaje en sentido descendente.

Los servidores y clientes de MRCPv2 NO DEBEN basarse en el orden de los campos de encabezado . Se recomienda enviar primero los campos de encabezado general, luego los campos de encabezado de solicitud o respuesta y finalmente los campos de encabezado de entidad.
Sin embargo, los servidores y clientes de MRCPv2 DEBEN estar preparados para procesar los campos de encabezado en cualquier orden. La única excepción a esta regla es cuando hay varios campos de encabezado con el mismo nombre en el mensaje.

Pueden aparecer varios campos de encabezado con el mismo nombre en un mensaje si y solo si el valor completo de ese campo de encabezado se define como una lista separada por comas.

Dado que los parámetros de proveedor/específicos del proveedor pueden depender del pedido, debe ser posible combinar varios campos de encabezado del mismo nombre en un solo par "nombre:valor" sin cambiar la semántica del mensaje, agregando cada valor subsiguiente al primero, cada uno separado por una coma. Por lo tanto, el orden en que se reciben los campos de encabezado con el mismo nombre es importante para la interpretación de los valores de los campos de encabezado compuestos, por lo que los intermediarios NO DEBEN cambiar el orden de estos valores al reenviar mensajes.

generic-header      =    channel-identifier
                       /    accept
                       /    active-request-id-list
                       /    proxy-sync-id
                       /    accept-charset
                       /    content-type
                       /    content-id
                       /    content-base
                       /    content-encoding
                       /    content-location
                       /    content-length
                       /    fetch-timeout
                       /    cache-control
                       /    logging-tag
                       /    set-cookie
                       /    vendor-specific

6.2.1. Identificador de canal

Todas las solicitudes, respuestas y eventos de MRCPv2 DEBEN contener un campo de encabezado de identificador de canal . El servidor asigna este valor cuando el canal de control se agrega a la sesión y se comunica al cliente a través del atributo " a=channel " en la respuesta SDP del servidor.

El valor del campo de encabezado consta de dos partes separadas por el símbolo "@". La primera parte es una cadena inequívoca que se utiliza para identificar la sesión MRCPv2. La segunda parte es una etiqueta de cadena que especifica uno de los tipos de recursos de procesamiento de medios enumerados en la Sección 3.1.
La cadena inequívoca (primera parte) debe ser difícil de adivinar, única dentro de la instancia de recurso administrada por el servidor y común a todos los canales de recursos establecidos con ese servidor en una única conversación SIP.

   channel-identifier  = "Channel-Identifier" ":" channel-id CRLF
   channel-id          = 1*alphanum "@" 1*alphanum

6.2.2. Aceptar

El campo de encabezado Aceptar sigue la sintaxis definida en [H14.1]. La semántica también es la misma, excepto que si el campo de encabezado Aceptar está ausente, el servidor DEBE asumir un valor predeterminado específico para el tipo de recurso que se controla. Este valor predeterminado se puede cambiar para los recursos de la sesión enviando este campo de encabezado en el método SET-PARAMS. El valor predeterminado actual de este campo de encabezado para los recursos de la sesión se puede encontrar a través del método GET-PARAMS. Este campo de encabezado puede estar presente en cualquier solicitud.

6.2.3. Lista de ID de solicitud activa

En una solicitud, este campo de encabezado indica la lista de ID de solicitud a los que se aplica la solicitud. Esto es útil cuando hay múltiples solicitudes en PENDIENTES o EN CURSO y el cliente desea que esta solicitud se aplique exclusivamente a una o más de ellas.

En las respuestas, este campo de encabezado devuelve una lista de los ID de solicitud modificados o afectados por este método. Puede haber una o más solicitudes en estado de solicitud PENDIENTE o EN CURSO . Cuando un método que afecta a una o más solicitudes PENDIENTES o EN CURSO se envía desde un cliente a un servidor, la respuesta DEBE contener en sus encabezados una lista de ID de solicitudes afectadas o modificadas por este comando.

Active-Request-Id-List solo se usa para solicitudes y respuestas, no para eventos .

Por ejemplo, si se envía una solicitud de STOP sin una lista de Id. de solicitud activa a un recurso de síntesis (de voz) que tiene una o más solicitudes de SPEAK en estado PENDIENTE o EN CURSO , todas las solicitudes de SPEAK DEBEN cancelarse, incluido el estado Está en proceso. La respuesta a una solicitud STOP contiene los ID de solicitud de todas las solicitudes SPEAK terminadas en el valor Active-Request-Id-List . Después de enviar una respuesta STOP, el servidor NO DEBE enviar ningún evento SPEAK-COMPLETE o RECOGNITION-COMPLETE para la solicitud terminada .

active-request-id-list  =  "Active-Request-Id-List" ":"
                             request-id *("," request-id) CRLF

6.2.4. Proxy-Sync-Id

Cuando cualquier recurso del servidor genera un evento " barge -in-able " , también genera una etiqueta única . El token se envía al cliente en el evento como el valor de este campo de encabezado. Luego, el cliente actúa como intermediario entre los recursos del servidor y envía un método BARGE-IN-OCCURRED al recurso del servidor de síntesis (de voz) utilizando el Proxy-Sync-Id recibido del recurso del servidor . Cuando los recursos del reconocedor (de voz) y del sintetizador (de voz) pertenecen a la misma sesión, pueden optar por trabajar juntos para lograr una interacción y una respuesta más rápidas. Aquí, el Proxy-Sync-Id ayuda al recurso que recibe el evento (mediado por el cliente) a decidir si este evento ha sido manejado por la interacción directa del recurso.

Este campo de encabezado solo puede aparecer en los métodos **evento (evento)** y BARGE-IN-OCCURRED . El nombre de este campo de encabezado contiene la palabra "proxy" solo por razones históricas y no implica que se trate de un servidor proxy.

proxy-sync-id    =  "Proxy-Sync-Id" ":" 1*VCHAR CRLF

6.2.5. Aceptar juego de caracteres

Ver [H14.2]. Esto especifica el juego de caracteres aceptable para las entidades devueltas en respuestas o eventos asociados con esta solicitud. Esto es útil para especificar el conjunto de caracteres que se usará en los resultados del lenguaje de marcado semántico de lenguaje natural (NLSML) de los eventos de RECONOCIMIENTO COMPLETO . Este campo de encabezado solo se usa para solicitudes .

6.2.6. Tipo de contenido

Ver [H14.17]. MRCPv2 admite un conjunto restringido de tipos de medios para el registro de contenido, incluido el marcado de voz , la gramática (gramma) y los resultados de reconocimiento (resultados de reconocimiento) . Los tipos de contenido aplicables a cada tipo de recurso MRCPv2 se especifican en la sección correspondiente del documento y se registran en el Registro de tipos de medios MIME mantenido por IANA. Se admite el tipo de contenido multiparte " multipart/mixed " para transmitir múltiplos del contenido anterior, en cuyo caso la parte del cuerpo NO DEBE contener ningún campo de encabezado específico de MRCPv2. Este campo de encabezado puede estar presente en todos los mensajes .

  content-type     =    "Content-Type" ":" media-type-value CRLF

   media-type-value =    type "/" subtype *( ";" parameter )

   type             =    token

   subtype          =    token

   parameter        =    attribute "=" value

   attribute        =    token

   value            =    token / quoted-string

6.2.7. ID de contenido

Este campo de encabezado contiene el ID o el nombre del contenido referenciable. Este campo de encabezado funciona de acuerdo con las especificaciones de RFC 2392 [RFC2392] y es necesario para eliminar la ambigüedad del contenido en mensajes de varias partes. En MRCPv2, cada vez que el cliente o el servidor almacene el contenido relevante, debe poder recuperarse utilizando esta ID. Se puede hacer referencia a dicho contenido más adelante en una sesión al abordarlo utilizando el esquema de URI de "sesión" descrito en la Sección 13.6. Este campo de encabezado puede estar presente en todos los mensajes .

6.2.8. Base de contenido

El encabezado de la entidad Content-Base se puede usar para especificar el URI base que se usa para resolver los URI relativos dentro de la entidad.

content-base      = "Content-Base" ":" absoluteURI CRLF

Tenga en cuenta, sin embargo, que el URI base para el contenido en un cuerpo de entidad se puede redefinir dentro de ese cuerpo de entidad. Un ejemplo de esto son los medios multiparte, que a su vez pueden contener múltiples entidades dentro de ellos. Este campo de encabezado puede estar presente en todos los mensajes .

6.2.9. Codificación de contenido

El encabezado de entidad de codificación de contenido se utiliza como modificador para el tipo de contenido. Si está presente, su valor indica qué codificaciones de contenido adicionales se han aplicado al cuerpo de la entidad y, por lo tanto, qué mecanismos de decodificación deben aplicarse para obtener el tipo de medio al que hace referencia el campo de encabezado Tipo de contenido. La codificación de contenido se utiliza principalmente para permitir la compresión de documentos sin perder la identidad de su tipo de medio subyacente. Tenga en cuenta que las sesiones SIP se pueden utilizar para determinar las codificaciones aceptadas (consulte la Sección 7). Este campo de encabezado puede estar presente en todos los mensajes.

content-encoding  = "Content-Encoding" ":"
                       *WSP content-coding
                       *(*WSP "," *WSP content-coding *WSP )
                       CRLF

Las codificaciones de contenido se definen en [H3.5]. Un ejemplo de su uso es Content-Encoding:gzip

Si se han aplicado múltiples codificaciones a una entidad, las codificaciones de contenido DEBEN enumerarse en el orden en que se aplicaron.

6.2.10. Ubicación del contenido

El encabezado de la entidad Content-Location PUEDE usarse para proporcionar la ubicación del recurso para la entidad contenida en el mensaje cuando se puede acceder a la entidad desde una ubicación separada del URI del recurso solicitado. Ver [H14.14].

content-location  =  "Content-Location" ":"
                        ( absoluteURI / relativeURI ) CRLF

El valor Content-Location es una declaración de la ubicación del recurso correspondiente a esta entidad en particular en el momento de la solicitud. Este campo de encabezado se utiliza únicamente con fines de optimización. Los destinatarios de este encabezado PUEDEN suponer que la entidad que se envía es la misma entidad que se recuperó o podría haberse recuperado del URI de ubicación de contenido .

Por ejemplo, si el cliente proporciona un marcado de sintaxis en línea y lo ha recuperado previamente de un URI, el URI se puede proporcionar como parte de la entidad mediante el campo de encabezado Ubicación de contenido. Esto permite que un recurso como un reconocedor busque en su caché para ver si esta gramática se ha recuperado, compilado y almacenado en caché previamente. En este caso, puede usar objetos de sintaxis previamente compilados para la optimización.

Si Content-Location es un URI relativo, el URI relativo se interpreta en relación con el URI de base de contenido . Este campo de encabezado puede estar presente en todos los mensajes.

6.2.11. Largancia de contenido

Este campo de encabezado contiene la longitud del contenido del cuerpo del mensaje (es decir, después del CRLF doble después del último campo de encabezado). A diferencia de HTTP, debe incluirse en todos los mensajes que llevan contenido más allá de los encabezados. Si falta, se supone un valor predeterminado de cero . De lo contrario, interpretar como en [H14.13]. Cuando un mensaje sin uso para el cuerpo del mensaje contiene un mensaje, es decir, la longitud del contenido no es cero, el receptor DEBE ignorar el contenido del cuerpo del mensaje. Este campo de encabezado puede estar presente en todos los mensajes.

content-length  =  "Content-Length" ":" 1*19DIGIT CRLF

6.2.12. Tiempo de espera de recuperación

Cuando un reconocedor (de voz) o un sintetizador (de voz) necesita recuperar un documento u otro recurso, este campo de encabezado controla los atributos de acceso URI correspondientes. Esto define un tiempo de espera para el contenido que el servidor puede necesitar para obtener a través de la red. El valor se interpreta como milisegundos y varía de 0 a un valor máximo específico de la implementación. Se recomienda a los servidores que tengan cuidado al aceptar valores de tiempo de espera prolongados. El valor predeterminado de este campo de encabezado es específico de la implementación. Este campo de encabezado puede aparecer en DEFINE-GRAMMAR, RECOGNIZE, SPEAK, SET-PARAMS o GET-PARAMS.

fetch-timeout       =   "Fetch-Timeout" ":" 1*19DIGIT CRLF

6.2.13. Control de caché

Si un servidor implementa el almacenamiento en caché de contenido, DEBE obedecer las reglas de corrección de caché de HTTP 1.1 [ RFC2616 ] al acceder y almacenar contenido almacenado en caché . En particular, los campos de encabezado "expires" y "cache-control" de los URI o documentos en caché DEBEN respetarse, teniendo prioridad sobre los valores predeterminados de Cache-Control establecidos por este campo de encabezado.

La directiva Cache-Control se usa para definir el algoritmo de almacenamiento en caché predeterminado en el servidor para una sesión o solicitud. El alcance de un comando se basa en el método por el cual se envía. Si esta directiva se envía en el método SET-PARAMS , se aplica a todas las solicitudes realizadas por el servidor para documentos externos durante esa sesión, a menos que sea anulada por el campo de encabezado Cache-Control de una solicitud individual.

Si se envían directivas para cualquier otra solicitud, solo se aplican a las solicitudes de documentos externos realizadas por el servidor para esa solicitud. Un campo de encabezado de control de caché vacío en el método GET-PARAMS es una solicitud al servidor para devolver la configuración actual de la directiva de control de caché en el servidor. Este campo de encabezado solo puede estar presente a pedido.

   cache-control    =    "Cache-Control" ":"
                         [*WSP cache-directive
                         *( *WSP "," *WSP cache-directive *WSP )]
                         CRLF

   cache-directive     = "max-age" "=" delta-seconds
                       / "max-stale" [ "=" delta-seconds ]
                       / "min-fresh" "=" delta-seconds

   delta-seconds       = 1*19DIGIT

Aquí, los segundos delta son un valor de tiempo decimal que especifica la cantidad de segundos transcurridos desde el momento en que el servidor recibió la respuesta del mensaje o los datos.

Las diferentes opciones de directivas de caché permiten a los clientes solicitar al servidor que anule el mecanismo de caducidad de caché predeterminado:

   max-age        Indicates that the client can tolerate the server
                  using content whose age is no greater than the
                  specified time in seconds.  Unless a "max-stale"
                  directive is also included, the client is not willing
                  to accept a response based on stale data.

   min-fresh      Indicates that the client is willing to accept a
                  server response with cached data whose expiration is
                  no less than its current age plus the specified time
                  in seconds.  If the server's cache time-to-live
                  exceeds the client-supplied min-fresh value, the
                  server MUST NOT utilize cached content.

   max-stale      Indicates that the client is willing to allow a server
                  to utilize cached data that has exceeded its
                  expiration time.  If "max-stale" is assigned a value,
                  then the client is willing to allow the server to use
                  cached data that has exceeded its expiration time by
                  no more than the specified number of seconds.  If no
                  value is assigned to "max-stale", then the client is
                  willing to allow the server to use stale data of any
                  age.

Si se le solicita a un caché de servidor que use respuestas/datos obsoletos no validados, solo lo hará si esto no entra en conflicto con ningún requisito de nivel "obligatorio" con respecto a la validación de caché (por ejemplo, directivas de control de caché "debe revalidar"). hecho de acuerdo con la especificación HTTP 1.1 asociada con el URI correspondiente).

Si tanto la directiva de control de caché de MRCPv2 como la entrada de caché en el servidor contienen una directiva de "edad máxima", se usa el menor de los dos valores para determinar la actualización de la entrada de caché para esa solicitud.

6.2.14. Etiqueta de registro

Este campo de encabezado se puede enviar como parte de los métodos SET-PARAMS/GET-PARAMS para establecer o recuperar etiquetas de registro para registros generados por el servidor. Una vez establecido, el valor persiste hasta que se establece un nuevo valor o finaliza la sesión. Los servidores MRCPv2 pueden proporcionar un mecanismo para crear subconjuntos de sus registros de salida para que los administradores del sistema puedan examinar o extraer solo la parte del archivo de registro durante el cual el indicador de registro se establece en un valor específico.

Se recomienda a los clientes que incluyan información que identifique al agente de usuario del cliente MRCPv2 en la información de la etiqueta de registro para que pueda determinar qué solicitud de cliente MRCPv2 generó un mensaje de registro determinado en el servidor. También se recomienda a los clientes de MRCPv2 que no registren información de identificación personal, como números de tarjetas de crédito y números de identificación nacional.

logging-tag    = "Logging-Tag" ":" 1*UTFCHAR CRLF

6.2.15. Establecer-Cookie

Dado que el cliente HTTP asociado en el servidor MRCPv2 obtiene documentos para procesarlos en nombre del cliente MRCPv2, el almacenamiento de cookies en el cliente HTTP del servidor MRCPv2 se considera una extensión del almacenamiento de cookies en el cliente HTTP del cliente MRCPv2.

Esto requiere que los clientes y servidores MRCPv2 puedan sincronizar sus almacenes de cookies comunes según sea necesario. Para que un cliente MRCPv2 pueda enviar su cookie almacenada al servidor MRCPv2 y obtener una nueva cookie del servidor MRCPv2 para almacenarla nuevamente en el cliente MRCPv2, el campo de encabezado de entidad Set-Cookie se puede incluir en la solicitud de MRCPv2 para actualizar la cookie almacenada en el servidor y en Returned en la respuesta o evento final de MRCPv2 para actualizar posteriormente el propio almacén de cookies del cliente. Las cookies almacenadas en el servidor persisten durante una sesión de MRCPv2 y deben destruirse al final de la sesión. Para garantizar la compatibilidad con cookies, los clientes y servidores de MRCPv2 deben admitir el campo de encabezado de entidad Set-Cookie.

Tenga en cuenta que es el cliente MRCPv2 el que decide qué cookies (si las hay) se envían al servidor. No es necesario compartir todas las cookies. En su lugar, se recomienda que los clientes de MRCPv2 transmitan solo las cookies que el servidor de MRCPv2 necesita para procesar sus solicitudes.

 set-cookie      =       "Set-Cookie:" cookies CRLF
 cookies         =       cookie *("," *LWS cookie)
 cookie          =       attribute "=" value *(";" cookie-av)
 cookie-av       =       "Comment" "=" value
                 /       "Domain" "=" value
                 /       "Max-Age" "=" value
                 /       "Path" "=" value
                 /       "Secure"
                 /       "Version" "=" 1*19DIGIT
                 /       "Age" "=" delta-seconds
 set-cookie        = "Set-Cookie:" SP set-cookie-string
 set-cookie-string = cookie-pair *( ";" SP cookie-av )
 cookie-pair       = cookie-name "=" cookie-value
 cookie-name       = token
 cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
 cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
 token             = <token, defined in [RFC2616], Section 2.2>
 cookie-av         = expires-av / max-age-av / domain-av /
                      path-av / secure-av / httponly-av /
                      extension-av / age-av
 expires-av        = "Expires=" sane-cookie-date
 sane-cookie-date  = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
 max-age-av        = "Max-Age=" non-zero-digit *DIGIT
 non-zero-digit    = %x31-39
 domain-av         = "Domain=" domain-value
 domain-value      = <subdomain>
 path-av           = "Path=" path-value
 path-value        = <any CHAR except CTLs or ";">
 secure-av         = "Secure"
 httponly-av       = "HttpOnly"
 extension-av      = <any CHAR except CTLs or ";">
 age-av            = "Age=" delta-seconds

El campo de encabezado Set-Cookie se especifica en RFC 6265 [RFC6265]. El atributo " Edad " se introduce en esta especificación para indicar la edad de la cookie y es opcional. Un cliente o servidor MRCPv2 DEBE calcular la edad de la cookie de acuerdo con las reglas de cálculo de edad en la especificación HTTP/1.1 [RFC2616] y agregar el atributo " Edad " en consecuencia . Esta propiedad se proporciona porque puede haber pasado algún tiempo desde que el cliente recibió la cookie del servidor HTTP.

En lugar de hacer que el cliente disminuya Max-Age por su edad real, pasa Max-Age textualmente con un atributo "Edad" adjunto, manteniendo así la cookie recibida sin dejar de tener en cuenta el hecho de que ha pasado el tiempo.

Los clientes o servidores MRCPv2 DEBEN proporcionar valores predeterminados para los atributos " Dominio " y " Ruta ", como se especifica en RFC 6265, si el servidor de origen HTTP los omite. Tenga en cuenta que en este caso no hay un punto inicial en el valor del atributo "Dominio". Un cliente o servidor MRCPv2 NO DEBE modificar el valor de "dominio" cuando se recibe a través del protocolo MRCPv2, aunque un valor de "dominio" especificado explícitamente recibido a través del protocolo HTTP puede modificarse para incluir un punto inicial.

Un cliente o servidor MRCPv2 PUEDE combinar varios campos de encabezado de cookie del mismo tipo en un par "nombre de campo: valor de campo", como se describe en la Sección 6.2.

El campo de encabezado Set-Cookie se puede especificar en cualquier solicitud que posteriormente haga que el servidor realice un acceso HTTP. Cuando un servidor recibe nueva información de cookies de un servidor de origen HTTP, suponiendo que el almacén de cookies se haya modificado de acuerdo con RFC 6265, el servidor DEBE devolver nueva información de cookies en una respuesta o evento MRCPv2 COMPLETO según sea necesario para permitir que el cliente actualice sus propias cookies. comercio.

Una solicitud SET-PARAMS puede especificar un campo de encabezado Set-Cookie para actualizar el almacén de cookies en el servidor. Se puede utilizar una solicitud GET-PARAMS para devolver todo el almacén de cookies para una cookie de tipo "Set-Cookie" al cliente.

6.2.16. Parámetros específicos del proveedor

Este conjunto de campos de encabezado permite a los clientes establecer o recuperar parámetros específicos del proveedor.

   vendor-specific          =    "Vendor-Specific-Parameters" ":"
                                 [vendor-specific-av-pair
                                 *(";" vendor-specific-av-pair)] CRLF

   vendor-specific-av-pair  = vendor-av-pair-name "="
                              value

   vendor-av-pair-name     = 1*UTFCHAR

Esta forma de campo de encabezado se puede enviar en cualquier método (solicitud) y se usa para administrar parámetros específicos de implementación en el lado del servidor.
proveedor-av-pair-name sigue las convenciones de nombres de dominio de Internet inversas (consulte la Sección 13.1.6 para obtener información sobre la sintaxis y el registro). El valor del atributo del proveedor se especifica después del signo "=" y se puede citar. Por ejemplo:

   com.example.companyA.paramxyz=256
   com.example.companyA.paramabc=High
   com.example.companyB.paramxyz=Low

Cuando se usa en GET-PARAMS para obtener los valores actuales de estos parámetros del servidor, este valor de campo de encabezado puede contener una lista separada por punto y coma de nombres de propiedad específicos de la implementación.