sip protocolo de sinalização que permite a configuração, estabelecimento e término de uma...

SIPSIP

Protocolo de sinalização que

permite a configuração,

estabelecimento e término de

uma sessão fim-a-fim para

comunicação multimídia.

SIP – Funções BásicasSIP – Funções Básicas

• Convite de usuários para participar de sessões multimídia;

• Localização do destino do usuário;

• Transporte de informações que permitam o estabelecimento da sessão;

• Modificações de sessões já existentes;

• Encerramento de Sessões;

• Indicação de presença e transporte de mensagens instantâneas.

SIP - HistóricoSIP - Histórico

Desenvolvido pelo grupo MMUSIC do

IETF. Definição do protocolo:

• Versão 1.0 : 1997 - Draft;

• Versão 2.0 : março 1999 - RFC 2543;

• Correções : julho de 2000 – RFC

SIP - CaracterísticasSIP - Características

• Incorpora elementos de protocolos

usados na Internet:

• HTTP (Hyper Text Transport Protocol):

utiliza estrutura cliente/servidor e url /

• SMTP (Simple Mail Transport Protocol):

utiliza forma de codificação em texto e

campos de cabeçalho (to, from e

subject, entre outros)

SIP - CaracterísticasSIP - Características

• Trabalha em conjunto com outros

protocolos;

• Mobilidade pessoal;

• Utiliza, preferencialmente,

transporte sem conexão e não

confiável para a sinalização (UDP):

acelera o estabelecimento de

chamadas.

Aplicação

Apresentação

Sessão

Transporte

Enlace

Física

H.323H.323 SIPSIP

Sinal de Áudio Sinal de Vídeo

G.711 G.728

G.722 G.729

G.723.1

RTCP RAS RTP

T.125 /T.122

X.224.0

Serviços Suplementa.

H.450.3 H.450.2

H.450.1

UDP TCP

Controle

H.245 H.225

UDP TCP

RTCP RAS RTP

Sinal De

Áudio/ Vídeo

SIPSIP

• Conexão simplificada;

• Inspirou mudanças no

H.323:

• H.323v2 : Fast

Connect;

• H.323v5: Sinalização

sobre UDP.

SIP – Exemplo de conexãoSIP – Exemplo de conexão

• Mensagens SIP são

codificadas em formato

texto;

• Mensagens são pedidos

ou respostas

(cliente/servidor) -

transações;

INVITE sip:marconi@radio.org SIP/2.0Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19bMax-Forwards: 70To: G. Marconi <sip:Marconi@radio.org>From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341Call-ID: 123456789@lab.high-voltage.orgCSeq: 1 INVITESubject: About That Power Outage...Contact: <sip:n.tesla@lab.high-voltage.org>Content-Type: application/sdpContent-Length: 158

v=0o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.orgs=Phone Callc=IN IP4 100.101.102.103t=0 0m=audio 49170 RTP/AVP 0a=rtpmap:0 PCMU/8000

Corpo SDP da mensagem INVITE Parâmetro SDP

v=0 Versão

o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org Origem

s=Phone Call Assunto

c=IN IP4 100.101.102.103 Conexão

t=0 0 Tempo

m=audio 49170 RTP/AVP 0 Mídia

a=rtpmap:0 PCMU/8000 Atributos

SIP/2.0 180 RingingVia: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b ;received=100.101.102.103To: G. Marconi <sip:marconi@radio.org>;tag=a53e42From: Nikola Tesla <sip:n.tesla@high-voltage.org>>;tag=76341Call-ID: 123456789@lab.high-voltage.orgCSeq: 1 INVITEContact: <sip:marconi@tower.radio.org>Content-Length: 0

SIP/2.0 200 OKVia: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b ;received=100.101.102.103To: G. Marconi <sip:marconi@radio.org>;tag=a53e42From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341Call-ID: 123456789@lab.high-voltage.orgCSeq: 1 INVITEContact: <sip:marconi@tower.radio.org>Content-Type: application/sdpContent-Length: 155

