FAQ para Cisco MediaSense

Introducción

Este documento describe los FAQ para el servidor del sentido de los medios de Cisco. 

Prerequisites

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

• Cisco MediaSense
• Cisco unificó al administrador de la comunicación (CUCM)

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

Cisco MediaSense 10.5

1. ¿Cómo usted correlaciona los ID de llamadas de la referencia para diversos escenarios de llamada, bajo bifurcar del teléfono del administrador de las Comunicaciones unificadas?

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.

1.1. La búsqueda y el juego de MediaSense llaman la característica de la asociación

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.

1.2. Control del agente/escenario del curriculum vitae

1. El agente A (extn 1000) y el C del llamador (extn 2000) se llamaron y en el estado que hablaba.
2. El agente A pone invita al control.
3. Llamada de los curriculums vitae del agente A.

Hay dos sesiones de registración para este escenario:

• La sesión con el sessionId = el s1 con estas dos pistas, porque el período de tiempo /segment antes del agente pone invitan al control:
  trackNumber = 0 con el participante A (deviceRef = 1000, xRefCi = aaaa)
  trackNumber = 1 con el participante B (deviceRef = 2000, xRefCi = cccc)
• Sesión con el sessionId = el s2 con estas dos pistas, porque el período de tiempo/el segmento después de que el agente reanude la llamada.
  trackNumber = 0 con el participante A (deviceRef = 1000, xRefCi = aaaa)
  trackNumber = 1 con el participante B (deviceRef = 2000, xRefCi = cccc)

MediaSense no registra el segmento de la llamada mientras que el agente ha puesto la llamada en el control.

1.3. Control del cliente/escenario del curriculum vitae

1. El agente A (extn 1000) y el C del llamador (extn 2000) alled y en el estado que hablaba.
2. El C del cliente pone invita al control.
3. Llamada de los curriculums vitae del C del cliente.

La llamada entera se registra en una sesión para este escenario:

• Sesión con el sessionId = el s1 con estas dos pistas:
  trackNumber = 0 con el participante A (deviceRef = 1000, xRefCi = aaaa)
  trackNumber = 1 con el participante B (deviceRef = 2000, xRefCi = cccc)

En este escenario MediaSense también registra el segmento de la llamada mientras que el cliente ha puesto la llamada en el control.

1.4. Transferencia del agente a otro escenario del agente 

1. El C del llamador (extn 2000) llama el agente A (extn 1000)
2. El agente A (extn 1000) consulta con el agente B (3000)
3. El agente A (extn 1000) completa la transferencia.
4. El agente B (extn 3000) cuelga para arriba.

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).

• S1 de la sesión TERMINADO
• El s2 de la sesión COMENZADO, la pista 0 es A (extn 1000), la pista 1 es B (extn 3000)
• La sesión S3 COMENZADA, la pista 0 es B (extn 3000), la pista 1 es A (extn 1000)

Consideraciones:

• Los extremos del s1 de la sesión debido al teléfono del agente A han colocado el C del llamador en el control.
• El s2 de las sesiones y el S3 existen porque ambos teléfonos se configuran para bifurcar.
• Los participantes y el xRefCi para los dos participantes en el s2 y el S3 son idénticos, pero en las posiciones reversas de uno a.
• los valores del xRefCi del s1 no se reflejan en el s2 o el S3, puesto que la consulta se considera una llamada independiente.

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:

• Una transferencia del otro extremo acciona una ACTUALIZACIÓN de la sesión existente de la grabación.
• El participante del otro extremo cambia al del s1.
• El nuevo xRefCi del otro extremo S3 hace juego el xRefCi del otro extremo del s1.
• El agente B (extn 3000) cuelga para arriba.
• El C (extn 2000) y B (extn 3000) son disconnected.
•   Sesión S3 TERMINADA

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).

• S1 de la sesión - TERMINADO
• S2 de la sesión - COMENZADO - La pista 0 es A (extn 1000), la pista 1 es B (extn 3000)
• Sesión S3 - COMENZADO - La pista 0 es B (extn 3000), la pista 1 es A (extn 1000)

Consideraciones:

• El s1 de la sesión termina porque el teléfono del agente A ha colocado el C del llamador en el control.
• El s2 y el S3 ambos de las sesiones existen porque ambos teléfonos se configuran para bifurcar.
• Los participantes así como el xRefCi para los dos participantes en el s2 y el S3 son idénticos pero en las posiciones invertidas de uno a.
• Los valores del xRefCi del s1 no se reflejan en el s2 o el S3, puesto que la consulta se considera una llamada independiente

4. El agente A (extn 1000) completa la transferencia.

5. El C (extn 2000) habla con B (extn 3000).
6. A (extn 1000) desconectó.

• Sesión S3 - TERMINADO
• S2 de la sesión - TERMINADO
• Sesión S4 - COMENZADO - La pista 0 es B (extn 3000), la pista 1 es C (extn 2000)

