BRPI0721330A2 - mÉtodo para facilitar acesso a serviÇos de uma rede de subsistema de multimÍdia de ip, mÉtodos para operar uma funÇço de controle de sessço de chamada de proxy, uma funÇço de controle de sessço de chamada de serviÇo e um servidor de assinante domÉstico de um subsistema de multimÍdia de ip, e, computadores adaptados para implementar uma funÇço de controle de sessço de chamada de proxy, uma funÇço de controle sessço de chamada de serviÇo e um servidor de assinante domÉstico de um subsistema de multimÍdias de ip - Google Patents

Abstract

MÉTODO PARA FACILITAR ACESSO A SERVIÇOS DE UMA REDE DE SUBSISTEMA DE MULTIMIDIA DE IP, MÉTODOS PARA OPERAR UMA FUNÇçO DE CONTROLE DE SESSçO DE CHAMADA DE PROXY, UMA FUNÇçO DE CONTROLE DE SESSçO DE CHAMADA DE SERVIÇO E UM SERVIDOR DE ASSINANTE DOMÉSTICO DE UM SUBSISTEMA DE MULTIMIIDIA DE IP, E, COMPUTADORES ADAPTADOS PARA IMPLEMENTAR UMA FUNÇçO DE CONTROLE DE SESSçO DE CHAMADA DE PROXY, UMA FUNÇçO DE CONTROLE SESSçO DE CHAMADA DE SERVIÇO E UM SERVIDOR DE ASSINANTE DOMÉSTICO DE UM SUBSISTEMA DE MULTIMIDIA DE IP. Um método para facilitar acesso a serviços de uma rede de Subsistema Multimídia de IP por terminais de usuário localizados atrás de um ponto de acesso à dita rede. O ponto de acesso está associado com uma assinatura à rede de Subsistema de Multimídia de IP. O método compreende incluir dentro de um Conjunto de Registro Implícito definido para dita assinatura, uma Identidade de Usuário Pública 'feita curinga' ou subdomínio de Identidade de Usuário Pública representativa de uma gama de Identidades de Usuário Públicas. No registro de Subsistema de Multimídia de IP de dito ponto de acesso com a rede de Subsistema de Multimídia de IP, as Identidades de Usuário Públicas contidas no Conjunto de Registro Implícito são distribuídas a uma Função de Controle de Sessão de Chamada de Serviço alocada a dito ponto de acesso e a uma Função de Controle de Sessão de Chamada de Proxy à qual dito ponto de acesso está conectado.

Description

"MÉTODO PARA FACILITAR ACESSO A SERVIÇOS DE UMA REDE DE SUBSISTEMA DE MULTIMÍDIA DE IP, MÉTODOS PARA OPERAR UMA FUNÇÃO DE CONTROLE DE SESSÃO DE CHAMADA DE PROXY, UMA FUNÇÃO DE CONTROLE DE SESSÃO DE CHAMADA DE SERVIÇO E UM SERVIDOR DE ASSINANTE DOMÉSTICO DE UM SUBSISTEMA DE MULTIMÍDIA DE IP, E, COMPUTADORES ADAPTADOS PARA IMPLEMENTAR UMA FUNÇÃO DE CONTROLE DE SESSÃO DE CHAMADA DE PROXY, UMA FUNÇÃO DE CONTROLE SESSÃO DE CHAMADA DE SERVIÇO E UM SERVIDOR DE ASSINANTE DOMÉSTICO DE UM SUBSISTEMA DE MULTIMÍDIAS DE IP" Campo Técnico

A presente invenção relaciona-se a acesso de grupo a serviços de Subsistema de Multimídia de IP e em particular a facilitar tal acesso a usuários que não têm assinaturas individuais de Subsistema de Multimídia de IP, mas pertencem a um grupo que tem. Fundamento

Subsistema de Multimídia de IP (IMS) é a tecnologia definida pelo Projeto de Sociedade de Terceira Geração (3GPP) para prover serviços de Multimídia de IP através de redes de comunicação móveis (3 GPP TS 22.228). IMS provê características fundamentais para enriquecer a experiência de comunicação de pessoa para pessoa de usuário final pela integração e interação de serviços. IMS permite novas ricas comunicações de pessoa para pessoa (cliente para cliente) como também de pessoa para conteúdo (cliente para servidor) através de uma rede baseada em IP. O IMS faz uso do Protocolo de Iniciação de Sessão (SIP) para

estabelecer e controlar chamadas ou sessões entre terminais de usuário (UEs) ou entre UEs e servidores de aplicativo (ASs). O Protocolo de Descrição de Sessão (SDP), levado por sinalização de SIP, é usado para descrever e negociar os componentes de mídia da sessão. Enquanto SIP foi criado como um protocolo de usuário para usuário, IMS permite aos operadores e provedores de serviços controlarem acesso de usuário a serviços e cobrar os usuários por conseguinte.

Dentro de uma rede de IMS, Funções de Controle de Chamada/Sessão (CSCFs) operam como entidades de SIP dentro do IMS. A arquitetura de 3GPP define três tipos de CSCFs: a CSCF de Proxy (P-CSCF), que é o primeiro ponto de contato dentro do IMS para um terminal de SIP; a CSCF de Serviço (S-CSCF), que provê serviços ao usuário aos quais o usuário se subscreveu; e a CSCF de Interrogação (I-CSCF), cujo papel é identificar a S-CSCF correta e encaminhar para aquela S-CSCF um pedido recebido de um terminal de SIP por uma P-CSCF.

