BRPI0418942B1

BRPI0418942B1 - Método para prover serviços diferentes em um sistema de comunicação de multimídia, e, servidor de aplicativo em um sistema de comunicação de multimídia

Info

Publication number: BRPI0418942B1
Application number: BRPI0418942-6A
Authority: BR
Inventors: Synnergren Per; Stille Mats
Original assignee: Telefonaktiebolaget Lm Ericsson
Priority date: 2004-07-09
Filing date: 2004-07-09
Publication date: 2018-05-29
Also published as: WO2006006897A1; BRPI0418942A; CN1985489A; US8443091B2; JP2008506303A; US20120278384A1; US20090055473A1; CN1985489B; EP1766918B1; KR101214326B1; US8239547B2; KR20070032314A; EP1766918A1; JP5026964B2

Abstract

método para prover serviços diferentes em um sistema comunicação aplicativo em de um multimídia, sistema de e, servidor comunicação multimídia em sistemas de comunicação de multimídia atuais usando protocolos de iniciação de sessão tal como sip, uma mudança de serviço por exemplo, adicionar um novo tipo de mídia a uma conversação de multimídia existente) impõe atrasos significantes e carga de processador em ambos clientes e servidor. a invenção atual resolve isto separando sinalização de sessão e sinalização de controle de mídia em canais de sinalização diferentes (141, 142) e eliminando a necessidade para restabelecer sessões de sip para cada mudança de serviço. o servidor de aplicativo (120) mantém uma lista de todos os tipos de mídia suportados por cada cliente de multimídia (110) envolvido em uma conversação de multimídia. cada cliente de multimídia (110) pedindo para enviar um ou vários fluxos de mídia com tipos de mídia diferentes para um ou vários outros clientes de multimídia, negocia com o servidor de aplicativo (120) somente. o conceito inventivo reduz significativamente atrasos de redes e acelera a mudança de serviço como percebida pelo usuário. a invenção e de interesse para vários aplicativos de conferência de multimídia.

Description

(54) Título: MÉTODO PARA PROVER SERVIÇOS DIFERENTES EM UM SISTEMA DE COMUNICAÇÃO DE MULTIMÍDIA, E, SERVIDOR DE APLICATIVO EM UM SISTEMA DE COMUNICAÇÃO DE MULTIMÍDIA (51) Int.CI.: H04L 29/06 (73) Titular(es): TELEFONAKTIEBOLAGET LM ERICSSON (72) Inventor(es): PER SYNNERGREN; MATS STILLE • ♦ “MÉTODO PARA PROVER SERVIÇOS DIFERENTES EM UM SISTEMA DE COMUNICAÇÃO DE MULTIMÍDIA, E, SERVIDOR DE APLICATIVO EM UM SISTEMA DE COMUNICAÇÃO DE MULTIMÍDIA

CAMPO TÉCNICO DA INVENÇÃO

A invenção atual relaciona-se a um método e arranjo para prover serviços diferentes em um sistema de comunicação de multimídia.

DESCRIÇÃO DA TÉCNICA RELACIONADA Atualmente, iniciativas dentro da comunidade de telecomunicação tal como 3GPP e 3GPP2 (Projeto de Sociedade de 3^aGeração) estão especificando uma próxima geração de redes de núcleo comutadas por pacote para serviços de telecomunicação. Em 3GPP, um domínio de rede de núcleo é chamado IMS (Subsistema de Multimídia de IP), e em 3GPP2 é chamado MMD (Domínio de Multimídia).

Uma semelhança entre o domínio de IMS e o domínio de

MMD é que a sinalização para estabelecer chamadas ou sessões é executada usando SIP, Protocolo de Iniciação de Sessão (IETF RFC 3261). Serviços de multimídia são estabelecidos usando mensagens de SIP que também levam SDP, Protocolo de Descrição de Sessão (IETF RFC 2327). Um cliente de multimídia (um terminal) que origina uma sessão ou uma chamada deve descrever todos os tipos de mídia (tais como vídeo, voz, etc.) que o serviço usará na parte de SDP da mensagem. Os tipos de mídia são então negociados em uma troca de mensagem de SIP com um cliente de multimídia chamado por um servidor de aplicativo no domínio de rede de núcleo.

A mídia é enviada através de IP, tipicamente usando RTP,

Protocolo de Transporte em Tempo Real (IETF RFC 3550), mas outros protocolos de transporte e aplicativo podem ser usados.

Usando redes baseadas em IP toma possível executar mudança de serviço. Mudança de serviço é a possibilidade para adicionar ou remover

um ou vários fluxos de mídia de mesmos ou diferentes tipos para/de um serviço de multimídia durante uma sessão ativa. Um exemplo é um usuário que quer adicionar ou remover um fluxo de vídeo a um fluxo de VoIP existente (Voz através de IP) durante uma chamada em andamento.

Uma mudança de serviço dentro de VoIP é especificada como um procedimento de negociação usando mensagens de SIP. Para exemplificar: um cliente primeiro envia uma mensagem de SIP para iniciar uma chamada de VoIP. Esta mensagem é tipicamente uma mensagem de CONVITE de SIP. A mensagem de CONVITE de SIP leva o SDP, que contém uma descrição de qual codec de fala usar. Mais tarde, o usuário quer adicionar um fluxo de vídeo à sessão enviando outra mensagem de CONVITE de SIP, também referida como uma mensagem de RE-CONVITE. Na mensagem de RE-CONVITE, o SDP está descrevendo ambos o codec de fala e o codec de vídeo.

