El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe los FAQ para el servidor del sentido de los medios de Cisco.
Cisco recomienda que tenga conocimiento sobre estos temas:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
Cisco MediaSense 10.5
En Cisco MediaSense, los meta datos para cada llamada proporcionan solamente el xRefCi (ID de llamada de la referencia) y la referencia del dispositivo (extensión) del dispositivo que bifurca y del dispositivo en el extremo (puede ser un Bridge de conferencia o cualquier otro teléfono).
El parámetro del xRefCi es el identificador del administrador unificado de la comunicación para una secuencia de los medios en particular. No corresponden siempre 1:1 con las pistas registradas.
MediaSense genera a las sesiones múltiples para una llamada que se registre en caso del control/del curriculum vitae o de la transferencia, que hacen difícil identificar todas las sesiones de la grabación en una llamada. Para poder asociar estas sesiones de la grabación en una sola llamada, MediaSense introduce una nueva función llamada como asociación de la llamada. A través de esta característica, todas las llamadas fuertemente asociadas con un valor común del xRefci se agrupan juntas. MediaSense 10.5 soporta la característica de la asociación de la llamada para las grabaciones del Construir-en-Bridge.
Hay dos sesiones de registración para este escenario:
MediaSense no registra el segmento de la llamada mientras que el agente ha puesto la llamada en el control.
La llamada entera se registra en una sesión para este escenario:
En este escenario MediaSense también registra el segmento de la llamada mientras que el cliente ha puesto la llamada en el control.
Con el administrador 9.x de las Comunicaciones unificadas y anterior, aquí están los resultados:
el C 1.Caller (extn 2000) llama el agente A (extn 1000)
El s1 de la sesión COMENZADO, la pista 0 es A (extn 1000), la pista 1 es C (extn 2000).
las transferencias 2.Agent A (extn 1000) llaman a otro agente B (extn 3000). Los dispositivos A y B se configuran para bifurcar.
el C 3.Caller (extn 2000) oye la música en el control (moh).
4.Agent A (extn 1000) habla con B (extn 3000).
Consideraciones:
5.Agent A (extn 1000) completa la transferencia.
6.C (extn 2000) que habla con B (extn 3000).
7.A (extn 1000) desconectó.
S2 de la sesión TERMINADO.
La sesión S3 ACTUALIZADA, y la pista 0 es B (extn 3000) y la pista 1 es C (extn 2000).
Consideraciones:
Note: Una transferencia del otro extremo da lugar a una actualización de la sesión existente. El teléfono que bifurca sigue siendo el único participante en la pista 0, pero el participante en los cambios de la pista 1 al nuevo partido.
En caso del administrador 10.0 de las Comunicaciones unificadas y posterior, aquí está el resultado:
1. El C del llamador (extn 2000) llama el agente A (extn 1000).
El C (extn 2000) habla con el agente A (extn 1000). S1 de la sesión - COMENZADO - La pista 0 es A (extn 1000), la pista 1 es el C (2000)
2. El agente A (extn 1000) consulta el agente B (extn 3000).
3. El C (extn 2000) oye el moh. A (extn 1000) habla con B (extn 3000).
Consideraciones:
4. El agente A (extn 1000) completa la transferencia.
5. El C (extn 2000) habla con B (extn 3000).
6. A (extn 1000) desconectó.
Consideraciones:
7. El agente B (extn 3000) cuelga para arriba.
8. El C (extn 2000) y B (extn 3000) desconectaron.
Note: Una transferencia del otro extremo da lugar al final de una sesión de registración y al comienzo de otra sesión de la grabación.
En caso del administrador 9.x de las Comunicaciones unificadas y anterior, aquí está el resultado:
1. El C del llamador (extn 2000) llama el agente A (extn 1000).
2. El C (extn 2000) habla con A (extn 1000).
S1 de la sesión COMENZADO - La pista 0 es A (extn 1000), la pista 1 es C (extn 2000).
3. El agente A (extn 1000) consulta el agente B (extn 3000).
4. El C (extn 2000) oye las negociaciones del moh A (extn 1000) a B (extn 3000)
Consideraciones:
5. El agente A (extn 1000) completa la conferencia.
6. C (extn 2000) que habla con A (extn 1000) y B (extn 3000).
Consideraciones:
Una transferencia del otro extremo acciona una ACTUALIZACIÓN de la sesión existente de la grabación.
La realización de una conferencia se implementa:
Durante la consulta:
Cuando se completa la conferencia (todos los partidos conectados):
Como consecuencia:
7. El agente A (extn 1000) cae de la conferencia.
8. A (extn 1000) desconectó. C (extn 2000) que habla con la sesión S3 B (extn 3000) ACTUALIZADA - la pista 0 es B (extn 3000), la pista 1 es C (extn 2000).
Consideraciones:
9. El agente B (extn 3000) cuelga para arriba.
10. El C (extn 2000) y B (extn 3000) desconectaron.
Sesión S4 TERMINADA.
Consideraciones:
En caso del administrador 10.x de las Comunicaciones unificadas y posterior, aquí está el resultado:
1. El C del llamador (extn 2000) llama el agente A (extn 1000).
2. El C (extn 2000) que habla con el s1 de la sesión A (extn 1000) - COMENZADO - la pista 0 es A (extn 1000), la pista 1 es C (extn 2000).
3. El agente A (extn 1000) consulta el agente B (extn 3000).
4. Moh A (extn 1000) de la audición del C (extn 2000) que habla con B (extn 3000).
Consideraciones:
5. El agente A (extn 1000) completa la conferencia.
6. C (extn 2000) que habla con A (extn 1000) y B (extn 3000)
Consideraciones:
Una transferencia del otro extremo acciona el final de una sesión de registración y el comienzo de otra grabación. La realización de una conferencia se implementa enumeró aquí:
7. El agente A (extn 1000) cae de la conferencia
8. A (extn 1000) desconectó. C (extn 2000) que habla con B (extn 3000)
Consideraciones:
9. El agente B (extn 3000) cuelga para arriba
10. El C (extn 2000) y B (extn 3000) desconectaron
Consideraciones:
Con el elemento unificado de la frontera bifurcando, muy pocas situaciones hacen una llamada estar partidas en las sesiones múltiples de la grabación. Sosténgase/curriculum vitae, transferencia y las operaciones de la conferencia no comienzan las nuevas sesiones de la grabación en la mayoría de los casos. En pocos casos donde las nuevas sesiones se crean, hay un valor común, CCID (correlación de llamadas ID). Este valor es común a todas las sesiones en la llamada. CCID es la forma decimal de Cisco-GUID, una clave única de la llamada que sea generada por los routeres de voz de Cisco. El primer router que recibe una llamada genera esta clave, y la pasa abajo de la línea a todos los dispositivos subsiguientes incluyendo Cisco MediaSense.
El elemento unificado sí mismo de la frontera no genera los valores del xRefCi, pero crear la semejanza con las llamadas que bifurcan del teléfono del administrador de las Comunicaciones unificadas, Cisco MediaSense también sintetiza un par de valores del xRefCi para cada llamada unificada del elemento de la frontera. Éstos se pueden ver en los meta datos en el nivel de la pista, junto con CCID, que aparece en el nivel de la sesión.
La causa de estas situaciones unificó las grabaciones del elemento de la frontera que se partirán en las sesiones múltiples:
Si la transferencia, la conferencia, el descenso de la conferencia, o la otra operación hace los partidos renegociar su codificador-decodificador, Cisco MediaSense termina la sesión actual de la grabación y comienza un nuevo. Las dos sesiones comparten el mismo CCID y los mismos pares de valores del xRefCi.
Una transferencia de consultas es una transferencia a partir de un agente a otro, en las cuales los dos agentes hablan el uno al otro mientras que el llamante de origen espera en el control. La pierna de la consulta de la llamada se relaciona de cierta manera con la llamada total, y es posible configurar al administrador de las Comunicaciones unificadas tales que consulte las llamadas pasan a través del CUBO. Sin embargo, el elemento unificado y Cisco MediaSense de la frontera no saben que estas llamadas son relacionadas, y crean un nuevo CCID y un nuevo par de valores del xRefCi para esta sesión.
Estas llamadas se pueden asociar el uno con el otro a comparan de los campos del deviceRef y del grupo fecha/hora del participante. Considere este escenario:
La indicación roja en este escenario está en el paso 2. Durante ese período, el agente A (deviceRef 1000) es un participante en dos sesiones de registración inmediatamente:
Por lo tanto, el s1 se relaciona con el s2 y el c1 se relaciona con el C2.
Primero, necesitamos una definición clara de consultamos la llamada:
Cualquier llamada secundaria que sea hecha por un participante actual en una sesión existente a un punto final que sea el exterior que sesión y que excluye a los otros participantes en esa sesión.
En la teoría, este escenario podría incluir un agente coloca al llamador en el control para marcar con su jefe para la rotura del luch, o aún un agente puso al llamador en el control para recibir una llamada de su esposa, pero ignoramos esas posibilidades por ahora.
Es posible para que una aplicación de cliente detecte una llamada de la consulta en el tiempo real por la pista de la secuencia del evento de Cisco MediaSense. Si el cliente observa un evento COMENZADO sesión contiene un deviceRef dado, con otro evento COMENZADO sesión contiene el mismo deviceRef sin el evento TERMINADO sesión de intervención, puede concluir que los sessionIds y el CCIDs encontrados en los dos eventos COMENZADOS sesión son asociados.
Históricamente, un cliente puede marcar para saber si hay ningunos consulta las llamadas que se asocian a una llamada primaria dada, con Cisco MediaSense API. Asuma que el cliente conoce ese extn usado A 1000 del agente, en CCID <C1>. Este instrucciones de encontrar cualquier asociado para consultar las llamadas:
Paso 1. Extraiga los meta datos de la sesión para la llamada primaria publicando getSessionByCCID(<C1>).
Step2. Extraiga el sessionStartDate (llamada él <Ta>), y el sessionDuration.
Step3. Calcule el sessionEndDate (llamada él <Tb>) agregando el sessionDuration al <Ta>.
Step4. Ejecute esta petición API:
IP address:8443/ora/queryService/query/getSessionsByDeviceRef?value=1000&minSessionStartDate=<Ta>&maxSessionStartDate=<Tb> de https://Mediasense
Esta interrogación puede volver más de una sesión. Si lo hace, después todos se pueden asumir para ser asociado a la misma llamada.
El procedimiento mencionado adentro consulta la sección de la detección de llamada, encuentra todo para consultar las llamadas hechas del dispositivo que recibió las llamadas telefónicas iniciales. ¿Sin embargo, qué si allí consultan las llamadas se hacen de un dispositivo al cual la llamada fue transferida posteriormente?
Considere este procedimiento:
Este procedimiento no coge la llamada de la consulta entre el agente 2 y el agente 3.
Puesto que esto es una llamada unificada del elemento de la frontera, podemos hacer uso del hecho de que todas las conexiones entre el llamador y cada uno de los agentes están incluidas en la misma sesión de la grabación, y del hecho de que todos los agentes implicados están enumerados como participantes en la misma sesión en uno u otro momento. Así, de los meta datos primarios de la sesión, podemos recoger una lista de todos los deviceRefs que estaban implicados. Para encontrar esas sesiones, podemos hacer una serie de las llamadas al getSessionsByDeviceRef, especificamos el rango de tiempo de la sesión primaria, así como un deviceRef por la petición.
Alternativamente, el proceso se puede simplificar con una sola petición de los getSessions tal como esto:
{ "requestParameters": [ { "fieldName": "deviceRef", "fieldConditions": [ { "fieldOperator": "equals", "fieldValues": [ "1000" ], "fieldConnector": "OR" }, { "fieldOperator": "equals", "fieldValues": [ "2000" ], "fieldConnector": "OR" }, { "fieldOperator": "equals", "fieldValues": [ "3000" ], "fieldConnector": "OR" }, { "fieldOperator": "equals", "fieldValues": [ "4000" ] } ], "paramConnector": "AND" }, { "fieldName": "sessionStartDate", "fieldConditions": [ { "fieldOperator": "between", "fieldValues": [ <Ta>, // session start time <Tb>// session end time ] } ] } ] }
Esta interrogación vuelve todas las llamadas de la consulta asociadas a la llamada del primario original y a todas sus transferencias.
Este procedimiento echa realmente la red demasiado ampliamente. Si por ejemplo, el agente en el deviceRef 4000 condujo y terminó una llamada totalmente independiente que sucedió comenzar después de que <Ta> y antes de que lo agregaron a la llamada en la pregunta, este procedimiento incluye que independiente llame en el conjunto. Este problema se puede solucionar sin embargo, con la información disponible en los meta datos de la sesión primaria. La información de cada participante incluye el desplazamiento del tiempo en el cual él se unió a la sesión y la duración de su arrendamiento. El código de cliente podría utilizar que información para borrar simplemente las sesiones sin relación de la lista que recibió arriba. O, podría formular una serie de getSessions o de interrogaciones directos del getSessionByDeviceRef que enmarcan correctamente los períodos de tiempo durante los cuales cada agente estaba en la llamada primaria. Nos vamos que como ejercicio al lector.
En la sección precedente, presentamos los precedures para la extracción de todas las sesiones asociadas a una sesión dada de la grabación de Cisco MediaSense. Sin embargo, también hemos visto que una llamada dada se puede dividir en más de una sesión, como en el caso de un cambio del codificador-decodificador de la mediados de-llamada.
¿Cómo extraemos todas las grabaciones (así como consulta) asociadas a todas las sesiones conectadas con la interacción del llamador?
La respuesta es ampliar este las instrucciones para el detectiion del múltiplo consulta las llamadas. Primero, recogemos todas las sesiones que compartan el CCID de la sesión primaria en la pregunta. Entonces, construimos nuestra lista de participantes de todos esos expedientes de la sesión. Después, calculamos los rangos de tiempo como el sessionStartDate de la sesión más temprana a través del final de la última sesión. pasado, podemos ejecutar la interrogación de los getSessions mostrada.
Como antes, podemos terminar para arriba con la captura de demasiadas grabaciones, así que podríamos ejecutar un paso del postprocessing para borrar esas sesiones sin relación de su lista.
Estas dos tablas — uno para el administrador de las Comunicaciones unificadas llama y uno para el elemento unificado de la frontera llama. Cada columna representa a un componente de solución o el protocolo, con la primera columna representa Cisco MediaSense. Cada fila representa un tipo determinado de identificador.
Para leer las tablas, comience con una célula que represente el elemento de datos que usted conoce, y después mire a la columna represente horizontalmente al componente de solución en quien usted quiere encontrar la llamada. La entrada en esa célula indica por qué nombre se conoce el exacto el mismo elemento de datos en el componente de la blanco. Si el componente de la blanco tiene una célula en blanco en esa fila, después ese elemento de datos no se sabe a ese componente. Usted puede en lugar de otro buscar una columna de intervención donde usted puede cruzar verticalmente en otra fila donde no está en blanco esa célula en la columna del componente de la blanco.
Por ejemplo, con una llamada del administrador de las Comunicaciones unificadas, asuma que usted conoce el GED-188 CallReferenceID y que usted quiere encontrar la llamada en Cisco MediaSense. Marque a la izquierda de la columna del GED-188, usted ven que no hay valor en la columna de MediaSense, así que usted no puede asociar directamente a ella.
Sin embargo, hay una columna donde usted puede zigzaguear a través de las filas: Administrador CDR de las Comunicaciones unificadas. Un cliente puede seleccionar el registro CDR apropiado del administrador de las Comunicaciones unificadas buscando para uno en el cual el IncomingProtocolCallRef haga juego el GED-188 CallReferenceID. Que el expediente contiene un valor llamaron más destLegCallIdentifier, que es lo mismo que el xRefCi de MediaSense NearEnd, y se pueden por lo tanto utilizar para encontrar el expediente correspondiente en Cisco MediaSense.
Los registros CDR del administrador de las Comunicaciones unificadas no se escriben hasta una cierta hora después de que el final de la llamada termine, sin embargo, así que este método se puede utilizar solamente históricamente.
Hay otra trayectoria también. Mire hacia abajo del GED-188 CallReferenceID. Resulta que usted puede también utilizar el AlertingDevice y el AnsweringDevice para hacer juego el campo del deviceRef en MediaSense. Este método también trabaja en el tiempo real.
Consideraciones:
Para el CUBO llama, sigue 0 asocia siempre a la secuencia de medios de la pierna del ancla. La pierna del ancla es el dial-peer que el perfil de la grabación de los media se configura. La segunda pierna del NON-ancla de las correspondencias de la pista.
Si usted tiene perfil de la grabación de los media habilitado en el dialpeer entrante, después la pierna del ancla se convierte en la en-pierna. Es decir la parte llamadora aparece en la pista 0, y la Parte llamada aparece en la pista 1.
Si usted tiene perfil de la grabación de los media habilitado en el dialpeer saliente, después la pierna del ancla se convierte en la hacia fuera-pierna. En ese caso la parte llamadora aparece en la pista 1 y la Parte llamada aparece en la pista 0.
Para el CM unificado que bifurca, en los escenarios de llamada simples usted puede utilizar los campos del xRefCi en los meta datos para determinar qué partido está en qué media siga. El xRefCi numéricamente más pequeño refiere generalmente a la pista de la parte llamadora. La pista de la Parte llamada es numéricamente más grande (generalmente por una, pero ellos podrían estar más conforme razonablemente a un sistema cargado). Sin embargo, estos valores del xRefCi envuelven eventual alrededor a cero. Así pues, si usted encuentra que un valor es un número alto y el otro es un pequeño número, usted asume que sus posiciones están invertidas.
En escenarios más complicados, este algoritmo no trabaja siempre. Si invocan los servicios suplementarios, por ejemplo las transferencias y las conferencias, y el cluster del administrador UC consiste en más de un nodo, después los valores del xRefCi no se generan necesariamente secuencialmente, y usted no puede asumir que su orden tiene cualquier significado en absoluto. Una forma directa de determinar si la secuencia que ordena de un par determinado de valores del xRefCi puede ser confiada en es mirar el primer byte de los valores del xRefCi. Este byte representa el ID del nodo del administrador UC en el cual ese identificador determinado fue creado. Si los primeros bytes de los dos valores del xRefCi son lo mismo, después su ordenar está correcto. Si son diferentes, después el ordenar no pudo estar correcto.
Para estos casos, la única manera de determinar a la dirección de la llamada en el tiempo real es adquirir la información de cualquier otra fuente, tal como la alimentación del evento JTAPI. La llamada ha terminado una vez y algunos minutos han transcurrido, usted puede determinar siempre los datos CDR del administrador UC de la dirección de la llamada y del control para la llamada. Específicamente, el campo más origLegCallIdentifier en el registro CDR representa siempre al llamador.
Las posibles causas para un estado de la sesión de CLOSED_ERROR incluyen:
1. El servidor del Control de llamadas recibió una respuesta de error del servidor de los media (grabación) para la petición abierta o cercana.
2. El servidor del Control de llamadas detectó un error de la señalización del SORBO, por ejemplo un ACK que falta.
3. La sesión fue cerrada con éxito, pero TODAS LAS pistas tienen tamaño cero.
Cuando una sesión está en el estado ACTIVO, es normal que no hay duración en los meta datos, porque la duración no se sabe hasta que la sesión sea cerrada.
Para una sesión que esté en el estado CLOSED_ERROR, si los campos de la sesión o de la duración de la pista no están presentes en el evento o los datos de los getSessions, después el media para esta pista no está disponible.
Considere estas dos interrogaciones:
Esta interrogación vuelve un conjunto de las sesiones, todos cuyos de estados de la sesión SE BORREN:
https://Mediaserver IP address:8443/ora/queryService/query/getAllPrunedSessions?minSessionStartDate=1301788800000&maxSessionStartDate=1312329599000
Esta interrogación no vuelve ninguna sesión:
https://MediaServer IP address:8443/ora/queryService/query/getSessions { "requestParameters": [{ "fieldName" : "sessionState", "fieldConditions": [{ "fieldOperator" : "equals", "fieldValues" : [ "DELETED" ] }], "paramConnector" : "AND" }, { "fieldName" : "sessionStartDate", "fieldConditions": [{ "fieldOperator" : "between", "fieldValues" : [ "1301788800000", "1312329599000" ] }] }] }
La diferencia del comportamiento está por el diseño. Refiera a esto las secciones en la documentación de MediaSense:
Utilice este API para buscar todas las grabaciones podadas… que el término podado refiere a las grabaciones que son borradas por el sistema de Cisco MediaSense. Si usted ha borrado explícitamente cualquier grabación usando los deleteSessions API, después estas grabaciones borradas no se consideran como grabaciones podadas.
Cuando se podan las sesiones, sigue habiendo los meta datos que se asocia a estas sesiones en la base de datos, incluso después estas sesiones se marcan como “podado”. Este los meta datos no toman una gran cantidad de espacio para almacenar comparado a las grabaciones ellos mismos sino que toma un cierto espacio y debe ser quitado periódicamente. Para ayudar en esta actividad, los clientes pueden publicar periódicamente un pedido API las sesiones podadas, o los clientes pueden elegir para recibir los eventos podados sesión y para borrar explícitamente esos eventos que los clientes necesiten no más.
Para aclarar, las dos interrogaciones son totalmente diferentes. De hecho, la segunda interrogación (el lwhich busca todas las sesiones cuyo SE BORRE estado) vuelve siempre un conjunto vacío. Las interrogaciones cotidianas normales filtran hacia fuera las sesiones con los estados BORRADOS, incluso si eso es se pide qué. La única excepción es getAllPrunedSessions. Esta excepción se piensa para ayudar a la aplicación para encontrar las sesiones podadas de modo que la aplicación pueda pedir que estas sesiones estén borradas.
Una vez que usted utiliza los deleteSessions API en la lista de sesiones podadas que usted consigue de los getAllPrunedSessions, estas sesiones aparecen no más en el resultado de los getAllPrunedSessions. Tales sesiones se quitan totalmente de los meta datos inmediatamente.
Otra manera de mirar esto es que las sesiones podadas no son la misma cosa que las sesiones borradas:
Cuando usted tiene un gateway PSTN a través del cual llame los flujos, y le quiera registrar esas llamadas. Estas llamadas son llamadas del TDM-a-SORBO. Sin embargo, el bifurcar de los media está solamente disponible en las llamadas del Sorbo-a-SORBO.
Estas llamadas pueden ser registradas. Estas llamadas pueden dirigido a través del router al por segunda vez. El guía para la configuración y otros detalles pueden ser encontrados en este White Paper.
Cuando usted utiliza los media que bifurcan del CUBO, los meta datos de MediaSense contienen normalmente la extensión de la Parte llamada. Sin embargo, si el número llamado es un número piloto de grupo Hunt del administrador de comunicaciones, después por abandono los meta datos contienen solamente ese número piloto. No contiene la extensión del teléfono que contestó realmente a la llamada.
Hay una configuración del administrador de comunicaciones que puede cambiar esto. En la caza/la página de configuración del piloto, encuentre la sección dada derecho las transformaciones conectadas del partido. El miembro DN del grupo de mostrar línea de la configuración como partido conectado debe ser girado.
Esta capacidad está disponible en el administrador de comunicaciones 9.0(1) y posterior.
Con la grabación Basada en red del administrador de las Comunicaciones unificadas (NBR), usted puede utilizar un gateway para registrar las llamadas. NBR permite que el administrador de las Comunicaciones unificadas rutee las llamadas de la grabación, sin importar el dispositivo, la ubicación, o la geografía. Con NBR, los media de la grabación de la llamada pueden ser originados del teléfono del IP o de un gateway que esté conectado con el administrador de las Comunicaciones unificadas sobre un trunk SIP. El administrador de las Comunicaciones unificadas selecciona dinámicamente la fuente correcta de los media basada en los participantes del flujo de llamada y de la llamada.
NBR ofrece un Construir-en-Bridge automático del retraso (babero) cuando el Routers de los Servicios integrados (ISR) es inasequible pues no se requiere ninguna configuración de registración separada. Esto es útil en caso de que los clientes quieran incluir el agente-agente consulten las llamadas en las directivas de grabación pues el elemento unificado de la frontera no puede registrar consulta las llamadas, así que el babero necesita ser habilitado por separado.
NBR y las llamadas del babero se pueden correlacionar usando el xRefci, que es disponible desde el administrador JTAPI de las Comunicaciones unificadas. CISCO-GUID no es necesario, que significa que ni el CTI Server ni las conexiones CTIOS está requerido. Pues hay un solo identificador de la correlación, la correlación a través de los componentes es más fuerte y se puede hacer en una independiente uniforme de la manera del flujo de llamada.
Con NBR, directo-marcado así como las llamadas de salida marcador-iniciadas se pueden correlacionar con su aspecto en los componentes de la otra solución.
Con NBR, la grabación del gateway TDM se utiliza automáticamente sin la fractura de la capacidad del router. Actualmente, la grabación del gateway TDM no se soporta con MediaSense 10.5.
Un nodo puede tardar varias horas para actualizar depende del número y del tamaño de las grabaciones que lleva a cabo. Para MediaSense 10.5, cuando usted actualiza un nodo con los conjuntos de datos muy grandes, tarda alrededor 90 minutos adicionales por 1 millón de grabaciones.
Los usuarios del MediaSense buscan y la aplicación del juego es afectada si están situados en los husos horarios afectados uces de los o si seleccionan un huso horario afectado en los criterios de búsqueda. Los Productos del partner del otro vendedor que interconectan con MediaSense se afectan semejantemente hasta que pongan al día sus tablas respectivas del huso horario.
La solución alternativa es seleccionar un huso horario que haga juego el desplazamiento correcto del GMT incluso si la ciudad está no más correcta.
Aquí están los lenguajes soportados por MediaSense:
Para monitorear el rendimiento del sistema de MediaSense, analice los valores de estos indicadores de rendimiento clave (KPIs) con RTMT la herramienta de la garantía de la herramienta o de la Colaboración de la prima de Cisco.
Para más información sobre RTMT la herramienta primera de la garantía de la herramienta o de la Colaboración de Cisco, refiera RTMT unificadas las secciones primeras de la administración de la garantía de la administración y de la Colaboración de Cisco del guía del usuario de Cisco MediaSense.
Indicador de rendimiento clave | RTMT contadores | Valores de umbral sugeridos |
---|---|---|
Pocentaje de llamadas exitosas | Servicio de Control de llamadas de MediaSense > número de sesiones de la grabación sin los errores Servicio de Control de llamadas de MediaSense > número de sesiones de la grabación con los errores |
99.99% Pocentaje de llamadas exitosas = número de sesiones de la grabación sin los errores/(número de sesiones de la grabación sin los errores + el número de sesiones de la grabación con los errores) * 100 |
Tiempo intermedio de la respuesta API para el API | Tiempo de respuesta de la interrogación del servicio > del medio de Cisco MediaSense API | 60 secs |
Retardo de la configuración del medio del comienzo de grabación | Retardo de la configuración del servicio > del medio de Control de llamadas de Cisco MediaSense | 3 secs |
Utilización del medio CPU | Procesador > % hora de la CPU | 90% |
Utilización mala de la memoria | Memoria > %Mem usado | el 70% |
Caída de paquetes RTP/UDP | Interfaz de la red > rx caído > eth0 Interfaz de la red > errores > eth0 del rx |
0 0 |
De acuerdo con el navegador, realice estos pasos para funcionar con al jugador del en-navegador:
Internet Explorer 9 | Internet Explorer 11 | Mozilla Firefox |
---|---|---|
1. En la búsqueda y el juego de MediaSense, haga clic el icono del juego de una sesión de la grabación. | Requisitos previos: En caso de fresco instale de MediaSense 11.0, se aseguran de que los Nodos de MediaSense están agregados al cluster usando el nombre de dominio completo (FQDN) respectivo. En caso de una actualización a MediaSense 11.0, asegúrese de que los Nodos de MediaSense que fueron agregados previamente usando el nombre de host, ahora sean visualizados por el FQDN respectivo. Marque la lista de servidores de MediaSense en la ventana de la Configuración del servidor de MediaSense (la administración de Cisco MediaSense > sistema > Configuración del servidor de MediaSense). |
1. Agregue el certificado autofirmado de un nodo de MediaSense para el puerto 8446 de mp4url en la autoridad confiada en de Firefox del Mozilla. |
2. Haga clic sí para confiar en el certificado. Nota: Verifique que el certificado autofirmado ofrecido esté del nodo apuntado de MediaSense validando el FQDN en los detalles técnicos del certificado. |
Siga los pasos descriptos a continuación: 1. Fije el hostnameformediaurl CLI del conjunto como “verdad” para hacer que MediaSense prepara el mp4url y el resto de los mediaurls usando el FQDN solamente. admin:set useHostNameForMediaURL admin:set useHostNameForMediaURL true 2. Recomience el Servicio de configuración para activar la propiedad. admin:utils service restart Cisco MediaSense Configuration Service Nota: Si el servicio no ha recomenzado correctamente, ejecute el mismo comando otra vez. |
2. Para agregar el certificado autofirmado, haga clic el icono de la descarga de una sesión de la grabación y seleccione mp4. Esta conexión es ventana emergente untrusted aparece. |
3. Haga clic el icono del juego correspondiente a la grabación seleccionada. El jugador del en-navegador juega la sesión de registración seleccionada. |
Realice los pasos siguientes para agregar el certificado autofirmado de MediaSense a Windows confiaba en la autoridad. 1. Abra la búsqueda y el juego de MediaSense. The import was successful. 12. Click OK. |
2. Para agregar el certificado autofirmado, haga clic el icono de la descarga de una sesión de la grabación y seleccione mp4. Esta conexión es ventana emergente untrusted aparece. Nota: Verifique que el certificado autofirmado ofrecido esté del nodo apuntado de MediaSense validando el FQDN en los detalles técnicos del certificado. |
3. El tecleo I entiende el link de los riesgos. | ||
4. El tecleo agrega la excepción. La ventana emergente de la excepción de seguridad del agregar aparece. |
||
5. El tecleo confirma la excepción de seguridad. El certificado autofirmado del nodo determinado MS del puerto 8446 consigue agregado a la autoridad confiada en del navegador. |