Funcionalidade de serviço de IMS é implementada usando servidores de aplicativo (ASs). Para qualquer dado UE3 um ou mais ASs podem ser associados com aquele terminal. ASs se comunicam com uma S- CSCF pela interface de Controle de Serviço de IMS (ISC) e são ligados em uma rota de mensagem de SIP como exigido (por exemplo, como resultado da ativação de IFCs carregados na S-CSCF para um dado UE).

Um usuário se registra no IMS usando o método de REGISTRO de SIP especificado. Este é um mecanismo para se conectar ao IMS e anunciar ao IMS o endereço ao qual uma identidade de usuário de SIP pode ser alcançada. Em 3GPP, quando um terminal de SIP executa uma registro, o IMS autentica o usuário usando a informação de assinatura armazenada em um Servidor de Assinante Doméstico (HSS), e aloca uma S- CSCF àquele usuário do conjunto de S-CSCFs disponíveis. Enquanto os critérios para alocar S-CSCFs não estão especificados por 3GPP, estes podem incluir repartição de carga e exigências de serviço. É notado que a alocação de uma S-CSCF é fundamental para controlar, e cobrar por acesso de usuário a serviços baseados em IMS. Operadores podem prover um mecanismo para prevenir sessões de SIP de usuário para usuário diretas que caso contrário desviariam a S-CSCF.

Durante o processo de registro, é a responsabilidade da I- CSCF selecionar uma S-CSCF, se uma S-CSCF já não estiver selecionada. A I-CSCF recebe as capacidades de S-CSCF exigidas do HSS, e seleciona uma S-CSCF apropriada baseado nas capacidades recebidas. É notado que alocação de S-CSCF também é levada para um usuário pela I-CSCF no caso onde o usuário é chamado por outra parte, e o usuário não está alocado a uma S-CSCF atualmente. Quando um usuário registrado envia subseqüentemente um pedido de sessão ao IMS, a P-CSCF é capaz de encaminhar o pedido à S- CSCF selecionada baseado em informação recebida da S-CSCF durante o processo de registro.

Todo usuário de IMS possui uma ou mais Identidades de Usuário Privadas. Uma Identidade de Usuário Privada é nomeada pelo operador de rede domestica e é usada pelo IMS, por exemplo para propósitos de registro, autorização, administração e contabilidade. Esta identidade leva a forma de um Identificador de Acesso de Rede (NAI) como definido em IETF

r

RFC 2486. E possível para uma representação da Identidade de Assinante Móvel Internacional (IMSI) ser contida dentro do NAI para a identidade privada. 3GPP TS 23.228 especifica as propriedades seguintes da Identidade de Usuário Privada:

A Identidade de Usuário Privada não é usada para roteamento de mensagens de SIP.

A Identidade de Usuário Privada deverá ser contida em todos os pedidos de Registro (incluindo pedidos de Re-registro e Des-registro) passados do UE à rede doméstica.

Um aplicativo de Módulo de Identidade de Serviços de Multimídia de IP (ISIM) deverá armazenar seguramente uma Identidade de Usuário Privada. Não deverá ser possível para o UE modificar a informação de Identidade de Usuário Privada armazenada no aplicativo de ISIM. A Identidade de Usuário Privada é uma identidade global única definida pelo Operador de Rede doméstica, que pode ser usada dentro da rede doméstica para identificar a assinatura do usuário (por exemplo capacidade de serviço de IM) de uma perspectiva de rede. A Identidade de Usuário Privada identifica a assinatura, não o usuário.

A Identidade de Usuário Privada deverá ser alocada permanentemente à assinatura de um usuário (não é uma identidade dinâmica), e é válida para a duração da assinatura do usuário com a rede doméstica.

A Identidade de Usuário Privada é usada para identificar a

informação do usuário (por exemplo informação de autenticação) armazenada dentro do HSS (para uso por exemplo durante Registro).

A Identidade de Usuário Privada pode estar presente registros de cobrança baseado em políticas de operador.

A Identidade de Usuário Privada é autenticada só durante

registro do usuário (incluindo re-registro e des-registro).

O HSS precisa armazenar a Identidade de Usuário Privada.

A S-CSCF precisa obter e armazenar a Identidade de Usuário Privada no registro e terminação não registrada.

Além de uma Identidade de Usuário Privada, todo usuário de

IMS deverá ter uma ou mais IMS Identidades de Usuário Públicas (PUIs). As PUIs são usadas por qualquer usuário para pedir comunicações a outros usuários. Um usuário poderia por exemplo incluir uma PUI (mas não uma Identidade de Usuário Privada) em um cartão de visita. 3 GPP TS 23.228

especifica as propriedades seguintes da PUI:

Ambos esquemas de numeração de telecomunicação e nomeação de Internet podem ser usados para endereçar usuários dependendo das PUIs que os usuários têm.

