PT1931104E - Processo de controlo do estabelecimento de canais de comunicação multimédia - Google Patents

Description

PROCESSO DE CONTROLO DO ESTABELECIMENTO DE CANAIS DE COMUNICAÇÃO MULTIMÉDIÂ

DOMÍNIO TÉCNICO DA INVENÇÃO Ά presente invenção diz respeito is telecomunicações utilizando os protocolos de telefonia em PI (Protocolo de Internet) ou de estabelecimento de sessão multlmedlâ, e mais particuiarmente, com o fim de controlar o estabelecimento de canais de comunicação numa rede gerada por um operador, um processo e um sistema de geatâo de sessões multíméáia»

SITUAÇÃO TECNOLÓGICA ANTERIOR A INTENÇÃO A Internet é uma rede de dados bem conhecida. Num domínio PI (protocolo de Internet), abre-se a rede de dados, O que significa que não importa quais os terminais que podem comunicar dois a dois, per exemplo utilizando o mesmo protocolo de sinaliraçao. Podem assim ser criadas sessões do tipo mnltímédía, via a rede da internet, entre dois terminais de comunicação» A convergência entre as redes de voz e as redes de dados é permitida peia utilização de protocolos de sinalização adaptados. A tecnologia, Voz: em F1 ou VoPI e, mais geralmente, as tecnologias permitindo: o estabelecimento de cessões moltimêdia utilizam:, mais frequentemente, o . pro: focolo SXP (Sessão de Iniciação de Protocolo), que é um padrão aberto. interoperacioral. Outros prot oc o1os de sinalização, por exemplo H323, PC.H )M (Protocolo de C< >n.trol ,o das Entradas médias) 2 - 41 e Megaeo ( tendo esto último protocolo sido escolhido da norma UHTS pelo 3GPP para o controlo das passereiles Entrada a Médias) podem tamisem ser utilizados para as sessões muitimédia- 0 protocolo SXP é normalizado pelo PETI { Força de Engenharia das: Tarefas de Internet) e descrito em particular pelo RFC 3261, 0 protocolo SIP, como os protocolos H323 a MGCP foi. concebido pare estabelecer, modificar e terminar sessões multimédia, O protocolo encarrega-se da autenticação e locallração dos participantes múltiplos. Encarrega-se t iguaimente, da negociação sobre os tipos de meios utilizáveis pelos diferentes participantes encapsulando mensagens SDP íSessão da Descrição de Protocolo). 0 protocolo SIF nâo transporta dados trocados durante a sessão,- como a voz ou video. Este protocolo, sendo independente da transmissão de dados, todo o tipo de dados e de protocolos pode ser utilizado para esta troca s ê o protocolo FTTR {Protocolo de Transporte em Tempo Real.) que assegura, maia frequentemente „ as sessões audio e video. Uma vantagem do protocolo STP é que não se: destina somente à voz no PI mas, Iguâlmsnts, a numerosas outras aplicações tais como a imagem, a mensagem. Instantânea, a realidade virtual ou mesmo os jogos video.

Como qualquer outro protocolo de sinalização, o SIP incorpora uma fase de declaração junto da rode de ligação, seguidas de fases de pedido de estabelecimento de sessões multimédia, de negociação, de oâracteristicas do serviço pedido e enfim uma fase de encerramento da sessão mnitimédia,, Q protocolo de iniciação cie protocolo· SIP (Sessão de Iniciação de Protocolo) permite: a partir da versão v 2.0 trocas de inforajações entre os titulares em comunicação antes, ou durante, a sessão mui. timédia. De modo conhecido em si mesmo* estas trocas podem ser realizadas através dos métodos seguintes:

INFOi permite trocar a informação não afectando o estado da chamada (descrito na .RFC 2976} . Sm certos casos este campo é utilizado para transferir tonalidades DTMF HOTlflCâÇãO:. permite enviar notificações de acontecimentos (RFC 3265). SUBSCRE7EE;: permite abonar-se a uma notificação de acontecimentos (descrito n& RFC 3265). éC?UÃil2ÃÇASi é utilizada para Actualizar os parâmetros médios (cf RFC 3311); MEMSÃSEM: este método definido na RFC 3428 «Extensão SIP para mensagens instantâneasn pé-mi te trocar as mem&gem instantâneas entre dois terminais.

Ruma rede de radiotelefonia, por exemplo,· a utilização de tais protocolos (:S1P/B323/MSCR) para sessões mal timédia pode permitir trocas de informações através de canais de dados paralelos aos canais de voz. Mas o inconveniente destes métodos de troca de informação é que eles não são sempre suportados pelas redes sub-jacentes e/ou pelos terminais 4 -- 41 simples.. DESCRIÇÃO GERAL DA ikverçAo A presente invenção tem, portanto, por objeetivo suprimir um ou vários dos inconvenientes do estado da técnica anterior deflnin.de· um processo permitindo novas utili rações do protocolo de sinalização aproveitando ao máximo potencialidades da infraestrutura da rede suportando este tipo de protocolo.

Um ensinamento secundo a presente invenção mostra para isso um maneira de utilizar os métodos elementares, necessários ao estabelecimento de uma sessão multimêdia e, uma maneira de os encaminhar pelo conjunto das redes. Através de um novo uso, em conformidade com as normas, estes métodos simples sâo, por exemplo, capazes dé> reduzir o problema da renegociação em tempo real da qualidade negociada para a sessão multimêdia estabelecida. 0 docnirento ER A - 1S5D9A5 explica um processo de: controlo de estabelecimento de canais de trocas para permitir uma transmiasãó de informações multimêdia entre peio menos dois terminais de comunicação ligados entre si por uma rede de telecomunicações, compreendendo uma étapa de estabelecimento: de uma comunicação entra um primeiro terminal de comunicação e um segundo terminal dê comunicação: por utilização de aplicações respèctivas, gerando um protocolo de sinalização determinado, permitindo iniciai' sessOes, efectuando o primeiro terminal ama étapa. da selecçao de, peio menos, um canal de troca de dados entre os dois terminais efectnando-se a étapa de selecçao a um nivel aplicativo e compreendendo a étapa de estabelecijaento de ma comunicação, a étapa seguinte: ~ uma étapa de emissão de pelo Tuenos am pedido, pelo primeiro terminai, com destino a um segundo terminal, adrindo uma sessão de acordo com o protocolo de sinalinação determinado a invenção desenvolve este processo acresdentando uma étapa de envio pelo segundo terminai de uma resposta representativa da uma indisponibilidade para encerrar a sessão de acordo com o protocolo de .sinalização determinado e o processo compreendendo, quando das etapas de emissão e de envio, uma étapa de transxaissão de informações adicionais além do dito protocolo de sinalização, por utilização do dito canal de troca de dados seisccionado, sendo este cãnal de troca de dados acessível via um campo puramente descritivo/erplicativo de earacterlsticas de uma sessão, correspondendo as ditas informações adicionais a informações aplicativas não necessárias à gestão de sessões multimédia,

* È. invenção permite, assim, controlar a emergência de soluções a um nivel de aplicação que permite usos inovadores/invulgares das infrestruturas (3XP ou IMS especialmente) de um operador de rede. G funcionamento Intrínseco do protocolo de sinalização (por ememplo SIP) β ~ 41 permanece inalterado de modo a poder beneficiar de uma infraestrutura de rede elementar ao nível mundial·.

Compreende-se que o processo pode permitir alargar, com vantagem* o uso doa isètodos do protocolo cie sinaltração a fim de por exemplo trocar informações de sinalIração em relação oom o serv e / ou a sua qualidad & cl sua entrega por outro modo que nlo seja c :· canal da d o alui jado (PPTR) entre as rn rs ^ ^ CÍ CÍ ^ coim; ni cantei 5. A troca por e sta via inédita (via campos contex tuais } de infor aplicativas permite assegurar i m. serviço ei n tempo real De acordo * soai uma outr a P a r t r cu 1 a r Idade, o processo compreende uma étapa de identif reação pelo prime ire terminal de pelo menos um canal de troe ia de dados sasoeptivel de ser utiiirado para a é de f. ransmissâo de in forma eõ e s adiciona1s, resultando a identific aça o de uma étapa de pesquisa dé canais de trocas, iir.5 qual o primeiro ta írminal analisapelo menos um resposta do segundo terminai a um pedido no qual um dos campos paramente descritivo.#, foi carregado com informações adicionais além do dito protocolo de sinalíração.

De acordo coai uma outra particularidade, a étapa de pesquisa de canais de trocas compreende uma étapa de envio pelo segundo terminai de um conjunto de mensagens de resposta a pedidos do prime ir o te rminai.

De acordo com um outra particularidade, o canal de troca de dados seieceionado ê utilísado para difundir, de um extremo a outro, informações meltimédia. adicionais em paralelo uie, í s e t« spa de selecí jão *nais de troca de da; los snsmís são de i xiformaçí ;e, o proc esso compreende omuni caçâc ; em tempo rt sal e um serv idor através de endo uma capa iciaaoe de e de mensagens de dado: 5 api .icati vos. àade, pei< ; men os um < ios campos seguintes 4 utilizado para a etapa de transmissão de informações adicionais além do protocolo SIPt -Sm cabeçalho dos pacotes SXP em que são mencionadas caracterisfeioas de sessão; -Descritivo do código de resposta;