Um conceito dentro da estrutura de IMS/MMD é Aperte-paraConversar através de redes celulares (PoC). Este conceito permite aos usuários de telefones móveis se comunicarem em modo de meio-dúplex com um grupo de outros usuários de telefones móveis de uma maneira como 'walkie-talkie* através de IP. Uma vantagem de usar IP na rede celular é que usa recursos de rede mais eficientemente. Recursos de rede são usados só para a duração de surtos de conversa em vez de para uma sessão de chamada inteira. A sessão de chamada como tal é estabelecida usando SIP, e um canal de mídia para transportar voz está usando RTP. PoC também requer funções de controle de chamada específicas a fim de realizar a função de 'walkietalkie'. Por exemplo, quando um canal de mídia está inativo, um usuário pode pedir acesso a este canal (a fim de iniciar falando para outros usuários no grupo) apertando um botão no telefone móvel. Quando o usuário libera o botão, o canal de mídia se toma inativo e outros usuários no grupo podem pedir acesso a este canal. Este mecanismo é chamado 'controle de fundo’

como se relaciona a 'obter controle do fundo'. A fim de prover um padrão globalmente interoperável para PoC, a indústria de telecomunicação produziu várias especificações neste campo. Um exemplo é a especificação de PoC Liberação 1.0 PoC User Plane; Transport Protocols, que entre outros, especifica um mecanismo de controle de fundo no canal de mídia, usando o Protocolo de Controle de RTP (RTCP). O mecanismo de controle de fundo porém não trata mudança de serviço.

SUMARIO DA INVENÇÃO

Um problema com usar sinalização fora de banda (como por exemplo SIP/SDP) para mudança de serviço em conversações de multimídia é que cada mensagem de sinalização passa por um grande número de nós de rede intermediários (o Núcleo de SIP). O protocolo de SIP/SDP também usa grandes mensagens como o conteúdo nestas mensagens tem uma sintaxe de ASCII 'legível por humanos' em vez de serem codificadas em binário. O protocolo de SIP/SDP também requer que um restabelecimento de sessões em andamento seja precisado para cada mudança de serviço. Todos estes fatores conduzirão a atrasos desnecessários e alta carga de processador.

A presente invenção resolve estes problemas primeiramente separando a sinalização em dois planos, o plano de sinalização de sessão e o plano de sinal de controle de mídia.

O plano de sinalização de sessão inclui sinalização para controle de sessão (por exemplo, usando mensagens de sinalização de SIP como conhecido da técnica anterior). A sinalização de sessão é transportada em um canal de sinalização de sessão. O plano de sinal de controle de mídia inclui sinalização de controle de mídia como mudança de serviço, controle de fundo, etc. A sinalização de controle de mídia é transportada em um canal de controle de mídia separado do canal de sinalização de sessão. O canal de controle de mídia poderia tanto ser implementado de uma maneira 'em banda' em um canal de mídia ou usando um canal separado em relação íntima com o

canal de mídia.

A invenção também introduz um moderno procedimento de negociação de tipo de mídia envolvendo um servidor de aplicativo intermediário. Este servidor de aplicativo coleta informação sobre quais tipos de mídia cada cliente de multimídia envolvido em uma sessão pode suportar. Da informação coletada, o servidor de aplicativo pode tomar uma decisão sobre quais tipos de mídia cada cliente de multimídia está permitido usar para alcançar interoperabilidade máxima.

Um cliente de multimídia (um cliente iniciador de sessão) que deseja estabelecer uma sessão envolvendo dois ou mais clientes de multimídia convida os clientes de multimídia um por um. A sessão é estabelecida enviando uma mensagem de convite através de um canal de sinalização fora de banda ao servidor de aplicativo intermediário com o endereço para um cliente de multimídia convidado. A mensagem de convite também inclui um conjunto de tipos de mídia que o cliente iniciador de sessão pode suportar.

O servidor de aplicativo remete a mensagem de convite de sessão para o cliente de multimídia convidado. Se o cliente de multimídia convidado aceitar o convite, ele responde com um conjunto de tipos de mídia que pode suportar em uma mensagem de resposta de sessão. O servidor de aplicativo responde ao cliente iniciador de sessão com uma mensagem de resposta de sessão que o estabelecimento de sessão sucedeu.

Para cada procedimento de convite para outros clientes de multimídia, o servidor de aplicativo coleta informação sobre tipos de mídia suportados para estes outros clientes de multimídia.

Quando um dos clientes de multimídia envolvido na sessão (ademais referido como o cliente de multimídia pedinte ou transmissor) quer enviar um fluxo de multimídia com um ou mais tipos de mídia (tais como voz, vídeo, etc.), ele envia um primeiro pedido de mídia ao servidor de aplicativo incluindo um conjunto de tipos de mídia 'pedidos'. O conjunto de tipos de mídia 'pedidos' é um subconjunto ou igual a um conjunto de tipos de mídia suportados para o cliente de multimídia pedinte. Da informação coletada sobre quais tipos de mídia todos os clientes de multimídia na sessão podem suportar, o servidor de aplicativo concede ao cliente de multimídia pedinte um conjunto de tipos de mídia 'permitidos* em uma primeira concessão de mídia.

Os primeiros pedidos de mídia e as primeiras concessões de mídia são enviadas tanto nas mensagens de convite de sessão e nas mensagens de resposta de sessão ou em mensagens de controle de mídia separadas através de um canal de controle de mídia diferente do canal de sinalização. Este canal de controle de mídia pode ser implementado como um canal separado ou implementado 'em banda' em um canal de mídia. As mensagens de controle de mídia também poderíam usar uma sintaxe binária curta ao invés da sintaxe de ASCII longa usada em mensagens de controle de sessão conhecidas da técnica anterior (isto é, SIP).

O cliente de multimídia pedinte agora pode transmitir um fluxo de mídia (de acordo com o conjunto de tipos de mídia 'permitidos') através do canal de mídia para os clientes de multimídia receptores pelo servidor de aplicativo. O servidor de aplicativo reproduz (se necessário) o fluxo de mídia e o retransmite aos clientes de multimídia receptores.