v=0o=Marconi 2890844528 2890844528 IN IP4 tower.radio.orgs=Phone Callc=IN IP4 200.201.202.203t=0 0m=audio 60000 RTP/AVP 0a=rtpmap:0 PCMU/8000

ACK sip:marconi@tower.radio.org SIP/2.0

Via: SIP/2.0/UDP lab.high-

voltage.org:5060;branch=z9hG4bK321g

Max-Forwards: 70

To: G. Marconi <sip:marconi@radio.org>;tag=a53e42

From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341

Call-ID: 123456789@lab.high-voltage.org

CSeq: 1 ACK

Content-Length: 0

Elementos da Arquitetura

Elementos da ArquiteturaElementos da Arquitetura

• SIP User Agents

• SIP Presence Agents

• Back-to-Back User Agents (B2BUA)

• SIP Gateways

• Servidores SIP• Servidores Proxy: Statefull, Stateless,

• Servidores de Redirecionamento

• Servidores de registro

SIP User Agents

• User Agent Client (UAC)• São os terminais finais da Comunicação;• Enviam requisições SIP;

• User Agent Server (UAS)• Escutam as requisições de chamada;• Geram as respostas SIP;

• USER AGENT: UAC + UAS• Suporte obrigatório ao SDP.

SIP Presence Agents

• RFC 3265 - Session Initiation Protocol (SIP) - Specific Event Notification

• São dispositivos capazes de receber pedidos de subscrição e gerar notificações;

• Podem agir como servidores de informação de presença ou como proxy, encaminhando pedidos de subscrição para outros agentes de presença.

Back-to-Back User Agents (B2BUA)

• Dispositivos que recebem uma requisição, reformulam e enviam como uma nova requisição;

• Exemplo: Gateway de aplicação (ALG) de alguns firewalls.

SIP Gateways

• Aplicação que faz interface entre uma

rede SIP e outra usando outro protocolo

de sinalização;

• O gateway pode necessitar terminar

tanto a sinalização quanto o tráfego

multimídia (RTP)

• SIP User Agents

• SIP Presence Agents

• Back-to-Back User Agents (B2BUA)

• SIP Gateways

• Servidores SIP• Servidores Proxy: Statefull, Stateless,

• Servidores de Redirecionamento

• Servidores de registro

Servidores Proxy• Encaminham as requisições para outros servidores;

• Geralmente utiliza uma banco de dados ou um

serviço de localização para determinar o

encaminhamento (determina the next hop);

• Não geram requisições, apenas respondem (A

requisição CANCEL é uma exceção);

• Não têm capacidade multimídia;

• Não altera o corpo da mensagem, apenas o

cabeçalho: cada proxy no caminho acrescenta um

campo VIA na mensagem para estabelecer a rota;

• Podem ser Statefull ou StateLess;

• Pode duplicar o pedido para múltiplos destinos

(forking).

Topologia comum: o trapézio SIP

Servidores Proxy Stateless

• Processa cada requisição apenas baseado

no conteúdo da mensagem;

• Quando a resposta voltar, usa o

cabeçalho Via para saber qual o próximo

• Não retransmite mensagens;

• Podem ocorrer loops: verificação através

do campo Max-Forwards (RFC 3261)

Servidores Proxy Statefull

• O servidor guarda informações sobre a

transação até ocorrer uma resposta “200

OK” ou resposta de erro;

• Retransmite a requisição se não receber

resposta, liberando o user agent desta

função;

• Necessário para requisições multicast.

Servidores Proxy de Bifurcação

(Forking Proxies) São servidores Proxy Statefull (guardam

informações das transações) pois podem

duplicar e enviar cópias dos pedidos para

várias máquinas, permitindo que elas

possam ser usadas para tentar contatar

vários pontos finais pertencentes à mesma

