BRPI0614848A2 - método, sistema e equipamento para processar requisições sip em rede ims - Google Patents

método, sistema e equipamento para processar requisições sip em rede ims Download PDF

Info

Publication number
BRPI0614848A2
BRPI0614848A2 BRPI0614848-4A BRPI0614848A BRPI0614848A2 BR PI0614848 A2 BRPI0614848 A2 BR PI0614848A2 BR PI0614848 A BRPI0614848 A BR PI0614848A BR PI0614848 A2 BRPI0614848 A2 BR PI0614848A2
Authority
BR
Brazil
Prior art keywords
sip request
request
sip
cscf
user
Prior art date
Application number
BRPI0614848-4A
Other languages
English (en)
Inventor
Fenqin Zhu
Yajuan Wu
Original Assignee
Huawei Tech Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=36994476&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=BRPI0614848(A2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Huawei Tech Co Ltd filed Critical Huawei Tech Co Ltd
Publication of BRPI0614848A2 publication Critical patent/BRPI0614848A2/pt
Publication of BRPI0614848A8 publication Critical patent/BRPI0614848A8/pt
Publication of BRPI0614848B1 publication Critical patent/BRPI0614848B1/pt

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1063—Application servers providing network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

MéTODO, SISTEMA E EQUIPAMENTO PARA PROCESSAR REQUISIçõES SIP EM REDE IMS. A presente invenção refere-se a um método para processar re- quisições SIP em uma rede IMS que compreende: um AS na rede IMS recebendo uma primeira requisição SIP enviada por uma entidade S-CSCF, gerando uma segunda requisição SIP e decidindo se é necessário associar a segunda requisição SIP com a primeira requisição SIP em termos de lógica de serviço na entidade S-CSCF, e se for necessário associar as duas requisições, removendo o URI do AS do cabeçalho Route da primeira requisição SIP; caso contrário, gerando novamente o cabeçalho Route da segunda requisição SIP no modo de comportamento de UA que dá origem e enviando a segunda requisição SIP para a entidade S-CSCF. A presente invenção também refere-se a um sistema para processar requisições SIP em uma rede IMS, compreendendo um AS e uma entidade S-CSCF. A presente invenção também refere-se a um AS para processar requisições SIP em uma rede IMS e uma entidade de rede para controle de serviço.

Description

Relatório Descritivo da Patente de Invenção para "MÉTODO,SISTEMA E EQUIPAMENTO PARA PROCESSAR REQUISIÇÕES SIP EMREDE IMS".
Campo de Tecnologia
A presente invenção refere-se a rede de Subsistema de Multimí-dia IP (IMS) no campo de comunicação, mais particularmente, com um mé-todo, sistema e equipamento para processar requisições do Protocolo deIniciação de Sessão (SIP) na rede IMS quando um Servidor de Aplicação(AS) é utilizado como um Agente de Usuário back-to-back (B2BUA).
Antecedentes da Invenção
Em uma rede IMS, as entidades de Função de Serviço Controlede Sessão de Chamada (S-CSCF) geralmente não executam serviço especí-fico e a lógica do serviço é colocada no AS. Ao receber uma requisição SIP,a S-CSCF pesquisa o Perfil do Usuário (UP) transferido durante o registro dousuário em relação aos Critérios de Filtro Iniciais (iFC) combinando com arequisição SIP e envia a requisição SIP para o AS relevante baseada na re-gra dos iFC. O AS pode executar diferentes papéis para os diálogos IMS. Seo AS serve como o originador do diálogo, como apresentado na figura 1A, o
AS origina um diálogo e envia este diálogo para a S-CSCF, e a S-CSCF nãoirá alterar a informação relevante deste diálogo. Se o AS serve como oB2BUA, como apresentado na figura 1B, o AS recebe a requisição SIP envi-ada pela S-CSCF, ele termina este diálogo e inicia um novo diálogo, e a as-sociação entre os dois diálogos é executada pelo AS, mas a partir do aspec-to de S-CSCF, desde que os dois diálogos são diferentes, a informação rele-vante, tal como o CaII-ID e o indicador de / para, de um diálogo é diferentedesta do outro.
No modo quando o AS serve como o B2BUA, entretanto, a S-CSCF freqüentemente precisa saber a associação entre os dois diálogos,desde que o usuário ainda pode esperar adotar os iFC do diálogo originalpara o novo diálogo. Devido aos dois diálogos serem diferentes, os dois diá-logos devem ser associados por se utilizar outros identificadores nas requisi-ções SIP, tal como Orig-DIALOG ID no cabeçalho Route, ao invés do quediretamente utilizar identificadores do diálogo SIP como o Call-ID.
Vários cabeçalhos da requisição SIP rigorosamente relacionadoscom a presente invenção serão brevemente descritos daqui por diante:
Cabeçalho Route: indica a próxima entidade de roteamento, istoé, o próximo percurso da requisição SIP, e pode compreender o Orig-DIALOG ID que é utilizado para ajudar a S-CSCF no aprendizado da relaçãocorrespondente entre o novo diálogo e o diálogo original;
Cabeçalho P-Asserted-ldentity: um identificador do usuário inse-rido por uma entidade da rede e identificando o originador que origina a re-quisição;
Cabeçalho Request-URI: indica o destino final da requisição.
Quando o AS atua como o B2BUA, o AS decide se o diálogonovo e o diálogo original precisam ser associados baseado na lógica especí-fica do serviço. Além disso, o AS também pode modificar o cabeçalho Re-quest-URI ou o cabeçalho P-Asserted-ldentity compreendido na requisiçãoSIP baseado na lógica específica do serviço.
De acordo com a especificação de protocolo existente, quando aS-CSCF está enviando uma requisição SIP para o AS, a S-CSCF deve colo-car o Identificador de Recurso Uniforme (URI) da S-CSCF que inclui um O-rig-DIALOG ID no cabeçalho Route, após o URI do AS. Deste modo, ao re-ceber a requisição SIP, o AS remove a parte mais à frente do cabeçalhoRoute, isto é, o URI do AS, e portanto, o URI da S-CSCF fica sendo a pri-meira parte do cabeçalho Route. O AS transmite a requisição SIP baseadona informação do cabeçalho Route, de modo que a requisição SIP serátransmitida para a S-CSCF. Ao receber a requisição SIP, a S-CSCF decidese a requisição SIP é iniciada pelo AS ou foi processada pela S-CSCF antesde transmitida por julgar se o cabeçalho Route inclui uma Orig-DIALOG ID, ese for determinado que a requisição SIP é processada pela S-CSCF antes, aS-CSCF determina o diálogo original com o qual o diálogo corrente está as-sociado de acordo com o Orig-DIALOG ID transportado no cabeçalho Routeda requisição SIP e adicionalmente executa o processo iFC incompleto parao diálogo corrente.O processo específico de associar o diálogo novo e o originalpode ser descrito em detalhes por se descrever as operações da S-CSCF eestas do AS, respectivamente.
Operações da S-CSCF:
1. Ao receber uma requisição Sl P, se a S-CSCF constatar queesta requisição inclui um Orig-DIALOG ID, a S-CSCF determina que estarequisição foi processada antes pela S-CSCF. De acordo com o Orig-DIALOG ID, a S-CSCF encontra o diálogo original e, quando confirmandoque o identificador de usuário relacionado não está modificado, ou seja, nolado da chamada o P-Asserted-Identity não foi modificado ou no lado cha-mado, o Request-URI não foi modificado, continua a executar o processoiFC incompleto.
2. Ao receber a requisição SlP, se a S-CSCF constatar que estarequisição não inclui o Orig-DIALOG ID, a S-CSCF determina que esta re-quisição corresponde a um novo diálogo originado pelo AS. A S-CSCF deci-de como processar a requisição de acordo com os iFC associados com estarequisição. Se a S-CSCF precisar enviar esta requisição para o AS, a S-CSCF preenche o URI do AS e o URI da S-CSCF no cabeçalho Route naseqüência, e o URI da S-CSCF inclui um ORIG-DIALOG ID. Um exemplo écomo se segue:
<formula>formula see original document page 4</formula>
A esse respeito, o Orig-DIALOG ID também pode ser indicadopor outra identificação, tal como a porta específica.
Operações do AS:
1. Ao receber a requisição SIP e executar as operações relevan-tes, o AS determina seu próprio papel durante este diálogo de acordo com alógica do serviço e determina como gerar as novas requisições SIP. Se o ASserve como o B2BUA, o AS deve remover seu próprio URI do AS do cabeça-lho Route da requisição SIP original, copiar o resto do cabeçalho Route paraa nova requisição como o cabeçalho Route da nova requisição e rotear estanova requisição de acordo com o cabeçalho Route. Portanto, um URI na no-va requisição, o qual corresponde à S-CSCF e inclui o Orig-DIALOG ID, serácolocada no início do cabeçalho Route.
Portanto, o URI do AS é removido do cabeçalho Route na novarequisição pelo AS1 de modo que a S-CSCF irá receber uma requisição queinclui o seguinte cabeçalho Route:
Route < Orig-DIALOGID @ S-CSCF1 ;> quadratura...
Deste modo, ao receber a requisição SIP retornada a partir doAS, a S-CSCF pode determinar o diálogo original com o qual a requisiçãoSIP recebida se associa de acordo com o Orig-DIALOG ID e executar o pro-cesso iFC subseqüente após confirmar que o identificador de usuário rele-vante não está modificado.
Resumindo, quando o AS serve como o B2BUA, de modo a ga-rantir que a detecção iFC incompleta para o diálogo original seja executadasobre o novo diálogo associado com o diálogo antigo na S-CSCF, quandoiniciando o novo diálogo, o AS irá diretamente copiar parte do cabeçalhoRoute do diálogo original como o cabeçalho Route do novo diálogo, ao invésde gerar de novo um novo cabeçalho Route para o novo diálogo. Tal proces-so possui os seguintes problemas: se o AS esperar que a S-CSCF executeum novo processo iFC, o AS deve gerar novamente um novo cabeçalhoRoute para o novo diálogo, ao invés de copiar parte do cabeçalho Route dodiálogo original como o cabeçalho Route do novo diálogo. De acordo com atécnica anterior, o AS somente pode copiar o cabeçalho Route do diálogooriginal como este do novo diálogo, resultando na inabilidade da S-CSCF emexecutar o processo de detecção de acordo com os novos IFC e portanto, oprocesso lógico do serviço não pode prosseguir corretamente.
Sumário da Invenção
A presente invenção proporciona um método para processarrequisições SIP na rede IMS, de modo que quando o Servidor de Aplicação(AS) serve como o B2BUA e inicia um novo diálogo na rede IMS, o processológico do serviço pode continuar corretamente.
O método para processar as requisições do Protocolo de Inicia-ção de Sessão (SIP) em uma rede de Subsistema Multimídia IP (IMS) com-preende as seguintes etapas:um Servidor de Aplicação (AS) na rede IMS recebendo uma pri-meira requisição SIP enviada por uma entidade de Função de Serviço deControle de Sessão de Chamada (S-CSCF) e gerando uma segunda requi-sição SIP de acordo com a primeira requisição SIP;
o AS decidindo se é necessário associar a segunda requisiçãoSIP com a primeira requisição SIP na S-CSCF, e se for necessário associaras duas requisições, removendo o Identificador de Recurso Uniforme (URI)do AS do cabeçalho Route da primeira requisição SIP e pegando o redor docabeçalho Route como o cabeçalho Route da segunda requisição SIP; casocontrário, o AS construindo o cabeçalho Route da segunda requisição SIPno modo de comportamento de Agente Usuário (UA) que dá origem;
o AS enviando a segunda requisição SIP para a entidade S-CSCF.
O método para processar requisições SIP em uma rede IMScompreende as seguintes etapas:
um Servidor de Aplicação (AS) na rede IMS recebendo uma pri-meira requisição SIP enviada por uma entidade de Função de Serviço deControle de Sessão de Chamada (S-CSCF) e gerando uma segunda requi-sição SIP de acordo com a primeira requisição SIP;
se o AS atua como o papel do B2BUA neste processo, o AS de-cidindo se é necessário associar a segunda requisição SIP com a primeirarequisição SIP na S-CSCF, e se for necessário associar as duas requisições,removendo o Identificador de Recurso Uniforme (URI) do AS do cabeçalhoRoute da primeira requisição SIP e pegando o resto do cabeçalho Routecomo o cabeçalho Route da segunda requisição SIP; e se não existir neces-sidade de associar as duas requisições, o AS construindo o cabeçalho Routeda segunda requisição SIP no modo de comportamento do UA que dá origem;
o AS enviando a segunda requisição SIP para a entidade S-CSCF;
ao receber a segunda requisição SIP, a S-CSCF decidindo se asegunda requisição SIP transporta um identificador de diálogo associado, ese a segunda requisição SIP não transportar o identificador, a S-CSCF pro-cessando a segunda requisição SIP de uma maneira como processando umnovo diálogo;
se a segunda requisição SIP transportar o identificador, a S-CSCF encontrando o primeiro diálogo que está associado com a segundarequisição SIP de acordo com o identificador de diálogo associado e deci-dindo se a informação relacionada com o usuário da primeira requisição SIPé a mesma que esta da segunda requisição SIP, e se a informação relacio-nada com o usuário das duas requisições for a mesma, a S-CSCF execu-tando o processamento subseqüente em relação à segunda requisição SIPde acordo com o fato de que a primeira requisição SIP e a segunda requisi-ção SIP estão associadas em termos de lógica de serviço;
se as informações relacionadas com o usuário das duas requisi-ções forem diferentes, a S-CSCF executando o processamento subseqüenteem relação à segunda requisição de acordo com o fato de que a primeirarequisição SIP e a segunda requisição SIP não estão associadas em termosde lógica de serviço.
A presente invenção também proporciona um sistema para pro-cessar requisições SIP em uma rede IMS, o qual compreende:
um Servidor de Aplicação (AS), recebendo uma primeira requisi-ção SIP enviada por uma entidade de Função de Serviço de Controle deSessão de Chamada (S-CSCF), gerando uma segunda requisição SIP, ge-rando o cabeçalho Route da segunda requisição SIP por decidir se é neces-sário associar a segunda requisição SIP com a primeira requisição SIP na S-CSCF, e então enviando a segunda requisição SIP para a entidade S-CSCF;
a entidade S-CSCF, enviando a primeira requisição SIP para oAS, recebendo e processando a segunda requisição SIP a partir do AS.
A presente invenção também proporciona o Servidor de Aplica-ção (AS) em uma rede IMS, o qual compreende:
uma primeira unidade de processamento de lógica do serviço,processando uma primeira requisição enviada por uma entidade de Funçãode Serviço de Controle de Sessão de Chamada (S-CSCF);uma segunda unidade de processamento de lógica de serviço,gerando uma segunda requisição SIP e gerando o cabeçalho Route da se-gunda requisição SIP por decidir se é necessário associar o primeiro diálogoSIP com o segundo diálogo SIP em termos de lógica de serviço.
A presente invenção também proporciona equipamento de redepara controle de serviço em uma rede IMS, o qual compreende:
uma primeira unidade de processamento, decidindo se uma se-gunda requisição SIP recebida inclui um identificador de diálogo associado,e se a segunda requisição SIP incluir o identificador, encontrando uma pri-meira requisição SIP que se associe com a segunda requisição SIP;
uma segunda unidade de processamento, decidindo se a infor-mação relacionada com o usuário da primeira requisição SIP é a mesma queesta da segunda requisição SIP e emitindo a decisão para uma terceira uni-dade de processamento;
a terceira unidade de processamento, processando a segundarequisição SIP de acordo com a decisão e de uma maneira de acordo comas duas requisições estando ou não estando associadas.
Pode ser visto a partir do esquema técnico que efeitos benéficosda presente invenção são como se segue:
Quando o AS gera a segunda requisição SIP ao receber a pri-meira requisição SIP, o AS gera o cabeçalho Route da segunda requisiçãoSIP por decidir se a segunda requisição SIP e a primeira requisição SIP pre-cisam ser associadas de acordo com a lógica do serviço, e se estas duasrequisições não precisarem ser associadas, o AS gera o cabeçalho Route dasegunda requisição SIP. Entretanto, na técnica anterior, parte do cabeçalhoRoute da primeira requisição SIP é copiado como o cabeçalho Route da se-gunda requisição SIP não importando se as duas requisições precisam serassociadas. Como pode ser visto a partir da comparação acima, a presenteinvenção principalmente almeja situações em que o novo diálogo e o diálogoantigo não precisam ser associados na S-CSCF, o que não é consideradona técnica anterior, por exemplo, o novo diálogo e o diálogo antigo podemcorresponder a diferentes usuários e o conteúdo do cabeçalho Route do no-vo diálogo deve ser diferente deste do diálogo antigo, desse modo impedin-do a detecção e o processo da S-CSCF de ficarem confusos.
Adicionalmente, a presente invenção adota uma regra de asso-ciação de coringa para comparar vários URIs, desse modo evitando o pro-blema possível de ser incapaz de corretamente continuar a lógica do serviçodevido ao fato de que o caractere coringa não é considerado na técnica an-terior.
Breve Descrição dos Desenhos
A Figura 1A é um diagrama esquemático de um AS servindocomo um originador na técnica anterior.
A Figura 1B é um diagrama esquemático de um AS servindocomo um B2BUA na técnica anterior.
A Figura 2 é um fluxograma do processo de requisição quandoum AS serve como um B2BUA de acordo com uma modalidade da presenteinvenção.
A Figura 3A é um fluxograma para determinar a associação delógica de serviço quando um AS está no lado que chama de acordo comuma modalidade da presente invenção.
A Figura 3B é um fluxograma para determinar a associação delógica de serviço quando um AS está no lado chamado de acordo com umamodalidade da presente invenção.
A Figura 4 é um fluxograma de uma S-CSCF processando a re-quisição B2BUA de acordo com uma modalidade da presente invenção.
A Figura 5 é um fluxograma da associação de dois URIs em umarede IMS de acordo com uma modalidade da presente invenção.
A Figura 6 é um diagrama esquemático da estrutura de um ASde acordo com uma modalidade da presente invenção.
A Figura 7 é um diagrama esquemático da estrutura de uma S-CSCF de acordo com uma modalidade da presente invenção.
A Figura 8 é um diagrama esquemático da estrutura de um sis-tema para processar requisições SIP na rede IMS de acordo com uma mo-dalidade da presente invenção.Descrição Detalhada da Invenção
A presente invenção será ilustrada em detalhes daqui para fren-te com referência aos desenhos acompanhantes e às modalidades específicas.
Na rede IMS, os dois cabeçalhos principais estritamente relacio-nados com o processo da lógica do serviço são o cabeçãlho P-ASSERTED-Identity e o cabeçalho Request-URI. Quando um AS serve como um B2BUA,se não existir associação entre a primeira requisição SIP enviada a partir deuma S-CSCF para o AS e uma segunda requisição SIP gerada pelo AS emtermos de lógica de serviço, o AS pode modificar os dois cabeçalhos na se-gunda requisição SIP. Para fazer a S-CSCF corretamente detectar e proces-sar a segunda requisição SIP enviada pelo AS, o AS gera um cabeçalhoRoute da segunda requisição SIP por decidir se a nova requisição SIP e asrequisições SIP anteriores estão associadas em termos de lógica de serviço.
Deve ser observado que "primeira" e "segunda" como utilizadoneste documento é somente para distinguir as duas requisições e não paradefinir a seqüência real das duas requisições.
A Figura 2 apresenta o procedimento principal do processo derequisição quando o AS serve como o B2BUA. Deve ser entendido que oprocesso seguinte não inclui todas as etapas do processo de requisiçãoquando o AS serve como o B2BUA. Como apresentado na figura 2, o proce-dimento principal do processo de requisição quando o AS serve como oB2BUA inclui as seguintes etapas:
Etapa 100: O AS recebe a primeira requisição SIP enviada pelaentidade S-CSCF e processa esta requisição SIP de acordo com a lógica doserviço.
Etapa 110: O As gera a segunda requisição SIP de acordo coma lógica do serviço e, durante o procedimento de gerar a segunda requisiçãoSIP, decide se a primeira requisição SIP e a segunda requisição SIP preci-sam ser associadas em termos de lógica de serviço na S-CSCF, e se sim,continua para a etapa 120; caso contrário, continua para a etapa 130.
Etapa 120: O AS apaga a URI do cabeçalho Route da primeirarequisição SIP e copia o resto do cabeçalho Route para a segunda requisi-ção SIP como o cabeçalho Route da segunda requisição SlP, e então conti-nua para a etapa 140.
Etapa 130: O AS gera o cabeçalho Route da segunda requisiçãoSIP em um modo de comportamento de UA que dá origem.
Etapa 140: O AS envia a segunda requisição SIP para a entida-de S-CSCF.
Quanto a um diálogo, o AS pode processar uma requisição apartir da chamada, isto é, o AS está no lado que chama, e o AS pode pro-cessar uma requisição a partir do chamado, isto é, o AS está no lado cha-mado. O AS pode decidir se a Identidade Pública de Multimídia IP (IMPU)processada pelo AS é do chamador ou do chamado, de acordo com os da-dos de subscrição dos iFC, portanto, o AS pode decidir se ele está no ladoque chama ou no lado chamado ao receber a requisição SIP enviada pela S-CSCF. Por exemplo, o AS marca uma ORIG-AS no registro iFC subscrito, equando a S-CSCF precisa rotear uma requisição SIP contendo a ORIG-ASpara o AS de acordo com o processo iFC, o AS sabe que ele esta no ladoque chama e precisa processar em nome do usuário como o P-Asserted-Identity indicou. Caso contrário, se o AS receber um requisição SIPS em aORIG-AS, o AS sabe que ele está no lado chamado e precisa processar emnome do usuário como o Request-URI indicou. Obviamente, a presente in-venção não está limitada à descrição acima, e a identificação especial ouporta especial em um AS URI também pode ser adotada para decidir se oprocesso do AS está no lado que chama ou no lado chamado.
Existem dois métodos para decidir se a primeira e a segundarequisições SIP estão associadas em termos de lógica de serviço:
Primeiro método: o AS decide se modifica o cabeçalho P-Asserted-Identity ou o cabeçalho Request-URI de acordo com a lógica deserviço executada. Quando a lógica de serviço é designada, já é levado emconsideração que alguns tipos de lógica de serviço precisam modificar o ca-beçalho enquanto outros tipos de lógica de serviço não precisam. Se o ASdescobrir que a lógica de serviço executada irá modificar o cabeçalho, o ASdetermina que a primeira requisição SIP e a segunda requisição SIP nãoestão associadas; se o AS descobrir que a lógica de serviço executada nãoirá modificar o cabeçalho, o AS determina que a primeira requisição SIP e asegunda requisição SIP estão associadas.
Pode ser visto que o AS pode decidir se a primeira requisiçãoSIP e a segunda requisição SIP estão associadas enquanto selecionando oserviço, e processar o diálogo de acordo com a decisão, a saber, se o pri-meiro serviço e o último serviço precisam ser associados é definido pelo pro-jetista da lógica de serviço.
Segundo Método: o AS decide se a primeira requisição SIP e asegunda requisição SIP precisam ser associadas na S-CSCF de acordo como resultado da execução da lógica do serviço que é utilizada para processara requisição SIP.
O processamento subseqüente dos dois métodos acima, osquais são utilizados para determinar se o primeiro serviço e o último serviçoprecisam ser associados, é basicamente o mesmo para um e outro, e por-tanto, o processo será ilustrado daqui para frente por assumir o segundométodo como o exemplo.
Por exemplo, durante o procedimento para gerar a segunda re-quisição SIP, a lógica do serviço gera a informação relacionada com o usuá-rio para a segunda requisição SIP, e o AS pode decidir se a segunda requi-sição SIP e a primeira requisição SIP precisam ser associadas na S-CSCF,de acordo com a informação relacionada com o usuário gerada para a se-gunda requisição SIP e com a informação relacionada com o usuário da pri-meira requisição SIP, e gera o cabeçalho Route da segunda requisição SIPde acordo com a decisão. Durante o processo de decisão, se o AS estiver nolado que chama, a decisão é executada principalmente de acordo com o ca-beçalho P-Asserted-Identity da primeira requisição SIP e com o cabeçalho P-Asserted-Identity da segunda requisição SIP; se o AS estiver no lado cha-mado, a decisão é executada principalmente de acordo com o cabeçalhoRequest-URI da primeira requisição SIP e com o cabeçalho Request-URI dasegunda requisição SIP. Durante o processo de decisão, a regra de associa-ção de coringa também pode ser utilizada para comparação. A aplicação docaractere coringa na rede IMS será ilustrada antes de introduzir o processoespecífico.
Nas redes tradicionais de telecomunicação, existe um tipo denúmeros especiais de telefone, tipo 114/100. Estes números especiais detelefone geralmente não representam usuários reais, de modo que por con-seqüência não existem processos tal como registro ou de autenticação deusuário. A rede IMS também introduz uma identidade especial similar que échamada de Identidade de Serviço Público (PSI). Dois tipos de PSI são in-traduzidos na rede IMS, os quais são diferentes da identidade especial tradi-cional. Um tipo é chamado de PSI específico que representa usuários espe-ciais, e o outro tipo é chamado de PSI coringa que representa um certo tipode usuário ao invés de usuários especiais.
A PSI coringa pode representar várias PSIs específicas diferen-tes, e quando o formato da PSI coringa adota o formato de SIP URI, a U-SER-INFO pode incluir o formato de expressão canônica extensivo que érestringido por "!" e definido pela IEEE 1003.1-2004 Part 1. Por exemplo,"sip:chatlist!.*!@example.com" pode ser associado com:sip:chatlist1 @example.com,sip:chatlist2@example.com,sip:chatlist42@example.com,sip:chatlistAbC @ example.com.
quando o formato de TEL URI é adotado, a parte de telefone dousuário pode incluir o formato de expressão canônica extensivo que é res-tringido por "!" e definido pela IEEE 1003.1-2004 Part 1. Por exemplo,"TEL:1234560.quadratura.*!" pode ser associado com:TELquadraturaI 234561;TELquadraturaI 234567;TELquadraturaI 23456789.
De acordo com o método existente de comparação SIP URI, seo AS alterar um certo identificador coringa para um identificador específico, apartir do aspecto de processo de lógica de serviço, o processo de serviçooriginal deve ser continuado. Por exemplo, o usuário não pode determinar onúmero da sala de bate-papo disponível, de modo que a chamada inicial éuma PSI coringa da sala de bate-papo, a qual é processada pelo AS no mo-do B2BUA e transformada para uma PSI específica pelo AS. De acordo como método existente de comparação de SIP URI, estes dois URIs serão con-siderados diferentes e o processo iFC incompleto original não será continua-do. A nova requisição SIP será considerada uma nova chamada, e será pro-cessada com um novo iFC. Obviamente, não é razoável em termos de pro-cesso de lógica de serviço considerar a nova requisição SIP como uma novachamada. De acordo com a presente invenção, a regra de associação decoringa é introduzida para vencer a limitação mencionada acima da técnicaanterior, pela qual os dois URIs que são formalmente diferentes mas, essen-cialmente os mesmos são considerados como URIs idênticos, desse modocontinuando o processo iFC incompleto original em relação ao novo diálogo.
Com referência à figura 3A, quando o AS está no lado que cha-ma, o procedimento principal de decidir se a primeira requisição SIP e a se-gunda requisição SIP estão associadas em termos de lógica de serviço incluias seguintes etapas:
Etapa 200: obter o P-Asserted-Identity da primeira requisiçãoSIP e este da segunda requisição SIP.
Etapa 210: Decidir se o P-Asserted-Identity da primeira requisi-ção SIP e este da segunda requisição SIP são idênticos, e se os dois foremidênticos, continuar para a etapa 240; caso contrário, continuar para a etapa220.
Etapa 220: Decidir se o P-Asserted-Identity inclui qualquer ca-ractere coringa, e se sim, continuar para a etapa 230; caso contrário, conti-nuar para a etapa 250.
Etapa 230: Decidir se o P-Asserted-Identity da primeira requisi-ção SIP e este da segunda requisição SIP combinam um com o outro deacordo com a regra de associação de coringa predefinida, e se sim, continu-ar para a etapa 240; caso contrário, continuar para a etapa 250.
Etapa 240: o AS determina que a primeira requisição SIP e asegunda requisição SIP estão associadas em termos de lógica de serviço.
Etapa 250: o AS determina que a primeira requisição SIP e asegunda requisição SIP não estão associadas em termos de lógica de servi-o.
De acordo com o requerimento do processo de lógica de serviço,a base para a decisão executada pelo AS também pode ser a combinaçãodo P-Asserted-Identity e do Request-URI da primeira requisição SIP e estesda segunda requisição SIP. Em outras palavras, após determinar que o P-Asserted-Identity da primeira requisição SIP e este da segunda requisiçãoSIP são idênticos, o AS pode adicionalmente decidir se o Request-URI daprimeira requisição SIP e este da segunda requisição SIP são idênticos. Seos P-Asserted-Identity das duas requisições forem idênticos enquanto osRequest-URI das duas requisições não forem, pode ser determinado que aprimeira requisição SIP e a segunda requisição SIP não precisam ser asso-ciadas em termos de lógica de serviço.
Deve ser entendido que, quando comparando o P-Asserted-Identity da primeira requisição SIP com este da segunda requisição SIP, éviável desconsiderar o caractere coringa e somente decidir se os P-Asserted-Identity das duas requisições são idênticos; se sim, é determinadoque as duas requisições estão associadas; caso contrário, as duas requisi-ções não estão associadas. A introdução da associação de coringa é utiliza-da para adicionalmente otimizar o esquema básico da presente invenção.
Com referência à figura 3B, quando o AS está no lado chamado,o procedimento principal de decidir se a primeira requisição SIP e a segundarequisição SIP estão associadas em termos de lógica de serviço inclui asseguintes etapas:
Etapa 300: Obter o Request-URI da primeira requisição SIP eeste da segunda requisição SIP.
Etapa 310: decidir se o Request-URI da primeira requisição SIPe este da segunda requisição SIP são idênticos, e se os dois forem idênti-cos, continuar para a etapa 340; caso contrário, continuar para a etapa 320.
Etapa 320: decidir se o Request-URI inclui qualquer caracterecoringa, e se sim, continuar para a etapa 330; caso contrário, continuar paraa etapa 350.
Etapa 330: decidir se o Request-URI da primeira requisição SIPe este da segunda requisição SIP combinam um com o outro de acordo coma regra de associação de coringa predefinida, e se sim, continuar para a e-tapa 340; caso contrário, continuar para a etapa 350.
Etapa 340: o AS determina que a primeira requisição SIP e asegunda requisição SIP estão associadas em termos de lógica de serviço.
Etapa 350: o AS determina que a primeira requisição SIP e asegunda requisição SIP não estão associadas em termos de lógica de serviço.
Do mesmo modo, após determinar que os Request-URI das du-as requisições são idênticos, o AS pode adicionalmente decidir se o P-Asserted-Identity da primeira requisição SIP e este da segunda requisiçãoSIP são idênticos.
O AS também pode adicionar informações para a segunda re-quisição SIP ou modificar as informações da segunda requisição SIP, talcomo modificar o Request-URI ou o P-Asserted-Identity para solicitar à S-CSCF para continuar o processo iFC subseqüente ou não.
Deve ser entendido que, durante o procedimento de comparar oRequest-URI da primeira requisição SIP com este da segunda requisiçãoSIP, é viável desconsiderar o caractere coringa e somente decidir se os Re-quest-URI das duas requisições são idênticos, e se os dois Request-URIforem diferentes, é determinado que as duas requisições estão associadas;caso contrário, é determinado que as duas requisições não estão associa-das. A introdução da combinação de coringa é utilizada para adicionalmenteotimizar o esquema da presente invenção.
Quanto a S-CSCF, ao receber a segunda requisição SIP trans-mitida pelo AS, se a S-CSCF detectar que a requisição recebida transportaum Orig-DIALOG ID, a S-CSCF irá pesquisar a primeira requisição SIP (odiálogo anterior) associado com esta requisição de acordo com Orig-DIALOG ID diretamente. Então, a S-CSCF executa o processo de acordocom a informação de se continua o processo iFC subseqüente transportadopela segunda requisição SIP. Se a S-CSCF não detectar qualquer Orig-DIALOG ID na segunda requisição SIP, esta requisição será consideradauma nova requisição SIP e será processada diretamente de acordo com ométodo existente do padrão.
Ao receber a segunda requisição SIP gerada pelo AS de acordocom o método mencionado acima, a entidade S-CSCF pode diretamenteexecutar a detecção e o processo iFC subseqüente sobre a segunda requi-sição SIP de acordo com o cabeçalho Route da requisição SIP, desde que ocabeçalho Route da primeira requisição SIP não será copiado como o cabe-çalho Route da segunda requisição SIP até que o AS tenha determinado quea primeira requisição SIP e a segunda requisição SIP precisam ser associa-das. Entretanto, de modo a tornar a S-CSCF compatível com estes As nãopossuindo a habilidade de processamento mencionada acima, após desco-brir a primeira requisição SIP combinando com a segunda requisição SIP deacordo com o Orig-DIALOG ID, a S-CSCF pode adicionalmente determinarse continuar o processo iFC subseqüente por decidir se a informação adicio-nada ou modificada pelo AS, tal como P-Asserted-Identity ou Request-URI,na primeira requisição SIP e esta na segunda requisição SIP são idênticasde acordo com a SIP URI ou com a regra de associação da SIP URI ou TEL-URI. Deve ser entendido que, enquanto comparando o P-Asserted-Identityou o Request-URI na primeira requisição SIP e na segunda requisição SIP, éviável desconsiderar o caractere coringa e somente decidir se os P-Asserted-Identity ou os Request-URI das duas requisições são idênticos, ese os dois Request-URI forem diferentes, é determinado que as duas requi-sições estão associadas; caso contrário, é determinado que as duas requisi-ções não estão associadas. A introdução da associação de coringa é utiliza-da para adicionalmente otimizar o esquema da presente invenção.
Ao receber a requisição SIP, a S-CSCF decide se é a primeiravez que esta requisição SIP chega nesta S-CSCF por decidir se esta requi-sição compreende um ORIG-DIALOG ID. Quanto à primeira requisição SIP,a S-CSCF pode decidir se ela está processando a requisição SIP no ladoque chama ou a requisição SIP no lado chamado de acordo com a informa-ção da primeira requisição SIP. Quando a requisição SIP que não chega naS-CSCF a primeira vez, a S-CSCF descobre se a primeira requisição SIPassociada com a requisição SIP primeiramente e então decide se esta requi-sição SIP é a requisição SIP no lado que chama ou esta no lado chamado.Se determinando que a requisição é uma requisição SIP no lado que chama,a S-CSCF irá decidir se executar a detecção e o processo iFC sobre a se-gunda requisição SIP enviada pelo AS principalmente por decidir se o P-Asserted-Identity da primeira requisição SIP e este da segunda requisiçãoSIP são idênticos; se determinando que a requisição é uma requisição SIPno lado chamado, a S-CSCF irá decidir se executar a detecção e o processoiFC sobre a segunda requisição SIP enviada pelo AS principalmente por de-cidir se o Request-URI da primeira requisição SIP e este da segunda requi-sição SIP são idênticos. Durante o procedimento de comparar o P-Asserted-Identity e o Request-URI da primeira requisição SIP e estes da segunda re-quisição SIP, o caractere coringa pode ser levado em consideração.
Com referência a figura 4, quando a S-CSCF está no lado quechama, o procedimento principal para processar a segunda requisição SIPenviada pelo AS inclui as seguintes etapas:
Etapa 400: a entidade S-CSCF recebe a segunda requisiçãoSIP.
Etapa 410: a S-CSCF decide se o cabeçalho Route inclui umORIG-DIALOG ID, e se sim, continua para a etapa 420; caso contrário, con-tinua para a etapa 480.
Etapa 420: a S-CSCF descobre se a primeira requisição SIP es-tá associada com a segunda requisição SIP de acordo com o Orig-DIALOGID.
Etapa 430: a S-CSCF decide se o P-Asserted-Identity da primei-ra requisição SIP e este da segunda requisição SIP são idênticos, e se sim,continua para a etapa 460; caso contrário, continua para a etapa 440.
Etapa 440: a S-CSCF decide se o P-Asserted-Identity incluiqualquer caractere coringa, e se sim, continua para a etapa 450; caso con-trário, continua para a etapa 470.
Etapa 450: a S-CSCF decide se o P-Asserted-Identity da primei-ra requisição SIP e este da segunda requisição SIP combinam um com ooutro, e se sim, continua para a etapa 460; caso contrário, continua para aetapa 470.
Etapa 460: a S-CSCF determina que a primeira requisição SIP ea segunda requisição SIP estão associadas em termos de lógica de serviçoe executa a detecção e o processo iFC subseqüente sobre a segunda requi-sição SIP.
Etapa 470: a S-CSCFdetermina que a primeira requisição SIP ea segunda requisição SIP não estão associadas em termos de lógica de ser-viço e, ao invés de executar a detecção e o processo iFC subseqüente sobrea segunda requisição SIP, determina o próximo pulo de acordo com o cabe-çalho Route e com o cabeçalho Request-URI da segunda requisição SIP eentão envia a segunda requisição SIP para o próximo salto.
Etapa 480: a S-CSCF processa a segunda requisição SIP deuma maneira como processando um novo diálogo.
Quando a entidade S-CSCF está no lado chamado e processa asegunda requisição SIP enviada pelo AS, os processos basicamente são osmesmos que os processos quando a entidade S-CSCF está no lado quechama, exceto o procedimento para decidir se o Request-URI da primeirarequisição SIP e o Request-URI da segunda requisição SIP são idênticosquando a S-CSCF está no lado que chamada, os quais não são para serdescritos em detalhes daqui para frente.
Deve ser entendido que, durante o procedimento de compararos P-Asserted-Identity das duas requisições, é viável desconsiderar o carac-tere coringa e somente decidir se os P-Asserted-Identity das duas requisi-ções são idênticos, e se sim, é determinado que as duas requisições estãoassociadas; caso contrário, é determinado que as duas requisições não es-tão associadas. A introdução da associação de coringa é utilizada para oti-mizar o esquema da presente invenção.
Com referência à descrição da figura 3A, da figura 3B e da figura4, pode ser visto que o método par associar as URIs de acordo com umamodalidade da presente invenção pode ser aplicado a qualquer cenário derede IMS para comparar os URIs. Como apresentado na figura 5, o procedi-mento principal para associar os URIs inclui as seguintes etapas:
Etapa 500: decidir se os dois URIs são idênticos, e se sim, con-tinuar para a etapa 530; caso contrário, continuar para a etapa 510.
Etapa 510: adicionalmente decidir se pelo menos um dos URIsinclui qualquer caractere coringa, e se não, continuar para a etapa 540; casocontrário, continuar para a etapa 520.
Etapa 520: decidir se os dois URIs estão associados um com ooutro de acordo com a regra de associação de coringa predefinida, e se sim,continuar para a etapa 530; caso contrário, continuar para a etapa 540.
Etapa 530: determinar que os dois URIs combinam um com ooutro e continuar o processamento subseqüente de acordo com a condiçãode associação.
Etapa 540: determinar que os dois URIs não combinam um como outro e continuar o processamento subseqüente de acordo com a condi-ção de não associação.
Com referência à figura 6, o AS 60 em uma modalidade paraimplementar o método descrito acima inclui a primeira unidade de proces-samento de lógica de serviço 600 e a segunda unidade de processamentode lógica de serviço 601. Deve ser observado que outros módulos de funçãopara implementar as funções básicas existentes não são apresentados nafigura 6.
A primeira unidade de processamento de lógica de serviço 600 éutilizada para processar a primeira requisição SIP enviada pela S-CSCF.
A segunda unidade de processamento de lógica de serviço 601está logicamente conectada com a primeira unidade de lógica de serviço600, e utilizada para gerar a segunda requisição SIP e, enquanto gerando asegunda requisição SIP, gerando o cabeçalho Route para a segunda requi-sição SIP de acordo com a decisão e se é necessário associar a primeirarequisição SIP com a segunda requisição SIP em termos de lógica de servi-ço. Especificamente, se for necessário associar as duas requisições SlΡ, oURI da AS será removido do cabeçalho Route da primeira requisição SIP e oresto do cabeçalho Route será assumido como o cabeçalho Route da se-gunda requisição SIP; caso contrário, o cabeçalho Route da segunda requi-sição SIP será construído em um modo de comportamento de UA que dáorigem.
A segunda unidade de processamento de lógica de serviço 601inclui o primeiro módulo 6010, o segundo módulo 6011 e o terceiro módulo6012.
O primeiro módulo 6010 é utilizado para decidir se a informaçãorelevante da primeira requisição SIP e esta da segunda requisição SIP sãoidênticas ou determinar se é necessário associar a primeira requisição SIPcom a segunda requisição SIP na entidade S-CSCF de acordo com a lógicade serviço selecionada; se as informações relevantes das duas requisiçõesforem idênticas ou se for necessário associar as duas requisições, emitir adecisão para o segundo módulo 6011; caso contrário, emitir a decisão para oterceiro módulo 6012. As informações relevantes podem ser informaçõesrelacionadas com o usuário incluindo o cabeçalho P-Asserted-Identity e / ouo cabeçalho Request-URI.
O terceiro módulo 6012 está logicamente conectado com o pri-meiro módulo 6010; quando a informação relevante da primeira requisição eesta da segunda requisição são diferentes e quando cada uma das duasrequisições não inclui caractere coringa, o terceiro módulo 6012 é utilizadopara decidir se a informação relevante da primeira requisição SIP e esta dasegunda requisição SIP combinam uma com a outra e emitindo a decisãopara o segundo módulo 6011.
O segundo módulo 6011 está logicamente conectado tanto como primeiro módulo 6010 como com o terceiro módulo 6012 e é utilizado paragerar o cabeçalho Route de acordo com a decisão do primeiro módulo 6010e esta do terceiro módulo 6012.
Deve ser observado que o terceiro módulo 6012 é opcional epode ser excluído. Em outras palavras, o processo de decidir se a informa-ção relevante da primeira requisição SIP e esta da segunda requisição SIPcombinam de acordo com a regra de associação de coringa pode ser excluí-do. Neste caso, o primeiro módulo 6010 diretamente emite a decisão para osegundo módulo 6011.
Com referência à figura 7, a entidade S-CSCF 70 em uma moda-lidade da presente invenção para implementar o método mencionado acimainclui a primeira unidade de processamento 700, a segunda unidade de pro-cessamento 701, a terceira unidade de processamento 702, e a quarta uni-dade de processamento 704, enquanto outros módulos de função para im-plementar as funções básicas existentes não são apresentados na figura 7.
A primeira unidade de processamento 700 decide se a segundarequisição SIP recebida inclui o identificador de diálogo associado relaciona-do e, quando é determinado que a segunda requisição SIP inclui o identifi-cador de diálogo associado, determina a primeira requisição SIP que estáassociada com a segunda requisição SIP.
A segunda unidade de processamento 701 está logicamenteconectada com a primeira unidade de processamento 700 e é utilizada paradecidir se a informação relevante da primeira requisição SIP e esta da se-gunda requisição SIP são idênticas, e se sim, emitindo a decisão para a ter-ceira unidade de processamento 702; caso contrário, emitindo a decisão pa-ra a quarta unidade de processamento 703.
A quarta unidade de processamento 703 está logicamente co-nectada com a segunda unidade de processamento 701; quando a informa-ção relevante da primeira requisição e esta da segunda requisição são dife-rentes e cada uma das duas requisições não inclui o caractere coringa, aquarta unidade de processamento 703 é utilizada para decidir se a informa-ção relevante da primeira requisição SIP e esta da segunda requisição SIPcombinam uma com a outra e emitindo a decisão para a terceira unidade deprocessamento 702. A informação relevante pode ser informação relaciona-da com o usuário incluindo o cabeçalho P-Asserted-Identity e / ou o cabeça-Iho Request-URI.
A terceira unidade de processamento 702 está logicamente co-nectada tanto com a segunda unidade de processamento 701 como com aquarta unidade de processamento 703, respectivamente, e é utilizada paraprocessar a segunda requisição SIP de acordo com a decisão da segundaunidade de processamento 701 ou com esta da quarta unidade de proces-samento 703.
A quarta unidade de processamento 703 é opcional e pode serexcluída. Em outras palavras, o processo de decidir se a informação relevan-te da primeira requisição SIP e esta da segunda requisição SIP combinamde acordo com a regra de associação de coringa pode ser excluído. Nestecaso, a segunda unidade de processamento 701 diretamente emite a deci-são para a terceira unidade de processamento 702.
A presente invenção também proporciona um sistema para pro-cessar requisições SIP na rede IMS, o qual inclui um AS e uma entidade S-CSCF. Como apresentado na figura 8, a estrutura do AS na figura 8 é com-pletamente a mesma que esta do AS apresentado na figura 6 e também asfunções dos mesmo, as quais não são descritas em detalhes; a estrutura daS-CSCF na figura 8 é completamente a mesma que esta da entidade S-CSCF apresentada na figura 6 e também são as funções da mesma, asquais não são para serem descritas em detalhes daqui para frente.
A presente invenção será adicionalmente ilustrada daqui parafrente com referência a um exemplo, o qual somente lista os segmentos derequisição SIP que estão relacionados com a presente invenção. Outros de-talhes de cada requisição podem ser obtidos por referência aos padrões re-levantes.
1. O AS está no lado que chama e determina que não é neces-sário associar a requisição SIP original com a nova requisição SIP em ermosde lógica de serviço na S-CSCF.
Na etapa final, a S-CSCF recebe uma requisição SIP (segmento)de entrada, a qual é como se segue:
INVITE sip:bob@biloxi.com SIP/2.0
To: Bob<sip:bob@biloxi.com>From: Alice<sip.alice@atlanta.com>;tag=1928301774Call-ID: a84b4c76e66710Route: s-cscs1 @biloxi.comP-Asserted-ldentity: "John Doe" <sip:user1_public1 @home1.net>...
Ao receber a requisição SIP1 a S-CSCF executa a lógica rele-vante do serviço e decide enviar a requisição SIP para o AS, assumindo arequisição SIP como a primeira requisição SIP.
Na segunda etapa, o AS recebe a primeira requisição SIP (seg-mento) a partir da entidade S-CSCF, a qual é como segue:...INVITE sip:bob@biloxi.com SIP/2.0To: Bob<sip:bob@biloxi.com>From: Alice<sip.alice@atlanta.com>;tag=1928301774Call-ID: a84b4c76e66710Route: <AS@biloxi.com>,<ORIG_DILAG ID@biloxi.com>P-Asserted-ldentity: "John Doe" <sip:user1_public1 @home1 .net>
Na terceira etapa, o AS descobre de acordo com a lógica doserviço que o P-Asserted-ldentity deve ser modificado, e assim, não é ne-cessário associar a primeira requisição SIP com a segunda requisição SIPna S-CSCF, e o cabeçalho Route da segunda requisição SIP será construídoe o Call ID também pode ser modificado. A segunda requisição SIP (seg-mento) gerada pelo AS é como segue:
INVITE sip:bob@biloxi.com SIP/2.0To: Bob<sip:bob@biloxi.com>From: Alice2<sip.alice@atlanta.com>;tag=1928301774Call-ID: a84b4c76e66721Route: <S-CSCF@biloxi.com; Orig>P-Asserted-ldentity: "TOM" <sip:user2_public1 @home1.net>...Na quarta etapa, ao receber a segunda requisição SIP enviadapelo AS, a S-CSCF não detecta Orig-DIALOG ID, de modo que a segundarequisição SIP será assumida como um novo diálogo que chama e será pro-cessado baseado em um novo iFC. A requisição SIP (segmento) após serprocessada é como segue:
INVITE sip:bob@biloxi.com SIP/2.0
To: Bob2<sip:bob@biloxi.com>
From: Alice2<sip.alice@atlanta.com>;tag==1928301774
Call-ID: a84b4c76e66721
P-Asserted-ldentity: "TOM" <sip:user2_public1 @home1.net>
2. O AS está no lado que chama e decide se é necessário asso-ciar a requisição SIP original e a nova requisição SIP em termos de lógica deserviço na S-CSCF.
Na primeira etapa, a requisição SIP (segmento) recebida pela S-CSCF é como segue:
INVITE sip:bob@biloxi.com SIP/2.0
To: Bob<sip:bob@biloxi.com>
From: Alice<sip.alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
Route: s-cscf1 @biloxi.com
P-Asserted-ldentity: "John Doe" <sip:user1_public1 @home1.net>
A S-CSCF executa a lógica de serviço relevante e decide enviara requisição para o AS, assumindo a requisição como a primeira requisiçãoSIP.
Na segunda etapa, a primeira requisição SÍP (segmento) recebi-da pelo AS a partir da entidade S-CSCF é como segue:
INVITE sip:bob@biloxi.com SIP/2.0
To: Bob<sip:bob@biloxi.com>From: Alice<sip.alice@atlanta.com>;tag=1928301774Call-I D: a84b4c76e66710
Route: <AS@biloxi.com>,<ORIG_DILAG ID@biloxi.com>P-Asserted-ldentity: "John Doe" <sip:user1_public1 @home1.net>
Na terceira etapa, o AS determina não modificar o P-Asserted-Identity de acordo com a lógica do serviço, e assim, é necessário associar aprimeira requisição SIP com a segunda requisição SIP na S-CSCF, e o ca-beçalho Route da primeira requisição SIP será copiado. A segunda requisi-ção SIP gerada pelo AS é como segue:
INVITE sip:bob@biloxi.com SIP/2.0To: Bob2<sip:bob@biloxi.com>From: Alice2<sip.alice@atlanta.com>;tag=1928301774Call-ID: a84b4c76e66721
Route: <ORIG_DILAG ID@biloxi.com>
P-Asserted-ldentity: "John Doe" <sip:user1_public1 @home1.net>
Na quarta etapa, ao receber a segunda requisição SIP, a S-CSCF detecta um Orig-DIALOG ID, determina que a segunda requisição SIPestá associada com a primeira requisição SIP e vê que o P-Asserted-ldentitynão está modificado, de modo que o processo iFC incompleto original serácontinuado. A requisição SIP (segmento) após ser processada é como se- gue:
INVITE sip:bob@biloxi.com SIP/2.0To: Bob2<sip:bob@biloxi.com>From: Alice2<sip.alice@atlanta.com>;tag=1928301774Call-ID: a84b4c76e66721P-Asserted-ldentity: "John Doe" <sip:user1_public1 @home1 .net>
O precedente é somente as modalidades preferidas da presenteinvenção e não é pretendido para limitar o escopo da presente invenção.Qualquer modificação, substituição equivalente, ou aperfeiçoamento feitosem se afastar do espírito e do princípio da presente invenção deve ser co-berto pelo escopo exposto nas reivindicações anexas.

Claims (26)

1. Método para processar as requisições do Protocolo de Inicia-ção de Sessão (SIP) em um rede de Subsistema Multimídia IP (IMS)1 com-preendendo:um Servidor de Aplicação (AS) na rede IMS recebendo uma pri-meira requisição SIP enviada por uma entidade de Função de Serviço deControle de Sessão de Chamada (S-CSCF) e gerando uma segunda requi-sição SIP de acordo com a primeira requisição SIP;AS decidindo se é necessário associar a segunda requisiçãoSIP com a primeira requisição SIP na S-CSCF, e se for necessário associaras duas requisições, removendo o Identificador de Recurso Uniforme (URI)do AS do cabeçalho Route da primeira requisição SIP e pegando o resto docabeçalho Route como o cabeçalho Route da segunda requisição SIP; casocontrário, o AS construindo o cabeçalho Route da segunda requisição SIPno modo de comportamento de Agente Usuário (UA) que dá origem;AS enviando a segunda requisição SIP para a entidade S-CSCF.
2. Método, de acordo com a reivindicação 1, onde a etapa dedecidir se é necessário associar a segunda requisição SIP com a primeirarequisição SIP na S-CSCF compreende: o AS decidindo se associar a se-gunda requisição SIP com a primeira requisição SIP na S-CSCF de acordocom a lógica de serviço selecionada.
3. Método, de acordo com a reivindicação 1, onde a etapa do ASdecidir se é necessário associar a primeira requisição SIP com a segundarequisição SIP na S-CSCF compreende: o AS decidindo se associar a se-gunda requisição SIP com a primeira requisição SIP na S-CSCF de acordocom o resultado da execução de uma lógica de serviço selecionada.
4. Método, de acordo com a reivindicação 3, onde a etapa dedecidir se associa a primeira requisição SIP com a segunda requisição SIPde acordo com o resultado da execução da lógica de serviço selecionadacompreende: decidir se associar a primeira requisição SIP com a segundarequisição SIP por comparar a informação relacionada com o usuário que égerada pela lógica do serviço para a segunda requisição SIP e a informaçãorelacionada com o usuário da primeira requisição SIP.
5. Método, de acordo com a reivindicação 4, onde a etapa dedecidir se associa a primeira requisição SIP com a segunda requisição SIPpor compara a informação relacionada com o usuário que é gerada pela ló-gica do serviço para a segunda requisição SIP e a informação relacionadacom o usuário da primeira requisição SIP compreende:decidir se a informação relacionada com o usuário da primeirarequisição SIP é a mesma que esta da segunda requisição SIP, e se sim,determinar associar as duas requisições; caso contrário, determinar não as-sociar as duas requisições.
6. Método, de acordo com a reivindicação 5, adicionalmentecompreendendo:se a informação relacionada com o usuário da primeira requisi-ção SIP e esta da segunda requisição SIP forem diferentes, decidir se a in-formação relacionada com o usuário inclui um caractere coringa, e se não,determinar não associar as duas requisições;se a informação relacionada com o usuário incluir um caracterecoringa, decidir se a informação relacionada com o usuário da primeira re-quisição SIP e esta da segunda requisição SIP combinam uma com a outrade acordo com uma regra de associação de coringa predefinida, e se sim,determinar associar as duas requisições; caso contrário, não associar asduas requisições.
7. Método, de acordo com a reivindicação 4, adicionalmentecompreendendo:o AS especificando se ele está no lado que chama ou no ladochamado através dos dados de subscrição de um Critérios de Filtro Inicial(iFC);onde, se o AS estiver no lado que chama, a informação relacio-nada com o usuário compreende o P-Asserted-Identity da primeira requisi-ção e este da segunda requisição que são utilizados para identificar um ori-ginador da requisição;se o AS estiver no lado chamado, a informação relacionada como usuário compreende o Request-URI e / ou o P-Asserted-Identity da primei-ra requisição SIP e este da segunda requisição SIP que são utilizados paraidentificar uma extremidade destino.
8. Método, de acordo com qualquer uma das reivindicações 1até 7, adicionalmente compreendendo:ao receber a segunda requisição SIP, a S-CSCF decidindo se asegunda requisição SIP transporta um identificador de diálogo associado, ese a segunda requisição SIP não transporta o identificador, a S-CSCF pro-cessando a segunda requisição SIP de uma maneira como processando umnovo diálogo;se a segunda requisição SIP transportar o identificador, a S-CSCF encontrando a primeira requisição SIP que está associada com a se-gunda requisição SIP de acordo com o identificador de diálogo associado edecidindo se a informação relacionada com o usuário da primeira requisiçãoSIP é a mesma que esta da segunda requisição SIP;se as informações relacionadas com o usuário das duas requisi-ções forem as mesmas, a S-CSCF executando o processamento subse-qüente sobre a segunda requisição SIP de acordo com o fato de que a pri-meira requisição SIP e a segunda requisição SIP estão associadas em ter-mos de lógica de serviço;se as informações relacionadas com o usuário das duas requisi-ções forem diferentes, a S-CSCF executando o processamento subseqüentesobre a segunda requisição SIP de acordo com o fato de que a primeira re-quisição SIP e a segunda requisição SIP não estão associadas em termosde lógica de serviço.
9. Método, de acordo com a reivindicação 8, onde a etapa da S-CSCF executar o processamento subseqüente se a primeira requisição SIPe esta da segunda requisição SIP forem associadas em termos de lógica deserviço compreende: a S-CSCF executando o processo iFC subseqüentesobre a segunda requisição SIP.
10. Método, de acordo com a reivindicação 8, adicionalmentecompreendendo:se a S-CSCF determinar que a informação relacionada com ousuário da primeira requisição SIP e esta da segunda requisição SIP sãodiferentes, a entidade S-CSCF decidindo se a informação relacionada com ousuário da primeira requisição SIP e esta da segunda requisição SIP incluemum caractere coringa, e se nem a informação relacionada com o usuário daprimeira requisição SIP nem esta da segunda requisição SIP incluir um ca-ractere coringa, determinando que a informação relacionada com o usuárioda primeira requisição SIP e esta da segunda requisição SIP não se associam;se a informação relacionada com o usuário da primeira requisi-ção SIP ou esta da segunda requisição SIP incluir um caractere coringa, de-cidindo se a informação relacionada com o usuário da primeira requisiçãoSIP e esta da segunda requisição SIP se associam de acordo com uma re-gra de associação de coringa, e se sim, executando o processamento sub-seqüente de acordo com o fato de que a primeira requisição SIP e a segun-da requisição SIP estão associadas em termos de lógica de serviço; casocontrário, executando o processamento subseqüente de acordo com o fatode que a primeira requisição SIP e a segunda requisição SIP não estão as-sociadas em termos de lógica de serviço.
11. Método, de acordo com a reivindicação 8, onde: se a entida-de S-CSCF estiver no lado que chama, a informação relacionada com o u-suário compreende o P-Asserted-Identity da primeira requisição SIP e esteda segunda requisição SIP; ouse a entidade S-CSCF estiver no lado chamado, a informaçãorelacionada com o usuário compreende o Request-URI e / ou o P-Asserted-Identity da primeira requisição SIP e este da segunda requisição SIP.
12. Método para processar requisições de Protocolo de Iniciaçãode Sessão (SIP) em uma rede de Subsistema de Multimídia IP (IMS), com-preendendo:um Servidor de Aplicação (AS) na rede IMS recebendo uma pri-meira requisição SIP enviada por uma entidade de Função de Serviço deControle de Sessão de Chamada (S-CSCF) e gerando uma segunda requi-sição SIP de acordo com a primeira requisição SIP;o AS decidindo se é necessário associar a segunda requisiçãoSIP com a primeira requisição SIP na S-CSCF, e se for necessário associaras duas requisições, removendo o Identificador de Recurso Uniforme (URI)do AS do cabeçalho Route da primeira requisição SIP e pegando o resto docabeçalho Route como o cabeçalho Route da segunda requisição SIP; e senão existir necessidade de associar as duas requisições, o AS construindo ocabeçalho Route da segunda requisição SIP no modo de comportamento doUA que dá origem;o AS enviando a segunda requisição SIP para a entidade S-CSCF;ao receber a segunda requisição SIP, a S-CSCF decidindo se asegunda requisição SIP transporta um identificador de diálogo associado, ese a segunda requisição SIP não transportar o identificador, a S-CSCF pro-cessando a segunda requisição SIP de uma maneira como processando umnovo diálogo;se a segunda requisição SIP transportar o identificador, a S-CSCF encontrando a primeira requisição SIP que está associada com a se-gunda requisição SIP de acordo com o identificador de diálogo associado edecidindo se a informação relacionada com o usuário da primeira requisiçãoSIP é a mesma que esta da segunda requisição SIP, e se a informação rela-cionada com o usuário das duas requisições for a mesma, a S-CSCF execu-tando o processamento subseqüente em relação à segunda requisição SIPde acordo com o fato de que a primeira requisição SIP e a segunda requisi-ção SIP estão associadas em termos de lógica de serviço;se as informações relacionadas com o usuário das duas requisi-ções forem diferentes, a S-CSCF executando o processamento subseqüenteem relação à segunda requisição de acordo com o fato de que a primeirarequisição SIP e a segunda requisição SIP não estão associadas em termosde lógica de serviço.
13. Método, de acordo com a reivindicação 12, adicionalmentecompreendendo:se a informação relacionada com o usuário da primeira requisi-ção SIP e esta da segunda requisição SIP forem diferentes, decidindo se ainformação relacionada com o usuário da primeira requisição SIP ou esta dasegunda requisição SIP compreende um caractere coringa;se nem a informação relacionada com o usuário da primeira re-quisição SIP nem esta da segunda requisição SIP compreender um caracte-re coringa, executar processamento subseqüente em relação à segunda re-quisição SIP de acordo com o fato de que a primeira requisição SIP e a se-gunda requisição SIP não estão associadas em termos de lógica de serviço;se a informação relacionada com o usuário da primeira requisi-ção SIP ou esta da segunda requisição SIP compreender um caractere co-ringa, decidir se a informação relacionada com o usuário da primeira requisi-ção SIP e esta da segunda requisição SIP estão associadas de acordo comuma regra de associação de coringa;se a informação relacionada com o usuário das duas requisiçõescombinarem, executar processamento subseqüente em relação à segundarequisição SIP de acordo com o fato de que a primeira requisição SIP e sasegunda requisição SIP estão associadas em termos de lógica de serviço;caso contrário, executar processamento subseqüente em relação à segundarequisição SIP de acordo com o fato de que a primeira requisição SIP e asegunda requisição SIP não estão associadas em termos de lógica de serviço.
14. Método, de acordo com a reivindicação 12, onde a etapa daS-CSCF executar o processamento subseqüente se a primeira requisiçãoSIP e esta da segunda requisição SIP forem associadas em termos de lógicade serviço compreende: a S-CSCF executando o processo iFC subseqüentesobre a segunda requisição SIP.
15. Método, de acordo com a reivindicação 12, onde: se o ASestiver no lado que chama, a informação relacionada com o usuário compre-ende o P-Asserted-Identity da primeira requisição SIP e este da segundarequisição SIP que são utilizados para identificar o originador da requisição;se o AS estiver no lado chamado, a informação relacionada como usuário compreende o Request-URI e / ou o P-Asserted-Identity da primei-ra requisição SIP e este da segunda requisição SIP que são utilizados paraidentificar uma extremidade destino.
16. Sistema para processar requisições de Protocolo de Inicia-ção de Sessão (SIP) em uma rede de Subsistema Multimídia IP (IMS), com-preendendo:um Servidor de Aplicação (AS), recebendo uma primeira requisi-ção SIP enviada por uma entidade de Função de Serviço de Controle deSessão de Chamada (S-CSCF), gerando uma segunda requisição SIP, ge-rando o cabeçalho Route da segunda requisição SIP por decidir se é neces-sário associar a segunda requisição SIP com a primeira requisição SIP na S-CSCF, e enviando a segunda requisição SIP para a entidade S-CSCF;a entidade S-CSCF, enviando a primeira requisição SIP para oAS, recebendo e processando a segunda requisição SIP a partir do AS.
17. Sistema, de acordo com a reivindicação 16, onde o AS com-preende:uma primeira unidade de processamento de lógica do serviço,processando uma primeira requisição pela S-CSCF;uma segunda unidade de processamento de lógica de serviço,gerando uma segunda requisição SIP e gerando o cabeçalho Route da se-gunda requisição SIP por decidir se é necessário associar a primeira requisi-ção SIP e a segunda requisição SIP em termos de lógica de serviço.
18. Sistema, de acordo com a reivindicação 17, onde a segundaunidade de processamento de lógica de serviço compreende:um primeiro módulo, decidindo se a informação relacionada como usuário da primeira requisição SIP e esta da segunda requisição SIP sãoas mesmas ou decidindo se é necessário associar a primeira requisição SIPcom a segunda requisição SIP na entidade S-CSCF de acordo com uma ló-gica de serviço selecionada, e então emitindo a decisão para um segundomódulo;o segundo módulo, gerando o cabeçalho Route da segunda re-quisição SIP de acordo com a decisão.
19. Sistema, de acordo com a reivindicação 18, onde a segundaunidade de processamento de lógica de serviço adicionalmente compreen-de:um terceiro módulo, decidindo se a informação relacionada como usuário da primeira requisição SIP e esta da segunda requisição SIP com-binam uma com a outra quando a informação relacionada com o usuário daprimeira requisição e esta da segunda requisição são diferentes e pelo me-nos uma das duas requisições inclui um caractere coringa, e emitindo a de-cisão para o segundo módulo.
20. Sistema, de acordo com a reivindicação 16, onde a entidadeS-CSCF compreende:uma primeira unidade de processamento, decidindo se a segun-da requisição SIP recebida inclui um identificador de diálogo associado, e sea segunda requisição SIP incluir o identificador, encontrando uma primeirarequisição SIP que se associe com a segunda requisição SIP;uma segunda unidade de processamento, decidindo se a infor-mação relacionada com o usuário da primeira requisição SIP é a mesma queesta da segunda requisição SIP e emitindo a decisão para uma terceira uni-dade de processamento;a terceira unidade de processamento, processando a segundarequisição SIP de acordo com a decisão e de uma maneira de acordo comas duas requisições estando ou não estando associadas.
21. Sistema, de acordo com a reivindicação 20, onde a entidadeS-CSCF adicionalmente compreende:uma quarta unidade de processamento, se for determinado pelasegunda unidade de processamento que a informação relacionada com ousuário da primeira requisição e esta da segunda requisição são diferentes eque pelo menos uma das duas requisições inclui um caractere coringa, deci-dindo se a informação relacionada com o usuário da primeira requisição eesta da segunda requisição combinam e emitindo a decisão para a terceiraunidade de processamento.
22. Servidor de Aplicação (AS) para processar requisições SIPem uma rede de Subsistema de Multimídia IP (IMS), compreendendo:uma primeira unidade de processamento de lógica de serviço,processando uma primeira requisição enviada por uma entidade de Funçãode Serviço de Controle de Sessão de Chamada (S-CSCF);uma segunda unidade de processamento de lógica de serviço,gerando uma segunda requisição SIP e gerando o cabeçalho Route da se-gunda requisição SIP por decidir se é necessário associar a primeira requisi-ção SIP e a segunda requisição SIP em termos de lógica de serviço.
23. AS, de acordo com a reivindicação 22, onde a segunda uni-dade de processamento de serviço compreende:um primeiro módulo, decidindo se a informação relacionada como usuário da primeira requisição SIP e esta da segunda requisição SIP sãoas mesmas ou decidindo se é necessário associar a primeira requisição SIPcom a segunda requisição SIP na entidade S-CSCF de acordo com uma ló-gica de serviço selecionada, e então emitindo a decisão para um segundomódulo;o segundo módulo gerando o cabeçalho Route da segunda re-quisição SIP de acordo com a decisão.
24. AS, de acordo com a reivindicação 23, onde a segunda uni-dade de processamento de serviço adicionalmente compreende:um terceiro módulo, decidindo se a informação relacionada como usuário da primeira requisição SIP e esta da segunda requisição SIP com-binam uma com a outra quando a informação relacionada com o usuário daprimeira requisição SIP e esta da segunda requisição SIP são diferentes epelo menos uma das duas requisições inclui um caractere coringa, e emitin-do a decisão para o segundo módulo.
25. Equipamento de rede para controle de serviço em uma redede Subsistema de Multimídia IP (IMS), compreendendo:uma primeira unidade de processamento, decidindo se uma se-gunda requisição SIP recebida inclui um identificador de diálogo associado,e se a segunda requisição SIP incluir o identificador, encontrar uma primeirarequisição SIP que combine com a segunda requisição SIP;uma segunda unidade de processamento, decidindo se a infor-mação relacionada com o usuário da primeira requisição SIP é a mesma queesta da segunda requisição SIP e emitindo a decisão para uma terceira uni-dade de processamento;uma terceira unidade de processamento, processando a segun-da requisição SIP de acordo com a decisão de uma maneira das duas requi-sições estando ou não associadas.
26. Equipamento de rede, de acordo com a reivindicação 25,adicionalmente compreendendo:uma quarta unidade de processamento, quando é determinadopela segunda unidade de processamento que a informação relacionada como usuário da primeira requisição SIP e esta da segunda requisição SIP sãodiferentes e pelo menos uma das duas requisições inclui um caractere corin-ga, decidindo se a informação relacionada com o usuário da primeira requi-sição e esta da segunda requisição combinam e emitindo a decisão para aterceira unidade de processamento.
BRPI0614848-4A 2005-08-19 2006-07-26 Método e servidor de aplicação para processar requisições sip em rede ims BRPI0614848B1 (pt)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
CN200510090919.5 2005-08-19
CN200510090919 2005-08-19
CNB2005101197569A CN100502402C (zh) 2005-08-19 2005-11-03 一种在ims网络中处理会话消息的方法及装置
CN200510119756.9 2005-11-03
PCT/CN2006/001851 WO2007019775A1 (en) 2005-08-19 2006-07-26 A method, system and device for processing sip message in ims network

Publications (3)

Publication Number Publication Date
BRPI0614848A2 true BRPI0614848A2 (pt) 2011-04-19
BRPI0614848A8 BRPI0614848A8 (pt) 2018-06-12
BRPI0614848B1 BRPI0614848B1 (pt) 2019-07-09

Family

ID=36994476

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0614848-4A BRPI0614848B1 (pt) 2005-08-19 2006-07-26 Método e servidor de aplicação para processar requisições sip em rede ims

Country Status (6)

Country Link
US (1) US7835352B2 (pt)
EP (1) EP1755310B1 (pt)
CN (1) CN100502402C (pt)
AT (1) ATE512535T1 (pt)
BR (1) BRPI0614848B1 (pt)
WO (1) WO2007019775A1 (pt)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101175075B (zh) * 2006-11-03 2012-12-12 华为技术有限公司 对业务信息进行关联处理的方法
CN101197806B (zh) * 2006-12-08 2012-04-18 华为技术有限公司 一种路由会话的方法、网络及设备
WO2008074348A1 (en) * 2006-12-19 2008-06-26 Telefonaktiebolaget Lm Ericsson (Publ) Technique for providing services in a service provisioning network
US8254288B2 (en) * 2006-12-21 2012-08-28 Telefonaktiebolaget Lm Ericsson (Publ) Method and an arrangement for handling a service request in a multimedia network
CN101212522B (zh) * 2006-12-29 2010-06-02 华为技术有限公司 关联会话的方法、装置及系统
CN101212418B (zh) * 2006-12-31 2010-05-12 华为技术有限公司 背靠背用户代理及其传输信息的方法
ES2375871T3 (es) * 2007-02-22 2012-03-07 Telefonaktiebolaget Lm Ericsson (Publ) Acceso de grupo a un servicio del subsistema multimedia ip.
WO2008119377A1 (en) * 2007-03-29 2008-10-09 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for use in a communications network
US20090049087A1 (en) * 2007-08-17 2009-02-19 Tekelec Methods, systems, and computer program products for providing a universal uniform resource identifier (UURI)
WO2009023569A2 (en) * 2007-08-10 2009-02-19 Tekelec Methods, systems, and computer program products for providing a universal uniform resource identifier (uuri)
EP2106091B1 (en) * 2008-03-28 2013-11-13 Telefonaktiebolaget LM Ericsson (publ) Method of setting up a call in an internet protocol (IP) multimedia subsystem (IMS) network, method of operating a network nude, network node, a telecommunications service provider using such a method, computer program and computer readable medium
JP5488267B2 (ja) * 2010-06-30 2014-05-14 富士通株式会社 情報処理装置、情報処理方法、情報処理プログラム
US9729502B2 (en) * 2011-02-02 2017-08-08 Junction Networks, Inc. System and method for geographic SIP scaling
CN102355430B (zh) * 2011-09-16 2014-07-30 大唐移动通信设备有限公司 一种即时消息触发的方法、系统及设备
US11778000B1 (en) 2013-03-25 2023-10-03 Junction Networks Inc. Event subscription in distributed session initiation protocol architectures
ES2795876T3 (es) * 2017-10-12 2020-11-25 Deutsche Telekom Ag Método y aparatos para el servicio de múltiples identidades basado en el registro de identidades compartidas
US11463485B2 (en) * 2017-12-29 2022-10-04 Telefonaktiebolaget Lm Ericsson (Publ) Method, system and entity for a media transfer session in an IMS infrastructure
US11743304B2 (en) * 2019-12-27 2023-08-29 Ribbon Communications Operating Company, Inc. Methods and apparatus to preserve original attestation/signature information for diverted calls
US12568029B2 (en) * 2024-06-18 2026-03-03 At&T Intellectual Property I, L.P. Systems and methods for auto-assuring reachability in a software defined network

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1300399A (zh) 1999-03-03 2001-06-20 索尼公司 发送和接收设备、发送和接收系统、发送和接收方法
AU2002224990A1 (en) * 2002-01-10 2003-07-24 Nokia Corporation Method and system for proxying a message
KR100487124B1 (ko) * 2002-11-12 2005-05-03 삼성전자주식회사 세션 이니세이션 프로토콜 시스템의 세션 정보 처리 방법및 그 기록매체
CN100338924C (zh) 2002-11-23 2007-09-19 中兴通讯股份有限公司 Ip网络中控制设备和业务设备互通提供业务的方法
GB0321975D0 (en) 2003-09-19 2003-10-22 Ericsson Telefon Ab L M Exchange protocol for combination multimedia services
US7283506B2 (en) * 2003-10-13 2007-10-16 Nokia Corporation System and method for releasing sessions at network entities associated with the sessions
US7359373B2 (en) * 2003-10-17 2008-04-15 Nokia Corporation System, apparatus, and method for establishing circuit-switched communications via packet-switched network signaling
AU2003299301A1 (en) * 2003-12-01 2005-06-24 France Telecom System for providing services in response to a communications session message
CN100362838C (zh) * 2004-02-10 2008-01-16 华为技术有限公司 一种减轻归属签约用户服务器接口负荷的方法
US20050213606A1 (en) * 2004-03-25 2005-09-29 Jiun-Yao Huang Method of triggering application service using response filter criteria and IP multimedia subsystem using the same
CN100531194C (zh) 2004-09-07 2009-08-19 华为技术有限公司 分组域业务信号处理系统及其方法
US7586903B2 (en) * 2004-10-28 2009-09-08 Samsung Electronics Co., Ltd. System and method for VoIP call transfer using instant message service in an IP multimedia subsystem

Also Published As

Publication number Publication date
CN100502402C (zh) 2009-06-17
EP1755310A1 (en) 2007-02-21
WO2007019775A1 (en) 2007-02-22
ATE512535T1 (de) 2011-06-15
BRPI0614848A8 (pt) 2018-06-12
CN1832473A (zh) 2006-09-13
BRPI0614848B1 (pt) 2019-07-09
EP1755310B1 (en) 2011-06-08
US7835352B2 (en) 2010-11-16
US20070121622A1 (en) 2007-05-31

Similar Documents

Publication Publication Date Title
BRPI0614848A2 (pt) método, sistema e equipamento para processar requisições sip em rede ims
US8213425B2 (en) Method for matching initial request message in the IP multimedia subsystem service triggering process
US7996541B2 (en) Methods, systems, and computer program products for identifying a serving home subscriber server (HSS) in a communications network
US8208930B2 (en) Message routing in a telecommunication system
US10038794B2 (en) System for communicating with an internet protocol multimedia subsystem network
BRPI0804748B1 (pt) adaptador de protocolo de início de sessão
BRPI0520192B1 (pt) método para indicar o(s) serviço(s) de comunicação de subsistema de multimídia de ip e aplicativo terminal com que uma mensagem de protocolo de iniciação de sessão se relaciona e para operar um terminal de usuário ou nó de rede de ims
WO2006066145A2 (en) Supporting database access in an internet protocol multimedia subsystem
CN103369159B (zh) 一种呼叫处理方法和设备
ES2327274T3 (es) Tratamiento o gestion de mensajes en un subsistema multimedia ip.
WO2010069197A1 (zh) 多媒体子系统业务处理的方法、装置和多媒体子系统
CN102884858B (zh) 用于使能来自ims中未登记ue的连接的设置的方法和装置
CN100403692C (zh) 在ims网络中处理注册初始过滤规则的方法
WO2007112640A1 (en) A method and an apparatus for replacing the session id, an application server and a method for replacing the session
JP2023540063A (ja) 合法的傍受のためのパケットのルーティングのための方法、システムおよびコンピュータ読取可能媒体
WO2008106885A1 (en) Method and system for the service compatibility
WO2007090348A1 (en) A method, apparatus and system for checking the validity for globally routable user agent uri
CN101448316B (zh) 叠加注册的实现方法
CN1905433B (zh) 一种提高服务可靠性的方法及系统
ES2365743T3 (es) Métodos y aparatos para procesar peticiones sip en una red ims comprendiendo un as.
CN101001248B (zh) 在ims网络中处理注册初始过滤规则的方法
CN100589459C (zh) 边界网关处理媒体网关协议用户注册的方法及系统
CN113543163A (zh) 提升Volte端到端语音质量方法及装置
WO2008058472A1 (fr) Procédé permettant de mettre en œuvre un service de réseau basé sur l&#39;envoi de paquets de données, système et base de données enregistrés par des utilisateurs
CN102984168A (zh) 一种实现分布式软交换系统和ims系统互通的方法

Legal Events

Date Code Title Description
B25A Requested transfer of rights approved

Owner name: INVENTERGY, INC. (US)

B25A Requested transfer of rights approved

Owner name: INVT SPE LLC (US)

B06T Formal requirements before examination [chapter 6.20 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: A CLASSIFICACAO ANTERIOR ERA: H04L 29/06

Ipc: H04L 29/08 (1990.01)

B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 09/07/2019, OBSERVADAS AS CONDICOES LEGAIS. (CO) 10 (DEZ) ANOS CONTADOS A PARTIR DE 09/07/2019, OBSERVADAS AS CONDICOES LEGAIS

B21F Lapse acc. art. 78, item iv - on non-payment of the annual fees in time

Free format text: REFERENTE A 19A ANUIDADE.

B24J Lapse because of non-payment of annual fees (definitively: art 78 iv lpi, resolution 113/2013 art. 12)

Free format text: EM VIRTUDE DA EXTINCAO PUBLICADA NA RPI 2841 DE 17-06-2025 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDA A EXTINCAO DA PATENTE E SEUS CERTIFICADOS, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.