Consideraciones:

• Una transferencia del otro extremo acciona el final de una sesión de registración y el comienzo de otra sesión de la grabación.
• Aunque una nueva sesión comienza, sus valores del xRefCi harán juego las sesiones anteriores.
• El xRefCi del otro extremo S4 hace juego el xRefCi del otro extremo del s1, y el xRefCi del final cercano S4 hace juego el xRefCi del final cercano S3.

7. El agente B (extn 3000) cuelga para arriba.

8. El C (extn 2000) y B (extn 3000) desconectaron.

• Sesión S4 - TERMINADO

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.

1.5. Conferencias del agente con otro escenario del agente 

1. El C del llamador (extn 2000) llama el agente A (extn 1000).
2. El agente A (extn 1000) consulta el agente B (extn 3000).
3. El agente A (extn 1000) completa la conferencia.
4. El agente A (extn 1000) cae de la conferencia.
5. El agente B (extn 3000) cuelga para arriba.

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)

• S1 de la sesión TERMINADO
• S2 de la sesión COMENZADO - La pista 0 es A (extn 1000), la pista 1 es B (extn 3000)
• Sesión S3 COMENZADA - La pista 0 es B (extn 3000), la pista 1 es A (extn 1052

Consideraciones:

• El s1 de la sesión termina porque el teléfono del agente A ha colocado el C del llamador en el control.
• El s2 de las sesiones y el S3 existen porque ambos teléfonos se configuran para bifurcar.
• Los participantes así como el xRefCi para los dos participantes en el s2 y el S3 son idénticos pero en las posiciones invertidas de uno a.
• Los valores del xRefCi del s1 no se reflejan en el s2 o el S3, puesto que la consulta se considera una llamada independiente.

5. El agente A (extn 1000) completa la conferencia.

6. C (extn 2000) que habla con A (extn 1000) y B (extn 3000).

• S2 de la sesión TERMINADO
• Sesión S3 ACTUALIZADA - La pista 0 es B (extensión 3000), la pista 1 es Bridge de conferencia
• Sesión S4 COMENZADA - La pista 0 es A (extn 1000), la pista 1 es Bridge de conferencia

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:

• El teléfono asesor hace que un primario invite al control y un active consulta la llamada.
• El teléfono consultado tiene solamente una llamada activa (la llamada de la consulta).

Cuando se completa la conferencia (todos los partidos conectados):

• El teléfono asesor consulta la llamada termina.
• La llamada primaria del teléfono asesor consigue una transferencia del otro extremo al Bridge de conferencia.
• El teléfono consultado consigue una transferencia del otro extremo al Bridge de conferencia.

Como consecuencia:

• El s2 termina, porque representa el teléfono asesor consulta la llamada, que también termina.
• Comienzo S4; representa la transferencia de la continuación y del otro extremo de la llamada primaria a, pero el s1 original no puede ser ACTUALIZADO porque estaba previamente debido terminada sostenerse anterior.
• El S3 consigue ACTUALIZADO porque el otro extremo B se está transfiriendo simplemente de A al Bridge de conferencia.
• El valor del xRefCi del final cercano S4 hará juego el valor del xRefCi del final cercano del s1.

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:

• El decapado de una conferencia en una llamada bipartita normal se implementa como otro extremo de ambos teléfonos restantes que transfiere el uno al otro
• Una transferencia del otro extremo acciona una ACTUALIZACIÓN de la sesión existente de la grabación.
• El S3 y el s1 tendrán valores del xRefCi del final cercano que corresponden con. Observe que solamente una sesión sigue siendo activa porque el C del llamador no tiene bifurcar habilitado.

9. El agente B (extn 3000) cuelga para arriba.

10. El C (extn 2000) y B (extn 3000) desconectaron.
Sesión S4 TERMINADA.

Consideraciones:

• 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.
• Una conferencia se crea con la transferencia de todos los teléfonos al Bridge de conferencia. Por lo tanto, una conferencia actúa apenas como un conjunto de las transferencias. Ponen al día a las sesiones existentes en esas sesiones que el teléfono que bifurca sigue siendo el único participante en la pista 0, solamente el participante en los cambios de la pista 1 al Bridge de conferencia.
• El otro vendedor cae una vez de la conferencia, los partidos se transfiere el uno al otro. Esto pone al día a las sesiones existentes otra vez, 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 otro partido.
• Si un cuarto partido se agrega al Bridge de conferencia, no hay indicación en los meta datos, a menos que el cuarto partido también tenga su propio bifurcar habilitado.

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).

• S1 de la sesión - TERMINADO
• S2 de la sesión - COMENZADO - La pista 0 es A (extn 1000), la pista 1 es B (extn 3000)
• Sesión S3 - COMENZADO - La pista 0 es B (extn 3000), la pista 1 es A (extn 1000)

