BRPI0717609A2

BRPI0717609A2 - Sistema e método para fornecer serviços combinacionais a chamadores anônimos

Info

Publication number: BRPI0717609A2
Application number: BRPI0717609-0A
Authority: BR
Inventors: Apostolis K Salkintzis; Michael F Coulas
Original assignee: Motorola Inc
Priority date: 2006-10-16
Filing date: 2007-10-15
Publication date: 2013-10-22
Also published as: US20090239513A1; WO2008048939A3; MX2009007030A; CN101529883B; CN101529883A; KR101051826B1; US20080090556A1; KR20090068252A; ES2451499T3; EP1914973B1; BRPI0717609A8; WO2008048939A2; US9699220B2; EP1914973A1

Description

SISTEMA E MÉTODO PARA FORNECER SERVIÇOS COMBINACIONAIS A

CHAMADORES ANÔNIMOS

HISTÓRICO

Os consumidores hoje utilizam um grande número de serviços de comunicação móvel. Esses serviços incluem, sem a eles se limitar, serviços de voz tradicionais, partilhamento de vídeo, partilhamento de arquivos, mensagens de multimídia, mensagens instantâneas, quadro branco, e assemelhados.

Muitas vezes, os consumidores desejam utilizar dois ou

mais serviços ao mesmo tempo. Duas partes podem querer ter uma chamada de voz enquanto visualizam um vídeo partilhado ou colaboram em um documento partilhado. Os consumidores também querem ser capazes de se deslocar com facilidade

entre os serviços. Por exemplo, duas partes tendo uma chamada de voz tradicional podem querer mudar a chamada para uma chamada de vídeo. No entanto, por demais das vezes o estado atual da tecnologia torna essas trocas impossíveis.

2 0 Por exemplo, uma parte pode não saber a identidade de

outra parte por causa da invocação de Calling Line Identification Restriction (CLIR - Restrição à Identificação da Linha Chamadora) durante o estabelecimento de uma chamada de voz CS. Se isso ocorrer, a parte chamada.

não saberá a identidade da parte que chama. A parte que chama não será capaz de invocar uma sessão IMS com a parte que chama, pois a parte chamada não será capaz de enviar uma mensagem convite para a parte que chama. Em outro caso, o usuário poderá chamar um serviço de auxílio na estrada ao

3 0 colocar uma chamada CS normal para o número do serviço. O serviço de auxílio na estrada então seleciona dinamicamente um terminal (agente) disponível para terminar a chamada CS. Se o usuário deseja estabelecer uma sessão IMS (digamos, uma sessão de partilhamento de vídeo, ou de quadro branco) com o representativo de auxílio na estrada, o usuário tentará iniciar a sessão IMS com o serviço de auxílio na estrada (por exemplo, sip:1154@operator.com). No entanto, como o usuário não conhece a identidade do terminal exato do operador, o serviço IMS não será estabelecido. Em outro caso, o usuário pode querer transferir uma chamada CS para uma rede IMS, mas se o usuário não sabe a identidade da outra parte, tal transferência não será possível. Assim, o que é necessário é uma abordagem pela qual serviços em um primeiro domínio são acoplados a serviços em um segundo domínio.

DESCRIÇÃO SUCINTA DOS DESENHOS

Para a finalidade de facilitar a compreensão da matéria que se procura ser protegida, há versões ilustrativas nos desenhos acompanhantes, de uma inspeção dos quais, quando considerados à luz da descrição seguinte e das reivindicações, a matéria que se procura seja protegida, sua construção e operação, e muitas de suas vantagens devem ser prontamente compreendidas e apreciadas. A Figura 1 mostra uma versão exemplar de um sistema que inclui um primeiro dispositivo e um segundo dispositivo que são capazes de um intercâmbio de dados tanto em um primeiro domínio como em um segundo domínio.

A Figura 2 mostra o sistema na Figura 1 com o segundo domínio mostrado em maior detalhe. 3 0 A Figura 3 é um diagrama de blocos funcionais exemplar do servidor de aplicação da Figura 2.

A Figura 4 é um fluxograma que descreve a operação exemplar do sistema da Figura 1.

A Figura 5 é um fluxograma que fornece uma descrição exemplar da criação de um contexto de chamada no sistema da Figura 1.

A Figura 6 mostra outra versão exemplar do sistema da Figura 1.

A Figura 7 é um diagrama de sinais que fornece a operação exemplar descrita do sistema da Figura 6. DESCRIÇÃO DETALHADA

Em um exemplo, é fornecido um método. Uma notificação é recebida de uma chamada de um primeiro dispositivo para um segundo dispositivo em um primeiro domínio. Um contexto de chamada é criado para o primeiro tipo de chamada. Uma notificação é recebida da iniciação de uma chamada do segundo dispositivo para o primeiro dispositivo em um segundo domínio. 0 contexto de chamada é utilizado para notificar o primeiro dispositivo da iniciação da chamada do segundo dispositivo para o primeiro dispositivo.

Em outro exemplo, um sistema é fornecido. Um primeiro componente de interface recebe uma notificação de uma chamada de um primeiro dispositivo para o segundo dispositivo em um primeiro domínio. Um componente de criação de contexto cria um contexto de chamada para o primeiro tipo de chamada. Um segundo componente de interface recebe uma notificação da iniciação de uma chamada do segundo dispositivo para o primeiro dispositivo em um segundo domínio. Um componente de notificação utiliza o contexto de chamada para notificar o primeiro dispositivo da iniciação da chamada do segundo dispositivo para o primeiro dispositivo.

Com referência à Figura 1, um sistema 10 em um exemplo compreende um primeiro dispositivo 11, um segundo dispositivo 12, um primeiro domínio 13, e um segundo domínio 14.

Os dispositivos 11, 12 em um exemplo são quaisquer dispositivos adequados operativos para enviar e receber dados de acordo com a operação de um sistema de comunicação sem fio. Exemplos dos dispositivos 11, 12 incluem, mas sem a eles se limitar, telefones celulares, telefones móveis, dispositivos de radiochamada, rádios, assistentes digitais pessoais (PDAs), terminais de dados móveis, computadores laptop, dispositivos de jogos específicos da aplicação, dispositivos de jogos de vídeo que incorporam modems sem fio, e combinações ou sub-combinações desses dispositivos. Esses dispositivos geralmente incluem componentes como processadores, controladoras, componentes de memória, dispositivos de interface de usuário, lógica de transmissão de dados, interfaces de redes, antenas, e assemelhados. O projeto e a operação desses dispositivos são bem conhecidos de modo que uma descrição detalhada de cada possibilidade será omitida.