-Chamada ID -Ramo

-ThG

De acordo com uma outra particularidade:, pelo menos um campo associado ao método HERSAGBM do protocolo SXã è utilizado para a etapa de trasnmissâo de informações adicionais alem do; protocolo D1P,

De acordo coxa uma outra particularidade, pelo menos um campo Β - 41 assoarado à: Informação SDP, dé dsrqa útil dé SIP é utilissdo para a étapa de tranámissão de informações adicionais alem de protocolo SIP, seru :io este campo SDP, π a oarqa útil de SIP, definido como opc ionai peio protocole 5 SI? ou tende y uma estrutura e uma s 1 π taxe que não são f ixadas pelo prol £Ocole sip*

De acordo com uma: outra partícularidade, um campo Chamada_ ID do protocolo SIP ê utilizado pare e étapa de transmissão cie informações adicionais além do protocolo Slíb pe acordo com uma outra par ticularidade, alo modificadas as condições de consumo/uso do conteúdo muitimédia transmitido quando da di.tã étapa: de transmiasio , Por uma aplicação mult imédia consumidora do conteúdo muitimédia, sobre a recepção a a tomada em consideração das informações adicionais veiculadas através do protocolo SIP,

Da acordo com uma ou fera particuiafidaâe,: são modificadas as condições da: consumo/e#o dd fluxo da transmissão ésbibilécid© entra os dois terminais de comunicação, por aplicações muitimédia consumidoras e emissoras do conteúdo muitimédia de cada terminal sobre a emiBaãoç a recepção a a tomada em consideração das informações adicionais veiculadas através do protocolo SIP,

Sata tomada em consideração pode ser piarult.tcada de acordo com um: protocolo partilhado, previamente, pelas duas aplicações muitimédia, 9 - 41

De acordo com uma Outra particularidade, o processo compreende uma étapa de avaliação de uma banda circulante, disponivel para peio menós um. dos canais de trocas identificadas, fora da ssssâo*