As PUI(s) deverão levar a forma de uma URI de SIP (como definida em RFC 3261 e RFC 2396 ou o formato de "tel": URI definido em RFC 3966.

Um aplicativo de ISIM deverá armazenar seguramente pelo menos uma PUI (não será possível para o UE modificar a PUI), mas não é requerido que todas as PUIs adicionais sejam armazenadas no aplicativo de ISIM.

Uma PUI deverá ser registrada tanto explicitamente ou implicitamente antes que a identidade possa ser usada para originar sessões de IMS e procedimentos não relacionados a sessão de IMS. Uma PUI deverá ser registrada tanto explicitamente ou

implicitamente antes que sessões de IMS de terminação e procedimentos não relacionados à sessão de IMS de terminação possam ser entregues ao UE do usuário ao qual a PUI pertence.

Deverá ser possível registrar globalmente (isto é, por um único pedido de UE) um usuário que tem mais de uma PUI por um mecanismo dentro do IMS (por exemplo usando um Conjunto de Registro Implícito). Isto não deverá impedir o usuário de registrar individualmente algumas de suas PUIs se precisado.

PUIs não são autenticadas pela rede durante registro. PUIs podem ser usadas para identificar a informação do

usuário dentro do HSS (por exemplo durante estabelecimento de sessão terminada móvel).

PUIs podem ser usadas por ASs dentro do IMS para identificar dados de configuração de serviço a serem aplicados a um usuário. Figura 1 ilustra esquematicamente relações de exemplo entre

uma assinatura de usuário (IMS) e as Identidades de Usuário Pública e Privada. No exemplo mostrado, um assinante tem duas Identidades de Usuário Privadas, com ambas estando associadas com duas Identidades de Usuário Públicas (uma das Identidades de Usuário Públicas, Identidades de Usuário Públicas 2, estando associadas com ambas as Identidades de Usuário Privadas). Um Perfil de Serviço é associado com cada Identidade de Usuário Pública, este perfil especificando dados de serviço para as Identidades de Usuário Públicas associadas. Um Perfil de Serviço é criado ou modificado quando um servidor de aplicativo é provido para um usuário no Servidor de Assinante Doméstico. Cada Perfil de Serviço inclui um ou mais Critérios de Filtro (IFC) iniciais, que são usados para ativar a provisão, ou restrição, de serviços de IMS. As diferenças entre serviços oferecidos por Perfil de Serviço 1 e Perfil de Serviço 2 são o específicas de operador, mas podem envolver servidores de aplicativo diferentes (ASs), e até mesmo esquemas de cobrança/taxação diferentes.

No exemplo, Identidade de Usuário Pública 1 está associada com um Perfil de Serviço 1, enquanto Identidade de Usuário Pública 2 e Identidade de Usuário Pública 3 estão associadas com Perfil de Serviço 2. Em um cenário típico, a Identidade de Usuário Pública 1 poderia ser uma identidade que o usuário dá aos amigos e família, por exemplo "Big_Joe@priv.operator.com", enquanto Identidade de Usuário Pública 2 e Identidade de Usuário de Pública 3 poderiam ser identidades que o usuário dá a contatos de negócio, por exemplo "+46111222333@operator.com" e i oe.black@operator.com.

3GPP define um denominado conceito de "Conjunto de Registro Implícito" para identificar um conjunto de PUIs que trabalham como um grupo, e que são registradas e des-registradas juntas quando qualquer uma das PUIs do conjunto é registrada ou des-registrada. 3GPP obriga que o HSS envie o Conjunto de Registro Implícito à S-CSCF no registro de um usuário ou na terminação uma chamada. Foi compreendido que (em registro) o HSS identifica todas as PUIs dentro do Conjunto de Registro Implícito, e então identifica todos os Perfis de Serviço associados com estas PUIs. Os Perfis de Serviço (ou dados selecionados dos Perfis de Serviço) contendo as PUIs com as quais eles estão associados, são então enviados à S-CSCF. Como resultado desta operação, a S-CSCF conhece todas as PUIs que pertencem ao mesmo Conjunto de Registro Implícito, como também seus Perfis de Serviço.

Um possível caso de uso do IMS envolve uma coleção de usuários tendo uma assinatura de nível de grupo para o IMS, mas onde os próprios usuários individuais não têm nenhuma assinatura e de qual o IMS é não ciente. No entanto, é desejável ou até mesmo necessário permitir discagem interior e exterior direta aos usuários. Isto poderia surgir, por exemplo, no caso de um empreendimento tendo uma assinatura ao IMS e tendo estações ou terminais de empregado individuais conectados a uma central telefônica privada de IP (IP-PBX). Os terminais de empregado podem ou não serem providos com clientes de SIP. No último caso, a IP-PBX executa uma tradução entre sinalização de SIP e não SIP. Enquanto poderia certamente ser possível para o IMS registrar uma PUI individual para cada terminal (dentro do mesmo Conjunto de Registro Implícito), isto se torna ineficiente quando o tamanho de grupo fica grande. ETSI TISPAN define uma tal rede corporativa como uma Rede Corporativa de Próxima Geração (NGCN).

Uma solução alternativa é ilustrada esquematicamente na Figura 2, que mostra um IP-PBX (designado "IP-PBX 2") que serve uma pluralidade de terminais de usuário, um dos quais é mostrado na Figura como "Ext. 5678". Esta solução emprega a denominada Identidade de Serviço Pública (PSI), que é pretendida para identificar serviços de IMS baseados em rede disponível publicamente, em lugar de serviço de usuário para usuário. A solução define dentro do HSS uma PSI feita curinga que casa com as PUIs especificadas para os terminais pertencendo a IP-PBX 2.

No caso de terminação, quando uma mensagem de SIP, por exemplo um CONVITE, é recebida a uma I-CSCF da rede de IMS doméstica (por uma Função de Controle de Fronteira Interconectada, I-BCF), a I-CSCF reconhecerá um URI de pedido de SIP correspondendo a um número de telefone e converterá isto a um Tel URI. No exemplo da Figura 2, o URI de pedido de SIP é "sip:+31161255678@operator2.com, user=phone", e isto é convertido ao Tel URI "Tel:+31161255678". A I-CSCF então envia uma pergunta ao HSS de acordo com procedimentos de IMS normais. O HSS determina que o Tel URI case com um curinga de PSI, e responde a I- CSCF com a identidade da S-CSCF alocada. A I-CSCF encaminha a mensagem de SIP à S-CSCF alocada, que então obtém o perfil de serviço para a PSU feita curinga do HSS. Este perfil inclui um gatilho de IFC que faz a S-CSCF rotear a mensagem a um servidor de aplicativo de Entroncamento Empresarial (BT). O servidor de aplicativo substitui o URI de pedido de SIP "Tel:+31161255678" com o endereço de IP-PBX 2, isto é "pbx2@operator2.com", e insere o endereço de destino no campo de Para cabeçalho, apagando o conteúdo prévio que está agora perdido.

r

E então necessário atravessar um complexo de CSCF de

terminação, como o URI de pedido mudou e conseqüentemente uma nova parte de terminação é visada. A mensagem então chega a uma I-CSCF adicional, que pergunta ao HSS para determinar a S-CSCF alocada ao PBX antes de entregar a mensagem a essa S-CSCF alocada. Esta S-CSCF conhece o endereço de contato para o PBX, e adiciona isto como o novo URI de pedido. A fim de preservar o URI antigo, "pbx2@operator2.com", a S-CSCF adiciona um 1P-Called-Party-Id' contendo este URI, antes de encaminhar a mensagem a uma P-CSCF e entregar para o IP-PBX 2. Opcionalmente, a segunda S-CSCF pode encaminhar a mensagem a um servidor de aplicativo adicional se gatilhos forem ativados em relação à identidade de PBX.

No caso onde o terminal de destino é um terminal de SIP, na recepção da mensagem, IP-PBX 2 pode arranjar para entrega da mensagem ao terminal baseado no endereço contido no campo de cabeçalho "Para". Se o terminal de destino não for um terminal de SIP, o terminal de IP-PBX 2 operará a terminação de acordo com alguma lógica específica de aplicativo. A solução "alternativa" ilustrada na Figura 2 tem a desvantagem que requer duas travessias de um complexo de CSCF. Isto resultará em tempos de trânsito de mensagem aumentados. Além disso, a informação contida originalmente no cabeçalho de "Para" é perdida, como é o URI de pedido original que foi inserido pelo chamador. Sem o cabeçalho de "Para" original, certos aplicativos no terminal chamado podem não funcionar.

Figura 3 ilustra uma solução alternativa para o caso de chamada de origem, isto é, onde um terminal atrás de um PBX inicia uma chamada para um terminal remoto. Neste caso, como a P-CSCF de longo curso não reconhece a 'P-Preferred-Identity' contida dentro do CONVITE enviado a ela pelo PBX, usa como um padrão 'P-Asserted-Identity' a PUI do PBX, isto é "pbxl@operatorl.com". Na S-CSCF, e IFC do perfil de serviço de PBX conta para a S-CSCF para envolver o servidor de aplicativo de BT. O servidor de aplicativo de BT valida e declara que o usuário de origem é o usuário que está identificado no cabeçalho de "De", e substitui o cabeçalho de 'P-Asserted-Identity' com a identidade do usuário chamador, isto é "tel:+31161241234". Encaminha então o CONVITE de SIP ao usuário de terminação pela S-CSCF servindo a identidade de PBX. Sumário

r

E um objetivo da presente invenção prover um procedimento e sistema que habilitam serviços de Subsistema de Multimídia de IP serem feitos disponíveis a terminais de usuário que estão localizados dentro de redes corporativas ou similares, e que não têm assinaturas individuais de Subsistema de Multimídia de IP. É um objetivo adicional da presente invenção alcançar o primeiro objetivo de uma maneira eficiente.

Estes e outros objetivos são alcançados incluindo dentro do Conjunto de Registro Implícito associado com uma assinatura, uma Identidade de Usuário Pública 'feita curinga'. "Feita curinga" ou "curinga" é compreendido aqui significar uma Identidade de Usuário Pública que contém um símbolo ou símbolo que representa um ou mais caracteres não especificados. A Identidade de Usuário Pública 'feita curinga' terá um perfil de serviço associado com ela. Qualquer nó dentro do Subsistema de Multimídia de IP que executa verificações ou processamento baseado no Conjunto de Registro Implícito, atuará em uma Identidade de Usuário Pública recebida casando uma Identidade de Usuário Pública 'feita curinga' da mesma maneira como se a Identidade de Usuário Pública recebida casasse com alguma Identidade de Usuário Pública padrão dentro do Conjunto de Registro Implícito. Em lugar de representar uma gama de Identidades de Usuário Públicas usando Identidades de Usuário Públicas 'feitas curingas', uma tal gama pode ser representada ao invés por um subdomínio. Por exemplo, uma gama de Tel URIs pode ser representada por um prefixo de discagem, enquanto uma gama de URIs de SIP pode ser representada por um domínio corporativo.

De acordo com um primeiro aspecto da presente invenção, é provido um método para facilitar acesso a serviços de uma rede de Subsistema de Multimídia de IP por terminais de usuário localizados atrás de um ponto de acesso à dita rede. O ponto de acesso está associado com uma assinatura para a rede de Subsistema de Multimídia de IP. O método compreende incluir dentro de um Conjunto de Registro Implícito definido para dita assinatura, uma Identidade de Usuário Pública 'feita curinga' ou subdomínio de Identidade de Usuário Pública representativo de uma gama de Identidades de Usuário Públicas. No registro de Subsistema de Multimídia de IP de dito ponto de acesso com a rede de Subsistema de Multimídia de IP, as Identidades de Usuário Públicas contidas no Conjunto de Registro Implícito são distribuídas a uma Função de Controle de Sessão de Chamada de Serviço alocada a dito ponto de acesso e a uma Função de Controle de Sessão de Chamada de Proxy à qual dito ponto de acesso está conectado. Concretizações da presente invenção tornam possível prover terminais de usuário localizados dentro de uma rede corporativa ou similar, e que não têm eles mesmos assinaturas de Subsistema de Multimídia de IP, com serviços Subsistema de Multimídia de IP incluindo discagem direta de chegada e partida. Nenhuma travessia complexa de S-CSCF adicional é requerida para sinalização, e, informação de cabeçalho de SIP importante é preservada. Aspectos adicionais da invenção relacionam-se a uma Função de Controle de Sessão de Chamada de Serviço, uma Função de Controle de Sessão de Chamada de Proxy, e um Servidor de Assinante Doméstico, e métodos de operar o mesmo.

De acordo com ainda outro aspecto da presente invenção, é provido um método para operar um Servidor de Assinante Doméstico de um Subsistema de Multimídia de IP. O método inclui manter em relação a uma assinatura ou serviços, dados incluindo um Conjunto de Registro Implícito contendo uma Identidade de Serviço Pública 'feita curinga' ou subdomínio de Identidade de Serviço Pública representativa de uma gama de Identidades de Serviço Públicas associadas com um serviço ou serviços, e uma identidade de uma Função de Controle de Sessão de Chamada de Serviço alocada a ditos serviços ou critérios para alocar uma Função de Controle de Sessão de Chamada de Serviço. No recebimento de um pedido de informação de local de uma Função de Controle de Sessão de Chamada de Interrogação em relação a uma mensagem de SIP recebida na Função de Controle de Sessão de Chamada de Interrogação, se a URI de pedido da mensagem casar com dita Identidade de Serviço Pública de 'feita curinga' ou subdomínio, a Função de Controle de Sessão de Chamada de Interrogação é informada da identidade da Função de Controle de Sessão de Chamada de Serviço ou provida com os critérios de seleção.

Um aspecto adicional da invenção provê para um produto de programa de computação carregável na memória interna de um computador digital, incluindo porções de código de software para executar as etapas do método acima de operar um Servidor de Assinante Doméstico. Aspectos adicionais provêem produtos de programa de computação carregáveis na memória interna de um computador digital, incluindo porções de código de software para executar as etapas de operar uma Função de Controle de Sessão de Chamada de Serviço, uma Função de Controle Sessão de Chamada de Proxy, e uma Função de Controle de Sessão de Chamada de Interrogação de acordo com a presente invenção. Breve Descrição

Figura 1 ilustra esquematicamente relações de exemplo entre uma assinatura de IMS de usuário e as Identidades de Usuário Públicas e Privadas;

Figura 2 ilustra esquematicamente uma solução de solução alternativa da arte anterior para um caso de chamada de terminação dentro de uma arquitetura de IMS;

Figura 3 ilustra esquematicamente uma solução alternativa da arte anterior para um caso de chamada de origem dentro de uma arquitetura de IMS;

Figura 4 ilustra esquematicamente uma arquitetura de rede de IMS com um fluxo de sinalização de registro de acordo com uma concretização da presente invenção;

Figura 5 ilustra uma arquitetura de rede de IMS com um fluxo de sinalização de caso de origem de acordo com uma concretização da presente invenção; e

Figura 6 ilustra uma arquitetura de rede de IMS com um fluxo de sinalização de caso de terminação de acordo com uma concretização da presente invenção.

Descrição Detalhada de Certas Concretizações

Registro de IMS consiste em duas fases. Durante uma primeira fase, a entidade registradora envia um REGISTRO de SIP para sua P-CSCF que é encaminhado por uma I-CSCF para uma S-CSCF que está alocada pelo HS S. Este registro extrai uma intimação (mensagem 401) do HSS e que é retornada à entidade registradora. Essa entidade então envia um REGISTRO adicional contendo uma resposta à intimação. No caso de um PBX (denotado IP-PBX 1) se registrando em nome de um grupo de terminais de usuário, o fluxo de sinalização associado é ilustrado na Figura 4, com o PBX aprendendo o endereço do P-CSCF externa por meio de uma consulta de DHCP. O PBX se registra usando sua própria PUI, neste exemplo "pbxl@operatorl.com". A informação de assinatura contida dentro do HSS para o PBX inclui um Conjunto de Registro Implícito como discutido acima. Como também a PUI do PBX e um tel URI: "tel:+31161251111" também alocado ao PBX, o Conjunto de Registro Implícito contém uma PUI "curinga" que representa uma gama de extensões de telefone associadas com o PBX. Neste exemplo, o curinga é denotado por "tel:+3116124!*!", onde o segmento "!*!" indica que uma PUI tendo o prefixo especificado e qualquer sufixo casará com a PUI curinga. O HSS retorna o Conjunto de Registro Implícito na Resposta de Nomeação de Servidor (sinal 17 na Figura 4) junto com os perfis de serviço associados. A S-CSCF então envia de volta o 200 OK ao PBX pela I-CSCF e P-CSCF, com o 200 OK incluindo um campo de 'P-Associated- URI' identificando as PUIs dentro do Conjunto de Registro Implícito associado com a PUI do PBX.

Em lugar do PBX executar o registro, isto poderia ser executado por uma função que registra em nome do PBX. Tal função poderia por exemplo estar localizada em um nó de fronteira tal como um Portal de Fronteira de Sinalização. O nó de fronteira pode estar localizado entre o PBX e a P-CSCF ou pode conter a P-CSCF. Outro exemplo de um dispositivo que poderia ser hospedeiro da função de registro é um Dispositivo de Acesso Integrado ou Portal Doméstico nas instalações de cliente. Considerando agora o caso onde um terminal de usuário atrás do PBX deseja originar uma chamada para um terminal remoto, e com referência à Figura 5, isto é sinalizado ao PBX pelo terminal de usuário (por exemplo usando SIP se o terminal for habilitado para SIP). O PBX então envia um CONVITE à P-CSCF servindo como Proxy externa. O PBX inclui como o cabeçalho de 'P-Preferred-Identity' a identidade (local) do usuário chamador, por exemplo "tel:+31161241234". A lógica de serviço dentro da P- CSCF é arranjada convencionalmente para validar o cabeçalho de 'P- Preferred-Identity', usando a associação de segurança previamente negociada e as PUIs do Conjunto de Registro Implícito. Além disso, determina que o cabeçalho de 'P-Preferred-Identity' casa com a PUI 'feita curinga' que previamente contida no Conjunto de Registro Implícito recebido da S-CSCF. A P-CSCF então substitui o cabeçalho de 'P-Preferred-Identity' com o cabeçalho de 'P-Asserted-Identity', usando o mesmo usuário chamador PUI5 e encaminha o CONVITE à S-CSCF pela I-CSCF. No recebimento do CONVITE, a S-CSCF determina que o cabeçalho de 'P-Asserted-Identitity' casa com a PUI 'feita curinga' pertencendo ao Conjunto de Registro Implícito (já carregado à S-CSCF com o perfil de serviço durante a fase de registro), e a S-CSCF aplicará o perfil de serviço de grupo comum usando servidores de aplicativo se necessário (Figura 5 ilustra um servidor de aplicativo de Entroncamento Empresarial por meio de exemplo). Todos os membros de grupo receberão os mesmos serviços de grupo e custos podem ser feitos contra a assinatura de grupo. A S-CSCF executa uma operação de consulta de ENUM no tel URI de pedido para identificar o domínio de operador para essa URI. Cria então o URI de SIP correspondente, neste exemplo,

"sip:+31161255678@operator2. com;user=phone", e substitui isto no CONVITE em lugar da URI de pedido

original.

Estabelecimento de chamada continua de acordo com procedimentos normais. Será notado que a URI de Pedido, De, Para, e cabeçalhos de 'P-Asserted-ID' não são alterados pela operação de manipulação de grupo (pelo menos não de qualquer maneira que seja diferente do que ocorre para usuários de não grupo normais).

Figura 6 ilustra o caso de terminação, onde um terminal remoto inicia uma chamada de IMS para um terminal de usuário atrás do PBX. Quando a I-CSCF dentro da rede de IMS doméstica do PBX recebe um pedido de CONVITE destinado para um membro de grupo (tendo neste exemplo a PUI "sip:+31161255678@operator2.com"), converterá a URI de pedido de SIP para uma URI de pedido de TEL, e executará um pedido de informação de local normal ao HS S. Quando a PUI de destino casa com um PUI 'feita curinga' dentro do Conjunto de Registro Implícito (isto é "tel:+3116125!*!"), a I-CSCF encaminhará o pedido à S-CSCF que foi alocada ao perfil do usuário de grupo. Na S-CSCF, a operação de pedido inicial de terminação normal é executada, e depois de executar qualquer serviço de grupo requerido (utilizando um ou mais servidores de aplicativo tal como o servidor de aplicativo de entroncamento empresarial ilustrado), a URI de pedido dentro do CONVITE é substituída com o endereço de contato do PBX, isto é, "pbx2-contact-adress". A identidade de membro de grupo de terminação discada original é retida no cabeçalho de 'P-Called-Party-ID'. Como com o caso de origem (Figura 5), a URI de Pedido, Para, De, e 'P- Asserted-Id não são alterados pela operação de operação de grupo de uma maneira daquela que ocorre para membros de não grupo.

Na recepção deste CONVITE, o PBX pode encaminhar o pedido para um membro de grupo habilitado para SIP, por exemplo, usando o valor de 'P-Called-Pary-ID' para construir uma URI de pedido, removendo o 'P-Called-Party-ID', e encaminhando isto dentro da rede do grupo.

Em lugar do PBX executar a reconstrução da URI de Pedido, isto poderia ser executado por uma função que executa a reconstrução antes que o CONVITE seja encaminhado ao PBX. Tal função poderia estar localizada por exemplo em um nó de fronteira tal como um Portal de Fronteira de Sinalização. O nó de fronteira pode estar localizado entre o PBX e a P-CSCF, ou pode conter a P-CSCF. Outro exemplo de um dispositivo que poderia hospedar desta função é um Dispositivo de Acesso Integrado ou Portal Doméstico nas instalações de cliente.

Será apreciado pela pessoa de habilidade na arte que várias modificações podem ser feitas às concretizações descritas acima sem partir da extensão da presente invenção. A abordagem descrita acima pode ser aplicada, por exemplo, para habilitar a inclusão dentro de um Conjunto de Registro Implícito de uma Identidade de Serviço Pública 'feita curinga' ou subdomínio de Identidade de Serviço Pública.

Claims (15)

1. Método para facilitar acesso a serviços de uma rede de Subsistema de Multimídia de IP por terminais de usuário localizados atrás de um ponto de acesso à dita rede, o ponto de acesso estando associado com uma assinatura à rede de Subsistema de Multimídia de IP, caracterizado pelo fato de que compreende: incluir dentro de um Conjunto de Registro Implícito definido para dita assinatura, uma Identidade de Usuário Pública 'feita curinga1 ou subdomínio de Identidade de Usuário Pública representativa de uma gama de Identidades de Usuário Públicas; e no registro de Subsistema de Multimídia de IP de dito ponto de acesso com a rede de Subsistema de Multimídia de IP, distribuir as Identidades de Usuário Públicas contidas no Conjunto de Registro Implícito a uma Função de Controle de Sessão de Chamada de Serviço alocada a dito ponto de acesso e a uma Função de Controle de Sessão de Chamada de Proxy à qual dito ponto de acesso está conectado.

2. Método de acordo com reivindicação 1, caracterizado pelo fato de que dito Conjunto de Registro Implícito incluindo pelo menos uma Identidade de Usuário Pública explícita de dito ponto de acesso.

3. Método de acordo com reivindicação 1 ou 2, caracterizado pelo fato de que dito ponto de acesso é uma Central Telefônica de Ramal Privado de IP.

4. Método de acordo com qualquer uma das reivindicações precedentes, caracterizado pelo fato de que dito Conjunto de Registro Implícito é mantido dentro de um Servidor de Assinante Doméstico do Subsistema de Multimídia de IP, e é provido à Função de Controle de Sessão de Chamada de Serviço no registro dentro de uma Resposta de Nomeação de Servidor enviada pelo Servidor de Assinante Doméstico, e para a Função de Controle de Sessão de Chamada de Proxy em um cabeçalho de P-Associated- URI de um 200 OK enviado da Função de Controle de Sessão de Chamada de Serviço.

5. Método de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que dito Conjunto de Registro Implícito é mantido dentro de um Servidor de Assinante Doméstico do Subsistema de Multimídia de IP, e é provido à Função de Controle de Sessão de Chamada de Serviço depois que dita assinatura é modificada, dentro de um Pedido de Perfil de Impulso enviado pelo Servidor de Assinante Doméstico.

6. Método para operar uma Função de Controle de Sessão de Chamada de Proxy de uma rede de Subsistema de Multimídia de IP, caracterizado pelo fato de que inclui: no registro de um ponto de acesso tendo uma assinatura à rede de Subsistema de Multimídia de IP, receber e armazenar um Conjunto de Registro Implícito para o ponto de acesso, o Conjunto de Registro Implícito incluindo uma Identidade de Usuário Pública 'feita curinga' ou subdomínio de Identidade de Usuário Pública representativa de uma gama de Identidades de Usuário Públicas; receber uma mensagem de Protocolo de Iniciação de Sessão de dito ponto de acesso; se o cabeçalho de 'P-Preferred-Identity' de dita mensagem casar com dita Identidade de Usuário Pública feita curinga ou subdomínio, substituir o cabeçalho de 'P-Preferred-Identity' com um cabeçalho de 'P- Asserted-Identity' contendo o mesmo Identificador de Recurso Universal; e encaminhar a mensagem para uma Função de Controle de Sessão de Chamada de Interrogação.

7. Método para operar uma Função de Controle de Sessão de Chamada de Serviço de um Subsistema de Multimídia de IP, caracterizado pelo fato de que inclui: no registro de um ponto de acesso tendo uma assinatura à rede de Subsistema de Multimídia de IP, receber e armazenar um Conjunto de Registro Implícito para o ponto de acesso, o Conjunto de Registro Implícito incluindo uma Identidade de Usuário Pública 'feita curinga' ou subdomínio de Identidade de Usuário Pública representativa de uma gama de Identidades de Usuário Públicas, e um perfil de serviço associado com dita Identidade de Usuário Pública 'feita curinga' ou subdomínio; receber uma mensagem de SIP a) se originando de ou b) destinada para um terminal de usuário localizado atrás de dito ponto de acesso;e se a P-Asserted-Identity' de dita mensagem no caso de a) ou o Indicador de Recurso Universal de pedido de dita mensagem no caso b) casar com dita Identidade de Usuário Pública ou 'feita curinga' subdomínio, aplicar procedimentos de IMS padrão de acordo com o perfil de serviço associado.

