Pour les partenaires
Vous êtes déjà partenaire?
ConnexionAvez-vous un compte?
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit des Foires aux questions pour le serveur de sens de medias de Cisco.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
Cisco MediaSense 10.5
Dans le Cisco MediaSense, les méta-données pour chaque appel fournissent seulement le xRefCi (ID d'appel de référence) et la référence de périphérique (extension) du périphérique bifurquant et du périphérique final (peut être une passerelle de conférence ou tout autre téléphone).
Le paramètre de xRefCi est l'identifiant de la Communication Manager unifiée pour un flux multimédia particulier. Ils ne correspondent pas toujours 1:1 aux pistes enregistrées.
MediaSense génère des plusieurs sessions pour un appel qui est enregistré en cas d'attente/de reprise ou de transfert, qui le rendent difficile d'identifier toutes les sessions enregistrées dans un appel. Afin de pouvoir associer ces sessions enregistrées dans un appel unique, MediaSense introduit une nouvelle caractéristique nommée comme association d'appel. Par cette caractéristique, tous les appels fortement associés avec une valeur commune de xRefci sont groupés ensemble. MediaSense 10.5 prend en charge la caractéristique d'association d'appel pour des enregistrements de Construire-dans-passerelle.
Il y a deux sessions enregistrées pour ce scénario :
MediaSense n'enregistre pas le segment de l'appel tandis que l'agent a mis l'appel sur l'attente.
L'appel entier est enregistré en une session pour ce scénario :
Dans ce scénario MediaSense enregistre également le segment de l'appel tandis que le client a mis l'appel sur l'attente.
Avec l'Unified Communications Manager 9.x et plus tôt, voici les résultats :
le C 1.Caller (extn 2000) appelle l'agent A (extn 1000)
La session S1 COMMENCÉE, la piste 0 est A (extn 1000), la piste 1 est C (extn 2000).
les transferts 2.Agent A (extn 1000) appellent à un autre agent B (extn 3000). Des périphériques A et B sont installés pour bifurquer.
le C 3.Caller (extn 2000) entend la musique d'attente (MoH).
4.Agent A (extn 1000) parle à B (extn 3000).
Considérations :
5.Agent A (extn 1000) se termine le transfert.
6.C (extn 2000) parlant à B (extn 3000).
7.A (extn 1000) a déconnecté.
Session S2 FINIE.
La session S3 MISE À JOUR, et la piste 0 est B (l'extn 3000) et la piste 1 est C (extn 2000).
Considérations :
Note: Un transfert d'extrémité a comme conséquence une mise à jour de la session existante. Le téléphone bifurquant demeure le seul participant dans la piste 0, mais le participant aux modifications de la piste 1 au nouvel interlocuteur.
En cas d'Unified Communications Manager 10.0 et plus tard, voici le résultat :
1. Le C d'appelant (extn 2000) appelle l'agent A (extn 1000).
Le C (extn 2000) parle à l'agent A (extn 1000). Session S1 - COMMENCÉ - La piste 0 est A (extn 1000), la piste 1 est le C (2000)
2. L'agent A (extn 1000) consulte l'agent B (extn 3000).
3. Le C (extn 2000) entend le MoH. A (extn 1000) parle à B (extn 3000).
Considérations :
4. L'agent A (extn 1000) se termine le transfert.
5. Le C (extn 2000) parle à B (extn 3000).
6. A (extn 1000) a déconnecté.
Considérations :
7. L'agent B (extn 3000) raccroche.
8. Le C (extn 2000) et le B (extn 3000) ont déconnecté.
Note: Un transfert d'extrémité a comme conséquence l'extrémité d'une session enregistrée et le début d'une autre session enregistrée.
En cas d'Unified Communications Manager 9.x et plus tôt, voici le résultat :
1. Le C d'appelant (extn 2000) appelle l'agent A (extn 1000).
2. Le C (extn 2000) parle à A (extn 1000).
Session S1 COMMENCÉE - La piste 0 est A (extn 1000), la piste 1 est C (extn 2000).
3. L'agent A (extn 1000) consulte l'agent B (extn 3000).
4. Le C (extn 2000) entend des entretiens MoH A (extn 1000) à B (extn 3000)
Considérations :
5. L'agent A (extn 1000) se termine la conférence.
6. C (extn 2000) parlant à A (extn 1000) et à B (extn 3000).
Considérations :
Un transfert d'extrémité déclenche une MISE À JOUR de la session enregistrée existante.
La fin d'une conférence est mise en application :
Pendant la consultation :
Quand la conférence est terminée (tous les interlocuteurs connectés) :
En conséquence :
7. L'agent A (extn 1000) relâche de la conférence.
8. A (extn 1000) a déconnecté. C (extn 2000) parlant à la session S3 B (extn 3000) MISE À JOUR - la piste 0 est B (extn 3000), la piste 1 est C (extn 2000).
Considérations :
9. L'agent B (extn 3000) raccroche.
10. Le C (extn 2000) et le B (extn 3000) ont déconnecté.
Session S4 FINIE.
Considérations :
En cas d'Unified Communications Manager 10.x et plus tard, voici le résultat :
1. Le C d'appelant (extn 2000) appelle l'agent A (extn 1000).
2. Le C (extn 2000) parlant à la session S1 A (extn 1000) - COMMENCÉ - la piste 0 est A (extn 1000), la piste 1 est C (extn 2000).
3. L'agent A (extn 1000) consulte l'agent B (extn 3000).
4. Entendre MoH A (extn 1000) de C (extn 2000) parlant à B (extn 3000).
Considérations :
5. L'agent A (extn 1000) se termine la conférence.
6. C (extn 2000) parlant à A (extn 1000) et à B (extn 3000)
Considérations :
Un transfert d'extrémité déclenche l'extrémité d'une session enregistrée et le début d'un autre enregistrement. La fin d'une conférence est mise en application l'a répertorié ici :
7. L'agent A (extn 1000) relâche de la conférence
8. A (extn 1000) a déconnecté. C (extn 2000) parlant à B (extn 3000)
Considérations :
9. L'agent B (extn 3000) raccroche
10. Le C (extn 2000) et le B (extn 3000) ont déconnecté
Considérations :
Avec Unified Border Element bifurquant, très peu de situations causent un appel d'être coupé en plusieurs sessions enregistrées. L'Attente/Reprise, le transfert et les exécutions de conférence ne commencent pas de nouvelles sessions enregistrées dans la plupart des cas. Dans peu des cas où de nouvelles sessions sont créées, il y ont une valeur commune, CCID (ID de corrélation d'appel). Cette valeur est commune à toutes les sessions dans l'appel. CCID est la forme décimale de Cisco-GUID, une seule clé d'appel qui est générée par des Routeurs de Voix de Cisco. Le premier routeur qui reçoit un appel génère cette clé, et la passe en bas de la ligne à tous les périphériques ultérieurs comprenant le Cisco MediaSense.
Unified Border Element lui-même ne génère pas des valeurs de xRefCi, mais pour créer la similitude avec des appels téléphoniques bifurquants d'Unified Communications Manager, le Cisco MediaSense synthétise également une paire de valeurs de xRefCi pour chaque appel d'Unified Border Element. Ceux-ci peuvent être vus dans les métadonnées au niveau de piste, avec CCID, qui apparaît au niveau de session.
Ces situations causent des enregistrements d'Unified Border Element d'être coupés en plusieurs sessions :
Si un transfert, la conférence, la baisse de conférence, ou toute autre exécution fait renégocier les interlocuteurs leurs codecs, le Cisco MediaSense finit la session enregistrée en cours et commence un neuf. Les deux sessions partagent le même CCID et les mêmes paires de valeurs de xRefCi.
Un transfert de consultation est un transfert à partir d'un agent à l'autre, dans lequel les deux agents parlent entre eux tandis que l'appelant d'origine attend sur l'attente. Le tronçon de consultation de l'appel est lié d'une certaine façon à l'appel global, et il est possible de configurer l'Unified Communications Manager tels que consultez les appels traversent le CUBE. Cependant, Unified Border Element et le Cisco MediaSense ne savent pas que ces appels sont connexes, et ils créent un nouveau CCID et une nouvelle paire de valeurs de xRefCi pour cette session.
Ces appels peuvent être associés entre eux avec comparent des champs de deviceRef et d'horodateur de participant. Considérez ce scénario :
L'alerte dans ce scénario est dans l'étape 2. Au cours de cette période, l'agent A (deviceRef 1000) est un participant à deux sessions enregistrées immédiatement :
Par conséquent, le S1 est lié à S2 et à C1 est lié au C2.
D'abord, nous avons besoin d'une définition précise de consultons l'appel :
Tout appel secondaire qui est fait par un participant en cours à une session existante à un point final qui est l'extérieur qui session et qui exclut les autres participants à cette session.
Dans la théorie, ce scénario pourrait inclure un agent place l'appelant sur l'attente pour vérifier avec son patron pour la rupture de luch, ou même un agent a mis l'appelant sur l'attente pour recevoir un appel de son épouse, mais nous ignorons ces possibilités pour l'instant.
Il est possible pour application cliente de détecter un appel de consultation en temps réel par la piste du flot d'événement de Cisco MediaSense. Si le client observe un événement COMMENCÉ par session contient un deviceRef donné, avec un autre événement COMMENCÉ par session contient le même deviceRef sans l'événement FINI par session intervenant, il peut conclure que les sessionIds et le CCIDs trouvés dans les deux événements COMMENCÉS par session sont associés.
Historiquement, un client en peut vérifier consultent les appels qui sont associés avec un appel primaire donné, avec le Cisco MediaSense API. Supposez que le client connaît cet extn utilisé par A 1000 d'agent, dans CCID <C1>. Ce les instructions de trouver tout associé consultent des appels :
Étape 1. Récupérez les métadonnées de session pour l'appel primaire en émettant getSessionByCCID(<C1>).
Step2. Extrayez le sessionStartDate (appel il <Ta>), et le sessionDuration.
Step3. Calculez le sessionEndDate (appel il <Tb>) en ajoutant le sessionDuration au <Ta>.
Step4. Exécutez cette demande API :
IP address:8443/ora/queryService/query/getSessionsByDeviceRef?value=1000&minSessionStartDate=<Ta>&maxSessionStartDate=<Tb> de https://Mediasense
Cette requête peut renvoyer plus d'une session. S'il fait, alors on peut assumer que tous sont associés avec le même appel.
Toute la procédure mentionnée dedans consultent la section de détection d'appel, trouve consultent des appels faits à partir du périphérique qui a reçu l'appel téléphonique initial. Cependant, ce qui si là consultent des appels sont faits à partir d'un périphérique vers lequel l'appel a été ultérieurement transféré ?
Considérez cette procédure :
Cette procédure n'attrape pas l'appel de consultation entre l'agent 2 et l'agent 3.
Puisque c'est un appel d'Unified Border Element, nous pouvons nous servir du fait que toutes les connexions entre l'appelant et chacun des agents sont incluses en même session enregistrée, et du fait que tous les agents impliqués sont répertoriés comme participants à la même session à un moment ou un autre. Ainsi, des métadonnées primaires de session, nous pouvons collecter une liste de tous les deviceRefs qui étaient impliqués. Pour trouver ces sessions, nous pouvons faire une gamme des appels au getSessionsByDeviceRef, spécifie la plage de temps de la session primaire, ainsi qu'un deviceRef par demande.
Alternativement, le processus peut être simplifié avec une demande simple de getSessions de ce type :
{ "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 ] } ] } ] }
Cette requête renvoie tous les appels de consultation associés avec l'appel primaire d'origine et tous ses transferts.
Cette procédure moule réellement le net trop largement. Si par exemple, l'agent au deviceRef 4000 conduisait et terminait un appel complètement indépendant qui s'est avéré justement commencer après que <Ta> et avant qu'il a été ajouté à l'appel en question, cette procédure inclut qu'indépendant appelez dans le positionnement. Ce problème peut être résolu cependant, avec les informations disponibles dans les métadonnées de la session primaire. Les informations de chaque participant incluent le décalage de temps auquel il a joint la session et la durée de sa tenure. Code client pourrait l'utiliser que les informations pour supprimer simplement les sessions indépendantes de la liste qu'elle a reçue en haut. Ou, il pourrait formuler une gamme de getSessions ou de requêtes directs de getSessionByDeviceRef qui encadrent correctement les délais prévus lesoù chaque agent était dans l'appel primaire. Nous partons que comme exercice au lecteur.
Dans la section précédente, nous avons présenté des precedures pour la récupération de toutes les sessions associées avec une session enregistrée donnée de Cisco MediaSense. Cependant, nous avons également vu qu'un appel donné peut être divisé en plus d'une session, comme dans le cas d'un codec de mid-appel changeons.
Comment récupérons-nous tous les enregistrements (aussi bien que consulte) associés avec toutes les sessions connectées à l'interaction de l'appelant ?
La réponse est d'étendre le ce des instructions pour le detectiion du multiple consultent des appels. D'abord, nous collectons toutes les sessions qui partagent le CCID de la session primaire en question. Puis, nous établissons notre liste des participants de tous ces enregistrements de session. Ensuite, nous calculons les plages de temps comme sessionStartDate de la session la plus tôt par la fin de la dernière session. pour finir, nous pouvons exécuter la requête de getSessions affichée.
Comme avant, nous pouvons finir par avec la capture de trop d'enregistrements, ainsi nous pourrions exécuter une étape de post-traitement pour supprimer ces sessions indépendantes de sa liste.
Ces deux tables — une pour des appels d'Unified Communications Manager et une pour des appels d'Unified Border Element. Chaque colonne représente un composant de la solution ou le protocole, avec la première colonne représente le Cisco MediaSense. Chaque ligne représente un type particulier d'identifiant.
Pour lire les tables, commencez par une cellule qui représente l'élément de donnée que vous connaissez, et puis regarde horizontalement à la colonne représente le composant de la solution en lequel vous voulez trouver l'appel. L'entrée en cette cellule indique par quel nom le précis le même élément de donnée est connu dans le composant de cible. Si le composant de cible a une cellule vide dans cette ligne, alors cet élément de donnée n'est pas connu à ce composant. Vous pouvez à la place rechercher une colonne intervenante où vous pouvez croiser verticalement dans une autre ligne où cette cellule n'est pas vide dans la colonne du composant de cible.
Par exemple, avec un appel d'Unified Communications Manager, supposez que vous connaissez le GED-188 CallReferenceID et que vous voulez trouver l'appel dans le Cisco MediaSense. Vérifiez gauche de la colonne GED-188, vous voient qu'il n'y a aucune valeur dans la colonne de MediaSense, ainsi vous ne peut pas tracer directement à elle.
Cependant, il y a une colonne où vous pouvez zigzaguer à travers des lignes : Unified Communications Manager CDR. Un client peut sélectionner l'enregistrement approprié de l'Unified Communications Manager CDR en recherchant un dans lequel l'IncomingProtocolCallRef apparie le GED-188 CallReferenceID. Que l'enregistrement contient une valeur ont appelé destLegCallIdentifier, qui est identique que le xRefCi de MediaSense NearEnd, et peuvent donc être utilisés pour trouver l'enregistrement correspondant dans le Cisco MediaSense.
Des enregistrements de l'Unified Communications Manager CDR ne sont pas écrits jusqu'à une certaine heure après que la fin de l'appel se termine, cependant, ainsi cette méthode peut seulement être utilisée historiquement.
Il y a un autre chemin aussi bien. Regardez vers le bas du GED-188 CallReferenceID. Il s'avère que vous pouvez également employer l'AlertingDevice et l'AnsweringDevice pour apparier le champ de deviceRef dans MediaSense. Cette méthode fonctionne également en temps réel.
Considérations :
Pour le CUBE appelle, dépiste 0 trace toujours au flux multimédia de tronçon d'ancre. Le tronçon d'ancre est le cadran-pair que le profil d'enregistrement de medias est configuré. Le deuxième tronçon de non-ancre de cartes de piste.
Si vous avez le profil d'enregistrement de medias activé sur le dialpeer d'arrivée, alors le tronçon d'ancre devient le dans-tronçon. En d'autres termes, l'appelant apparaît dans la piste 0, et l'appelé apparaît dans la piste 1.
Si vous avez le profil d'enregistrement de medias activé sur le dialpeer sortant, alors le tronçon d'ancre devient le -tronçon. Dans cela le cas l'appelant apparaît dans la piste 1 et l'appelé apparaît dans la piste 0.
Pour l'Unified CM bifurquant, dans les scénarios simples d'appel vous pouvez employer les champs de xRefCi dans les métadonnées pour déterminer quel interlocuteur est dans quels medias dépistez. Le xRefCi numériquement plus petit se rapporte habituellement à la piste de l'appelant. La piste de l'appelé est numériquement plus grande (habituellement par une, mais eux pourraient être plus sous un système raisonnablement chargé). Cependant, ces valeurs de xRefCi s'enveloppent par la suite autour à zéro. Ainsi, si vous constatez qu'une valeur est un nombre élevé et l'autre est un petit nombre, vous supposez que leurs positions sont renversées.
Dans des scénarios plus compliqués, cet algorithme ne fonctionne pas toujours. Si des services supplémentaires sont appelés, comme des transferts et des conférences, et la batterie de gestionnaire UC se compose de plus d'un noeud, alors les valeurs de xRefCi ne sont pas nécessairement générées séquentiellement, et vous ne pouvez pas supposer que leur commande a n'importe quelle signification du tout. Un moyen direct de déterminer si l'ordre de commande d'une paire particulière de valeurs de xRefCi mettent en boîte sont de confiance est de regarder le premier octet des valeurs de xRefCi. Cet octet représente l'ID de noeud de gestionnaire UC sur lequel cet identifiant particulier a été créé. Si les premiers octets des deux valeurs de xRefCi sont identiques, alors leur commande est correcte. S'ils sont différents, alors la commande ne pourrait pas être correcte.
Pour ces cas, la seule manière de déterminer la direction d'appel en temps réel est de saisir les informations de n'importe quelle autre source, telle que le flux d'événement JTAPI. Une fois l'appel a fini et quelques minutes se sont écoulées, vous pouvez toujours déterminer les données CDR du gestionnaire UC de direction et de contrôle d'appel pour l'appel. Spécifiquement, le champ origLegCallIdentifier dans l'enregistrement CDR représente toujours l'appelant.
Les causes possibles pour un état de session de CLOSED_ERROR incluent :
1. Le serveur de Contrôle d'appel a reçu une réponse d'erreur du serveur de medias (enregistrement) pour la demande ouverte ou étroite.
2. Le serveur de Contrôle d'appel a détecté une erreur de signalisation de SIP, par exemple des disparus ACK.
3. La session a été avec succès clôturée, mais TOUTES LES pistes ont la taille zéro.
Quand une session est dans l'état active, il est normal qu'il n'y ait aucune durée dans les métadonnées, parce que la durée n'est pas connue jusqu'à ce que la session soit fermée.
Pour une session qui est dans l'état CLOSED_ERROR, si les champs de session ou de durée de piste ne sont pas présents dans l'événement ou les données de getSessions, puis le support pour cette piste n'est pas disponible.
Considérez ces deux requêtes :
Cette requête renvoie un ensemble de sessions, tous ce que de la session des états SONT SUPPRIMÉS :
https://Mediaserver IP address:8443/ora/queryService/query/getAllPrunedSessions?minSessionStartDate=1301788800000&maxSessionStartDate=1312329599000
Cette requête ne renvoie aucune session :
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 différence de comportement est par conception. Référez-vous à ceci des sections dans la documentation de MediaSense :
Employez cet API pour rechercher tous les enregistrements taillés… que le terme taillé se rapporte aux enregistrements qui sont supprimés par le système de Cisco MediaSense. Si vous avez explicitement supprimé n'importe quel enregistrement utilisant les deleteSessions API, alors ces enregistrements supprimés ne sont pas considérés en tant qu'enregistrements taillés.
Quand des sessions sont taillées, les métadonnées qui est associé avec ces sessions demeure dans la base de données, même après que ces sessions sont marquées en tant que « taillé ». Ce les métadonnées ne prend pas un grand nombre d'espace de stockage comparé aux enregistrements eux-mêmes mais il prend un certain espace et devrait être périodiquement retiré. Pour faciliter cette activité, les clients peuvent périodiquement émettre une demande API des sessions taillées, ou les clients peuvent choisir de recevoir des événements taillés par session et de supprimer explicitement ces événements dont les clients n'ont besoin plus.
Pour clarifier, les deux requêtes sont entièrement différentes. En fait, la deuxième requête (le lwhich recherche toutes les sessions dont l'état EST SUPPRIMÉ) renvoie toujours un positionnement vide. Les requêtes de jour en jour normales filtrent des sessions avec les états SUPPRIMÉS, même si c'est ce qui est demandé. La seule exception est des getAllPrunedSessions. Cette exception est destinée pour aider l'application pour trouver des sessions taillées de sorte que l'application puisse demander que ces sessions soient supprimées.
Une fois que vous utilisez les deleteSessions API sur la liste de sessions taillées que vous obtenez des getAllPrunedSessions, ces sessions n'apparaît plus dans le résultat des getAllPrunedSessions. De telles sessions est complètement retirées des métadonnées immédiatement.
Une autre manière de regarder ceci est que les sessions taillées ne sont pas la même chose que des sessions supprimées :
Quand vous avez une passerelle PSTN par laquelle appelle les écoulements, et vous voulez enregistrer ces appels. Ces appels sont des appels de TDM-à-SIP. Cependant, bifurquer de medias est seulement disponible aux appels de Sip-à-SIP.
Ces appels peuvent être enregistrés. Ces appels mettent en boîte dirigé par le routeur une deuxième fois. Des conseils de configuration et d'autres détails peuvent être trouvés en ce livre blanc.
Quand vous utilisez des medias bifurquant du CUBE, les métadonnées de MediaSense contient normalement l'extension de l'appelé. Cependant, si le nombre appelé est un numéro pilote de groupe de recherche de gestionnaire de transmissions, puis par défaut les métadonnées contient seulement ce numéro pilote. Il ne contient pas l'extension du téléphone qui a répondu réellement à l'appel.
Il y a une configuration de gestionnaire de transmissions qui peut changer ceci. À la page de configuration de recherche/pilote, trouvez la section autorisée des transformations connectées d'interlocuteur. La ligne d'affichage de configuration DN de membre du groupe en tant qu'interlocuteur connecté doit être activée.
Cette capacité est disponible dans le gestionnaire de transmissions 9.0(1) et plus tard.
Avec l'enregistrement Fondé(e) sur le réseau d'Unified Communications Manager (NBR), vous pouvez utiliser une passerelle pour enregistrer des appels. NBR permet à l'Unified Communications Manager pour conduire des appels d'enregistrement, indépendamment du périphérique, de l'emplacement, ou de la zone géographique. Avec NBR, les medias d'enregistrement d'appels peuvent être originaires du téléphone IP ou d'une passerelle qui est connectée à l'Unified Communications Manager au-dessus d'un joncteur réseau de SIP. L'Unified Communications Manager sélectionne dynamiquement la bonne source de medias basée sur l'écoulement et les participants de l'appel d'appel.
NBR offre une Construire-dans-passerelle automatique de retour (bavoir) quand les Integrated Services Router (ISR) sont indisponibles car aucune configuration de enregistrement distincte n'est exigée. C'est utile dans les cas où les clients veulent inclure l'agent-agent consultent des appels dans les stratégies d'enregistrement car Unified Border Element ne peut pas enregistrer consultent des appels, ainsi le bavoir doit être activé séparément.
NBR et appels de bavoir peuvent être corrélés utilisant le xRefci, qui est fourni par l'Unified Communications Manager JTAPI. CISCO-GUID n'est pas nécessaire, qui signifie que ni le serveur CTI ni les connexions CTIOS ne sont priés. Car il y a un identifiant simple de corrélation, la corrélation à travers des composants est plus forte et peut être faite dans un indépendant uniforme de manière de l'écoulement d'appel.
Le NBR, direct-étant composé aussi bien que des appels sortants numéroteur-initiés peuvent être corrélés avec leur apparence dans d'autres composants de la solution.
Avec NBR, l'enregistrement de passerelle TDM est automatiquement utilisé sans le fractionnement de la capacité du routeur. Actuellement, l'enregistrement de passerelle TDM n'est pas pris en charge avec MediaSense 10.5.
Un noeud peut prendre plusieurs heures pour améliorer dépend du nombre et de la taille d'enregistrements qu'elle se tient. Pour MediaSense 10.5, quand vous améliorez un noeud avec les postes de données très grands, cela prend environ 90 minutes supplémentaires par 1 million d'enregistrements.
Les utilisateurs du MediaSense les recherchent et l'application de jeu est affectée s'ils se trouvent dans des fuseaux horaires affectés l'uns des ou s'ils sélectionnent un fuseau horaire affecté dans les critères de recherche. Les Produits de partenaire de tiers qui se connectent par interface à MediaSense sont affectés pareillement jusqu'à ce qu'ils mettent à jour leurs tables respectives de fuseau horaire.
Le contournement est de sélectionner un fuseau horaire qui apparie le décalage correct du GMT même si ville n'est plus correcte.
Voici les langages pris en charge par MediaSense :
Pour surveiller la performance du système de MediaSense, analysez les valeurs de ces indicateurs de performances de clé (ICP) avec l'outil principal d'assurance d'outil RTMT ou de Collaboration de Cisco.
Pour plus d'informations sur l'outil principal d'assurance d'outil RTMT ou de Collaboration de Cisco, référez-vous les sections Administration principales unifiées d'assurance de gestion RTMT et de Collaboration de Cisco du guide utilisateur de Cisco MediaSense.
Indicateur de performances de clé | Compteurs RTMT | Valeurs seuil suggérées |
---|---|---|
Taux de réussite des appels | Service de Contrôle d'appel de MediaSense > nombre de sessions enregistrées sans erreurs Service de Contrôle d'appel de MediaSense > nombre de sessions enregistrées avec des erreurs |
99.99% Taux de réussite des appels = nombre de sessions enregistrées sans erreurs/(nombre de sessions enregistrées sans erreurs + nombre de sessions enregistrées avec des erreurs) * 100 |
Temps de réponse API moyenne pour l'API | Temps de réponse de requête de service > de moyen du Cisco MediaSense API | 60 sec |
Retard d'installation de moyen de début d'enregistrement | Retard d'installation de service > de moyen de Contrôle d'appel de Cisco MediaSense | 3 sec |
Utilisation de moyen CPU | Processeur > % de temps- CPU | 90 % |
Moyenne utilisation de mémoire | Mémoire > %Mem utilisé | 70% |
Perte de paquets RTP/UDP | Interface réseau > Rx relâché > eth0 Interface réseau > erreurs de Rx > eth0 |
0 0 |
Basé sur le navigateur, exécutez ces étapes pour exécuter le lecteur de dans-navigateur :
Internet Explorer 9 | Internet Explorer 11 | Mozilla Firefox |
---|---|---|
1. En recherche et jeu de MediaSense, cliquez sur l'icône de jeu d'une session enregistrée. | Conditions préalables : En cas de frais installez de MediaSense 11.0, s'assurent que des Noeuds de MediaSense sont ajoutés à la batterie utilisant le nom de domaine complet respectif (FQDN). En cas de mise à jour à MediaSense 11.0, assurez-vous que les Noeuds de MediaSense qui ont été précédemment ajoutés utilisant l'adresse Internet, devraient maintenant être affichés par le FQDN respectif. Vérifiez la liste de serveur de MediaSense dans la fenêtre de configuration du serveur de MediaSense (gestion de Cisco MediaSense > système > configuration du serveur de MediaSense). |
1. Ajoutez le certificat auto-signé d'un noeud de MediaSense pour le port 8446 de mp4url dans l'autorité de confiance de Mozilla Firefox. |
2. Clic oui pour faire confiance au certificat. Remarque: Vérifiez que le certificat auto-signé offert est du noeud visé de MediaSense en validant le FQDN dans les détails techniques du certificat. |
Exécutez les étapes suivantes : 1. Placez le hostnameformediaurl CLI de positionnement en tant que « vrai » pour faire MediaSense préparer le mp4url et le reste des mediaurls utilisant le FQDN seulement. admin:set useHostNameForMediaURL admin:set useHostNameForMediaURL true 2. Redémarrez le service de configuration pour lancer la propriété. admin:utils service restart Cisco MediaSense Configuration Service Remarque: Si le service n'a pas redémarré correctement, exécutez la même commande de nouveau. |
2. Pour ajouter le certificat auto-signé, cliquez sur l'icône de téléchargement d'une session enregistrée et sélectionnez mp4. Cette connexion est fenêtre externe non approuvée apparaît. |
3. Cliquez sur l'icône de jeu correspondant à l'enregistrement sélectionné. Le lecteur de dans-navigateur lit la session d'enregistrement sélectionné. |
Exécutez les étapes suivantes pour ajouter le certificat auto-signé par MediaSense à Windows a fait confiance à l'autorité. 1. Recherche et jeu ouverts de MediaSense. The import was successful. 12. Cliquez sur OK. |
2. Pour ajouter le certificat auto-signé, cliquez sur l'icône de téléchargement d'une session enregistrée et sélectionnez mp4. Cette connexion est fenêtre externe non approuvée apparaît. Remarque: Vérifiez que le certificat auto-signé offert est du noeud visé de MediaSense en validant le FQDN dans les détails techniques du certificat. |
3. Le clic I comprennent le lien de risques. | ||
4. Cliquez sur Add l'exception. La fenêtre externe d'exception de Sécurité d'ajouter apparaît. |
||
5. Le clic confirment l'exception de Sécurité. Le certificat auto-signé du noeud particulier de MS du port 8446 obtient ajouté à l'autorité de confiance du navigateur. |