pessoa.

Servidores de

RedirecionamentoSão servidores que

respondem mas não

encaminham requisições.

Utilizam banco de dados ou

serviço de localização para

procurar o usuário e

responde com uma

mensagem de

redirecionamento (3xx).

Servidores de Registro

(Registrar)

• Recebem registro sobre a atual localização do usuário,

acionados por servidores de redirecionamento ou proxy

quando se quer procurar o usuário;

• Endereço de configuração all SIP servers:

sip.mcat.net:224.0.1.75;

• Cada registro possui um tempo de vida;

• Se o terminal se mover e desejar modificar os

parâmetros, pode enviar um pedido de cancelamento.

Mensagens SIP

Mensagens SIPMensagens SIP

• Mensagens SIP são codificadas em formato texto ISSO 10646 com codificação UTF-8;

• Mensagens são pedidos (requests) ou respostas (responses)

Linha de início: pedido ou resposta

Cabeçalhos

Linha em branco

Corpo da mensagem, se houver. Pode ser SDP limpo ou criptografado, MIME...

Formato genérico da mensagem SIP. Fonte Telefonia IP - HERSENT, Oliver, GUIDE,David, PETIT, Jean-Pierre.

CABEÇALHO

• Possui diversos campos, sendo alguns presentes tanto em pedidos como respostas;

• Na maioria dos casos, segue as regras do cabeçalho HTTP:

Nome do Campo: campo/valor <CRLF>

• Muitos cabeçalhos possuem forma compacta (uma única letra para indicar o nome campo);

Mensagens SIPMensagens SIPForma compacta de cabeçalhos SIP

Campo Compactado

Accept-Contact a

Allow-Event u

Call-ID i

Contact m

Content-Encoding e

Content-Length l

Content-Type c

Event o

From f

Refer-To r

Referred-By b

Reject-Contact j

Subject s

CABEÇALHO - CAMPOS MAIS COMUNS:

• CALL-ID : obrigatório em pedidos e respostas, é um identificador único para identificar uma chamada. É composto de um identificador aleatório único localmente seguido do nome de um domínio ou endereço IP. Ex:

Call-ID: 34a5d553192cc35@15.34.3.1

i: 35866383092031257@port34.carrier.com

• CSeq: obrigatório nas requisições, o campo de seqüência de comando é usado para determinar pedidos fora de seqüência ou diferencia entre uma nova requisição e uma retransmissão. Composto de um número decimal (incrementado a cada novo pedido, exceto no ACK ou CANCEL) seguido do método. Ex:

Cseq: 12 INVITE

• From: obrigatório em pedidos e respostas, indica a origem da requisição. Contém uma URI (Universal Resource Identifier);

Os endereços SIP são URLs (Uniform Request Location)

Esquema: sip/http/ftp/email, Nome do Usuário, Senha(Opcionalmente), Nome do Host (Porta Opcional), Parâmetros, Cabeçalhos e Corpo

Permite o uso de outros prefixos, além do sip, facilitando a integração com a internet e permitindo o redirecionamento. Ex:

sip:aluno@ufrn.br; tag=123456

Prefixo Significado

sip SIP URI

sips Secure SIP URI

tel Telephone URI

pres Presence URI

im Instant Message URI

mailto E-mail URL

http Web URL

URIs mais comuns em mensagens SIP

• To : indica o destino pretendido da requisição. Contém uma URI (Universal Resource Identifier) e um tag para auxiliar na identificação da chamada (obrigatório na RFC 3261). Ex:

sip:aluno2@ufrn.br; tag=654321

To e From são copiados dos pedidos nas respostas, não são alterados os campos. Indicam sentido de origem do pedido.

• VIA: usado pra gravar a rota de um pedido, para que as respostas usem o mesmo caminho. O user agent gera a requisição colocando seu próprio endereço no campo Via. Cada proxy acrescenta um campo Via no topo da lista. O campo Via contém o nome e versão do protocolo, transporte e endereço, além de parâmetros adicionais como received, maddr (endereço multicast) e ttl. Ex:

Via : SIP/2.0/UDP proxysip.ufrn.br

O primeiro campo Via é o

endereço do

servidor?

Descarte a mensagem

Remova a primeira linha

Há um segund

o campo VIA?

A mensagem é para este servidor.

Existe o parâme

tro maddr?

Encaminhe para o end. multicast

Existe o parâmet

ro received

Encaminhe para o end.

received

Encaminhe a resposta para o

endereço VIA.

Resposta Recebida pelo servidor

Sim Não Sim

Encaminhamento VIA

Campos que se relacionam com o corpo da mensagem:

• Content-Type: descreve o tipo de conteúdo do corpo da mensagem. Ex:

Content-Type: application/sdp

Content-Type: multipart/mixed

• Content-Lenght: o tamanho do corpo da mensagem em octetos

• Max-Forwards: campo utilizado para indicar o máximo de hops que o pedido pode fazer. O valor é decrementado por cada proxy que encaminhar o pedido. Um proxy que receba o campo com valor 0 descarta a mensagem e retorna uma mensagem de erro 483 (Too Many Hops). Obrigatório na RFC 3261 para controle de loop (feito pelo campo Via na RFC 2543).

CABEÇALHO

• Muitos outros campos foram definidos e tem uso de acordo com a requisição ou resposta: Accept, Accept-Encoding, Accept-Language,

Alert-Info, Allow, Allow-events, Authentication-Info, Authorization, Call-Info, Contact, Content-Disposition, Content-Encoding, Content-Language, Content-Length, Content-Type, Date, Error-Info, Expires, In-Reply-To, Max-Forwards, Min-Expires, MIME-Version, Organization, Priority, Proxy-Authenticate, Proxy-Authorization, Proxy-Require, Record-Route, Reply-To, Require, Retry-After, Route, Server, Subject, Supported, Timestamp, Unsupported, User-Agent, Warning, WWW-Authenticate;

CABEÇALHO

• Proxies não necessitam entender novos métodos e campos de cabeçalho: extensões podem ser feitas ao protocolo sem necessitar mudança da estrutura de rede.

LISTA DE CAMPOS QUE PODEM INSERIDOS OU

MODIFICADOS POR PROXIES

Alert-Info

Call-Info

Content-Length

Error-Info

Max-Forwards

Organization

Priority

Proxy-Authenticate

Proxy-Authorization

Proxy-Require

Record-Route

Reason

Require

WWW-Authenticate

Linha de início: determina se a mensagem é um pedido ou uma resposta. Composta de método, uri e versão do SIP. Ex:

INVITE sip:aluno@ufrn.br SIP/2.0

Cabeçalhos

Linha em branco

Requisições e respostas

• Pedidos, requisições ou métodos especificam a ação a ser tomada por outro user agent ou servidor. A RFC 3261 define 6 métodos: INVITE, REGISTER, BYE, ACK, CANCEL E OPTIONS. Outros 7 métodos são definidos em outras RFCs: REFER, SUBSCRIBE, NOTIFY, MESSAGE, UPDATE, INFO e PRACK;

• Respostas contém um código de status e uma frase de justificativa inteligível por pessoas. Podem ser informativas (1xx), de Sucesso (2xx), de redirecionamento (3xx), de erro de cliente (4xx).

Requisições - INVITE

• É o método utilizado para

estabelecer sessões entre user

agents;

• Sempre é confirmado com ACK;

• Geralmente possui um corpo que

descreve as informações de mídias

da origem;

• O User agent cria um Call-ID para

ser usado enquanto durar a

chamada.

Requisições - INVITE• CSeq é utilizado para controle de

retransmissões;

• No caso de ser necessário mudar as características da mídia, um re-INVITE pode ser usado com o CSeq incrementado;