De acordo cosi uma outra particularidade:, o processo compreende uma etapa de renegociação em tempo real da entrega de um serviço multimádia guando as condições de aso são modificadas atxavés da emissão de informações adicionais via. a rede S1P sub-jseente, compreendendo a êtapa de renegociação, uma detecção pelo segundo terminai desta modificação das condições de uso, em função: - da evolução do ambiente de radas de transporta disponíveis para o segundo terminal (por exemplo detecção de urna rede ¥XFX ou de redes á®. conectividade locai e/ou infiltrante); ~ condições de localização geográfica do segundo terminal (com base em informações do tipo geolocãlisação õPS ou célula de ligação de uma rede motel ou rede de ligação (roaxaing/ if ineranela!? ~ condições de funcionamento doí segundo terminal ele^prôprid, por exemplo na sequência da modificação do ambiente radio, da energia disponível (bateria.!, da disponibilidade dos processadores internos do segundo terminai (especiaImante guando este ultimo é um terminai móvel em função do numere de tarefas em curso de execução no seio do dito terminal; * condições de uso e de consume do serviço, por exemplo pagamento por tranche dé duração, segundo p horário de ligação, pagamento em função da resolução afixada e do rendimento das cores, serviço degradado conforme a posição geoaráfíca, serviço necessitando de numeração suplementar ou uma autenticação suplementar porque o segundo terminai acaba de ser locaiirado numa 2ona não segura.

Segundo uma outra particularidade, a étapa de renegociação é realirada para modificar as condições de entrega do serviço multimédia na peguênciã de uma aoçlo especifica do utilizador. É assim permitido ao utilizador diminuir temporariamente um consumo de banda em movimento, fcransformando em. ícone um fluxo continuo de TV/Video. Dito de outro modo, quando as condições de uso são modificadas,: por euempfoy m nivel do segundo terminai, a étapa de renegociação permite modificar o tamanho de uma janela, vi de o visivei no ecrã.

Segundo um outra particularidade, o processo compreende uma étapa de memorização numa raemória de cada um dos dois terminais de uma lista dos canais de troca identifiçados e podendo ser utilizados: fora de sessão para transmitir informações multimádia«

Segundo um outra oa r t icu.i a r .1 cia oe, o protocolo de sinala raçao e d protocolo Sip e a étapa de transmissão de informações a d i c i ona i & além. do dx to protocolo compr e end.e: * uma étapa de escrita, poio primeiro terminar, dé um pedido rmra formato texto; 11 - 41 - uma étapa de codificação 4o pedido; uma etapa de envio de uma mensagem. IISiVITS passando pelo pedido codificado no campo Chamada_ID,

Segundo uma outra parf i cuia rida de, a étapa de transm.issão de informações adicionais além do dito protocolo compreende também;

Uma etapa de envio de uma mensagem de resposta contendo: ama indicação cie indisponíbil idade temporária e na cru ai ê posicionada uma resposta ao pedido,, pelo segundo terminal, num campo paramente descritivo ou explicativo? - uma étapa de confirmação de fecho de uma sessão SIP, na qual o primeiro terminai envia ao segundo terminal uma mensagem de execução àCK com o. mesmo campo Ghamada-ID para indicar uma boa recepção da resposta fdefí.n.itíva} ao pedido·.

Secundo uma outra particularidade, o dito campo paramente descritivo ou explicativo é o campo «Razão» (servindo habituaimente para o motivo de recusa ou da aceitação de um pedido).

Um objectivo suplementar é propor num terminai de comunicação em rede, uma aplicação permitindo novas ut.ill rações do protocolo de sinalização aproveitando ao máximo potencialidades da infraestrutura de rede suportando este tipo de pro t o eo1 o:..

Para este efeito, a invenção dir respeito a um programa de um módulo de tratamento directaimeufce carregãvel na memória de um terminal de comunicação com uma rede, para comandar etapas; do processo, de acordo com a presente invenção assim que o dito programa é executado no terminai- k, invenção, com as: suas caracteristicas e vantagens, sobressairá ruais claramente peia leitura da descrição feita em referência aos desenhos anexos dados a titulo de exemplos, não limitativos, nos quais: - a fig 1 representa um logigrama das etapas dó processo rmm modo de realização da invenção? - a fig 2 mostra um exemplo de estabelecimento da trocas de sinalização próprias das aplicações dos terminais, sem interferência com as redes S1P sab~jacentes; ~ a fig 3 ilustra um primeiro cenário de chamada que pode ser detectada pela utilização de um ..indicador cie um sistema, de acordo com a presente invenção? a fig 4 ilustra um segundo cenário de chamada que pode ser detectada peia utilização de um indicador de um sistema, de acordo com a presente invenção; a fig 5 representa, esquematicamente, um contexto S?I Subsistema Muitimêd.ia { Sói), no qual uma rede de operador de fãdíoteiefonia ê dotado de um sistema de vigilância e gestão dos pedidos SIF, de acordo com um modo de realização da presente invenção 13 - 41 DESCRIÇÃO Dí )S MODOS INVENÇÃO 0 processo, de aco' métodos de troca utilizando especif protocolo f ie sxnal ;.asaes do protocoie Si.?- ou outro àçâo f mas sem. jamais trazer espera ao funcionamento intrineeco do protocolo de sinalízaçao de modo a poder beneficiar de uma infraestrufcura da rede ao nível mundial. No exemplo da £ig 2, trocas de sinalização próprias das aplicações utilizadas devem ser estabelecidas entre as aplicações (A, Μ, M) dos terminais (HX? T2, 14) .Podem ser trocadas informações de sinalização, entre estas aplicações (Ãl, 113:, M) sem interferir com as redes SIP sub-jacentes. 0 processo prevê identificar uma pluralidade de possibilidades de troca de informação num cenário simples de comunicação e a titulo de exemplo nao limitativo: © uso de INVIfõ, resposta e ACK β BYE.

Um método INYllÉ indica que a aplicação (ou o utilizador) correspondente ao endereço URL, SIP especifícado é convidado a participar numa sessão ( o corpo da mensagem descrevendo esta sessão, por exemplo: media suportada pelo apelante); em caso de resposta favorávelo convidada deve especificar os media que suporta. Existe igualmente © método RE-IWITB, O formato das mensagens SIP permanece inalterado. Lembra-se aqui que uma mensagem SIP pode ser, por um lado, um pedido de 14 ~ 41 ura cliente (terminal apelante) em direcçâo a um servidor (terminal de chamada) cm úma resposta de um servidor em direcçâo a um cliente,: Ã titulo de exemplo* um pedido SIP de um. cliente em direcçâo a um servidor pode representar-se como se segue:

Cabeçalho geral; ou de pedido ou de identidade

Li.nha de cedido (Método,· Pedido URI, versão BIP) CR1F (permite especificar o fim do campo de cabeçalhos e o principio do corpo da mensagem)

Corpo da mensagem

Um pedido SIP de um servidor para um cliente pode: representar -~se como se seguet

Linha de estado (versão SIP, código de estado, Razão-frases) ·.·<<« .VXWW.»W.W^ ,WWV^.M~^VWVW,WW,^»'W^W.VVV'VWW*WW>VM\W.W^W'M·

Cabeçalho geral, ou de resposta ou de entidade CRLF (permite: especificar o fim do campo de cabeçalhos a o principio do corpo da mensagem )

Corpo da mensagem do caso dos pedidos, um corpo (da mensagem) é acrescentado, ou não, segundo o método utilizado, da se tratar, por exemplo, de um método XHVXTE, o corpo da mensagem do pedido IM¥ITE contém informações· Indicando a progressão do pedido, Ho caso das respostas, o corpo da mensagem ê obrigatório. Assim a resposta a um pedido IHV1TS contém no corpo da mensagem uma descrição da sessão» O abonado que utiliza, mia o seu terminal (TI), uma infraestutura SIP está, normalmente, ligado a esta, Passou fases de: autenticação e registou-se junto do seu servidor (3) proxv SIF. 0 abonado gne queira estabelecer um serviço: utilizando os princípios do processo, de acordo com a presente invenção, vai lançar uma aplicação (Ά1) apelidada cliente do 16-41 seu terminal (Ti) que vai numa primeira fase passar no seanner Õ5 3 p O t'. θ λ"1ο íalidades dê i infraeetrutu ta SIP útil irada .Para assim proceder, o cliente embarcado c lo abonado vai emitir um conjunto de pedidos em dírecçâo ao servidor (3) de entrega do serviç o ou de um. outro abonado (terminal T2) sí s o serviço requerido for do tipo posto a posto «Peer a Peer» (P2P), 0 protocolo SIP assenta no envio dé pedidos no formato texto, Um pedido utliixa um método definido no RFC do protocolo tal como X&TOE, OPÇÕES, AQRf , BYE, REGISTO, CAMCELAR ou MERSAGEM (definida na extensão da RFC).. Cada pedido contém cabeçalhos (garalmenfce p .dezena,: mas o numero é extensível) e, eventualmente:, um corpo de mensagem, 0 anexo 1 fornece um exerspdo s áe pedidos SIP esta.belecendo uma cham; ads telefónica. 0 proces sso descrito no anexo 1 refere à sucessão de chamadas ilustradas n<: i. fig 3 , t precise obse rvar que neste t uia uiiSXiaausx * χχ·α/ eompo r i axsen t o da infra a a s t r u t u r a SI?, >or tanto, um ef eito no :olhídoa | mio t .erminai aestrutur; a SIP até ao sp©& têm muítc í pouca Ϋ-' p -p f'*·· ss XV, Vis \w àlments àicionai au v erminai inatár xo / rp Çt λ Pum „stos, para a ex ecuçâo f a c i i. x da de prevista ΐ 7 ΐ 7 pela norma * Par \Λ .*·. θ' Ο Of o t erra. iria agent :e de tí ratamenfco dispondo de estes camp:< as > Compreende ”S e igua Ι,ί rente qu« i desti .natâr; lo ; p ode u tilisar o oa para emi t i y uma infoj sanação, além prime 5iro t er :min; al (Ti .) . & rec ep< segundo terminal (T2) o campo Call^XP, informado com o valor emitido pelo primeiro terminai (TI)* fornece uma informação sobre o facto que o dado veiculado no campo eCáll-ID» foi devidamente tomado em conta pelo segundo terminai (T2) > De modo paralelo, o primeiro terminal (TI) pode reenviar uma emecuçáo ACK em direcção ao segundo terminal (T2} para lhe significar através do TAG associado ao campo «de» que a sua resposta foi. devidamente tomada em consideração.

Em referência a fi.g 2.# a rede (d) SiF inclui um primeiro domínio {15} de prot ocolc > PI (Int eruet Protocol) permitindo utilirar uma topologi .a de opções d* e encaminhamento { traços era pont i lhado } é um s >egua< .lo dorclnic i correspondente ; a uma rede de radioteXefonia ( ή /' ·< X C* ) > Om dom( Lnio de tipo mi: (Rede Tel efónii ca Cc mutáda) pode iguaiment e fazer parte dã i rede }N) c<t-d v· > Hum modo de í Γ& ci X X X Xi. Ç-X o prr íferencial , a rede ÍN) $ip ilustrada na f i q 2 Ut.l 1: iza uma arq: .si.tect.ura de serviço com um sub™ -sistema IMS (IP Mui. ti média Subsistema;!,, í zoe permite deslocar 18 -- 41 urna tecnologia da voz sobre PI. Apesar da rede (d) SIP ser representada como incluindo uma rede de r a d .1 o t. e X e £ o n i a (16) dotaria de estações e uma parte com ligação de rios, compreende-se que .não importa qual a ligação sem fios que pode ser utilizada; na rede (W), podendo este último mesmo utilizar unicamente ligações sem fio (radio, difi, díman, Slusfcooth &, etc.).

Po eu amplo da fig 2, o domínio PI (15) dispõe de uma pluralidade de elementos de rede, especialmente uma passagem intermédia (2), media (entrada média), um servidor (3) proxy assim como os primeiro e segundo terminais de utilizador (TI, T2)<. Cada terminal (ΤΙ, T2) pode utilizar uma porção da topologia das: opções de encamindamento quando do estabelecimento de uma comunicação com. um terminal de radiocomunicação (4), por exemplo celular, ligado via a rede de raáiotelefouía (1>S) ,deste caso são utilizados o servidor (3) proxy e a passagem, intermédia (2) . OS primeiro e segundo terminais podem assim comunicar entre eles por utilização do servidor (3) proxy SIP, sem utilização da passagem intermédia (2) neste caso.

Em. referência à fig: 1, o processo prevê utilizar um canal de troca de dados, acessível ria o protocolo de sinalização, para difundir, de extremo a extremo, outras informações além das necessárias à gestão de sessões muitMédia * 0 processo controla o estabelecimento de canais de trocas para permitir a transmissão de informações muitimédia entre terminais de comunicação (ΤΙ, T2, 4} ligados entre si pela rede Cl) da telecoMurd.eaçÇes.

Hm referência às flg 1 a 2f uma étapa {51} de estabelecimento de uma comunicação entre um primeiro terminal de comunicação (Tl) e um segundo terminal de comunicação (T2) é realizada por utilização de aplicações respeetivas (Aif A2) gerando o pro tr O colo de sinaliz ação. 0 prit xei . ro t minai (21 } e f eotv ia urna éta pa (500) d< s pesquisa de cx ys -;p is de trocas e ntri s os doía ·£·. Λ y mi: nais (Tl, T2) , Esta < Ita pa (5 00) . de pesquisa de /*> rs V\ rj vw.iit! :is de tro ca pode assim perrn —.v ·> -X laixu ra r o invent .ário das pos sx bilidades de t roçar ir ifor ma çOes a .p 1 X Octll Λ. ox sf podei Eido o can al de troca ser assim es·: lolt d dO | 301 : ocasião de uma éOXllpX uit lor (52) de si '£ X0:ÇÇã.Q v Dm* i êtap: 3 (50) de identificação pel o primeiro teravii ial (T 1} de P elo me. nos um cu :s na .1 eis troca e ser real: Irada pelo pr: Lmei y í terminal (fl), poi : exc -mplo, apo & OròC.idL .c.&c epção de u ma me ns agem. c ie respos ta a ux r> dos ped idos emitidos qua: ndo d.a èt: apa ( 500} dí s pesquis® t. <

Quando da comunicação, o processo pode com portar: ~ uma èt apa {13} de emissão de um ou vários pedi cios pxtm .eii :o terminal (T11r com * lestino ao segundo ter (221 abrindo uma sessão de acordo com o prot ocol sinal1ração determinado; - uma etapa {54} de envio pelo segundo terminal C?2) de uma resposta encerrar a representatxva de acoi de uma índi sponibi1idade pa ra coxa o protocolo de sinalização determinado. mm modo de realização da presente invenção, o processo compreende uma étapa (55) de transmissão de informações multimédiâ por utilização do dito canal de troca seleccionad©. C omp r e en de-se que a utilização deste canal de troca não corresponda absolutamente à via utilirada quando de uma sessão clássica, no qual o inicio da transferência de ama informação multimédiâ é efectuada utilizando o corpo da mensagem do pedido SIP.Com vantagem, a étapa (55) de transmissão de informaçoêd adicionais via este canal efemina-se quando as ditas étapas (53, 54) de emissão e de envio, além do dito protocolo de sinalização. iata étapa (55) de transmissão é realizada por exemplo apõs ã étapa (52) de selecçâo do canal de troca. Estas duas étapas (52, 55) são por exemplo, cada uma delas despoietadas a um nivel aplicativo·. A étapa (500) de pesquisa de canais de trocas pode compreender uma étapa (5x0) de envio pelo segundo terminai (T2) de um. conjunto de mensagens de resposta aos pedidos do primeiro terminal (2!)*lato permite identificar e elaborar o relatório, ao nivel de cada uma das aplicações {Pãf AZ) t m canais paralelos disponíveis. Vários métodos subjacentes ao princxpro de utxlzração 21 - 41 decorrente de canais de comunicação vão, a seguir, ser descritos. Apesar dos exemplos descritos se focalizarem sobre o protocolo SAP, deve ser compreendido que isso pode set estendido a outros protocolos de sinalização {SXP, K323,MCCP, Mega.eo). Método dos campos não definidos A técnica proposta repousa no facto da troca dos dados de nível aplicativo além da sinalização utilizando astucíosamente as facilidades de codificação propostas pelo protocolo SIP. Focaliza-se em quatro métodos utilizáveis simplesmente para as trocas, combinando~as ma is ou menos: pode—as generalizar todos os casos de: uso, Deve ser compreendido que o processo de controlo não é restritivo a estes quatro métodos visto que a presente solução recai, mais geraimente, sobre o facto da utilizar o transporta de sinalização sempre presente, qualquer que seja o consumo de fluxo continuo em curso (cf o descritivo das trocas entre Sob e Alice noa anexos 1 e 2).Podem ser citados os qnacrc métodos seguintes:; - Cabeçalhos dos pacotes Sip {carácteristicas das sessões); ~ Descritivo do câdígo de resposta {req 200 0K;) ? ~ Cali ID {<Cseq>}; ~ TAG {ou RAMO)<

Assim ma- multítnde de cabeçalhos num protocolo (SIF ou outro) e podendo ser incluídos nas mensagens para precisar um pouco mais de caracierlstícas da sessão são susceptiveís de fazer ti - 41 transitar da informação na sinalização. Do mesmo modo, uma resposta a um pedido num protocolo dado, constituído por um código a uma desoriçlo do: código fpor exemplo para :SXB>2dO ON, 301 Removido Parmanentemsnte, 404 Nâo encontirado. . .) permite fazer transitar informaçlo na sinalização: resposta: 200 Bom dia Pór

Método incluído no seio dos métodos MENSAGEM A aplicação (Ai) do terminal (Ti) constrói um pedido transportado no método MENSAGEM do protocolo SIP, cujo formato èf previ amante, estabelecido com o serva dor / de st. ina t â r i o ao qual ele deseja aoçdsr/cormrniçar, O agente embarcado testa, então,· se é possível comunicar com o servidor (3) informações descritivas. $e a rede (N) SIP encaminha os métodos MENSAGEM, então ê: o meio mais simples de transportar e estabelecer uma troca de dados entre aplicações (Al, A2) entre dois

utilisadores flob o Alicéj, D ónico inconveniente dos métodos MENSAGEM é a facturaçao possível desta, no caso em que a rede sob-jacente põe em execução serviços de ménsagébA ínstimtaneàsç ora, na nossa ;prob:I:emáf:ío:ã, a rehegodíaçid das condições bé qualidade; da entrega de um: contendo mnltimêdia não deve ser facturâvel para um acto de sinalização, dum; modo de realização da presente; invenção, o processo dé: controlo do estabeleoimento de canais de comunicação permite trocãr informações de sinalização para modificar, em tempo real, a natureza das informações trocadas, portanto, da 23 - 41 sinalização:-: poda ser prejudicial dever utilizar em -canal submetido ã fact-uraÇâo para estabelecer e trocar a sinalização relativa a um serviço em curso de entrega.

Método apoiando~se no uso do paylaad (carga útil de SXP) SDP O protocolo SDP (Sessão Descrição de Protocolo} é descrito no RFC 2327 (2} ei è ufcíl irado para descrever sessões mui ti encaminhamento nos anúncios ou nos convites de sessões. Estas descrições não congelam., forçosamente, a estrutura e a sintaxe de todos os campos e em particular campos: opcionais, Entre estes campos facultativos,, alguns não são s íntatiçamsn te descritos e, portanto, utilizáveis seguindo a boa aceitação dos serviços: desenvolvidos« Este facto é habílidosamente descrito no anexo 4, A titulo de exemple não limitativo,, a carga útil de SXP ou payioad SDP contida nas mensagens XdVllE e alguns 200 e ACR pode ser utilizada para transferir dados, mesmo se nenhuma sessão foi estabelecida, Q campo s™ da páyloãd SDP é, per exemplo, um nome descritivo da sessão δ pede ser utilizado para transmitir dados de modo paralelo:. Aplicação ao método Call X.D na mensagexs XRVIIS h ausência d© formato destes campos permite ao agente/elienie CAI} gerar os seus próprios dados e de lhes juntar um dado único permitindo a garantia da unicidade dc campo na sua globalidade, E, portanto, fácil de imaginar no seio do campo Call-XD, o funcionamento de uma estrutura do tipo: < id. uni ca > < c om a ri do / ped i d o > < d ado a a s s o c i a d o s >

Sste identificante id-único pode sor composto por uma informaçio de identif icaçâo do abonado ou agente e de uma variável. de valor único toto MSlSP;N^sf>.fr-cMo único (tempo) , como por exemplo:

tt}t»J)[email protected] \ 81U 0J2h3047GMT

Um exemplo interessante é o seguintes guando da. difusão de em conteúdo em fluxo continuo(prev lamenta estabelecido), o cliente ÍA2) do terminal (T2) recebendo o fluxo continuo, deseja informar o servidor (3); ou o emissor (Ti) da necessidade de baixar temporariamente a qualidade do fluxo por rardes de disponibilidade da unidade de tratamento CPU ao nivel do cliente (Â2) o pedido: modificação da qualidade de vídeo com o valor de 7 para 5 minutes,: pode ser codificada entre 1& para o campo descritivo da acção e PP para o campo: descritivo dos parâmetros Âãv?ideoAAFF7'__.5PP,

Para transferir informações em direcçãò ao servidor (3) Ou o cliente (A2)do abonado distante, pode-se prever que o campo dali ID vai escrever-se ΐοία^33603Ι3ΐ30202@δίτ.Ι>- 197.1110.10.....12h304?GMTÂAvídeoAAPP7@PP. O anexo 2 ilustra então o formato do pedido emitido pela aplicação (Al)do primeiro terminal (Til, Q correspondente pode então reenviar as suas respostas ou parâmetros através d.o campo Descritivo do código de resposta recopiando o Cail 1D> A mensagem «pedido de vídeo 7 5 em tratamento* pode, portanto, ser recebida pelo prirteíro exemplo pode set terminal (TI). Este exemplo pode set tornado mals complexo integrando-Ihie noções de atrasos horários ou programação de pratos em termo da trama FT.R ou sequências de imagens. 0 protocolo é realizado sob a forma quéstJ.o/resposta ou comando/resposta.Ã estrutura seguinte <id única><comando/pedido><dados associados> permite oferecer a qualquer camada aplicativa um suporte {suporte) de transporte, é assim muito simples reconstruir um módulo de transferência de ficheiro funcionando por um uso dos canais Calí 1D a descri ti vo: do código de resposta através das mensagens IHVXTE. Ê preciso assim observar que, se a conta de INVITE for negai :ív f nenhuma ses; são será estabelecida. nive.'. í do servi dor { 3) ΕΓΡ. 0 módulo de ficheir o pode, j portanl :o, emitir uma mensag nivel Ca 11 - XD o segu: Lnt θ t toto@MS mce) £s rr.net> <mod i f i c ar vide·:: ·>>< quer O- izer modificar a pedido gualidado seleccicnando o nivel 7,: para uma duração- de 5 minutos, Em exemplo de resposta do: servidor esta ilustrado no :flm do anexo 0 servidor i 3) pode, assim, espontaneamente, pedi r a um utilizador aetívar os meios de segurança ma is e .1 evac Los se o cliente s® encontrar num ambien te pouco seguro n o me: Lo de um pedido INVI TE, no presente exemp lo, Qoserva-sé que o çampo PE pode também ser util. izadc • para 2.6 ~ 41 dialogar direetamente com um servidor de serviço, visto que •está disponível para não importa qual valor de pseudónimo. Este campo não saúdo constrangido no seu conteúdo, pode ser carregado com não importa qual estrutura, convindo, autoriormente, respeitar as obrigações da estrutura da norma.

Dm outro interesse do campo DS é que, de maneira geral, o conteúdo deste campo será afixado na recepção pelo terminal? é, assim, permitido: construir ofertas de serviços { com. Interaotividade) pedindo acçõe« do utilizador no mcmento da recepção do pedido de tratamento emitido, quer esse pedido seja relativo ou não à renegociação da qualidade de serviço do contéádo muliimèdia em curso de difusão. £m referência ao anexo 3, dois outros campos são também interessantes: no quadro de uma utiXi cação paralela da sinalização SIP de acordo com a invenção dos campos do protocolo de sinalização: «campo de avisoo e ratão «campo». A leitura do descritivo da RFC permite ver que estes campos são do tipo texto e são obrigatórios quando dos revés, ou dos alertas, acontecimento particuiarmente pesquisado para nâo estabelecer sessão de troca de dados entre os interlocutores RIR {Rrotocolo de lampo Real).

Dm dos meios mais habilidosos é estabelecer uma convenção de formato ao uivei aplicativo para o conjunto dos campos da norma deixados livres para fornecer uma explicação textual Uiumanamente legível: "a frase-razão deveria ser legível humanamente”) . A informação e assim veiculada de ponta a ραπ ta pela infraestrutura SXP será qualquer outra modificação aó nível dos servidores, entrada € proxy (2, 3) atravessados.

Esta informação encontre-se nas respostas sip e aos métodos. Ê preciso também sublinhar que pode ser evitado de emitir pedidos conduzindo a revés, para .não despolet.ar o estabelecimento de um canal dado: um novo canal de dados pode, com. efeito, ser vsatajosamente estabelecido e utilizado entre dois terminais (Tl, 12} ou mesmo ma is de dois terminais (TI, T2f 4), A forma de realização da fíg 5 mostra a infraestrutura de dois operadores de radioteieionia diferentes com uma comunicação entre estas redes via servidores (31, 32} FCSC (Função de

Controlo de Sessão Ca.ll), dotados, por ememplo de base de dados SBD (Servidor de Subscritor Doméstico} para recuperar os dados de abonados * Passagens intermédias ( 21, 21*;} s comutadores (22, 22f) previstos em cada uma destas redes de radiotelefonia (16, 16'} permitem, encaminhar mensagens até aos terminais móveis de radlOdomunícação (ΤΙ, T2>. m protocolo PTC (Protocolo de Túneis CPRS } permite comunicar entre uma passagem intermédia (21, 21/} do tipo MSP (Md de Suporte da Passagem GPRS} a um comutador (22, 22' ) do tipo MSB ( Mô de

Suporte de Servidor GPRS) „ Pode ser colocado ura cor ta™ fogo íM) ,· no interface entre peio menos uma das redes (16) de radiotelefonia e no: domínio (15) de tipo Internet, A arquitectura IMS: tal como ilustrada na tig 5 permite aceder a serviços multímÉdiaf pelos terminais móveis ou fixo-s, utilizando o protocolo SI? no PI. 0 sub-sistema SM é organizado em três camadas que são: - a camada de transporte que designa o melo de acesso ao SM; R$P para os telefones xadveis* DSLAM para o ADSLf etc»; ~ o controlador de sessão {Cal1/Punção de Controlo de Sessão ou CFCS); compreendendo esta camada* especlalmente, os servidores seguintes; ~ Promp-CPCS que desempenha o papel de proxy SIFt todas as mensagens de sinalização passam por ele; ele estabelece um túnel IPSeo entre o MSP e ele próprio; - o Servidor CFSC que permite administrar o domínio; desem-penha o papel de Registador 3ΓΡ e permite estabelecer uma política de sinalização; assegura também as funções de sneaminhamsnios (todas as mensagens passam· também por o Inquiridor CFCS é o ponto de entrada de um domínio; é por ele que passam os pacotes SIF provenientes de um outro domínio; o seu endereço ê publicado no sistema SMD (Sistema de Mome de Domínio)? -- os servidores da aplicação que ©mecutam os serviços, Ά figura 3 permite lembrar o desenrolar convencional de um cenário de chamada com um protocolo de sinalização. OS cenários simples de comunicação utilizam pedidos SIP tais 41 comoί IN;V'ITE,: &CK, BY!> Dm terminal cliente SIP (TI) chama um outro terminal £12} utilizando a mensagem INVITS, .¾ mensagem enviada contém, informações permitindo estabelecer os fluxos media em direçção ao terminal cliente (11} gue esta a onamár, 0 exemplo a seguir ilustra uma mensagem de convite de acordo com o protocolo SIP: IMVXTS síp dMstÍM(§t1oiSáiíiíeiíSIP/2,0

Via: S.IP/2.. 0/UDP (o rue u ande reço prív ad orpo rt}; ramo: ::: {ramo} Max_ forward: '70 De: PChristianH <si.p: {chris tianidoma in e< fr ! >; Para : {PauX}<síp: {paul §domai ne,fr}> Ca 11 ~ID:(29663245 58-ed :C“6548 "fg8g9} Cseq : {1} BÍVI1E Expi ração: 1800 ConO s u d o - Come r íme nto:: 1 187} Om s er v i dor 3fTP> por exa melo o set vidot (3) P roxy do domi nio «domin io, f r », responde a um pedis io SIP p; -v ·/· mei o de uxm i ou várias tesp -ostas, A mal orla das r espostas, r' :ujos códigos sao da foma 2xx* 3xxf 4xx, 5>:x e Sxx são respostas finais e terminam a fcransacçáo corrente, ns respostas da forma Ijíx são respostas provisórias, Um exemplo de resposta é fornecido a .seguir: S1P/2,0 100 Tentativa

Via:; SIP/2,0/0DP {o meu endereço privado;popt }.? xamo::;

Iramo} 30 - 41 'Deí {"Chrlsfcian"Ksip: {chrlstiangdomaine, fr} } >;

Pará: {Páu1o} < s i p:(pá u1§doma xne«t r >>

Ca 11-1D; {296632455$~edo~BMB~tqBqS·}

Cseq:{1}INVI?E No exemplo dá fig 3: o código do r espoe ta «100» significa «tentativa» em curso de tratamento ίο código de resposta «180» significa «Topes» campainha em: corso; - o código de resposta «200» significa «OK»<

Para compreender a noção de trana&eçôes e de retransmissão de mensagens., é preciso aqui lembrar. gue um diálogo STP é identificado pela combinação dos campos «De», «Para», Call-IP do nómetí a de sequência *. rCseq» abeleeido,: todos os pedidos e as ea campos hg cabe çaiho. Cada trauá. valor comam do cabeçalho «Cseq» {o nome do método e o numero de sequência devem ser idênticos} , 0 sistema, de acorde com. a p.res^ ante ínven çã 0 od e perra. iti tipo de pedi do s e mi ti . dO f c· compc irar t.r an áâcç õe s 0fS £{ a e ΗίΓι τ eferí §nC.Í-3 1 ! fl g 4 , pe did mm nem podem ser λ-·. bêm < sair étapx i (55 ). da t.r ansm xs s á o ce ir·. 31 - 41 de utilizar os pedidos SUSCRSVER e EOTlEICMí permite difundir, de ponta a ponta, outras informações além das necessárias à gestão de sessões multimédia. Estes dois pedidos genéricos podem ser encaminhado© pelos servidores (3) proxy com a ajuda dos cabeçalhos <xDe» e «Para» e são entregues por respostas. 0 pedido SUBSCREVER é enviado pelo terminal cliente (TI) que deseja receber certos acontecimentos m direççáo a m servidor (3) que gera os acontecimentos (por exemplo; um pedido de informações, de presença para uma aplicação do tipo lista de amigos «feudy list») > 0 pedido SUBSCREVER contém no cabeçalho «Expiração» que indica a duração da subscrição. 0 pedido UOTIFICAR serve para enviar notificações de acontecimentos. Estes pedidos SUBSCREVER e EOTIBICAE podem, criar um diálogo STF, nio têm: necessidade do pedido INVITE e podem ser enviados de maneira assíncrona, nâo Importa em que momento. È assim muito simples tealixar sob a infraestrutura SIP um sistema de comunicação na base questâo/resposta. Com o exemplo dó campo cãli-TD, se um primeiro terminai (TI} çper, por exemplo emitir em direeçâo a um segundo terminal (12} um pedido elementar para interrogar uma base de dados, então: - o primeiro terminal (11} escreve o seu pedido elementar no formato texto; - codifica de seguida o seu pedido ha foase-u4; depois ~ envia uma mensagem IHVXtE ao segundo terminal ;T2) passando o pedido codificado no C.all.~XD, 32 - 41 O segundo terminal (:12} responde com o código 480 ítemporáríamentè indisponival e posiciona no campo tacão-código a resposta do: pedido a uma tosse de dados. 0 primeiro terminal (TI) reenvia, então, uma execução ACK com o mesíao Cãll-ID para confirmar 0 fecho da sessão SIF e a boa recepção <io resultado ao pedido. A inf raestrutura SIS vai considerar que a chamada nunca foi realirada e que a sessão terminou, mas um. cedido terá sido tratado através da infrsestrutura SXP.

Compreende-se que 6 fácil tornar complexo o proto colo para embarcar ao: nível dos campos tais como Cal.l- ID, um st icessão de pedidos. A pessoa cor rhecedora de estado da técnica apreciará que e suficiente e s t a beXecer uma convenção .] para ider itificar o primei ro pacote·,. iden tificar o pacote de o; rde.m h e o último pacote { ver SXP IMv ITE definição; RFC 253 13 e RFC 3231} , 0 exemplo da :figurá t 3 permite mostrar a síxr·] plícidade relativa do cenário de comunicação, por uso de IHVITE/ACK e BYE.

Pum modo de reaiiraçâo da presente invenção, ó processo prevê escutinar/varrsr os canais abertos. A maior parte dos exemplos precedentemente citados utilizam simplesmente o campo Call-ID para veicular os pedidos e isso de forma bidxfeocional graça.s ao poderio do protocolo SIP. Mas certas inf raestritiuras SIP não encaminham a informação de Call-ID de ponta a pcnta, exu particular se um servidor (3) proxy SIP pdesorçve estes dados. Isso é possível ao nivel do protocolo SIP visto que o único constrangimento é que a informação constituida de TO, 33 ~ 41 «de» e Call-1D deve identificar uma ligação para prescrutar, única. 0 uso do campo «De» como aetivador de troca pode então ser necessário. No caso em que os campos «de» se encontrassem também retidos pelo servidor (3) proxy SIP do facto das limitações das suas capacidades, podem ser; visados esquemas apoiando-se no uso do campo TO.

No quadro do uso do campo DE, o pedido é codificado neste e o esquema revelado com o Csli-IO fica idêntico (cf anexos 1~2). No quadro do campo TQ, o terminal raceptor {? t) utilizado por Bote faz um pedido para © terminal (TI) da Alice xsas orientando um pseudónímp (pseudo) especifico de Alice pedindo-lhe para chamar, para permitir passar o pedido.. Alice chame, então, e por sua vez, o terminai (T2) de Sob transporta o seu pedido num dos campos contextuais oferecidos: a resposta retornará ao mirei da execução ACK, ou se este método não estiver disponível na rede, pode ser conveniente ão nível da rejeição do pedido: que, por meio de um ídentif icante de pedido, Bob chama Alice a fim, da lhe transmitir o seu ídentif icante de pedido e que este lhe responda no momento da rejeição, Vários xaétcdos são, portanto, possíveis para tirar habiiidosamente partido da potência do protocolo SIP, mas é necessário convir qual destes métodos se deseja utilizar a, em particular, detectar qual· pode ser usado nuxaa rede (N) SIP e isso de forma automática. 0 principio do: funcionamento do sçan |escrutínio) repousa na utilização de um conjunto de métodos, do forma sequencial, atê que se detecta um método operacional sobre esta infraesfcrufcura.

Quando da fase da descoberta dos canais paralelos disponíveis, o agente/o cliente embarcado emite um pedido IMVXTE em direeçá© ao destinatário informando os campos disponíveis sucessívamente e pode assim, estabelecer uma cartografia dos meios de comunicação paralela disponível para atingir o correspondente, for extensão, o agente podo estabelecer uxna cartografia dos meios de comunicações paralelas disponíveis para atingir H correspondentes ou servidores, podendo,por extensão das noções de grupos de destinatários, também ser sempre gerados em relação aos meios de comunicação paralelos cario g r a f a d o s:. & descrição dos testes necessários â descoberta dos meios de comunicações paralelas pede ser précodifiçada sequencialmente, Uma gramática pode descrever a lista dos campos do protocolo de sinalização que a aplicação (dl, i\2) ou agente poderia utilizar e avaliar. Orna vez a cartografia realizada, é visado avaliar a banda concorrida, disponível para cada um dos canais paralelos, por uma sucessão de testes recorrentes de dísponifed lids.de dos canais paralelos cartografados „ Várias opções são possíveis, mantendo-se o cliente (M, é2) no primeiro método operacional. Testa todos os métodos conhecidoe 35 ~ 41

e o| pe 1¾ \1<S SU< í e scolf ia ^otíi v* xase em critérios 51 Χΐ5ΐ atóríos, o r d; Lnai f ou ds zperr dend So da r i ature Z& Cicâ s inforxt fâÇÕS s que deseja tro< > Γ C-< ;>m 0 seu Irri cerlo cutor. 0 cli ente { •Ai, A2) Cí· v 1> X 2* CÍ vár: Los ml ?tO< áos em par *1 ώ ΐ ClvX-tU·isU f se s . infra ;eatruti ura ; STF autoriza vári Los d 8 S t 7BS .mé todc ss e pode dédío; ar/part . icui a r i i sar cada método a sur s-tipOS de servi ;p os bôxx ' prsci ,'-s :p <y! V y V

Constata-cse ei&ramente que os clientes (Ά1, A2) no quadro do : UtJ ..li ·;> ::v j-n /\ v í'í <'4 Ât Va\a's·' vX> W W f- ou O Si arvldor S) e o me ir ·χ·\ . V 1 caso se: ruir· am "•se previamente de r e de :ut ura â, as in forma coes que a fí .car in te li glvei ,s> A vante igem :ar cá infra trut ur Ú 31P de maneira 5X lii ma troes a < de < ÍS! dos mn.lt im édia via . liza r a irs.fi cae :Stru ΙΧΛ rra SIP e í .chega- -se, car a r 1 fi P !vt 1· í, O ^ ou cv crua 1.idade ou ta ssmo liqi ação de da r^rj -íp jâ estabelecida, a pa ra est abei aoer LliTicl outra.. S assim eduç 3λ; da qualid a de na entrega e 0 servi .do r, < ou os cli.es ites dos utilizadores, detectarem uma alteração da banda concorrida, disponível ao nível do seu controlo ( ..monitorização) cias transferèncias/trocaso Este tipo de 'modificação è hoje muito difícil de por em execução e necessita a maior parte do tempo de romper a .sessão estabelecida para reconstruir uma outra. Afixa de diminuir o consumo da banda concorrida, 0 terminal 36 - 41 (12) reoeptor. pode, por exemplo, formar Ícones, ou reduzir o tamanho da afixação do videc reduzindo para isso a banda concorrida necessária (portanto redução do fluxo continuo de Tv/Video, do exemplo dá figura S, è assim utilizada uma janela reduzida (I) para a visualização do conteúdo muit.i.mèdiá (imagens/video) recebido, Esta janela {!) temi um formato bem inferior ao do êcrã ÇE) do terminal (Τ2) reoeptor e o conteúdo poete ser visualizado com uma menor definição, o que permite ecônoxaixsr a banda concorrida. Â título de exemplo, o consumo da banda concorrida pode ser voluntariamente reduzida durante certas fases da difusão de uma banda anúncio, por exemplo no momento do genérico:. As condições de utilização em recepção do conteúdo muXtímèdla podem ser tomadas em. conta para ajustar automaticamente o consume da banda concorrida.

Uma das vantagens dá invenção é permitir uma ma tris de novos protocolos utilizados., especiaiemnte, na gestão dos serviços mu.lt imsdia tais como a vi sinfonia» a vos sobre o IP, troca da ficheiros», as mensagens, etc. Em particular, o processe de acordo com a presente: invenção pode permitir controlar o uso dos canais- paralelos nos protocolos de vos sobre o Px e de pôr em execução canais de comunicação era tempo real oferecendo a possibilidade aos utilizadores de modificar a qualidade do serviço consumido, o nlvei do serviço e o cipo do serviço por uma execução de uma sinalização suave, independente do suporte (portador) de «cesso, Além disso, pode-se prever, com vantagem 3? ··· 41 uma camada aplicativa de serviço# para oferecer ãs aplicações dos meios de eomunícações com os centros .servidoras,, indepcndentemente das políticas de filtragem e das capacidades funcionais dos servidores de sinaliração subjacentes, 0 processo de acordo com a presente invenção é aplicável a numerosos serviços# como por exemplo os serviços de reeneaminbamento de mensagens# os serviços de interaotivídade no çonsesô dos novos media (por exemplo· a televisão interactíva# ou as trocas do tipo Peer to Peer no seio das comunidades},. os serviços de negociação em tempo real da qualidade de serviço.

Deve ser evidente para as pessoas versadas no estado da técnica que a presente ixvvenção permite modos de reaiisação sob numerosas outras formas específicas# sem se afastar do domínio de aplicação da presente invenção conforme reivindicado. Por consequência# os presentes modos de realização: deve® ser considerados a titulo de ilustração# mas podem ser modificados no domxnío definido pelo alcance das reivindicações juntas e a invenção não deve ser limitada aos detaibes dados acima. iisjOOíw # jl 1 de Agosto de 2009 ψ ο 0 i

W m 4 ê co :¾ Ά 4 1 1 φ 0 0 é 'Λ' 0 4 § W &ι Λ .Λ* 0 * 0

Ν 0 N ϋ: Η # X i xp QP· •0' 0 0 0 0# g3 μ: ;ss ,...; gM 0 X T) Í1:0 Μ X 0 X Λ"Λ Λμλ Sí 0 d d· ^ :0 0 ri > Η X , V'*! 0 «λ 0 A 0 a i. o U X > : ί ο ο χ H sr é 0 :0 t 0 X 0 ί X: ♦ Φ 0 * I Λ X 0 0 X X s «ο s CO M οο f > m X X CO ® £ \ 0 0) H I ντϊ | a o « 1 I ri 0 4 0 - <3 0 & 0 1 ® -o OiOi Η 0 0 x· 0: >: d 0 Μ η o d v: 10 Η Η N Λ " & # 0: & •o m \ » 0 0 0 0> * Λ 0 Λ* 0 0 i: Ό X 0 ^ 1 f g 0 g Λ 0 :¾ :à 4 \%vv| 0: C A Â -H # (0 H * Á A 0 M 0 *00 0 # \ 0 a a 0 #00 g | 0 f % D w® ε e ® l \r· 0 » ϋ 0 0 0 0 0 0 0 a ê o 0 0 0 X 0 00 H 0 0 0 d CP ► Η <0 H 0 <d 0 n i 0 i S8 g H:«« g H 0 0 :0: 0 d 0 Η d » Wi, / μ Γ>> >> h μ: w& ‘ .* 0: 0 f vv 0 ' ' :♦ 0: H 0 " 0 ♦ 0 Μ ϊ í «) 0 0 0 Ϊ f 0: « s o x ϋ! o w ϋ 0 8 8 §0 d d Í ! 1 0 ® h # μ 0 X 08 0 0 V X 0 0 V ov( #! d! t? X O X ν 0 < ® 0 " 0 d # 0 0 ti 0 o: 1 i 0 :** 0 $ d 0 ffi i'} 0: ti. :0 d 0 Η 0 A 0 Φ 0 ti i < * 0 I 0: f ' < w 101 0 * 0 #0 # 0 0 ti o d ft g d 0 M y*-s V0·’ SSf !·ι m c 0 α g # X d d d d α d 0 0 10 0 li) C 0 0 ζΓ 0 0 è. S «ri 0 0 0 d 0 0 . D μ μ t S IP .ο oseac Φ « d úmw i 0:f 1) vv :0 e B 0 0 # - d dPiti f 1 » d 0 0 0 d M s'< a<·. 0) 0 flb i f Ji 0 m % MiaBs fea 0\ili S SIS 0 \ Ή 0 H d o«as o o h 0 ο ο α e 0000 dag IQ ϋ 0 H do o as .. 0 Γΐ Λ > 13 0 j 0 0 :00:00 0< 0* :0 1 0 ·β 0 -i .0 > " 0 i 0: 1 /·) v ri M IX 3 S ! -ri 0 Q, 5! ·· 2 3 v' d ti 0 03 0 ·♦ X d) ti !·! 0 0 É 0 >v 0 0 0 kM 0 0 :0 :0 >* $ 5 :» ÍSi Ή 0 »* OtH DOS i h § m 0 0 1 í 0 M 4 Η H 0 0 í: i ó% « S h: 0 0 1 1 <S\ 00 << 0 # 0 0 >> 0 x\ ^ ί' a a «9: iBf8;Í :*>. 0: 'A 0 r0# 0 0 0 0 )¾ H S-v >833 o Mh 0 v> X df f S 0.1 8 H 8 > I TI 8 I:H 0 # ri 3 > 8¾¾ U H 3} V μ c n Ό ^ A 00 V H c: i 0:d • a V 3 S M 0 0 0 0 0 V H d H d # h a v »- i 0 0 ti ti (\! fô ** » 1 i m # t 0 Ϊ- 00 00 1 1 i M » “: 1 X 'd 11 H >* (U 00 \ 0 .U d I i 0 i 0 0 0 0 v d i § 1 0 0 d· s* V O 00 i .0 d d > 0 « ti Φ H x -.-ί c s X 0 0 0 t 0 £ 0 k ti ti o: i X: 0 d c i 0 «: 0: # ri X 0: d d: z ή $ <u a«® a o 0 h > a au osduo h # d d «< S μ 0 0 H $ 8 8 í 8 8 0 0 a fi A ϋ 0 2 D ϋ U #0 d O 1 f 1:1 0 0 0 2 A t) ;* \ 1./ S a ϋ u 4;>;0 A O UÍD:U:U 39 - 41

Anexo 2

Para transferir informações em direcçâo ao servidor ou ao agente do abonado distante A chaaiada 10: T o t o__0 3 3 6 0 31313 0 2 0 2 §s f r. £t~ 197 «118,0.10^1203047GMT_AAvideoAAPP?__5PP XMVXTE sip:bobê£r. sfr. eom. SXP/2.0

Via: SIP/2. C/udp 197., 118,0,10: 5060 ?RAM029fíg4Bk894 348304 De: <sip: alíceOfr, sfr., com>; tag^EX4EvRd?'LY'

Para:<sip:bobgfr.sir.o óm>

Cseq: X INVITE

Chamada~ 1D: toto .03350313 l383mí$sâr.lT-I9T.lÍ3-O-10.J2t3õ4?OMT..AAyideeAAPF?,5RP Max-Envio:70 01 i1i 2ador ~agente: X~~ 11te Con te údo~t ip o:ap1ieação/sdp Conteúdo~€om|rr iment o: 370

Para reenviar respostast ou parâmetros atra’;és do cara»o Descritivo do código cie respostat recop.ia.ndo a Chamada~XD SXP/2,0' 180 pedido video 7 5 em tratamento De: <sip:alíceifr,sfr,eom>:taçm;:EX4EvRd7LY Para;<sip:teobgfr,sfr,com>

Cseq:l 1MVITS Cali-ID: .197.118.0.10 JL2h3G47GMT___AAvideoAAPP7_3EP Max-Envio:70 011.1 i tador-a gen te: X -11 te Conteúdo-Tipo:aplí eaçao/sdp Contendo-CosrpriTaento: 370

Resposta do servidpr

Call ID; totoSMSISDDÉfrnceSsxr,nettmodíficaqar qualidade video><7, 5> 4GOXO< axacsuçâo do pedido: qualidade de video modificado de a 7> SXP/2.0 400 pedido video 7 5 tomada em conta De;<aip:alice§fr, sfr,com>;tap~EXi£vRd7LY Para.; <s ip: bofo8 fr. s f r. côm>

Cseq: 1 IDVITS 1.97.. 118.0.10_12h30i?GMTmAAvideoAAPP7_5PP Man-Envio: 70 atili aador-agenifce ;2t~lite Coúte&do“Tipo: apiiçaç&o/sdp Conteúdo-Comprimento: 3? 0

Anexo 3:

Estabelecimento de um novo canal de dados (cf campos dá norma deixados livres) Método de aviso

Aviso:307 íei.edu "Sessão parâmetro too não compreendida Aviso-;3-01 iei.edu "Rede incompatível endereço tipo '8.164'" Método Ratão A ratão campo preponderante * campo MAY , aparece em qualquer pedido dentro do um diálogo, em qualquer pedido de C&MCE.LAR e em qualquer resposta cujo código de estatuto Explicítamente permita a presença deste campo preponderante A sintaxe do campo preponderante segue os parâmetros da sintaxe do padrão SIP»

Ra São - "Razão" HCOLDN razão-valor* (CQMMA razão™vaiôr) Rasao-vaior ::: protocolo * {SEMI razão-parâmetros)

Protocolo “"SIE"/0, 850"7 token ra z ã o-parâme tros -protoco1o-caus a/ra z ão-1exto /ra zã o -exten e ão

protocolo-causa “"causa" EQUAL causa c a u s a -1* DIGITO

razãó-texto «"texto" SQCAL cotádo-fí O .ra sâo-exten si o ~p a r ame t r o g e néric o

Razão; S1P; causa-580; texto-Rrecondição Falha" 41 - 41

Anexo 4

Descrição de uma sessão com SDP '/^(versão da protocolo) 0a8 (proprietário/eriadox e identificador de sessão) sessão de Nome de utilizador id versão de rede fcípo endereço S~Cnome de sessão) i~*(informação de sessão) 11“* (URI de descrição' ligação a mais informação} ο™* (endereço de emaíi da pessoa responâvel da sessso~> e“mjh(psi«du(Mari Handiey) ou e~Mark Handisy mfh@isteda) p»* (mime.ro de telef one™> p~ei6.1? 253 6011} (informação de ligação ~ não requerida se incluída em todos os meios) c^endereço de tipo rede,, tipo ligação de endereço/TTL b~*(informação de largura de banda) b~modiricadorrralor de largura de banda

Dma ou mais descrições de tempo (ver mais abaixo) Z~*(ajustamentos de tona de tempo) Z-tempo de ajustamentotempo de ajustamenteo de alinhamento ____eg z2 8 8 2 8 4; 4 52 6--1 h 28:38848070 0 k*** (. chave de enoriptaçao) k** método [: chave de encriptaçào) a»* (zero ou mais linhas de atributo de sessão) a«at ributo-[:valor} Zero ou mais descrições medias (ver mais abaixo)

Descrição de tempo 1“(tempo em que a sessão esta activa) t™tempo de partida tempo de paragem de valores dados de acordo com o formato do protocolo NTF R~* (zero ou mais tempos repetidos) r~lísta de duração activa de intervalos .repetidos de alinhamentos desde o tempo d.e partida

Descrição média M~ (endereço de transporte ê homé dos meios)} m-porto d.e meios (/número de portos) lista de transporte de fmt (os portos são sucessivos) I™*(título dos meios) O *(ligação de inf ormação-opcional se incluída no nível da sessão) b«»* (informação de largura de banda) k=« * (c ha ve en c r íp ta da)

Os atributos referenciados em itálico são facultativos. As informações descritas por SDP serão diferentes de acordo com o tipo de trama PSP (Protocolo de Serviço de Publicidade), Entre estes campos facultativos, alguns não são sintaticamente descritos e, portanto, utilizáveis de acordo com o desejo dos serviços desenvolvidos,

Claims (12)

1. SEI¥IHDICÃ:ÇdSS 1 - Processo de eontroio do estabelecimento de canais de trocas para permitir ama transmissão de informações cu]timédia, entre pelo menos dois terminais de cçcminicação (Tlf T2, i ; 1) gados setre ei. por uma rede {&} de telecomanicaçoes, compreendendo uma etapa (dl) de est abe 1 eeimenoo de uma ccotanioaçâo entre um primeirõ terminai, de comum caça o (Ti} e um segundo terminai de comanicaçaο (72 ; por ut11ireguo de aplicações respecticas gerando um protocolo de sinalizocão determinado permi tindo iniciar sessões, ef eotuaa.de e primeiro terminal til; uma. etapa (52) de seleccão de pelo menos nm canal de troca da d a do s e n t te o s do is te rmi.ua í s (T i. , T 2) , e f e c t u a nde ~ se a ètapa ; 52; da seleccão a nm niuel aplica ti. to e a etapa (51) de eatadei.ecim.ento de um.a comunicação compreendendo as éteres seguintes; "· uma étapa (53) de emissão de pelo menos um pedido pelo primeiro terminal (TI},· com destino ao segundo terminal (72}, abrindo uma sessão de acordo com o protocolo de sina lisa gâ o determinado e sendo o processo caracteriçado por - uma étapa (54) de envio pelo segando terminal (T2) de ama resposta representativa de uma índisponlmil idade paro. encerrar a sessão de acorde cem o protocolo de s i na i. 1 xa eâo de t e rm i na do; o processo compreendendo então as etapas (53, 54) de 0 emissão e <Je envio ama etapa (35) ds transmissão de informações adicionais além do dito protocole; de sinal iiação, por utilização· do dito canal de troca de dados seiecoionudo, senso este canal de troca de dados, acessível vis cm campo pura mente de s c r i r. 1 v o / exp 1 i ca 11 ao de caractéristicss de uma sessão, correspondendo as ditas informações adicionais a informações aplicativas não necessárias à gestão de sessões mnltimédiau
2. 2 -Processo de controlo de estabelecimento de canais de comunicação mui Limédia de acordo com a reivindicação 1, compreendendo ama etapa ? 30; de identificação pelo primeiro teruvinal (TI; de peio menos um canal de troca de dados susceptloeX de ser atiiicado para a etapa (55) de transmissão oe informações adicionais, resultando a idonxifioação de ama etapa íãOO) oe pesquisa de canais Oe trocas, na qual o primeiro terminal (Tl) analisa peio menos uma resposta do segundo terminai (12) s um pedido no qual um dos campos puramente descritivos, foi. carregado com informações adicionais além do oito protocolo de sinal;. sacão.
3. 3 - Processo de controlo do estabelecimento do canais de comunicação multimédia de acordo com a reivindicação 2, no qual a etapa (SOO) de pesquisa de canai.e de trocas compreende uma etapa (510) de envio pelo segundo terminai (12) de um conjunto de mensagens de resposta a pedidos d o priraelro termina! f:Tl} . 4 Processo de- controlo de estabelecimento de canais de comunicação multimédi.a do acordo com ao reivindicaçCes 1 a 3, nc qual o canal de troca de dados seleccionado d ntilíaado para difundir, de ponta a ponta, infcossações mult imódia,
4. 5 - Processo de controlo de estabelecimento de canais de comunicação murtimédia de acordo com as reivindicações 1 a i, no qual a etapa 152) de seiacçio compreende: uma seiecção de várioo canais de troca de dados para ot il irar vários métodos de transmissão de informações adicionais em paraleio.
5. 6 - Processo de controlo do estabelecimento de canais de comunicação mnltimédia dc acordo com as reivindicações 1 a 5, comprsendeado uma etapa de neqociaçáo de meios de comunicação, em tempo real, entre um cliente (dl) do primeiro terminal (TI) e um servidor (3) através de uma inrraestrutura do comunicação, tendo uma capacidade de encaminhar através do informações o de mensagens de sinatiração de ponta a ponta dados aplicativos.
6. 7 - Processo de controlo de estabelecimento de canais de comunicação muitimmdts de acordo com as reivindicações 1 a 5, no dual. pelo monos um dos campos seguintes é utilizado para a étapa (5o) de transmissão de informaçbes adicionais além do crosooolo Silo 4 - 8 - Cabeçalho cios pacotes ÇXP em que aio mern:i ornadas caracterisfloas de sessão; De sor itivo do código do resposta; - Call-ID; - Pamo; l.Ób *
7. 8 - Processo de controlo de estabelecimento de capais de comunicação multimédia de acorde cora as relvindlcapões 1 a 7í no qoai peio menos am campo associado ao método ÇCMSóGnM do protocolo SIP é utilisado para a etapa (¾¾) de transmissão de informações adicionais do protocolo SIP. 9 ~ Processo de controlo de estabelecimento de canais do cosam·icação muitimedia de acordo com as rol vir;d icações 1 a 8, no qual peio menos em campo associado à informação SD? de oarga tltli de 81P é ntiiirado para a etapa toS) de transmissão de informações adicionais além do protocolo IIP, sendo este campo 8 DP na carga útil de SIP definido como cpciona 1 peio protocolo SI?, ou tendo uma estrutura: e ursa sintaxe que não são fixadas peio protocolo 3IP, IQ - Processo de controlo de estabelecimento de canais de comunicação mu11iméoia de acordo com as reivindicações 1 a 8, no qual. um. campo Cal!--Xo do protocolo SXP s otilirado para a etapa (55) de transmissão de informações adicionais além do protocolo siP, 8
8. 11 - Prooasso de controlo dc ostabslec.uaento de canais de comunicação rsultimédia cie acordo com as reiviadicacdes 1 a 10, no qual. condições de consumo/uso do conteúdo incltimédiâ transmitido quando da dita etapa (eo) de i. r ansmu.ssâo são modi f icadas por ume. apli cação mu ir i méd La,, consumidora do conteúdo muitimèdia; sobre a recepção e a tomada em conta da a iniormaçoes adiciona l s veiculadas através do protocolo SIP. 12 ·" Processo de controlo de estabelecimento de canais de comunicação muitimèdia de acordo com a reivindicação 11, na qual as ditas condições de consumo/uso do conteúdo muitimèdia transmitido quando da dita etapa ido) de transmissão são modificadas de acordo com a evolução do ambiente oe reooc de transporte disponíveis para o segundo terminal Π:2) ,· 13 " Processo de controlo de estabelecimento oe canais de comunicação tíultimèdia de acordo com aa reiuindi oações il e 12f no qu a 1 as ditas condições de consumo/uso do conteúdo muitimèdia; transmitido quando da dita etapa iSõ) de transmissão; são mo dl ficadas de «s cor do com a evolução das condições de iocaiimação geográfica do segundo terminal fia) -,
9. 14 - Processo de controlo de estabelecimento de canais de comunicação muitimèdia de acordo com as reivindicações 11 a 13; no qual as ditas condições de: eoTisumo/uso do Ό ~ 8 contendo multimédia transmitido quando da dita etapa (ato de transmissão sâo moeificadas do acordo com a eaolaçâc das condições de tonel enamore: o intrínseco do segundo terminai (T2), 15 "· Processo de controlo de estabelecimento de cariais de comunicação multimédia de acordo oom as rei cindi opções 11 a 11, no qual as ditas condições de çoasumo/aso de conteúdo .multimédia transmitido quando da dita etapa (5:5) de transmissão são mod.ificadas de acordo com a evrrloção da a condições de entrega de um seroiço recebido peio segundo terminal (T2), 16 " Processo de acordo com as reieindicações 1 a ldf no qual as condições de oonsnme/uso de um r lano de transmissão estabelecido entre os dois tenm.in.ais de comunicação (1,2). são moem troadas por aplicações muitimèdia consumidoras e emissoras do contendo multimédia de cada terminei, sobre a emissão, a recepção e a tomada em conta nas informações adicionais reiculedas através do protocolo dIb,
10. 17 - Processo de controle de estabelecimento de canais de comunicação multimédia de acordo oom as reivu.adioeçõcs 1 a 16, compreendendo uma étapa de aeaiiaçâo de uma banda passante disponivei para peio menos nm dos canais de trotas identificadas fora da sessão.
11. 18 - Processo de controio de estabelecimento de canais de comunicação: muitímédia de acordo com. as reivindicações X a 17,. compreendendo uma etapa de r enegooi. ação, em tempo real,: de uru ser rico quando são mo dl ficadas condições do uso, ao niuel do segundo terminal (T2), sendo real .toada a etapa de renegociação, para diminuir um consumo do banda passante, modificando ao dimensões de uma janela mi deo visitei no écra. lã Processo de controlo de estabelecimento de canais do comunicação nu Iro média de acordo com as reivindicações 1 a 18, compreendendo uma etapa de memorização numa memória de cada um dos dois terminais (Ti, 12(, de uma lista de: canais de troes idantifiçados e podendo ser utilizados fora da os suão para transmitir i.n formações mui timedia. 20 Processe de controlo de estabelecimento de canais do comunicação :r.dt imedia de acordo com as reivindicações 1 a 19, no qual o protocolo de sina 11 ração é o protocolo IIP e a étapa íns) de transmissão de informaedos adicionais além do di to protocoi o compreende; - uma étapa do escritura poio primeiro terminal. (Ti) de um pedido, em formato tente; - uma étapa de codi.ficação do pedido? - uma étapa de env io oc uma mensagem 1NVITE passando o pedi.do codificado no campo Ca; 1 - i D. Β: 8 21 ~ Processo de controlo cio estabelecimento de canais de cremam, ca p á o multissádia cie acordo cor a rei sindicado 22, no qua 1 a 6 tapa (55) de transei s sé o de informações adicionais além do dito protocolo cocoroendo além disso: - uma etapa do envio de noa m.ensagem de resposta contendo uca indicação do indisponibilidade temporária e na qual uma resposta ao podido e posicionada pelo segundo corei na 1 ( 12) num campo paramente dosor 1 t.i.vo o u oxo 1 i.cativo; - urna etapa de con.fitmaçao do fecho do uma soasse 51P, na qual o primeiro terminai (11) envia ao segunde terminai (12) ma mensagem do execução ACK com o mesmo campo Cali-ID para indicar uma boa recepção da r e s po st a ao ρe d1do < 22 ~ Processo de core:rolo de esr adoieermen to de cariais de comunicação multiarédia do acordo com a reivindicação 2.1, no qual o dito campo puramente descritivo ou eapticativo é c campo «Racaov,
12. 23 - Programe do um módulo de tratamento directaxaonte carregávol na momo ria de um terminai (II, 12, «) do comuni.eapâo com uma rede (d) para coma·'dar as etapas da reivindicação 1, 2, 3, A, ou 5, quando o dito programa é executado sobre o terminal (11, 12, 4) Lisboa, 11 de Agosto de 2Oud