FAQ’s voor Cisco MediaSense
Inhoud
Inleiding Voorwaarden Vereisten
Gebruikte componenten
1. Hoe correleer u referentie vraag IDs voor verschillende telefoonscenario's, onder Unified Communications Manager telefoon forking?
1.1. Zoeken en afspelen van gesprekken met MediaSense 1.2. Scenario voor Agent Hold/Resume
1.3. Klantenvoorraad/herstellingsscenario
1.4. Overdracht van Agent naar een ander Agent-scenario 1.5. Agent-conferenties met een ander agentenscenario
2. Hoe correleren we referentie-ID’s voor verschillende gesprekssessies, bij het maken van Unified Border Element?
2.1. Tussentijdse codec-wijziging 2.2. Overdrachten raadplegen 2.3. Detectie van oproepen
2.4. Ontdekking van oproepen door meerdere deelnemers 2.5. Samenvatting
3. Hoe associeert u oproepen in Cisco MediaSense met hun uiterlijk in andere oplossingscomponenten?
3.1. Concordantietabel van identificatiemiddelen
4. Hoe bepaalt u welk spoor de oproepende partij heeft en welk spoor de opgeroepen partij heeft?
4.1. Voor door CUBE opgeroepen oproepen
4.2. Voor oproepen die worden gedaan door Unified CM-telefoons
5. Wat zijn de mogelijke oorzaken van een sessiestatus van CLOSED_FOUT?
6. Wat is het verschil tussen afgebroken en afgeschreven sessies?
6.1. Met GetAllPrunedSessions Query 6.2. Met GetSessions Query
6.3. Waarom het gedragsverschil in geprunde en verwijderde sessies?
7. Hoe moet u een TDM-gateway instellen voor het maken van media?
8. Hoe kan je de echte doeltelefoon opnemen wanneer je een stuntgroep gebruikt?
9. Waarom wordt Unified Communications Manager-netwerkgebaseerde opname aanbevolen als een voorkeursmechanisme?
10. Waarom duurt het langer om een knooppunt te upgraden naar MediaSense 10.5?
11. Wat is de invloed van de wijzigingen in de Russische tijdzone op de toepassing MediaSense Search and Play?
12. Welke talen worden ondersteund door MediaSense?
13. Hoe de prestaties van het MediaSense-systeem te controleren?
14. Hoe moet je een browser configureren om een in-browser-speler in MediaSense te laten draaien?
Inleiding
Dit document beschrijft veelgestelde vragen voor Cisco Media Sense server.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
Cisco MediaSense
●
Cisco Unified Communications Manager (CUCM)
●
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
Cisco MediaSense release 10.5
1. Hoe correleer u referentie vraag IDs voor verschillende telefoonscenario's, onder Unified Communications Manager telefoon forking?
In Cisco MediaSense verstrekken de meta-gegevens voor elke oproep alleen de xRefCi (referentie call ID) en het apparaat ref (extensie) van het forking apparaat en het extreem-end apparaat (kan een conferentiebrug of een andere telefoon zijn).
De xRefCi parameter is het herkenningsteken van Unified Communications Manager voor een bepaalde mediastroom. Ze komen niet altijd overeen met 1:1 met de geregistreerde sporen.
1.1. Zoeken en afspelen van gesprekken met MediaSense
MediaSense genereert meerdere sessies voor een oproep die wordt opgenomen in het geval van een hold-up/CV of overdracht, waardoor het moeilijk is alle opnamesessies in een oproep te identificeren. Om deze opnamesessies in één enkele vraag te kunnen associëren, introduceert MediaSense een nieuwe eigenschap die als Associatie van Bel wordt genoemd. Door deze eigenschap, worden alle sterk verbonden vraag met een gemeenschappelijke xRefci waarde gegroepeerd. MediaSense 10.5 ondersteunt de Call Association optie voor ingebouwde brug opnames.
1.2. Scenario voor Agent Hold/Resume
Agent A (extn 1000) en beller C (extn 2000) riepen elkaar en in praakende staat op.
1.
Agent A zet telefoontje op.
2.
Agent A belt terug.
3.
Er zijn twee opnamesessies voor dit scenario:
SessionID = S1 met deze twee sporen, voor de periode /het segment voordat de agent aanzet om te kunnen:
trackNumber = 0 met deelnemer A (deviceRef = 1000, xRefCi = aaaa) trackNumber = 1 met deelnemer B (deviceRef = 2000, xRefCi = ccc)
●
SessionID = S2 met deze twee sporen, voor de periode / het segment nadat de agent het gesprek hervat.
trackNumber = 0 met deelnemer A (deviceRef = 1000, xRefCi = aaaa) trackNumber = 1 met deelnemer B (deviceRef = 2000, xRefCi = ccc)
●
MediaSense neemt het segment van het gesprek niet op terwijl de agent de oproep heeft geblokkeerd.
1.3. Klantenvoorraad/herstellingsscenario
Agent A (extn 1000) en beller C (extn 2000) riepen elkaar en in praaktoestand.
1.
Customer C stelt de oproep in de wacht.
2.
Customer C hervat het gesprek.
3.
De gehele oproep wordt in één sessie opgenomen voor dit scenario:
Session.ID = S1 met deze twee sporen:
trackNumber = 0 met deelnemer A (deviceRef = 1000, xRefCi = aaaa) trackNumber = 1 met deelnemer B (deviceRef = 2000, xRefCi = ccc)
●
In dit scenario registreert MediaSense ook het segment van de vraag terwijl de klant de vraag op te houden heeft geplaatst.
1.4. Overdracht van Agent naar een ander Agent-scenario
Bel C (uitgebreid 2000) roept agent A (uitgebreid 1000) op 1.
Agent A (uitgebreid 1000) consulten met agent B (3000) 2.
Agent A (extn 1000) voltooit de overdracht.
3.
Agent B (extn 3000) hangt omhoog.
4.
Met Unified Communications Manager 9.x en eerder worden de resultaten weergegeven:
1.Caller C (uitgebreid 2000) roept Agent A (uitgebreid 1000) op
Session S1 STARTED, Track 0 is A (extn 1000), Track 1 is C (extn 2000).
2.Agent A (extn 1000) overschrijvingen belt naar een andere agent B (extn 3000). Zowel A- als B- inrichtingen zijn ontworpen voor het maken.
3.Caller C (uitgebreid 2000) hoort muziek op Hold (MoH).
4.Agent A (extn 1000) praat met B (extn 3000).
Sessie S1 BEËINDIGD
●
Session S2 STARTED, Track 0 is A (extn 1000), Track 1 is B (extn 3000)
●
Session S3 STARTED, Track 0 is B (extn 3000), Track 1 is A (extn 1000)
●
Opmerkingen:
Session S1 eindigt als gevolg van Agent Een telefoon heeft Nummer C op zijn plaats gezet.
●
Sessies S2 en S3 bestaan omdat beide telefoons voor het maken zijn geconfigureerd.
●
De deelnemers en de xRefCi voor de twee deelnemers in S2 en S3 zijn identiek, maar in omgekeerde posities.
●
RefCi-waarden van S1 worden niet gereflecteerd in S2 of S3, aangezien de consultatie als een onafhankelijke oproep wordt beschouwd.
●
5.Agent A (extn 1000) voltooit de overdracht.
6.C (uitgebreid 2000), met B (uitgebreid 3000).
7.A (uitgebreid 1000) losgekoppeld.
Sessie S2 BEËINDIGD.
Session S3 UPDATED, en track 0 is B (extn 3000) en spoor 1 is C (extn 2000).
Opmerkingen:
Een extreem-eindoverdracht leidt tot een UPDATE van de bestaande opnamesessie.
●
De extreem-end deelnemer verandert in die van S1.
●
S3 nieuwe end-end RefCi komt overeen S1 ver-end xRefCi.
●
Agent B (extn 3000) hangt omhoog.
●
C (uitgebreid 2000) en B (uitgebreid 3000) zijn losgekoppeld.
●
Session S3 voltooid
●
Opmerking: Een veel te lange overdracht resulteert in een update van de bestaande sessie.
De forking phone blijft de enige deelnemer in Track 0, maar de deelnemer in Track 1 verandert de nieuwe partij.
In het geval van Unified Communications Manager 10.0 en hoger is dit het resultaat:
1. Bel C (uitgebreid 2000) als agent A (uitgebreid 1000).
C (uitgebreid 2000) praat met agent A (uitgebreid 1000). Session S1 - STARTED - Track 0 is A (extn 1000), Track 1 is C (2000)
2. Agent A (extn 1000) raadpleegt Agent B (extn 3000).
3. C (uitgebreid 2000) hoort MoH. A (uitgebreid 1000) praat met B (uitgebreid 3000).
Session S1 - einde
●
Session S2 - STARTED - Track 0 is A (extn 1000), Track 1 is B (extn 3000)
●
Session S3 - STARTED - Track 0 is B (extn 3000), Track 1 is A (extn 1000)
●
Opmerkingen:
Session S1 eindigt omdat Agent A phone C op slot heeft gezet.
●
Sessies S2 en S3 bestaan beide omdat beide telefoons voor het maken zijn geconfigureerd.
●
De deelnemers en de xRefCi voor de twee deelnemers in S2 en S3 zijn identiek, maar in omgekeerde posities van elkaar.
●
S1 xRefCi-waarden worden niet gereflecteerd in S2 of S3, omdat de consultatie als een onafhankelijke call wordt beschouwd
●
4. Agent A (extn 1000) voltooit de overdracht.
5. C (uitgebreid 2000) praat met B (uitgebreid 3000).
6. A (uitgebreid 1000) losgekoppeld.
Session S3 - einde
●
Session S2 - einde
●
Session S4 - STARTED - Track 0 is B (extn 3000), Track 1 is C (extn 2000)
●
Opmerkingen:
Een extreem-eindoverdracht leidt tot het eind van één opnamesessie en het begin van een andere opnamesessie.
●
Hoewel een nieuwe sessie begint, komen de xRefCi-waarden overeen met de vorige sessies.
●
S4 end-end RefCi komt overeen S1 ver-end xRefCi, en S4 dichtbij-end xRefCi lucifers S3 dichtbij-end xRefCi.
●
7. Agent B (extn 3000) staat op.
8. C (uitgebreid 2000) en B (uitgebreid 3000) losgekoppeld.
Session S4 - einde
●
Opmerking: Een eindoverdracht resulteert in het eind van één opnamesessie en het begin van een andere opnamesessie.
1.5. Agent-conferenties met een ander agentenscenario
Caller C (uitgebreid 2000) roept Agent A (uitgebreid 1000).
1.
Agent A (extn 1000) raadpleegt Agent B (extenn 3000).
2.
Agent A (uitgebreid 1000) voltooit conferentie.
3.
Agent A (uitgebreid 1000) daalt van de conferentie.
4.
Agent B (extn 3000) hangt omhoog.
5.
In het geval van Unified Communications Manager 9.x en eerder, is dit het resultaat:
1. Bel C (uitgebreid 2000) als agent A (uitgebreid 1000).
2. C (uitgebreid 2000) praat met A (uitgebreid 1000).
Sessie S1 STARTED - baan 0 is A (extn 1000), spoor 1 is C (extn 2000).
3. Agent A (extn 1000) raadpleegt Agent B (extn 3000).
4. C (uitgebreid 2000) hoort MoH A (uitgebreid 1000) gesprekken met B (uitgebreid 3000) Sessie S1 BEËINDIGD
●
Session S2 STARTED - Track 0 is A (extn 1000), Track 1 is B (extn 3000)
●
Session S3 STARTED - Track 0 is B (extn 3000), Track 1 is A (extn 1052)
●
Opmerkingen:
Session S1 eindigt omdat Agent A phone C op slot heeft gezet.
●
Sessies S2 en S3 bestaan omdat beide telefoons voor het maken zijn geconfigureerd.
●
De deelnemers en de xRefCi voor de twee deelnemers in S2 en S3 zijn identiek, maar in omgekeerde posities van elkaar.
●
S1 xRefCi-waarden worden niet gereflecteerd in S2 of S3, omdat de consultatie als een onafhankelijke oproep wordt beschouwd.
●
5. Agent A (uitgebreid 1000) voltooit de conferentie.
6. C (uitgebreid 2000) die met A (uitgebreid 1000) en B (uitgebreid 3000) praten.
Sessie S2 BEËINDIGD
●
Session S3 UPDATED - Track 0 is B (volgend jaar 3000), Track 1 is Conference Bridge
●
Session S4 STARTED - Track 0 is A (extn 1000), Track 1 is Conference Bridge
●
Opmerkingen:
Een extreem-eindoverdracht leidt tot een UPDATE van de bestaande opnamesessie.
De afronding van een conferentie wordt uitgevoerd:
Tijdens het volgende raadpleeg:
De raadplegende telefoon heeft een eerste aanroep om te kunnen houden en een actieve consultatieoproep.
●
De geraadpleegde telefoon heeft slechts één actief gesprek (de consultatieoproep).
●
Na afloop van de conferentie (alle betrokken partijen):
De consultatietelefoon raadpleegt de gespreksbeëindiging.
●
Het primaire telefoontje van de consultatietelefoon krijgt een vergaande overdracht naar de conferentiebrug.
●
De geraadpleegde telefoon krijgt een verreikende overdracht naar de conferentiebrug.
●
Dit leidt tot:
S2 eindigt, omdat het de consultatie vraag van de telefoon vertegenwoordigt, die ook eindigt.
●
S4 start; het betekent de voortzetting en de vergaande overdracht van A's primaire oproep, maar het oorspronkelijke S1 kan niet worden bijgewerkt omdat het eerder werd beëindigd vanwege eerdere vertraging.
●
S3 krijgt UPDATED omdat B's verre einde simpelweg van A naar de conferentiebrug wordt overgebracht.
●
S4-waarde van bijna-end RefCi komt overeen met de S1-waarde van bijna-end xRefCi.
●
7. Agent A (extn 1000) daalt van de conferentie.
8. A (uitgebreid 1000) losgekoppeld. C (extn 2000) die spreekt met B (extn 3000)-sessie S3 - Track 0 is B (extn 3000), Track 1 is C (extn 2000).
Opmerkingen:
De de-escalatie van een conferentie in een normaal gesprek van twee partijen wordt geïmplementeerd als de overblijvende telefoons op elkaar overstappen
●
Een extreem-eindoverdracht leidt tot een UPDATE van de bestaande opnamesessie.
●
S3 en S1 hebben overeenkomende exRefCi-waarden aan het eind. Merk op dat slechts één sessie actief blijft omdat Caller C geen forking ingeschakeld heeft.
●
9. Agent B (extn 3000) staat op.
10. C (uitgebreid 2000) en B (uitgebreid 3000) losgekoppeld.
Sessie S4 BEËINDIGD.
Opmerkingen:
Een veel te lange overdracht resulteert in een update van de bestaande sessie. De forking phone blijft de enige deelnemer in Track 0, maar de deelnemer in Track 1 verandert de nieuwe partij.
●
Er wordt een conferentie gecreëerd met overdracht van alle telefoons naar de
conferentiebrug. Daarom werkt een conferentie als een verzameling overdrachtsbetalingen.
Bestaande sessies worden in die sessies geactualiseerd; de telefoon blijft de enige deelnemer in Track 0, maar de deelnemer in Track 1 verandert de conferentiebrug.
●
Zodra de derde partij afziet van de conferentie, worden de partijen aan elkaar overgedragen.
Dit actualiseert de bestaande sessies opnieuw, de forking phone blijft de enige deelnemer in Track 0, maar de deelnemer in Track 1 verandert de andere partij.
●
Als een vierde partij aan de conference bridge wordt toegevoegd, is er geen indicatie in de metagegevens, tenzij de vierde partij ook zijn eigen forking-mogelijkheid heeft.
●
In het geval van Unified Communications Manager 10.x en later, is dit het resultaat:
1. Bel C (uitgebreid 2000) als agent A (uitgebreid 1000).
2. C (extn 2000) dat verwijst naar A (extn 1000)-sessie S1 - STARTED - Track 0 is A (extn 1000), Track 1 is C (extn 2000).
3. Agent A (extn 1000) raadpleegt Agent B (extn 3000).
4. C (extn 2000)-hoorzitting met MoH A (extn 1000) met B (extn 3000).
Session S1 - einde
●
Session S2 - STARTED - Track 0 is A (extn 1000), Track 1 is B (extn 3000)
●
Session S3 - STARTED - Track 0 is B (extn 3000), Track 1 is A (extn 1000)
●
Opmerkingen:
Session S1 eindigt omdat Agent A's telefoon Caller C op slot heeft gezet.
●
Sessies S2 en S3 bestaan omdat beide telefoons voor het maken zijn geconfigureerd.
●
De deelnemers en de xRefCi voor de twee deelnemers in S2 en S3 zijn identiek, maar in omgekeerde posities van elkaar.
●
S1 xRefCi-waarden worden niet gereflecteerd in S2 of S3, omdat de consultatie als een onafhankelijke call wordt beschouwd
●
5. Agent A (uitgebreid 1000) voltooit de conferentie.
6. C (uitgebreid 2000) die spreekt met A (uitgebreid 1000) en B (uitgebreid 3000) Session S2 - einde
●
Session S3 - einde
●
Session S4 - STARTED - Track 0 is A (extn 1000), Track 1 is Conference Bridge
●
Session S5 - STARTED - Track 0 is B (extn 3000), Track 1 is Conference Bridge
●
Opmerkingen:
Een extreem-eindoverdracht leidt tot het eind van één opnamesessie en het begin van een andere
opname. Hieronder staat de voltooiing van een conferentie:
Tijdens het volgende raadpleeg: De consultphone heeft een primair geluid tijdens de eerste uren van een woning en een actief consultatiegesprekDe geraadpleegde telefoon heeft slechts één actief gesprek (de consultatieoproep)
●
Na afloop van de conferentie (alle betrokken partijen):
●
De consultatietelefoon raadpleegt gesprekken
●
Het primaire telefoontje van de consultatietelefoon krijgt een vergaande overdracht naar de conferentiebrug
●
De geraadpleegde telefoon heeft een verreiking naar de conferentiebrug
●
Dit leidt tot: Er worden twee nieuwe sessies gecreëerd omdat zowel Agent A als Agent B zijn ingeschakeldS4 end-of-end xRefCi-waarde en S1 bijna-end xRefCi- waardeovereenkomstenS5-waarde aan het einde van rfCi en S3-waarde aan het einde van xRefCiDe extreem-eindwaarden van RefCi voor S4 en S5 komen niet overeen, ook al zijn beide verbonden met dezelfde conferentiebrug
●
7. Agent A (extn 1000) daalt van de conferentie
8. A (uitgebreid 1000) losgekoppeld. C (uitgebreid 2000) met B (uitgebreid 3000) Session S4 - einde
●
Sessiesessie S5 - beëindigd
●
Session S6 - STARTED - Track 0 is B (extn 3000), Track 1 is C (extn 2000)
●
Opmerkingen:
De de-escalatie van een conferentie in een normaal gesprek van twee partijen wordt geïmplementeerd als de overblijvende telefoons op elkaar overstappen
●
Een extreem-eindoverdracht leidt tot het einde van één opnamesessie en het begin van een andere opnamesessie
●
S6 en S5 worden corresponderend met bijna-end xRefCi-waarden. Merk op dat slechts één sessie actief blijft omdat Caller C geen forking heeft ingeschakeld
●
9. Agent B (extn 3000) houdt op
10. C (uitgebreid 2000) en B (uitgebreid 3000) losgekoppeld Session S6 - einde
●
Opmerkingen:
Een eindoverschrijving resulteert in het einde van de ene sessie en het begin van de volgende
●
Er wordt een conferentie gecreëerd met overdracht van alle telefoons naar de
conferentiebrug. Daarom werkt een conferentie als een verzameling overdrachtsbetalingen.
Bestaande sessies worden beëindigd en er worden nieuwe sessies gecreëerd tussen de valse telefoons en de conferentiebrug
●
Zodra de derde partij afziet van de conferentie, worden de partijen aan elkaar overgedragen.
Hiermee worden de sessies afgesloten die de conferentiebrug bevatten en nieuwe sessies gestart tussen de twee resterende eindpunten
●
Als een vierde partij aan de conference bridge wordt toegevoegd, is er geen indicatie in de metagegevens, tenzij de vierde partij ook zijn eigen forking-mogelijkheid heeft
●
2. Hoe correleren we referentie-ID’s voor verschillende
gesprekssessies, bij het maken van Unified Border Element?
Als het element Unified border-element wordt vervormd, veroorzaken zeer weinig situaties dat een oproep in meerdere opnamesessies wordt gesplitst. De handelingen van de a/m houden, van de overdracht en van de conferentie beginnen geen nieuwe opnamesessies in de meeste gevallen. In weinig gevallen waar nieuwe sessies worden gecreëerd, is er een gemeenschappelijke waarde, CCID (Call Correlatie ID). Deze waarde is gemeenschappelijk voor alle sessies in de oproep.
CCID is de decimale vorm van Cisco-oundbuis, een unieke vraagsleutel die door Cisco
spraakrouters wordt gegenereerd. De eerste router die een vraag ontvangt genereert deze sleutel en geeft deze door aan alle daaropvolgende apparaten inclusief Cisco MediaSense.
Unified Border Element zelf genereert geen xRefCi-waarden, maar om overeenkomsten met Unified Communications Manager te maken bij het maken van oproepen, synthetiseert Cisco MediaSense ook een paar xRefCi-waarden voor elke Unified Border Element-oproep. Deze kunnen worden gezien in de metagegevens op het niveau van de sporen, samen met CCID, die op sessieniveau verschijnen.
Deze situaties veroorzaken om de opnames van het Unified border-element in meerdere sessies te splitsen:
2.1. Tussentijdse codec-wijziging
Als een overdracht, conferentie, conferentiedaling, of andere verrichting de partijen ertoe aanzet opnieuw te onderhandelen over hun codec, eindigt Cisco MediaSense de huidige opnamesessie en begint een nieuwe. De twee sessies delen dezelfde CCID en hetzelfde paar xRefCi-waarden.
2.2. Overdrachten raadplegen
Een consulaire overdracht is een overdracht van de ene agent naar de andere, waarbij de twee agenten met elkaar praten terwijl de oorspronkelijke beller wacht op de kap. Het
raadplegingsgedeelte van de vraag is op één of andere manier verwant aan de algemene vraag, en het is mogelijk om Unified Communications Manager te vormen zo dat de vraag DO pass door CUBE raadpleegt. Maar Unified Border Element en Cisco MediaSense weten niet dat deze
oproepen verwant zijn, en zij creëren een nieuwe CCID en een nieuw paar xRefCi waarden voor deze sessie.
Deze aanroepen kunnen met elkaar in verband worden gebracht met vergelijking van de velden van participant deviceRef en timestamp. Neem dit scenario in overweging:
Bel C (uitgebreid 2000) roept Agent A (uitgebreid 1000) (sessieID = S1, CCID = C1) 1.
Agent A consults met Agent B (uitgebreid 3000) (sessieID = S2, CCID = C2) 2.
Agent A druppels, en de gesprekken van de Beer C met Agent B (sessieID = S1, CCID = C1)
3.
De rode vlag in dit scenario is in Stap 2. Gedurende die periode is Agent A (deviceRef 1000) een deelnemer in twee opnamesessies tegelijk:
Sessie = S1 / CCID = C1 en
●
Sessie = S2 / CCID = C2
●
Daarom is S1 gerelateerd aan S2 en is C1 gerelateerd aan C2.
2.3. Detectie van oproepen
Ten eerste hebben we een duidelijke definitie nodig van raadplegingsoproepen:
Elke secundaire oproep die wordt gedaan door een huidige deelnemer aan een bestaande sessie aan een eindpunt dat buiten die sessie is en dat de andere deelnemers aan die sessie uitsluit.
In theorie zou dit scenario een agent kunnen omvatten die de beller in de gaten houdt om voor een pauze bij zijn baas te controleren, of zelfs een agent die de beller in de wacht zet om een telefoontje van zijn vrouw te ontvangen, maar we negeren deze mogelijkheden voorlopig.
Het is mogelijk voor een clienttoepassing om een openbare aanroep in real-time te detecteren door het volgen van de Cisco MediaSense-eventstream. Als de client een sessie STARTED-event observeert, bevat een andere sessie STARTED-gebeurtenis hetzelfde apparaatRef zonder
tussenkomst van de sessie Eind-gebeurtenis, kan deze concluderen dat de sessie Ids en de CCIDs die gevonden zijn in de twee sessie STARTED-gebeurtenissen gekoppeld zijn.
Historisch, kan een client om het even welke raadpleeg vraag controleren die aan een bepaald primair verzoek is gekoppeld, met Cisco MediaSense API. Stel dat de klant weet dat Agent A gebruikt heeft behalve 1000, in CCID <C1>. Deze instructies om elke gekoppelde consultatie te vinden:
Stap 1. Neem de sessiemetagegevens voor de primaire vraag terug door GetSessionByCCID(<C1>) uit te geven.
Stap 2. Trek de sessieStartDate (noem het <a>) en sessieDuur uit.
Stap 3. Bereken de sessieEndDate (vraag het <Tb>) door sessieDuration aan <Ta> toe te voegen.
Stap 4. Start dit API-verzoek:
https://Mediasense IP-
adres:843/ora/queryService/query/getSessionsByDevicesRef?value=1000&minSessionStartDate=
<Ta>&maxSessionStartDate=<Tb>
Deze query kan meer dan één sessie teruggeven. Als dat wel het geval is, dan kunnen ze allemaal gekoppeld worden aan dezelfde aanroep.
2.4. Ontdekking van oproepen door meerdere deelnemers
De procedure die in raadpleeg de sectie van de vraagdetectie wordt vermeld, vindt alle raadpleeg oproepen gemaakt van het apparaat dat het eerste telefoongesprek ontving. Maar wat als er consultaties zijn van een apparaat waarop de oproep vervolgens is overgebracht?
Denk aan deze procedure:
Bel Agent 1 1.
Agent 1 raadpleegt met Agent 2, en laat vallen 2.
Het programma van de bezoeker spreekt met Agent 2 3.
Agent 2 raadpleegt met Agent 3, en laat dan vallen 4.
Het programma spreekt met Agent 3 5.
Deze procedure vat de consultatieoproep tussen Agent 2 en Agent 3 niet.
Aangezien dit een Unified Border Element-oproep is, kunnen we gebruik maken van het feit dat alle verbindingen tussen de beller en elk van de agenten in dezelfde opnamesessie zijn
opgenomen, en het feit dat alle betrokken agenten zijn opgenomen als deelnemers aan dezelfde sessie op één of ander moment. Dus, vanaf de primaire sessie-metagegevens, kunnen we een lijst verzamelen van alle betrokken apparatenRefs. Om die sessies te vinden, kunnen we een serie oproepen maken omte krijgen SessionsByDevicesRef, specificeert het tijdbereik van de primaire sessie, samen met één apparaatRef per verzoek.
U kunt het proces ook vereenvoudigen door één verzoek uit een van de volgende sessies in te dienen:
{
"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 ]
}
] } ] }
Deze query retourneert alle consulaire oproepen gekoppeld aan de oorspronkelijke primaire oproep en alle overdrachten ervan.
Deze procedure werpt het net te breed op. Bijvoorbeeld, als de agent op deviceRef 4000 een volledig onafhankelijke oproep plaatste en stopte die begon na <Ta> en voordat hij werd
toegevoegd aan de betreffende oproep, omvat deze procedure die onafhankelijke oproep in de set. Dit probleem kan echter worden opgelost met de informatie beschikbaar in de metadata van de primaire sessie. De informatie van elke deelnemer omvat de tijdspanne waarin hij zich bij de sessie heeft aangesloten en de duur van zijn ambtstermijn. Clientcode kan die informatie
gebruiken om de niet-gerelateerde sessies simpelweg te verwijderen uit de lijst die hij eerder heeft ontvangen. Of hij kan een reeks directe sessies formuleren of vragen van SessionByDevicesRef krijgen, die de tijdsperioden waarin elke agent in de primaire oproep zat correct samenvatten. We laten dat als een oefening aan de lezer over.
2.5. Samenvatting
In de bovenstaande sectie hebben we precedenten geschetst voor het ophalen van alle sessies die gekoppeld zijn aan een bepaalde Cisco MediaSense-opnamesessie. Maar we hebben ook gezien dat een bepaalde oproep in meer dan één sessie kan worden verdeeld, zoals in het geval van een mid-call codec wijziging.
Hoe halen we alle opnames (zowel als consults) op die gekoppeld zijn aan alle sessies die verbonden zijn met de interactie van de beller?
Het antwoord is om deze instructies voor het detecteren van meerdere consultaties uit te breiden.
Ten eerste verzamelen we alle sessies die de CCID van de betreffende primaire sessie delen.
Vervolgens maken we onze deelnemerslijst op uit al die sessies. Daarna berekenen we de
tijdbereiken als de sessieStartDate van de vroegste sessie tot het einde van de laatste sessie. ten slotte kunnen we de getSessions query uitvoeren.
Zoals eerder kunnen we eindigen met opname van te veel opnames, zodat we een stap na verwerking kunnen uitvoeren om die niet verwante sessies van de lijst te verwijderen.
3. Hoe associeert u oproepen in Cisco MediaSense met hun uiterlijk in andere oplossingscomponenten?
3.1. Concordantietabel van identificatiemiddelen
Deze twee tabellen—één voor Unified Communications Manager en één voor Unified Border Element-oproepen. Elke kolom vertegenwoordigt een oplossing component of protocol, waarbij de eerste kolom Cisco MediaSense representeert. Elke rij vertegenwoordigt een bepaald type
identificator.
Om de tabellen te lezen, begin met een cel die het gegevenspost weergeeft dat u kent, en dan horizontaal naar de kolom kijkt, vertegenwoordigt de oplossingscomponent waarin u de aanroep wilt vinden. De ingang in die cel geeft aan welke naam het exact dezelfde gegevenspost bekend is in de doelcomponent. Als de doelcomponent een lege cel in die rij heeft, dan is dat gegevenspost
niet bekend bij die component. In plaats daarvan kunt u naar een kolom zoeken waar u verticaal kan kruisen. rij waar die cel niet leeg is in de kolom van de doelcomponent.
Bijvoorbeeld, met een Unified Communications Manager vraag, veronderstel dat u de GED-188 CallReferenceID kent en dat u de vraag in Cisco MediaSense wilt vinden. Links van de kolom GED-188 ziet u dat er geen waarde is in de kolom MediaSense, zodat u niet direct naar de kolom kunt toewijzen.
Er is echter een kolom waar je de rijen van een strook kan bekijken: Unified Communications Manager CDR. Een client kan het juiste Unified Communications Manager CDR-record selecteren door te zoeken naar een record waarin de InkomendProtocolCallRef overeenkomt met GED-188 CallReferenceID. Dat record bevat een waarde genaamd destBeenCallIdentifier, die hetzelfde is als MediaSense NearEndCi, en die daarom kan worden gebruikt om de corresponderende record in Cisco MediaSense te vinden.
De gegevens van Unified Communications Manager CDR. worden niet geschreven tot enige tijd na het eind van de oproep, echter, zodat deze methode alleen historisch kan worden gebruikt.
Er is ook een ander pad. Kijk naar beneden vanaf de GED-188 CallReferenceID. Het blijkt dat u ook het AlertingDevices en AnsweringDevices kunt gebruiken om het apparaatRef in MediaSense aan te passen. Deze methode werkt ook in real time.
Opmerkingen:
In opnames van Unified Communications Manager de vraag, ontvangt Cisco MediaSense in feite een Cisco-″buis van UCM, maar het is niet het zelfde die door de andere
oplossingsapparaten wordt gevangen. MediaSense slaat deze waarde dus niet eens op.
1.
Voor agent-to-agent aanroepen is TCD.InstrumentPortNumber de uitbreiding van de bestemmingsagent. De uitbreiding van de oproepende instantie kan worden gevonden in TCD.ANI.
2.
CCID is de Cisco-oundpositie in decimale vorm, die 4 hyphen-gescheiden sets van 10- cijferige decimale getallen is. Deze kunnen worden geconverteerd naar het hex-formulier 3.
waarbij elk 10-cijferig decimaal nummer wordt geconverteerd naar een 8-cijferig hex- nummer, en de koppeltekens worden verwijderd. Waar Cisco-oundbuis in UCCE wordt gebruikt, is het in zijn hexuitmakende vorm.
4. Hoe bepaalt u welk spoor de oproepende partij heeft en welk spoor de opgeroepen partij heeft?
4.1. Voor door CUBE opgeroepen oproepen
Voor CUBE-oproepen geeft Track 0 altijd kaarten aan de Anchor-beenstroom. Het Anchor-been is het dial-peer welk media-opnameprofiel is geconfigureerd. De tweede sporen kaarten naar niet- ankerbeen.
Als het opnameprofiel van media op het inkomende dialoogvenster is ingeschakeld, wordt het ankerbeen de in-been. Met andere woorden: de oproepende partij staat in Track 0 en de opgevraagde partij is in Track 1 vermeld.
Als het media opnameprofiel is ingeschakeld in het uitgaande dialoogvenster, dan wordt het ankerbeen het uiteinde. In dat geval komt de oproepende partij voor in Track 1 en verschijnt de opgevraagde partij in Track 0.
4.2. Voor oproepen die worden gedaan door Unified CM-telefoons
Voor Unified CM forking kunt u in eenvoudige callscenario's de xRefCi-velden in de metagegevens gebruiken om te bepalen welke partij is in welk mediagraject. De numeriek kleinere refCi verwijst doorgaans naar het nummer van de oproepende partij. Het nummer van de partij is numeriek groter (gewoonlijk één, maar wellicht meer onder een redelijk geladen systeem). Deze xRefCi- waarden zullen echter uiteindelijk op nul uitkomen. Dus als je vindt dat de ene waarde een hoog getal is en de andere een klein getal, dan neem je aan dat hun posities omgekeerd zijn.
In ingewikkelder scenario's, werkt dit algoritme niet altijd. Als er een beroep wordt gedaan op aanvullende diensten, zoals overmakingen en conferenties, en de UC Manager-cluster uit meer dan één knooppunt bestaat, dan worden de xRefCi-waarden niet noodzakelijk sequentieel gegenereerd en kunt u niet veronderstellen dat hun order überhaupt enige betekenis heeft. Een directe manier om te bepalen of de bestelsequentie van een bepaald paar xRefCi-waarden kan worden vertrouwd is de eerste byte van de xRefCi-waarden te bekijken. Deze byte
vertegenwoordigt de UC Manager Node-ID waarop die specifieke identificator is gemaakt. Als de eerste bytes van de twee xRefCi-waarden hetzelfde zijn, is het bestellen correct. Als ze anders zijn, is het mogelijk dat de bestelling niet juist is.
Voor deze gevallen is de enige manier om de aanroeprichting in real time te bepalen het verkrijgen van de informatie van een andere bron, zoals de JTAPI gebeurtenis feed. Zodra de oproep is beëindigd en een paar minuten zijn verstreken, kunt u altijd de gespreksrichting bepalen en de CDR-gegevens van UC Manager voor de oproep controleren. In het bijzonder,
vertegenwoordigt hetBeenCallIdentifier veld in het CDR record altijd de beller.
5. Wat zijn de mogelijke oorzaken van een sessiestatus van
CLOSED_FOUT?
Mogelijke oorzaken voor een sessiestatus van CLOSED_FOUT zijn:
1. De Call Control Server heeft een foutreactie van de Media (opname) server ontvangen voor de open of gesloten aanvraag.
2. Call Control Server heeft een SIP-signaleringsfout gedetecteerd, bijvoorbeeld een ontbrekende ACK.
3. De sessie is gesloten, maar ALLE sporen hebben een nulgrootte.
Wanneer een sessie in actieve toestand is, is het normaal dat er geen tijdsduur in de metagegevens is, omdat de duur niet bekend is tot de sessie gesloten is.
Voor een sessie die in CLOSED_FOUT staat, als de sessie- of spoorduurvelden niet aanwezig zijn in de gebeurtenis of de getSessions gegevens, dan zijn er geen media voor dit spoor beschikbaar.
6. Wat is het verschil tussen afgebroken en afgeschreven sessies?
Bekijk deze twee vragen:
6.1. Met GetAllPrunedSessions Query
Deze query geeft een set sessies terug, waarvan alle sessiestatus is VERWIJDERD:
https://Mediaserver IP
address:8443/ora/queryService/query/getAllPrunedSessions?minSessionStartDate=1301788800000&maxSe ssionStartDate=1312329599000
6.2. Met GetSessions Query
Deze query geeft geen sessies terug:
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. Waarom het gedragsverschil in geprunde en verwijderde sessies?
Het gedragsverschil is per ontwerp. Raadpleeg deze secties in de MediaSense documentatie:
De API-parameterbeschrijving: Beschrijving van GetAllPrunedSessions API:
●
Gebruik deze API voor het doorzoeken van alle gesnoerde opnames...Het begrip Pruned verwijst naar opnames die door het Cisco MediaSense-systeem worden verwijderd. Als u expliciet een opname hebt verwijderd met behulp van de Delete Sessions API, worden deze verwijderde opnames niet als gepruned opnames beschouwd.
MediaSense SRND onder het gedeelte Proactief opslagbeheer:
●
Wanneer sessies worden gepruned, blijven de metagegevens die bij deze sessies horen in de database, zelfs nadat deze sessies als 'gesnoerd' zijn gemarkeerd. Deze metagegevens nemen geen grote hoeveelheid opslagruimte in vergelijking tot de opnames zelf, maar er is wel enige ruimte voor nodig en deze moeten periodiek worden verwijderd. Om bij deze activiteit te helpen, kunnen klanten periodiek een API-verzoek voor geprononeerde sessies indienen, of kunnen klanten ervoor kiezen sessiegebonden gebeurtenissen te ontvangen en expliciet de
gebeurtenissen te verwijderen die klanten niet langer nodig hebben.
Ter verduidelijking, de twee vragen zijn volledig anders. Sterker nog, de tweede query (die alle sessies doorzoekt waarvan de status is VERWIJDERD) geeft altijd een lege set terug. Normale dagelijkse vragen filteren sessies met VERWIJDERDE staten, zelfs als dat is waarom wordt gevraagd. De enige uitzondering is GetAllPrunedSessions. Deze uitzondering is bedoeld om de toepassing te helpen bij het vinden van geprinte sessies, zodat de sollicitatie kan vragen om het schrappen van deze sessies.
Zodra u de API van verwijderen sessies gebruikt in de lijst met gesnoerde sessies die u van GetAllPrunedSessions krijgt, verschijnen deze sessies niet langer in het resultaat van GetAllPrunedSessions. Zulke sessies worden direct uit de metagegevens verwijderd.
Een andere manier om dit te zien is dat geprinte sessies niet hetzelfde zijn als verwijderde sessies:
Gevirtualiseerde sessies zijn gemarkeerd voor verwijdering door een algoritme in het MediaSense-systeem. Niemand was betrokken bij het besluit om deze sessies te snoeien.
Dus zelfs al worden deze sessies verplaatst naar de DELETED status, deze sessies worden niet daadwerkelijk verwijderd van de metadata. Er is een interventie van de mens (of van toepassing) nodig. Omdat deze sessies in de DELETED status zijn, zijn deze sessies niet zichtbaar voor de meeste vragen. Deze sessies zijn echter zichtbaar voor de
getAllPrunedSessions query API. Ook, als om het even welke mp4 bestanden voor deze sessies werden gegenereerd, blijven deze mp4 bestanden op de schijf aanwezig en blijven beschikbaar om te downloaden tot de geprinte sessies daadwerkelijk zijn VERWIJDERD.
1.
Verwijderde sessies worden gemarkeerd door de Delete Sessions API expliciet te bellen.
2.
Deze markering kan worden aangebracht op sessies die al gepruniseerd zijn of op sessies die nog niet verwijderd zijn. Zodra een sessie is verwijderd door de Delete Sessions API, is deze sessie niet langer zichtbaar voor een query. Dit omvat de getAllPrunedSessions API.
Deze verwijderde sessies worden direct uit de metagegevens verwijderd, zodat de schijfruimte kan worden hersteld.
7. Hoe moet u een TDM-gateway instellen voor het maken van media?
Als je een PSTN-poort hebt waardoor hij stromen aanroept, wil je die oproepen opnemen. Deze oproepen zijn TDM-to-SIP-oproepen. Media forking is echter alleen beschikbaar op SIP-naar-SIP oproepen.
Deze gesprekken kunnen worden geregistreerd. Deze gesprekken kunnen een tweede keer door de router worden gericht. In dit witboek vindt u de configuratierichtlijnen en andere informatie.
8. Hoe kan je de echte doeltelefoon opnemen wanneer je een stuntgroep gebruikt?
Wanneer u media forking van CUBE gebruikt, bevatten de MediaSense metadata normaal gesproken de extensie van de opgeroepen partij. Als het nummer dat wordt opgeroepen echter een pilootnummer is van de Communications Manager-jachtgroep, dan bevat de metagegevens standaard alleen dat proefnummer. Het bevat niet de uitbreiding van de telefoon die daadwerkelijk de vraag beantwoordde.
Er is een instelling voor Communications Manager die dit kan wijzigen. Ga naar de pagina Configuration Hunt/Pilot naar de sectie Connected Party Transformations. Het lid van de instellingsweergavegroep DN als verbonden partij moet worden ingeschakeld.
Deze mogelijkheid is beschikbaar in Communications Manager 9.0(1) en later.
9. Waarom wordt Unified Communications Manager- netwerkgebaseerde opname aanbevolen als een voorkeursmechanisme?
Met Unified Communications Manager Network-Based Opname (NBR) kunt u een gateway gebruiken om oproepen op te nemen. NBR staat de Unified Communications Manager toe om opnameoproepen te routeren, ongeacht apparaat, locatie of geografie. Met NBR kunnen de vraag opnamemedia van of de IP telefoon of van een gateway worden gebracht die aan de Unified Communications Manager via een SIP stam wordt aangesloten. Unified Communications Manager selecteert dynamisch de juiste mediabron op basis van de aanroep-stroom en de
gespreksdeelnemers.
NBR biedt een automatische back-up van Built-in-Bridge (BiB) aan wanneer de Geïntegreerde services routers (ISR) niet beschikbaar zijn omdat er geen afzonderlijke opnameconfiguratie vereist is. Dit is nuttig in gevallen waar de klanten agent-agent vraag in het controlebeleid willen
opnemen aangezien het Unified Border Element geen vraag kan raadplegen, zodat BiB afzonderlijk moet worden toegelaten.
Zowel NBR- als BiB-oproepen kunnen gecorreleerd worden met xRefci, dat beschikbaar is bij Unified Communications Manager JTAPI. CISCO-ô is niet nodig, wat betekent dat er geen CTI- server of CTIOS-verbindingen vereist zijn. Aangezien er één enkele correlatie - identificator is, is de correlatie tussen componenten sterker en kan deze op uniforme wijze plaatsvinden,
onafhankelijk van de callflow.
Met NBR, direct-dialed zowel als dialer-geïnitieerde uitgaande vraag kan gecorreleerd worden met hun verschijning in andere oplossingscomponenten.
Met NBR wordt de TDM gateway-opname automatisch gebruikt zonder verdeling van de capaciteit van de router. Op dit moment wordt de TDM-gateway-opname niet ondersteund door MediaSense 10.5.
10. Waarom duurt het langer om een knooppunt te upgraden naar MediaSense 10.5?
Een knooppunt kan meerdere uren duren voor het upgraden is voltooid, afhankelijk van het aantal en de grootte van de opnames die het bevat. Voor MediaSense 10.5, wanneer u een knooppunt verbetert met zeer grote gegevenssets, duurt dit ongeveer 90 extra minuten per 1 miljoen
opnames.
11. Wat is de invloed van de wijzigingen in de Russische tijdzone op de toepassing MediaSense Search and Play?
De gebruikers van de toepassing MediaSense Search and Play worden beïnvloed als ze zich in een van de getroffen tijdzones bevinden of als ze een getroffen tijdzone in de zoekcriteria selecteren. De producten van derden die een interface met MediaSense hebben, worden op dezelfde manier beïnvloed tot ze hun respectievelijke tabellen voor de tijdzone bijwerken.
De tijdelijke oplossing is een tijdzone te selecteren die overeenkomt met de juiste offset van GMT, ook al is de stad niet langer correct.
12. Welke talen worden ondersteund door MediaSense?
Hier worden de talen ondersteund door MediaSense:
Arabisch
●
Deens
●
Nederlands
●
Engels (Verenigde Staten)
●
Fins
●
Frans
●
Duits
●
Italiaans
●
Japans
●
Koreaans
●
Noors
●
polijsten
●
Portugees (Braziliaans)
●
Russisch
●
Vereenvoudigd Chinees
●
Spaans
●
Zweeds
●
Traditioneel Chinees
●
Turks
●
13. Hoe de prestaties van het MediaSense-systeem te controleren?
Om de prestaties van het MediaSense systeem te controleren, analyseert u de waarden van deze belangrijke prestatie-indicatoren (KPI's) met het RTMT-gereedschap of Cisco Prime Collaboration Assurance-gereedschap.
Voor meer informatie over RTMT-gereedschap of Cisco Prime Collaboration Assurance- gereedschap kunt u de Unified RTMT-beheer en de Cisco Prime Collaboration Assurance Administration-secties van Cisco MediaSense gebruikersgids raadplegen.
KPI's en hun drempelwaarden Key Performance
Indicator RTMT-tellers Aanbevolen drempelwaarden
Succespercentage oproepen
MediaSense Call Control Service > Aantal opnamesessies zonder fouten
MediaSense Call Control Service > Aantal opnamesessies met fouten
99.99%
Call Success rate = aantal opnamesessies zonder fouten / (aantal opnamesessies zonder fouten + aantal opnamesessies met fouten) * 100
Tijd voor API-respons Cisco MediaSense API-service > Gemiddelde
antwoordtijd 60 seconden
Gemiddelde setup- vertraging opnemen
Cisco MediaSense Call Control Service >
Gemiddelde setup-vertraging 3 seconden CPU-gemiddelde
benutting Processor > %CPU tijd 90%
Geheugengemiddelde Geheugen > %em gebruikt 70%
RTP-/UDP-pakketdrop
Netwerkinterface > RX gedaald > eth0 Netwerkinterface > RX-fouten > eth0
0 0
14. Hoe moet je een browser configureren om een in-browser- speler in MediaSense te laten draaien?
Op basis van de browser, voer deze stappen uit om in-browser speler te starten:
Internet Explorer 9 Internet Explorer 11 Mozilla Firefox
1. Klik in MediaSense Search and Voorvereisten: Zorg er bij installatie 1. Voeg het zelf-ondertekende
Play op het Play pictogram van een opnamesessie.
van MediaSense 11.0 voor dat er mediaSense knooppunten aan het cluster worden toegevoegd met de respectievelijke FQDN-naam (Full Qualified Domain Name).
In het geval van een upgrade naar MediaSense 11.0 moet u ervoor zorgen dat de MediaSense- knooppunten die eerder met de
hostname zijn toegevoegd, nu door de betreffende FQDN worden
weergegeven. Controleer de lijst MediaSense Server in MediaSense Server Configuration venster (Cisco MediaSense Management > System >
MediaSense Server Configuration).
certificaat van een MediaSense- knooppunt toe voor poort 8446 van mp4url in de vertrouwde instantie van Mozilla Firefox.
2. Klik op Ja om het certificaat te vertrouwen.
Opmerking: Controleer dat het aangeboden zelf-ondertekende certificaat afkomstig is van het beoogde MediaSense-knooppunt door de FQDN te valideren in de technische details van het
certificaat.
Volg de volgende stappen:
1. Stel de ingestelde
hostnameformediaurl CLI in als "waar"
om MediaSense voor te bereiden op mp4url en de rest van de media die alleen FQDN gebruiken.
admin:set useHostNameForMediaURL admin:set useHostNameForMediaURL true
2. Start de configuratieservice om de eigenschap te activeren.
admin:utils service restart Cisco MediaSense Configuration Service
Opmerking: Als de service niet goed is gestart, voert u dezelfde opdracht opnieuw uit.
3. Nadat de Configuration Service is herstart, neemt u contact op met MediaSense Search en Play.
Beperking: Indien de MediaSense- knooppunten eerder werden
toegevoegd met behulp van IP’s, worden de knooppunten nog slechts na een upgrade naar MediaSense 11.0 weergegeven door de IP’s. In- browser-speler werkt niet op Internet Explorer 11, ongeacht de waarde van de hostnameformediaurl CLI-
opdracht. In dit geval, wordt aangeraden om de opdracht hostnameformediaurl CLI niet als
"waar" in te stellen.
2. Als u het zelf-ondertekende certificaat wilt toevoegen, klikt u op het pictogram downloaden van een opnamesessie en vervolgens selecteert u MP4.
Dit pop-upvenster is onbetrouwbaar.
3. Klik op het pictogram Afspelen dat overeenkomt met de
geselecteerde opname.
Voer de volgende stappen uit om het MediaSense zelfgetekende certificaat toe te voegen aan de vertrouwde
2. Als u het zelf-ondertekende certificaat wilt toevoegen, klikt u op het pictogram downloaden van een
De in-browser speler speelt de geselecteerde opnamesessie.
instantie van Windows.
1. Open MediaSense op zoek en afspelen.
Er verschijnt een pop-upvenster met veiligheidscertificaat.
2. Klik op Doorgaan.
MediaSense Search and Play venster verschijnt.
3. Klik in de adresbalk op het pictogram certificaatfout.
4. Klik op vaarbevoegdheidsbewijzen bekijken.
Het pop-upvenster voor certificaten verschijnt.
5. Klik op Installeer het certificaat.
De wizard Certificaat importeren verschijnt.
6. Klik op Volgende.
7. Selecteer in het venster
certificaatopslag het venster op alle certificaten in de volgende radioknop van de winkel en klik op Bladeren.
Het dialoogvenster certificaatopslaan verschijnt.
8. Controleer het aanvinkvakje
Fysieke opslag tonen en selecteer de map Trusted Root Certification
Horities.
9. Klik op OK en Volgende.
10. Klik op Voltooien om het certificaat te importeren.
Een pop-upvenster met
veiligheidswaarschuwing verschijnt om de installatie van het certificaat te bevestigen.
11. Klik op Ja.
Het volgende bericht verschijnt.
The import was successful.
12. Klik op OK.
13. Klik op OK in het pop-upvenster certificaataanvraag.
14. Sluit en open de browser.
15. Open MediaSense zoektocht en afspelen.
Het veiligheidscertificaat blijft bestaan.
16. Ga naar Gereedschappen >
Internet-opties > Geavanceerd, haal de waarschuwing uit over
selectieknop voor onjuist
certificaatadres onder Security.
17. Klik op Toepassen en OK.
18. Start de browser opnieuw en open
opnamesessie en vervolgens selecteert u MP4.
Dit pop-upvenster is
onbetrouwbaar. Opmerking:
Controleer dat het aangeboden zelf-ondertekende certificaat afkomstig is van het beoogde MediaSense-knooppunt door de FQDN te valideren in de
technische details van het certificaat.
MediaSense Search and Play.
Zorg ervoor dat de MediaSense server toegankelijk is via FQDN op de browser. Als niet, navigeer naar C:\Windows\System32\drivers\etc, open het gastheren dossier in
Kladblok en voeg het IP adres van de server MediaSense en zijn FQDN bij de onderkant van het bestand toe. In- browser speler begint te werken op Internet Explorer 11.
Opmerking: Als er een opname aanwezig is op een ander MediaSense knooppunt van het cluster, wordt u gevraagd het certificaat van dat MediaSense- knooppunt in de vertrouwde instantie toe te voegen.
3. Klik op de link Risks.
4. Klik op Add Exception.
Het pop-upvenster Add Security Exception verschijnt.
5. Klik op Bevestig de beveiligingsuitzondering.
Het zelfgetekende certificaat van het specifieke MS-knooppunt van de 8446-poort wordt toegevoegd aan de vertrouwde autoriteit van de browser.
