- Página inicial
- /
- Artigo
Obrigado pelos seus comentários.
Parâmetros de provisionamento para telefones das séries 9800 e 8875 (BroadWorks)
Neste artigo
Comentários?Este artigo de ajuda é para o Cisco Desk Phone 9800 Series e o Cisco Video Phone 8875 registrados no Cisco BroadWorks. As informações nesta página incluem os parâmetros de provisionamento e sua sintaxe.
Tipos de parâmetros de provisionamento
Esta seção descreve os parâmetros de provisionamento amplamente organizados de acordo com a função.
Parâmetros de uso geral
Os parâmetros de uso geral GPP_* () são usados como registros de cadeias de caracteres gratuitos ao configurar o telefone para interagir com uma solução específica de servidor de provisionamento. Os parâmetros GPP_* estão vazios por padrão. Eles podem ser configurados para conter diversos valores, incluindo os seguintes:
-
Chaves de criptografia
-
URLs
-
Informações de status de provisionamento em vários estágios.
-
Modelos de solicitação de postagem
-
Mapas de aliases de nomes de parâmetros
-
Valores parciais de string, eventualmente combinados em valores de parâmetros completos.
Os parâmetros GPP_* estão disponíveis para expansão de macros dentro de outros parâmetros de provisionamento. Para esse propósito, nomes de macro de uma letra maiúscula (A a P) são suficientes para identificar o conteúdo de GPP_A a GPP_P. Além disso, os nomes de macro de duas letras maiúsculas SA a SD identificam GPP_SA a GPP_SD como um caso especial quando usados como argumentos das seguintes opções de URL:
chave, uid e pwd
Esses parâmetros podem ser usados como variáveis nas regras de provisionamento e atualização. Eles são referenciados prefixando o nome da variável com um caractere '$', como $GPP_A.
Ativar parâmetros
Os parâmetros Provision_Enable e Upgrade_Enable controlam todas as operações de ressincronização de perfil e atualização de firmware. Esses parâmetros controlam ressincronizações e atualizações independentemente uns dos outros. Esses parâmetros também controlam os comandos de URL de ressincronização e atualização que são emitidos pelo servidor web de administração. Esses dois parâmetros são definidos como Sim por padrão.
O parâmetro Resync_from_SIP controla as solicitações de operações de ressincronização. Um evento SIP NOTIFY é enviado do servidor proxy do provedor de serviços para o telefone. Se ativado, o proxy pode solicitar uma ressincronização. Para fazer isso, o proxy envia uma mensagem SIP NOTIFY que contém o cabeçalho Event: resync para o dispositivo.
O dispositivo desafia a solicitação com uma resposta 401 (autorização recusada para credenciais usadas). O dispositivo espera uma solicitação subsequente autenticada antes de atender à solicitação de ressincronização do proxy. Os cabeçalhos Event: reboot_now e Event: restart_now realizam reinicializações a frio e a quente, respectivamente, que também são desafiadas.
As duas habilitações restantes são Resync_On_Reset e Resync_After_Upgrade_Attempt. Esses parâmetros determinam se o dispositivo executa uma operação de ressincronização após a reinicialização do software de inicialização e após cada tentativa de atualização.
Quando Resync_On_Reset está habilitado, o dispositivo introduz um atraso aleatório que segue a sequência de inicialização antes que a reinicialização seja executada. O atraso é um tempo aleatório até o valor que o Resync_Random_Delay (em segundos) especifica. Em um pool de telefones que são ligados simultaneamente, esse atraso distribui os horários de início das solicitações de ressincronização de cada unidade. Esse recurso pode ser útil em uma grande implantação residencial, no caso de uma falha de energia regional.
Gatilhos
O telefone permite que você ressincronize em intervalos específicos ou em um horário específico.
Ressincronize em intervalos específicos
O telefone foi projetado para ressincronizar periodicamente com o servidor de aprovisionamento. O intervalo de ressincronização é configurado em Resync_Periodic (segundos). Se esse valor for deixado vazio, o dispositivo não será ressincronizado periodicamente.
A ressincronização normalmente ocorre quando as linhas de voz estão ociosas. Se uma linha de voz estiver ativa quando a ressincronização estiver prevista, o telefone atrasará o procedimento de ressincronização até que a linha fique ociosa novamente. Uma ressincronização pode fazer com que os valores dos parâmetros de configuração sejam alterados.
Uma operação de ressincronização pode falhar porque o telefone não consegue recuperar um perfil do servidor, o arquivo baixado está corrompido ou ocorreu um erro interno. O dispositivo tenta ressincronizar novamente após um tempo especificado em Resync_Error_Retry_Delay (segundos). Se Resync_Error_Retry_Delay estiver definido como 0, o dispositivo não tentará ressincronizar novamente após uma falha na tentativa de ressincronização.
Se uma atualização falhar, uma nova tentativa será executada após segundos de Upgrade_Error_Retry_Delay.
Dois parâmetros configuráveis estão disponíveis para acionar condicionalmente uma ressincronização: Resync_Trigger_1 e Resync_Trigger_2. Cada parâmetro pode ser programado com uma expressão condicional que passa por expansão macro. Quando o intervalo de ressincronização expirar (hora da próxima ressincronização), os acionadores, se definidos, evitarão a ressincronização, a menos que um ou mais acionadores sejam avaliados como verdadeiros.
O exemplo de condição a seguir aciona uma ressincronização. No exemplo, a última tentativa de atualização do telefone durou mais de 5 minutos (300 segundos) e pelo menos 10 minutos (600 segundos) se passaram desde a última tentativa de ressincronização.
$UPGTMR gt 300 and $PRVTMR ge 600Ressincronize em um horário específico
O parâmetro Resync_At permite que o telefone seja ressincronizado em um horário específico. Esse parâmetro usa o formato de 24 horas (hhmm) para especificar a hora.
O parâmetro Resync_At_Random_Delay permite que o telefone seja ressincronizado com um atraso de tempo não especificado. Esse parâmetro usa um formato inteiro positivo para especificar a hora.
Deve ser evitado inundar o servidor com solicitações de ressincronização de vários telefones configurados para ressincronizar ao mesmo tempo. Para fazer isso, o telefone aciona a ressincronização até 10 minutos após o horário especificado.
Por exemplo, se você definir o horário de ressincronização como 1000 (10h), o telefone acionará a ressincronização a qualquer momento entre 10h e 10h10.
Por padrão, esse recurso está desativado. Se o parâmetro Resync_At for provisionado, o parâmetro Resync_Periodic será ignorado.
Horários configuráveis
Você pode configurar programações para ressincronizações periódicas e especificar os intervalos de repetição para falhas de ressincronização e upgrade usando estes parâmetros de provisionamento:
-
Resync_Periodic
-
Erro_resincronização_retenta_atraso
-
Upgrade_Error_Retry_Delay
Cada parâmetro aceita um único valor de atraso (segundos). A nova sintaxe estendida permite uma lista separada por vírgulas de elementos de atraso consecutivos. O último elemento na sequência é implicitamente repetido para sempre.
Opcionalmente, você pode usar um sinal de mais para especificar outro valor numérico que acrescente um atraso extra aleatório.
Exemplo 1
Neste exemplo, o telefone é sincronizado periodicamente a cada 2 horas. Se ocorrer uma falha de ressincronização, o dispositivo tentará novamente nos seguintes intervalos: 30 minutos, 1 hora, 2 horas, 4 horas. O dispositivo continua tentando em intervalos de 4 horas até que seja ressincronizado com êxito.
Resync_Periodic=7200
Resync_Error_Retry_Delay=1800,3600,7200,14400
Exemplo 2
Neste exemplo, o dispositivo ressincroniza periodicamente a cada hora (além de um atraso aleatório extra de até 10 minutos). No caso de uma falha de ressincronização, o dispositivo tenta novamente nos seguintes intervalos: 30 minutos (mais até 5 minutos). 1 hora (mais até 10 minutos), 2 horas (mais até 15 minutos). O dispositivo continua testando em intervalos de 2 horas (mais até 15 minutos) até que seja ressincronizado com êxito.
Resync_Periodic=3600+600
Resync_Error_Retry_Delay=1800+300,3600+600,7200+900
Exemplo 3
Neste exemplo, se uma tentativa de atualização remota falhar, o dispositivo repetirá a atualização em 30 minutos, depois de mais uma hora e depois em duas horas. Se a atualização ainda falhar, o dispositivo tentará novamente a cada quatro a cinco horas até que a atualização seja bem-sucedida.
Upgrade_Error_Retry_Delay = 1800,3600,7200,14400+3600
Regras de perfil
O telefone fornece vários parâmetros de perfil de configuração remota (Profile_Rule*). Assim, cada operação de ressincronização pode recuperar vários arquivos gerenciados por diferentes servidores.
No cenário mais simples, o dispositivo é sincronizado periodicamente com um único perfil em um servidor central, que atualiza todos os parâmetros internos pertinentes. Como alternativa, o perfil pode ser dividido entre arquivos diferentes. Um arquivo é comum a todos os telefones em uma implantação. Um arquivo separado e exclusivo é fornecido para cada conta. As chaves de criptografia e as informações do certificado podem ser fornecidas por outro perfil, armazenado em um servidor separado.
Sempre que ocorre uma operação de ressincronização, o telefone avalia os quatro parâmetros Profile_Rule* em sequência:
-
Profile_Rule
-
Perfil _Rule_B
-
Perfil _Rule_C
-
Perfil _Rule_D
Cada avaliação pode resultar na recuperação do perfil de um servidor de provisionamento remoto, com uma possível atualização de alguns parâmetros internos. Se uma avaliação falhar, a sequência de ressincronização será interrompida e repetida novamente a partir do início especificado pelo parâmetro Resync_Error_Retry_Delay (segundos). Se todas as avaliações forem bem-sucedidas, o dispositivo aguardará a segunda especificada pelo parâmetro Resync_Periodic e, em seguida, executará outra ressincronização.
O conteúdo de cada parâmetro Profile_Rule* consiste em um conjunto de alternativas. As alternativas são separadas pelo caractere | (pipe). Cada alternativa consiste em uma expressão condicional, uma expressão de atribuição, uma URL de perfil e qualquer opção de URL associada. Todos esses componentes são opcionais em cada alternativa. A seguir estão as combinações válidas e a ordem em que elas devem aparecer, se presentes:
[ conditional-expr ] [ assignment-expr ] [[ options ] URL ]
Em cada parâmetro Profile_Rule*, todas as alternativas, exceto a última, devem fornecer uma expressão condicional. Essa expressão é avaliada e processada da seguinte forma:
-
As condições são avaliadas da esquerda para a direita, até que seja encontrada uma que seja avaliada como verdadeira (ou até que uma alternativa seja encontrada sem expressão condicional).
-
Qualquer expressão de atribuição anexa é avaliada, se presente.
-
Se um URL for especificado como parte dessa alternativa, será feita uma tentativa de baixar o perfil localizado no URL especificado. O sistema tenta atualizar adequadamente os parâmetros internos.
Se todas as alternativas tiverem expressões condicionais e nenhuma for avaliada como verdadeira (ou se toda a regra de perfil estiver vazia), todo o parâmetro Profile_Rule* será ignorado. O próximo parâmetro da regra de perfil na sequência é avaliado.
Exemplo 1
Este exemplo ressincroniza incondicionalmente com o perfil na URL especificada e executa uma solicitação HTTP GET para o servidor de provisionamento remoto:
http://remote.server.com/cisco/$MA.cfg
Exemplo 2
Neste exemplo, o dispositivo ressincroniza com dois URLs diferentes, dependendo do estado do registro da Linha 1. Em caso de perda do registro, o dispositivo executa um HTTP POST em um script CGI. O dispositivo envia o conteúdo da macro GPP_A expandida, que pode fornecer informações adicionais sobre o estado do dispositivo:
($PRVTMR ge 600)? http://p.tel.com/has-reg.cfg
| [--post a] http://p.tel.com/lost-reg?
Exemplo 3
Neste exemplo, o dispositivo é sincronizado novamente com o mesmo servidor. O dispositivo fornece informações adicionais se um certificado não estiver instalado na unidade (para unidades antigas pré-2.0):
(“$CCERT” eq “Installed”)? https://p.tel.com/config?
| https://p.tel.com/config?cisco$MAU
Exemplo 4
Neste exemplo, a Linha 1 é desativada até que GPP_A seja definido como Provisionado por meio da primeira URL. Depois, ele ressincroniza com o segundo URL:
(“$A” ne “Provisioned”)? (Line_Enable_1_ = “No”;)! https://p.tel.com/init-prov
| https://p.tel.com/configs
Exemplo 5
Neste exemplo, supõe-se que o perfil que o servidor retorna contenha marcas de elementos XML. Essas tags devem ser remapeadas para nomes de parâmetros adequados pelo mapa de aliases armazenado em GPP_B:
[--alias b] https://p.tel.com/account/$PN$MA.xml
Normalmente, uma ressincronização é considerada malsucedida se um perfil solicitado não for recebido do servidor. O parâmetro Resync_Fails_on_FNF pode substituir esse comportamento padrão. Se Resync_fails_on_fnf estiver definido como Não, o dispositivo aceitará uma resposta de arquivo não encontrado do servidor como uma ressincronização bem-sucedida. O valor padrão para Resync_Fails_on_FNF é Sim.
Regra de atualização
A regra de atualização é dizer ao dispositivo para ativar uma nova carga e de onde obter a carga, se necessário. Se a carga já estiver no dispositivo, ele não tentará obtê-la. Portanto, a validade do local de carregamento não importa quando a carga desejada está na partição inativa.
A Upgrade_Rule especifica uma carga de firmware que, se for diferente da carga atual, será baixada e aplicada, a menos que seja limitada por uma expressão condicional ou que Upgrade_Enable seja definida como Não.
O telefone fornece um parâmetro de atualização remota configurável, Upgrade_Rule. Esse parâmetro aceita sintaxe semelhante aos parâmetros da regra de perfil. As opções de URL não são suportadas para atualizações, mas expressões condicionais e expressões de atribuição podem ser usadas. Se expressões condicionais forem usadas, o parâmetro poderá ser preenchido com várias alternativas, separadas pelo caractere |. A sintaxe de cada alternativa é a seguinte:
[ conditional-expr ] [ assignment-expr ] URL
Como no caso dos parâmetros Profile_Rule*, o parâmetro Upgrade_Rule avalia cada alternativa até que uma expressão condicional seja satisfeita ou uma alternativa não tenha nenhuma expressão condicional. A expressão de atribuição anexa é avaliada, se especificada. Em seguida, uma atualização para o URL especificado é tentada.
Se a Upgrade_Rule contiver uma URL sem uma expressão condicional, o dispositivo será atualizado para a imagem de firmware especificada pela URL. Após a expansão da macro e a avaliação da regra, o dispositivo não tenta atualizar novamente até que a regra seja modificada ou a combinação efetiva de esquema + servidor + porta + caminho de arquivo seja alterada.
Para tentar uma atualização de firmware, o dispositivo desativa o áudio no início do procedimento e reinicia no final do procedimento. O dispositivo inicia automaticamente uma atualização que é impulsionada pelo conteúdo de Upgrade_Rule somente se todas as linhas de voz estiverem inativas no momento.
Por exemplo,
https://10.73.10.223/firmware/PHONEOS-8875.1-0-1-0001-1.loadsNeste exemplo, o Upgrade_Rule atualiza o firmware para a imagem armazenada na URL indicada.
Aqui está outro exemplo:
(“$F” ne “beta-customer”)? http://p.tel.com/firmware/PHONEOS-8875.1-0-1-0001-1.loads
| http://p.tel.com/firmware/PHONEOS-8875.1-0-1-0001-1.loads
Esse exemplo direciona a unidade para carregar uma das duas imagens, com base no conteúdo de um parâmetro de uso geral, GPP_F.
Parâmetros de provisionamento
Você pode encontrar os parâmetros de provisionamento na guia Provisionamento na página da web do telefone.
Parâmetros do perfil de configuração
A tabela a seguir define a função e o uso de cada parâmetro na seção Parâmetros do Perfil de Configuração na guia Provisionamento.
|
Nome do parâmetro |
Descrição e valor padrão |
|---|---|
|
Ativar provisionamento |
Controla todas as ações de ressincronização, independentemente das ações de atualização do firmware. Defina como Sim para ativar o provisionamento remoto. O valor padrão é Sim. |
|
Ressincronizar na reinicialização |
Aciona uma ressincronização após cada reinicialização, exceto nas reinicializações causadas por atualizações de parâmetros e upgrades de firmware. O valor padrão é Sim. |
|
Atraso aleatório de ressincronização |
Um atraso aleatório após a sequência de inicialização antes de realizar a reinicialização, especificado em segundos. Em um pool de dispositivos de telefonia IP programados para serem ativados simultaneamente, isso introduz uma dispersão nos horários em que cada unidade envia uma solicitação de ressincronização ao servidor de provisionamento. Esse recurso pode ser útil em uma grande implantação residencial, no caso de uma falha de energia regional. O valor desse campo deve ser um número inteiro variando entre 0 e 65535. O valor padrão é 2. |
|
Ressincronizar em (HHmm) |
A hora (hHmm) em que o dispositivo se ressincroniza com o servidor de provisionamento. O valor desse campo deve ser um número de quatro dígitos que varia de 0000 a 2400 para indicar a hora no formato HHmm. Por exemplo, 0959 indica 09:59. O valor padrão é vazio. Se o valor for inválido, o parâmetro será ignorado. Se esse parâmetro for definido com um valor válido, o parâmetro Resync Periodic será ignorado. |
|
Ressincronizar com atraso aleatório |
Evita a sobrecarga do servidor de provisionamento quando um grande número de dispositivos é ligado simultaneamente. Para evitar a inundação de solicitações de ressincronização para o servidor de vários telefones, o telefone ressincroniza no intervalo entre as horas e os minutos e as horas e os minutos mais o atraso aleatório (hhmm, hhmm+random_delay). Por exemplo, se o atraso aleatório = (Resync At Random Delay + 30) /60 minutos, o valor de entrada em segundos será convertido em minutos, arredondando para o próximo minuto para calcular o intervalo final de random_delay. O valor válido varia entre 600 e 65535. Se o valor for menor que 600, o atraso aleatório interno estará entre 0 e 600. O valor padrão é 600 segundos (10 minutos). |
|
Ressincronização periódica |
O intervalo de tempo entre as ressincronizações periódicas com o servidor de provisionamento. O cronômetro de ressincronização associado fica ativo somente após a primeira sincronização bem-sucedida com o servidor. Os formatos válidos são os seguintes:
Defina esse parâmetro como zero para desativar a ressincronização periódica. O valor padrão é 3600 segundos. |
|
Erro de ressincronização | Atraso na nova tentativa |
Se uma operação de ressincronização falhar porque o dispositivo de telefonia IP não conseguiu recuperar um perfil do servidor, se o arquivo baixado estiver corrompido ou ocorrer um erro interno, o dispositivo tentará ressincronizar novamente após um tempo especificado em segundos. Os formatos válidos são os seguintes:
Se o atraso for definido como 0, o dispositivo não tentará ressincronizar novamente após uma falha na tentativa de ressincronização. |
|
Atraso de ressincronização forçada |
Atraso máximo (em segundos) que o telefone espera antes de realizar uma ressincronização. O dispositivo não ressincroniza enquanto uma de suas linhas telefônicas está ativa. Como a ressincronização pode levar vários segundos, é desejável esperar até que o dispositivo fique inativo por um longo período antes de ressincronizar. Isso permite que um usuário faça chamadas em sucessão sem interrupção. O dispositivo tem um cronômetro que começa a contagem regressiva quando todas as linhas ficam ociosas. Esse parâmetro é o valor inicial do contador. Os eventos de ressincronização são adiados até que esse contador diminua para zero. O valor válido varia entre 0 e 65535. O valor padrão é 14.400 segundos. |
|
Ressincronizar a partir do SIP |
Permite que uma ressincronização seja acionada por meio de uma mensagem SIP NOTIFY. O valor padrão é Sim. |
|
Ressincronizar após tentativa de atualização |
Ativa ou desativa a operação de ressincronização após a ocorrência de qualquer atualização. Se a opção Sim for selecionada, a sincronização será acionada. O valor padrão é Sim. |
|
Acionador de ressincronização 1, acionador de ressincronização 2 |
Condições de gatilho de ressincronização configuráveis. Uma ressincronização é acionada quando a equação lógica nesses parâmetros é avaliada como VERDADEIRA. O valor padrão é (vazio). |
|
A ressincronização falha no FNF |
Uma ressincronização é considerada malsucedida se um perfil solicitado não for recebido do servidor. Isso pode ser substituído por esse parâmetro. Quando definido como não, o dispositivo aceita uma resposta O valor padrão é Sim. |
|
Regra de perfil Regra de perfil B Regra de perfil C Regra de perfil D |
Cada regra de perfil informa ao telefone uma fonte da qual obter um perfil (arquivo de configuração). Durante cada operação de ressincronização, o telefone aplica todos os perfis em sequência. Padrão:
Opcionalmente, você pode colocar a chave de criptografia entre aspas duplas (“). |
|
Opção DHCP a ser usada |
Opções de DHCP, delimitadas por vírgulas, usadas para recuperar firmware e perfis. O valor padrão é 66.160.159.150.60,43.125. |
|
Mensagem de solicitação de registro |
Esse parâmetro contém a mensagem que é enviada ao servidor syslog no início de uma tentativa de ressincronização. O valor padrão é |
|
Mensagem de sucesso do log |
A mensagem de syslog que é emitida após a conclusão bem-sucedida de uma tentativa de ressincronização. O valor padrão é |
|
Mensagem de falha de registro |
A mensagem de syslog emitida após uma falha na tentativa de ressincronização. O valor padrão é |
|
Ressincronização configurável pelo usuário |
Permite que um usuário ressincronize o telefone a partir da tela do telefone IP. O valor padrão é Sim. |
Parâmetros de atualização do firmware
A tabela a seguir define a função e o uso de cada parâmetro na seção Atualização de firmware da guia Provisionamento.
|
Nome do parâmetro |
Descrição e valor padrão |
|---|---|
|
Habilitar atualização |
Permite operações de atualização de firmware independentemente das ações de ressincronização. O valor padrão é Sim. Configure esse parâmetro com um dos métodos:
|
|
Erro de atualização | Atraso na tentativa |
O intervalo de novas tentativas de upgrade (em segundos) aplicado em caso de falha no upgrade. O dispositivo tem um temporizador de erro de atualização do firmware que é ativado após uma tentativa falhada de atualização do firmware. O cronômetro é inicializado com o valor nesse parâmetro. A próxima tentativa de atualização do firmware ocorre quando esse cronômetro faz a contagem regressiva até zero. O valor padrão é 3600 segundos. Configure esse parâmetro com um dos métodos:
|
|
Regra de atualização |
Um script de atualização de firmware que define as condições de atualização e os URLs de firmware associados. Ele usa a mesma sintaxe da regra de perfil. Use o formato a seguir para inserir a regra de atualização:
Por exemplo: Se nenhum protocolo for especificado, o TFTP será assumido. Se nenhum nome de servidor for especificado, o host que solicita a URL será usado como nome do servidor. Se nenhuma porta for especificada, a porta padrão será usada (69 para TFTP, 80 para HTTP ou 443 para HTTPS). O valor padrão está em branco. Configure esse parâmetro com um dos métodos:
|
|
Mensagem de solicitação de atualização de log |
Mensagem de syslog emitida no início de uma tentativa de atualização de firmware. Padrão: Configure esse parâmetro com um dos métodos:
|
|
Mensagem de sucesso da atualização do log |
Mensagem de syslog emitida após a conclusão bem-sucedida de uma tentativa de atualização de firmware. O valor padrão é Configure esse parâmetro com um dos métodos:
|
|
Mensagem de falha na atualização do log |
Mensagem de syslog emitida após uma falha na tentativa de atualização do firmware. O valor padrão é Configure esse parâmetro com um dos métodos:
|
|
Compartilhamento de firmware entre pares |
Ativa ou desativa o recurso Peer Firmware Sharing (PFS). Selecione Sim ou Não para ativar ou desativar o recurso. Padrão: Sim Configure esse parâmetro com um dos métodos:
|
|
Servidor de log de compartilhamento de firmware entre pares |
Indica o endereço IP e a porta para a qual a mensagem UDP é enviada. Por exemplo: 10.98.76. 123:514 em que 10.98.76.123 é o endereço IP e 514 é o número da porta. Configure esse parâmetro com um dos métodos:
|
Parâmetros de uso geral
A tabela a seguir define a função e o uso de cada parâmetro na seção Parâmetros de uso geral da guia Provisionamento.
|
Nome do parâmetro |
Descrição e valor padrão |
|---|---|
|
GPP A - GPP P |
Os parâmetros de uso geral GPP_* são usados como registros de strings gratuitos ao configurar os telefones para interagir com uma solução específica de servidor de provisionamento. Eles podem ser configurados para conter diversos valores, incluindo os seguintes:
O valor padrão está em branco. |
Variáveis de expansão macro
Algumas variáveis macro são reconhecidas nos seguintes parâmetros de provisionamento:
-
Profile_Rule
-
Regra_de_perfil _*
-
Resync_Trigger_*
-
Upgrade_Rule
-
Registro_*
-
GPP_* (sob condições específicas)
Dentro desses parâmetros, os tipos de sintaxe, como $NAME ou $ (NAME), são reconhecidos e expandidos.
Subcadeias de variáveis macro podem ser especificadas com a notação $ (Name:p) e $ (Name:p:q), em que p e q são números inteiros não negativos (disponíveis na revisão 2.0.11 e superior). A expansão da macro resultante é a substring começando no deslocamento de caracteres p, com comprimento q (ou então até o final da string se q não for especificado). Por exemplo, se GPP_A contiver ABCDEF, $ (A:2) se expandirá para CDEF e $ (A: 2:3) se expandirá para CDE.
Um nome não reconhecido não é traduzido e o formulário $NAME ou $ (NAME) permanece inalterado no valor do parâmetro após a expansão.
|
Nome do parâmetro |
Descrição e valor padrão |
|---|---|
|
$ |
O formulário $$ se expande para um único caractere $. |
|
De A a P |
Substituído pelo conteúdo dos parâmetros de uso geral GPP_A a GPP_P. |
|
SA a SD |
Substituídos por parâmetros de propósito especial GPP_SA a GPP_SD. Esses parâmetros contêm chaves ou senhas usadas no provisionamento. $SA a $SD são reconhecidos como argumentos para o qualificador opcional de URL de ressincronização, --key. |
|
MA |
Endereço MAC usando dígitos hexadecimais minúsculos, por exemplo, 000e08aabbcc. |
|
MAU |
Endereço MAC usando dígitos hexadecimais maiúsculos, por exemplo 000E08AABBCC. |
|
MAC |
Endereço MAC usando dígitos hexadecimais minúsculos e dois pontos para separar pares de dígitos hexadecimais. Por exemplo, 00:0 e:08:aa:bb:cc. |
|
PN |
Nome do produto. Por exemplo, CP-8875, DP-9851, DP-9871. |
|
PSN | Número da série do produto. Por exemplo, V03. |
|
SN |
Cadeia de caracteres do número de série. por exemplo, 88012BA01234. |
|
CCERT |
Status do certificado de cliente SSL: instalado ou não instalado. |
|
IP |
Endereço IP do telefone em sua sub-rede local. Por exemplo, 192.168.1.100. |
|
EXTIP |
IP externo do telefone, conforme visto na Internet. Por exemplo, 66.43.16.52. |
|
SWVER |
Cadeia de caracteres da versão do software Por exemplo, PHONEOS.3-1-1-0104-37 |
|
HWVER |
Sequência de caracteres da versão de hardware Por exemplo, 2.0.1 |
|
PRVST |
Estado de provisionamento (uma sequência numérica): -1 = solicitação explícita de ressincronização 0 = ressincronização de inicialização 1 = ressincronização periódica 2 = falha na ressincronização, tente novamente |
|
UPGST |
Estado da atualização (uma sequência numérica): 1 = primeira tentativa de atualização 2 = falha na atualização, tente novamente |
|
UPGERR |
Mensagem de resultado (ERR) da tentativa anterior de atualização; por exemplo, http_get falhou. |
|
PRVTMR |
Segundos desde a última tentativa de ressincronização. |
|
UPGTMR |
Segundos desde a última tentativa de atualização. |
|
REGTMR1 |
Segundos desde que a Linha 1 perdeu o registro no servidor SIP. |
|
REGTMR2 |
Segundos desde que a Linha 2 perdeu o registro no servidor SIP. |
|
UPGCOND |
Nome da macro legada. |
|
SCHEME |
Esquema de acesso a arquivos, TFTP, HTTP ou HTTPS, conforme obtido após a análise do URL de ressincronização ou atualização. |
|
SERV |
Solicite o nome do host do servidor de destino, conforme obtido após a análise do URL de ressincronização ou atualização. |
|
SERVIP |
Solicite o endereço IP do servidor de destino, conforme obtido após a análise do URL de ressincronização ou atualização, possivelmente após a pesquisa de DNS. |
|
PORT |
Solicite a porta UDP/TCP de destino, conforme obtida após a análise do URL de ressincronização ou atualização. |
|
PATH |
Solicite o caminho do arquivo de destino, conforme obtido após a análise do URL de ressincronização ou atualização. |
|
ERR |
Mensagem de resultado da tentativa de ressincronização ou atualização. Útil apenas na geração de mensagens de syslog de resultados. O valor é preservado na variável UPGERR no caso de tentativas de atualização. |
|
UIDN |
O conteúdo do parâmetro de configuração Line n UserID. |
|
EMS |
Extension MobilityStatus |
|
MUID |
Extension MobilityID de usuário |
|
MPWD |
Extension MobilitySenha |
Códigos de erro internos
O telefone define vários códigos de erro internos (X00—X99) para facilitar a configuração e fornecer um controle mais preciso sobre o comportamento da unidade sob determinadas condições de erro.
|
Nome do parâmetro |
Descrição e valor padrão |
|---|---|
|
X00 |
Erro na camada de transporte (ou ICMP) ao enviar uma solicitação SIP. |
|
X20 |
A solicitação SIP atinge o tempo limite enquanto espera por uma resposta. |
|
X40 |
Erro geral do protocolo SIP (por exemplo, codec inaceitável no SDP em mensagens 200 e ACK ou expira enquanto espera pelo ACK). |
|
X60 |
Número discado inválido de acordo com o plano de discagem fornecido. |