• Os clientes transmitem INVITE com backoff exponencial: 500ms, 1s, 2s, 4s.

• Retransmissões cessam quando chegam respostas provisórias (100 trying).

Requisições - ACK• Método usado para confirmação

final para requisições INVITE;

• O CSeq não é incrementado para o ACK, mas alterado para a próxima requisição;

• Opcionalmente, pode conter uma mensagem SDP;

• Para respostas 2xx (sucesso), o ACK é fim-a-fim, mas todas as outras são hop-by-hop quando statefull proxies estão envolvidos.

Requisições – BYE

• Método usado para encerrar

uma sessão já estabelecida;

• Enviado apenas pelos users

agents envolvidos, nunca por

proxies;

• É um método fim-a-fim;

Requisições – CANCEL

Método utilizado para terminar

buscas pendentes ou tentativas de

chamadas. O pedido pode ser gerado

pelos user agents ou proxies que

receberam uma mensagem informativa

provisória (1xx) mas não receberam a

mensagem final.

Requisições – OPTION

Método utilizado para um

cliente saber sobre as capacidades do

servidor. A resposta contém uma lista

dos métodos permitidos.

Requisições – REGISTER

Método utilizado pelo user

agent para notificar a rede SIP da sua

localização atual (Contact URI – IP

Address – um ou mais endereço).

Requisições RFC 3261

• INVITE

• REGISTER

• BYE

• ACK

• CANCEL

• OPTIONS.

Requisições de outras RFCs

• REFER

• SUBSCRIBE

• NOTIFY

• MESSAGE

• UPDATE

• INFO

• PRACK.

Requisições• REFER: método usado por um user agent para

requisitar que outro user agent acesse uma URI ou URL. Pode ser utilizado, por exemplo, para implementar uma transferência de chamada;

• SUBSCRIBE: método usado por um user agent para estabelecer uma inscrição com o propósito de receber notificações (Ex: informações de presença - online/offline)

• NOTIFY: método usado para transportar informações sobre eventos particulares, definidos na subscrição;

• MESSAGE: usado para transporte de mensagens instantâneas usando SIP. Pode conter anexos MIME

Requisições• UPDATE: usado para modificar o estado da sessão

sem mudança de estado do diálogo. Usado no lugar de re-INVITE enquanto o INVITE não foi confirmado.

• INFO: usado para que o user agent envie informações de sinalização da chamada para outro agente com o qual estabeleceu uma conexão multimídia. Diferente do re-INVITE pois não muda as características da sessão. Proposto para transportar algumas informações de sinalização PSTN;

• PRACK: ACK provisório, utilizado para reconhecimento de mensagens provisórias (1xx).

RESPOSTASRespostas contém um código de status e uma frase de justificativa inteligível por pessoas.

Classes de Status Code:100-199 (1XX) :Informação Provisória200-299 (2XX) :Sucesso300-399 (3XX) :Redirecionamento400-499 (4XX) :Erro no Cliente500-599 (5XX) :Erro no Servidor600-699 (6XX) :Falha Global

RESPOSTASStatus Code• 100-199 : são consideradas respostas

provisórias e sem confiabilidade;• 200-699 :são as respostas finais,

definitivas, terminam uma transação no ambiente SIP.

Cabeçalho da RespostaOs campos Call-ID, To, From,CSeq são espelhadas em respostas para suportar o match (verificação) de campos entre requisição e resposta.

1xx Informativo (Pedido recebido, continuando a processar o pedido)

100 Tentando180 Chamando181 A chamada está sendo retransmitida182 Colocado na fila

2xx Sucesso (a ação foi recebida, entendida e aceito com sucesso)

200 OK

3xx Redirecionamento (uma ação adicional deve ser tomada para completar o pedido)

300 Múltiplas escolhas301 Movido permanentemente302 Movido temporariamente380 Serviço alternativo

Categorias de códigos de status

