BRPI9904366B1 - Dispositivo de radiocomunicação e método com api entre o programa de aplicação de usuário e o programa de telefonia e método - Google Patents

Description

DISPOSITIVO DE RADIOCOMUNICAÇÃO E MÉTODO DE ESTABELECER UMA CHAMADA DE MODO DUPLO EM UM DISPOSITIVO DE RADIOCOMUNICAÇÃO

CAMPO DA INVENÇÃO A presente invenção refere-se a um dispositivo de radiocomunicação tendo um programa de aplicação de usuário (comumente mencionado como uma aplicação ou applet) e um programa de telefonia (por exemplo, um exemplo de uma classe de telefonia) e uma interface de programação de aplicação (API) entre o programa de aplicação de usuário e o programa de telefonia. A invenção refere-se a aspectos da API e refere-se a um método invocado através da API, por exemplo um método para estabelecer uma chamada de modo duplo.

FUNDAMENTOS DA INVENÇÃO

Linguagens de programa orientado a objetos como JAVA (TM) são cada vez mais populares em mais e mais dispositivos devido à portabilidade de programas através de plataformas, sistemas operacionais e dispositivos. Isto significa que um programa desenvolvido para um dispositivo é mais facilmente utilizado em outro dispositivo de características diferentes, por exemplo, sistemas operacionais diferentes ou microprocessadores diferentes.

Esta popularidade de programas orientados a objetos está se estendendo para dispositivos que são significativamente menores em termos de tamanho de memória e potência de processamento do que computadores pessoais tradicionais e outras plataformas nas quais tais linguagens estão em uso difundido. Surgiram problemas ao tentar utilizar linguagens de orientação a objetos como JAVA (TM) em plataformas muito pequenas por diversos motivos. Um exemplo de um problema situa-se na necessidade de suportar um conjunto completo de classes de objeto, onde um objeto é um programa de computado independente o qual interage com outros programas em um modo definido, e onde uma classe é um gabarito genérico para um conjunto de objetos com características similares. Um problema é que para se manter a portabilidade de programas através de plataformas diferentes, a uniformidade necessita estar presente nas classes que qualquer aplicação dada espera ser capaz de invocar. Por exemplo, pJava (TM) tem um conjunto muito grande de bibliotecas de classe e esforços estão sendo feitos para se definir uma linguagem menor a ser denominada "eJava" (TM) utilizando apenas um subconjunto do conjunto completo de bibliotecas de classe.

Um exemplo de uma classe é uma classe de telefonia que é invocada através de uma API de telefonia Java (TM) (JTAPI). Um exemplo de tal classe podería ser denominado uma "implementação JTAPI".

JTAPI é uma interface de programação de aplicação orientada a objetos, portável, para aplicações de telefonia-computador baseadas em JAVA (TM) descritos no seguinte localizador de recurso universal na rede mundial:www.javasoft.com/products/JTAPI/index.html. A API de Telefonia JAVA (TM) suporta os domínios tanto de aplicação de telefonia tanto de primeira como terceira parte. A API é projetada para tornar fáceis aplicações simples de programação, enquanto fornece as características necessárias para aplicações de telefonia avançada. JTAPI é um conjunto de APIs. Há um "núcleo" API que fornece um modelo de chamada básico e características de telefonia rudimental, como fazer chamadas telefônicas e atender chamadas telefônicas. 0 núcleo API é circundado por APIs de extensão padrão fornecendo funcionalidade para domínios de telefonia específicos como centros de chamada e acesso de fluxo de meio. As aplicações escritas utilizando JTAPI são portáveis através de várias plataformas de computador e sistemas telefônicos. A versão 1.2 da JTAPI foi liberada ao público em dezembro de 1997.

Um exemplo de uso da JTAPI está em uma configuração de rede onde a aplicação JTAPI ou applet JAVA (TM) opera em uma estação remota, como um computador de rede com apenas uma tela, teclado, processador e alguma memória. Este computador acessa recursos de rede, fazendo uso de um servidor centralizado que gerencia os recursos de telefonia. A JTAPI comunica-se com este servidor através de um mecanismo de comunicação remota, como a invocação de método remoto (RMI) de Java (TM) ou um protocolo de telefonia. A API de telefonia Java (TM) é composta de um conjunto de pacotes de linguagem JAVAM (TM) . Cada pacote fornece uma parte de funcionalidade para um certo aspecto de aplicações de telefonia-computador. As implementações de servidores de telefonia escolhem os pacotes que suportam, dependendo dos recursos de seu hardware para plataforma subjacente. As aplicações podem indagar pelos pacotes suportados pela implementação que estão atualmente utilizando. Adicionalmente, os desenvolvedores de aplicação podem se preocupar apenas com os pacotes suportados de que as aplicações necessitam para realizar uma tarefa. Por exemplo, um pacote de chamada permite que os projetistas de applet acrescentem recursos telefônicos a uma página da Web, enquanto diversos pacotes de extensão padrão estendem o pacote básico JTAPI. Estes pacotes de extensão trazem funcionalidade de telefonia adicional à API, como por exemplo pacotes de controle total, centro de chamadas, meios, telefone, dados privados e recursos.

Seria desejável utilizar-se uma API de telefonia padrão como JTAPI como API de telefonia para um radiotelefone ou outro dispositivo de radiocomunicação.

Diversos problemas dificultam o uso da JTAPI como API de telefonia para um dispositivo de comunicação sem fio, e em particular como API de telefonia para radiotelefones do Sistema Global para Móvel (GSM). Em geral, a JTAPI ainda sofre da carga de ter mais de 63 classes de eventos com um tamanho de arquivo de classe total de aproximadamente 130k bytes. Isto representa uma alocação substancial de memória para um elemento relativamente pequeno de um programa global para um radiotelefone. Há a necessidade de se reduzir a exigência de memória para programas compatíveis com JTAPI.

No contexto de um dispositivo de comunicação GSM, há funções GSM que não podem ser facilmente acessadas utilizando-se assinaturas de método e sintaxe JTAPI existentes. Além disso, há a necessidade de suportar uma chamada de modo duplo (termo utilizado em GSM para uma chamada de fax e voz ou uma chamada de dados e voz) e o conceito de chamada de modo duplo é desconhecido em telefonia de linha telefônica e em JTAPI. A simples adição à JTAPI ou redução da JTAPI não fornece soluções satisfatórias, porque a adição à JTAPI aumenta a necessidade de encontrar classes de eventos, e a redução da JTAPI elimina o benefício de uma API padrão que permite portabilidade de aplicações através de plataformas.

Por conseguinte, há necessidade de uma API de telefonia para um dispositivo de radiocomunicação e classes associadas que ocupe um mínimo e memória e suporte características que são únicas da radiotelefonia.

BREVE DESCRIÇÃO DOS DESENHOS A figura 1 mostra um exemplo de um dispositivo de radiotelefone de acordo com uma primeira modalidade da invenção. A figura 2 mostra um exemplo de um dispositivo de radiotelefone de acordo com uma segunda modalidade da invenção. A figura 3 é um diagrama de arquitetura de software que ilustra a estrutura de software ou qualquer um dos radiotelefones da figura 1 e figura 2. A figura 4 é um fluxograma de programa que ilustra detalhes adicionais da implementação de método JTAPI da figura 3.

As figuras 5 e 6 são fluxogramas que ilustra detalhes da implementação de método JTAPI da figura 3.

As figuras 7-13 são mencionadas no Apêndice 1 que descreve JTAPI.

DESCRIÇÃO DTALHADA DOS DESENHOS

