FAQ para Cisco MediaSense

Introdução

Este documento descreve FAQ para o server do sentido do Cisco media. 

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco MediaSense
• Cisco unificou o gerente de uma comunicação (CUCM)

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

Cisco MediaSense 10.5

1. Como você correlaciona identidades da chamada da referência para cenários de chamada diferentes, sob a bifurcação do telefone de gerenciador das comunicações unificadas?

Em Cisco MediaSense, o meta - os dados para cada atendimento fornecem somente o xRefCi (identidade da chamada da referência) e a referência do dispositivo (extensão) do dispositivo de bifurcação e do dispositivo de extremidade oposta (podem ser um bridge de conferência ou todo o outro telefone).

O parâmetro do xRefCi é o identificador do gerente unificado de uma comunicação para um córrego das mídias particular. Não correspondem sempre 1:1 com as trilhas gravadas.

1.1. A busca e o jogo de MediaSense chamam a característica da associação

MediaSense gerencie sessões múltiplas para um atendimento que seja gravado em caso da posse/resumo ou da transferência, que fazem difícil identificar todas as sessões da gravação em um atendimento. A fim poder associar estas sessões da gravação em um único atendimento, MediaSense introduz uns novos recursos denominados como a associação do atendimento. Através desta característica, todos os atendimentos fortemente associados com um valor comum do xRefci são agrupados junto. MediaSense 10.5 apoia a característica da associação do atendimento para gravações da Construir-em-ponte.

1.2. Posse do agente/encenação do resumo

1. O agente A (extn 1000) e o C do chamador (extn 2000) chamaram-se e no estado de fala.
2. O agente A põe chama a posse.
3. Atendimento dos resumos do agente A.

Há duas sessões de gravação para esta encenação:

• A sessão com sessionId = S1 com estas duas trilhas, porque o período de tempo /segment antes do agente põem chamam a posse:
  trackNumber = 0 com participante A (deviceRef = 1000, xRefCi = aaaa)
  trackNumber = 1 com participante B (deviceRef = 2000, xRefCi = cccc)
• Sessão com sessionId = S2 com estas duas trilhas, porque o período de tempo/segmento depois que o agente recomeça o atendimento.
  trackNumber = 0 com participante A (deviceRef = 1000, xRefCi = aaaa)
  trackNumber = 1 com participante B (deviceRef = 2000, xRefCi = cccc)

MediaSense não grava o segmento do atendimento quando o agente puser a posse chamar.

1.3. Posse do cliente/encenação do resumo

1. O agente A (extn 1000) e o C do chamador (extn 2000) alled e no estado de fala.
2. O C do cliente põe chama a posse.
3. Atendimento dos resumos do C do cliente.

O atendimento inteiro é gravado em uma sessão para esta encenação:

• Sessão com sessionId = S1 com estas duas trilhas:
  trackNumber = 0 com participante A (deviceRef = 1000, xRefCi = aaaa)
  trackNumber = 1 com participante B (deviceRef = 2000, xRefCi = cccc)

Nesta encenação MediaSense igualmente grava o segmento do atendimento quando o cliente puser a posse chamar.

1.4. Transferência do agente a uma outra encenação do agente 

1. O C do chamador (extn 2000) chama o agente A (extn 1000)
2. O agente A (extn 1000) consulta com o agente B (3000)
3. O agente A (extn 1000) termina transferência.
4. O agente B (extn 3000) pendura acima.

Com gerente 9.x das comunicações unificadas e mais cedo, estão aqui os resultados:

o C 1.Caller (extn 2000) chama o agente A (extn 1000)

A sessão S1 COMEÇADA, a trilha 0 é A (extn 1000), a trilha 1 é C (extn 2000).

transferências 2.Agent A (extn 1000) chamam a um outro agente B (extn 3000). Os dispositivos A e B estabelecem-se bifurcando-se.

o C 3.Caller (extn 2000) ouve a música na posse (MoH).
4.Agent A (extn 1000) fala a B (extn 3000).

• Sessão S1 TERMINADA
• A sessão S2 COMEÇADA, a trilha 0 é A (extn 1000), a trilha 1 é B (extn 3000)
• A sessão S3 COMEÇADA, a trilha 0 é B (extn 3000), a trilha 1 é A (extn 1000)

Considerações:

• As extremidades da sessão S1 devido ao telefone do agente A colocaram o C do chamador na posse.
• As sessões S2 e S3 existem porque ambos os telefones são configurados se bifurcando.
• Os participantes e o xRefCi para os dois participantes no S2 e no S3 são idênticos, mas em posições reversas de se.
• os valores do xRefCi do S1 não são refletidos no S2 ou no S3, desde que a consulta é considerada um atendimento independente.

5.Agent A (extn 1000) termina transferência.

6.C (extn 2000) que fala a B (extn 3000).

7.A (extn 1000) desligou.

Sessão S2 TERMINADA.

A sessão S3 ATUALIZADA, e a trilha 0 são B (extn 3000) e a trilha 1 é C (extn 2000).

Considerações:

• Transferência da ponta oposta provoca uma ATUALIZAÇÃO da sessão existente da gravação.
• O participante da ponta oposta muda àquele do S1.
• O xRefCi novo da ponta oposta S3 combina o xRefCi da ponta oposta S1.
• O agente B (extn 3000) pendura acima.
• O C (extn 2000) e B (extn 3000) são desligados.
•   Sessão S3 TERMINADA