Os domínios 13, 14, referem-se, cada um, a um ambiente em que pelo menos um serviço é fornecido. Cada domínio 13, 14 poderia ser compreendido de uma ou mais redes. Essas redes incluem, sem a elas se limitar, as redes GSM, GPRS, CDMA, IDEN, 2,5G, 3G, e WiMAX (802.16c). Além disso, os domínios 13, 14 poderiam fazer parte da mesma rede. Para os fins desta revelação, cada domínio 13, 14 será de SCz-Xto como fornecendo pelo menos um serviço que é distinto do outro domínio. Por exemplo, o domínio 13 poderia ser uma rede comutada por circuito (CS) em que o serviço de voz CS tradicional é fornecido e o domínio 14 poderia ser uma rede IP Subsistema de Multimídia (IMS) em que serviços, como partilhamento de vídeo e quadro branco, são fornecidos. O domínio 13 poderia ser compreendido de uma pluralidade de redes que fornecem serviço de voz CS, e o domínio 14 poderia ser compreendido de uma pluralidade de redes que fornecem serviço IMS. Além disso, os domínios 13, 14 poderiam fazer parte de uma única rede, como a rede GSM, que suporta tanto os serviços CS como os serviços IMS (isto é, o domínio 13 é um domínio CS dentro de uma rede GSM e o domínio 14 é um domínio IMS dentro da mesma rede GSM) . Com referência à Figura 2, uma descrição mais

detalhada, mas exemplar, do sistema 10 será fornecida agora para fins ilustrativos. Mais uma vez, para fins ilustrativo o domínio 13 será referido como o domínio CS e o domínio 14 será referido como o domínio IMS. No entanto, tal descrição não deve ser interpretada como limitando a aplicação atual a esta versão.

Com referência ainda à Figura 2, o domínio IMS 14 inclui um servidor de aplicação 21 e um servidor de função de controle 22. Em um exemplo, o servidor de aplicação 21 é 2 5 um Servidor de Aplicação de Identidade Comutado por Circuito (CSI-AS) e o servidor de função de controle 22 é um servidor de Função de Controle de Sessão de Servidor- Chamada (S-CSCF).

Como será discutido a mais aqui, o CSI-AS 21 recebe notificações do domínio CS 13, de chamadas de voz que envolvem o dispositivo 12 e cria contexto para as chamadas que permite que o dispositivo 12 invoque serviços no domínio IMS 14 que são acoplados de perto às chamadas de voz no domínio CS 13.

Em um exemplo, o servidor S-CSCF 22 é um servidor de

protocolo de iniciação de sessão (SIP). S-CSCF fornece controle para usuários do domínio IMS 14. Ele interage com a rede em prol do usuário e é alocado ao usuário durante o processo de registro SIP. 0 servidor de aplicação 21 e o servidor de função de

controle 22, em um exemplo, são formados de um ou mais componentes de software de computador e/ou de lógica de hardware. Um número desses componentes pode ser combinado ou dividido. Em um exemplo, um componente exemplar de cada dispositivo emprega e/ou compreende uma série de instruções de computador escritas ou implementadas com qualquer um de um número de linguagens de programação, como será apreciado por aqueles habilitados na tecnologia.

Com referência à Figura 3, componentes de CSI-AS 21 incluem componentes de interface 31, 32, um ou mais casos de componente de processador 33, um ou mais casos de componente de memória 34, estrutura de dados 35, componente de criação de contexto 36, componente de notificação 37, e componente de comunicação de referência de chamada 38. 0 componente de interface 31 em um exemplo é utilizado

pelo CSI-AS 21 para enviar dados de/para o primeiro domínio 13. 0 componente de interface 32 em um exemplo é utilizado para enviar dados d/para S-CSCF 22. O componente do processador 33 governa e realiza a funcionalidade do CSI-AS 21 ao executar código incorporado em hardware e/ou software. 0 componente de memória 34 fornece armazenamento em que dados, instruções, rotinas de software, conjuntos de código, bases de dados, etc., podem ser armazenados. Estrutura de dados 35 em um exemplo é utilizada para armazenar informação de contexto de chamada gerada quando os dispositivos 11, 12 engajam em chamadas no domínio CS 13. A estrutura de dados 35 poderá ser armazenada na memória 34 ou poderá ser um elemento individual. O componente de criação de contexto 36 é utilizado para criar um contexto de chamada quando o dispositivo 11 fizer uma chamada CS ao dispositivo 12. 0 componente de notificação 37 é utilizado para notificar o dispositivo 11 quando o dispositivo 12 faz uma chamada para o dispositivo 11 através do segundo domínio 14. 0 componente de comunicação de referência de chamada 3 8 é utilizado para enviar uma referência de chamada para o dispositivo 12 após um contexto de chamada ser criado. 0 componente de criação de contexto 36, o componente de notificação 37, e o componente de comunicação de referência de chamada 3 8 em um exemplo são executados no processador 33 e podem ser armazenados na memória 34, ou em outro lugar.

Por exemplo, em um exemplo, o sistema 10 inclui pelo menos um meio portador de sinal lido por computador 39. Um exemplo de um meio portador de sinal lido por computador 3 9 é um meio de armazenamento de dados graváveis como um meio de armazenamento de dados em escala magnética, óptica e/ou atômica. Em outro exemplo, um meio portador de sinal lido por computador 3 9 é um sinal de portadora modulado transmitido por uma rede acoplado ao CSI-AS 21. Um meio 3 0 portador de sinal lido por computador 3 9 pode armazenar componentes de lógica de software que são empregáveis para realizar a funcionalidade aqui descrita.

Com referência à Figura 4, um método exemplar 4 00 de operação do sistema 10 será descrito agora para fins exemplares.

Na etapa 401, CSI-AS 21 recebe uma notificação do domínio CS 13 de que o dispositivo 11 colocou uma chamada CS para o dispositivo 12 no primeiro domínio 13. Em um exemplo, o domínio CS 13 é uma rede GSM. A sinalização de estabelecimento de chamada CC GSM no MSC terminador (o dispositivo servidor 12, mas não mostrado) dispara uma mensagem DP inicial Customized Applications for Mobile Network Enhanced Logic (CAMEL - Lógica Aprimorada de Rede Móvel para Aplicações Personalizadas) no sentido da Função de Controle de Serviço GSM (gsmSCF) do CSI-AS 21. Por sua vez, o gsmSCF envia uma resposta CAMEL dirigindo o MSC para continuar o estabelecimento da chamada.