Com referência à figura 1, um radiotelefone é ilustrado em termos de camadas diferentes, com hardware na camada mais baixa e software de aplicações na camada mais elevada. 0 radiotelefone compreende um primeiro microprocessador 10 (microprocessador A) , um segundo microprocessador 11 (microprocessador B) e certo hardware RF 13. Os microprocessadores A e B são conectados um ao outro. O microprocessador B é conectado ao hardware RF 13. 0 hardware RF 13 inclui elementos de comunicação de voz 23, que incluem preferivelmente um codificador de voz, como exemplo, e elementos de comunicação de dados 24, que incluem preferivelmente um modem de dados ou modem de fax, como exemplo. 0 microprocessador tem um sistema operacional (OS) 14 como OS 9000 fornecido por Microware Systems Corporation de Des Moines, Iowa. Acima do sistema operacional é mostrada uma máquina virtual 15, como uma máquina virtual JAVA (TM) comercializada. Um programa de aplicação 16 e várias outras classes JAVA (TM) 17 operam na máquina virtual 15. Uma das classes 17 é uma implementação JTAPI 18. 0 microprocessador 11 tem software de transceptor 20 que executa funções tais como controle de chamada, enquadramento e, geralmente, manipulação de nível de byte como codificação de bloco. O software de transceptor 20 comunica-se através de uma interface de módulo provedor de serviço comum (CSPMI) 22 com o sistema operacional 14.

Como alternativa para o arranjo da figura 1, os microprocessadores A e B podem, com efeito, ser integrados em um único circuito integrado 25 como mostrado em esboço em espectro na figura 2. Nesta modalidade, o microprocessador 10, o hardware 13, o sistema operacional 14, a máquina virtual 15 e os vários elementos de software 16 - 18 são iguais à modalidade da figura 1. No lugar do microprocessador B, há um processador de sinal digital (DSP) integrado com o microprocessador 10 no circuito integrado único 25. O DSP 27 tem código DSP 28, que executa enquadramento e outras manipulações de nível de byte como codificação de bloco, enquanto outras funções de software de transceptor como controle de chamada são executadas pelo código de software de transceptor 29, operado no microprocessador 10 com o uso do sistema operacional 14. Um circuito integrado adequado 25 é o microprocessador integrado M-core (TM) e DSP comercializados por Motorola, Inc., de Schaumburg, Illinois.

Na figura 3, a aplicação 16 é mostrada (mencionada como um "applet telefônico") e a implementação de método JTAPI 18 é mostrada. Uma interface JTAPI 30 é mostrada estabelecendo a interface entre o applet telefônico 16 e a implementação do método JTAPI 18. A implementação do método JTAPI 18 controla e recebe a entrada de um transceptor de rádio como um transceptor GSM 30 sobre a CSPMI 22. O transceptor GSM 30 compreende o segundo microprocessador 11, o hardware RF 13 e o software de transceptor 20 (todos mostrados na figura 11) . O JTAPI 30 é substancialmente como descrito na especificação da JTAPI versão 1.2, que define a sintaxe ou operação de objetos de alto nível, como "Provedor" e acha-se exposto no Apêndice A. Além disso, certas operações específicas para GSM são suportadas, para as quais as seguintes semânticas específicas são agora definidas. O domínio do Provedor JTAPI é simplesmente a estação móvel (MS) . Os únicos endereços no domínio do Provedor são aqueles da MS, por exemplo, um único endereço no Domínio para um telefone de linha única.

Provider.getAddresses() retorna um conjunto de endereços para a MS, normalmente com apenas 1 entrada. Se a MS suporta múltiplas linhas e números telefônicos, o endereço primário ou padrão é a primeira entrada.

Provider.getAddress() aceita apenas o número ou números atribuídos à MS. Por padrão, o endereço primário, isto é getAddresses()[0], é retornado.

Provider.getTerminals() retorna um conjunto de Terminais suportado pela MS. Um terminal separado é definido para cada tipo de portador de chamada (vide abaixo).

Provider.getTerminals() toma uma cadeia especificando o nome do terminal. Por padrão, o Terminal de voz é retornado. Todas as implementações devem suportar VOZ, DADOS e FAX como nomes para os respectivos Terminais (vide abaixo).

Provider.createCall() criará uma chamada, mesmo se o Provedor estiver OUT OF SERVICE, desde que não tenha sido desligado. A chamada não pode ser feita com sucesso até que o Provedor esteja IN_SERVICE. Esta característica é uma mudança em relação às pré-condições da JTAPI 1.2 createCall() e é descrita abaixo em maior detalhe com referência às figuras 5 e 6.

Call.connect() analisa a cadeia de endereço de destino para códigos SS comuns e sinalizações de endereço. Se a cadeia de número de destino passada para Call. connect () começa com um caractere "+", o tipo de número (TON) é ajustado para INTERNACIONAL; de outro modo, o TON é UNKNOWN (DESCONHECIDO). Se a cadeia contiver apenas dígitos numéricos, o identificador de plano de numeração (NPI) é ISDN, de outro modo é UNKNOWN (DESCONHECIDO).

TerminalConnection.join()e TerminalConnection.leave() são utilizados para mudar modos de chamada em uma chamada de modo duplo (voz e dados ou voz e fax) . Há sempre exatamente um TerminalConnection que está ativo em uma chamada; invocar join() em outro TerminalConnection ocasiona mudança no modo de chamada e chamar leaveO no TerminalConnection ativo ativa automaticamente o modo alternado.

As aplicações podem interagir com o teor de informações da chamada utilizando a API definida para MediaTerminalConnection. Se um TerminalConnection retornado do Connection.getTerminalConnections() implementar MediaTerminalConnection, a aplicação pode utilizar os seguintes métodos: Media TerminalConnection.getMediaAvailabitily(), implementado como se acha definido na JTAPI 1.2; MediaTerminalConnection.getMediaState(), implementado como se acha definido em JTAPI 1.2; MediaTerminalConnection.generateDtmf(), utilizado para gerar tons DTMF na chamada. Todos os outros métodos em mediaTerminalConnection são opcionais. O Provedor não desconectará necessariamente quaisquer chamadas ativas quando sair de serviço. O Provedor pode manter a Chamada ativa e tentar restabelecer a chamada, supondo uma falha de comunicação temporária. A aplicação pode supor que o Provedor esteja tentando restabelecer uma chamada se o provOutofServiceEv não for seguido de perto por CallInvalidEv e eventos correlatos ConnDisconnectedEv (isto é, se estes últimos não seguirem em um tempo-limite).

Adicionalmente, algumas funções GSM não podem ser facilmente acessadas utilizando-se a assinatura de método e sintaxe JTAPI existente. São definidos os seguintes novos métodos ou métodos com assinaturas diferentes.

Provider.getNetworkID() retorna o nome da rede atual.

Provider.getServiceLevel() retorna o nível de serviço de operação, ΝΟΝΕ, EMERGENCY, FULL (NENHUM, EMERGÊNCIA, CHEIO).

Provider.isRoaming() retorna verdadeiro se a MS não estiver no PLMN doméstico.

Estes novos métodos permitem que a aplicação determine a rede móvel pública terrestre atual (PLMN), nível de serviço operacional e se a unidade está ou não no PLMN doméstico.

Em JTAPI, o objeto Terminal representa a extremidade física da chamada. Supõe-se que a chamada esteja transportando voz. Para suportar os tipos de portador de chamada adicionais definidos para GSM, subclasses de Terminal adicionais são definidas, uma para cada tipo de portador de chamada principal. A subclasse DataTerminal do Terminal representa a extremidade física de uma chamada de dados GSM. A subclasse FaxTerminal do Terminal representa a extremidade física de uma chamada de fax GSM.

Uma MS GSM típica suportará pelo menos três Terminais VOZ, um de DADOS e um de FAX. Uma MS pode suportar exemplos ou subclasses adicionais de Terminal (por exemplo, um InternalDataTerminal para dados internos e um ModemDataTerminal para dados enviados para um PC conectado). As aplicações aceitam chamadas de entrada de vários tipos de portador observando eventos de chamada de entrada no Terminal apropriado. É descrito agora, com referência à figura 4, uma característica específica que permite suporte de uma chamada GSM de modo duplo. A figura 4 ilustra detalhes da implementação JTAPI 18 da figura 3. Para o método, é central o método de provedor 40. Este método de provedor estabelece a interface com o sistema operacional 14 em um modo que não necessita ser descrito em detalhes. Como utilizado neste contexto, um "método" é uma função definida dentro de uma classe que opera em instâncias dessa classe. O método provedor 40 tem associado a si um objeto de terminal de voz 42, um objeto de terminal de dados 44, um objeto de terminal de fax 46 e um objeto de endereço 48. Quando uma chamada deve ser feita, o método provedor 40 cria um objeto de chamada 50. 0 objeto de chamada 50 cria um objeto de conexão local 52. Para uma conexão de voz simples, o objeto de conexão local 52 cria um objeto de conexão terminal 54 que referencia o terminal de voz 42. Como será descrito em maior detalhe, o objeto de conexão local 52 também pode criar um segundo objeto de conexão de terminal 56 (e mesmo um terceiro objeto de conexão de terminal 58) . O segundo objeto de conexão de terminal 56 referencia o objeto de terminal de dados 44. O terceiro objeto de terminal 58, se presente, pode referenciar o terminal de fax 46. Como configuração alternativa, os segundo e terceiro objetos de conexão de terminal podem ser gerados para fins de criar uma chamada de fax de dados, como será descrito em maior detalhe.

