Konfigurere telefonen for en resynkronisering av profilen

Resynkronisere telefonprofilen over TFTP

Telefonen støtter flere nettverksprotokoller for henting av konfigurasjonsprofiler. Den mest grunnleggende profiloverføringsprotokollen er TFTP (RFC1350). TFTP brukes i stor grad til klargjøring av nettverksenheter i private lokalnett. Selv om den ikke anbefales til klargjøring av eksterne endepunkter over Internett, kan TFTP være praktisk til distribusjon i små organisasjoner, til intern forhåndsklargjøring og til utvikling og testing. I prosedyren nedenfor endres en profil etter nedlasting av en fil fra en TFTP-server.

1

I et LAN-miljø kobler du datamaskinen og telefonen til en hub, bryter eller liten ruter.

2

På datamaskinen installerer og aktiverer du en TFTP-server.

3

Bruk tekstredigering for å opprette en konfigurasjonsprofil.

For å bekrefte om profilen er klargjort for telefonen senere, kan du angi noen av verdiene som merker. Du kan for eksempel angi verdien for GPP_A til 12345678 som vist i følgende eksempel:
<flat-profile>
  <GPP_A> 12345678
  </GPP_A>
</flat-profile>
4

Lagre XLM-konfigurasjonsfilen i rotkatalogen for TFTP-serveren.

Du kan bekrefte at TFTP-serveren er riktig konfigurert: Be om konfigurasjonsprofil-filen ved å bruke en TFTP-klient som ikke er telefonen. Bruk helst en TFTP-klient som kjører på en separat vert fra klareringsserveren.

5

I nettleseren på datamaskinen kan du åpne administasjonsnettsiden. Hvis for eksempel at IP-adressen for telefon er 192.168.1.100, åpner du følgende URL i nettleseren:

http://192.168.1.100/admin/advanced
6

Velg fanen Stemme > Klargjøring og inspiser verdiene i de generelle parametrene GPP_A til GPP_P. Disse skal være tomme.

7

Resynkroniser testtelefonen til konfigurasjonsprofilen du opprettet ved å åpne resynkroniser URL i en nettleser.

Eksempel:

Hvis IP-adressen til TFTP-serveren er 192.168.1.200, skal kommandoen være lik følgende eksempel:

http://192.168.1.100/admin/resync?tftp://192.168.1.200/basic.txt

Når telefonen mottar denne kommandoen, vil enheten på adressen 192.168.1.100 motta konfigurasjonsprofil-filen basic.txt fra TFTP-serveren fra IP-adressen 192.168.1.200. Telefonen analyserer deretter den nedlastede filen og oppdaterer parameteren GPP_A med verdien 12345678.

8

Bekreft at parameteren ble riktig oppdatert. Oppdater administratornettsiden og gå til Stemme > Klargjøring.

GPP_A-parameteren skal nå inneholde verdien 12345678.

Klargjøre en telefonspesifikk profil på en TFTP-server
1