A um certo momento durante a sessão, o usuário do cliente de multimídia pedinte gostaria de fazer uma mudança de serviço para os clientes receptores, por exemplo trocando de só transmitir voz para transmitir voz + vídeo.

O cliente de multimídia pedinte envia um novo pedido de mídia para o servidor de aplicativo incluindo um novo conjunto de tipos de mídia 'pedidos'. O servidor de aplicativo concede ao cliente de multimídia pedinte um novo conjunto de tipos de mídia 'permitidos' em uma nova concessão de mídia.

/21

O cliente de multimídia pedinte agora pode transmitir um fluxo de mídia (de acordo com o novo conjunto de tipos de mídia 'permitidos') através do canal de mídia para os clientes de multimídia receptores pelo servidor de aplicativo. Os novos pedidos de mídia e as novas concessões de mídia são enviados em mensagens de controle de mídia.

O servidor de aplicativo pode muito bem conceder o cliente de multimídia pedinte transmitir um certo tipo de mídia até mesmo se todos os clientes de multimídias receptores não suportarem isto. O servidor de aplicativo neste caso terminará o fluxo de mídia com este tipo de mídia dentro do servidor de aplicativo em vez de retransmiti-lo aos clientes de multimídia receptores.

O servidor de aplicativo também pode conceder ao cliente de multimídia pedinte conjuntos diferentes de tipos de mídia 'permitidos' dependendo de parâmetros adicionais, tais como informação de assinante, políticas locais obrigadas pelo servidor de aplicativo, etc.

O objetivo principal da invenção atual é permitir uma mudança de serviço rápida e eficiente e a invenção tem várias vantagens. Usando um protocolo de controle de mídia que é separado do protocolo de controle de sessão e que não está passando pelo Núcleo de SIP, o atraso de sinalização é reduzido na rede. O conceito inventivo também reduz significativamente a sinalização removendo a necessidade de restabelecer sessões em andamento para cada mudança de serviço. Sinalização e atrasos reduzidos aceleram o procedimento de mudança de serviço como percebido pelos usuários.

A invenção será descrita agora em mais detalhes e com concretizações preferidas e se referindo aos desenhos acompanhantes.

BREVE DESCRIÇÃO DOS DESENHOS

Figura 1 é um diagrama de bloco mostrando uma arquitetura funcional com elementos de rede envolvidos e sinalização e interfaces de mídia diferentes;

Figura 2 é um fluxograma descrevendo um fluxo de informação típico para uma mudança de serviço;

Figura 3 é um fluxograma descrevendo o fluxo de informação para estabelecer uma sessão de voz em uma concretização envolvendo VoIP e Vídeo;

Figura 4 é um fluxograma e uma continuação da Figura 3 descrevendo o fluxo de informação para pedir uma mudança de serviço em uma sessão de voz estabelecida em uma concretização envolvendo VoIP e Vídeo;

Figura 5 é um fluxograma descrevendo o fluxo de informação para estabelecer uma sessão em uma concretização envolvendo PoC e Vídeo;

Figura 6 é um fluxograma e uma continuação da Figura 5 descrevendo o fluxo de informação para pedir uma mudança de serviço em uma sessão estabelecida em uma concretização envolvendo PoC e Vídeo.

DESCRIÇÃO DETALHADA DAS CONCRETIZAÇÕES

Uma arquitetura funcional de um sistema de comunicação de multimídia implementando pelo menos uma concretização da invenção é achada na Figura 1. A arquitetura permite uma pluralidade de clientes de multimídia, exemplificada na Figura 1 como um telefone de vídeo móvel 110, um Servidor de Aplicativo 120 e uma rede 130. O Servidor de Aplicativo 120 inclui várias entidades funcionais como uma Unidade de Sinalização de Sessão 121 e uma Unidade de Recurso de Mídia 122. A Unidade de Sinalização de Sessão 121 tem Interfaces de Sinalização 123 que recebem e enviam mensagens de sinalização de SIP de e para o Cliente de Multimídia 110. O protocolo de sinalização de SIP é transportado em um Canal de Sinalização de Sessão 141. A Unidade de Recurso de Mídia 122 tem Interfaces de Controle de Mídia 124 que recebem e enviam sinalização de controle de mídia de e para o Cliente de Multimídia 110. Sinalização de controle de mídia é transportada em um Canal de Controle de Mídia 142. O fluxo de mídia é transportado em um Canal de Mídia 143. A Unidade de Recurso de Mídia 122 tem Interfaces de Mídia 125 que recebem e enviam os fluxos de mídia de e para o Cliente de Multimídia 110. A Unidade de Recurso de Mídia 122 se necessário reproduz o fluxo de mídia recebido de Cliente de Multimídia 110 para outros clientes de multimídia envolvidos em uma conversação de multimídia usando a Unidade de Reprodução 126. A Unidade de Recurso de Mídia 122 também pode terminar certos tipos de mídia no fluxo de mídia recebido de Cliente de Multimídia 110 que não são suportados por certos outros clientes de multimídia. O Servidor de Aplicativo 120 também inclui Lógica de Processador 128 para processar sinalização de sessão e sinalização de controle de mídia e uma Área de Memória 127 para armazenar dados, incluindo conjuntos de tipos de mídia suportados para cada Cliente de Multimídia 110.

O Canal de Sinalização de Sessão 141 pode passar por vários nós intermediários diferentes na rede 130, e em cada nó as mensagens de sinalização de sessão são processadas. Estes nós intermediários processando sinalização de SIP são coletados sob um termo genérico, o Núcleo de SIP 131.0 Canal de Controle de Mídia 142 e o Canal de Mídia 143 são ambos claramente separados do Canal de Sinalização de Sessão 141. O Canal de Controle de Mídia 142 e o Canal de Mídia 143 porém podem opcionalmente ser integrados no mesmo canal.