Pode ser observado que se a chamada for uma chamada de três modos, o objeto de chamada 50 criará um objeto de conexão remota adicional 60 com seus próprios objetos de conexão terminal, associados, 62-66, conforme necessário. Também pode ser observado que se houver outra chamada (por exemplo uma chamada em espera) o método provedor 40 pode criar um objeto de segunda chamada adicional 70 que terá sua própria conexão local e conexões de terminal correspondentes. Em todos os casos, para um telefone de rádio dado, há apenas três terminais: o terminal de voz, o terminal de dados e o terminal de fax. Assim, em todos os casos, os vários objetos de conexão de terminal criados pela conexão local 52, a conexão remota 60 e quaisquer outras conexões locais ou conexões remotas, todas referenciam o objeto terminal de voz respectivo 42, o objeto terminal de dados 44 e o objeto de terminal de fax 46 .

No processo a ser descrito, o objetivo é que o transceptor GSM 30 faça uma chamada com um comutador remoto em um canal de comunicação por radiotelefone e, no caso onde a chamada seja um modo duplo (por exemplo voz e dados ou voz e fax), é o objetivo para a implementação de método JTAPI 18 fazer uma chamada com capacidade de modo duplo e informar o transceptor GSM sobre a CSPMI 22 de que uma chamada de modo duplo foi estabelecida, de modo que o transceptor GSM 30 possa informar ao sistema GSM que a chamada é uma chamada de modo duplo para que, por sua vez, o comutador do sistema GSM, após receber a solicitação para fazer uma chamada, faça uma chamada e reserve um modem de sua função de interconexão para suportar os dados ou funcionalidade de fax da chamada. É ainda o objetivo de estabelecer esta chamada de modo duplo na instigação da aplicação telefônica 16, utilizando o comando JTAPI call.connect().

Em JTAPI versão 1.2, call.connect() espera um argumento que é um objeto terminal, desse modo permitindo o estabelecimento de uma chamada de modo único para ou daquele terminal. Para estabelecer uma chamada de modo duplo, a modalidade preferida da presente invenção permite que call.connect() seja cancelado para acrescentar um método que tem como primeiro argumento um conjunto terminal, em vez de um único terminal de origem. O conjunto terminal é o argumento do comando call.connect e contém um conjunto de objetos terminais que podem ser um terminal de voz e um terminal de dados, um terminal de voz e um terminal de fax, um terminai de dados e um terminal de fax ou um terminal de voz, um terminal de dados e um terminal de fax. Quando o provedor de método 40 é invocado com este comando e um conjunto como argumento, cria o objeto de chamada 50 e o objeto de conexão local 22. O objeto de conexão local 22 cria os primeiro e segundo objetos terminais 54 e 56. O objeto de conexão local 52 consulta o primeiro objeto de conexão terminal 54 em relação ao seu terminal e o primeiro objeto terminal 54 responde ao objeto de conexão local 52 indicando que seu terminal (isto é, o terminal de referencia) é o terminal de voz. Similarmente, o segundo objeto de conexão terminal 56 é consultado pelo objeto de conexão local 52 e responde indicando que seu terminal é o terminal de dados. 0 objeto de conexão local 54 informa ao objeto de chamada 50 que uma conexão de terminal de dados e uma conexão de terminal de voz estão estabelecidos. O objeto de chamada 50 informa ao provedor 40 que a chamada de modo duplo foi estabelecida. O provedor 40 informa o transceptor GSM sobre a CSPMI 22 (através do OS 14) de que a chamada de modo duplo foi estabelecida. O provedor 40 estabelece a chamada através do transceptor 30 como se segue. O provedor 40 cria um buffer que tem como seu tipo PlaceCallReq e acrescenta parâmetros M/O/C da Tabela 1 a seguir. Estes parâmetros descrevem a chamada. TABELA 1 1. Opcional para chamadas de emergência, obrigatório para todos os outros tipos de chamada. 2. Obrigatório para chamadas de múltiplos tipos de chamada. 3. Obrigatório quando qualquer tipo de chamada for para fax ou dados. 4. Pode ser incluído se o cliente desejar cancelar padrão de subscrição CLIR. 5. Pode ser incluído se o cliente desejar cancelar padrões de subscrição CUG. O conteúdo deste buffer é enviado através do link serial 22 para o transceptor 30 e, se aceito, o transceptor retorna a mensagem de confirmação da tabela 2 a seguir. TABELA 2 1. Obrigatório da solicitação de chamada bem-sucedida Esta mensagem de confirmação fornece escoamento de chamadas que permite que o microprocessador 10 identifique a chamada em comandos subsequentes.

Na Tabela 1, o tipo de chamada 2 indica um tipo de chamada alternado e indica que o tipo de chamada alternado é dado ou fax (o tipo de chamada inicial é sempre voz em GSM). Desse modo, o provedor 40 informa o transceptor 30 de que há um tipo de chamada alternado e que são dados (alternativamente fax). Desse modo, quando o transceptor 30 faz a chamada, o comutador é então informado de que há um tipo de chamada alternado e que este tipo de chamada alternado requer reserva de um modem de dados (ou um fax modem) . A primeira entrada do conjunto terminal é o terminal inicialmente ativo, porém a chamada é configurada para manipular qualquer um dos terminais declarados no conjunto, isto é, as conexões de terminal aos outros terminais são colocadas no controle de chamada terminal connection.bridgedstate (ou terminalconnection. passivestate). Como discutido acima, joined/leave é utilizado para controlar o modo atual da chamada. Esta variante de connectO é utilizada para suportar a exigência GSM de declarar inicialmente parâmetros de chamada de modo duplo (desse modo exigindo que a aplicação 16 declare em frente de todos os terminais que poderíam participar da chamada).

Call.connect() é cancelado para acrescentar métodos para especificar explicitamente o TON (tipo de número) e NPI (identificador de plano de numeração) da cadeia do endereço de destino, se estes não puderem ser inferidos como descrito acima.

Call.setEmergency() é definido para ajustar a sinalização de modo de emergência.

Call.setCUGInfo() é definido para especificar informações de grupo de usuário fechado de forma programática, em vez de utilizar códigos SS (serviços suplementares) na cadeia do endereço de destino.

Call.setCUGInfo() é definido para especificar solicitações de restrição de identificação de linha de forma programática, em vez de utilizar códigos SS (serviços suplementares) na cadeia do endereço de destino.

Call.offHook() não é suportado.

As aplicações não podem especificar o controlador de conferência ou transferência. Os métodos setTransferController() e setConferenceController() lançam returno <NULL> para MethodNotSupported, getConferenceController() e getTransferController().

SetConferenceEnable(), getConferenceEnable(), setTransferEnable() e getTransferEnable() manipulam sinalizações internas que controlam a capacidade de transferencia ou conferência dessa chamada.

Invocações de Call.consult () devem incluir a cadeia do endereço de destino; a variante não especificada não é suportada.

Connection.reject(int) é definido para permitir que a aplicação especifique um motivo de rejeição ao recusar uma chamada. Isto suporta a funcionalidade de usuário-ocupado-determinado-por-usuário.

Connection.addToAddress() não é suportado.

Connection.parkO não é suportado.

Uma subclasse de conexão de terminal é definida (conexão de terminal de dados) representando a ligação física entre a rede e o terminal de dados de extremidade.