Nota: Transferência da ponta oposta conduz a uma atualização da sessão existente. O telefone de bifurcação permanece o único participante na trilha 0, mas o participante em mudanças da trilha 1 ao partido novo.

Em caso do gerente 10.0 das comunicações unificadas e mais atrasado, está aqui o resultado:

1. O C do chamador (extn 2000) chama o agente A (extn 1000).

O C (extn 2000) fala ao agente A (extn 1000). Sessão S1 - COMEÇADO - A trilha 0 é A (extn 1000), a trilha 1 é o C (2000)

2. O agente A (extn 1000) consulta o agente B (extn 3000).

3. O C (extn 2000) ouve MoH. A (extn 1000) fala a B (extn 3000).

• Sessão S1 - TERMINADO
• Sessão S2 - COMEÇADO - A trilha 0 é A (extn 1000), a trilha 1 é B (extn 3000)
• Sessão S3 - COMEÇADO - A trilha 0 é B (extn 3000), a trilha 1 é A (extn 1000)

Considerações:

• A sessão S1 termina porque o telefone do agente A colocou o C do chamador na posse.
• As sessões S2 e S3 ambos existem porque ambos os telefones são configurados se bifurcando.
• Os participantes assim como o xRefCi para os dois participantes no S2 e no S3 são idênticos mas em posições invertidas de se.
• Os valores do xRefCi S1 não são refletidos no S2 ou no S3, desde que a consulta é considerada um atendimento independente

4. O agente A (extn 1000) termina transferência.

5. O C (extn 2000) fala a B (extn 3000).
6. A (extn 1000) desligou.

• Sessão S3 - TERMINADO
• Sessão S2 - TERMINADO
• Sessão S4 - COMEÇADO - A trilha 0 é B (extn 3000), a trilha 1 é C (extn 2000)

Considerações:

• Transferência da ponta oposta provoca o fim de uma sessão de gravação e o começo de uma outra sessão da gravação.
• Embora uma sessão nova começa, seus valores do xRefCi combinarão as sessões precedentes.
• O xRefCi da ponta oposta S4 combina o xRefCi da ponta oposta S1, e o xRefCi da extremidade próxima S4 combina o xRefCi da extremidade próxima S3.

7. O agente B (extn 3000) pendura acima.

8. O C (extn 2000) e B (extn 3000) desligaram.

• Sessão S4 - TERMINADO

Nota: Transferência da ponta oposta conduz ao fim de uma sessão de gravação e ao começo de uma outra sessão da gravação.

1.5. Conferências do agente com uma outra encenação do agente 

1. O C do chamador (extn 2000) chama o agente A (extn 1000).
2. O agente A (extn 1000) consulta o agente B (extn 3000).
3. O agente A (extn 1000) termina a conferência.
4. O agente A (extn 1000) deixa cair da conferência.
5. O agente B (extn 3000) pendura acima.

Em caso do gerente 9.x das comunicações unificadas e mais cedo, está aqui o resultado:

1. O C do chamador (extn 2000) chama o agente A (extn 1000).

2. O C (extn 2000) fala a A (extn 1000).
Sessão S1 COMEÇADA - A trilha 0 é A (extn 1000), a trilha 1 é C (extn 2000).

3. O agente A (extn 1000) consulta o agente B (extn 3000).

4. O C (extn 2000) ouve negociações de MoH A (extn 1000) a B (extn 3000)