8. Método para operar um Servidor de Assinante Doméstico de um Subsistema de Multimídia de IP, caracterizado pelo fato de que inclui: para um ponto de acesso servindo uma pluralidade de terminais de usuário, manter dados de assinante incluindo um Conjunto de Registro Implícito contendo uma Identidade de Usuário Pública 'feita curinga' ou subdomínio de Usuário Identidade Pública representativa de uma gama de Identidades de Usuário Públicas associadas com ditos terminais de usuário, e uma identidade de uma Função de Controle de Sessão de Chamada de Serviço alocada a dito nó de acesso ou critérios para alocar uma Função de Controle de Sessão de Chamada de Serviço; e no recebimento de um pedido de informação de local de uma Função de Controle de Sessão de Chamada de Interrogação em relação a uma mensagem de SIP recebida na Função de Controle de Sessão de Chamada de Interrogação, se o URI de pedido da mensagem casar com dita Identidade de Usuário Pública ou 'feita curinga' subdomínio, informar a Função de Controle de Sessão de Chamada de Interrogação da identidade da Função de Controle de Sessão de Chamada de Serviço ou provê-la os critérios de seleção.

9. Método para operar um Servidor de Assinante Doméstico de um Subsistema de Multimídia de IP, caracterizado pelo fato de que inclui: para um ponto de acesso servindo uma pluralidade de terminais de usuário, manter dados de assinante incluindo um Conjunto de Registro Implícito contendo um Identidade de Usuário Pública 'feita curinga' ou subdomínio de Identidade de Usuário Pública representativa de uma gama de Identidades de Usuário Públicas associadas com ditos terminais de usuário; e prover dita a uma ou mais de uma Função de Controle de Sessão de Chamada de Interrogação, uma Função de Controle de Sessão de Chamada de Serviço, e uma Função de Controle de Sessão de Chamada de Proxy.