Figura 2 ilustra um fluxo de informação típico para uma mudança de serviço como visto do servidor de Aplicativo 120. O Servidor de Aplicativo 120 recebe uma mensagem de convite de sessão 201 de um primeiro cliente de multimídia. A mensagem de convite de sessão inclui um conjunto de tipos de mídia suportados pelo primeiro cliente de multimídia. Este conjunto é armazenado 204 no Servidor de Aplicativo 120. O Servidor de Aplicativo 120 envia uma mensagem de convite de sessão 202 para um segundo cliente de multimídia. Se o segundo cliente de multimídia aceitar o convite, ele envia uma mensagem de resposta de sessão 203. A mensagem de resposta de sessão 203 inclui um conjunto de tipos de mídia suportados pelo segundo cliente de multimídia. Este conjunto também é armazenado 204 no Servidor de Aplicativo 120. O Servidor de Aplicativo 120 também envia uma mensagem de resposta de sessão 205 para o primeiro cliente de multimídia indicando que o convite de sessão teve êxito. O procedimento de convite de sessão pode ser repetido para cada cliente de multimídia adicional que é convidado à sessão pelo primeiro cliente de multimídia.

Quando quaisquer dos clientes de multimídia envolvidos na sessão, um cliente de multimídia pedinte deseja começar a transmitir um fluxo de mídia (por exemplo, voz) para os outros clientes de multimídia, o cliente de multimídia pedinte envia um primeiro pedido de mídia 206. Este primeiro pedido de mídia 206 inclui um primeiro conjunto de tipos de mídia pedidos. Como o servidor de Aplicativo 120 tem conhecimento de tipos de mídia suportados pelos outros clientes de multimídia, o servidor de Aplicativo 120 compara 207 o primeiro conjunto de tipos de mídia pedidos com todos os conjuntos de tipos de mídia suportados pelos outros clientes de multimídia e concede o pedido respondendo com uma concessão de mídia 208 com um primeiro conjunto de tipos de mídia permitidos. O cliente de multimídia pedinte agora pode transmitir um fluxo de mídia no canal de mídia com tipos de mídia de acordo com o primeiro conjunto de tipos de mídia permitidos. O fluxo de mídia é recebido 209 pelo Servidor de Aplicativo 120 e é reproduzido (se necessário) e retransmitido 210 para os outros clientes de multimídia. Durante a conversação, o cliente de multimídia pedinte deseja modificar o fluxo de mídia (por exemplo, adicionando vídeo a uma conversação de voz existente). O cliente de multimídia pedinte envia um segundo pedido de mídia 211 ao Servidor de Aplicativo 120 incluindo um segundo conjunto de tipos de mídia pedidos. O servidor de Aplicativo 120 compara 212 o segundo conjunto de tipos de mídia pedidos com todos os ίί

conjuntos de tipos de mídia suportados pelos outros clientes de multimídia, e concede o pedido com uma segunda concessão de mídia 213. Esta segunda concessão de mídia 213 inclui um segundo conjunto de tipos de mídia permitidos. O cliente de mídia pedinte pode agora transmitir um fluxo de mídia modificado no canal de mídia com tipos de mídia de acordo com o segundo conjunto de tipos de mídia permitidos. O fluxo de mídia é recebido 214 pelo servidor de Aplicativo 120, reproduzido (se necessário), e retransmitido 215 para os outros clientes de multimídia.

O primeiro e segundo pedidos de mídia 206, 211 e a primeira e segunda concessões de mídia 208, 213 são enviados tipicamente em mensagens de controle de mídia.

O fluxo de informação típico na Figura 2 permite opções diferentes. Se o cliente de multimídia pedinte for o mesmo como o primeiro cliente de multimídia e o primeiro cliente de multimídia desejar começar a enviar dados diretamente depois do procedimento de convite, o primeiro pedido de mídia 206 e a primeira concessão de mídia 208 podem ser incorporados nas mensagens de convite de sessão e resposta de sessão 202, 205, respectivamente. Altemativamente, também é possível enviar o primeiro pedido de mídia 206 na mensagem de convite de sessão e enviar a primeira concessão de mídia 208 em uma mensagem de controle de mídia separada.

Outra opção é deixar o primeiro pedido de mídia 206 e a primeira concessão de mídia 208 serem substituídos por uma concessão de mídia 'implícita’. Se, por exemplo, o Servidor de Aplicativo 120 souber (por exemplo, de dados de assinatura de cliente de multimídia armazenados ou observando outros parâmetros na mensagem de convite de sessão 201) que um serviço de VoIP é pedido, uma primeira concessão de mídia 208 pode ser incorporada na mensagem de convite de sessão 202 para o segundo cliente de multimídia e na mensagem de resposta de sessão 205 para o primeiro cliente de multimídia. A primeira concessão de mídia 208 neste exemplo incluirá o tipo de mídia de 'voz' como uma conversação de VoIP começa normalmente usando voz.

Além de comparar tipos de mídia 207, 212, o Servidor de Aplicativo 120 pode conceder 208, 213 os conjuntos diferentes de cliente de multimídia pedinte de tipos de mídia permitidos dependendo de outros parâmetros, tais como informação de assinante, políticas locais obrigadas pelo Servidor de Aplicativo 120, etc.

O procedimento de mudança de serviço descrito acima e na Figura 2 certamente não está limitado a um ou dois eventos de mudança de serviço somente. A qualquer momento durante a sessão à conveniência de quaisquer dos clientes de multimídia envolvidos, uma mudança de serviço pode ser pedida e pode ser repetida usando as mensagens de controle de mídia descritas acima.