4xx Erro de cliente (O pedido contém sintaxe inválida ou não pode ser efetuado neste servidor)

400 Pedido inválido401 Não autorizado402 Necessário pagamento403 Proibido404 Não encontrado405 Método não permitido406 Não aceitável407 Necessária autenticação do proxy408 Tempo para o pedido esgotado 409 Conflito410 Não mais presente411 Necessário fornecer comprimento413 Corpo da mensagem de pedido muito grande414 URI do pedido muito grande415 Tipo de mídia não suportado420 Extensão inválida480 Temporariamente não disponível481 Transação ou leg de chamado não existe482 Laço (loop) detectado483 Excesso de segmentos (hops)484 Endereço incompleto485 Ambíguo

5xx Erro de servidor500 Erro interno ao servidor501 Não implementado502 Gateway inválido503 Serviço não disponível504 Tempo esgotado no gateway505 Versão SIP não suportada

6xx Falha global600 Ocupado em todos os lugares603 Declínio604 Não existe em lugar nenhum606 Não aceitável

Corpo da mensagem: obrigatoriamente deve suportar SDP. Pode utilizar formato MIME (Multipurpose Internet Mail Extensions) e S/MIME para aumentar a segurança (criptografia do corpo da mensagem).

Cabeçalhos

Linha em branco

SDP Session Description

Protocol

SDP : Session Description ProtocolSDP : Session Description Protocol

O Protocolo de descrição de Sessão –

SDP - foi desenvolvido para descrever

sessões de multimídia.

Esta descrição pode ser usada para

negociar uma aceitação de um conjunto de

tipos de mídias compatíveis.

O SDP contém informações sobre a sessão, tais como:

• Endereço IP ou host name;

• Número da Porta (usada pelo UDP ou pelo TCP);

• Tipo de mídia (áudio, vídeo, whiteboard interativo);

• Assunto da sessão;

• Tempo de inicio;

• Informações de contato.

Assim como o SIP, SDP usa codificação textual. Uma

mensagem SDP é composta de uma série de linhas,

chamadas campos, cujos nomes são abreviados por

uma única letra.

Lista dos principais campos SDP, em sua ordem requerida.

Campo Nome obrigatório/opcional

v= Número da versão do protocolo obrigatório

o= Identificador do proprietário da sessão obrigatório

s= Nome da Sessão obrigatório

i= Informação da sessão opcional

u= Uniform Resource Identifer opcional

e= Endereço de e-mail opcional

p= Número de telefone opcional

c= Informações de conexão obrigatório

b= Informação sobre largura de banda opcional

t= Tempo – início e fim da sessão obrigatório

r= Número de repetições opcional

z= Correções de zonas de horário opcional

k= Chave de criptografia opcional

m= Informações de mídia opcional

a= Atributos da mídia opcional

Informações de capacidade de Mídia (m=)

O campo opcional m= contém informações sobre os tipos de mídias:

m=mídia porta transporte lista-de-formatos

Sendo:

mídia: audio, video, application, data, telephone ou control;

porta: número da porta;

transporte: protocolo de transporte – RTP/AVP ou UDP;

lista-de-formatos: contém os tipos de payload definido nos perfis RTP de aúdio e vídeo;

Exemplo:

m=audio 49170 RTP/AVP 0

• Payloads RTP de 0 a 95 são estáticos, designados pela IANA (Internet Assigned Numbers Authority). Ex:

• Payloads de 96 a 127 são dinâmicos, negociados pelo protocolo de controle de conferência. Ex:

a=rtmap:98 L16/16000/2

Tipo de payload

0 Áudio PCM, µ law

8 PCM, a law

9 G.722

4 G.723

15 G.728

18 G.729

34 Vídeo H.263

31 H.261

Informações de capacidade de Mídia (m=)

(Áudio estéreo com codificação de linear de 16 bits amostrado a 16 kHz)

Exemplo SDP