10. Método de acordo com reivindicação 9, caracterizado pelo fato de que o Conjunto de Registro Implícito é provido no registro de uma β assinatura para dito ponto de acesso, ou no recebimento de um pedido de estabelecimento de sessão quando dita assinatura é não registrada.

11. Método de acordo com reivindicação 10, caracterizado pelo fato de que o Conjunto de Registro Implícito é provido no recebimento de um pedido de estabelecimento de sessão quando dita assinatura é não registrada, o método ademais compreendendo primeiro casar um URI de pedido de dito pedido contra dita Identidade de Usuário Pública feita curinga ou subdomínio de Identidade de Usuário Pública, e prover dito Conjunto de Registro Implícito se um casamento for confirmado.

12. Computador adaptado para implementar uma Função de Controle de Sessão de Chamada de Proxy para uso em uma rede de Subsistema de Multimídia de IP, caracterizado pelo fato de que inclui: meio arranjado, no registro de um ponto de acesso tendo uma assinatura à rede de Subsistema de Multimídia de IP, para receber e armazenar um Conjunto de Registro Implícito para o ponto de acesso, o Conjunto de Registro Implícito incluindo uma Identidade de Usuário Pública 'feita curinga' ou subdomínio de Identidade de Usuário Pública representativa de uma gama de Identidades de Usuário Públicas; meio para receber uma mensagem de Protocolo de Iniciação de Sessão de dito ponto de acesso; meio arranjado, se o cabeçalho de 'P-Preferred-Identity' de dita mensagem casar com dita Identidade de Usuário Pública ou feita curinga subdomínio, para substituir o cabeçalho de 'P-Preferred-Identity' com um cabeçalho de 'P-Asserted-Identity' contendo o mesmo Identificador de Recurso Universal; e meio para encaminhar a mensagem para uma Função de Controle de Sessão de Chamada de Interrogação.