Para clientes de multimídia que não suportam um certo tipo de mídia no fluxo de mídia retransmitido, este certo tipo de mídia pode ser terminado no Servidor de Aplicativo 120 antes que alcance estes clientes.

Figuras 3 e 4 descrevem uma concretização de um estabelecimento de sessão e um procedimento de mudança de serviço para uma conversação de VoIP (Voz através de IP) que é enriquecida com vídeo (por exemplo, um videoclipe). Entidades de rede envolvidas no fluxo de informação são dois terminais de usuário ou clientes de multimídia, Cliente-1 310 e Cliente-2 350, o Núcleo de SIP 131 e o Servidor de Aplicativo 120.

Os clientes de multimídia 310, 350 estão se comunicando com o Servidor de Aplicativo 120 usando sinalização de SIP e sinalização de controle de Mídia. Mensagens de sinalização de SIP são transportadas tipicamente em um canal de sinalização de sessão 141 e são processadas por vários nós intermediários na rede de sinalização, o Núcleo de SIP 131. A Sinalização de controle de Mídia está separada do Núcleo de SIP e é transportada em um canal de controle de mídia 142. O Servidor de Aplicativo

120 também recebe e retransmite os fluxos de mídia recebidos dos clientes de multimídia 310, 350 no canal de mídia 143,

O fluxo de informação para estabelecer a sessão entre Cliente1 310 e Cliente-2 350 é ilustrado na Figura 3. Figura 4 descreve o fluxo de informação para o procedimento de mudança de serviço.

Um usuário usando seu Cliente-1 310 pede para iniciar 301 uma sessão de multimídia com outro usuário usando Cliente-2 350. Cliente-1 310 envia uma mensagem de CONVITE de SIP 311 ao Núcleo de SIP 131. A mensagem de CONVITE de SIP 311 inclui um conjunto de todos os tipos de

Io mídia que Cliente-1 310 pode suportar (neste exemplo, voz e vídeo). A mensagem de CONVITE de SIP 311 também inclui um primeiro conjunto de tipos de mídia pedidos (neste exemplo, voz somente). O Núcleo de SIP 131 responde com uma mensagem de 100 Tentativa de SIP 312. A mensagem de 100 Tentativa de SIP 312 indica que a mensagem de CONVITE de SIP 311 foi recebida pelo Núcleo de SIP 131 e que alguma ação não especificada está sendo tomada em nome desta sessão. O Núcleo de SIP 131 envia uma mensagem de CONVITE de SIP 321 ao Servidor de Aplicativo 120 incluindo os conjuntos de tipos de mídia recebidos de Cliente-1 310. O Servidor de Aplicativo 120 responde com uma mensagem de 100 Tentativa de SIP 322 para o Núcleo de SIP 131. O Servidor de Aplicativo 120 armazena os conjuntos de tipos de mídia recebidos de Cliente-1 310 e envia uma mensagem de CONVITE de SIP 331 ao Núcleo de SIP 131. O Núcleo de SIP 131 responde ao Servidor de Aplicativo 120 com uma mensagem de 100 Tentativa de SIP 332 e envia uma mensagem de CONVITE de SIP 341 para

Cliente-2 350. Cliente-2 350 gera uma indicação de chamada entrante 351 para o usuário de Cliente-2. Se o usuário aceitar 352 o convite de sessão, Cliente-2 350 envia uma mensagem de 200 OK de SIP 342 para o Núcleo de SIP 131, que por sua vez envia uma mensagem de 200 OK de SIP 333 ao Servidor de Aplicativo 120. As duas mensagens de 200 OK de SIP 342, 333

levam um conjunto de todas os tipos de mídia que Cliente-2 350 pode suportar (neste exemplo, voz e vídeo) e este conjunto é armazenado no Servidor de Aplicativo 120. O Servidor de Aplicativo 120 compara os dois conjuntos de todos os tipos de mídia que são suportados por Cliente-1 310 e Cliente-2 350, respectivamente. Como Cliente-1 310 pediu só voz para começar e como Cliente-2 350 suporta voz, o Servidor de Aplicativo 120 envia uma mensagem de 200 OK de SIP 323 incluindo um primeiro conjunto de tipos de mídia permitidos (neste caso, só voz). O Núcleo de SIP 131 remete esta informação para Cliente-1 310 em uma mensagem de 200 OK de SIP 313. Cliente-1 310 envia uma mensagem de ACK de SIP 314 para o Núcleo de SIP 131, que envia uma mensagem de ACK de SIP 324 ao Servidor de Aplicativo 120.

É agora possível para Cliente-1 310 começar a enviar voz para Cliente-2 350 pelo Servidor de Aplicativo 120 no canal de mídia 143 usando o protocolo de RTP 325, 343.

Se o usuário de Cliente-1 durante a conversação de voz gostaria, além de voz, de enviar um videoclipe ao vivo para Cliente-2 350, uma mudança de serviço é necessária. O fluxo de informação para esta mudança de serviço é achado na Figura 4. Quando o usuário de Cliente-1 pede 401 para fazer esta mudança de serviço, Cliente-1 310 envia uma mensagem de Controle de Mídia 411 para o Servidor de Aplicativo 120 com um pedido para transmitir voz e vídeo. Como ambos Cliente-1 310 e Cliente2 350 suportam vídeo, o Servidor de Aplicativo 120 concede este pedido com uma mensagem de Controle de Mídia 412. O Servidor de Aplicativo 120 também envia uma mensagem de Controle de Mídia 431 para Cliente-2 350 indicando uma mudança de serviço. Cliente-1 310 pode enviar agora ambos um fluxo de mídia de voz e vídeo 421, 441 para Cliente-2 350.

Quando o usuário de Cliente-1 pede para terminar 403 o fluxo de vídeo e continuar só com o fluxo de voz, Cliente-1 310 envia uma

2&