• Sessão S1 TERMINADA
• Sessão S2 COMEÇADA - A trilha 0 é A (extn 1000), a trilha 1 é B (extn 3000)
• Sessão S3 COMEÇADA - A trilha 0 é B (extn 3000), a trilha 1 é A (extn 1052

Considerações:

• A sessão S1 termina porque o telefone do agente A colocou o C do chamador na posse.
• As sessões S2 e S3 existem porque ambos os telefones são configurados se bifurcando.
• Os participantes assim como o xRefCi para os dois participantes no S2 e no S3 são idênticos mas em posições invertidas de se.
• Os valores do xRefCi S1 não são refletidos no S2 ou no S3, desde que a consulta é considerada um atendimento independente.

5. O agente A (extn 1000) termina a conferência.

6. C (extn 2000) que fala a A (extn 1000) e a B (extn 3000).

• Sessão S2 TERMINADA
• Sessão S3 ATUALIZADA - A trilha 0 é B (ext 3000), a trilha 1 é bridge de conferência
• Sessão S4 COMEÇADA - A trilha 0 é A (extn 1000), a trilha 1 é bridge de conferência

Considerações:
Transferência da ponta oposta provoca uma ATUALIZAÇÃO da sessão existente da gravação.
A conclusão de uma conferência é executada:
Durante a consulta:

• O telefone de consulta manda um preliminar chamar a posse e um active consulta o atendimento.
• O telefone do consultado tem somente uma chamada ativa (o atendimento da consulta).

Quando a conferência for terminada (todos os partidos conectados):

• O telefone de consulta consulta o atendimento termina.
• O atendimento preliminar do telefone de consulta obtém transferência da ponta oposta ao bridge de conferência.
• O telefone do consultado obtém transferência da ponta oposta ao bridge de conferência.

Em consequência:

• O S2 termina, porque representa o telefone de consulta consulta o atendimento, que igualmente termina.
• Começos S4; representa transferência da continuação e da ponta oposta do atendimento preliminar do a, mas o S1 original não pode SER ATUALIZADO porque era previamente devido terminado guardar mais cedo.
• O S3 obtém ATUALIZADO porque a ponta oposta do b está sendo transferida simplesmente de A ao bridge de conferência.
• O valor do xRefCi da extremidade próxima S4 combinará o valor do xRefCi da extremidade próxima S1.

7. O agente A (extn 1000) deixa cair da conferência.

8. A (extn 1000) desligou.  C (extn 2000) que fala à sessão S3 B (extn 3000) ATUALIZADA - a trilha 0 é B (extn 3000), a trilha 1 é C (extn 2000).

Considerações:

• O de-agravamento de uma conferência em um atendimento bipartido normal é executado como a ponta oposta de ambos os telefones restantes que transfere entre si
• Transferência da ponta oposta provoca uma ATUALIZAÇÃO da sessão existente da gravação.
• O S3 e o S1 terão valores de harmonização do xRefCi da extremidade próxima. Note que somente uma sessão permanece ativa porque o C do chamador não tem a bifurcação permitida.

9. O agente B (extn 3000) pendura acima.

10. O C (extn 2000) e B (extn 3000) desligaram.
Sessão S4 TERMINADA.

Considerações:

• Transferência da ponta oposta conduz a uma atualização da sessão existente. O telefone de bifurcação permanece o único participante na trilha 0, mas o participante em mudanças da trilha 1 ao partido novo.
• Uma conferência é criada com transferência de todos os telefones ao bridge de conferência. Consequentemente, uma conferência atua apenas como um grupo de transferências. As sessões existentes são atualizadas naquelas sessões que o telefone de bifurcação permanece o único participante na trilha 0, mas no participante em mudanças da trilha 1 ao bridge de conferência.
• Uma vez a terceira parte deixa cair da conferência, os partidos é transferida entre si. Isto atualiza as sessões existentes outra vez, o telefone de bifurcação permanece o único participante na trilha 0, mas o participante em mudanças da trilha 1 ao outro partido.
• Se um quarto partido é adicionado ao bridge de conferência, não há nenhuma indicação nos metadata, a menos que o quarto partido igualmente tiver sua própria bifurcação permitida.

Em caso do gerente 10.x das comunicações unificadas e mais tarde, está aqui o resultado:

1. O C do chamador (extn 2000) chama o agente A (extn 1000).

2. O C (extn 2000) que fala à sessão S1 A (extn 1000) - COMEÇADO - a trilha 0 é A (extn 1000), a trilha 1 é C (extn 2000).

3. O agente A (extn 1000) consulta o agente B (extn 3000).

4. Audição MoH A do C (extn 2000) (extn 1000) que fala a B (extn 3000).

• Sessão S1 - TERMINADO
• Sessão S2 - COMEÇADO - A trilha 0 é A (extn 1000), a trilha 1 é B (extn 3000)
• Sessão S3 - COMEÇADO - A trilha 0 é B (extn 3000), a trilha 1 é A (extn 1000)

Considerações:

• A sessão S1 termina porque o telefone do agente a colocou o C do chamador na posse.
• As sessões S2 e S3 existem porque ambos os telefones são configurados se bifurcando.
• Os participantes assim como o xRefCi para os dois participantes no S2 e no S3 são idênticos mas em posições invertidas de se.
• Os valores do xRefCi S1 não são refletidos no S2 ou no S3, desde que a consulta é considerada um atendimento independente

5. O agente A (extn 1000) termina a conferência.

6. C (extn 2000) que fala a A (extn 1000) e a B (extn 3000)

• Sessão S2 - TERMINADO
• Sessão S3 - TERMINADO
• Sessão S4 - COMEÇADO - A trilha 0 é A (extn 1000), a trilha 1 é bridge de conferência
• Sessão S5 - COMEÇADO - A trilha 0 é B (extn 3000), a trilha 1 é bridge de conferência

Considerações:

Transferência da ponta oposta provoca o fim de uma sessão de gravação e o começo de uma outra gravação. A conclusão de uma conferência é executada alistou aqui:

• Durante a consulta:
  • O telefone de consulta manda um preliminar chamar a posse e um active consulta o atendimento
  • O telefone do consultado tem somente uma chamada ativa (o atendimento da consulta)
• Quando a conferência for terminada (todos os partidos conectados):
• O telefone de consulta consulta o atendimento termina
• O atendimento preliminar do telefone de consulta obtém transferência da ponta oposta ao bridge de conferência
• O telefone do consultado obtém transferência da ponta oposta ao bridge de conferência
• Em consequência:
  • Duas sessões novas são criadas porque o agente A e o agente B têm a bifurcação permitida
  • O valor do xRefCi da extremidade próxima S4 e o xRefCi da extremidade próxima S1 avaliam fósforos
  • O valor do xRefCi da extremidade próxima S5 e o xRefCi da extremidade próxima S3 avaliam fósforos
  • Os valores do xRefCi da ponta oposta para o S4 e o S5 não combinam, mesmo que ambos sejam conectados ao mesmo bridge de conferência

7. O agente A (extn 1000) deixa cair da conferência

8. A (extn 1000) desligou.  C (extn 2000) que fala a B (extn 3000)

• Sessão S4 - TERMINADO
• Sessão S5 - TERMINADO
• Sessão S6 - COMEÇADO - A trilha 0 é B (extn 3000), a trilha 1 é C (extn 2000)

Considerações:

• O de-agravamento de uma conferência em um atendimento bipartido normal é executado como a ponta oposta de ambos os telefones restantes que transfere entre si
• Transferência da ponta oposta provoca o fim de uma sessão de gravação e o começo de uma outra sessão da gravação
• O S6 e o S5 terão valores de harmonização do xRefCi da extremidade próxima. Note que somente uma sessão permanece ativa porque o C do chamador não tem a bifurcação permitida

9. O agente B (extn 3000) pendura acima

10. O C (extn 2000) e B (extn 3000) desligaram

• Sessão S6 - TERMINADO

Considerações:

• Transferência da ponta oposta conduz ao fim de uma sessão e ao começo de outra
• Uma conferência é criada com transferência de todos os telefones ao bridge de conferência. Consequentemente, uma conferência atua apenas como um grupo de transferências. As sessões existentes são terminadas e as sessões novas são criadas entre os telefones de bifurcação e o bridge de conferência
• Uma vez a terceira parte deixa cair da conferência, os partidos é transferida entre si. Isto termina as sessões que incluíram o bridge de conferência e começam sessões novas entre os dois valores-limite restantes
• Se um quarto partido é adicionado ao bridge de conferência, não há nenhuma indicação nos metadata, a menos que o quarto partido igualmente tiver sua própria bifurcação permitida

2. Como nós correlacionamos identidades da chamada da referência para sessões de chamada diferentes, sob a bifurcação unificada do elemento da beira?

Com o elemento unificado da beira que bifurca-se, muito poucas situações fazem com que um atendimento seja rachado em sessões múltiplas da gravação. Guarde/resumo, transferência e as operações da conferência não começam sessões novas da gravação na maioria dos casos. Em poucos casos onde as sessões novas são criadas, hão um valor comum, CCID (correlação de chamada ID). Este valor é comum a todas as sessões no atendimento. CCID é o formulário decimal do Cisco-GUID, uma chave original do atendimento que seja gerada pelo Roteadores da Voz de Cisco. O primeiro roteador que recebe um atendimento gerencie esta chave, e passa-a abaixo da linha a todos os dispositivos subsequentes que incluem Cisco MediaSense.

O elemento unificado próprio da beira não gerencie valores do xRefCi, mas para criar a similaridade com os atendimentos de bifurcação do telefone de gerenciador das comunicações unificadas, Cisco MediaSense igualmente sintetiza um par de valores do xRefCi para cada atendimento unificado do elemento da beira. Estes podem ser vistos nos metadata a nível da trilha, junto com CCID, que aparece a nível da sessão.

A causa destas situações unificou as gravações do elemento da beira a ser rachadas em sessões múltiplas:

2.1. mudança do codec do Meados de-atendimento

Se transferência, a conferência, a gota da conferência, ou a outra operação fazem com que os partidos renegociem seu codec, Cisco MediaSense termina a sessão atual da gravação e começa um novo. As duas sessões compartilham do mesmo CCID e dos mesmos pares de valores do xRefCi.

2.2. Transferências de consulta

Transferência de consulta é transferência de um agente a outro, em que os dois agentes falam entre si quando o chamador original esperar na posse. O pé da consulta do atendimento é relacionado de uma certa maneira ao atendimento total, e é possível configurar o gerente das comunicações unificadas tais que consulte atendimentos passam através do CUBO. Contudo, o elemento unificado da beira e Cisco MediaSense não sabem que estes atendimentos são relacionados, e criam um CCID novo e um par novo de valores do xRefCi para esta sessão.

Estes atendimentos podem ser associados um com o outro com comparam de campos do deviceRef e do timestamp do participante. Considere esta encenação:

1. O C do chamador (extn 2000) chama o agente A (extn 1000) (sessionId = S1, CCID = o C1)
2. O agente A consulta com o agente B (extn 3000) (sessionId = S2, CCID = o C2)
3. As gotas do agente A, e o C do chamador falam com agente B (sessionId = S1, CCID = o C1)

O flag vermelho nesta encenação está em etapa 2. Durante esse período, o agente A (deviceRef 1000) é um participante em duas sessões de gravação imediatamente:

• Sessão = S1/CCID = C1 e
• Sessão = S2/CCID = C2

Consequentemente, o S1 é relacionado ao S2 e ao C1 é relacionado ao C2.

2.3. Consulte a detecção de atendimentos

Primeiramente, nós precisamos uma definição clara de consultamos o atendimento:

Algum atendimento secundário que for feito por um participante atual em uma sessão existente a um valor-limite que seja a parte externa que sessão e que exclui os outros participantes nessa sessão.

Na teoria, esta encenação poderia incluir um agente coloca o chamador na posse para verificar com seu chefe para ver se há a ruptura de luch, ou mesmo um agente pôs o chamador sobre a posse para receber um atendimento de sua esposa, mas nós ignoramos aquelas possibilidades por agora.

É possível para que um aplicativo do cliente detecte um atendimento da consulta no tempo real pela trilha do córrego do evento de Cisco MediaSense. Se o cliente observa um evento COMEÇADO sessão contém um deviceRef dado, com um outro evento COMEÇADO sessão contém o mesmo deviceRef sem o evento TERMINADO sessão de intervenção, pode concluir que os sessionIds e o CCIDs encontrados nos dois eventos COMEÇADOS sessão são associados. 

Historicamente, um cliente pode verificar para ver se há alguns consulta os atendimentos que são associados com um atendimento preliminar dado, com Cisco MediaSense API. Supõe que o cliente conhece esse extn usado A 1000 do agente, em CCID <C1>. Este instruções para encontrar algum associado para consultar atendimentos:

Etapa1. Recupere os metadata da sessão para o atendimento preliminar emitindo getSessionByCCID(<C1>).

Step2. Extraia o sessionStartDate (atendimento ele <Ta>), e o sessionDuration.

Step3. Calcule o sessionEndDate (atendimento ele <Tb>) adicionando o sessionDuration ao <Ta>.

Step4. Execute este pedido API:

IP address:8443/ora/queryService/query/getSessionsByDeviceRef?value=1000&minSessionStartDate=<Ta>&maxSessionStartDate=<Tb> de https://Mediasense

Esta pergunta pode retornar mais de uma sessão.  Se faz, a seguir todo podem ser supostas para ser associado com a mesma chamada.

2.4. Consulte a detecção de atendimentos dos participantes múltiplos

Todo o procedimento mencionado dentro consulta a seção da detecção de atendimento, encontra para consultar os atendimentos feitos do dispositivo que recebeu a chamada telefônica inicial. Contudo, o que se lá consultam atendimentos são feitos de um dispositivo a que o atendimento foi transferido subseqüentemente?

Considere este procedimento:

1. O chamador chama o agente1
2. O agente1 consulta com o agente 2, então gotas
3. O chamador fala com o agente 2
4. O agente 2 consulta com o agente 3, então gotas
5. O chamador fala com o agente 3

Este procedimento não trava o atendimento da consulta entre o agente 2 e o agente 3.

Desde que este é um atendimento unificado do elemento da beira, nós podemos utilizar o fato de que todas as conexões entre o chamador e cada um dos agentes estão incluídas na mesma sessão da gravação, e o fato de que todos os agentes envolvidos estão alistados como participantes na mesma sessão a um momento ou outro. Assim, dos metadata preliminares da sessão, nós podemos recolher uma lista de todos os deviceRefs que eram involvidos. Para encontrar aquelas sessões, nós podemos fazer uma série dos atendimentos ao getSessionsByDeviceRef, especificamos o intervalo de tempo da sessão preliminar, junto com um deviceRef pelo pedido.

Alternativamente, o processo pode ser simplificado com um único pedido dos getSessions tal como este:

{
    "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 pergunta retorna todos os atendimentos da consulta associados com o atendimento do primário original e as todas suas transferências.

Este procedimento molda realmente a rede demasiado amplamente. Se por exemplo, o agente no deviceRef 4000 conduziu e terminou um atendimento completamente independente que acontecesse começar depois que <Ta> e antes que esteve adicionado ao atendimento na pergunta, este procedimento incluiu que independente chame no grupo. Este problema pode ser resolvido embora, com a informações disponíveis nos metadata da sessão preliminar.  A informação de cada participante inclui o deslocamento de tempo em que se juntou à sessão e à duração de sua posse. O código cliente poderia usar-se que informação para suprimir simplesmente das sessões não relacionadas da lista que recebeu acima. Ou, poderia formular uma série de getSessions ou de perguntas diretas do getSessionByDeviceRef que moldam corretamente os períodos de tempo durante que cada agente estava no atendimento preliminar. Nós saimos que como um exercício ao leitor.

2.5. Resumo

Na seção precedente, nós apresentamos precedures para a recuperação de todas as sessões associadas com uma sessão dada da gravação de Cisco MediaSense. Contudo, nós igualmente vimos que um atendimento dado pode ser dividido em mais de uma sessão, como no caso de uma mudança do codec do meados de-atendimento. 

Como nós recuperamos todas as gravações (assim como consulta) associadas com todas as sessões conectadas à interação do chamador? 

A resposta é estender o este instruções para o detectiion do múltiplo consulta atendimentos. Primeiramente, nós recolhemos todas as sessões que compartilham do CCID da sessão preliminar na pergunta. Então, nós construímos nossa lista de participantes de todos aqueles registros da sessão. Em seguida, nós calculamos os intervalos de tempo como o sessionStartDate da sessão a mais adiantada através do fim da sessão a mais atrasada. ultimamente, nós podemos executar a pergunta dos getSessions mostrada.

Como antes, nós podemos terminar acima com captação de gravações demais, assim que nós poderíamos executar uma etapa do postprocessing para suprimir daquelas sessões não relacionadas de sua lista.

3. Como você associa atendimentos em Cisco MediaSense com suas aparências em componentes da outra solução?

3.1. Tabela de correlação do identificador

Estas duas tabelas — se para o gerente das comunicações unificadas chama e se para o elemento unificado da beira chama. Cada coluna representa um componente de solução ou o protocolo, com a primeira coluna representa Cisco MediaSense. Cada fileira representa um tipo particular de identificador.

Para ler as tabelas, comece com uma pilha que represente o item de dados que você conhece, e olhe então horizontalmente à coluna represente o componente de solução em que você quer encontrar o atendimento. A entrada nessa pilha indica por que nome o exato o mesmo item de dados é conhecido no componente do alvo. Se o componente do alvo tem uma pilha vazia nessa fileira, a seguir esse item de dados não está sabido a esse componente. Você pode pelo contrário procurar uma coluna de intervenção onde você possa se cruzar verticalmente em uma outra fileira onde essa pilha não esteja vazia na coluna do componente do alvo.

Por exemplo, com um atendimento do gerente das comunicações unificadas, supõe que você conhece o GED-188 CallReferenceID e que você quer encontrar o atendimento em Cisco MediaSense. Verifique à esquerda da coluna do GED-188, você veem que não há nenhum valor na coluna de MediaSense, assim que você não pode traçar-lhe diretamente.

Contudo, há uma coluna onde você possa fazer zigzag através das fileiras: Gerente CDR das comunicações unificadas. Um cliente pode selecionar o registro de CDR apropriado do gerente das comunicações unificadas procurando por um em que o IncomingProtocolCallRef combina o GED-188 CallReferenceID. Que o registro contém um valor chamaram mais destLegCallIdentifier, que fosse o mesmo que o xRefCi de MediaSense NearEnd, e podem consequentemente ser usadas para encontrar o registro correspondente em Cisco MediaSense.

Os registros de CDR do gerente das comunicações unificadas não estão redigidos até alguma hora depois que o fim do atendimento termina, contudo, assim que este método pode somente ser usado historicamente.

Há um outro trajeto também. Olhe para baixo do GED-188 CallReferenceID. Despeja que você pode igualmente usar o AlertingDevice e o AnsweringDevice para combinar o campo do deviceRef em MediaSense. Este método igualmente trabalha no tempo real.

Considerações:

1. Nas gravações de atendimentos do gerente das comunicações unificadas, Cisco MediaSense recebe de fato um Cisco-GUID do UCM, mas não é mesmo que é capturado pelos dispositivos da outra solução. MediaSense consequentemente armazena nem sequer este valor.
2. Para chamadas de agente a agente, TCD.InstrumentPortNumber é a extensão do agente do destino. A extensão do agente de chamada pode ser encontrada em TCD.ANI.
3. CCID é o Cisco-GUID no formulário decimal, que é 4 grupos hífen-separados dos números decimais 10-digit. Estes podem ser convertidos ao formulário encantar com simplesmente o converso de cada número decimal 10-digit a um de 8 di'gitos encantam o número, e removem os hífens. Onde o Cisco-GUID é usado em UCCE, está no seu encanta o formulário.

4. Como você determina que trilha tem a chamada originada e que trilha tem o número chamado?

4.1. Para atendimentos bifurcou-se pelo CUBO

Para o CUBO chama, seguem 0 traça sempre ao fluxo de mídia do pé da âncora. O pé da âncora é o dial-peer que o perfil da gravação dos media é configurado. O segundo pé da NON-âncora dos mapas da trilha.

Se você tem o perfil da gravação dos media permitido no dialpeer de entrada, a seguir o pé da âncora transforma-se o em-pé. Ou seja a chamada originada aparece na trilha 0, e o número chamado aparece na trilha 1.

Se você tem o perfil da gravação dos media permitido no dialpeer de partida, a seguir o pé da âncora transforma-se o para fora-pé.  Nesse caso a chamada originada aparece na trilha 1 e o número chamado aparece na trilha 0.

4.2. Para atendimentos bifurcou-se por telefones unificados CM

Para o CM unificado que bifurca-se, em cenários de chamada simples você pode usar os campos do xRefCi nos metadata para determinar que partido está em que media siga. O xRefCi numericamente menor refere geralmente a trilha da chamada originada. A trilha do número chamado é numericamente maior (geralmente por uma, mas por eles poderiam estar mais sob razoavelmente um sistema carregado). Contudo, estes valores do xRefCi envolvem eventualmente ao redor a zero. Assim, se você encontra que um valor é um alto número e o outro é um número pequeno, você supõe que suas posições estão invertidas.

Em umas encenações mais complicadas, este algoritmo não trabalha sempre. Se os serviços suplementares estão invocados, como transferências e conferências, e o conjunto do gerente UC consiste em mais de um nó, a seguir os valores do xRefCi não estão gerados necessariamente sequencialmente, e você não pode supor que sua ordem tem todo o significado de todo. Uma maneira direta determinar se a sequência pedindo de um par particular de valores do xRefCi pode ser confiada é olhar o primeiro byte dos valores do xRefCi. Este byte representa a identificação de nó do gerente UC em que esse identificador particular foi criado. Se os primeiros bytes dos dois valores do xRefCi são os mesmos, a seguir seu pedir está correto. Se são diferentes, a seguir pedir não pôde estar correto.

Para estes casos, a única maneira de determinar a direção do chamador no tempo real é adquirir a informação de toda a outra fonte, tal como a alimentação do evento JTAPI. Uma vez o atendimento terminou e alguns minutos decorreram, você pode sempre determinar a direção do chamador e verificar dados CDR do gerente UC para ver se há o atendimento. Especificamente, o campo mais origLegCallIdentifier no registro de CDR representa sempre o chamador.

5. Que são as causas possíveis para um estado de sessão de CLOSED_ERROR?

As causas possíveis para um estado de sessão de CLOSED_ERROR incluem:

1. O server do Controle de chamadas recebeu uma resposta de erro do server dos media (gravação) para o pedido aberto ou próximo.
2. O server do Controle de chamadas detectou um erro da sinalização do SORVO, por exemplo um ACK faltante.
3. A sessão foi fechada com sucesso, mas TODAS AS trilhas têm o tamanho zero.

Quando uma sessão está no estado ATIVO, é normal que não há nenhuma duração nos metadata, porque a duração não é sabida até que a sessão esteja fechada.

Para uma sessão que esteja no estado CLOSED_ERROR, se os campos da sessão ou da duração da trilha não estão atuais no evento ou nos dados dos getSessions, a seguir o media para esta trilha não está disponível.

6. Que é a diferença entre sessões podadas e suprimidas?

Considere estas duas perguntas:

6.1. Com pergunta dos getAllPrunedSessions

Esta pergunta retorna um grupo de sessões, tudo cujos de estados de sessão SÃO SUPRIMIDOS:

https://Mediaserver IP address:8443/ora/queryService/query/getAllPrunedSessions?minSessionStartDate=1301788800000&maxSessionStartDate=1312329599000

6.2. Com pergunta dos getSessions

 Esta pergunta não retorna nenhuma sessão:

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 que a diferença do comportamento em sessões podadas e suprimidas?

A diferença do comportamento é pelo projeto. Refira esta a seções na documentação de MediaSense:

• A descrição de parâmetro API: A descrição dos getAllPrunedSessions API:

Use este API para procurar todas as gravações podadas… que o termo podado refere as gravações que são suprimidas pelo sistema de Cisco MediaSense. Se você suprimiu explicitamente de qualquer gravação usando os deleteSessions API, a seguir estas gravações suprimidas não estão consideradas como gravações podadas.

• O MediaSense SRND sob a gestão de armazenamento dinâmica da seção:

Quando as sessões são podadas, os metadata que é associado com estas sessões permanecem no base de dados, mesmo depois que estas sessões são marcadas como “podado”. Este os metadata não tomam uma grande quantidade do espaço de armazenamento comparada às gravações elas mesmas mas toma algum espaço e deve periodicamente ser removida. Para ajudar nesta atividade, os clientes podem periodicamente emitir um pedido API para sessões podadas, ou os clientes podem eleger para receber eventos podados sessão e para suprimir explicitamente daqueles eventos que os clientes já não precisam.

Para esclarecer, as duas perguntas são totalmente diferentes. Com efeito, a segunda pergunta (o lwhich procura todas as sessões cujo o estado É SUPRIMIDO) retorna sempre um grupo vazio. As perguntas do dia a dia normais filtram para fora sessões com estados SUPRIMIDOS, mesmo se aquele é o que é pedido. A única exceção é getAllPrunedSessions. Esta exceção é pretendida ajudar ao aplicativo encontrar sessões podadas de modo que o aplicativo possa pedir que estas sessões estejam suprimidas.

Uma vez que você usa os deleteSessions API na lista de sessões que podadas você obtém dos getAllPrunedSessions, estas sessões já não aparecem no resultado dos getAllPrunedSessions. Tais sessões são removidas completamente dos metadata imediatamente.

Uma outra maneira de olhar isto é que as sessões podadas não são a mesma coisa que sessões suprimidas:

1. As sessões podadas foram marcadas para a remoção por um algoritmo no sistema de MediaSense. Nenhuma pessoa foi envolvida na decisão para podar estas sessões. Assim mesmo que estas sessões sejam movidas para o estado SUPRIMIDO, estas sessões não são removidas realmente dos metadata. A intervenção humana (ou aplicativo) é exigida. Porque estas sessões estão no estado SUPRIMIDO, estas sessões não são visíveis à maioria de perguntas. Contudo, estas sessões são visíveis à pergunta API dos getAllPrunedSessions. Também, se algum arquivo mp4 foi gerado para estas sessões, estes arquivos mp4 continuam a estam presente no disco e continuam a estar disponíveis para a transferência até que as sessões podadas ESTEJAM SUPRIMIDAS realmente.
2. As sessões suprimidas são marcadas explicitamente chamando os deleteSessions API. Esta marcação pode ser feita às sessões que são podadas já ou às sessões que não foram suprimidas ainda. Uma vez que uma sessão foi suprimida pelos deleteSessions API, esta sessão é já não visível a toda a pergunta. Isto inclui os getAllPrunedSessions API. Estas sessões suprimidas são removidas dos metadata imediatamente de modo que o espaço de disco possa ser recuperado.
   
   

7. Como configurar um gateway TDM para a bifurcação dos media?

Quando você tem um gateway PSTN através de que o chama fluxos, e queira gravar aqueles atendimentos. Estes atendimentos são atendimentos do TDM-à-SORVO. Contudo, a bifurcação dos media está somente disponível em atendimentos do Sorvo-à-SORVO.

Estes atendimentos podem ser gravados. Estes atendimentos enlatam dirigido através do roteador um a segunda vez. A orientação de configuração e outros detalhes podem ser encontrados neste White Paper.

8. Como capturar o telefone de destino real ao usar um grupo de buscas?

Quando você usa os media que se bifurcam do CUBO, os metadata de MediaSense contêm normalmente a extensão do número chamado. Contudo, se o número chamado é um número piloto de grupo de buscas do Gerenciador de Comunicações, a seguir à revelia os metadata contêm somente esse número piloto. Não contém a extensão do telefone que respondeu realmente ao atendimento.

Há um ajuste do Gerenciador de Comunicações que possa mudar este. Na caça/página de configuração do piloto, encontre a seção autorizada transformações conectadas do partido. O membro DN do grupo de linha de exibição do ajuste como o partido conectado deve ser girado sobre.

Esta capacidade está disponível no Gerenciador de Comunicações 9.0(1) e mais atrasada.

9. Por que gravação Com base na rede do gerente das comunicações unificadas é recomendado como uma bifurcação preferida o mecanismo?

Com gravação Com base na rede do gerente das comunicações unificadas (NBR), você pode usar um gateway para gravar atendimentos. NBR permite que o gerente das comunicações unificadas distribua atendimentos da gravação, apesar do dispositivo, do lugar, ou da geografia. Com NBR, os media da gravação do atendimento podem ser originado do telefone IP ou de um gateway que seja conectado ao gerente das comunicações unificadas sobre um tronco do SORVO. O gerente das comunicações unificadas seleciona dinamicamente a fonte direita dos media baseada nos participantes do fluxo de chamadas e do atendimento.

NBR oferece uma Construir-em-ponte automática da reserva (babador) quando o Roteadores dos Serviços integrados (ISR) é não disponível porque nenhuma configuração de gravação separada está exigida. Isto é útil nos casos onde os clientes querem incluir o agente-agente consultam atendimentos nas políticas de gravação porque o elemento unificado da beira não pode gravar consulta atendimentos, assim que o babador precisa de ser permitido separadamente.

NBR e os atendimentos do babador podem ser correlacionados usando o xRefci, que está disponível do JTAPI do gerente das comunicações unificadas. CISCO-GUID não é precisado, que significa que nem o CTI Server nem as conexões CTIOS estão exigidos. Porque há um único identificador da correlação, a correlação através dos componentes é mais forte e pode ser feita em um independente uniforme da maneira do fluxo de chamadas.

Com o NBR, direto-discado assim como as chamadas externas discador-iniciadas podem ser correlacionadas com sua aparência em componentes da outra solução.

Com NBR, a gravação do gateway TDM é usada automaticamente sem a separação da capacidade do roteador. Atualmente, a gravação do gateway TDM não é apoiada com MediaSense 10.5.

10. Por que um nó toma mais por muito tempo para promover a MediaSense 10.5?

Um nó pode tomar diversas horas para promover depende do número e do tamanho das gravações que guarda. Para MediaSense 10.5, quando você promove um nó com conjuntos de dados muito grandes, toma ao redor 90 minutos adicionais por 1 milhão gravações.

11. Que é o impacto das mudanças da zona de hora (fuso horário) do russo no aplicativo da busca e do jogo de MediaSense?

Os usuários do MediaSense procuram e o aplicativo do jogo é afetado se estão ficados situados em algumas das zonas de hora (fuso horário) impactadas ou se selecionam uma zona de hora (fuso horário) impactada nos critérios de pesquisa. O Produtos do sócio da terceira parte que conectam com o MediaSense está afetado similarmente até que atualize suas tabelas respectivas da zona de hora (fuso horário).

A ação alternativa é selecionar uma zona de hora (fuso horário) que combine o offset correto do GMT mesmo se a cidade está já não correta.

12. Que são as línguas apoiadas por MediaSense?

Estão aqui as línguas apoiadas por MediaSense:

• Árabe
• Dinamarquês
• Holandês
• Inglês (Estados Unidos)
• Finlandês
• Francês
• Alemão
• Italiano
• Japonês
• Coreano
• Norueguês
• Polonês
• Português (brasileiro)
• Russo
• Chinês simplificado
• Espanhol
• Sueco
• Chinês tradicional
• Turco

13. Como monitorar o desempenho de sistema de MediaSense?

Para monitorar o desempenho de sistema de MediaSense, analise os valores destes indicadores de desempenho chave (KPIs) com a ferramenta do acreditação da ferramenta RTMT ou da Colaboração da prima de Cisco.

Para obter mais informações sobre da ferramenta principal do acreditação da ferramenta RTMT ou da Colaboração de Cisco, consulte as seções principais unificadas da administração do acreditação da administração RTMT e da Colaboração de Cisco do Guia do Usuário de Cisco MediaSense.

14. Como configurar um navegador para executar o jogador do em-navegador em MediaSense?

Baseado no navegador, execute estas etapas para executar o jogador do em-navegador:

admin:set useHostNameForMediaURL 
admin:set useHostNameForMediaURL true

admin:utils service restart Cisco MediaSense Configuration Service

The import was successful.