13. Computador adaptado para implementar uma Função de Controle Sessão de Chamada de Serviço para uso em um Subsistema de Multimídia de IP, caracterizado pelo fato de que inclui: meio arranjado, no registro de um ponto de acesso tendo uma assinatura à rede de Subsistema de Multimídia de IP, para receber e armazenar um Conjunto de Registro Implícito para o ponto de acesso, o Conjunto de Registro Implícito incluindo uma Identidade de Usuário Pública feita curinga ou subdomínio de Identidade de Usuário Pública representativa de uma gama de Identidades de Usuário Públicas, e um perfil de serviço associado com dita Identidade de Usuário Pública feita curinga ou subdomínio; meio para receber uma mensagem de SIP a) se originando de ou b) destinada para um terminal de usuário localizado atrás de dito ponto de acesso;e meio arranjado, se a 'P-Asserted-Identity' de dita mensagem no caso a) ou o Indicador de Recurso Universal de pedido de dita mensagem no caso b) casar com dita Identidade de Usuário Pública feita curinga ou subdomínio, aplicar lógica de serviço padrão incluindo o perfil de serviço associado.

14. Computador adaptado para implementar um Servidor de Assinante Doméstico de um Subsistema de Multimídias de IP, caracterizado pelo fato de que inclui: meio adaptado, para um ponto de acesso servindo uma pluralidade de terminais de usuário, para manter dados de assinante incluindo um Conjunto de Registro Implícito contendo uma Identidade de Usuário Pública 'feita curinga' ou subdomínio de Identidade Usuário Pública representativa de uma gama de Identidades de Usuário Públicas associadas com ditos terminais de usuário, e uma identidade de uma Função de Controle de Sessão de Chamada de Serviço alocada a dito nó de acesso ou critérios para alocar uma Função de Controle de Sessão de Chamada de Serviço; e meio adaptado, no recebimento de um pedido de informação de local de uma Função de Controle de Sessão de Chamada de Interrogação em relação a uma mensagem de SIP recebida na Função de Controle de Sessão de Chamada de Interrogação, para determinar se o URI de pedido da mensagem casa com dita Identidade de Usuário Pública feita curinga ou subdomínio, e nesse caso informar a Função de Controle de Sessão de Chamada de Interrogação da identidade da Função de Controle de Sessão de Chamada de Serviço ou provê-la com os critérios de seleção.

15. Método para operar um Servidor de Assinante Doméstico de um Subsistema de Multimídia de IP, caracterizado pelo fato de que inclui: manter em relação a uma assinatura ou serviços, dados incluindo um Conjunto de Registro Implícito contendo uma Identidade de Serviço Pública 'feita curinga' ou subdomínio de Identidade de Serviço Pública representativa de uma gama de Identidades de Serviço Públicas associadas com um serviço ou serviços, e uma identidade de uma Função de Controle de Sessão de Chamada de Serviço alocada a ditos serviços ou critérios para alocar uma Função de Controle de Sessão de Chamada de Serviço; e no recebimento de um pedido de informação de local de uma Função de Controle de Sessão de Chamada de Interrogação em relação a uma mensagem de SIP recebida na Função de Controle de Sessão de Chamada de Interrogação, se o URI de pedido da mensagem casar com dita Identidade de Serviço Pública 'feita curinga' ou subdomínio, informar a Função de Controle de Sessão de Chamada de Interrogação da identidade da Função Controle de Sessão de Chamada de Serviço ou provê-la com os critérios de seleção.