Os métodos são definidos para especificar e consultar os parâmetros de chamada de dados, como taxa de dados, tipo de modem, camada para protocolo etc. Similarmente, uma subclasse de conexão de terminal ((conexão de terminal de fax) , descrita mais precisamente como uma subclasse de conexão de terminal de meios) representa a ligação física entre a rede e os terminais de extremidade. Os métodos são definidos para especificar e consultar os parâmetros de chamada de fax, como peso de dados, modo de grupo, etc.

FaxTerminalConnection também forneceu métodos específicos de meios para configurar o fluxo de meios de fax, e transmitir páginas de dados e indicadores de término de página.

Um novo evento Terminal é definido para permitir aplicações para determinar se o envio de chamada é ativo para um Terminal específico "TermForwardingActiveEv". O envio para diferentes serviços (isto é, voz, fax e dados) está sinalizando através do objeto Terminal apropriado (isto é, VOZ, DADOS, FAX).

Foi mencionado que Provider.createCall() criará uma chamada mesmo se o Provedor estiver OUT_OF_SERVICE, desde que não tenha sido desligado e que a chamada não possa ser feita com êxito até que o Provedor esteja IN_SERVICE. Esta característica é descrita agora em maior detalhe com referência às figuras 5 e 6.

Com referência à figura 5, o caso será considerado onde, por qualquer motivo, a aplicação 16 busca fazer uma chamada ou estabelecer uma conexão ou uma sessão de dados de pacote. A aplicação 16 é normalmente a interface para o usuário e pode buscar iniciar uma chamada, por exemplo com usuário ligando o dispositivo de radiocomunicação (a estação móvel ou MS) e discando um número telefônico. A aplicação 16 inicia o programa (ou método) ilustrado na figura 5 chamando (invocando) um método Provider.createCall (etapa 100) através de um comando Provider.createCall() através da API 30. Se, na etapa 101, o dispositivo de comunicação estiver em um modo desligado, o programa simplesmente retorna um erro na etapa 102 e sai na etapa 103. Se o dispositivo não estiver no modo desligado, um objeto de Chamada 50 é criado na etapa 110 e o programa da figura 5 é concluído na etapa 111, pronto para o início do programa da figura 6.

Imediatamente após criação do objeto de Chamada 50 e sem quaisquer eventos ou condições adicionais (e na ausência de qualquer evento de cancelamento), a aplicação 16 chama (invoca) um método Call.connect (etapa 150) através de um comando Call.connect através da API 30. Se, na etapa 151, o dispositivo de comunicação for determinado como fora de serviço, o programa (ou método) aguarda na etapa 152 enquanto outras funções executam uma operação de varredura na etapa 154. Um período de espera de aproximadamente 10 segundos é normalmente suficiente para permitir conexão a uma rede celular em uma rotina de varredura. Se, após a etapa 151 ou etapa 156, o dispositivo de comunicação tiver estabelecido serviço com uma rede de radiocomunicação, a etapa 158 começa e um comando é enviado para o transceptor 30 através da interface serial 22 para fazer a chamada. 0 programa da figura 6 termina na etapa 160.

Desse modo, um usuário pode começar a discar um número telefônico para fazer uma chamada mesmo antes do serviço ter sido estabelecido. Esta é uma característica particularmente útil, uma vez que um usuário típico deseja começar a fazer uma chamada tão logo o dispositivo de comunicação seja ligado, sem considerar se o serviço foi estabelecido. 0 estabelecimento de serviço pode começar em resposta ao ato de ligação do dispositivo (por exemplo, ao pressionar uma tecla de ligação ou abrir um flip) e os métodos das figuras 5 e 6 podem começar em paralelo, em resposta a algum outro ato do usuário ou aplicação. É um problema significativo que a definição JTAPI tenha uma classe separada para cada evento JTAPI diferente. Isto é agravado com a MS com a definição em mais de 63 classes de eventos, com um arquivo de classe total de aproximadamente 130k bytes.

De acordo com um aspecto da presente invenção, as aplicações são despachadas com base em um ID de evento em vez do tipo de classe de evento. Isto substitui as diversas classes de evento por um conjunto bem menor de classes de categoria-evento. As aplicações utilizam o ID de evento para determinar um evento específico em um tipo amplo. Isto resulta em economia de espaço significativo sem perda significativa de encapsulação de objeto.

As classes de evento são agrupadas em oito classes genéricas como se segue: EV - classe de base de todos os eventos ProvEv - eventos de provedor.

CallCtlAddrEv - eventos de endereço e de endereço para controle de chamada.

CallCtlCallEv - eventos de chamada e de chamada de controle de chamada CallCtlConnEv - eventos de conexão e de conexão de controle de chamada.

CallCtrlTermEv - eventos de terminal e de terminal de controle de chamada.

CallCtlTermConnEv - eventos de conexão de terminal e de conexão de terminal de controle de chamada. - MediaEv - eventos de meios.

Os eventos específicos agrupados nestas classes genéricas são expostos na tabela 3 a seguir.

Tabela 3 Em resumo, foram descritos uma API de telefonia para um dispositivo de comunicação sem fio e uma implementação associada incluindo um método provedor, que são altamente adequados ao desenvolvimento de programas de computador orientados a objetos para invocar funções de telefonia sem fio. É utilizada uma API que permite alto grau de portabilidade através de plataformas, em uma implementação que tem uma exigência de memória muito baixa. Além disso, a funcionalidade de chamada de modo duplo, como é necessário no sistema de radiotelefone GSM, é suportada utilizando uma classe de evento JTAPI padrão até o presente utilizada para a feitura de chamadas de telefonia de linha telefônica simples com fio.