o=johnston 2890844526 2890844526 IN IP4 43.32.1.5

s=SIP Tutorial

i=This broadcast will cover this new IETF protocol

u=http://www.digitalari.com/sip

e=Alan Johnston alan@mci.com

p=+1-314-555-3333 (Daytime Only)

c=IN IP4 225.45.3.56/236

b=CT:144

a=rtpmap:0 PCMU/8000

m=video 23422 RTP/AVP 31

a=rtpmap:31 H261/90000

Cabeçalhos

Linha em branco

SIP Operação

do Protocolo

Operação do ProtocoloOperação do Protocolo

Negociação da sessão• Destino recebe INVITE com SDP

especificando o formato de mídia / codec desejado;

• Pedido pode ser aceito ou rejeitado;

• Resposta lista os tipos de mídia disponíveis. Se aceito, possui o mesmo tipo (payload RTP);

Localização de usuário

• Requisições podem passar por vários

servidores proxy;

• Cada servidor chega se é responsável pelo

domínio requisitado, caso contrario repassa

para o servidor SIP do domínio

correspondente;

• Servidores SIP são registrados no DNS através

de registros SRV (DNS location of services ) ou

NAPTR (Naming Authority Pointer).

Localização de Usuários

sip:aluno@ufrn.br

SIP Statefull Proxy 1

Invite SIP Redirect Server

InviteMoved TemporarilyACK

SIP Stateless Proxy

Invite

SIP Statefull Proxy 2Invite

sip:aluno2@ufrn.br

Invite 200 OK

200 OK

200 OKACK

Caminho da

Sinalização

Mídia (RTP)

1. Codificação binária ASN.1, tamanho da PDU menor

2. Uso de e-mail, mas presumindo que o protocolo é H.323;

3. Não faz priorização de chamada;

4. Sub-Protocolos: H.245, H225 (Q.931, RAS, RTP/RTCP), H.450.x.

5. Recursos poderosos para controle de conferência;

6. Servidor único Gatekeeper H.323

SIP x H.323SIP x H.323

1. Codificação em modo texto, fácil de depurar;

2. Uso de url como identificador de protocolo / possibilidade de redirecionamento;

3. Priorização de chamadas;

4. Protocolo SDP descreve os tipos de mídia;

5. Multicast possível na sinalização;

6. Servidores com diferentes comportamentos: registro, proxy, redirecionamento;

7. Protocolo de sinalização presença e mensagens instantâneas

SIP x H.323SIP x H.323

• Ambos usam RTP/RTCP sobre UDP/IP;

• Velocidade de Conexão SIP inspirou

mudanças na Conexão H.323 (uso de Fast

Connect) e possibilidade de sinalização sobre

• SIP tem suporte para DNS e url desde o

início, enquanto H.323 começou sem nenhum

suporte;

• Enquanto o H.323 tem o conceito de MCU

desde o início, SIP inicialmente não tinha

definido mecanismos de conferência;

• Utilização de gateways SIP-H.323.

sip protocolo de sinalização que permite a configuração, estabelecimento e término de uma...

Documents

reportagens multimídia

kx-hdv230 sip телефон kx-hdv130...

elastix – instalando, criando ramais e sip trunk vono

os textos multimídia multimÍdia multimídia multimÍdia...

sistemas multimídia o Áudio tópico: características do...

sip session initiation protocol

introdução ao protocolo sip* -...

aligera - gateways sip - 201404 v.1(1).pdf

norma - sip-spp.pt

703741_redes multisserviços-redes-sip-5.pdf

codigos sip paragens ord carreira

sistemas multimÍdia

sip pulse presentation

trabalho sip 2015

para registro de estabelecimentos sip/poa

03 material sip 1bim

kit multimídia

dsc/ceei/ufcg sistemas multimídia hardware/software para...

sistemas multimídia - aula 04 - o que é multimídia...

kit's multimídia