Em resposta à sinalização CAMEL, o CSI-AS 21 cria um contexto para a chamada CS na etapa 4 03. Com referência à Figura 5, na etapa 501, o CSI-AS 21 extrai a ID do primeiro dispositivo 11 da notificação recebida do primeiro domínio 13. Em um exemplo, isso é informação de identificador de chamador (CLID) da chamada CS do primeiro dispositivo 11 para o segundo dispositivo. Deve ser observado que se o dispositivo 11 invocasse CLIR, a informação CLID não estaria disponível para o dispositivo 12. Entretanto, a informação CLID estará disponível para a rede do primeiro domínio 13. Assim, o MSC terminador fornecerá a informação CLID para o CSI-AS 21. Na etapa 503, o CSI-AS 21 cria uma referência de chamada. Em um exemplo, a referência de chamada é gerada pelo CSI-AS 21 utilizando um Universally Unique IDentifier (UUID - Identificador Universalmente Singular) Uniform Resource Name (URN - Nome de Recurso Uniforme) , conforme especificado no Request for Comments (RFC - Solicitação para Comentários) 4122, que é aqui incorporado por referência. O UUID URN permite a computação não- centralizada de um URN com base em tempo, nomes singulares, ou um gerador de número aleatório e garante singularidade através do espaço e do tempo. Uma referência de chamada exemplar é: urn:uuid:f81d4fac-7dec-IldO-a765-00a0c91c6bf6 .

0 contexto de chamada não é limitado a uma referência de chamada e um identificador. Informação adicional poderia ser acrescentada ao contexto de chamada. Por exemplo, a informação de chamada, como números de telefone das partes que chama e que é chamada, um número de telefone da parte que redirecional, estado de invocação CLIR, informação contida em User-user IEs, e qualquer outra informação importante contida nas mensagens de sinalização CC. Esta informação adicional poderia ser obtida pelo CSI-AS 21 através da sinalização CAMEL. Também poderá ser possível para o CSI-AS 21 obter informação adicional de outros Servidores de Aplicações IMS que armazenam a informação da chamada CS, como a Voice Call Continuity (VCC) AS, por exemplo.

Com referência ainda à etapa 5 05, o contexto de chamada em um exemplo é armazenado em estrutura de dados 3 5 tal que a referência de chamada corresponde ao identificador para o primeiro dispositivo 11. Por exemplo, a referência de chamada e o identificador poderiam ser armazenados em uma tabela de dados.

Com referência agora à Figura 4, na etapa 4 05, a referência de chamada é enviada para o segundo dispositivo 12. Conseqüentemente, se o dispositivo 12 quer fazer invocar uma chamada IMS para o dispositivo 11, o dispositivo 12 não precisa conhecer a identidade do dispositivo 11. Em vez disso, o dispositivo 12 pode iniciar uma chamada IMS através do CSI-AS 21 que tem a referência cruzada da identidade do dispositivo 11 com a referência de chamada.

CSI-AS 21 pode implementar a etapa 4 05 em um número de maneiras. Em um exemplo, o CSI-AS 21 inicia uma sessão Unstructured Supplementary Service Data (USSD - Dados de Serviço Suplementar Não-Estruturado) com o dispositivo 12 e envia a referência de chamada dentro da sessão. Em outro exemplo, o CSI-AS 21 envia a referência de chamada para o segundo dispositivo 12 em uma mensagem short message service (SMS - Serviço de Mensagem Curta) . Em mais um exemplo, o segundo dispositivo 12 solicita a referência de chamada do CSI-AS 21 pela Internet através de uma interface da Web (por exemplo, uma interface WAP) . Em ainda outro exemplo, um pacote de evento SIP pode ser utilizado tal que o segundo dispositivo 12 recebe uma mensagem SIP NOTIFY do CSI-AS que inclui a referência de chamada. Uma discussão mais detalhada do pacote de evento SIP será aqui discutido mais adiante.

Com referência ainda à Figura 4, como outra alternativa, em vez de enviar a referência de chamada para o segundo dispositivo 12, o segundo dispositivo 12 e o CSI- AS 21 poderiam, cada um, gerar uma referência de chamada utilizando o mesmo conjunto de regras. Por exemplo, a referência de chamada poderia conter a informação seguinte: (1) A identidade móvel (por exemplo, TMSI ou IMSI) atualmente em uso pela parte chamada quando ela aceitou a chamada (por exemplo, em PAGING REQUEST) ; e (2) o DTAP CC Transaction ID (TI) gerado pela rede e incluído na solicitação CC Setup enviada à parte chamada (identifica a chamada CS específica para o móvel).

Continuando com a referência à Figura 4, na etapa 4 07, o CSI-AS 21 recebe uma notificação de que o segundo dispositivo 12 deseja iniciar uma chamada IMS com o primeiro dispositivo 11.

Em um exemplo, o dispositivo 12 envia a solicitação para o CSI-AS 21 ao endereçar uma solicitação SIP para a referência de chamada da chamada CS. Tal solicitação SIP pode ser gerada utilizando um SIP URI (por exemplo, SIP:combinational.operador.com) com um parâmetro

vcallref=<callreference>' para identificar a referência de chamada (por exemplo,

SIP:combinational.operator . com; callref = <callreference>) . O S-CSCF 22 no domínio IMS 14 aplica Initial Filter Criteria (iFC) para P-Asserted-Identity à solicitação SIP e quando do casamento do SIP URI, encaminha a solicitação SIP para o CSI-AS 21. 0 CSI-AS 21 então tecla <callreference> e re- direciona a solicitação para o número de telefone do dispositivo 11.

Em outro exemplo, o segundo dispositivo 12 endereça uma solicitação para o PSI do CSI-AS 21 com um parâmetro 1callref=<callreference>' para identificar a referência de chamada e um parâmetro 'combinational' ou λremote-party' para indicar que a parte remota da chamada CS está sendo endereçada. Por exemplo,

SIP:<CSI_AS_PSI>.operator.com;callref=<callreference>; combinational ou