De acordo com um aspecto da invenção, um dispositivo de radiocomunicação foi descrito compreendendo uma memória que tem ali armazenados um programa de aplicação de usuário e um programa de telefonia móvel. O programa de telefonia móvel mantém parâmetros que descrevem rede sem fio à qual o dispositivo é conectado. Estes parâmetros incluem um ou mais entre: nome de uma rede atual, nível de serviço operacional da rede atual e indicação de se a rede atual é uma rede doméstica. Estes parâmetros podem ser fornecidos ao programa de telefonia móvel de um transceptor ou em uma conexão de protocolo de Internet móvel. Uma interface de programação de aplicação entre o programa de aplicação de usuário e o programa de telefonia móvel tem pelo menos um comando (por exemplo Provider.getNetworkID(), Provider.getServiceLevel() ou Provider.isRoaming() para chamar estes parâmetros e retorná-los ao programa de aplicação. A descrição acima foi fornecida apenas como exemplo e modificações de detalhes podem ser feitas no âmbito e espírito da invenção. APÊNDICE 1 API de Telefonia Java Visão geral Versão 1.2 Introdução A API de Telefonia Java (JTAPI) é uma interface de programação de aplicação orientada a objetos, portável, para aplicações de telefonia-computador baseadas em Java. A JTAPI serve a um público amplo, de desenvolvedores de aplicações para centros de chamada até designers de páginas da Web. A JTAPI suporta domínios de aplicação de telefonia de primeira e terceira pessoa. A API é projetada para tornar fácil a programação das aplicações simples, enquanto fornece as características necessárias para aplicações de telefonia avançada. A API de Telefonia Java é, na realidade, um conjunto de APIs. A API "básica" fornece as características de telefonia rudimentar e modelo de chamada básico, como fazer chamadas telefônicas e atender a chamadas telefônicas. A API básica é circundada por APIs de extensão padrão que fornecem funcionalidade para domínios de telefonia específico, como por exemplo centros de chamada e acesso de fluxo de meios. As arquiteturas básica e de pacotes de extensão JTAPI são descritas posteriormente neste documento.

As aplicações escritas utilizando a API de Telefonia Java são portáveis através das várias plataformas de computador e sistemas telefônicos. As implementações da JTAPI estarão disponíveis para plataformas de integração de telefonia-computador existentes como SunXTL da Sun Microsystem, TAPI da Intel e Microsoft, TSAPI da Novell e Lucent, e CallPath da IBM. Adicionalmente, vendedores de hardware independentes podem optar por fornecer implementações da API de Telefonia Java além de seu próprio hardware de propriedade.

Visão Geral da Organização do Documento Este documento é organizado nas seguintes seções: Características da API de Telefonia Java descreve as características da JTAPI e os princípios nos quais o mesmo foi projetado.

Configurações suportadas - resume os ambientes nos quais JTAPI pode ser utilizada e as configurações de software e computador para as quais foi projetada.

Arquitetura de Pacotes de Telefonia Java - resume como a API de Telefonia Java é organizada em vários pacotes de linguagem Java. Uma descrição resumida acompanha cada pacote juntamente com links para documentação mais detalhada. O Modelo de Chamada de Telefonia Java - descreve como as chamadas telefônicas e diferentes objetos que compõem as chamadas telefônicas são representados na API. Métodos do Pacote Básico - fornece um resumo dos métodos chave disponíveis no pacote básico que executam as operações de telefonia básicas, como por exemplo fazer uma chamada telefônica, atender a uma chamada telefônica, e desconectar uma conexão com uma chamada telefônica.

Estados do Objeto Conexão - descreve os estados nos quais o objeto Conexão pode existir. Fornece uma descrição das transições permissíveis de cada estado.

Estados do Objeto TerminalConnection (conexão de terminal) - descreve os estados nos quais o objeto TerminalConnection (conexão de terminal) pode existir. Fornece uma descrição das transições permissíveis de cada estado.

Fazer uma chamada telefônica - uma das características mais comuns utilizadas em qualquer API de telefonia é fazer uma chamada telefônica. Esta seção descreve as invocações de método JTAPI necessárias para fazer uma chamada telefônica e examina as mudanças de estado no modelo de chamada. Esta análise explicará como as chamadas são feitas, atendidas e terminadas. O Modelo Observador de Telefonia Java - descreve o modelo observador JTAPI. As aplicações utilizam observadores para notificação assíncrona de alterações no estado do modelo de chamada JTAPI.

Os exemplos de código de aplicação não são incluídos aqui, porém dois exemplos de código da vida real utilizando API de Telefonia Java podem ser encontrados na Visão Geral da API de Telefonia Java, Versão 1.2, publicada por Sun Microsystems, Inc., de Paio Alto, Califórnia. Um exemplo faz uma chamada telefônica para um número telefônico especificado. 0 outro exemplo mostra um Terminal designado atendendo a uma chamada telefônica que entra.

Locação e obtenção de provedores - descreve o modo no qual as aplicações criam e obtêm objetos de provedor JTAPI.

Segurança - resume a estratégia de segurança JTAPI.

Características de Telefonia Java As características e princípios de design que orientam a API de Telefonia Java são: traz simplicidade às aplicações de telefonia mais elementares, fornece uma estrutura redimensionável que abrange as aplicações de desktop até aplicações de telefonia de centro de chamada distribuída, estabelece a interface direta entre aplicações e provedores de serviço ou atua como uma interface Java para APIs de telefonia existentes, como SunXTL, TSAPI, e TAPI baseia-se em um núcleo simples que é aumentado com pacotes de extensão padrão, opera em uma ampla faixa de configurações de hardware, onde quer que tempo de execução Java possa ser utilizado.

Configurações Suportadas A JTAPI opera em várias configurações de sistema, incluindo servidores centralizados com acesso direto aos recursos de telefonia e computadores de rede remota com acesso a recursos de telefonia em rede. Na primeira configuração, um computador de rede está operando a aplicação JTAPI e está acessando recursos de telefonia em rede, como ilustra a figura 7. Na Segunda configuração, a aplicação está operando em um computador com seus próprios recursos de telefonia, como ilustra a figura 8.

Configuração de Computador de Rede (NC) Em uma configuração de rede, a aplicação JTAPI ou applet Java opera em uma estação de trabalho remota. Esta estação de trabalho pode ser um computador de rede com apenas uma tela, teclado, processador e alguma memória. Acessa os recursos da rede, fazendo uso de um servidor centralizado que gerencia os recursos de telefonia. A JTAPI comunica-se com este servidor através de um mecanismo de comunicação remota, como a Remote Method Invocation (RMI) da Java, JOE, ou um protocolo de telefonia. 0 diagrama a seguir mostra esta configuração.

Configuração de Computador de Mesa Em uma configuração de mesa, a aplicação JTAPI ou applet Java opera na mesma estação de trabalho que aloja os recursos de telefonia. A figura 8 mostra a configuração da área de trabalho.

Arquitetura de Pacotes de Telefonia Java A API de Telefonia Java é composta por um conjunto de pacotes em linguagem Java. Cada pacote fornece uma parte específica de funcionalidade para um certo aspecto de aplicações de telefonia-computador. As implementações de servidores de telefonia escolhem os pacotes que suportam, dependendo dos recursos de sua plataforma subjacente e de hardware. As aplicações podem indagar pelos pacotes suportados pela implementação que estão atualmente utilizando. Adicionalmente, os desenvolvedores de aplicação podem se preocupar apenas com as aplicações de pacotes suportados que necessitam para realizar uma tarefa. A figura 9 ilustra a arquitetura dos pacotes JTAPI.

No centro da API de Telefonia Java encontra-se o pacote "básico". 0 pacote básico fornece a estrutura básica para chamadas telefônicas modelo e características de telefonia rudimentar. Estas características incluem fazer uma chamada telefônica, atender a uma chamada telefônica e desconectar uma conexão com uma chamada telefônica. As aplicações de telefonia simples necessitarão apenas utilizar o núcleo para realizar suas tarefas e não precisam se preocupar com os detalhes de outros pacotes. Por exemplo, o pacote básico permite que designers de applet acrescentem com facilidade recursos telefônicos a uma página de Web.

Diversos pacotes de "extensão padrão" estendem o pacote básico JTAPI. Estes pacotes de extensão trazem individualmente funcionalidade de telefonia adicional à API. Atualmente, há os seguintes pacotes de extensão para esta API: pacotes de controle de chamada, centro de chamadas, meios, telefone, dados privados e de recursos. Cada pacote é resumido abaixo em termos das características que traz para JTAPI e é ligado a um documento de visão geral e especificações em separado. A arquitetura de pacotes JTAPI é uma via em dois sentidos tanto para implementações como para aplicações. Em outras palavras, as implementações de servidor de telefonia escolhem quais pacotes de extensão (além do pacote básico) que as mesmas implementam, com base nos recursos subjacentes do hardware. As aplicações escolhem os pacotes de extensão (além dos pacotes básicos) que necessitam utilizar para realizar as tarefas desejadas da aplicação. As aplicações podem consultar a implementação para os pacotes de extensão suportados pela implementação e o desenvolvedor da aplicação não precisa se preocupar com os detalhes de quaisquer pacotes não necessários à aplicação.

Pacotes de Extensão Padrão de Telefonia Java Cada pacote de extensão JTAPI tem sua própria especificação descrevendo suas extensões para a API básica, e, na maioria dos casos, tem seu próprio documento de visão geral em separado, descrevendo-o. O gráfico abaixo relaciona cada pacote de extensão disponível, com um link para o documento de visão geral individual, caso exista.

Pacote de Controle de Chamada 0 pacote javax.telephony.callcontrol estende o pacote básico fornecendo características mais avançadas de controle de chamada, como por exemplo colocar chamadas em espera, transferir chamadas telefônicas e conferência de chamadas telefônicas. Este pacote também provê um modelo de estado mais detalhado de chamadas telefônicas.

Pacote de Centro de Chamadas 0 pacote javax.telephony.callcenter fornece às aplicações a capacidade de executar características avançadas necessárias ao gerenciamento de grandes centros de chamada. Os exemplos dessas características avançadas incluem: Roteamento, Distribuição Automatizada de chamada (ACD), Chamada de prognóstico e associar dados de aplicação a objetos de telefonia.

Pacote de Meios 0 pacote javax.telephony.media fornece às aplicações acesso aos fluxos de meios associados a uma chamada telefônica. São capazes de ler e escrever dados destes fluxos de meios. Detecção DTMF (discagem por pressão de botão) e não-DTMF tone e gerações são também fornecidos no pacote de java.telephony.media.

Pacote Telefônico 0 pacote javax.telephony.phone permite às aplicações controlar as características físicas de aparelhos telefônicos de hardware telefônico. As implementações podem descrever Terminais como conjuntos de componentes, onde cada um desses tipos de componente tem interfaces neste pacote.

Pacote de Recursos 0 pacote javax.telephony.capabilites permite que as aplicações indaguem se certas ações podem ser realizadas. Os recursos assumem duas formas: recursos estáticos, que indicam se uma implementação suporta uma característica; recursos dinâmicos, que indicam se uma certa ação é permissível dado o estado atual do modelo de chamada.

Pacote de Dados Privados O pacote javax.telephony.privatedata permite que as aplicações comuniquem dados diretamente ao comutador de hardware subjacente. Estes dados podem ser utilizados para instruir o comutador a executar uma ação específica de comutador. As aplicações também podem utilizar o pacote para executar piggyback de uma parte de dados com um objeto de API de Telefonia Java. O Modelo de Chamada de Telefonia Java 0 modelo de chamada JTAPI consiste em meia dúzia de objetos Java. Esses objetos são definidos utilizando interfaces Java no pacote básico. Cada objeto de modelo de chamada representa uma entidade física ou lógica no mundo de telefonia. A finalidade principal desses objetos de modelo de chamada é descrever chamadas telefônicas e os pontos finais envolvidos em uma chamada telefônica. Estes objetos de modelo de chamada são relacionados entre si em modos específicos, que é resumido abaixo e descrito em mais detalhe na especificação de pacote básico. A figura 10 mostra o modelo de chamada JTAPI e os objetos que compõem o modelo de chamada. Uma descrição de cada objeto segue o diagrama.

Objeto Provedor 0 objeto Provedor é uma abstração de software de provedor-serviço de telefonia. 0 provedor poderia gerenciar um PBX conectado a um servidor, um cartão de fax/telefonia em uma máquina de mesa ou uma tecnologia de rede de computador, como por exemplo IP. Um Provedor oculta os aspectos específicos de serviço do subsistema de telefonia e permite que aplicações e applets Java interajam com o subsistema de telefonia em um modo independente de dispositivo.

Objeto Chamada 0 objeto Chamada representa uma chamada telefônica, fluindo as informações entre o provedor de serviço e os participantes da chamada. Uma chamada telefônica compreende um objeto de Chamada e zero ou mais conexões. Em um cenário de chamada de duas pessoas, uma chamada telefônica tem um objeto de Chamada e duas conexões. Uma chamada de conferência são três ou mais conexões associadas a um objeto de Chamada.

Objeto Endereço 0 objeto Endereço representa um número telefônico. Ê uma abstração para a extremidade lógica de uma chamada telefônica. Observe que isto é bem distinto de uma extremidade física. Na realidade, um endereço pode corresponder a vários pontos finais físicos (isto é Terminais).

Objeto Conexão Um objeto Conexão modela o link de comunicação entre um objeto Chamada e um objeto Endereço. Esta relação também é mencionada como uma visão "lógica", porque diz respeito à relação entre a Chamada e o Endereço (isto é, uma extremidade lógica). Objetos Conexão podem estar em um de vários estados, indicando o estado atual da relação entre a Chamada e o Endereço. Estes estados Conexão são resumidos posteriormente.

Objeto Terminal O objeto Terminal representa um dispositivo físico como um telefone e suas propriedades associadas. Cada objeto Terminal pode ter um ou mais objetos Endereço (números telefônicos) associados a si, como no caso de alguns telefones de escritório capazes de gerenciar aparições de múltiplas chamadas. 0 Terminal também é conhecido como a extremidade física de uma chamada, porque corresponde a uma parte física de hardware.

Objeto TerxninalConnection (Conexão de Terminal) Objetos TerminalConnection (conexão de terminal) modelam a relação entre uma Conexão e uma extremidade física de uma Chamada, que é representada pelo objeto Terminal. Esta relação também é conhecida como a visão "física" da Conexão (em contraste com a Conexão, que modela a vista lógica). 0 TerminalConnection descreve o estado atual de relação entre a Conexão e um Terminal específico. Os estados associados à TerminalConnection são descritos posteriormente neste documento. Métodos do Pacote Básico 0 pacote básico define três métodos para suportar suas principais características: fazer uma chamada telefônica, atender uma chamada telefônica e desconectar uma conexão com uma chamada telefônica. Estes métodos são Call.connect(), TerminalConection.answer(), e Connection.disconnect(), respectivamente.

Call.connect() Quando uma aplicação tem um objeto de chamada inativa (obtido através do Provider.createCall(), pode fazer uma chamada telefônica utilizando o método Call.connect(). A aplicação deve especificar o Terminal de origem (extremidade física) e o Endereço de origem (extremidade lógica) naquele Terminal (no caso de um Terminal ter múltiplos números telefônicos no mesmo). Também fornece a cadeia de número telefônico de destino. Dois objetos Conexão são retornados do método de Call.connect() , representando as extremidades de origem e destino da chamada telefônica.

TerminalConnection.answer() As aplicações monitoram com observadores (discutidos posteriormente) no Terminal quando as chamadas que entram são apresentadas. Uma chamada telefônica que entra para um Terminal é indicada por um TerminalConnnection para aquele Terminal no estado RINGING (TOQUE) (vide estados de TerminalConnection abaixo). Neste momento, as aplicações podem invocar o TerminalConnection.answer() para atender a chamada telefônica que entra.

Connection.disconnect() 0 método de Connection.disconnect() é utilizado para remover um Endereço da chamada telefônica. 0 objeto Conexão representa a relação daquele Endereço com a chamada telefônica. As aplicações invocam normalmente este método quando a Conexão está no estado CONNECTED (CONECTADO) , resultando na Conexão se movendo para o estado DISCONNECTED (DESCONECTADO). No pacote básico, a aplicação pode remover apenas Endereços inteiros da Chamada e todos os Terminais associados àquele Endereço que fazem parte da chamada são também removidos. 0 pacote de extensão para controle de chamada fornece a capacidade para a aplicação remover Terminais individuais apenas da Chamada.

Estados de Objeto Conexão Um objeto Conexão está sempre em um estado que reflete a relação entre uma Chamada e um Endereço. O estado no qual existe uma Conexão não apenas é importante para a aplicação para fins de informação, como é sempre uma indicação de quais métodos e ações podem ser invocadas no objeto Conexão. As mudanças de estado às quais os objetos Conexão são submetidos são regidas por regras mostradas abaixo em um diagrama de transição de estado. Este diagrama assegura aos desenvolvedores de aplicação os estados possíveis nos quais o objeto Conexão pode transicionar dado algum estado atual. Estas regras de transição de estado são inestimáveis para desenvolvedores de aplicação. A figura 11 mostra as transições de estado possível para o objeto Conexão. Segue-se um resumo do significado de cada estado.

Estado IDLE (INATIVO) 0 estado IDLE (INATIVO) é o estado inicial para todos os novos objetos de Conexão. Conexões transicionam rapidamente para fora do estado IDLE (INATIVO) para outro estado. Uma Conexão no estado IDLE (INATIVO) indica que a parte se uniu há pouco à chamada telefônica de alguma forma. Nenhum método básico é válido nas Conexões no estado IDLE (INATIVO).

Estado INPROGRESS (EM ANDAMENTO) 0 estado INPROGRESS (EM ANDAMENTO) indica que uma chamada telefônica está sendo atualmente feita para esta extremidade de destino.

Estado de ALERTING (ALERTA) 0 estado ALERTING (ALERTA) indica que a parte de destino de uma chamada telefônica está sendo alertada para uma chamada telefônica que entra.

Estado CONNECTED (CONECTADO) 0 estado CONNECTED (CONECTADO) indica que uma parte faz parte ativamente de uma chamada telefônica. Uma Conexão no estado CONNECTED (CONECTADO) implica que a parte associada está conversando com outras partes na chamada ou é conectada a tom.

Estado DISCONNECTED (DESCONECTADO) 0 estado DISCONNECTED (DESCONECTADO) indica que uma parte não mais faz parte de uma chamada telefônica. Nenhum método é válido para Conexões no estado DISCONNECTED (DESCONECTADO).

Estado FAILED (FALHOU) O estado FAILED (FALHOU) indica que uma chamada telefônica feita para a extremidade falhou. Por exemplo, se uma aplicação utiliza Call.connect() para fazer uma chamada telefônica para uma parte que está ocupada, a Conexão associada à parte chamada transiciona para o estado FAILED (FALHOU).

Estado UNKNOWN (DESCONHECIDO) 0 estado UNKNOWN (DESCONHECIDO) indica que o Provedor não pode determinar o estado da Conexão atualmente. Uma Conexão pode entrar e sair do estado UNKNOWN (DESCONHECIDO) a qualquer momento, a menos que esteja no estado DISCONNECTED (DESCONECTADO) ou FAILED (FALHOU). Os efeitos da invocação de qualquer método em uma Conexão neste estado são imprevisíveis.

Estados do Objeto TerminalConnection (conexão de terminal) O objeto TerminalConnection (conexão de terminal) representa a relação entre um Terminal e uma Conexão. Como mencionado anteriormente, estes objetivos representam uma visão tísica da Chamada, descrevendo que pontos finais de Terminal físicos fazem parte da chamada telefônica. Similares aos objetos de Conexão, os objetos TerminalConnection (conexão de terminal) têm seu próprio conjunto de estados de diagrama de transição de estado. Um diagrama de transição de estado é mostrado na figura 12 e uma descrição resumida de cada estado encontra-se a seguir.

Estado IDLE (INATIVO) 0 estado IDLE (INATIVO) é o estado inicial para todos os objetos TerminalConnection (conexão de terminal). Tem a mesma conotação para o estado IDLE (INATIVO) do obj eto Conexão.

Estado ACTIVE (ATIVO) 0 estado ACTIVE (ATIVO) indica que um Terminal faz parte ativamente de uma chamada telefônica. Isto implica f reqüentemente que o monofone do terminal está fora do gancho.

Estado RINGING (TOQUE) O estado RINGING (TOQUE) indica que um Terminal está sinalizando para um usuário de que uma chamada telefônica que entra está presente no Terminal.

Estado DROPPED (CAIU) 0 estado DROPPED (CAIU) indica que um Terminal fez parte uma vez de uma chamada telefônica, porém desde então caiu daquela chamada telefônica. O estado DROPPED (CAIU) é o estado final para todas as TerminalConnections (conexões com o terminal).

Estado PASSIVE (PASSIVO) O estado PASSIVE (PASSIVO) indica que um Terminal faz parte de uma chamada telefônica, porém não faz ativamente. Um TerminalConnection no estado PASSIVE (PASSIVO) indica que um recurso no Terminal está sendo utilizado por esta chamada telefônica. Pacotes fornecendo características avançadas permitem que os Terminais unam chamadas do estado PASSIVE (PASSIVO).

Estado UNKNOWN (DESCONHECIDO) O estado UNKNOWN (DESCONHECIDO) indica que o Provedor é incapaz de determinar o estado atual de um TerminalConnection. Tem uma conotação similar àquela do estado UNKNOWN (DESCONHECIDO) do objeto Conexão.

Fazer uma Chamada Telefônica As últimas Esboçaram o modelo de chamada JTAPI, os métodos essenciais no pacote básico e os estados de Conexão e de TerminalConnection. Esta seção junta todas estas informações, apresentando um cenário comum encontrado na maioria das aplicações de telefonia. Esta seção descreve as alterações de estado às quais o modelo de chamada inteiro é normalmente submetido quando uma aplicação faz uma chamada telefônica simples. Os leitores terão uma compreensão abrangente das alterações de modelo de chamada para este simples exemplo. 0 veículo utilizado para descrever as alterações de estado submetidas pelo modelo de chamada é mostrado na figura 13. Este diagrama é um diagrama de regulação de modelo de chamada, onde alterações nos vários objetos são ilustradas à medida que os tempos aumentam no eixo vertical. Este diagrama mostra as alterações típicas de estado após uma aplicação invocar o método Call.connnect().

Na figura 13, etapas de tempo distintas são indicadas por números inteiros descendo no eixo vertical. 0 tempo aumenta descendo por este eixo, porém os números inteiros não pretendem indicar tempo real (relógio). A figura 13, como um todo, representa uma única Chamada Telefônica. Neste caso, o diagrama representa uma chamada telefônica de duas partes (o método Call.connect() resulta sempre em uma chamada de duas partes). 0 diagrama pode ser dividido em duas partes: a metade da esquerda e a metade da direita. A metade da esquerda representa a extremidade de origem da chamada telefônica e a metade a direita representa a extremidade de destino da chamada telefônica.

No lado da esquerda (origem) do diagrama, as duas linhas verticais representam os objetos de Terminal e Endereço de origem (que são argumentos para o método de Call.connect(), como indicado no diagrama. As linhas horizontais representam objetos de Conexão ou objetos TerminalConnection (conexão de terminal) como marcado. Observe que os objetos Conexão são traçados nas regiões mais internas, ao passo que os objetos TerminalConnection (conexão de terminal) são traçados nas regiões mais externas.

Similarmente, no lado direito (destino do diagrama), as duas linhas verticais representam os Terminais e Endereço de destino. Neste exemplo, há dois Terminais de destino associados ao Endereço de destino. Esta configuração foi ilustrada previamente na figura 10. Observe que uma vez que há dois Terminais, há dois objetos TerminalConnection (conexão de terminal) no lado de destino. A figura 13 pode ser lida como se segue: à medida que o tempo passa os objetos Conexão e TerminalConnection (conexão de terminal) mudam de estados. A aparição de uma nova linha horizontal de Conexão ou TerminalConnection corresponde a um novo objeto daquele tipo sendo criado.

No exemplo de fazer uma chamada telefônica, vemos que após a criação das duas Conexões no estado IDLE (INATIVO), a Conexão de origem transiciona para o estado CONNECTED (CONECTADO), enquanto a Conexão de destino transiciona para o estado INPROGRESS (EM ANDAMENTO). Neste momento, uma TerminalConnection para o Terminal de origem é criada e transiciona para o estado ACTIVE (ATIVO). Quando a Conexão de destino transiciona para o estado ALERTING (ALERTA), duas TerminalConnections (conexões com o terminal) são criadas no estado RINGING (TOQUE).

Neste ponto, uma pessoa em um dos Terminais de destino atende a chamada. Quando isto acontece, aquela TerminalConnection se move para o estado ACTIVE (ATIVO) e a outra TerminalConnection se move para o estado PASSIVE (PASSIVO) . Ao mesmo tempo, a Conexão de destino se move, simultaneamente, para o estado CONNECTED (CONECTADO). Quando a chamada telefônica termina, todas as Conexões se movem para o estado DISCONNECTED (DESCONECTADO), e todas TerminalConnections (conexões com o terminal) se movem para o estado DROPPED (CAIU).

Como ponto final, este documento utilizou os termos visão "lógica" e "física de uma chamada telefônica. Este diagrama torna claro estes conceitos. Uma aplicação pode monitorar as alterações de estado do objeto Conexão (isto é, a visão lógica). Olhando o diagrama, o leitor pode entender que estes estados fornecem uma visão de nível mais elevado do progresso da chamada telefônica. As alterações de estado de TerminalConnection representam a visão física. Monitorando as alterações de estado de TerminalConnection, as aplicações podem descobrir o que está acontecendo em cada extremidade lógica física. O Modelo de Observador de Telefonia Java A API de Telefonia Java utiliza o modelo observador/observável Java para notificar assincronamente a aplicação de várias alterações no modelo de chamada JTAPI. Estas alterações podem incluir a alteração de estado de um objeto ou a criação de um objeto.

Os objetos Provedor, Chamada, Terminal e Endereço têm observadores. As interfaces correspondentes a estes observadores são ProviderObserver, CallObserver, TerminalObserver e AddressObserver, respectivamente. 0 ProviderObserver reporta todas as alterações de estado para o objeto Provedor. Para o pacote básico, as alterações de estado são reportadas quando o Provedor muda de estado OUT_OF_SERVICE para IN_SERVICE, para SHUTDOWN. 0 observador de Chamada reporta informações de alteração de estado para todas as Conexões e TerminalConnections (conexões com o terminal) que fazem parte da chamada telefônica bem como alterações de estado na própria chamada. Estas alterações de estado não são reportadas nem no observador de Endereço nem no observador de Terminal. Às vezes, a aplicação pode desejar monitorar objetos de Endereço ou Terminal para chamadas telefônicas que entram. Nestes casos, a aplicação utiliza os métodos Address.addCallObserver() ou Terminal.addCallObserver(). Estes métodos instruem a implementação para acrescentar automaticamente um CallObserver a qualquer chamada que entre em um Endereço ou Terminal. Estes CallObervers são removidos assim que a chamada sai do Endereço ou Terminal.

Os observadores de Endereço e Terminal reportam quaisquer alterações de estado nestes objetos. No pacote básico não há eventos para estes objetos. As interfaces AddressObserver e TerminalObserver ainda existem; contudo, de modo que outros pacotes possam estender estas interfaces.

Localização e obtenção de Provedores A API de Telefonia Java define uma convenção pela qual as implementações de servidor de telefonia da JTAPI tornam seus serviços disponíveis para aplicações.

Os dois elementos que ligam uma aplicação a um servidor são: JtapiPeerFactory A classe JtapiPeerFactory é o primeiro ponto de contato para uma aplicação que necessita de serviços de telefonia. Tem a capacidade de retornar um objeto denominado JtapiPeer ou um objeto JtapiPeer padrão. É definida como uma classe estática.

JtapiPeer A interface JtapiPeer é a base para uma implementação específica de vendedor da API de Telefonia Java. Cada revendedor que fornece uma implementação da JTAPI deve implementar esta interface em uma classe que pode ser carregada pela JtapiPeerFactory. É através de uma classe que implementa o objeto JtapiPeer que uma aplicação obtém um objeto Provedor.

JtapiPeerFactory: Primeiros Passos 0 JtapiPeerFactory é uma classe estática definida em JTAPI. Seu único método público, getJtapiPeer() obtém a implementação JtapiPeer solicitada ou retorna uma implementação padrão. getJtapiPeer() tira o nome da classe desejada para implementação de servidor JTAPI como parâmetro para retornar um exemplo de objeto daquela classe. Se nenhum nome for fornecido, getJtapiPeer() retorna o objeto padrão de implementação de servidor JTAPI.

JtapiPeer: Obtendo vim Objeto Provedor JtapiPeer é uma interface. É utilizado pelos implementadores de servidor JTAPI. Define os métodos que as aplicações utilizam parar obter objetos de provedor, indagar sobre serviços disponíveis naqueles provedores, e obter o nome do exemplo de objeto JtapiPeer. Criando uma classe que implementa a interface JtapiPeer, as implementações JTAPI tornam os seguintes métodos disponíveis para aplicações.

As aplicações utilizam o método JtapiPeer.getProvider() para obter novos objetos de Provedor. Cada implementação pode suportar um ou mais "serviços" diferentes (por exemplo, para tipos diferentes de substrato de rede subjacente). Uma lista de serviços disponíveis pode ser obtida através do método JtapiPeer.getServices().

As aplicações também podem fornecer argumentos opcionais ao Provedor. Estes argumentos são apensos ao argumento em cadeia passado para o método JtapiPeer.getProvider(). 0 argumento em cadeia tem o seguinte formato: <nome de serviço> ; argl = vall; arg2 = val2; ... onde cnome de serviço não é opcional e cada par de argumento opcional que segue é separado por um ponto e vírgula. As chaves para estes argumentos são específicas de implementação, exceto por duas chaves definidas por padrão: 1. login: fornece o nome de usuário login para o Provedor. 2. passwd: fornece uma senha para o Provedor.

As aplicações utilizam o método JtapiPeer.getName() para obter o nome deste exemplo de objeto JtapiPeer. Tem um parâmetro de nome, que é o mesmo nome utilizado como argumento para o método JtapiPeerFactory.getJtapiPeer() .

Segurança na ΆΡΙ de Telefonia Java As implementações da JTAPI de par utilizam o modelo "sandbox" Java para controlar acesso a operações sensíveis. As pessoas que chamam dos métodos JTAPI são categorizados como "confiável" ou "não confiável", utilizando critérios determinados pelo sistema de tempo de execução.

As pessoas que chamam confiáveis têm acesso total aos recursos da JTAPI. Pessoas que chamam não confiáveis são limitadas a operações que não podem comprometer a integridade do sistema. A JTAPI pode ser utilizada para acessar servidores de telefonia ou implementações que fornecem seus próprios mecanismos de segurança. Estes mecanismos permanecem no lugar; parâmetros como nome do usuário e senha são fornecidos através de parâmetros no método JtapiPeer.getProvider() .

Claims (10)

1. Dispositivo de radiocomunicação, compreendendo: uma memória tendo armazenada na mesma um programa de aplicação de usuário (16) e um programa de telefonia (18) que, em operação, tem uma pluralidade de objetos de terminal (54-58); e uma interface de programação de aplicativo (API) (30) entre o programa de aplicação de usuário (16) e o programa de telefonia (18), o dispositivo de radiocomunicação caracterizado pelo fato de que o API (30) tem um comando para aceitar um argumento para estabelecer uma chamada de modo único, e em que programa de telefonia (18) aceita, como um argumento do comando para estabelecer a chamada de modo único, um conjunto identificando uma pluralidade de objetos de terminal (54-58), e permitindo o cancelamento da chamada de modo único para estabelecer uma chamada de modo duplo para a pluralidade de objetos terminais (54-58) utilizando o mesmo comando utilizado no estabelecimento da chamada de modo único.

2. Dispositivo, de acordo com a reivindicação 1, caracterizado pelo fato de que a pluralidade de objetos de terminal (54-58) são selecionáveis para serem pelo menos dois objetos de terminal diferentes (46) do grupo que compreende objetos de terminal de voz (42), objetos de terminal de fax e objetos de terminal de dados (44).

3. Dispositivo, de acordo com a reivindicação 1, caracterizado por ter pelo menos elementos de voz controlados por um primeiro objeto terminal da pluralidade de objetos de terminai (54-58) e elementos de dados controlados por um segundo objeto de terminal da pluralidade de objetos de terminal (54-58)

4. Dispositivo, de acordo com a reivindicação 3, caracterizado por incluir ainda um primeiro processador (10) tendo uma máquina virtual (15) na qual pelo menos o programa de telefonia (18) funciona e um segundo processador (11) tendo programa de transceptor (20) funcionando no mesmo que controla os elementos de voz e os elementos de dados.

5. Dispositivo, de acordo com a reivindicação 4, caracterizado por incluir ainda um link serial (22) entre o primeiro processador (10) e o segundo processador (11).

6. Dispositivo, de acordo com a reivindicação 4, caracterizado por incluir ainda um link (22) entre o primeiro processador (10) e o segundo processador (11), em que o link (22) identifica para o programa de transceptor (20) de que um comando para estabelecer uma chamada é um tipo de um tipo principal e um tipo alternado, em que um tipo alternado indica uma chamada de modo duplo.

7. Método de estabelecer uma chamada de modo duplo em um dispositivo de radiocomunicação, caracterizado por: invocar, de um programa de aplicação (16) através de uma interface de programação de aplicação (API) (30), uma classe de conexão de chamada utilizando um comando tendo um argumento que compreende um conjunto, onde o conjunto compreende uma pluralidade de objetos e terminal (54-58) de tipos diferente selecionados de um tipo de voz (42) , um tipo de fax (46) e um tipo de dados (44)

8. Método, de acordo com a reivindicação 7, caracteri zado por incluir ainda a etapa de, na classe de conexão da chamada, invocar um primeiro objeto de conexão que referencia um terminal de voz (42) e um segundo objeto de conexão que referencia um de um terminal de dados (44) e um terminal de fax (4 6) .

9. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que o programa de aplicação (16) é capaz ainda de interfacear com uma classe de conexão de chamada que não suporta estabelecimento de uma chamada de modo duplo utilizando um comando tendo um argumento que compreende um 'nico objeto terminal.

10. Método, de acordo com a reivindicação 7, caracteri zado pelo fato de que a classe de conexão de chamada é capaz de ser invocada por um comando tendo um argumento que compreende um único objeto de terminal, desse modo estabelecendo uma chamada de modo único.