mensagem de Controle de Mídia 413 para o Servidor de Aplicativo 120, pedindo para liberar o fluxo de vídeo. O Servidor de Aplicativo 120 também envia uma mensagem de Controle de Mídia 432 para Cliente-2 350 indicando uma nova mudança de serviço.

Cliente-1 310 agora envia só voz 422, 442 para Cliente-2 350. Como a mensagem de Controle de Mídia 413 se relacionava a uma liberação de um tipo de mídia, não é necessário para o Servidor de Aplicativo 120 enviar qualquer mensagem de resposta.

Outra e uma concretização preferida da invenção são ilustradas por Figura 5 e Figura 6. Figuras 5 e 6 descrevem um estabelecimento de sessão e um procedimento de mudança de serviço para PoC (Aperte-paraconversar através de Celular) que é enriquecido com vídeo. O princípio é o mesmo como para VoIP (Figuras 3 e 4), mas aqui a Sinalização de Controle de Mídia é levada nas mesmas mensagens como usadas em um procedimento de Controle de Fundo de PoC e aplicativos de conferência. Controle de fundo em um contexto de PoC é basicamente a possibilidade para um usuário de um telefone móvel pedir um acesso de meio-dúplex a um canal de comunicação comum a um grupo de outros usuários de telefone móvel simplesmente apertando um botão no telefone móvel.

Começando com a Figura 5, um primeiro usuário de PoC aperta 501 um botão de PoC em seu telefone móvel, um Cliente-1 de PoC 510. Se nenhuma sessão com outros telefones móveis já existir, este evento 501 começa um processo de iniciação de sessão para Cliente-1 de PoC 510, que envia uma mensagem de CONVITE de SIP 511 ao Núcleo de SIP 131. Esta mensagem de CONVITE de SIP 511 também é considerada como um 'Pedido de Fundo' implícito. A mensagem de CONVITE de SIP 511 inclui um conjunto de todos os tipos de mídia que Cliente-1 de PoC 510 pode suportar (neste exemplo, áudio e vídeo). A mensagem de CONVITE de SIP 511 também inclui um primeiro conjunto de tipos de mídia pedidos (neste exemplo, só áudio). O Núcleo de SIP 131 responde ao Cliente-1 de PoC 510 com uma mensagem de 100 Tentativa de SIP 512 e envia uma mensagem de CONVITE de SIP 521 ao Servidor de Aplicativo 120. A mensagem de CONVITE de SIP 521 inclui os conjuntos de tipos de mídia recebidos de Cliente-1 de PoC 510. O Servidor de Aplicativo 120 responde com uma mensagem de 100 Tentativa de SIP 522 para o Núcleo de SIP 131.0 Servidor de Aplicativo 120 armazena o conjunto de todos os tipos de mídia que Cliente-1 de PoC 510 pode suportar e envia uma mensagem de CONVITE de SIP 531 ao Núcleo de SIP 131.0 Núcleo de SIP 131 responde ao Servidor de Aplicativo 120 com uma mensagem de 100 Tentativa de SIP 532 e envia uma mensagem de CONVITE de SIP 541 para um Cliente-2 de PoC 550.

Cliente-2 de PoC 550 envia uma mensagem de 200 OK de SIP 542 para o Núcleo de SIP 131, que por sua vez envia uma mensagem de 200 OK de SIP 533 para o Servidor de Aplicativo 120. As duas mensagens de 200 OK de SIP 542, 533 levam um conjunto de todos os tipos de mídia que Cliente-2 de PoC 550 pode suportar (neste exemplo, áudio e vídeo). Este conjunto de tipos de mídia é armazenado no Servidor de Aplicativo 120. O Servidor de Aplicativo 120 compara os dois conjuntos de todos os tipos de mídia que são suportados por Cliente-1 de PoC 510 e Cliente-2 de PoC 550, respectivamente. Como pedido Cliente-1 de PoC 510 só pediu áudio para começar e como Cliente-2 de PoC 550 suporta áudio, o Servidor de Aplicativo 120 envia uma mensagem de 202 Aceito de SIP 524. O Núcleo de SIP 131 remete esta informação para Cliente-1 de PoC 510 em uma mensagem de 202 Aceito de SIP 513. Junto com enviar a mensagem de 202 Aceito de SIP 524, o Servidor de Aplicativo 120 também envia uma mensagem incluindo uma combinação de uma mensagem de Pedido de Mídia e mensagem de Controle de Fundo 523 com um primeiro conjunto de tipos de mídia permitidos (neste caso, áudio).

Cliente-1 de PoC 510 envia uma mensagem de ACK de SIP

514 para o Núcleo de SIP 131, que envia uma mensagem de ACK de SIP 525 para o Servidor de Aplicativo 120. O usuário de Cliente-1 de PoC recebe uma indicação de conversa 502, que é possível começar a falar. O Servidor de Aplicativo 120 envia uma mensagem de Áudio Tirado de Fundo 534 para Cliente-2 de PoC 550 e o usuário de Cliente-2 de PoC recebe uma Indicação de Escuta 551.

Como ilustrado por Figura 6, agora é possível para Cliente-1 de PoC 510 começar a enviar 601 um fluxo de áudio de meio-dúplex para Cliente-2 de PoC 550 pelo servidor de Aplicativo 120 no canal de mídia 143 usando o protocolo de RTP 621, 641.

O usuário de Cliente-1 de PoC pode a qualquer momento 'liberar o fundo' e fazer o canal disponível para outros clientes de PoC liberando 602 o botão de PoC. Uma mensagem de Liberação de Áudio de Fundo 611 é enviada ao Servidor de Aplicativo 120. O Servidor de Aplicativo 120 envia uma mensagem de Fundo Inativo 631 para Cliente-2 de PoC 550 para indicar que o fundo está inativo e o usuário de Cliente-2 de PoC recebe uma Indicação de Fundo Inativo 651 em Cliente-2 de PoC 550.