SIP:<CSI_AS_PSI>.operator.com;callref=<callreference> ; remote-party

Neste caso, o SIP Request é roteado diretamente para o CSI-AS 21 (não há necessidade de iFC) . O CSI-AS 21 então tecla <callreference> e redireciona a solicitação para o número de telefone do dispositivo 11. Um AS PSI precisa ser provisionado no terminal.

Em outro exemplo, a referência de chamada é embutida em um PSI carta-curinga gerenciado pelo CSI-AS 21. A solicitação é então endereçada para o PSI carta-curinga com um parâmetro 'combinational' ou 'remote-party' para indicar que a parte remota da chamada CS está sendo endereçada. Por exemplo:

SIP:<CALL_REF_PSI>.operator.com;combinational 2 0 ou

SIP:< CALL_REF_PSI>.operator.comremote-party

Neste caso, o SIP Request é roteado diretamente para o CSI-AS 21 onde o PSI carta-curinga é gerenciado. 0 CSI-AS então tecla na chamada CS referenciada pelo PSI carta- curinga e redireciona a solicitação para o número de telefone do dispositivo 11.

Finalmente, deve-se observar que o CSI-AS 21 apaga a chamada quando as partes terminam a chamada CS e o domínio CS 13 libera a chamada CS. Por exemplo, em uma rede GSM, a sinalização de liberação de chamada CC GSM no MSC terminador inicia a sinalização CAMEL no sentido da função gsmSCF do CSI-AS 21. Em resposta à sinalização CAMEL, o CSI-AS 21 apaga o contexto para a chamada CS.

Com referência à Figura 6, um pacote de evento SIP será aqui agora descrito. Outra versão do sistema 10 é mostrado em que um ou mais dispositivos IMS 15 podem assinar a um pacote de eventos SIP, que notificará os dispositivos IMS 15 quando um ou mais dispositivos CS. O sistema 10 é mostrado na Figura 6, como incluindo o dispositivo IMS 15, além do primeiro dispositivo 11 e do segundo dispositivo 12. Mais uma vez, o domínio 13 é descrito como um domínio CS e o domínio 14 é descrito como um domínio IMS. No entanto, a presente aplicação deve ser interpretada como limitada a esta versão. 0 primeiro dispositivo 11 e o segundo dispositivo 12

são mostrados como conectados ao domínio CS e o dispositivo é mostrado como um dispositivo IMS conectado ao domínio IMS 14. Deve-se observar que esta disposição é fornecida apenas para fins ilustrativos. Diferentes combinações e sub-combinações dos dispositivos 11, 12, e 15 são previstos. Por exemplo, os dispositivos 11, 12 poderiam cada um deles incluir capacidade IMS e o dispositivo 15 poderia incluir capacidade CS. Assim, o pacote de evento SIP descreve doravante os dispositivos 11, 12. No entanto, por questão de clareza, o pacote de eventos SIP será descrito com relação ao dispositivo 15. Ademais, deve-se observar que os usuários do primeiro domínio 13 e do segundo domínio 14 poderiam, cada um deles, ter múltiplos dispositivos IMS, que assinam o pacote de eventos SIP aqui descrito, para um ou mais dispositivos CS possuídos, mas por questão de brevidade, apenas os dispositivos 11, 12 e são mostrados.

