BRPI0706489A2 - estabelecimento de sessão pt usando caixa pt - Google Patents

Abstract

ESTABELECIMENTO DE SESSAO PT USANDO CAIXA PT Um serviço de Premir Para (PT) de serviços de sessão baseados em Protocolo de Iniciação de Sessão (SIP), e particularmente, o método e sistema em que mesmo se um ter- minal de cliente PT alvo estiver no estado não registrado no núcleo SIP/IP e um servidor PT também não tiver recebido 'configuração de serviço PT' do terminal de cliente PT alvo, um cliente PT particular pode usar a caixa PT do terminal de cliente PT alvo.

Description

"ESTABELECIMENTO DE SESSÃO PT USANDO CAIXA PT"REVELAÇÃO DA INVENÇÃO

Solução Técnica

Esta revelação diz respeito a um serviço baseadoem sessão, e a um método e terminal para estabelecer umasessão PT (Premir Para) em um serviço baseado em Protocolode Iniciação de Sessão (SIP) que permite a um terminal espe-cifico usar um serviço de caixa PT sob o controle de um ser-vidor PT.

Em comunicações sem fio, SIP indica um protocolode sinalização que define um procedimento no qual terminaisdesejando se comunicar com outros identificam e descobremsuas localizações, e estabelecem sessões de serviço de mul-timídia de liberação ou troca entre eles. Serviços baseadosno SIP (isto é, serviços baseados em SIP) têm uma estruturade solicitação/resposta de controle de geração, modificaçãoe término de sessões de serviço de multimídia. Também, osserviços baseados em SIP fornecem serviços pelo uso de umLocalizador Uniforme de Recursos (URL) de SIP, o qual é si-milar a um endereço de correio eletrônico, sem referênciaaos endereços IP (Protocolo de Internet) a fim de capacitaridentificação de cada usuário.

Um serviço de Premir Para (PT) pode ser um dosserviços de sessão baseados em SIP. 0 serviço PT é pretendi-do para fornecer comunicações rápidas para provedores deserviço e usuários de comunicação móvel. Também, o serviçoPT é um tipo de serviço de comunicação bidirecional, isto é,um serviço de comunicação no qual um cliente transmite dadosde midia (por exemplo, rajadas de voz ou rajadas de mídia)para um ou mais outros clientes com os quais uma sessão te-nha sido configurada. 0 serviço PT tipicamente pode ser umserviço de Premir Para Falar Sobre Celular (POC) para trans-missão de dados de voz (áudio) , um serviço de Premir ParaVisualizar (PTV) para transmissão de dados de imagem em mo-vimento (vídeo), ou um serviço de Premir Para Enviar Dados(PTD) para transmissão de dados.

O serviço PT pode fornecer um certo terminal decliente para comunicação com um único recebedor (1 para 1)ou entre grupos de recebedores tal como em uma sessão deconversa em grupo (1 para muitos), e pode usar um Protocolode Iniciação de Sessão (SIP) para estabelecer uma sessão.

Usualmente, o serviço de caixa PT pode se referira um serviço similar a uma caixa postal de voz de um serviçode comunicação móvel.

A figura 1 é um fluxograma de sinalização ilus-trando um método para usar um serviço de caixa PT.

Na figura 1, um cliente PT A pode ser qualquerterminal particular (ou Equipamento de Usuário (UE) PT) queindique uma entidade para processar ou manusear mensagensSIP. Também, as mensagens mostradas na figura 1 são todasmensagens baseadas em SIP.

A fim de usar o serviço de caixa PT diversos pré-requisitos devem ser primeiramente satisfeitos, isto é, oterminal particular deve ser registrado em um núcleo SIP/IPe uma configuração de serviço PT deve ser recebida e/ou serimplementada em um servidor PT.Tal como ilustrado na figura 1, um cliente PT A 15pode se registrar em um núcleo SIP/IP A 20 (por exemplo,3GPP IMS ou 3GPP2 MMD) usando uma mensagem de REGISTRO SIP(Sl) . O núcleo SIP/IP A 20 pode transmitir uma mensagem SIP200 OK para o cliente PT A 15 para informar de que o clientePT A 15 foi registrado de forma bem-sucedida no núcleoSIP/IP A 20 (S2).

O cliente PT A 15 pode transferir valores de con-figuração exigidos para o serviço PT (isto é, configuraçãode serviço PT) para um servidor PT A 30 por meio do núcleoSIP/IP A 20 pelo uso de uma mensagem de DIVULGAÇÃO SIP. A-qui, a configuração de serviço PT pode incluir, por exemplo,um modo de resposta, uma sinalização excetuando sessão deentrada, uma sinalização excetuando alerta pessoal de ins-tante, e uma sinalização de suporte simultâneo, etc. (S3 eS4). A configuração de serviço PT pode ser entregue ao serincluída em um corpo ou campo da mensagem de DIVULGAÇÃO SIP.

O servidor PT A 30 pode armazenar a configuraçãode serviço PT no mesmo (S5) . O servidor PT A 30 também podeinformar o cliente PT A 15, pelo uso da mensagem SIP 200 OK,de que a configuração de serviço PT foi armazenada de formabem-sucedida (S6 e S7). Aqui, nas etapas S6 e S7, a mensagemSIP 200 OK pode ser entregue do servidor PT 30 para o clien-te PT A 15 por meio do núcleo SIP/IP A 20.

As etapas mencionadas anteriormente Sl e S2 podemser referidas como um processo de Registro', e as etapas S3a S7 podem ser referidas como uma Configuração de serviçoPT' .Entretanto, neste caso, o terminal particular (is-to é, o cliente PT A 15 na figura 1) pode usar o serviço decaixa PT somente depois de executar completamente o processode registro e transmitir a configuração de serviço PT para oservidor PT.

"Para abordar tais desvantagens, existe uma neces-sidade de um método para usar o serviço de caixa PT mesmoquando um terminal particular não é capaz de executar um re-gistro de núcleo SIP/IP e a configuração de serviço PT nãopuder ser transmitida para o servidor PT por causa de umdesligamento inesperado do terminal particular, ou mesmo nocaso onde o terminal particular está em um estado não regis-trado para o núcleo SIP/IP (IMS).

Um aspecto desta revelação envolve o reconhecimen-to pelos presentes inventores de tais desvantagens, tal comoexplicado anteriormente. Com base em tal reconhecimento, po-de ser alcançado aperfeiçoamento no estabelecimento de umasessão PT em um serviço PT baseado em SIP para usar um ser-viço de caixa PT. Certos recursos que podem ser parte do mé-todo e terminal para estabelecer a sessão PT no serviço PTbaseado em SIP não serão descritos com muitos detalhes, sim-plesmente para impedir que as características desta revela-ção sejam obscurecidas. Entretanto, tais recursos adicionaistambém podem ser parte do método para estabelecer a sessãoPT no serviço de sessão baseado em SIP para usar o serviçode caixa PT, tal como seria entendido pelos versados na téc-nica.

Portanto, em uma modalidade, é fornecido um métodoe terminal para estabelecer uma sessão PT em um Serviço PTbaseado em Protocolo de Iniciação de Sessão (SIP), a fim deusar um serviço de caixa PT, mesmo quando um terminal parti-cular (ou UE PT) não tiver sido registrado em um núcleoSIP/IP e um servidor PT não tiver recebido uma configuraçãode serviço PTT do terminal particular.

Em uma outra modalidade, é fornecido um método pa-ra estabelecer uma sessão PT compreendendo: receber, de umprimeiro cliente, uma mensagem de convite de sessão para pe-Io menos um ou mais terminais alvos; verificar, a partir deuma certa entidade, informação de condições de diretrizespara acessar caixa PT relacionada aos um ou mais terminaisalvos; e transmitir a mensagem de convite de sessão para umacaixa PT se a condição para acessar caixa PT dos clientesalvos na informação de condições de diretrizes para acessarcaixa PT estiver satisfeita.