A algum momento durante a sessão, o usuário de Cliente-1 de PoC pede 603 para enviar uma salva de multimídia envolvendo ambos áudio e vídeo. Cliente-1 de PoC 510 envia uma mensagem de Pedido de Áudio e Vídeo de Fundo 612 ao Servidor de Aplicativo 120. Se o Servidor de Aplicativo 120 conceder o pedido, ele envia uma mensagem de Áudio e Vídeo Tirado de Fundo 632 para Cliente-2 de PoC 550 e uma mensagem de Áudio e Vídeo Concedido de Fundo 613 para Cliente-1 de PoC 510. O usuário de Cliente-2 de PoC recebe uma indicação de Chamada de Vídeo e Áudio Entrante 652 em Cliente-2 de PoC 550 e o usuário de Cliente-1 de PoC recebe 604 uma indicação de Converse e Mostre em Cliente-1 de PoC 550.

É agora possível para Cliente-1 de PoC 510 começar a enviar um fluxo de voz e vídeo de meio-dúplex para Cliente-2 de PoC 550 pelo

Servidor de Aplicativo 120 no canal de mídia 143 usando o protocolo de RTP 622, 642.

Quando o usuário de Cliente-1 de PoC pede para liberar 605 o fluxo de áudio e vídeo, Cliente-1 de PoC 510 enviará uma mensagem de Liberação de Áudio e Vídeo de Fundo 614 para o Servidor de Aplicativo 120 e o servidor de Aplicativo 120 envia uma mensagem de Fundo Inativo 633 para Cliente-2 de PoC 550. O usuário de Cliente-2 de PoC recebe uma Indicação de Fundo Inativo 653 em Cliente-2 de PoC 550 e o Canal de mídia entre Cliente-1 de PoC 510 e Cliente-2 de PoC 550 está agora inativo. O 'fundo' pode ser pedido agora por quaisquer dos clientes envolvidos na sessão.

Embora as concretizações da invenção como descritas e ilustradas pelas figuras acima estejam mostrando uma mudança de serviço entre dois clientes de multimídia somente, o conceito inventivo certamente está permitindo uma mudança de serviço envolvendo um número arbitrário de clientes de multimídia. Para cada novo cliente de multimídia que é convidado, uma mensagem de CONVITE de SIP é enviada ao cliente convidado pelo Servidor de Aplicativo 120. Para cada mensagem de 200 OK de SIP que o Servidor de Aplicativo 120 recebe de cada cliente convidado, os conjuntos de tipos de mídia suportados por cada cliente convidado e contidos nestas mensagens são armazenados no Servidor de Aplicativo 120. A cada vez que um cliente de multimídia arbitrário pertencendo à sessão (um cliente de multimídia pedinte) envia um pedido para enviar um fluxo de mídia (ou enviar um pedido de fundo'), o Servidor de Aplicativo 120 concede este pedido baseado na disponibilidade do canal de mídia 143 naquele momento particular e nos tipos de mídia suportados por todos os outros clientes de multimídia envolvidos. Novamente, o servidor de aplicativo pode muito bem conceder o cliente de multimídia pedinte para transmitir um certo tipo de mídia até mesmo se certos clientes de multimídia pertencendo à sessão não suportarem isto. O servidor de aplicativo neste caso terminará o fluxo de mídia com este tipo de mídia dentro do servidor de aplicativo em vez de retransmiti-lo para estes certos clientes de multimídia.

Também é importante enfatizar que o termo 'tipo de mídia' deveria ser interpretado como não sendo apenas voz, vídeo, imagens, etc., como tal, mas podería por exemplo também significar tipos diferentes de codecs usando algoritmos diferentes para codifícar/decodificar voz, vídeo, etc.

1/4

Claims

REIVINDICAÇÕES

1. Método para prover serviços diferentes em um sistema de comunicação de multimídia incluindo um servidor de aplicativo (120) e uma pluralidade de clientes de multimídia (110), caracterizado pelo fato de

5 compreender as etapas seguintes:

receber (201) em um canal de sinalização de sessão (141) de um primeiro dos clientes de multimídia um pedido para convidar pelo menos um segundo dos clientes de multimídia para fazer parte de uma conversação de multimídia;

10 receber (201) no canal de sinalização de sessão (141) do primeiro cliente de multimídia um conjunto de tipos de mídia suportados por dito primeiro cliente de multimídia;

enviar (202) no canal de sinalização de sessão (141) ao segundo cliente de multimídia um pedido para convidar dito segundo cliente

15 de multimídia para fazer parte da conversação de multimídia;

receber (203) no canal de sinalização de sessão (141) do segundo cliente de multimídia um conjunto de tipos de mídia suportados por dito segundo cliente de multimídia;

armazenar (204) os conjuntos de tipos de mídia suportados

20 pelos primeiro e segundo clientes de multimídia;

receber (206) em um canal de controle de mídia (142) de um cliente de multimídia transmissor dos clientes de multimídia um pedido para transmitir um fluxo de mídia de acordo com um primeiro conjunto de tipos de mídia pedidos para pelo menos um cliente de multimídia receptor dos clientes

25 de multimídia, onde o cliente de multimídia transmissor e o cliente de multimídia receptor fazem todos parte da conversação de multimídia;

comparar (207) o primeiro conjunto de tipos de mídia pedidos com cada conjunto de tipos de mídia suportados por cada cliente de multimídia receptor;

Petição 870170085087, de 06/11/2017, pág. 8/11
2/4 enviar (208) em um canal de controle de mídia (142) ao cliente de multimídia transmissor uma concessão relacionada ao primeiro conjunto de tipos de mídia pedidos;

receber (209) do cliente de multimídia transmissor um 5 primeiro fluxo de mídia incluindo tipos de mídia de acordo com o primeiro conjunto de tipos de mídia pedidos; e retransmitir (210) o primeiro fluxo de mídia para o cliente de multimídia receptor;

receber (211) no canal de controle de mídia (142) do cliente de 10 multimídia transmissor um pedido para transmitir um fluxo de mídia de acordo com o segundo conjunto de tipos de mídia pedidos para o cliente de multimídia receptor;

comparar (212) o segundo conjunto de tipos de mídia pedidos com cada conjunto de tipos de mídia suportados por cada cliente de

15 multimídia receptor;

enviar (213) no canal de controle de mídia (142) ao cliente de multimídia transmissor uma concessão relacionada ao segundo conjunto de tipos de mídia pedidos;

receber (214) um segundo fluxo de mídia incluindo tipos de 20 mídia de acordo com um segundo conjunto de tipos de mídia permitidos do cliente de multimídia transmissor e retransmitir (215) o segundo fluxo de mídia ao cliente de multimídia receptor.

2. Método de acordo com reivindicação 1, caracterizado pelo 25 fato de que ditos pedidos para convidar o segundo dos clientes de multimídia e dito conjunto de tipos de mídia suportados pelo primeiro dos clientes de multimídia são transportados em mensagens de convite de sessão.
3. Método de acordo com reivindicação 2, caracterizado pelo fato de que dito conjunto de tipos de mídia suportado pelo segundo dos

Petição 870170085087, de 06/11/2017, pág. 9/11

3/4 clientes de multimídia é transportado em uma mensagem de resposta de sessão.
4. Método de acordo com reivindicação 1, caracterizado pelo fato de que ditos pedidos para transmitir um fluxo de mídia de acordo com o
5 primeiro e o segundo conjunto de tipos de mídia pedidos são transportados em mensagens de controle de mídia.

5. Método de acordo com reivindicação 4, caracterizado pelo fato de que as concessões relativas aos ditos primeiro e segundo conjunto de tipos de mídia pedidos são transportadas em mensagens de controle de mídia.

10 6. Método de acordo com reivindicações 3, caracterizado pelo fato de que ditas mensagens de convite de sessão e de resposta de sessão fazem parte do Protocolo de Iniciação de Sessão, SIP.

7. Método de acordo com qualquer uma das reivindicações 1 a 6, caracterizado pelo fato de que ditos primeiro e segundo fluxos de mídia são

15 transportados em um canal de mídia.

8. Método de acordo com a reivindicação 1, caracterizado pelo fato de que cada um do primeiro e do segundo conjunto de tipos de mídia pedidos é igual a ou é um subconjunto de um conjunto de tipos de mídia suportados pelo cliente de multimídia transmissor.

20 9. Servidor de aplicativo (120) para um sistema de comunicação de multimídia, caracterizado pelo fato de compreender:

a) pelo menos uma interface de sinalização (123) projetada para remeter em um canal de sinalização (141) de um primeiro cliente de multimídia (310) a um segundo cliente de multimídia (350) um pedido para