0 pacote de evento SIP em um exemplo é um CS Calling Services Event Package (Pacote de Evento de Serviços de Chamada CS) ao qual o usuário de um dispositivo IMS (por exemplo, o dispositivo 15) pode assinar. Ao assinar o SIP Calling Service Event Package (doravante referido como λ o pacote SIP'), o usuário do dispositivo 15 pode informar o CSI-AS 21 do segundo domínio para notificar o dispositivo quando serviços específicos forem iniciados no primeiro domínio 13. Por exemplo, o dispositivo 15 pode solicitar que o CSI-AS 21 notifique o dispositivo 15 quando uma chamada de voz CS é terminada para um dispositivo particular (por exemplo, o dispositivo 11 ou o dispositivo 12) . O CSI-AS 21 então identificará e manterá informação sobre a chamada CS e fornecerá informação da chamada CS para o usuário do dispositivo 15.

Deve-se observar que se o dispositivo 15 e o dispositivo de interesse no domínio CS (por exemplo, o dispositivo 11 ou o dispositivo) for de propriedade do mesmo usuário, então assinar o pacote SIP e direto de um ponto de vista da segurança. De modo similar, se o dispositivo de interesse e o dispositivo 15 fossem o mesmo dispositivo (por exemplo, uma unidade móvel com capacidade CS e IMS), então assinar o pacote SIP seria direto de uma perspectiva de segurança. No entanto, se o dispositivo de interesse e o dispositivo 15 fossem dispositivos separados e possuídos por usuários separados, então do ponto de vista da segurança, valeria a pena fornecer um mecanismo para verificar que o dispositivo 15 está autorizado a assinar à informação da chamada CS relacionada ao dispositivo de interesse. Por exemplo, uma senha poderia ser exigida para que a assinatura entrasse em vigor, ou o proprietário do dispositivo em questão pode precisar fornecer ao sistema uma autorização explícita para permitir que o dispositivo assine, ou o proprietário do dispositivo poderia ter uma opção de ligar ou desligar os parâmetros de segurança, e assim por diante.

0 pacote SIP fornece uma aplicação concreta da estrutura de eventos SIP especificada na RFC 3265, que é aqui incorporada por referência, e define os eventos e a informação relacionada às chamadas CS do usuário ao qual o usuário IMS poderá assinar. 0 pacote de eventos CS Calling Services pode notificar o assinante dos eventos, como a chamada CS envolvendo o assinante sendo estabelecido (neste caso, informação sobre a chamada também é transferida, por exemplo, o tipo de chamada originador, terminador, o modo da chamada, a referência da chamada no CSI-AS, etc.) ; um CS envolvendo o assinante que está sendo liberado; uma mudança no estado da chamada (por exemplo, segurar a chamada) e outros eventos relacionados CS (nova chamada CS esperando, etc.) .

Essas notificações não necessariamente duplicam a informação que já é transmitida para o assinante sobre o domínio CS, mas em vez disso transmitem para o assinante informação adicional sobre esses eventos que podem ser utilizadas no domínio IMS (por exemplo, uma referência de chamada). O assinante poderá optar por não assinar a todos os eventos possíveis. Por exemplo, o assinante poderá optar por assinar apenas para o evento 'CS established' (em cujo caso ele não será notificado quando uma chamada for liberada ou seu estado for modificado. Esta opção pode ser especificada ao incluir um documento filtro no corpo de uma solicitação SIP SUBSCRIBE.

Exemplos da utilização do pacote SIP no sistema 10

incluem, sem a eles se limitar, o seguinte: Um único assinante IMS pode ter múltiplos dispositivos capazes de IMS. Cada dispositivo poderá obter informação sobre as chamadas CS estabelecidas em dispositivos CS e utilizar esta informação para iniciar serviços IMS relacionados a essas chamadas CS. Um dispositivo WLAN/VoIP pode solicitar receber uma chamada de voz ativa atualmente em um dispositivo GSM. O usuário pode iniciar uma sessão de vídeo IMS com um dispositivo anônimo. 0 usuário pode iniciar chamadas combinacionais para centros de chamada mesmo se o terminal ao qual o usuário estiver conectado, for anônimo (ver o centro de auxílio na estrada descrito acima).

Ainda com referência à Figura 6, em um exemplo, o CSI- AS 21 identifica e mantém informação de maneira similar àquela da etapa 403 do método 400. Por exemplo, o CSI-AS 21 cria um contexto de chamada que contém uma referência de chamada e um identificador para o primeiro dispositivo. Além desses elementos, o contexto de chamada poderia conter informação adicional, como os números de telefone das partes que chama e a chamada, o número de telefone da parte que redireciona, o estado de invocação CLIR, informação contida no User-user IEs, e qualquer outra informação importante contida nas mensagens de sinalização CC. Em outro exemplo, o CSI-AS 21 poderia obter informação 3 0 adicional de outros IMS Application Servers que armazenam informação de chamada CS, como o Voice Call Continuity (VCC) AS.

Em um exemplo, quando uma chamada CS originadora ou terminadora estiver sendo estabelecida com um dos dispositivos 11, 12, procedimentos CAMEL são invocados para rotear mensagens de controle da chamada CS para o CSI-AS 21 que estabelece e armazena o contexto da chamada. Como com o sistema mostrado na Figura 10, o mesmo mecanismo é utilizado quando uma chamada CS é liberada. 0 procedimento CAMEL é invocado pelo MSC do domínio CS para enviar uma notificação para o CSI-AS 21. 0 CSI-AS 21 então remove o contexto de chamada CS.

Com referência agora à Figura 7, o pacote SIP será descrito agora em maior detalhe para fins ilustrativos. 0 dispositivo 15, em um exemplo, é um terminal IMS. O

dispositivo 15 assina o pacote SIP ao enviar uma mensagem SUBSCRIBE 701 para o CSI-AS 22 através do S-CSCF 21. A assinatura (SUBSCRIBE request) é servida pelo CSI-AS 21. Após receber a solicitação SUBSCRIBE, o CSI-AS 22 envia uma mensagem de resposta OK 703 para o dispositivo 15 através do S-CSCF 21.

O pacote SIP permite que o CSI-AS 21 forneça ao usuário do dispositivo 15 informação sobre chamadas CS em andamento com dispositivos no domínio CS. As notificações de eventos do pacote SIP (isto é, solicitação SIP NOTIFY) podem fornecer várias informações para cada chamada CS a que o assinante está conectado: uma referência de chamada que identifica singularmente a chamada na rede IMS; os números de telefone das partes que chama e a chamada; o 3 0 número de telefone da parte que redireciona; estado de invocação CLIR; informação contida no User-user IEs; outra informação importante contida nas mensagens de sinalização CC.

Uma descrição exemplar do formato do pacote de evento é conforme segue:

Event Package Name: cs-calling-service NOTIFY body: XML document MIME media type name: application MIME subtype name: cscallinfo+xml SUBSCRIBE Request-URI: TEL URL or Tel URL in SIP URI

format. Must be a registered IMPU.

SUB SCRIBE To header: Same as Request URI. 0 SUBSCRIBE request é endereçado a um TEL URL registrado ou um TEL URL no formato SIP URI (isto é, IMPU registrado). Critérios de filtragem associados ao TEL URL roteiam a solicitação SUBSCRIBE inicial para o CSI-AS 21. O CSI-AS 21 utiliza o IMPU endereçado no Request-URI como a chave para acessar os contextos de chamada CS para aquele usuário.

2 0 No caso em que um único assinante IMS tem múltiplos

dispositivos capazes de IMS utilizando o mesmo número de telefone IMPU, então as assinaturas para o pacote de evento SIP poderão ser estabelecidas de qualquer um desses dispositivos. Isto permite ao usuário obter informação sobre chamadas CS estabelecidas em outros dispositivos e utilizar potencialmente esta informação para iniciar serviços IMS relacionados àquelas chamadas CS de um dispositivo diferente.

Uma solicitação de assinatura exemplar 701, para

3 0 informação relacionada a um número de telefone (35850482137) é fornecido agora para fins ilustrativos: Telefone SUBSCRIBE:+35850482137 SIP/2.0

via: SIP/2.0/UDP 192.0.2.3:1357;comp=sigcomp;branch= z9hG4bKnashds7

Max-Forwards: 7 0

Route:<sip:pcscf1.visitedl.net:7 531;Ir;cp,'=sigcomp> Route:sip:orig@scscf1.homel.net;Ir

P-Preferred-Identity: "Dr John"tel:+ 35850482137 P-Access-Network-Info: 3 gpp-utran-tdd; utran-eell-id- 3gpp=234151D0FCEll Privacy: none

From:<tel> + 3 58504 82137>; tag=31415

To=Ntel:+ 35850482137>

Call-ID: b8 9rjhncdlrfj flslj40a222

Require: sec-agree

Proxy-Require: sec-agree

CSeq: 61 SUBSCRIBE

Event: cs-calling-services

Expires: 3600

Accept: applieation/cseallinfo+XML

Security-Verify: ipsec-3gpp; q=0.1; alg=hmae = sha-1-96 ; spi-c=98765432; spi-s=87654321; port-e=8642; port-s=7531 Contact:<sip:192.0.2.3:1357;comp=sigcomp Content-Length: 0

Com referência agora à Figura 7, o CSI-AS 22 enviará periodicamente mensagens NOTIFY 703 através do S-CSCF 21 para o dispositivo 15 indicando que nenhuma informação de chamada CS foi gerada. 0 dispositivo 15 enviará mensagens de confirmação OK 704 de volta ao CSI-AS 21.

Quando uma chamada for estabelecida em qualquer um do dispositivo 11 ou do dispositivo 12 no domínio CS 13, o MSC do domínio CS 13 enviará uma mensagem CAMEL 705 para o CSI- AS 22 notificando-o de que uma chamada CS foi estabelecida. 0 CSI-AS 22 enviará uma mensagem NOTIFY 706 através do S- CSCF 21 para o dispositivo 15. 0 dispositivo 15 responderá com mensagens de confirmação OK 70 7.

Se uma segunda chamada for estabelecida no dispositivo 12 no domínio CS 13, o MSC do domínio CS 13 enviará uma mensagem CAMEL 708 para o CSI-AS 22 notificando-o que uma chamada CS foi estabelecida. 0 CSI-AS 22 enviará uma mensagem NOTIFY 709 através do S-CSCF 21 para o dispositivo 15. O dispositivo 15 responderá com mensagens de confirmação OK 710.

AS 2 2 para o dispositivo 15 quando uma segunda chamada CS for estabelecida para um número de telefone exemplar (358504 8213 7) é mostrado para fins ilustrativos.

Uma mensagem NOTIFY SIP exemplar 709 enviada pelo CSI-

NOTIFY sip:192.0.2.3:1357;compusigcomp SIP/2.0

Via:

SIP/2.0/UDP

2 0 pscsf1.visitedl.net:7531;comp=sigcomp;branch= z9hH4bK24 Of34.1,

SIP/2.0/UDP

scscf1.homel.net;branch=

z9G4bK332b23.1,

SIP/2.0/UDP

csi-as.homel.net;branch=

z9hG4bK846ht53.1

Max-Forwards: 69

30

From:<tel:+ 3585048213 7M;tag=15117 0 To:tel:+ 35850482137;tag=31415 Call-ID:b89rjhnedlrfj flslj40a222 CSeq: 42 NOTIFY Subscription-State: active; expires=1580 Event: cs-calling-services Content-Type: application/cscallinfo+XML Contact: sip:csi-as.homel.net

Content-Length(---)

<?xml version="1.O"?>

ccscallinfo .......

Se a segunda chamada for liberada, uma mensagem CAMEL 711 é enviada do domínio CS 13 para o CSI-AS 22. O CSI-AS 22 enviará uma mensagem NOTIFY 712 através do S-CSCF 21 para o dispositivo 15. O dispositivo 15 responderá com mensagens de confirmação OK 713.

Se a primeira chamada for liberada, uma mensagem CAMEL 714 é enviada do domínio CS 13 para o CSI-AS 22. O CSI-AS 22 enviará uma mensagem NOTIFY 715 através do S-CSCF 21 para o dispositivo 15. O dispositivo 15 responderá com mensagens de confirmação OK 716.

Com referência ainda à Figura 7, durante a primeira ou a segunda chamada CS, o usuário do dispositivo IMS 15 pode utilizar a informação fornecida nas notificações do pacote SIP para invocar serviços IMS que são fortemente acoplados a chamadas CS específicas. Esses serviços poderão ser direcionados à própria chamada CS ou poderão ser direcionados à parte remota da chamada CS. Para suportar o direcionamento das invocações do serviço IMS para chamadas CS específicas identificadas nas notificações do pacote de evento CS Calling Services, um parâmetro SIP URI denominado "callref" é utilizado. Este parâmetro tem o sintaxe seguinte:

callref=<call reference>, em que <call reference> é a referência de chamada retornada nos CS Calling Services. Uma referência de chamada exemplar é:

callref=urn:uuid:f81d4fae-7dec-lld0-a7 65-00a0c81bf6 . Como uma alternative, a referência de chamada poderia ser embutida em um PSI com carta curinga gerado pelo CSI-AS e fornecido ao usuário IMS nas notificações do pacote de evento CS Calling Services. Neste caso, em vez de utilizar o parâmetro callref, a solicitação SIP seria endereçada diretamente ao PSI com carta curinga.

Exemplos que ilustram a utilização do CS Calling Event Package serão fornecidos agora para fins ilustrativos.

Uma chamada CS com CLIR invocado é estabelecida e a parte chamada deseja inicial um serviço combinacional mas ela não pode porque o numero de telefone da parte que chama é desconhecido. Conseqüentemente, ela endereça uma solicitação SIP para a referência de chamada indicando o serviço combinacional. Em um exemplo, a parte chamada utiliza um SIP URI que indica acesso ao contexto de chamada CS armazenado (por exemplo, SIP:csi-service.operator.com) com um parâmetro callref para identificar a referência de chamada e um parâmetro "combinational" ou "remote-party' para indicar que a parte remota da chamada CS está sendo endereçada. Exemplo: SIP:csi-

service . operator . com; callref = <callref erence> ; combinational ou

SIP:csi- service.operator.com:callref=<callreference>;remote-party

O iFC PARA ρ-Asserted-Identity é aplicado à solicitação SIP na rede IMS originadora (rede IMS da parte chamada) e guando do casamento do SIP URI, a solicitação SIP é encaminhada para o CSI-AS. 0 CSI-AS então tecla ccallreference> e redireciona a solicitação para o número de telefone da parte que chama.

Em outro exemplo, a parte chamada utiliza um SIP URI que indica serviço combinacional (por exemplo, SIP:combinational.operator.com ou SIP:remote-

party .operator.com) com um parâmetro callref para identificar a referência de chamada. Exemplo:

SIP; combinational. operator. com; callref = <calIref erence> ou

SIP:remote-party.operator. com;callref = <callreference>

0 iFC para P-Asserted-Identity é aplicado ã solicitação SIP na rede IMS originadora (rede IMS da parte chamada) e quando do casamento do SIP URI,a solicitação SIP é encaminhada para o CSI-AS. 0 CSI-AS 21 então tecla <callreference> e redireciona a solicitação para o número de telefone da parte que chama.

Em outro exemplo, uma solicitação é endereçada ao PSI do CSI-AS 21 com um parâmetro "callref=<callreference>" para identificar a referência da chamada e um parâmetro "combinational" ou "remote-party" para indicar que a parte remota da chamada CS está sendo endereçada. Exemplo:

SIP : <CSI_AS_PSI> . operator . com; callref = <callreference> ; combinational ou

SIP : <CSI_AS_PSI> . operator. com; callref = <callreference> ; remote-party

0 CSI-AS 21 então tecla <callreference> e redireciona a solicitação para o número de telefone da parte que chama. 0 psi CSI-AS precisa ser provisionado no terminal.

Como uma alternativa a utilizar o parâmetro callref, o

usuário IMS também poderá endereçar a invocação do serviço IMS diretamente a um USI de carta curinga com base na referência de chamada. Este CALL_REF_PSI seria incluído nas notificações de evento CS Calling Services para o usuário. A referência de chamada é embutida em um PSI carta curinga gerenciado pelo CSI-AS 21. A solicitação é então endereçada ao PSI carta curinga com um parâmetro "combinational" ou "remote-party" para indicar que a parte remota da chamada CS está sendo endereçada. Exemplo: SIP : <CALL_REF_PSI> . operator. com; combinational

ou

SIP : <CALL_REF_PSI> . operator. com; remote-party Neste caso, a solicitação SIP é roteada diretamente para o CSI-AS 21 onde o PSI carta curinga é gerenciado. O CSI-AS 21 então tecla a chamada CS referenciada pelo PSI carta curinga e redireciona a solicitação para o número de telefone da parte que chama. Observe que o serviço combinacional pode ser iniciado de um dispositivo diferente do que o dispositivo que hospeda a chamada CS se ambos os dispositivos partilharem o mesmo TEL URL IMPU registrado.

Em outro exemplo, o usuário IMS com uma chamada CS estabelecida decide transferir a chamada para o domínio IMS. Conseqüentemente ele endereça uma solicitação SIP para a referência de chamada indicando transferência. Várias abordagens alternativas são propostas. O usuário envia um SIP URI indicando acesso ao contexto de chamada CS armazenado (por exemplo, SIP:csi- service.operator.com) com um parâmetro callref para identificar a referência de chamada e um parâmetro "handoff" para indicar que a chamada CS deverá ser transferida para o IMS. Exemplo: SIP:cs i-

service.operator.com;callref=<callreference>;handoff

O Ifc PARA ρ-Asserted-Identity é aplicado à solicitação SIP na rede SIP originadora e quando do casamento do SIP URI, a solicitação SIP é encaminhada para o CSI-AS 21. 0 CSI-AS 21 então tecla ccallreference> e o parâmetro "handoff" e re-roteia a solicitação para o VCC AS (isto é, CCCF/NeDS) (O VCC AS e o CSI-AS poderia estar co- localizados. Se não, então um mecanismo para correlacionar referências de chamada CS através de ambos os servidores seria necessário) em que o procedimento de transferência é executado.

0 usuário envia um SIP URI indicando serviço VCC (por exemplo, SIP:vcc.operator.com) com um parâmetro callref para identificar a referência de chamada e um parâmetro "handoff" para indicar que a chamada CS deve ser transferida para o IMS. Exemplo>

SIP:vcc.operator.com; caqllref = <callreference>;handoff 0 iFC PARA p-Asserted-Identity é aplicado à

solicitação SIP na rede SIP originadora e quando do casamento do SIP URI, a solicitação SIP é encaminhada para o CSI-AS 21. 0 CSI-AS 21 então tecla <callreference> e re- roteia a solicitação para o VCC AS (isto é, CCCF/NeDS) onde o procedimento de transferência é executado. O usuário endereça uma solicitação para o PSI do CSI- AS 21 com um parâmetro "callref=<callreference>" para identificar a referência de chamada e um parâmetro "handoff" para indicar que a chamada CS deve ser transferida para o IMS. Exemplo:

SIP:<CSI_AS_PSI>.operator.com;callref = <callreference> ; handoff

A solicitação é roteada diretamente para o CSI-AS 21, que então tecla ccallreference> e re-roteia a solicitação para o VCC AS (isto é, CCCF/NeDS) onde o procedimento de transferência é executado. Um CSI-AS PSI precisa ser provisionado no terminal.

Como uma alternativa a utilizar o parâmetro callref, o usuário IMS também poderá endereçar a invocação de serviço IMS diretamente para um ISP carta curinga com base na referência de chamada. Esta CALL_REF_PSI seria incluída nas notificações do evento CS Calling Services para o usuário. A referência de chamada é embutida em um PSI carta curinga gerenciado pelo CSI-AS. A solicitação é então endereçada ao PSI carta curinga com um parâmetro "handoff" para indicar que a chamada CS deve ser transferida para IMS. Exemplo:

SIP:<CALL_REF_PSI> . operator.com;handoff

Neste caso, a solicitação SIP é roteada diretamente para o CSI-AS 21 onde o PSI carta curinga é gerenciado. O CSI-AS então tecla na chamada CS referenciada pelo PSI carta curinga e re-roteia a solicitação para o VCC AS (isto é, CCCF/NeDS) onde o procedimento de transferência é executado. Observe que a transferência pode ser iniciada de um dispositivo diferente do dispositivo que hospeda a chamada CS se ambos os dispositivos partilharem o mesmo TEL URL IMPU registrado.

Deve-se observar que a descrição anterior do pacote SIP incluiu nomes de parâmetro, por exemplo, callref, remote-party, handoff, etc. Esses nomes foram fornecidos apenas para fins ilustrativos. Outros nomes poderiam ser substituídos desde que o significado (isto é, o contexto dentro do pacote SIP) permaneça conforme aqui estabelecido.

Embora versões particulares tenham sido mostradas e descritas, será aparente para aqueles habilitados na tecnologia que mudanças e modificações poderão ser feitas sem desviar dos princípios aqui estabelecidos. A matéria explicitada na descrição anterior e nos desenhos acompanhantes é oferecida apenas por meio de ilustração e não como uma limitação.

Claims

1. Método, caracterizado pelo fato de compreender: receber a notificação de uma chamada de um primeiro dispositivo para um segundo dispositivo em um primeiro domínio; criar um contexto de chamada para o primeiro tipo de chamada; receber a notificação da iniciação de uma chamada do segundo dispositivo para o primeiro dispositivo em um segundo domínio; e utilizar o contexto de chamada para notificar o primeiro dispositivo da iniciação da chamada do segundo dispositivo para o primeiro dispositivo.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de a etapa de criar o contexto de chamada compreender: gerar uma referência de chamada para o primeiro tipo de chamada; e armazenar a referência de chamada em um componente da memória.

3. Método, de acordo com a reivindicação 2, caracterizado pelo fato de a etapa de criar o contexto de chamada ainda compreender ·. extrair um identificador do primeiro dispositivo da notificação da chamada do primeiro dispositivo para o segundo dispositivo; armazenar o identificador na memória tal que ele corresponda à referência de chamada.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de a etapa de utilizar compreender: empregar a referência de chamada para determinar o identificador do primeiro dispositivo; e enviar uma mensagem, no segundo domínio, para o primeiro dispositivo indicando que o segundo dispositivo gostaria de invocar o segundo tipo de chamada com o primeiro dispositivo.

5. Método, de acordo com a reivindicação 2, caracterizado pelo fato de ainda compreender: enviar a referência de chamada para o segundo dispositivo em resposta à criação do contexto de chamada.

6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de a etapa de enviar o identificador para o primeiro dispositivo compreender: iniciar uma sessão Unstructured Supplementary Service Data (USSD - Dados do Serviço Suplementar Não-Estruturado) com o segundo dispositivo; e enviar a referência de chamada para o segundo dispositivo durante a sessão USSD.

7. Método, de acordo com a reivindicação 5, caracterizado pelo fato de a etapa de enviar compreender: enviar uma mensagem Short Message Service (SMS - Serviço de Mensagem Curta) para o segundo dispositivo que inclui a referência de chamada.

8. Método, de acordo com a reivindicação 5, caracterizado pelo fato de ainda compreender: receber uma solicitação do segundo dispositivo por uma interface da Web para a referência de chamada; e em que a etapa de enviar compreender: enviar a referência de chamada pela interface da Web para o segundo dispositivo em resposta ao recebimento da solicitação .

9. Método, de acordo com a reivindicação 5, caracterizado pelo fato de a etapa de enviar compreender: enviar uma mensagem NOTIFY do protocolo de iniciação de sessão (SIP) para o segundo dispositivo que inclui a referência de chamada.

10. Método, de acordo com a reivindicação 5, caracterizado pelo fato de a etapa de gerar a referência de chamada compreender: gerar a referência de chamada dentro do segundo dispositivo.

11. Método, de acordo com a reivindicação 5, caracterizado pelo fato de ainda compreender: receber uma solicitação para iniciar uma chamada para o primeiro dispositivo, no segundo domínio, do segundo dispositivo, em que a solicitação inclui a referência de chamada.

12. Método, de acordo com a reivindicação 5, caracterizado pelo fato de a etapa de enviar compreender: enviar a mensagem através da utilização da mensagem instantânea SIP.

13. Sistema, caracterizado pelo fato de compreender: um primeiro componente de interface que recebe uma notificação de uma chamada de um primeiro dispositivo para o segundo dispositivo em um primeiro domínio; um componente de criação de contexto que cria um contexto de chamada para o primeiro tipo de chamada; um segundo componente de interface que recebe uma notificação da iniciação de uma chamada do segundo dispositivo para o primeiro dispositivo em um segundo domínio; e um componente de notificação que utiliza o contexto de chamada para notificar o primeiro dispositivo da iniciação da chamada do segundo dispositivo para o primeiro dispositivo.

14. Sistema, de acordo com a reivindicação 13, caracterizado pelo fato de o componente de criação de contexto compreender: componente de geração de referência de chamada que gera uma referência de chamada para o primeiro tipo de chamada; em que o sistema ainda compreender um componente de memória para armazenar a referência de chamada em um dispositivo de memória.

15. Sistema, de acordo com a reivindicação 14, caracterizado pelo fato de o componente de criação de contexto ainda compreender: um componente identificador de dispositivo que extrai um identificador do primeiro dispositivo da notificação da chamada do primeiro dispositivo para o segundo dispositivo ; em que o sistema ainda compreender um componente de memória para armazenar o tal que ele corresponde à referência de chamada.

16. Sistema, de acordo com a reivindicação 15, caracterizado pelo fato de o componente de notificação compreender: um componente de processamento que emprega a referência de chamada para determinar o identificador do primeiro dispositivo; e um componente de processamento que envia uma segunda mensagem, no segundo domínio, para o primeiro dispositivo indicando que o segundo dispositivo gostaria de invocar o segundo tipo de chamada com o primeiro dispositivo.

17. Sistema, de acordo com a reivindicação 14, caracterizado pelo fato de ainda compreender: um componente de comunicação de referência de chamada que envia a referência de chamada para o segundo dispositivo em resposta à criação do contexto de chamada.

18. Sistema, de acordo com a reivindicação 17, caracterizado pelo fato de o componente de comunicação de referência de chamada compreender: um componente de processamento que inicia uma sessão Unstructured Supplementary Service Data (USSD) com o segundo dispositivo; e um componente de processamento que envia a referência de chamada para o segundo dispositivo durante a sessão USSD.

19. Sistema, de acordo com a reivindicação 17, caracterizado pelo fato de o componente de comunicação de referência de chamada compreender: um componente de processamento que envia uma mensagem Short Message Service (SMS) para o segundo dispositivo que inclui a referência de chamada.

20. Sistema, de acordo com a reivindicação 17, caracterizado pelo fato de ainda compreender: uma interface da Web que recebe uma solicitação do segundo dispositivo para a referência de chamada; e em que o componente de comunicação de referência de chamada ainda compreender: um componente de processamento que envia a referência de chamada para o segundo dispositivo em resposta ao recebimento da solicitação.

21. Sistema, de acordo com a reivindicação 17, caracterizado pelo fato de o componente de comunicação de referência de chamada compreender: um componente do protocolo de iniciação de sessão (SIP) que envia uma mensagem SIP NOTIFY para o segundo dispositivo que inclui a referência de chamada.

22. Sistema, de acordo com a reivindicação 17, caracterizado pelo fato de o componente de geração de referência de chamada compreender residir no segundo dispositivo.

23. Sistema, de acordo com a reivindicação 17, caracterizado pelo fato de ainda compreender: um componente de solicitação de chamada que recebe uma solicitação para iniciar uma chamada para o primeiro dispositivo, no segundo domínio, do segundo dispositivo, em que a solicitação incluir a referência de chamada.

24. Sistema, de acordo com a reivindicação 17, caracterizado pelo fato de o componente de comunicação de referência de chamada compreender: um componente de processamento que envia a mensagem através da utilização de mensagem instantânea SIP.