Consideraciones:

• El s1 de la sesión termina porque el teléfono del agente a ha colocado el C del llamador en el control.
• El s2 de las sesiones y el S3 existen porque ambos teléfonos se configuran para bifurcar.
• Los participantes así como el xRefCi para los dos participantes en el s2 y el S3 son idénticos pero en las posiciones invertidas de uno a.
• Los valores del xRefCi del s1 no se reflejan en el s2 o el S3, puesto que la consulta se considera una llamada independiente

5. El agente A (extn 1000) completa la conferencia.

6. C (extn 2000) que habla con A (extn 1000) y B (extn 3000)

• S2 de la sesión - TERMINADO
• Sesión S3 - TERMINADO
• Sesión S4 - COMENZADO - La pista 0 es A (extn 1000), la pista 1 es Bridge de conferencia
• Sesión S5 - COMENZADO - La pista 0 es B (extn 3000), la pista 1 es Bridge de conferencia

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í:

• Durante la consulta:
  • El teléfono asesor hace que un primario invite al control y un active consulta la llamada
  • El teléfono consultado tiene solamente una llamada activa (la llamada de la consulta)
• Cuando se completa la conferencia (todos los partidos conectados):
• El teléfono asesor consulta la llamada termina
• La llamada primaria del teléfono asesor consigue una transferencia del otro extremo al Bridge de conferencia
• El teléfono consultado consigue una transferencia del otro extremo al Bridge de conferencia
• Como consecuencia:
  • Se crean dos nuevas sesiones porque el agente A y el agente B tienen bifurcar habilitado
  • Valor del xRefCi del final cercano S4 y coincidencias del valor del xRefCi del final cercano del s1
  • Coincidencias del valor del xRefCi del valor y del final cercano S3 del xRefCi del final cercano S5
  • Los valores del xRefCi del otro extremo para el S4 y el S5 no hacen juego, aunque ambos están conectados con el mismo Bridge de conferencia

7. El agente A (extn 1000) cae de la conferencia

8. A (extn 1000) desconectó.  C (extn 2000) que habla con B (extn 3000)

• Sesión S4 - TERMINADO
• Sesión S5 - TERMINADO
• Sesión S6 - COMENZADO - La pista 0 es B (extn 3000), la pista 1 es C (extn 2000)

Consideraciones:

• El decapado de una conferencia en una llamada bipartita normal se implementa como otro extremo de ambos teléfonos restantes que transfiere el uno al otro
• Una transferencia del otro extremo acciona el final de una sesión de registración y el comienzo de otra sesión de la grabación
• El S6 y el S5 tendrán valores del xRefCi del final cercano que corresponden con. Observe que solamente una sesión sigue siendo activa porque el C del llamador no tiene bifurcar habilitado

9. El agente B (extn 3000) cuelga para arriba

10. El C (extn 2000) y B (extn 3000) desconectaron

• Sesión S6 - TERMINADO

Consideraciones:

• Una transferencia del otro extremo da lugar al final de una sesión y al comienzo de otra
• Una conferencia se crea con la transferencia de todos los teléfonos al Bridge de conferencia. Por lo tanto, una conferencia actúa apenas como un conjunto de las transferencias. Terminan a las sesiones existentes y las nuevas sesiones se crean entre los teléfonos que bifurcan y el Bridge de conferencia
• El otro vendedor cae una vez de la conferencia, los partidos se transfiere el uno al otro. Esto termina las sesiones que incluyeron el Bridge de conferencia y comienzan las nuevas sesiones entre los dos puntos finales restantes
• Si un cuarto partido se agrega al Bridge de conferencia, no hay indicación en los meta datos, a menos que el cuarto partido también tenga su propio bifurcar habilitado

2. ¿Cómo correlacionamos los ID de llamadas de la referencia para diversas sesiones de llamada, bajo bifurcar unificado del elemento de la frontera?

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:

2.1. cambio del codificador-decodificador de la Mediados de-llamada

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.

2.2. Transferencias de consultas

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:

1. El C del llamador (extn 2000) llama el agente A (extn 1000) (sessionId = s1, CCID = el c1)
2. El agente A consulta con el agente B (extn 3000) (sessionId = s2, CCID = el C2)
3. Los descensos del agente A, y el C del llamador habla con el agente B (sessionId = s1, CCID = el c1)

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:

• Sesión = s1/CCID = c1 y
• Sesión = s2/CCID = C2

Por lo tanto, el s1 se relaciona con el s2 y el c1 se relaciona con el C2.

2.3. Consulte la detección de llamadas

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:

Step1. 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.

2.4. Consulte la detección de llamadas de los participantes múltiples

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:

1. El llamador llama el agent1
2. El agent1 consulta con el agente 2, entonces los descensos
3. El llamador habla con el agente 2
4. El agente 2 consulta con el agente 3, entonces los descensos
5. El llamador habla con el agente 3

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.

2.5. Resumen

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.

3. ¿Cómo usted asocia las llamadas en Cisco MediaSense a sus aspectos en los componentes de la otra solución?

3.1. Tabla de correlación del identificador

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:

1. En las grabaciones de las llamadas del administrador de las Comunicaciones unificadas, Cisco MediaSense de hecho recibe un Cisco-GUID del UCM, pero no es el mismo que es capturado por los dispositivos de la otra solución. MediaSense por lo tanto ni siquiera salva este valor.
2. Para las llamadas de agente a agente, TCD.InstrumentPortNumber es la extensión del agente del destino. La extensión del agente de llamada se puede encontrar en TCD.ANI.
3. CCID es el Cisco-GUID en la forma decimal, que es 4 conjuntos guión-separados de los números decimales 10-digit. Éstos se pueden convertir a la forma hexadecimal con simplemente el convertido de cada número decimal 10-digit a un número hexadecimal de 8 dígitos, y quitan los guiones. Donde el Cisco-GUID se utiliza en UCCE, está en su forma hexadecimal.

4. ¿Cómo usted determina qué pista tiene la parte llamadora y qué pista tiene la Parte llamada?

4.1. Para las llamadas bifurcó por el CUBO

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.

4.2. Para las llamadas bifurcó por los teléfonos unificados CM

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.

5. ¿Cuáles son las posibles causas para un estado de la sesión de CLOSED_ERROR?

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.

6. ¿Cuál es la diferencia entre las sesiones podadas y borradas?

Considere estas dos interrogaciones:

6.1. Con la interrogación de los getAllPrunedSessions

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

6.2. Con la interrogación de los getSessions

 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" ] 
                        }] 
            }] 
}

6.3. ¿Por qué la diferencia del comportamiento en las sesiones podadas y borradas?

La diferencia del comportamiento está por el diseño. Refiera a esto las secciones en la documentación de MediaSense:

• La Descripción de parámetros API: La descripción de los getAllPrunedSessions API:

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.

• El MediaSense SRND bajo gestión de la memoria externa dinámica de la sección:

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:

1. Las sesiones podadas han sido marcadas para el retiro por un algoritmo en el sistema de MediaSense. No se implicó ninguna persona en la decisión para podar estas sesiones. Tan aunque estas sesiones se mueven al estado BORRADO, estas sesiones no se quitan realmente de los meta datos. Se requiere la intervención humana (o aplicación). Porque estas sesiones están en el estado BORRADO, estas sesiones no son visibles a la mayoría de las interrogaciones. Sin embargo, estas sesiones son visibles a la interrogación API de los getAllPrunedSessions. También, si algunos archivos mp4 fueron generados para estas sesiones, estos archivos mp4 continúan estando presentes en el disco y continuando estando disponibles para la descarga hasta que las sesiones podadas SE BORREN realmente.
2. Las sesiones borradas son marcadas explícitamente llamando los deleteSessions API. Esta marca se puede hacer a las sesiones que se podan ya o a las sesiones que todavía no se han borrado. Una vez que una sesión ha sido borrada por los deleteSessions API, esta sesión es no más visible a cualquier interrogación. Esto incluye los getAllPrunedSessions API. Estas sesiones borradas se quitan de los meta datos inmediatamente para poder reclamar el espacio en disco.
   
   

7. ¿Cómo configurar un gateway TDM para bifurcar de los media?

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.

8. ¿Cómo capturar el teléfono de destino real al usar a un grupo Hunt?

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.

9. ¿Por qué grabación Basada en red del administrador de las Comunicaciones unificadas es recomendado como bifurcar preferido el mecanismo?

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.

10. ¿Por qué un nodo dura para actualizar a 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.

11. ¿Cuál es el impacto de los cambios rusos del huso horario en la aplicación de la búsqueda y del juego de MediaSense?

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.

12. ¿Cuáles son los lenguajes soportados por MediaSense?

Aquí están los lenguajes soportados por MediaSense:

• Árabe
• Danés
• Holandés
• Inglés (Estados Unidos)
• Finlandés
• Francés
• Alemán
• Italiano
• Japonés
• Coreano
• Noruego
• Polaco
• Portugués (brasileño)
• Ruso
• Chino simplificado
• Español
• Sueco
• Chino tradicional
• Turco

13. ¿Cómo monitorear el rendimiento del sistema de 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.

14. ¿Cómo configurar a un navegador para funcionar con al jugador del en-navegador en MediaSense?

De acuerdo con el navegador, realice estos pasos para funcionar con al jugador del en-navegador:

admin:set useHostNameForMediaURL 
admin:set useHostNameForMediaURL true

admin:utils service restart Cisco MediaSense Configuration Service

The import was successful.