25 convidar o segundo cliente de multimídia (350) para uma conversação multimídia e para receber um conjunto de tipos de mídia suportado de ambos o primeiro e o segundo cliente de multimídia (310, 350);

b) pelo menos uma interface de controle de mídia (124) projetada para receber em um canal de controle de mídia (142) pedidos

Petição 870170085087, de 06/11/2017, pág. 10/11

4/4 subsequentes e enviar concessões correspondentes para transferir fluxos de mídia com diferentes tipos de mídia de e para os clientes de multimídia (310, 350);

c) pelo menos uma interface de mídia (125) projetada para

5 receber e transmitir fluxos de mídia em um canal de mídia (143) de e para os clientes de multimídia (310, 350);

d) uma unidade de reprodução (126) projetada para reproduzir um fluxo de mídia recebido de um dos clientes de multimídia (310) em uma pluralidade de fluxos de mídia destinados a uma pluralidade dos clientes de

10 multimídia;

e) uma área de memória (127) projetada para armazenar os conjuntos de tipos de mídia suportados recebidos de ditos primeiro e segundo clientes de multimídia (310, 350);

f) lógica de processador (128) projetada para comparar os tipos 15 de mídia pedidos e os conjuntos de tipos de mídia suportados armazenados e para conceder os pedidos dos clientes de multimídia (310, 350).

10. Servidor de aplicativo (120) de acordo com reivindicação 9, caracterizado pelo fato de ser projetado para terminar pelo menos um dos tipos de mídia em um fluxo de mídia recebido de um dos clientes de

20 multimídia (310) se certos dos clientes de multimídia (310, 350) não suportarem estes tipos de mídia.

11. Servidor de aplicativo (120) de acordo com reivindicação 9, caracterizado pelo fato de que dita interface de controle de mídia (124) está integrada na interface de mídia (125).

25 12. Servidor de aplicativo (120) de acordo com reivindicação

9, caracterizado pelo fato de que a interface de sinalização (123) é projetada para suportar sinalização de SIP.

Petição 870170085087, de 06/11/2017, pág. 11/11

1/6 • · · · · · • * · * ·

3<7

120

2/6

Convite de sessão

201

Receber fluxo 1

209

Convite de sessão

202

Resposta de sessão

203

Armazenar conjuntos de 1 ^204 tipos de mídia

Resposta de sessão

205

Retransmitir fluxo 1

210

Pedido de mídia 1

206

Comparar conjuntos de tipos de mídia

207

Concessão de mídia 1

208

Pedido de mídia 2

Comparar conjuntos de tipos de mídia

211

212

FIGURA 2

3/6

FIGURA 3

4/6

FIGURA 4

5/6 o

LO

FIGURA 5

3%
6/6 ο

FIGURA 6