Hent telefonens MAC-adresse fra produktetiketten. (MAC-adressen er nummeret, brukte numre og heksadesimale små sifre, for eksempel 000e08aabbcc.

2

Endre navn på konfigurasjonsfilen til CP-xxxx macaddress.cfg (erstatter xxxx med modellnummeret og macaddress med MA- adressen til telefonen).

Eksempel:

CP-8875 000e08aabbcc.cfg

3

Flytt den nye filen til den virtuelle rotkatalogen for TFTP-serveren.

4

Åpne telefonens administrasjonsnettside.

5

Velg Stemme > Klargjøring.

6

Angi banen for profil-filen i feltet Profilregel.

Eksempel: TFTP-serverens IP-adresse er 192.168.1.200 og profilfilnavnet er 

<Profile_Rule>
tftp://192.168.1.200/CP-8875$MA.cfg
</Profile_Rule>
7

Klikk på Godta alle endringer. Dette utløser en umiddelbar omstart og resynkronisering.

Når den neste resynkroniseringen utføres, henter telefonen den nye filen ved å utvide $MA-makrouttrykket i MAC-adressen sin.

Resynkroniser telefonprofilen med HTTP GET
1

Installer en HTTP-server på den lokale datamaskinen eller en annen tilgjengelig vert.

En Apache-server med åpen kildekode kan lastes ned fra Internett.

2

Laste opp konfigurasjonsprofil-filen til den virtuelle rotkatalogen for den installerte serveren.

3

For å bekrefte riktig serverinstallasjon og tilgang til profil-filen, åpner du profilen med en nettleser.

4

Endre Profile_Rule for testtelefonen slik at den peker til HTTP-serveren i stedet for til TFTP-serveren, slik at profilen kan lastes ned regelmessig.

Hvis for eksempel HTTP-serveren er 192.168.1.300 og profilfilnavnet er basic.txt, må du angi følgende verdi:

<Profile_Rule>http://192.168.1.200/basic.txt</Profile_Rule>
5

Klikk på Godta alle endringer. Dette utløser en umiddelbar omstart og resynkronisering.

6

Se syslog-meldingene som telefonen sender. De regelmessige resynkroniseringene skal nå hente profilen fra HTTP-serveren.

7

I HTTP-serverloggen ser du hvordan informasjonen som identifiserer testtelefonen, vises i loggen til brukeragenter.

Denne informasjonen skal inneholde produsent, produktnavn, gjeldende fastvareversjon og serienummer.

Resynkroniser telefonprofilen automatisk

En enhet kan resynkronisere regelmessig med klargjøringsserveren for å sikre at eventuelle profilendringer foretatt på serveren spres til endepunktenheten (i stedet for å sende en eksplisitt resynkroniseringsforespørsel til endepunktet).

Du kan få telefonen til å resynkronisere regelmessig med en server ved å angi en konfigurasjonsprofil-URL ved hjelp av parameteren Profile_Rule og et resynkroniseringsintervall ved hjelp av parameteren Resync_Periodic.

1

Åpne telefonens administrasjonsnettside.

2

Velg Stemme > Klargjøring.

3

Angi parameteren Profile_Rule. Dette eksemplet forutsetter IP-adressen 192.168.1.200 for TFTP-serveren.

4

I feltet Resync Periodic (Resynkroniser regelmessig) angir du en liten testverdi, for eksempel 30 sekunder.

5

Klikk på Submit all Changes (Godta alle endringer).

Med de nye parameterinnstillingene resynkroniserer telefonen to ganger i minuttet med konfigurasjonsfilen som URL-adressen angir.

6

Observer de resulterende meldingene i systemloggsporingen.

7

Sjekk at feltet Resync On Reset (Resynkroniser ved tilbakestilling) er angitt til Yes (Ja).

<Resync_On_Reset>Ja</Resync_On_Reset>
8

Slå telefonen av og på for å tvinge den til å resynkronisere med klargjøringsserveren.

Hvis resynkronisering av en eller annen grunn mislykkes – for eksempel hvis serveren ikke svarer –, venter enheten (i antallet sekunder som er konfigurert i Resync Error Retry Delay (Resynkroniseringsfeil – forsinkelse før nytt forsøk)) før den forsøker å resynkronisere på nytt. Hvis Resync Error Retry Delay er null, prøver ikke telefonen å resynkronisere på nytt etter et mislykket resynkroniseringsforsøk.

9

(Valgfritt) Angi et lite tall som verdi for feltet Resync Error Retry Delay, for eksempel 30.

<Resync_Error_Retry_Delay>30</Resync_Error_Retry_Delay>
10

Deaktiver TFTP-serveren, og se resultatene i syslog-meldingen.

Parametre for resynkronisering av profil

Følgende tabell definerer funksjonen og bruken av parametere for resynkronisering av profil i området Konfigurasjonsprofil under fanen Stemme > Klargjøring på telefonens nettside. Den definerer også syntaks for strengen som er lagt til i telefonens konfigurasjonsfil (cfg.xml) med XML-kode for å konfigurere en parameter.

Tabell 1. Parametere for resynkronisering av profil

Parameter

Beskrivelse

Provision Enable

Tillat eller avvis handlinger for resynkronisering av konfigurasjonsprofil.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Provision_Enable ua="na">Ja</Provision_Enable>

  • På telefonens nettside angir du dette feltet som Ja for å tillate resynkroniseringshandlinger, eller Nei for å blokkere resynkroniseringshandlinger.

Standard: Ja

Resync On Reset

Angir om telefonen resynkroniserer konfigurasjoner med den klargjorte serveren etter oppstart og etter hvert oppgraderingsforsøk.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_On_Reset ua="na">Ja</Resync_On_Reset>

  • På telefonens nettside angir du dette feltet som Ja for å tillate resynkronisering ved oppstart eller tilbakestilling, eller Nei for å blokkere resynkronisering ved oppstart eller tilbakestilling.

Standard: Ja

Resync Random Delay

Hindrer en overbelastning for klargjøringsserver når et stort antall enheter starter opp samtidig og forsøker første konfigurasjon. Denne forsinkelsen er bare effektiv ved første konfigurasjonsforsøk, etter oppstart eller tilbakestilling av en enhet.

Denne parameteren er maksimalt tidsintervall enheten venter før den får kontakt med klargjøringsserveren. Faktisk forsinkelse er halvveis tilfeldig nummer mellom 0 og denne verdien.

Denne parameteren er i enheter på 20 sekunder.

Verdier i området mellom 0 og 65535 er gyldige.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_Random_Delay ua="na">2</Resync_Random_Delay>

  • På telefonens nettside angir du antallet enheter (20 sekunder) for telefonen å forsinke resynkronisering etter oppstart eller tilbakestilling.

Standard verdi er 2 (40 sekunder).

Resync At (TTmm)

Tid (TTmm) som telefonen resynkroniserer med klargjøringsserveren.

Verdien i dette feltet må være et firesifret tall mellom 0000 til 2400 som angir klokkeslettet i formatet TTmm. 0959 angir for eksempel 09:59.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_At__HHmm_ ua="na">0959</Resync_At__HHmm_>

  • På telefonens nettside angir du tid i HHMM-format for telefonen å starte resynkronisering.

Standard verdi er tom. Hvis verdien er ugyldig, ignoreres parameteren. Hvis parameteren angis med en gyldig verdi, ignoreres Resynkroniser regelmessig-parameteren.

Resync At Random Delay

Hindrer en overbelastning for klargjøringsserver når et stort antall enheter starter opp samtidig.

For å unngå at serveren oversvømmes med resynkroniseringsforespørsler fra flere telefoner, resynkroniserer telefonen i perioden mellom timer og minutter og timer og minutter pluss den tilfeldige forsinkelsen (hhmm, hhmm + random_delay). Hvis for eksempel den tilfeldige forsinkelsen = (Resync At Random Delay + 30)/60 minutter, konverteres den angitte verdien i sekunder til minutter og avrundes til neste minutt for å beregne det endelige random_delay-intervallet.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_At_Random_Delay ua="na">600</Resync_At_Random_Delay>

  • På telefonens nettside angir du tidsperiode i sekunder.

Verdier i området mellom 600 og 65535 er gyldige.

Hvis verdien er mindre enn 600 vil intervallet for tilfeldig forsinkelse være mellom 0 og 600.

Standard verdi er 600 sekunder (10 minutter).

Resync Periodic

Tidsintervallen mellom regelmessig resynkronisering med klargjøringsserveren. Den tilhørende resynkroniseringstidtakeren aktiveres bare etter den første vellykkede synkroniseringen med serveren.

Følgende formater er gyldige:

  • Et heltall

    Eksempel: Verdien 3000 betyr at den neste resynkroniseringen finner sted om 3000 sekunder.

  • Flere heltall

    Eksempel: Verdien 600,1200,300 betyr at den første resynkroniseringen finner sted om 600 sekunder, den andre resynkroniseringen finner sted 1200 sekunder etter den første, og den tredje resynkroniseringen finner sted 300 sekunder etter den andre.

  • En tidsperiode

    Eksempel: Verdien 2400+30 betyr at den neste resynkroniseringen finner sted mellom 2400 og 2430 sekunder etter en vellykket resynkronisering.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_Periodic ua="na">3600</Resync_Periodic>

  • På telefonens nettside angir du tidsperiode i sekunder.

Hvis du vil deaktivere regelmessig resynkronisering, angir du parameteren til null.

Standard verdi er 3600 sekunder.

Resync Error Retry Delay

Hvis en resynkroniseringsoperasjon mislykkes fordi telefonen ikke kunne motta en profil fra serveren eller at den nedlastede filen er korrupt, eller hvis det oppstår en intern feil, vil telefonen forsøke å resynkronisere igjen etter en tid angitt i sekunder.

Følgende formater er gyldige:

  • Et heltall

    Eksempel: Verdien 300 betyr at det neste forsøket på resynkronisering finner sted om 300 sekunder.

  • Flere heltall

    Eksempel: Verdien 600,1200,300 betyr at det første nye forsøket på resynkronisering finner sted 600 sekunder etter en mislykket resynkronisering, det andre forsøket finner sted 1200 sekunder etter at det første nye forsøket mislykkes, og det tredje forsøket finner sted 300 sekunder etter at det andre nye forsøket mislykkes.

  • En tidsperiode

    Eksempel: Verdien 2400+30 betyr at det neste nye forsøket finner sted mellom 2400 og 2430 sekunder etter en mislykket resynkronisering.

Hvis forsinkelsen angis til 0, prøver ikke enheten å resynkronisere på nytt etter et mislykket resynkroniseringsforsøk.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_Error_Retry_Delay ua="na">60,120,240,480,960,1920,3840,7680,15360,30720,61440,86400</Resync_Error_Retry_Delay>

  • På telefonens nettside angir du tidsperiode i sekunder.

Standard: 60,120,240,480,960,1920,3840,7680,15360,30720,61440,86400

Forced Resync Delay

Maksimumsintervallet (i sekunder) som telefonen venter før den utfører en resynkronisering.

Enheten resynkroniserer ikke mens noen av dens telefonlinjer er aktive. Siden en resynkronisering kan ta flere sekunder, er det ønskelig å vente til enheten har vært ledig en stund, før resynkroniseringen utføres. På denne måten kan en bruker foreta anrop etter hverandre uten avbrudd.

Enheten har en tidtaker begynner nedtellingen når alle linjene blir ledige. Denne parameteren er den første verdien til telleren. Resynkroniseringer utsettes til tidtakeren har telt ned til null.

Verdier i området mellom 0 og 65535 er gyldige.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Forced_Resync_Delay ua="na">14400</Forced_Resync_Delay>

  • På telefonens nettside angir du tidsperiode i sekunder.

Standard verdi er 14,400 sekunder.

Resync From SIP

Kontrollerer forespørsler for resynkroniseringsoperasjoner via en SIP NOTIFY-hendelse som er sendt fra tjenesteleverandørens proxy server til telefonen. Hvis den aktiveres kan proxy be om en resynkronisering ved å sende en SIP NOTIFY-melding som inneholder Hendelsen: resynkronisere topptekst til enheten.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_From_SIP ua="na">Ja</Resync_From_SIP>

  • På telefonens nettside velger du Ja for å aktivere denne funksjonen, eller Nei for å deaktivere den.

Standard: Ja

Resync After Upgrade Attempt

Aktiverer eller deaktiverer resynkronisering etter en oppgradering. Hvis du velger Ja utløses synkronisering etter en fastvareoppgradering.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_After_Upgrade_Attempt ua="na">Ja</Resync_After_Upgrade_Attempt>

  • På telefonens nettside velger du Ja for å utløse resynkronisering etter en fastvareoppgradering, eller Nei for å ikke resynkronisere.

Standard: Ja

Resynkroniseringsutløser 1

Resynkroniseringsutløser 2

Hvis den logiske formelen i disse parametrene evalueres til FALSE, utløses ikke en resynkronisering selv når Resynkroniser ved tilbakestilling er angitt som TRUE. Bare resynkronisering via direkte handlings-URL og SIP-varsel ignorerer disse resynkroniseringsutløserne.

Parametere kan programmeres med et betinget uttrykk som gjennomgår makroutvidelse. Hvis du vil ha informasjon om gyldige makroutvidelser, kan du se Makroutvidelsesvariabler under Klargjøringsparametere.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_Trigger_1 ua="na">$UPGTMR gt 300 og $PRVTMR ge 600</Resync_Trigger_1>

    <Resync_Trigger_2 ua="na"/>

  • På telefonens nettside angir du utløserne.

Standard: Tom

User Configurable Resync

Lar en bruker resynkronisere telefonen fra telefonskjermmenyen. Når den er angitt som Ja kan en bruker resynkronisere telefonkonfigurasjonen ved å angi profilregelen fra telefonen. Når den er angitt som Nei, vises ikke parameteren Profilregel på telefonskjermmenyen.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <User_Configurable_Resync ua="na">Ja</User_Configurable_Resync>

  • På telefonens nettside velger du Ja for å vise parameteren Profilregel på telefonmenyen, eller velger Nei for å skjule denne parameteren.

Standard: Ja

Resync Fails On FNF

En resynkronisering regnes vanligvis som mislykket hvis det ikke mottas en forespurt profil fra serveren. Denne parameteren overstyrer denne oppførselen. Når den er angitt som Nei godtar enheten et fil ikke funnet-svar fra serveren som en vellykket resynkronisering.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Resync_Fails_On_FNF ua="na">Ja</Resync_Fails_On_FNF>

  • På telefonens nettside velger du Ja for å ta fil ikke funnet-svar som en vellykket resynkronisering, eller velger Nei for å ta fil ikke funnet-svar som en vellykket resynkronisering.

Standard: Ja

Profilgodkjenningstype

Angir påloggingsopplysningene som skal brukes for godkjenning av profilkonto. Tilgjengelige alternativer er:

  • Deaktivert: Deaktiverer profilkontofunksjonen. Når denne funksjonen er deaktivert, viser ikke menyen Konfigurasjon av profilkonto på telefonskjermen.

  • Grunnleggende HTTP-godkjenning: HTTP-påloggingsopplysninger brukes til å godkjenne profilkontoen.

  • XSI-godkjenning: XSI-påloggingsopplysninger eller XSI SIP-påloggingsopplysninger brukes til å godkjenne profilkontoen. Godkjenning av påloggingsopplysninger avhenger av XSI-godkjenningstypr for telefonen:

    • Når XSI-godkjenningstype for telefonen er angitt som Påloggingsopplysninger vil XSI-påloggingsopplysninger brukes.

    • Når XSI-godkjenningstype for telefonen er angitt som SIP-påloggingsopplysinger vil XSI SIP-påloggingsopplysninger brukes.

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Profile_Authentication_Type ua="na">Grunnleggende Http-godkjenning</Profile_Authentication_Type>

  • På telefonens nettside velger du et alternativ fra listen for at telefonen skal kunne godkjenne resynkronisering av profil.

Standard: Grunnleggende HTTP-godkjenning

Hvis du vil ha mer informasjon, kan du se Angi godkjenningstypen for profil under Angi telefonen for ny synkronisering av profil.

Profilregel

Profile Rule B

Profile Rule C

Profile Rule D

Hver profilregel informerer telefonen om en kilde som den kan hente en profil (konfigurasjonsfil) fra. Under hver ny synkroniseringsoperasjon tar telefonen i bruk alle profiler i rekkefølge.

Hvis du tar i bruk AES-256-CBC-kryptering på konfigurasjonsfilene, angir du krypteringsnøkkel med --key-nøkkelordet på følgende måte:

[--key <krypteringsnøkkel>]

Krypteringsnøkkelen kan eventuelt settes i doble anførselstegn (").

  • I telefonens konfigurasjonsfil (cfg.xml) med XML angir du en streng i dette formatet:

    <Profile_Rule ua="na">/$PSN.xml</Profile_Rule>

    <Profile_Rule_B ua="na"/>

    <Profile_Rule_C ua="na"/>

    <Profile_Rule_D ua="na"/>

  • På telefonens nettside angir du profilregelen.

Standard: /$PSN.xml

DHCP-alternativ å bruke

DHCP-alternativer, atskilt med komma, brukes til å hente fastvare og profiler.

Standard: 66,160,159,150,60,43,125

DHCPv6-alternativ å bruke

DHCP-alternativer, atskilt med komma, brukes til å hente fastvare og profiler.

Standard: 17,160,159

Klargjøring gjennom Cisco XML

Du kan klargjøre telefonen gjennom Cisco XML-funksjoner.

Du kan sende et XML-element til telefonen med en SIP Notify-pakke eller en HTTP-oppføring til CGI-grensesnittet på telefonen: http://PhoneIPAddress/CGI/Execute.

CP-xxxx-3PCC utvider Cisco XML-funksjonen slik at den støtter klargjøring via et XML-objekt:

<CP-xxxx-3PCCExecute> <ExecuteItem URL=Resync:[profile-rule]/></CP-xxxx-3PCCExecute>

Etter at telefonen mottar XML-objektet, laster den ned klargjøringsfilen fra [profile-rule]. Denne regelen bruker makroer til å forenkle utviklingen av XML-tjenesteprogrammet.

URL-oppløsning med makroutvidelse

Underkataloger med flere profiler på serveren gir en praktisk måte å administrere mange distribuerte enheter. Profil-URL-adressen kan inneholde:

  • Navnet på en klargjøringsserver eller en eksplisitt IP-adresse. Hvis profilen identifiserer klargjøringsserveren på grunnlag av navn, utfører telefonen et DNS-oppslag for å løse navnet.

  • En ikke-standard serverport som angis i URL-adressen ved hjelp av standardsyntaksen :port etter navnet på serveren.

  • Underkatalogen i serverens virtuelle rotkatalog hvor profilen er lagret, angitt ved hjelp av standard URL-notasjon og administrert gjennom makroutvidelse.

Følgende Profile_Rule ber for eksempel om profil-filen ($PN.cfg), i serverens underkatalog /cisco/config, fra TFTP-serveren som kjører på vertens prov.telco.com og lytter etter en tilkobling på port 6900: 

<Profile_Rule>
tftp://prov.telco.com:6900/cisco/config/$PN.cfg
</Profile_Rule>

Det kan identifiseres en profil for hver telefon i en generell parameter, med verdien referert i en felles profilregel ved hjelp av makroutvidelse.

Forutsett for eksempel at GPP_B er angitt som Dj6Lmp23Q.

Profile_Rule har verdien:

tftp://prov.telco.com/cisco/$B/$MA.cfg

Når enheten resynkroniserer og makroene utvides, ber telefonen med MAC-adressen 000e08012345 om profilen som har et navn som inneholder enhetens MAC-adresse, på følgende URL-adresse:

tftp://prov.telco.com/cisco/Dj6Lmp23Q/000e08012345.cfg
Angi godkjenningstype for profil

Profilgodkjenning lar telefonbrukere resynkronisere klargjøringsprofilen på telefonen. Godkjenningsinformasjon kreves mens telefonen forsøker å resynkronisere og laste ned konfigurasjonsfil for første gang og får en HTTP- eller HTTPS 401-godkjenningsfeil. Når du aktiverer denne funksjonen, vises skjermen Konfigurasjon av profilkonto på telefonen for følgende situasjoner:

  • Når HTTP- eller HTTPS 401-godkjenningfeil oppstår ved første gangs klargjøring etter at telefonen starter på nytt.

  • Når profilkontoens brukernavn og passord er tomme

  • Når det ikke er noe brukernavn og passord i Profilregel

Hvis skjermen Konfigurasjon av profilkonto oversees eller ignoreres, kan brukeren også få tilgang til konfigurasjonsskjermen gjennom telefonskjermmenyen, eller funksjonstasten Konfigurasjon, som bare viser når det ikke er en registrert linje på telefonen.

Når du deaktiverer funksjonen, vil skjermen Konfigurasjon av profilkonto ikke vises på telefonen.

Brukernavn og passord i feltet Profilregel har høyere prioritet enn profilkontoen.

  • når du sørger for riktig URL i feltet Profilregel uten en brukernavn og passord, krever telefonen godkjenning eller sammendrag for å resynkronisere profilen. Med riktig profilkonto vedtas godkjenningen. Med feil profilkonto mislykkes godkjenningen.

  • Når du sørger for riktig URL i feltet Profilregel med riktig brukernavn og passord, krever telefonen godkjenning eller sammendrag for å resynkronisere profilen. Profilkontoen brukes ikke for resynkronisering av telefonen. Pålogging vellykket.

  • Når du sørger for riktig URL i feltet Profilregel med feil brukernavn og passord, krever telefonen godkjenning eller sammendrag for å resynkronisere profilen. Profilkontoen brukes ikke for resynkronisering av telefonen. Pålogging mislykkes alltid.

  • Når du leverer feil URL i feltet Profilregel, mislykkes alltid påloggingen.

Du kan også konfigurere parametrene i telefonens konfigurasjonsfil med XML-kode (cfg.xml).

Du kan angi godkjenningstype for profilen fra telefonens administrasjonsnettside.

1

Åpne telefonens administrasjonsnettside.

2

Velg Stemme > Klargjøring.

3

I området Konfigurasjonsprofil angir du parameteren Godkjenningstype for profil for å angi påloggingsopplysninger til bruk for godkjenning av profilkonto.

Du kan konfigurere denne parameteren i telefonkonfigurasjonens XML-fil (cfg.xml) ved å angi en streng i dette formatet:

<Profile_Authentication_Type ua="na">Deaktivert</Profile_Authentication_Type>

Alternativer:

  • Deaktivert: Deaktiverer profilkontofunksjonen. Når denne funksjonen er deaktivert, vil ikke menyen Konfigurasjon av profilkonto vises på telefonskjermen.

  • Grunnleggende HTTP-godkjenning: HTTP-påloggingsopplysninger brukes til å godkjenne profilkontoen.

  • XSI-godkjenning: XSI-påloggingsopplysninger eller XSI SIP-påloggingsopplysninger brukes til å godkjenne profilkontoen. Godkjenning av påloggingsopplysninger avhenger av XSI-godkjenningstypr for telefonen:

    Når XSI-godkjenningstype for telefonen er angitt som Påloggingsopplysninger vil XSI-påloggingsopplysninger brukes.

    Når XSI-godkjenningstype for telefonen er angitt som SIP-påloggingsopplysinger vil XSI SIP-påloggingsopplysninger brukes.

Standard: Grunnleggende HTTP-godkjenning

4

Klikk på Godta alle endringer.

Legge en profil til telefonen manuelt

Laste ned konfigurasjonsfilen til telefonen fra en TFTP-server

Følg denne fremgangsmåten for å laste ned konfigurasjonsfilen til et TFTP-serverprogram på datamaskinen.

1

Koble datamaskinen til LAN-porten på telefonen.

2

Kjør et TFTP-serverprogram på datamaskinen og sørg for at konfigurasjonsfilen er tilgjengelig i TFTP-rotkatalogen.

3

Angi IP-adressen til telefonens lokalnett, IP-adressen til datamaskinen, filnavnet og påloggingsinformasjonen i en nettleser. Bruk dette formatet:

http://<WAN_IP_Address>/admin/resync?tftp://<PC_IP_Address>/<file_name>&xuser=admin&xpassword=<password>

Eksempel: 

http://192.168.15.1/admin/resync?tftp://192.168.15.100/my_config.xml&xuser=admin&xpassword=admin
Laste ned konfigurasjonsfilen til telefonen med cURL

Følg denne fremgangsmåten for å laste ned konfigurasjonen til telefonen ved hjelp av cURL. Dette kommandolinjeverktøyet brukes til å overføre data med en URL-syntaks. Du kan laste ned cURL fra:

https://curl.haxx.se/download.html

Vi anbefaler at du ikke bruker cURL til å legge ut konfigurasjonen til telefonen. Dette er fordi brukernavnet og passordet kan fanges opp mens du bruker cURL.

1

Koble datamaskinen til LAN-porten på telefonen.

2

Last ned konfigurasjonsfilen til telefonen ved å skrive inn følgende cURL-kommando:

curl –d @my_config.xml“http://192.168.15.1/admin/config.xml&xuser=admin&xpassword=admin”

Konfigurasjonsprofiler

Telefonen godtar konfigurasjoner i XML-format.

Eksemplene i dette området bruker konfigurasjonsprofiler med XML-syntaks.

Konfigurasjonsprofilformater

Konfigurasjonsprofilen definerer parameterverdiene for telefonen.

XML-formatet for konfigurasjonsprofiler bruker standard XML-redigeringsverktøy til å kompilere parametre og verdier.

Det er bare UTF-8-tegnsettet som støttes. Hvis du endrer profilen i et redigeringsprogram, må du ikke endre kodingsformatet; hvis ikke, gjenkjenner ikke telefonen filen.

Hver telefon har et annet funksjonssett og derfor et annet sett med parametre.

Åpne profilformat

Profilen i åpent format er en tekstfil med XML-lignende syntaks i et hierarki av elementer, med elementattributter og -verdier. Med dette formatet kan du opprette konfigurasjonsfiler ved hjelp av standardverktøy. En XML-konfigurasjonsfil kan sendes fra klargjøringsserveren til telefonen under en resynkroniseringsoperasjon uten sammenstilling som et binærmål.

Telefonen kan godta konfigurasjonsformater generert av standardverktøy. Denne funksjonen gjør det enklere å utvikle bakgrunnsprogramvare – for klargjøringsservere – som generer konfigurasjonsprofiler fra eksisterende databaser.

For å beskytte konfidensielle opplysninger i konfigurasjonsfilen, leverer klargjøringsserveren XML-konfigurasjonsfilen til telefonen over en kanal som er sikret av TLS. Filen kan eventuelt komprimeres ved hjelp av deflate-algoritmen i gzip (RFC1951).

Filen kan krypteres med en av følgende krypteringsmetoder:

  • AES-256-CBC-kryptering

  • RFC-8188-basert kryptering av HTTP-innhold med AES-128-GCM-kryptering

En konfigurasjonsfil kan ha disse komponentene:

  • Elementkoder

  • Attributter

  • Parametre

  • Formateringsfunksjoner

  • XML-kommentarer

Eksempel: Åpent profilformat

<flat-profile><Resync_On_Reset> Yes </Resync_On_Reset><Resync_Periodic> 7200 </Resync_Periodic><Profile_Rule> tftp://prov.telco.com:6900/cisco/config/CP_xxxx_MPP.cfg</Profile_Rule></flat-profile>

Elementtaggen <flat-profile> inkluderer alle parameterelementer som telefonen gjenkjenner.

Egenskaper for elementtagg

Husk på følgende regler når du oppretter eller oppdaterer konfigurasjonsfilen.

  • XML-klargjøringsformatet og nettgrensesnittet tillater konfigurering av de samme innstillingene. XML-taggnavn og feltnavn i Webgrensesnittet er like men varierer grunnet begrensninger på XML-elementnavn. For eksempel understreker (_) i XML-konfigurasjonsfilen i stedet for mellomrom på Webgrensesnittet.

  • Telefonen gjenkjenner elementer med riktige parameternavn som er innkapslet i det spesielle <flat-profile>-elementet.

  • Elementnavn står i vinkelparenteser.

  • De fleste elementnavn er like feltnavn på telefonens Webgrensesnitt, med følgende modifikasjoner:

    • Elementnavn kan ikke inneholde mellomrom eller spesialtegn. Utlede elementnavnet fra webfeltnavnet, erstatte en understrek for hvert mellomrom eller spesialtegnene [, ], (, ) eller /.

      Eksempel: Elementet <Resync_On_Reset> representerer feltet Resync On Reset (Resynkroniser ved tilbakestilling).

    • Hvert elementnavn må være unikt. I telefonens Webgrensesnitt vises de samme feltene på flere nettside, som sidene Linje, Bruker og Internnummer. Føy [n] til elementnavnet for å angi nummeret som vises i sidefanen.

      Eksempel: Elementet <Dial_Plan_1_> representerer Oppringingsplan for Linje 1.

  • Hver startelementkode må ha en tilsvarende sluttelementkode. Eksempel:

    <flat-profile><Resync_On_Reset> Yes  </Resync_On_Reset><Resync_Periodic> 7200  </Resync_Periodic><Profile_Rule>tftp://prov.telco.com: 6900/cisco/config/CP_xxxx_MPP.cfg  </Profile_Rule></flat-profile>

  • Elementkoder skiller mellom store og små bokstaver.

  • Tomme elementkoder er tillatt og blir tolket som å konfigurere at verdien skal være tom. Skriv inn startelementkoden uten en tilsvarende elementkode, og sett inn et mellomrom og en skråstrek før den avsluttende vinkelhakeparentesen (>). I dette eksemplet er profilregel B tom:

    <Profile_Rule_B />

  • Tomme elementkoder kan brukes til å hindre overskriving av brukerdefinerte verdier under en resynkroniseringsoperasjon. I eksemplet nedenfor forblir brukerens kortnummerinnstillinger uendret:

    <flat-profile><Speed_Dial_2_Name ua="rw"/><Speed_Dial_2_Number ua="rw"/><Speed_Dial_3_Name ua="rw"/><Speed_Dial_3_Number ua="rw"/><Speed_Dial_4_Name ua="rw"/><Speed_Dial_4_Number ua="rw"/><Speed_Dial_5_Name ua="rw"/><Speed_Dial_5_Number ua="rw"/><Speed_Dial_6_Name ua="rw"/><Speed_Dial_6_Number ua="rw"/><Speed_Dial_7_Name ua="rw"/><Speed_Dial_7_Number ua="rw"/><Speed_Dial_8_Name ua="rw"/><Speed_Dial_8_Number ua="rw"/><Speed_Dial_9_Name ua="rw"/><Speed_Dial_9_Number ua="rw"/></flat-profile>

  • Bruk en tom verdi til å angi en tom streng for den tilsvarende parameteren. Skriv inn et start- og sluttelement uten at det er noen verdier mellom dem. I eksemplet nedenfor er parameteren GPP_A satt til en tom streng.

    <flat-profile><GPP_A>  </GPP_A></flat-profile>

  • Elementnavn som ikke gjenkjennes, ignoreres.

Parameteregenskaper

Disse egenskapene gjelder for parametre:

  • Alle parametre som ikke angis av en profil, forblir uendret i telefonen.

  • Parametre som ikke gjenkjennes, ignoreres.

  • Hvis en profil med åpent format inneholder flere forekomster av den samme parameterkoden, overstyrer den siste forekomsten alle de tidligere. For å unngå utilsiktet overstyring av konfigurasjonsverdier for en parameter, anbefaler vi at hver profil ikke angir mer enn én forekomst av en parameter.

  • Den sist behandlede profilen får prioritet. Hvis flere profiler angir den samme konfigurasjonsparameteren, får verdien til den siste profilen prioritet.

Strengformater

Disse egenskapene gjelder formateringen av strenger:

  • Kommentarer er tillatt via standard XML-syntaks.

    <!-- Min kommentar skrives inn her -->

  • Innledende og etterfølgende mellomrom er tillatt for lesing, men fjernes fra parameterverdien.

  • Nye linjer innenfor en verdi konverteres til mellomrom.

  • En XML-topptekst i formen <? ?> er tillatt, men telefonen ignorerer det.

  • Hvis du vil angi spesialtegn, kan du bruke grunnleggende XML-escapetegn, som vist i tabellen nedenfor.

    Spesialtegn

    XML-escapesekvens

    & (ampersand)

    &amp;

    < (mindre enn)

    &lt;

    > (større enn)

    &gt;

    ' (apostrof)

    &apos;

    " (dobbelt anførselstegn)

    &quot;

    I eksemplet nedenfor skrives escapetegn inn for å angi større enn- og mindre enn-symboler som er nødvendige i en oppringingsplanregel. Dette eksempelet definerer en informasjonsdirektelinje for oppringingsplan som angir parameteren <Dial_Plan_1_> (Administratorpålogging > avansert > Stemme > Ext (n)) lik (S0 <:18005551212>).

    <flat-profile> <Dial_Plan_1_> (S0 &lt;:18005551212&gt;) </Dial_Plan_1_></flat-profile>

  • Tall med desimal- og heksadesimalverdier (som &#40; og &#x2e;), oversettes.

  • Telefonens fastvare støtter bare ASCII-tegn.

Kompresjon og kryptering av åpen profil (XML)

Åpne konfigurasjonsprofiler kan komprimeres for å redusere nettverksbelastningen på klargjøringsserveren. Profilen kan dessuten krypteres for å beskytte konfidensiell informasjon. Komprimering er ikke nødvendig, men må gjøres før en kryptering.

Kompresjon av åpen profil

Den støttede komprimeringsmetoden er deflate-algoritmen i gzip (RFC1951). Gzip-verktøyet og komprimeringsbiblioteket som implementerer den samme algoritmen (zlib), er tilgjengelige fra Internett-nettsteder.

Telefonen identifiserer komprimering ved at den komprimerte filen inneholder et gzip-kompatibelt filhode. Filhodet genereres når gzip-verktøyet aktiveres på den opprinnelige åpne profilen. Telefonen inspiserer det nedlastede filhodet for å bestemme filformatet.

Hvis for eksempel profile.xml er en gyldig profil, godtas også filen profile.xml.gz. Én av følgende kommandoer kan generere denne profiltypen:

  • >gzip profile.xml

    Erstatter den opprinnelige filen med en komprimert fil.

  • >cat profile.xml | gzip > profile.xml.gz

    Lar originalfilen ligge or produserer en ny komprimert fil.

Åpne profilkryptering

Symmetrisk nøkkelkryptering kan brukes til å kryptere åpne konfigurasjonsprofiler, enten filen er komprimert eller ikke. Eventuell komprimering må utføres før kryptering.

Klargjøringsserveren bruker HTTPS til å håndtere den første klargjøringen av telefoner etter distribusjon. Forhåndskryptering av konfigurasjonsprofiler offline gjør det mulig med bruk av HTTP for resynkroniseringsprofiler. Dette reduserer belastningen på HTTPS-serveren ved omfattende distribusjoner.

Telefonen støtter to krypteringsmetoder for konfigurasjonsfiler:

  • AES-256-CBC-kryptering

  • RFC 8188-basert kryptering av HTTP-innhold med AES-128-GCM-kryptering

Nøkkelen eller nøkkelmaterialet (IKM) må være forhåndsklargjort på enheten. Oppstart av den hemmelige nøkkelen kan gjøres sikkert ved hjelp av HTTPS.

Navnet på konfigurasjonsfilen krever ikke et bestemt format, men et filnavn som avsluttes med internnummeret .cfg angir normalt en konfigurasjonsprofil.

AES-256-CBC-kryptering

Telefonen støtter AES-256-CBC-kryptering for konfigurasjonsfiler.

OpenSSL-krypteringsverktøyet, som er tilgjengelig for nedlasting fra forskjellige Internett-nettsteder, kan utføre krypteringen. Støtte for 256-biters AES-kryptering kan kreve at verktøyet rekompileres for å aktivere AES-kode. Fastvaren er testet mot versjonen openssl-1.1.1d.

Telefonen identifiserer kryptering ved at filen har formatet som genereres av følgende kommando:

 # eksempel krypteringsnøkkel = SecretPhrase1234 openssl enc –e –aes-256-cbc –k SecretPhrase1234 –in profile.xml –out profile.cfg # analog påkalling for en komprimert XML-fil openssl enc –e –aes-256-cbc –k SecretPhrase1234 –in profile.xml.gz –out profile.cfg

En liten -k kommer før den hemmelige nøkkelen, som kan være en hvilken som helst frase med ren tekst, og som brukes til å generere et tilfeldig 64-biters salt. Med hemmeligheten angitt av argumentet -k utleder krypteringsverktøyet en tilfeldig 128-biters initialvektor og den faktiske 256-biters krypteringsnøkkelen.

Når denne formen for kryptering brukes på en konfigurasjonsprofil, må telefonen informeres om den hemmelige nøkkelverdien for å kunne dekryptere filen. Verdien angis som en kvalifikator i profil-URL-adressen. Syntaksen er som følger, ved bruk av eksplisitt URL-adresse:

[--key “SecretPhrase1234”] http://prov.telco.com/path/profile.cfg

Verdien programmeres ved å bruke en av parametrene Profilregel.

Makroutvidelse

Flere klargjøringsparametre gjennomgår makroutvidelse internt før de blir evaluert. Dette preevalueringstrinnet gir større fleksibilitet ved styring av resynkroniserings- og oppgraderingsprosessene.

Disse parametergruppene gjennomgår makroutvidelse før evaluering:

  • Resync_Trigger_*

  • Profile_Rule*

  • Log_xxx_Msg

  • Upgrade_Rule

Under visse forhold gjennomgår noen generelle parametere (GPP_*) også makroutvidelse, som eksplisitt angitt i delen Valgfrie argumenter for ny synkronisering nedenfor.

Under makroutvidelse erstatter innholdet i de navngitte variablene uttrykk i skjemaet $NAME og $(NAME). Variablene omfatter generelle parametre, flere produktidentifikatorer, visse hendelsestidtakere og klargjøringstilstandsverdier. Hvis du vil ha en fullstendig liste, kan du se Makroutvidelsesvariabler under Klargjøringsparametere.

I eksemplet nedenfor brukes uttrykket $(MAU) til å sette inn MAC-adressen 000E08012345.

Administratoren skriver: $(MAU)config.cfg

Den påfølgende makroutvidelsen for en enhet med MAC-adresse 000E08012345 er: 000E08012345config.cfg

Hvis et makronavn ikke gjenkjennes, utvides det ikke. Navnet STRANGE gjenkjennes for eksempel ikke som et gyldig makronavn, mens MAU gjenkjennes som et gyldig makronavn.

Administratoren skriver: $STRANGE$MAU.cfg

Den påfølgende makroutvidelsen for en enhet med MAC-adresse 000E08012345 er: $STRANGE000E08012345.cfg

Makroutvidelse brukes ikke rekursivt. $$MAU” utvides for eksempel til $MAU” ($$ utvides) og gir ikke MAC-adressen.

Innholdet i spesialparametrene, fra GPP_SA til GPP_SD, tilordnes til makrouttrykkene fra $SA til $SD. Disse parameterne makroutvides bare som argument i alternativene --key, --uid og --pwd i en resynkroniserings-URL-adresse.

Betingelsesuttrykk

Betingelsesuttrykk kan utløse resynkroniseringshendelser og velge blant alternative URL-adresser for resynkroniserings- og oppgraderingsoperasjoner.

Betingelsesuttrykk består av en liste med sammenligninger, atskilt med operatoren og. Alle sammenligninger må oppfylles for at betingelsen skal bli sann.

Hver sammenligning kan være knyttet til én av følgende tre typer litteraler:

  • heltall

  • versjonsnumre for programvare eller maskinvare

  • strenger med doble anførselstegn

Versjonsnumre

Programvareversjoen for Cisco videotelefon 8875 bruker dette formatet (hvor BN er Build-nummeret):

PHONEOSåååå.1-0-1-0001-BN

hvor åååå angir telefonmodellen eller telefonserien, er 1 den store versjonen; 0 er en mindre versjon; 1-0001 er mikroversjonen og BN er build-nummeret.

Sammenligningsstrengen må bruke det samme formatet. Det vil ellers oppstå formatanalysefeil.

Ved sammenligning av programvareversjon vil den store versjonen, den mindre versjonen og mikroversjonen sammenlignes i rekkefølge, og sifrene lengst til venstre har forrang over nyere versjoner. Build-numre sammenlignes når versjonsnumre er identiske.

Eksempler på gyldig versjonsnummer

PHONEOS-8875.1-0-1-0001-19

Sammenligning

Strenger med anførselstegn kan sammenlignes for likhet eller ulikhet. Heltall og versjonsnumre kan dessuten sammenlignes aritmetisk. Sammenligningsoperatorene kan uttrykkes som symboler eller akronymer. Akronymer er praktiske å bruke til å uttrykke betingelser i profiler i åpent format.

Operatør

Alternativ syntaks

Beskrivelse

Gjelder for heltall og versjonsoperander

Gjelder for strengoperander med anførselstegn

=

eq

er lik

Ja

Ja

!=

ne

er ulik

Ja

Ja

<

lt

mindre enn

Ja

Nei

<=

le

mindre enn eller lik

Ja

Nei

>

gt

større enn

Ja

Nei

>=

ge

større enn eller lik

Ja

Nei

OG

og

Ja

Ja

Det er viktig å sette makrovariabler i doble anførselstegn der det forventes en strenglitteral. Ikke gjør det når et nummer eller versjonsnummer forventes.

Når de brukes i forbindelse med parametrene Profile_Rule* og Upgrade_Rule, må betingelsesuttrykk stå i syntaksen "(uttr)?", som i dette eksemplet på en oppgraderingsregel. Husk å bytte ut BN med build-nummeret for fastvarebelastningen som skal oppgraderes til.

($SWVER ne PHONEOS-8875.1-0-1-0001-19)? http://ps.tell.com/sw/PHONEOS-8875.1-0-1-0001-BN.loads

Ikke bruk den foregående syntaksen med parenteser til å konfigurere Resync_Trigger_*-parametre.

URL-syntaks

Bruk standard URL-syntaks til å angi hvordan konfigurasjonsfiler og fastvarelaster skal hentes i parametrene Profile_Rule* og Upgrade_Rule henholdsvis. Syntaksen er som følger:

[ skjema:// ] [ server [:port]] filbane

Hvor skjema er én av disse verdiene:

  • tftp

  • http

  • https

Hvis skjema utelates, antas tftp. Serveren kan være et DNS-gjenkjennelig vertsnavn eller en numerisk IP-adresse. Porten er destinasjonen for UDP- eller TCP-portnummeret. Filbanen må begynne med rotkatalogen (/); det må være en absolutt bane.

Hvis server mangler, brukes tftp-server angitt gjennom DHCP (alternativ 66).

Ved oppgraderingsregler må server angis.

Hvis port mangler, brukes standardporten for det angitte skjemaet. Tftp bruker UDP-port 69, http bruker TCP-port 80, https bruker TCP-port 443.

Det må angis filbane. Den trenger ikke nødvendigvis vise til en statisk fil, men kan angi dynamisk innhold skaffet gjennom CGI.

Makroutvidelse gjelder i URL-adresser. Følgende er eksempler på gyldige URL-adresser:

 /$MA.cfg /cisco/cfg.xml 192.168.1.130/profiles/init.cfg tftp://prov.call.com/cpe/cisco$MA.cfg http://neptune.speak.net:8080/prov/$D/$E.cfg https://secure.me.com/profile?Linksys

Når du bruker DHCP-alternativ 66, støttes ikke tom syntaks av oppgraderingsregler. Det er bare aktuelt for Profile Rule*.

RFC 8188-basert kryptering av HTTP-innhold

Telefonen støtter RFC 8188-basert kryptering av HTTP-innhold med AES-128-GCM-kryptering for konfigurasjonsfiler. Med denne krypteringsmetoden kan alle enheter lese HTTP-meldingshoder. Imidlertid kan bare enhetene som kjenner til nøkkelmaterialet (IKM), lese pakkeinnholdet. Når telefoner klargjøres ved hjelp av nøkkelmateriale, kan telefonene og klargjøringsserveren utveksle konfigurasjonsfiler på en sikker måte, samtidig som tredjeparts nettverkselementer kan bruke meldingshodene til analyse og overvåking.

XML-konfigurasjonsparameteren IKM_HTTP_Encrypt_Content inneholder nøkkelmaterialet på telefonen. Av sikkerhetsmessige årsaker er ikke denne parameteren tilgjengelig på telefonens administrasjonsnettside. Det vises heller ikke i telefonens konfigurasjonsfil, som du får tilgang til via telefonens IP-adresse eller via telefonens konfigurasjonsrapporter, som sendes til klargjøringsserveren.

Hvis du vil bruke RFC 8188-basert kryptering, må du kontrollere at følgende er på plass:

  • Klargjør telefonen med nøkkelmateriale ved å angi nøkkelmaterialet med XML-parameteren IKM_HTTP_Encrypt_Content i konfigurasjonsfilen som sendes fra klargjøringsserveren til telefonen.

  • Hvis denne krypteringen gjelder konfigurasjonsfilen som sendes fra klargjøringsserveren til telefonen, må du sørge for at HTTP-toppteksten Innholdskoding i konfigurasjonsfilen har aes128gcm.

    Hvis dette hodet mangler, får AES-256-CBC-metoden forrang. Telefonen bruker AES-256-CBC-dekryptering hvis det er en AES-256-CBC-nøkkel i en profilregel, uavhengig av nøkkelmateriale.

  • Hvis du vil at telefonen skal bruke denne krypteringen på konfigurasjonsrapporter som sendes til klargjøringsserveren, må du sjekke at det ikke er angitt en AES-256-CBC-nøkkel i rapportregelen.

Argumenter for valgfri resynkronisering

Valgfrie argumenter, tast, uid og pwd, komme før URL-er angitt i Profilregel*-parametere sammenstilt med hakeparenteser.

Key

Valget --tast forteller telefonen at konfigurasjonsfilen den mottok fra klargjøringsserveren krypteres med AES-256-CBC encryption, med mindre toppteksten Innholdskoding i filen angir aes128gcm kryptering. Selve nøkkelen angis som en streng etter ordet --key. Nøkkelen kan eventuelt settes i doble anførselstegn ("). Telefonen bruker nøkkelen til å dekryptere konfigurasjonsfilen.

Brukseksempler
[--key VerySecretValue][--key “my secret phrase”][--key a37d2fb9055c1d04883a0745eb0917a4]

Valgfrie argumenter i hakeparentes makroutvides. Spesialparametre – GPP_SA til GPP_SD – makroutvides til makrovariabler – fra $SA til $SD – bare når de brukes som nøkkelalternativargumenter. Se disse eksemplene:

[--key $SC][--key “$SD”]

I profiler med åpent format må argumentet til --key være det samme som argumentet til alternativet -k som gis til openssl.

Uid og pwd

Valgene uid og pwd kan brukes til å angi bruker-ID og passord som sendes i svar på utfordringer med HTTP Basic og Digest autentisering når den bestemte URL-en forespørres. Valgfrie argumenter i hakeparentes makroutvides. Spesialparametre – GPP_SA til GPP_SD – makroutvides til makrovariabler – fra $SA til $SD – bare når de brukes som nøkkelalternativargumenter. Se disse eksemplene:

GPP_SA = MyUserID GPP_SB = MySecretPassword

[--uid $SA --pwd $SB] https://provisioning_server_url/path_to_your_config/your_config.xml

utvides til:

[--uid MyUserID --pwdMySecretPassword] https://provisioning_server_url/path_to_your_config/your_config.xml

Datatyper

Disse datatypene brukes med konfigurasjonsprofilparametre:

  • {a,b,c,…} – et valg mellom a, b, c, …

  • bool – boolsk verdi som enten "ja" eller "nei".

  • CadScript – et miniskript som angir kadensparametrene for et signal. Opptil 127 tegn.

    Syntaks: S1[;S2], hvor:

    • Si=Di(oni,1/offi,1[,oni,2/offi,2[,oni,3/offi,3[,oni,4/offi,4[,oni,5/offi,5[,oni,6/offi,6]]]]]) og er kjent som en seksjon.

    • oni,j og offi,j er på/av-varigheten i sekunder av et segment. i = 1 eller 2, og j = 1 til 6.

    • Di er seksjonens totale varighet i sekunder.

    Alle varigheter kan ha opptil tre desimalplasser for å kunne gi en oppløsning på 1 ms. Jokertegnet "*" betyr ubegrenset varighet. Segmentene i en seksjon spilles av i rekkefølge og gjentas helt til den totale varigheten er avspilt.

    Eksempel 1:

     60(2/4) Antall tråkkfrekvensseksjoner = 1 Tråkkfrekvensdel 1: Seksjonslengde = 60 s Antall segmenter = 1 Segment 1: På=2S, Av=4S Total ringlengde = 60s

    Eksempel 2 – tydelig ringetone (kort,kort,kort,lang):

     60(.2/.2,.2/.2,.2/.2,1/4) Antall tråkkfrekvensseksjoner = 1 Tråkkfrekvensdel 1: Seksjonslengde = 60s Antall segmenter = 4 Segment 1: På=0,2s, Av=0,2s Segment 2: På=0,2s, Av=0,2s Segment 3: På=0,2s, Av=0,2s Segment 4: På=1,0s, Av=4,0s Total ringlengde = 60s

  • DialPlanScript – skriptsyntaks som brukes til å angi oppringingsplaner for linje 1 og linje 2.

  • Float<n> – en flyttallsverdi med opptil n desimalplasser.

  • FQDN – Fullstendig kvalifisert domenenavn. Det kan inneholde opptil 63 tegn. Eksempler:

    • sip.Cisco.com:5060 eller 109.12.14.12:12345

    • sip.Cisco.com eller 109.12.14.12

  • FreqScript – et miniscript som spesifiserer frekvens- og nivåparametrene for en tone. Inneholder opptil 127 tegn.

    Syntaks: F1@L1[,F2@L2[,F3@L3[,F4@L4[,F5@L5[,F6@L6]]]]], hvor:

    • F1–F6 er frekvens i Hz (bare usignerte heltall).

    • L1–L6 er tilsvarende nivåer i dBm (med opptil én desimalplass).

    Mellomrom før og etter komma er tillatt, men anbefales ikke.

    Eksempel 1 – samtale venter-tone:

     440@-10 Antall frekvenser = 1 Frekvens 1 = 440 Hz ved –10 dBm

    Eksempel 2 – summetone:

     350@-19,440@-19 Antall frekvenser = 2 Frekvens 1 = 350 Hz ved –19 dBm Frekvens 2 = 440 Hz ved –19 dBm

  • IP – Gyldig IPv4-adresse i formen x.x.x.x, hvor x er mellom 0 og 255. Eksempel: 10.1.2.100.

  • UserID – bruker-ID slik den vises i en URL-adresse; opptil 63 tegn.

  • Phone – en telefonnummerstreng, for eksempel 14081234567, *69, *72, 345678; eller en generell URL-adresse, for eksempel 1234@10.10.10.100:5068 eller jsmith@Cisco.com. Strengen kan inneholde opptil 39 tegn.

  • PhTmplt – en telefonnummermal. Hver mal kan inneholde ett eller flere mønstre som er atskilt med komma (,). Mellomrom ved begynnelsen av hvert mønster ignoreres. "?" og "*" representerer jokertegn. Bruk %xx til å representere litterale tegn. %2a representerer for eksempel *. Malen kan inneholde opptil 39 tegn. Eksempler: “1408*, 1510*”, “1408123????, 555?1.”.

  • Port – TCP/UDP-portnummeret (0-65535). Kan angis i desimalt eller heksadesimalt format.

  • ProvisioningRuleSyntax – skriptsyntaks som brukes til å definere regler for resynkronisering av konfigurasjoner og oppgradering av fastvare.

  • PwrLevel – effekt uttrykt i dBm med én desimalplass, for eksempel –13,5 eller 1,5 (dBm).

  • RscTmplt – En mal for SIP-responsstatuskode, som “404, 5*”, “61?”, “407, 408, 487, 481”. Kan inneholde opptil 39 tegn.

  • Sig<n> – n-biters verdi med fortegn. Kan angis i desimalt eller heksadesimalt format. Et "-"-tegn må stå foran negative verdier. Et + foran positive verdier er valgfritt.

  • Stjernekoder – aktiveringskode for en tilleggstjeneste, som for eksempel *69. Koden kan inneholde opptil 7 tegn.

  • Str<n> – en generell streng med opptil n ureserverte tegn.

  • Time<n> – varighet i sekunder, med opptil n desimalplasser. Ekstra desimaler som angis, ignoreres.

  • ToneScript – et miniscript som angir frekvens-, nivå- og kadensparametre for samtale pågår-tone. Skript kan inneholde opptil 127 tegn.

    Syntaks: FreqScript;Z1[;Z2].

    Seksjonen Z1 ligner seksjonen S1 i et CadScript, bortsett fra at hvert på/av-segment etterfølges av en frekvenskomponentparameter: Z1 = D1(oni,1/offi,1/fi,1[,oni,2/offi,2/fi,2 [,oni,3/offi,3/fi,3 [,oni,4/offi,4/fi,4 [,oni,5/offi,5/fi,5 [,oni,6/offi,6/fi,6]]]]]) hvor:

    • fi,j = n1[+n2]+n3[+n4[+n5[+n6]]]]].

    • 1 < nk < 6 angir frekvenskomponentene i FreqScript som brukes i det segmentet.

    Hvis det brukes mer enn én frekvenskomponent i et segment, summeres komponentene.

    Eksempel 1 – summetone:

     350@-19,440@-19; 10(*/0/1+2) Antall frekvenser = 2 Frekvens 1 = 350 Hz ved –19 dBm Frekvens 2 = 440 Hz ved –19 dBm Antall tråkkfrekvenssnitt = 1 Tråkkfrekvensdel 1: Seksjonslengde = 10 s Antall segmenter = 1 Segment 1: På=for alltid, med frekvensene 1 og 2 Total tonelengde = 10s

    Eksempel 2 – opptattone:

     350@-19,440@-19; 2(.1/.1/1+2); 10(*/0/1+2) Antall frekvenser = 2 Frekvens 1 = 350 Hz ved –19 dBm Frekvens 2 = 440 Hz ved –19 dBm Antall tråkkfrekvensseksjoner = 2 Tråkkfrekvensseksjon 1: Seksjonslengde = 2s Antall segmenter = 1 Segment 1: På=0,1s, Av=0,1s med frekvensene 1 og 2 Tråkkfrekvensdel 2: Seksjonslengde = 10s Antall segmenter = 1 Segment 1: På=for alltid, med frekvensene 1 og 2 Total tonelengde = 12s

  • Uns<n>—Usignert n-bitverdi, hvor n = 8, 16 eller 32. Den kan angis i desimal eller heksadesimalformat, slik som 12 eller 0x18, så lenge verdien kan passe inn i n bits.

Husk dette:

  • <Par Name> representerer et konfigurasjonsparameternavn. I en profil formes korresponderende tagg ved å bytte ut mellomrom med en understrek “_”, slik som Par_Name.
  • Et tomt standardverdifelt innebærer at strengen er tom < "" >.
  • Telefonen fortsetter å bruke de sist konfigurerte verdiene for koder som mangler i en gitt profil.
  • Maler sammenlignes i angitt rekkefølge. Det første, ikke det nærmeste, treffet velges. Parameternavnet må samsvare nøyaktig.
  • Hvis det gis mer enn én definisjon for en parameter i en profil, er det den siste definisjonen i filen som blir tatt i bruk i telefonen.
  • En parameterspesifikasjon med en tom parameterverdi tvinger parameteren tilbake til standard verdi. Hvis du vil angi en tom streng i stedet, kan du bruke den tomme strengen "" som parameterverdi.