Asterisk Presence
Fonte: http://www.voip-info.org/wiki/view/Asterisk+presence e http://www.voip-info.org/wiki/view/Asterisk+standard+extensions, em 12/12/2007
O CVS-HEAD atual fornece algum suporte ao “SIP Presence” conforme definido na RFC 3856 – Um Pacote sobre “Presence Event” do Session Initiation Protocol (SIP). A liberação da versão Asterisk (1.0.9) tem algum suporte também.
SIP Presence tem tudo a ver com o que já foi dito aqui sobre Appearance. É o mecanismo intrínseco do próprio SIP para monitorar estado/situação (se ringando, disponível, indisponível, na espera, ocupado) de outros usuários do sistema que seja do interesse de um determinado usuário.
Para suportar tal recurso, de alguma forma, você precisa dizer para qual extensão o usuário SIP é mapeado para se ter monitoração do seu estado. A prioridade "hint" é usada para descrever isso, como neste exemplo:
exten => 100,hint,SIP/peername
(Isso diz que, para os propósitos de “SIP Presence”, a ‘presença’ de atividade da extensão 100 deve ser mapeado para o peer SIP).
- IMPORTANTE: No Asterisk 1.4, o mecanismo intrínseco da funcionalidade hint foi um tanto alterado. Agora é imperativo que você defina um limite de chamada (call-limit) (mesmo que ele seja um valor arbitrariamente alto como 100) e/ou novo limitonpeers=valor no arquivo sip.conf. O recurso de Presence não vai funcionar sem isso. Se você estiver usando o parâmetro type igual à friend em vez de peer, você vai necessitar fazer limitonpeers=yes, bem como uma declaração de limite de chamada (call-limit) para cada um dos dispositivos SIP;
- Se você não adicionar uma prioridade ‘hint’, a extensão vai ficar sempre livre ("aberta"), mais ou menos;
- Se você adicionar incominglimit=1 ao peer que está monitorado o status no arquivo sip.conf, o canal SIP vai notificá-lo quando essa extensão estiver ocupada (busy).
Prioridade Padrão hint
• A prioridade 'hint' associa uma extensão com um canal Asterisk para os propósitos de mapeamento do estado do canal para um estado da extensão.
No Asterisk, um canal (tecnologia/dispositivo) pode ter vários estados (indisponível, em uso, ocupado, tocando, etc), contudo uma extensão é apenas um rótulo para uma seqüência de comandos. No entanto, quando ocorre a troca de comunicação sobre informação de status do canal para um dispositivo externo, como, por exemplo, uma console de recepcionista, você não consegue usar os nomes de canais internos do Asterisk, mas precisa usar externamente um nome identificável de recurso, tipicamente o número de extensão.
Um dispositivo então vai se inscrever para obter o estado da extensão de interesse e iria receber as notificações de status do canal que dar suporte a tecnologia. Isso é usado no canal SIP (implementado via os mecanismos SUBSCRIBE/NOTIFY da RFC-3265) para acender os led´s de sinalização de status correspondentes dispostos sobre os telefones SIP que fica monitorando as atividades de um ramal/usuário/peer.
Isso é suportado em telefones SNOM (veja também) com suas teclas programáveis definida para o tipo "destination", bem como em telefones Polycom (500/600), Aastra (480i, 9133i) e Sayson. Também é suportado nos Gateways Handset SIP da Citel.
Considerações de Privacidade: No arquivo sip.conf você pode definir um subscribecontext=valor que determina em qual contexto o Asterisk deve procurar pela extensão correspondente quando uma requisição subscribe é recebida do telefone; contudo, se a extensão não existir neste contexto, o Asterisk vai procurá-la no contexto default! Em outras palavras: todos podem inscrever-se (subscribe) a uma extensão com prioridade "hint" que estiver definida no contexto default. A propósito, especificando um subscribecontext vazio é também uma idéia boa se o telefone não deve inscrever-se de forma alguma a nenhum contexto.
Da mesma forma, o patch/bug 5515 (pós Asterisk 1.2.0) adiciona suporte a devstate também no MGCP (até o momento o SIP, o IAX e o ZAP são os canais suportados; "show channeltypes" lhe diz quais canais no seu Asterisk suportam notificação de status de dispositivo). Uma questão: Esse patch mostra somente um dispositivo que está indisponível (por exemplo, desconectado), ou ele também mostra "busy"? Resposta: também mostra "busy" (em uso).
Também, chan_capi-cm v0.6.2 e liberações posteriores vem com suporte básico a hint. Parece, contudo, que a nomeação dinâmica de canais CAPI que inclui o número chamado faz que a monitoração de uma linha CAPI para ligações saintes seja praticamente impossível – pelo menos por agora.
Nota: Os patches Bristuff de terceiros vem com a app_devstate que permite a manipulação de estado através do dialplan.
Novidade: No Asterisk 1.6 será incluído a função func_devstate nativamente, também já existe agora um backport disponível para o Asterisk 1.4. Ele é totalmente similar ao app_devstate porque ele parte dos patches bristuff.
Comandos CLI úteis para fazer debug são:
"sip show subscriptions", "show hints", "show channeltypes" e "sip show inuse".
Exemplo 1:
exten => 200,hint,SIP/phone1 ; this is case sensitive (!) in 1.0.9 and 1.2.0
exten => 200,1,Macro(stdexten,SIP/phone1)
Exemplo 2: Se você deseja monitorar o estado de múltiplos telefones usando alguma speeddial, você pode fazer assim:
exten => 200,hint,SIP/201&SIP/202&SIP/203
O Asterisk fornece uma sintaxe para permitir que mais de um canal seja mapeado para qualquer extensão particular através do mecanismo hint.
Exemplo 3: Monitorar Ligações Estacionadas (Callpark) (Asterisk 1.4 e mais recente):
include => parkedcalls
exten => 701,1,ParkedCall(701)
exten => 701,hint,park:701@parkedcalls
Extensão e estado de dispositivo combinado, sem estado de usuário!
O Asterisk – com ou sem o patch – não suporta atualmente o método PUBLISH para divulgação de documentos de presence no formato Presence Information Data Format (PIDF) definido na RFC 3863, mas ele pode gerar notificação (NOTIFY) dos usuários monitorados (SUBSCRIBEd) quando ocorre o REGISTER e também quando o cliente desconecta.
Isso funciona, por exemplo, com o cliente Eyebeam da Xten, mas pode também funcionar com vários outros telefones que suportam SIP Presence. Devido à falta de suporte ao método PUBLISH, não existe qualquer suporte aos estados estendidos (Away, Do not disturb, Busy). Você pode se inscrever para estado de extensão para qualquer canal que suporte notificação de estado de dispositivo. No CVS head, o canal Agent, SIP e IAX2 suporta isso.
A fim de resolver, nós precisamos de uma abstração de usuário no Asterisk, algo que foi sanado na versão de desenvolvimento 1.3.
Telefones que é sabido funcionar com a implementação atual do SIP Presence no Asterisk
• Snom (vários modelos)
• Polycom IP30x/IP50x/IP600
• Xten EyeBeam
• Grandstream GXP2000 (Firmware >= 1.0.1.13)
• Aastra 480i
• Aastra 9133i
• Thomson ST2030
• Linksys SPA962/932 - Tutorial
Configuração Específica Telefone (Telefones Polycom)
Para ativar tronca de informações de presença no telefones Polycom, você precisa adicionar um conato ao diretório contato. O parâmetro CONTACT precisa bater com extensão do telefone que você deseja monitorar e o parâmetro WATCH BUDDY precisa ser definido como "enabled". Também, assegure que a primeira linha do Polycom seja registrada com o seu servidor Asterisk. A Polycom tende a usar a configuração da primeira linha para todas as requisições de subscriptions.
Com o SIP v1.5.2, os telefones Polycom podem "esquecer" da sua subscrição para informação de presença, e retornar um erro 450 de notificação de Presence. Não existe indicação no telefone de que isso aconteceu, exceto que o status de buddy não mais muda. A única forma de contornar isso é rebootar o telefone ou chaveando o parâmetro WATCH BUDDY para disabled, e em seguida para enabled. Esse bug não afeta outras operações do telefone.
Obs.: Existe um limite quoted de 8 (Eu encontrei um limite real de 7) watchable buddies, assim se você for comprar a solução de console para atendente, não espere que vá conseguir monitorar mais do que 7 outras extensões (ramais). (veja abaixo).
Obs.: Quando da versão do firmware 1.6.6, o limite foi aumentado no modelo 601 para 48 watchable buddies. Ainda é de 8 nos aparelhos 501. Valeu Polycom!
Estacionamento e BLF
Isso pode ser realizado no asterisk 1.2 com um patch e está embutido no asterisk 1.4.
Estacionamento BLF no Asterisk 1.2
• Patch/bug 5779 adicionou suporte hint na construção do canal Local que permite a monitoração de ligações estacionadas (parking lot/ parked) verificando a existência de uma extensão no dialplan.
• OBS.: A fim de configurar um estacionamento com BLF com esse patch no Asterisk 1.2.X, você precisa configurar o fragmento seguinte no contexto onde seu telefone SIP se registra:
exten => 701,1,ParkedCall(701)
exten => 701,hint,Local/701@ParkedCalls
Estacionamento com BLF no Asterisk 1.4
• OBS.: A fim de configurar a funcionalidade embutida de estacionamento com BLF no Asterisk 1.4, você precisa definir a seguinte coisa no contexto onde seu telefone SIP se registra...
include => parkedcalls
exten => 701,1,ParkedCall(701)
exten => 701,hint,park:701@parkedcalls
Isso difere da sintaxe originalmente descrita no relato do patch/bug para a versão 1.2 acima. Se você está usando o patch do metermaid com o Asterisk 1.2.X e decidir atualizar para 1.4 esperando que ele 'apenas funcione' você fica para um cruel e pobremente documentado surpresa.
Atualização para o Asterisk 1.6 (em desenvolvimento)
Russel da Digium implementou uma função DEVSTATE que está descrito aqui em mais detalhes. Existe uma nova versão que funciona com o Asterisk 1.4 aqui.
Mensagens de Presença atravessando os PABX’s
Nuitari escreveu um script PHP que se conecta ao manager de múltiplos PABX’s e usa devastate do Russel (Digium) para definir o BLF ao longo dos PABX’s. Você pode encontrá-lo aqui.
Nenhum comentário:
Postar um comentário