De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft de Voice Extensible Markup Language (VXML) / Customer Voice Portal (CVP) Hypertext Transfer Protocol (HTTP) cache voor mediabestanden.
Cisco raadt kennis van de volgende onderwerpen aan:
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
In HTTP Client Cache zijn twee typen cache betrokken bij het opslaan van mediabestanden:
De server cache instelling overschrijft de HTTP client instellingen, deze parameters worden verzonden van de server via http bericht headers of via vxml applicatie scripts.
Stap 1. Wanneer audioresultaten op een HTTP-mediaserver worden opgeslagen, zijn er geschikte toegangs-snelheidscamethoden nodig om zowel de prestaties van de gateway als het verbruik van netwerkbandbreedte te optimaliseren. De prestaties van de gateway dalen met ongeveer 35-40% als het caching volledig wordt uitgeschakeld.
Om caching op de gateway te configureren stelt u deze in op de gateway:
..ivr prompt memory 15000 ..http client cache memory file 500 ..http client cache memory pool 15000
Opmerking: Het http client cache geheugen bestand vertegenwoordigt het grootste size prompt bestand (in Kbytes) dat kan worden gecached. In het algemeen moeten klantaanwijzingen van meer dan 500.000 (ongeveer een minuut lang) worden opgesplitst in kleinere, meer beheersbare stukken om het laden en caching te vergemakkelijken. Bijvoorbeeld, de rijmuziek zou een reptitief lus van een 30 seconden kunnen zijn. Merk op dat omdat de vroegen worden gestreamed, de herinnering niet cache geeft tenzij de hele prompt wordt afgespeeld. Daarom wordt aangeraden om snel een beheersbare grootte te maken.
Stap 2. synchroniseer de datetijd tussen de gateway en de HTTP media server.
Opmerking: Synchronisatie hoeft niet exact te zijn, maar ten minste binnen een minuut of twee. Times die niet gesynchroniseerd zijn kan aanleiding geven tot aanwijzingen om nooit te verfrissen of ze zullen verfrissen met elke oproep, die allebei ongewenst gedrag zijn.
Stap 3. Stel de verloopdatum van de inhoud op de mediaserver in (bijvoorbeeld 15 minuten).
Opmerking: In IS, wordt dit uitgevoerd onder het tabblad HTTP-header. De poort-melding wordt na deze periode opnieuw verstuurd. De gekozen periode moet weerspiegelen hoe vaak u aanwijzingen opnieuw opneemt en hoe lang u bereid bent te wachten om de nieuwe snelle lading na verandering te hebben.
Stap 4. Navigeer naar programma's > Administratieve hulpmiddelen > ISIS Manager.
Stap 5. Navigeer naar het .wav-bestand dat u wilt wijzigen.
Stap 6. Klik met de rechtermuisknop > Eigenschappen > HTTP-koppen
Stap 7. Laat contentverloopdatums toe.
Om te bepalen of u gateway caching correct hebt ingesteld, volgt u dit:
Het is logbestand op de media server records telkens wanneer een client om een melding vraagt. Als caching correct is ingesteld, verschijnen deze verzoeken bij benadering elke X minuten (X is wat is gedefinieerd als het vernieuwingsinterval in Stap 3.) voor elke bepaalde melding. Het logbestand is te vinden op: C:\WINNT\system32\LogFiles\W3SVC1\ex*
Of,
Laat http client cache op de poort zien. De kolom Fresh Time moet gelijk zijn aan de verfrissingstijd die op de HTTP-mediaserver is ingesteld.
Bijvoorbeeld, als de verfrissingsperiode werd ingesteld op 15 minuten, moet dit 900 seconden zijn. De Age-kolom toont hoeveel seconden zijn verstreken sinds de melding voor het laatst werd hervat. In het algemeen is dit aantal minder dan de nieuwe tijd. Maar als geen telefoontje ooit de prompt heeft benaderd, kan dit nummer groter zijn dan de nieuwe tijd. Prompts worden alleen ververst als ze worden geactiveerd na een oproep en de snelle Fresh Time is verlopen. Als de Fresh Time een zeer hoge waarde is, is de enige manier om de prompt te verwijderen uit cache (anders dan de verborgen opdrachten) het opnieuw laden van de poort.
Het is veel gemakkelijker om de header als echte HTTP-header toe te voegen via IS.
Dit kan worden gedaan via IS 6 of 7.
Er zijn verschillende variabelen die de FreshTime van een bestand kunnen beïnvloeden, zoals: http berichtkoppen van de server en cache verfrist waarde die is ingesteld via de CLI, enz.
Hoe weet je welke waarde een bestand gebruikt voor zijn FreshTime? FreshTime van een bestand wordt in deze voorrang bepaald:
1. Wanneer een bestand van de http server wordt gedownload, indien een van de http bericht headers dit bevat:
Cache-Control: max-age = <value in seconds>
Vervolgens wordt de <waarde in seconden> gebruikt als FreshTime voor dit bestand.
2. Indien (1) niet aanwezig is, maar deze twee kopregels zijn opgenomen in het http bericht:
Expires: <expiration date time> Date: <Current date time>
Vervolgens wordt het verschil <verloopdatumtijd> - <Huidige datumtijd> gebruikt als de FreshTime voor dit bestand.
3. De HTTP/1.1-specificatie, RFC 2616 (HTTP), adviseert dat één van de http-berichtkopregels zoals beschreven in (1) of (2) aanwezig is. Als de server niet zowel (1) als (2) heeft verzonden in zijn http reactie, kunt u 10% van het verschil tussen Date en Last-Modified uit de berichtkopregels opnemen:
Last-Modified: <last-modified date time> Date: <Current date time>
Dus wordt FreshTime voor dit bestand berekend als:
FreshTime = 10% x ((Last-Modified) - (Date))
4. Ten slotte, dit is wanneer het cache verfrissen CLI in spel komt. De CLI staat de gebruiker toe om een heuristische FreshTime-waarde aan de bestanden toe te wijzen als een voorlopige waarde voor het geval dat geen van de bovenstaande (1)-(3) berichtkopregels aanwezig zijn.
c5400-02(config)#http client cache refresh ?
<1-864000> Time value in seconds
De standaard vernieuwingswaarde is 86400 seconden (24 uur).
Opmerking: De geconfigureerde http client cache verfrist geen effect op bestanden wanneer een van de berichtenkoppen (1) - (3) aanwezig is.
Opmerking: Deze CLI is, indien van kracht, niet retroactief. Dat wil zeggen, de nieuw geconfigureerd vernieuwingswaarde is alleen van toepassing op nieuwe inkomende bestanden. Het heeft geen effect op de inzendingen die al in de cache zitten.
Opmerking: De router verfrist nooit om het even welke stabiele bestanden automatisch op zijn.
Stale bestanden worden alleen opgefrist als dat nodig is. Waarom zou de router zijn waardevolle CPU-cycli uitgeven bij het updaten van de bestanden in het cache zonder te weten of die bestanden zullen worden gebruikt, terwijl de CPU voor andere dringende services nodig is?
Dit betekent dat een gestale cached entry lang in de cache kan blijven tot het verwijderd is om ruimte te maken voor een nieuwe kopie van hetzelfde bestand of voor een ander bestand dat gewoon zijn geheugenruimte in de cache nodig heeft. Soms kan een gecached vaste ingang nog bruikbaar zijn, als zijn leeftijd niet de door de toepassing opgegeven MaxStale waarde heeft overschreden.
In een notendop kan, ongeacht of een ingecached entry oud is of nog steeds bruikbaar, met deze eenvoudige vergelijkingen worden berekend:
- file is fresh if FreshTime > Age - file is stale but still usable if (FreshTime + MaxStale) > Age - file is stale and not usable if (FreshTime + MaxStale) <= Age
Duidt erop dat de cliënt bereid is een antwoord te aanvaarden dat zijn verlooptijd heeft overschreden. Als max-stale een waarde wordt toegewezen, dan is de klant bereid een reactie te aanvaarden die zijn verlooptijd met niet meer dan het opgegeven aantal seconden heeft overschreden. Als geen waarde wordt toegewezen aan max-stale, dan is de klant bereid een stabiele respons van elke leeftijd te accepteren.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Zoals eerder vermeld, wordt een gelakte inslag van de vaste grond door de eigenaar naar behoefte verwijderd, wanneer:
de ingekaatste ingang wordt gestaal; en
De ref-telling is nul (0), d.w.z. niemand gebruikt deze gecached vermelding; en
De geheugenruimte is nodig om ruimte te maken voor andere items
Dit betekent dat de http client en IVR Media Player hun gecached items op deze manier moeten beheren en controleren in respectievelijk niet-streaming en streaming modi. Wat als de http client een paar vaste inzendingen moet opruimen om ruimte terug te winnen in de cache geheugen pool, maar het is niet de eigenaar van die bestanden? Dit wordt de verantwoordelijkheid van de http client cache achtergrond ager.
De http client cache achtergrondfunctie wordt elke 5 minuten wakker. Als het totale geheugen dat gebruikt wordt voor de gecached items meer dan 70% drempel van de geconfigureerde cache geheugen podale bedraagt, loopt de ager door elke gecachede ingang. Als de ingang nog vers is, laat hij het met rust. Indien de vermelding stale is en er geen verwijzing naar heeft, d.w.z. ref count = 0, schrapt de http client de vermelding op zichzelf omdat deze de rechtmatige eigenaar van die vermelding is. Als de vaste ingang een referentieteller 1 op het heeft en geen ouder of kind aan het verbonden heeft, wat betekent dat het bestand niet midden in het vernieuwen van de download staat, roept de http client terug om de Media Player op de hoogte te stellen om deze stap vrij te geven.
Soms, kan het wenselijk of noodzakelijk zijn om een audiobestand in de router handmatig te downloaden. Tegen nu wordt ons al verteld dat de router niet automatisch naar de http server gaat om de ingesloten inzendingen op te frissen. Die inzendingen worden alleen ververst als ze nodig zijn. Dit probleem kan worden opgelost door middel van een handmatige download.
Een ander scenario dat een handmatige download nuttig kan zijn, is om een grote audio-prompt in niet-streaming modus voor te leggen. Dit kan worden gedaan voordat de eerste oproep wordt ontvangen zodat de beller geen vertraging van snelle lading ervaart.
Wilt u een bepaald audiobestand handmatig downloaden, dan voert u deze CLI-opdracht uit:
vracht <url>
Het <url>is waar het audiobestand zich op de server bevindt. Natuurlijk wordt verwacht dat de http client cache correct wordt geconfigureerd om dit bestand op te slaan in de cache.
Opmerking: Als de <url> een actieve melding is, d.w.z. momenteel in spel is, wordt deze CLI niet uitgevoerd.
Zorg er ook voor dat de datetijd tussen de gateway en de HTTP media server gesynchroniseerd is. Dit is een must.
Waarschuwing: Gebruik geen duidelijke http client cache in de VXML GW. Als deze opdracht op zeer geladen/actieve VXML GW wordt opgeroepen, is het bekend dat deze problemen, geheugencorruptie en crashes veroorzaakt. Het gebruik van heldere ip http client cache alle wordt niet aanbevolen. Wat het doet is dat het alle inzendingen uit het cache opfrist, en wat er gebeurt is dat het knooppunten maakt en verwijdert uit de cache gekoppelde lijst, wat enkele problemen veroorzaakt. De opdracht wordt momenteel verwijderd van Cisco IOS®. De aanbevolen opdracht is http client cache stale ingesteld, wat deze opdracht doet is dat het net veranderd deel van de cache opfrist.