Aqui, o método para estabelecer a sessão PT podecompreender adicionalmente: receber uma mensagem de respostade convite de sessão da caixa PT; e transmitir a mensagem deresposta de convite de sessão para o primeiro cliente.

Em uma outra modalidade, um método para estabele-cer uma sessão PT pode compreender: transmitir, por meio deum segundo cliente, uma mensagem de convite de sessão paraconvidar um primeiro cliente; verificar, por meio de um nú-cleo SIP/IP, informação de condições de diretrizes para a-cessar caixa PT relacionada ao primeiro cliente; e usar, pe-lo segundo cliente, a caixa PT de acordo com o estado confi-gurado (configuração) na informação de condições de diretri-zes para acessar caixa PT verificada.

Em uma outra modalidade, um método para estabele-cer uma sessão PT pode compreender: armazenar, por meio deum cliente particular, informação de condições de diretrizespara acessar caixa PT em uma entidade particular por meio deuma primeira mensagem; e transmitir, pela entidade particu-lar, uma segunda mensagem em resposta à primeira mensagempara o cliente particular.

Em uma outra modalidade, um método para estabele-cer sessão PT, o qual é um método para usar uma caixa PT pe-la qual um primeiro cliente verifica dados específicos arma-zenados na caixa PT, pode compreender: acessar, pelo primei-ro cliente, a caixa PT por meio de um servidor PT pelo usode uma mensagem de DIVULGAÇÃO SIP; transmitir, pela caixaPT, uma mensagem SIP incluindo informação específica para oprimeiro cliente; e transmitir, pelo primeiro cliente, umamensagem de CONVITE SIP usando a informação específica a fimde verificar os dados específicos armazenados na caixa PT.

Também, é fornecido um terminal que pode transmi-tir uma mensagem de convite de sessão para pelo menos um oumais terminais alvos, pode receber a mensagem de convite desessão de uma caixa PT com base em informação de condiçõesde diretrizes para acessar caixa PT relacionada aos termi-nais alvos, e que pode receber dados específicos da caixa PTpela configuração de uma sessão com a caixa PT.

A figura 1 é um fluxograma de sinalização ilus-trando um método para usar um serviço de caixa PT.

A figura 2 é um fluxograma de sinalização ilus-trando um procedimento de armazenar informação de condiçõesde diretrizes para acessar caixa PT em um Servidor de Geren-ciamento de Base de Dados XML PT (XDMS PT) em um sistema PT.

A figura 3 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde um a-vanço de caixa PT da informação de condições de diretrizespara acessar caixa PT armazenada no servidor XDM PT do sis-tema PT é configurado como Verdadeiro'.

A figura 4 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde o avan-ço de caixa PT da informação de condições de diretrizes paraacessar caixa PT armazenada no servidor XDM PT do sistema PTé configurado como 'falso'.

A figura 5 é um fluxograma de sinalização ilus-trando um procedimento de armazenar informação de condiçõesde diretrizes para acessar caixa PT em uma caixa PT em umsistema PT.

A figura 6 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde um a-vanço de caixa PT da informação de condições de diretrizespara acessar caixa PT armazenada na caixa PT do sistema PT éconfigurado como 'verdadeiro'.

A figura 7 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde o avan-ço de caixa PT da informação de condições de diretrizes paraacessar caixa PT armazenada na caixa PT do sistema PT é con-figurado como 'falso'.

A figura 8 é um fluxograma de sinalização ilus-trando um procedimento de armazenar informação de condiçõesde diretrizes para acessar caixa PT em um Servidor Residen-cial (HSS) de um núcleo SIP/IP em um sistema PT.

A figura 9 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde um a-vanço de caixa PT da informação de condições de diretrizespara acessar caixa PT armazenada no núcleo SIP/IP do sistemaPT é configurado como Verdadeiro'.

A figura 10 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde o avan-ço de caixa PT da informação de condições de diretrizes paraacessar caixa PT armazenada no núcleo SIP/IP do sistema PT éconfigurado como 'also'.

A figura 11 é um fluxograma de sinalização ilus-trando um procedimento de notificação de caixa PT.

Em seguida, construções e operações das modalida-des preferidas desta revelação serão explicadas com referên-cia aos desenhos anexos.

Nesta revelação, no caso onde um terminal contra-parte (alvo) (ou um Equipamento de Usuário (EU) PT) não ti-ver sido registrado em um núcleo SIP/IP (isto é, um estadonão registrado no núcleo SIP/IP) e um servidor PT não tiverrecebido uma configuração de serviço PT' do terminal con-traparte, os itens seguintes são aplicados, isto é, primei-ro, o terminal contraparte pode armazenar informação rela-cionada ao uso de uma caixa PT (isto é, informação de condi-ções de diretrizes para acessar caixa PT) em uma entidadeparticular (por exemplo, servidor XDM PT, caixa PT, ou nú-cleo SIP/IP), segundo, um terminal particular consulta (in-vestiga) a informação de condições de diretrizes para aces-sar caixa PT relacionada ao terminal contraparte quando oterminal contraparte é convidado pelo terminal particularpara uma sessão PT, terceiro, o terminal particular pode ar-mazenar dados (por exemplo, rajadas de voz ou rajadas de mí-dia) na caixa PT de acordo com a configuração na informaçãode condições de diretrizes para acessar caixa PT para o ter-minal contraparte, e quarto, o terminal particular pode ve-rificar os dados armazenados para assim usar um serviço decaixa PT.

Modalidades preferidas de um a quatro são propos-tas ou sugeridas nesta revelação. As primeira, segunda eterceira modalidades desta revelação podem ser discriminadascom base em qual entidade um cliente particular PT usariapara armazenar a sua informação de condições de diretrizespara acessar caixa PT a fim de usar uma caixa PT. A quartamodalidade desta revelação pode ilustrar que um terminalparticular verifica dados específicos armazenados na caixaPT por meio de um terminal contraparte.

As primeira, segunda e terceira modalidades destarevelação podem ser explicadas ou descritas como se segue.

