Iniziamo ricordando che il telefono deve partire avendo l'indirizzo del TFTP server da cui scaricare il proprio file di configurazione XML: in Cisco, il TFTP server è proprietario e coincide con il Call Manager stesso (express o linux che sia). Nel file XML ci sono varie informazioni, in primis l'indirizzo del CME a cui registrarsi. Purtroppo non si può rispondere in maniera assolutistica al perché un ip-phone non si registra: serve un'analisi del traffico prodotto e ricevuto dal telefono in fase di registrazione, nonché la visione dei messaggi sul display del telefono. In generale, il file di configurazione esiste nel momento in cui si configurano i comandi visti nel CME (Nel CUCM Linux si procede in altro modo, ma l'effetto sarà lo stesso: produrre il file XML del telefono inserito). Può esserci un errore nella generazione del file di config (è molto raro, ma non impossibile), ma possono esserci errori nella configurazione fatta (es. MAC o type del telefono errati, no DN assegnato). Il CM Group fa parte del file di configurazione, che puoi vedere come una lista di informazioni in formato XML. Il firmware obsoleto può essere un problema solo se incompatibile con la versione del CME in uso (oggi accade raramente e solo per telefoni molto vecchi): come visto a lezione, si può registrare il telefono anche senza alcun firmware installato sul CME, perché questo servirebbe solo per aggiornare il firmware in uso al telefono. Se il telefono che deve registrarsi non è inserito manualmente, è necessario avere l'auto-registrazione abilitata (oggigiorno è deprecato fare così), perché se il telefono non trova il proprio file di configurazione, richiede un file Default XML generato per tipo di segnalazione (SCCP o SIP) e modello del telefono. Per avere i file XML Default, devi installare nel router i file che implementano le funzionalità avanzate di CME (tra cui la GUI). Il Call Manager Linux ha già tutto incluso (firmware compreso).
Per quanto riguarda LLQ, in caso di congestione è verosimile che le classi definite raggiungano l'intero ammontare configurato per ciò che riguarda la percentuale di buffer riservato alla particolare classe. L'approccio dovrebbe essere sempre quello di fare in modo che le classi create comprendano una classe finale dove finisce "tutto l'altro traffico". Anche qui, non si può rispondere in maniera assolutistica, perché le classi vanno progettate in base alla struttura della particolare rete considerata. Tanto per fare un esempio, potresti creare CLASSE 1 che corrisponde al traffico di controllo che permette alla rete di funzionare (es. OSPF): potresti riservare un 15% perché generalmente questo traffico non è molto a livello di numero di pacchetti, ma è vitale processarlo per primo in caso di congestione. Poi, ipotizziamo CLASSE 2 (traffico VoIP/Video) = 35%. CLASSE 3 = traffico HTTPS verso la server farm (sempre per fare un esempio) = 25%. Il restante 25% = CLASSE 4, che matcha tutto il resto del traffico. Ripeto all'infinito che il modello implementato deve essere progettato in base a uno studio approfondito del traffico della propria rete quando questa funziona in maniera normale (senza congestione). Come best practice, è bene non definire troppe classi per raggruppare tutto il traffico veicolato dalla rete. Cisco ne suggerisce 4.