Ou seja, a primeira modalidade desta revelação po-de ilustrar que a informação de condições de diretrizes paraacessar caixa PT relacionada a um cliente particular PT éarmazenada em um Servidor de Gerenciamento de Base de DadosXML PT (isto é, referido como servidor XDMS PT ou XDM PT). Asegunda modalidade desta revelação pode ilustrar que a in-formação de condições de diretrizes para acessar caixa PTrelacionada ao cliente particular PT é armazenada em umacaixa PT. A terceira modalidade desta revelação pode ilus-trar que a informação de condições de diretrizes para aces-sar caixa PT relacionada ao cliente particular PT é armaze-nada em um núcleo SIP/IP (particularmente, em iHSS').

As primeira, segunda e terceira modalidades destarevelação assumem que um cliente PT B não foi registrado nonúcleo SIP/IP e o servidor PT não recebeu 'configuração deserviço PT' . Aqui, pode ser dito que o terminal de clientePT B pode se tornar o estado não registrado em um núcleoSIP/IP se a configuração de serviço PT não tiver sido tambémrecebida do cliente PT ou o cliente PT não tiver executadoum registro IMS (isto é, núcleo SIP/IP).

Em seguida, a primeira modalidade desta revelaçãoserá explicada com referência às figuras 2 a 4.

A figura 2 é um fluxograma de sinalização ilus-trando um procedimento para armazenar informação de condi-ções de diretrizes para acessar caixa PT em um Servidor deGerenciamento de Base de Dados XML PT (XDMS PT) em um siste-ma PT de acordo com uma primeira modalidade desta revelação.

Tal como ilustrado na figura 2, um sistema PT podeincluir um cliente XDM B 10 que é incluído em um UE PT (E-quipamento de Usuário) para processar mensagens relacionadasHTTP, um núcleo SIP/IP 20, um servidor PT 30, um servidorXDM PT (Gerenciamento de Base de Dados XML) 40 que pode ge-renciar documentos XML para o serviço PT, e uma caixa PT 50que pode armazenar dados de voz (isto é, rajadas de voz) edados de multimídia (isto é, rajadas de mídia) para o servi-ço PT.

Os documentos XML gerenciados pelo servidor XDM PT40 indicam documentos em um formato XML -relacionados às po-líticas de acesso de usuário, que, por exemplo, podem estarrelacionadas aos serviços PT tais como grupos PT e regras deautorização.

Tal como ilustrado na figura 2, o cliente XDM B 10pode transmitir informação de condições de diretrizes paraacessar caixa PT para o servidor XDM PT 40 (S21). E então ainformação de condições de diretrizes para acessar caixa PTpode ser transmitida do cliente XDM B 10 para o servidor XDMPT 40 ao ser incluída em um corpo de uma mensagem deCOLOCAÇÃO HTTP. Aqui, a informação de condições de diretri-zes para acessar caixa PT pode incluir certa informação exi-gida para configurar ou para conectar (acessar) um terceiroUE PT à caixa PT quando o terceiro UE PT convida um UE PT(ou terminal PT) para uma sessão PT sob a condição de que oUE PT não está registrado no núcleo SIP/IP 20 (por exemplo,em um estado de desligado do UE PT). Tal informação pode serreferida como 'avanço de caixa PT', por causa da explicação.Se ela for configurada para conectar o terceiro UE PT à cai-xa PT, quando o UE PT estiver no estado não registrado nonúcleo SIP/IP 20, ela pode ser referida como 'avanço [verda-deiro] de caixa PT' , e a condição oposta pode ser referidacomo 'avanço [falso] de caixa PT'. Aqui, o estado não regis-trado do UE PT no núcleo SIP/IP 20 pode indicar que o servi-dor PT 30 não recebeu configuração de serviço PT do UE PT.Também, a informação de condições de diretrizespara acessar caixa PT pode incluir adicionalmente informaçãopara identificar se o UE PT é um terminal (isto é, UE PT)que é capaz de usar o serviço de caixa PT. Tal informaçãopode ser referida como 'capacidade de caixa PT' , por causada explicação. Se o UE PT for o terminal que é capaz de usaro serviço de caixa PT, a informação indicando a capacidadedo terminal pode ser referida como 'capacidade [verdadeira]de caixa PT'. Por outro lado, se o UE PT for o terminal quenão é capaz de usar o serviço de caixa PT, a informação in-dicando a capacidade do terminal pode ser referida como Ca-pacidade [falsa] de caixa PT'. Aqui, esta revelação pode serimplementada ao somente usar informação de 'avanço [verda-deiro/falso] de caixa PT' a não ser usando a informação de'capacidade de caixa PT' . Isto é por causa de que o 'avanço[verdadeiro/falso] de caixa PT' é um tipo de informação queestá disponível somente quando a informação de 'capacidadede caixa PT' é verdadeira. Em outras palavras, se um termi-nal usado por um usuário PT (isto é, o cliente PT do usuá-rio) não suportar um serviço de caixa PT (isto é, no caso de'capacidade [falsa] de caixa PT') o cliente PT não podetransmitir a configuração de serviço PT usando a informaçãode avanço de caixa PT. Isto é também porque ela não é neces-sária para o servidor PT identificar se o cliente PT não su-porta o serviço de caixa PT ou se o usuário PT não desejaenviar uma mensagem para a caixa PT pelo roteamento de umasessão PT para isto.

Por outro lado, essas informações, isto é, o 'a-vanço [verdadeiro/falso] de caixa PT' e a Capacidade [ver-dadeira/falsa] de caixa PT' podem ser parâmetros ou elemen-tos incluídos em um corpo de uma mensagem de COLOCAÇÃO HTTP.

0 servidor XDM PT 4 0 pode armazenar a informaçãode condições de diretrizes para acessar caixa PT relacionadaao cliente XDM B 10 incluída na mensagem de COLOCAÇÃO HTTP.

O servidor XDM PT 4 0 pode então transmitir uma mensagem HTTP200 OK para o cliente XDM B 10 incluído no UE PT B (S20). Amensagem HTTP 200 OK pode ser uma mensagem para indicar quea informação de condições de diretrizes para acessar caixaPT foi armazenada de forma bem-sucedida no servidor XDM PT40. A informação de condições de diretrizes para acessarcaixa PT armazenada no servidor XDM PT 40 não pode ser apa-gada mesmo se o cliente XDM B 10 se desconectar de um siste-ma PT ou o UE PT for desligado. Ou seja, a informação decondições de diretrizes para acessar caixa PT configuradainicialmente se mantém armazenada no servidor XDM PT 40 atéque o cliente XDM B 10 mude a informação de condições de di-retrizes para acessar caixa PT.

A figura 3 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde um a-vanço de caixa PT da informação de condições de diretrizespara acessar caixa PT armazenada no servidor XDM PT do sis-tema PT é configurado como Verdadeiro'.

Tal como ilustrado na figura 3, um sistema PT podeincluir adicionalmente um cliente PT A 15 e um cliente PT B11 além da construção do sistema PT mostrado na figura 2.Aqui, os clientes PT que são providos no UE PT indicam enti-dades para processar sinais relacionados de roteamento. Por-tanto, o cliente PT A 15 pode transmitir e receber mensagensSIP por meio do núcleo SIP/IP 20. O servidor PT 30 pode serconectado diretamente ao servidor XDM PT 40 por meio de umainterface chamada XCAP (por exemplo, HTTP).

Em seguida, operações na primeira modalidade destarevelação serão explicadas com referência à figura 3.

A fim de convidar o cliente PT B 11 para uma ses-são PT, o cliente PT A 15 pode transmitir uma mensagem deCONVITE SIP (que é uma mensagem de convite de sessão enviadatendo como alvo o cliente PT B 11) . A mensagem de CONVITESIP pode ser transferida (enviada) para o servidor PT 30 docliente PT B 11 por meio do núcleo SIP/IP 20 (S31).

O servidor PT 30 pode receber a mensagem deCONVITE SIP (isto é, a mensagem de convite de sessão) e podeverificar que a configuração de serviço PT não foi recebidado cliente PT B 11 que é o alvo da mensagem. Ou seja, umavez que o cliente PT B 11 esteja, por exemplo, no estado dedesligado (isto é, um estado desconectado) ou em um estadonão registrado, o servidor PT 30 pode verificar que o clien-te PT B 11 atualmente não pode responder com relação ao con-vite de sessão PT para o cliente PT B 11.

Portanto, o servidor PT 30 pode indagar (ou con-sultar) ao servidor XDM PT 40 tal como para informação decondições de diretrizes para acessar caixa PT relacionada aocliente PT B 11 por meio de uma mensagem de OBTENÇÃO HTTP(S32). O servidor XDM PT 40 pode transmitir para o servidorPT 30 a informação de condições de diretrizes para acessarcaixa PT armazenada anteriormente (isto é, avanço [verdadei-ro] de caixa PT) para o cliente PT B 11 por meio de uma men-sagem HTTP 200 OK (isto é, uma mensagem de resposta de con-vite de sessão) (S33).

O servidor PT 30 pode verificar um serviço de cai-xa PT que o cliente PT B 11 deseja para usar com base na in-formação de condições de diretrizes para acessar caixa PT(isto é, avanço [verdadeiro] de caixa PT) para o cliente PTB 11. Ou seja, uma vez que um parâmetro (isto é, um avançode caixa PT) tenha sido configurado (ou esteja incluído) nainformação de condições de diretrizes para acessar caixa PTpara o cliente PT B 11, o servidor PT 30 pode identificarque o UE PT incluindo o cliente PT B 11 é um terminal que écapaz de usar o serviço de caixa PT. Também, uma vez que oavanço de caixa PT tenha sido configurado como ^verdadeiro'na informação de condições de diretrizes para acessar caixaPT para o cliente PT B 11, o servidor PT 30 pode identificarque o cliente PT B 11 foi configurado para usar a caixa PTmesmo se o servidor PT 30 não tiver recebido a configuraçãode serviço PT do cliente PT B 11.

Portanto, com base na informação de condições dediretrizes para acessar caixa PT (isto é, avanço [verdadei-ro] de caixa PT) que foi configurada na figura 2, o servidorPT 30 pode transmitir a mensagem de CONVITE SIP para convi-dar a caixa PT 50 do cliente PT B 11 de maneira tal que ocliente PT A 15 possa armazenar rajadas de voz (um tipo demensagem de correio de voz) ou rajadas de mídia (um tipo demensagem multimídia tal como texto, vídeo, etc.) na caixa PT50 (S34). A mensagem de CONVITE SIP que tem como alvo a cai-xa PT 50 é enviada do servidor PT 30 para a caixa PT 50 docliente PT B 11 por meio do núcleo SIP/IP 20 (S34).

A caixa PT 50 pode transferir uma mensagem SIP 200OK indicando aceitação do convite pelo servidor PT 30 (istoé, a etapa correspondente a S34) para o servidor PT 30 pormeio do núcleo SIP/IP 20 (S35). O servidor PT 30 pode entãotransmitir a mensagem SIP 200 OK para o cliente PT A 15 pormeio do núcleo SIP/IP 20 (S36). Aqui, a mensagem SIP 200 OKpode incluir o assim chamado indicador PT' na etapa S35. 0indicador PT pode designar um indicador ou parâmetro parainformar uma resposta da caixa PT 50 do cliente PT B 11 comrelação ao convite de sessão PT pelo cliente PT A 15. O in-dicador PT pode ser enviado juntamente com a mensagem SIP200 OK ou ao ser incluído na mensagem SIP 200 OK. Também, oindicador PT pode ser enviado pelo servidor PT 30 ou pelacaixa PT 50.

O cliente PT A 15 pode armazenar, na caixa PT 50,as rajadas de voz ou as rajadas de mídia do cliente PT B 11que ele pode desejar para ter (permanecer) ou tanto as raja-das de voz quanto as rajadas de mídia (S37).

A figura 4 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde o avan-ço de caixa PT da informação de condições de diretrizes paraacessar caixa PT armazenada no servidor XDM PT do sistema PTé configurado como ^falso'.

Tal como ilustrado na figura 4, um processo (S31)no qual o cliente PT A 15 pode transmitir a mensagem deCONVITE SIP para o cliente PT B 11 e processos relacionadosde mensagem HTTP (S32 e S33) são iguais àqueles na figura 3.Assim, a explicação dos mesmos não será repetida, mas somen-te diferenças entre a modalidade da figura 4 e a modalidadeda figura 3 serão descritas como se segue.

O servidor PT 30 pode verificar o serviço de caixaPT que o cliente PT B 11 deseja para usar com base na infor-mação de condições de diretrizes para acessar caixa PT (istoé, avanço [falso] de caixa PT) relacionada ao cliente PT B11. Ou seja, uma vez que o parâmetro (isto é, o avanço decaixa PT) tenha sido configurado (ou esteja incluído) na in-formação de condições de diretrizes para acessar caixa PTpara o cliente PT B 11, o servidor PT 30 pode identificarque o UE PT incluindo o cliente PT B 11 é um terminal que écapaz de usar o serviço de caixa PT. Entretanto, uma vez queo avanço de caixa PT tenha sido configurado como ^falso' nainformação de condições de diretrizes para acessar caixa PTpara o cliente PT B 11, o servidor PT 30 pode reconhecer queo cliente PT B 11 não foi configurado para usar a caixa PTmesmo quando o servidor PT 30 não tiver recebido configura-ção de serviço PT do cliente PT B 11.

Portanto, com base na informação de condições dediretrizes para acessar caixa PT (isto é, avanço [falso] decaixa PT) que foi configurada na figura 2, o servidor PT 30pode transmitir uma mensagem de falha com relação ao convitede sessão (por exemplo, mensagem SIP 4xx, uma mensagem SIP480 de 'indisponível temporariamente', etc.) para o clientePT A 15 de maneira tal que o cliente PT A 15 não possa arma-zenar as rajadas de voz ou as rajadas de mídia na caixa PT50 do cliente PT B 11. A mensagem SIP 4xx pode ser transmi-tida para o cliente PT A 15 por meio do núcleo SIP/IP 20(S36').

Tal como mencionado anteriormente na primeira mo-dalidade desta revelação ilustrada nas figuras 2 a 4, o con-vite de sessão PT pelo cliente PT A 15 pode ser conectado àcaixa PT 50 somente quando a informação de condições de di-retrizes para acessar caixa PT estiver configurada na figura2, isto é, o avanço de caixa PT está configurado como verda-deiro. Então, o convidador (isto é, o cliente PT A 15) podearmazenar as rajadas de voz ou as rajadas de mídia, ou ambasna caixa PT 50.

Em seguida, uma segunda modalidade desta revelaçãoserá descrita com referência às figuras 5 a 7. Entretanto,partes sobrepostas com a primeira modalidade desta revelaçãopodem ser entendidas pela descrição fornecida com referênciaàs figuras 2 a 4, e a segunda modalidade desta revelação se-rá explicada com base nas diferenças com a primeira modali-dade desta revelação. Portanto, os números de referência nasfiguras 5 a 7 que são iguais àqueles nas figuras 2 a 4 mos-tram as mesmas operações e propriedades.

A figura 5 é um fluxograma de sinalização ilus-trando um procedimento para armazenar informação de condi-ções de diretrizes para acessar caixa PT em uma caixa PT emum sistema PT.

Comparada com a figura 2, na segunda modalidadeilustrada na figura 5, a informação de condições de diretri-zes para acessar caixa PT relacionada ao cliente PT B 10 po-de ser armazenada na caixa PT 50 a não ser no servidor XDMPT 40. A mensagem de COLOCAÇÃO HTTP pode ter como alvo acaixa PT 50, e a mensagem HTTP 200 OK pode ser enviada pelacaixa PT 50 (S21 e S22).

A figura 6 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde um a-vanço de caixa PT da informação de condições de diretrizespara acessar caixa PT armazenada na caixa PT do sistema PT éconfigurado como Verdadeiro'.

Tal como ilustrado na figura 6, o servidor PT 30pode receber a mensagem de CONVITE SIP da etapa S31 para ve-rificar que a configuração de serviço PT não foi recebida docliente PT B 11 que é o alvo da mensagem. Ou seja, o servi-dor PT 30 pode verificar que o cliente PT B 11 atualmentenão pode responder com relação ao convite de sessão PT.

Aqui, ao contrário da primeira modalidade da figu-ra 3 em que o servidor PT 30 inquire (ou consulta) o servi-dor XDM PT 4 0 tal como para a informação de condições de di-retrizes para acessar caixa PT para o cliente PT B 11 pormeio da mensagem de OBTENÇÃO HTTP, a segunda modalidade dafigura 6 ilustra que o servidor PT 30 pode transmitir a men-sagem de CONVITE SIP para a caixa PT 50 por meio do núcleoSIP/IP 20 (S32'). A caixa PT 50 pode então entregar a infor-mação de condições de diretrizes para acessar caixa PT arma-zenada anteriormente (isto é, avanço [verdadeiro] de caixaPT) para o cliente PT B 11 para o servidor PT 30 por meio damensagem SIP 200 OK (S35). Na comparação entre a primeiramodalidade da figura 3 e a modalidade da figura 6, ao con-trário da primeira modalidade da figura 3 em que as etapasS32 e S33 são executadas usando as mensagens HTTP, as etapasS32 e S35 correspondentes na segunda modalidade da figura 6podem ser executadas usando mensagens SIP. Também, a segundamodalidade da figura 6 não exige que a etapa S34 seja execu-tada. Além disso, a série de etapas (isto é, S35 a S37) dafigura 6 é igual àquela das etapas correspondentes (isto é,S35 a S37) da figura 3.

A figura 7 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde o avan-ço de caixa PT da informação de condições de diretrizes paraacessar caixa PT armazenada na caixa PT do sistema PT é con-figurado como 'falso'.

Tal como ilustrado na figura 7, a série de etapas(S31' a S33' ) pela mensagem de CONVITE SIP é igual àqueladescrita na figura 6.

Em seguida, diferenças entre a segunda modalidadeda figura 7 e a primeira modalidade da figura 4 serão expli-cadas.

A caixa PT 50 pode verificar o serviço de caixa PTque o cliente PT B 11 deseja para usar com base na informa-ção de condições de diretrizes para acessar caixa PT (istoé, avanço [falso] de caixa PT) para o cliente PT B 11. Destamaneira, com base na informação de condições de diretrizespara acessar caixa PT (isto é, avanço [falso] de caixa PT)que foi configurada na figura 5, a caixa PT 50 pode transmi-tir a mensagem SIP 4xx (isto é, uma mensagem SIP 480 de in-disponível temporariamente) indicando recusa (falha) para oconvite do servidor PT 30 (isto é, o processo correspondenteà etapa S34) para o servidor PT 30 por meio do núcleo SIP/IP20 (S35'). O servidor PT 30 pode então transmitir a mensagemSIP 4xx para o cliente PT A 15 por meio do núcleo SIP/IP 20(S36').

Comparando a segunda modalidade da figura 2 com aprimeira modalidade da figura 4, a segunda modalidade da fi-gura 7 é diferente da primeira modalidade da figura 4 em guea mensagem SIP 4xx é transmitida da caixa PT 50 para o ser-vidor PT 30 por meio do núcleo SIP/IP 20 (S35'), e a mensa-gem SIP 4xx é então enviada do servidor PT 50 para o clientePT A 15 por meio do núcleo SIP/IP 20 (S36').

Em seguida, uma terceira modalidade desta revela-ção será explicada com referência às figuras 8 a 10. Entre-tanto, as partes sobrepostas com a primeira modalidade destarevelação podem ser entendidas pela descrição fornecida comreferência às figuras 2 a 4, e as partes sobrepostas com asegunda modalidade desta revelação podem ser entendidas peladescrição fornecida com referência às figuras 5 a 7. A ter-ceira modalidade desta revelação será explicada com base nasdiferenças com as primeira e segunda modalidades desta reve-lação. Portanto, os números de referência nas figuras 8 a 10que são iguais àqueles nas figuras 2 a 4 e nas figuras 5 a 7mostram as mesmas operações e propriedades.

A figura 8 é um fluxograma de sinalização ilus-trando um procedimento de armazenar informação de condiçõesde diretrizes para acessar caixa PT em um Servidor Residen-ciai (HSS) de um Núcleo SIP/IP em um sistema PT.

Comparada à figura 2, na terceira modalidade destarevelação ilustrada na figura 8, a informação de condiçõesde diretrizes para acessar caixa PT para o cliente PT B 10pode ser armazenada no núcleo SIP/IP 20, especialmente, emum Servidor Residencial (HSS) do núcleo SIP/IP 20 a não serno servidor XDM PT 40 (ou na caixa PT 50 no caso da segundamodalidade da figura 5). Portanto, a mensagem de COLOCAÇÃOHTTP pode ter como alvo o HSS do núcleo SIP/IP 20, e a men-sagem HTTP 200 OK pode ser enviada pelo núcleo SIP/IP 20(S21 e S22).

A figura 9 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde um a-vanço de caixa PT da informação de condições de diretrizespara acessar caixa PT armazenada no núcleo SIP/IP do sistemaPT é configurado como Verdadeiro'.

Tal como ilustrado na figura 9, a fim de convidaro cliente PT B 11 para a sessão PT, o cliente PT A 15 podetransmitir a mensagem de CONVITE SIP para o cliente PT B 11(S31).

O núcleo SIP/IP 20 pode receber a mensagem deCONVITE SIP da etapa S31, e pode verificar a informação decondições de diretrizes para acessar caixa PT relacionada aocliente PT B 11 armazenada no HSS. Aqui, o núcleo SIP/IP 20pode verificar que a informação de condições de diretrizespara acessar caixa PT para o cliente PT B 11 foi armazenadano mesmo na figura 8, isto é, o avanço de caixa PT foi con-figurado como Verdadeiro'. Conseqüentemente, o núcleoSIP/IP 20 pode transmitir a mensagem de CONVITE SIP para oservidor PT 30 mesmo que o cliente PT B 11 não tenha sidotambém registrado no núcleo SIP/IP 20 (S32). A mensagem deCONVITE SIP na etapa S32 pode incluir informação especificaindicando que o cliente PT A 15 deve ser conectado à caixaPT 50 do cliente PT B 11.

Além disso, a série de etapas (isto é, S32 a S37)pela série de mensagens SIP ilustrada na figura 9 é igual àsetapas correspondentes ilustradas na figura 6 (isto é, S32 aS37 da figura 6).

A figura 10 é um fluxograma de sinalização ilus-trando um método para usar uma caixa PT no caso onde o avan-ço de caixa PT da informação de condições de diretrizes paraacessar caixa PT armazenada no núcleo SIP/IP do sistema PT éconfigurado como Afalso'.

Tal como ilustrado na figura 10, a fim de convidaro cliente PT B 11 para a sessão PT, o cliente PT A 15 podetransmitir a mensagem de CONVITE SIP para o cliente PT B 11(S31). O núcleo SIP/IP 20 pode receber a mensagem de CONVITESIP da etapa S31 para verificar a informação de condições dediretrizes para acessar caixa PT do cliente PT B 11 armaze-nada no HSS. Aqui, o núcleo SIP/IP 20 pode verificar a con-figuração da informação de condições de diretrizes para a-cessar caixa PT para o cliente PT B 11 que foi armazenada noHSS (isto é, se o avanço de caixa PT foi configurado comoΛ falso'.

Com base nessa configuração da informação de con-dições de diretrizes para acessar caixa PT do cliente PT B11, se o cliente PT B 11 não tiver sido também registrado nonúcleo SIP/IP 20 (isto é, em um estado não registrado no nú-cleo SIP/IP 20), o núcleo SIP/IP 20 pode determinar que oconvidador (isto é, o cliente PT A 15) não seria conectado àcaixa PT 50 do cliente PT B 11. Desta maneira, o núcleoSIP/IP 20 pode enviar a mensagem SIP 4xx (isto é, uma mensa-gem SIP 480 de λindisponível temporariamente' ) para o clien-te PT A 15 (S36").

Tal como mencionado anteriormente, as primeira,segunda e terceira modalidades desta revelação têm ilustradoa informação de condições de diretrizes para acessar caixaPT incluindo os parâmetros (isto é, a capacidade de caixa PTe o avanço de caixa PT) . Entretanto, as primeira, segunda eterceira modalidades desta revelação podem ser aplicadas aum caso onde a informação de condições de diretrizes paraacessar caixa PT inclua somente o avanço de caixa PT exclu-indo a capacidade de caixa PT. Isto pode ser aplicável emque, mesmo se a capacidade de caixa PT estiver configuradacomo qualquer uma de Verdadeira ou falsa', o estado confi-gurado (configuração) da informação de condições de diretri-zes para acessar caixa PT é determinado de acordo com a con-figuração do avanço de caixa PT. Ou seja, se o avanço decaixa PT estiver configurado como Verdadeiro', o cliente PTA 15 pode usar o serviço de caixa PT. Por outro lado, se oavanço de caixa PT estiver configurado como 'falso' , o cli-ente PT A 15 não pode usar o serviço de caixa PT.

A figura 11 é um fluxograma de sinalização ilus-trando um procedimento de notificação de caixa PT de acordocom uma quarta modalidade.

A figura 11 ilustra um procedimento em que as ra-jadas de voz ou rajadas de midia (ou ambas), as quais o cli-ente PT A 15 tenha armazenado na caixa PT 50 do cliente PT B11 nas primeira, segunda e terceira modalidades desta reve-lação, são verificadas pelo cliente PT B 11.

Tal como ilustrado na figura 11, depois de o cli-ente PT B 11 no estado não registrado no núcleo SIP/IP 20(não mostrado na figura 11) se registrar no núcleo SIP/IP20, o cliente PT B 11 pode transferir a configuração de ser-viço PT para o servidor PT 30 usando a mensagem deDIVULGAÇÃO SIP (Slll). Ou seja, através da etapa Slllf oservidor PT 30 pode reconhecer que o cliente PT B 11 estádisponível para usar o serviço PT (isto é, no estado de dis-ponível para serviço PT) . Portanto, o servidor PT 30 podetransmitir a mensagem SIP 200 OK para o cliente PT B 11(S112). Aqui, a mensagem SIP 200 OK pode indicar a recepçãobem-sucedida da mensagem de DIVULGAÇÃO SIP da etapa Slll.

O servidor PT 30 pode transmitir a mensagem deDIVULGAÇÃO SIP para a caixa PT 50 do cliente PT B 11 parainformar de que o cliente PT B 11 está atualmente no estadode disponível para serviço PT (isto é, o cliente PT B foiregistrado e completou a configuração de serviço PT na figu-ra 11) (S113) . A caixa PT 50 pode então transmitir a mensa-gem SIP 200 OK indicándo a recepção bem-sucedida da mensagemde DIVULGAÇÃO SIP da etapa S113 para o servidor PT 30(S114).

Se existirem as rajadas de voz ou as rajadas demídia (ou ambas) armazenadas para o cliente PT B 11, a caixaPT 50 pode transmitir uma mensagem SIP (por exemplo, MÉTODODE MENSAGEM SIP) que inclua informação específica para per-mitir ao cliente PT B 11 verificar as rajadas de voz ou asrajadas de mídia (ou ambas) armazenadas pelo cliente PT A 15(não mostrado na figura 11) (S115). Aqui, a informação espe-cífica pode incluir um endereço de uma caixa PT (por exem-plo, URL da caixa PT), um endereço de posição dentro da cai-xa PT na qual as rajadas de voz ou rajadas de mídia corres-pondentes (ou ambas) são armazenadas (por exemplo, URL dasrajadas de voz e/ou URL das rajadas de mídia), e outrosmais.

O cliente PT B 11 pode receber a mensagem SIP daetapa S115, e então pode transmitir a mensagem SIP 200 OKpara a caixa PT 50 para informar da recepção bem-sucedida damensagem SIP (S116).

O cliente PT B 11 pode transmitir a mensagem deCONVITE SIP para a caixa PT 50 a fim de ser conectado à cai-xa PT 50 pelo uso da informação específica incluída na men-sagem SIP da etapa S115, a informação específica indicando oendereço da caixa PT e o endereço de posição dentro da caixaPT na qual as rajadas de voz ou as rajadas de mídia (ou am-bas) são armazenadas (S117). Em resposta à mensagem deCONVITE SIP da etapa S117, a caixa PT 50 pode transmitir amensagem SIP 200 OK para o cliente PT B 11 para informar darecepção bem-sucedida da mensagem de CONVITE SIP (S 118).

A caixa PT 50 pode entregar para o cliente PT B 11as rajadas de voz ou rajadas de mídia (ou ambas) armazenadaspara o cliente PT B 11 (S119) .

Tal como descrito até agora, esta revelação podefornecer o método e sistema em que mesmo se o cliente PT al-vo (por exemplo, o cliente PT B) estiver no estado não re-gistrado no núcleo SIP/IP e o servidor PT não tenha recebido'configuração de serviço PT' também do cliente PT alvo, umcliente particular PT (por exemplo, o cliente PT A) pode u-sar a caixa PT. Especificamente, esta revelação fornece ummétodo e terminal para estabelecer uma sessão PT capaz depermitir a um terminal particular (ou UE PT) usar um serviçode caixa PT mesmo em um estado em que o terminal particularnão tenha sido registrado em um núcleo SIP/IP e um servidorPT também não tenha recebido uma configuração de serviço PT,em que no caso onde um terminal contraparte (ou um Equipa-mento de Usuário (EU) PT) não tenha sido registrado em umnúcleo SIP/IP (isto é, um estado não registrado no núcleoSIP/IP) e um servidor PT não tenha recebido ^configuração deserviço PT' do terminal contraparte, os itens seguintes sãoaplicados, isto é, primeiro, o terminal contraparte armazenainformação relacionada ao uso de uma caixa PT (isto é, in-formação de condições de diretrizes para acessar caixa PT')em uma entidade particular (por exemplo, servidor XDM PT,caixa PT, ou núcleo SIP/IP), segundo, um terminal particularconsulta a informação de condições de diretrizes para aces-sar caixa PT relacionada do terminal contraparte quando con-vidando o terminal contraparte para uma sessão PT, terceiro,o terminal particular armazena dados (por exemplo, rajadasde voz ou rajadas de midia) na caixa PT de acordo com a con-figuração na informação de condições de diretrizes para a-cessar caixa PT do terminal contraparte, e quarto, o termi-nal particular verifica os dados armazenados para assim usarum serviço de caixa PT.

Além do mais, esta revelação pode ser implementadade maneira tal que o cliente PT alvo pode ser conectado àcaixa PT para obter rajadas de voz ou rajadas de midia (ouambas) que estejam armazenadas na caixa PT para o cliente PTalvo.

Pode ser dito que esta revelação pode fornecer ummétodo para manusear um serviço de sessão Premir Para (PT)em um sistema de comunicação sem fio suportando um protocolode iniciação de sessão (SIP), o método compreendendo: rece-ber, de um terminal, uma mensagem de convite SIP para inici-ar uma sessão para pelo menos um de muitos terminais alvos;verificar se uma configuração de serviço PT foi recebida decada um dos terminais alvos; verificar informação de condi-ção para acessar caixa PT associada com um ou mais terminaisalvos particulares, se a configuração de serviço PT não ti-ver sido recebida desses um ou mais terminais alvos particu-lares; determinar se é para enviar a mensagem de convite SIPpara a caixa PT ou para transmitir uma mensagem de falha pa-ra o terminal com base na verificação da informação de con-dição para acessar caixa PT; transmitir um indicador PT parao terminal, em que o indicador PT representa uma resposta damensagem de convite SIP da caixa PT com relação à mensagemde convite SIP do terminal; e transmitir pelo menos uma derajadas de voz e rajadas de midia para a caixa PT se o ter-minai receber a resposta da mensagem de convite SIP; em quea etapa de determinação compreende adicionalmente: enviar amensagem de convite SIP para a caixa PT quando a informaçãode condição para acessar caixa PT estiver configurada comoum roteamento de caixa PT incondicional; a mensagem de falhaé uma mensagem SIP 480 de indisponível temporariamente'; ainformação de condição para acessar caixa PT é armazenadaantecipadamente em uma certa entidade de uma rede pelo o pe-lo menos um de muitos terminais alvos; a informação de con-dição para acessar caixa PT é recuperada da certa entidadede uma rede; a certa entidade é pelo menos um de um núcleoSIP/IP, um Servidor de Gerenciamento de Base de Dados de XMLde Premir Para (XDMS PT) e a caixa PT; e a resposta da men-sagem de convite SIP é uma mensagem SIP 200 xOK' .

Também pode ser dito que esta revelação pode for-necer um método para manusear um serviço de sessão PremirPara (PT) em um sistema de comunicação sem fio suportando umprotocolo de iniciação de sessão (SIP), o método compreen-dendo: transmitir uma mensagem de convite de sessão para umou mais terminais alvos; e receber uma mensagem de respostade convite de sessão de uma caixa PT quando informação decondição para acessar caixa PT, a qual é associada com um oumais terminais alvos não registrados, estiver configuradacomo roteamento de caixa PT incondicional; em que a mensagemde resposta de convite de sessão inclui um endereço da caixaPT; a informação de condição para acessar caixa PT é armaze-nada antecipadamente em uma certa entidade pelos um ou maisterminais alvos; a certa entidade é pelo menos um de um nú-cleo SIP/IP, um Servidor de Gerenciamento de Base de Dadosde XML de Premir Para (XDMS PT) e a caixa PT; a mensagem deresposta de convite de sessão é uma mensagem de falha quandoa informação de condição para acessar caixa PT não está con-figurada como roteamento de caixa PT incondicional; a mensa-gem de falha é uma mensagem SIP 480 de indisponível tempo-rariamente' ; a informação de condição para acessar caixa PTé recuperada de uma certa entidade de uma rede e a certa en-tidade é pelo menos um de um núcleo SIP/IP, um servidor XDMPT e a caixa PT; o um ou mais terminais alvos não registra-dos são terminais não conectados de Subsistema Multimídia IP(IMS); o um ou mais terminais alvos não registrados são ter-minais em que um servidor não recebeu dos mesmos uma confi-guração de serviço PT.

Esta revelação também pode fornecer um método paramanusear um serviço de sessão Premir Para (PT) em um sistemade comunicação sem fio suportando um protocolo de iniciaçãode sessão (SIP) , o método compreendendo: transmitir uma men-sagem de DIVULGAÇÃO SIP' para uma caixa PT por meio de umservidor PT; receber, da caixa PT, uma mensagem SIP que in-clui informação particular; transmitir, para a caixa PT, umamensagem de convite SIP usando a informação particular a fimde verificar certos dados armazenados na caixa PT; transmi-tir uma mensagem SIP 200 OK para a caixa PT em resposta àmensagem SIP recebida; receber uma mensagem SIP 200 OK dacaixa PT em resposta à mensagem de convite SIP transmitida;e receber os certos dados armazenados na caixa PT da caixaPT; em que a etapa de transmitir a mensagem de DIVULGAÇÃOSIP compreende adicionalmente: transmitir a mensagem deDIVULGAÇÃO SIP para o servidor PT; e receber uma mensagemSIP 200 OK do servidor PT em resposta à mensagem deDIVULGAÇÃO SIP, em que o servidor PT transmite a mensagem deDIVULGAÇÃO SIP para a caixa PT e então recebe a mensagem SIP200 OK da caixa PT em resposta à mensagem de DIVULGAÇÃO SIP;os certos dados são umas rajadas de voz (TB) e/ou umas raja-das de mídia (MB); e a informação particular inclui um ende-reço dos certos dados armazenados na caixa PT.

Esta revelação também pode fornecer um método paramanusear um serviço de sessão Premir Para (PT) em um sistemade comunicação sem fio suportando um protocolo de iniciaçãode sessão (SIP), o método compreendendo: receber uma mensa-gem de convite SIP para iniciar uma sessão para pelo menosum de muitos terminais alvos; verificar cada configuração deserviço PT para cada um dos terminais alvos respectivamente;transmitir a mensagem de convite SIP para a caixa PT se aconfiguração de serviço PT não tiver sido recebida de um oumais terminais alvos particulares; receber uma mensagem deresposta de convite SIP da caixa PT, em que a mensagem deresposta de convite SIP inclui informação de condição paraacessar caixa PT dos um ou mais terminais alvos particula-res; e executar comunicação de dados por meio de uma conexãode sessão com a caixa PT quando a informação de condição pa-ra acessar caixa PT estiver configurada como roteamento decaixa PT incondicional.

Também, esta revelação pode fornecer um método pa-ra manusear um serviço de sessão Premir Para (PT) em um sis-tema de comunicação sem fio suportando um protocolo de ini-ciação de sessão (SIP), o método compreendendo: receber umasolicitação de um cliente a fim de iniciar uma sessão parapelo menos um de muitos clientes alvos; verificar informaçãopara acessar entidade de armazenamento para um ou mais cli-entes alvos não registrados ou pelo menos um de terminaisalvos indisponíveis; determinar se é para enviar a solicita-ção para uma entidade de armazenamento ou para enviar umamensagem de falha para o cliente de acordo com a etapa deverificação; receber uma resposta da solicitação com relaçãoà solicitação que foi enviada para a entidade de armazena-mento pela etapa de determinação; e executar comunicação dedados por meio de uma conexão de sessão com entidade de ar-mazenamento quando a informação para acessar entidade de ar-mazenamento estiver configurada como envio de entidade dearmazenamento incondicional; em que a entidade de armazena-mento armazena dados de sessão; e o um ou mais clientes al-vos não registrados são terminais em que um servidor não re-cebeu dos mesmos uma configuração de serviço PT.

Os métodos exemplares descritos até aqui podem serimplementados em software, hardware, ou em uma combinaçãodos mesmos. Por exemplo, os métodos exemplares ou pelo menosalguns dos procedimentos dos mesmos podem ser armazenados emmídias de armazenamento (por exemplo, memória interna de umterminal móvel, memória Flash, disco rígido, etc.), e seremimplementados como códigos, comandos, instruções, etc. quesão partes de softwares que podem ser executados por proces-sadores (por exemplo, um microprocessador em um terminal mó-vel, um controlador, etc.).

Os terminais de cliente mencionados anteriormentepodem incluir um módulo de transceptor, uma unidade de saida(por exemplo, um mostrador, um dispositivo de saida de som,etc.), uma unidade de entrada (por exemplo, um microfone,uma unidade de entrada de chave, etc.), um módulo de câmera,assim como outro conjunto de circuitos ou componentes decontrole. Também, o servidor pode incluir uma interface derede, uma midia de armazenamento, um processador, assim comooutras entidades de rede.

Também, os recursos e aspectos descritos neste do-cumento são relacionados e podem ser implementados paraquaisquer sistemas de comunicação sem fio usando dispositi-vos móveis, tais como PDAs e computadores portáteis equipa-dos com dispositivos de comunicação sem fio (isto é, inter-face). Além disso, o uso de certos termos para descrever es-ta revelação não deve limitar o escopo desta revelação a umcerto tipo de sistema de comunicação sem fio. Esta revelaçãotambém é aplicável a outros sistemas de comunicação sem fiousando diferentes interfaces de ar e/ou camadas fisicas, porexemplo, TDMA, CDMA, FDMA, WCDMA, OFDM, EV-DO, Wi-Max Móvel,Wi-Bro, etc.

Também deve ser entendido que as modalidades exem-plares descritas anteriormente não são limitadas por qual-quer um dos detalhes da descrição anterior, a não ser queespecificado de outro modo, mas em vez disso devem ser in-terpretadas amplamente. Quaisquer mudanças e modificaçõesestruturais e/ou funcionais que estejam dentro das divisas elimites das reivindicações ou equivalências de tais divisae limites são, portanto, consideradas como sendo abrangidapor tais reivindicações.

Claims (31)

1. Método para manusear um serviço de sessão Pre-mir Para (PT) em um sistema de comunicação sem fio suportan-do um protocolo de iniciação de sessão (SIP), o métodoCARACTERIZADO pelo fato de que compreende:receber, de um terminal, uma mensagem de conviteSIP para iniciar uma sessão para pelo menos um de muitosterminais alvos;verificar se uma configuração de serviço PT foirecebida de cada um dos terminais alvos;verificar informação de condição para acessar cai-xa PT associada com um ou mais terminais alvos particulares,se a configuração de serviço PT não tiver sido recebida des-ses um ou mais terminais alvos particulares; edeterminar se é para enviar a mensagem de conviteSIP para a caixa PT ou para transmitir uma mensagem de falhapara o terminal com base na verificação da informação decondição para acessar caixa PT.

2. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a etapa de determinação com-preende adicionalmente:enviar a mensagem de convite SIP para a caixa PTquando a informação de condição para acessar caixa PT esti-ver configurada como um roteamento de caixa PT incondicional.

3. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a mensagem de falha é umamensagem SIP 480 de λindisponível temporariamente'.

4. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a informação de condição paraacessar caixa PT é armazenada antecipadamente em uma certaentidade de uma rede pelo o pelo menos um de muitos termi-nais alvos.

5. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que a informação de condição paraacessar caixa PT é recuperada da certa entidade de uma rede.

6. Método, de acordo com a reivindicação 5,CARACTERIZADO pelo fato de que a certa entidade é pelo menosum de um núcleo SIP/IP, um Servidor de Gerenciamento de Basede Dados de XML de Premir Para (XDMS PT) e a caixa PT.

7. Método, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que compreende adicionalmente:transmitir um indicador PT para o terminal, em queo indicador PT representa uma resposta da mensagem de convi-te SIP da caixa PT com relação à mensagem de convite SIP doterminal.

8. Método, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que compreende adicionalmente:transmitir pelo menos uma de rajadas de voz e ra-jadas de midia para a caixa PT se o terminal receber a res-posta da mensagem de convite SIP.

9. Método, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que a resposta da mensagem deconvite SIP é uma mensagem SIP 200 'ΟΚ' .

10. Método para manusear um serviço de sessão Pre-mir Para (PT) em um sistema de comunicação sem fio suportan-do um protocolo de iniciação de sessão (SIP), o métodoCARACTERIZADO pelo fato de que compreende:transmitir uma mensagem de convite de sessão paraum ou mais terminais alvos; ereceber uma mensagem de resposta de convite desessão de uma caixa PT quando informação de condição paraacessar caixa PT, a qual é associada com um ou mais termi-nais alvos não registrados, estiver configurada como rotea-mento de caixa PT incondicional.

11. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que a mensagem de resposta deconvite de sessão inclui um endereço da caixa PT.

12. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que a informação de condição paraacessar caixa PT é armazenada antecipadamente em uma certaentidade pelos um ou mais terminais alvos.

13. Método, de acordo com a reivindicação 12,CARACTERIZADO pelo fato de que a certa entidade é pelo menosum de um núcleo SIP/IP, um Servidor de Gerenciamento de Basede Dados de XML de Premir Para (XDMS PT) e a caixa PT.

14. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que a mensagem de resposta deconvite de sessão é uma mensagem de falha quando a informa-ção de condição para acessar caixa PT não está configuradacomo roteamento de caixa PT incondicional.

15. Método, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que a mensagem de falha é umamensagem SIP 480 de indisponível temporariamente'.

16. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que a informação de condição paraacessar caixa PT é recuperada de uma certa entidade de umarede e a certa entidade é pelo menos um de um núcleo SIP/IP,um servidor XDM PT e a caixa PT.

17. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que o um ou mais terminais alvosnão registrados são terminais não conectados de SubsistemaMultimídia IP (IMS).

18. Método, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que o um ou mais terminais alvosnão registrados são terminais em que um servidor não recebeudos mesmos uma configuração de serviço PT.

19. Método para manusear um serviço de sessão Pre-mir Para (PT) em um sistema de comunicação sem fio suportan-do um protocolo de iniciação de sessão (SIP), o métodoCARACTERIZADO pelo fato de que compreende:transmitir uma mensagem de DIVULGAÇÃO SIP para umacaixa PT por meio de um servidor PT;receber, da caixa PT, uma mensagem SIP que incluiinformação particular; etransmitir, para a caixa PT, uma mensagem de con-vite SIP usando a informação particular a fim de verificarcertos dados armazenados na caixa PT.

20. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de que a etapa de transmitir a men-sagem de DIVULGAÇÃO SIP compreende adicionalmente:transmitir a mensagem de DIVULGAÇÃO SIP para oservidor PT; ereceber uma mensagem SIP 200 OK do servidor PT emresposta à mensagem de DIVULGAÇÃO SIP, em gue o servidor PTtransmite a mensagem de DIVULGAÇÃO SIP para a caixa PT e en-tão recebe a mensagem SIP 200 OK da caixa PT em resposta àmensagem de DIVULGAÇÃO SIP.

21. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de gue os certos dados são umas ra-jadas de voz (TB) e/ou umas rajadas de mídia (MB).

22. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de gue a informação particular in-clui um endereço dos certos dados armazenados na caixa PT.

23. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de gue compreende adicionalmente:transmitir uma mensagem SIP 200 OK para a caixa PTem resposta à mensagem SIP recebida.

24. Método, de acordo com a reivindicação 19,CARACTERIZADO pelo fato de gue compreende adicionalmente:receber uma mensagem SIP 200 OK da caixa PT emresposta à mensagem de convite SIP transmitida; ereceber os certos dados armazenados na caixa PT dacaixa PT.

25. Método para manusear um serviço de sessão Pre-mir Para (PT) em um sistema de comunicação sem fio suportan-do um protocolo de iniciação de sessão (SIP), o métodoCARACTERIZADO pelo fato de gue compreende:receber uma mensagem de convite SIP para iniciaruma sessão para pelo menos um de muitos terminais alvos;verificar cada configuração de serviço PT para ca-da um dos terminais alvos respectivamente;transmitir a mensagem de convite SIP para a caixaPT se a configuração de serviço PT não tiver sido recebidade um ou mais terminais alvos particulares;receber uma mensagem de resposta de convite SIP dacaixa PT, em que a mensagem de resposta de convite SIP in-clui informação de condição para acessar caixa PT do um oumais terminais alvos particulares.

26. Método, de acordo com a reivindicação 25,CARACTERIZADO pelo fato de que compreende adicionalmente:executar comunicação de dados por meio de uma co-nexão de sessão com a caixa PT quando a informação de condi-ção para acessar caixa PT estiver configurada como roteamen-to de caixa PT incondicional.

27. Método para manusear um serviço de sessão Pre-mir Para (PT) em um sistema de comunicação sem fio suportan-do um protocolo de iniciação de sessão (SIP), o métodoCARACTERIZADO pelo fato de que compreende:receber uma solicitação de um cliente a fim de i-niciar uma sessão para pelo menos um de muitos clientes alvos;verificar informação para acessar entidade de ar-mazenamento para um ou mais clientes alvos não registradosou pelo menos para um de terminais alvos indisponíveis; edeterminar.se é para enviar a solicitação para umaentidade de armazenamento ou para enviar uma mensagem de fa-lha para o cliente de acordo com a etapa de verificação.

28. Método, de acordo com a reivindicação 27,CARACTERIZADO pelo fato de que a entidade de armazenamentoarmazena dados de sessão.

29. Método, de acordo com a reivindicação 27,CARACTERIZADO pelo fato de que o um ou mais clientes alvosnão registrados são terminais em que um servidor não recebeudos mesmos uma configuração de serviço PT.

30. Método, de acordo com a reivindicação 27,CARACTERIZADO pelo fato de que compreende adicionalmente:receber uma resposta da solicitação com relação àsolicitação que foi enviada para a entidade de armazenamentopela etapa de determinação.

31. Método, de acordo com a reivindicação 27,CARACTERIZADO pelo fato de que compreende adicionalmente:executar comunicação de dados por meio de uma co-nexão de sessão com entidade de armazenamento quando a in-formação para acessar entidade de armazenamento estiver con-figurada como envio de entidade de armazenamento incondicional.