SIP 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á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ó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 3261.

SIP - Características Incorpora elementos de protocolos usados na Internet: HTTP (Hyper Text Transport Protocol): utiliza estrutura cliente/servidor e url / uri; 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í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.

SIP H.323 Aplicação Sinal de Áudio Sinal de Vídeo Dados SDP Sinal De G.711 G.728 T.127 G.722 G.729 H.261 SIP G.723.1 H.263 T.126 Apresentação Sessão Transporte RTCP RAS RTP RTCP RAS RTP T.124 Serviços Suplementa. T.125 / T.122 H.450.3 H.450.2 H.235 H.450.1 X.224.0 Controle H.245 H.225 UDP TCP UDP TCP Rede Enlace Física

SIP Conexão simplificada; Inspirou mudanças no H.323: H.323v2 : Fast Connect; H.323v5: Sinalização sobre UDP.

SIP – Exemplo de conexão Mensagens SIP são codificadas em formato texto; Mensagens são pedidos ou respostas (cliente/servidor) - transações;

SIP – Exemplo de conexão INVITE sip:marconi@radio.org SIP/2.0 Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b Max-Forwards: 70 To: G. Marconi <sip:Marconi@radio.org> From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341 Call-ID: 123456789@lab.high-voltage.org CSeq: 1 INVITE Subject: About That Power Outage... Contact: <sip:n.tesla@lab.high-voltage.org> Content-Type: application/sdp Content-Length: 158 v=0 o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org s=Phone Call c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000

SIP – Exemplo de conexão 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 – Exemplo de conexão SIP/2.0 180 Ringing Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b ;received=100.101.102.103 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 INVITE Contact: <sip:marconi@tower.radio.org> Content-Length: 0

SIP – Exemplo de conexão SIP/2.0 200 OK Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b ;received=100.101.102.103 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 INVITE Contact: <sip:marconi@tower.radio.org> Content-Type: application/sdp Content-Length: 155 v=0 o=Marconi 2890844528 2890844528 IN IP4 tower.radio.org s=Phone Call c=IN IP4 200.201.202.203 t=0 0 m=audio 60000 RTP/AVP 0 a=rtpmap:0 PCMU/8000

SIP – Exemplo de conexão 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 SIP

Elementos da Arquitetura SIP User Agents SIP Presence Agents Back-to-Back User Agents (B2BUA) SIP Gateways Servidores SIP Servidores Proxy: Statefull, Stateless, Fork Servidores de Redirecionamento Servidores de registro

Elementos da Arquitetura 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.

Elementos da Arquitetura 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.

Elementos da Arquitetura 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.

Elementos da Arquitetura 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)

Elementos da Arquitetura SIP User Agents SIP Presence Agents Back-to-Back User Agents (B2BUA) SIP Gateways Servidores SIP Servidores Proxy: Statefull, Stateless, Fork Servidores de Redirecionamento Servidores de registro

Elementos da Arquitetura 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).

Elementos da Arquitetura Topologia comum: o trapézio SIP

Elementos da Arquitetura 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 hop; Não retransmite mensagens; Podem ocorrer loops: verificação através do campo Max-Forwards (RFC 3261)

Elementos da Arquitetura 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.

Elementos da Arquitetura 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.

Elementos da Arquitetura Servidores de Redirecionamento Sã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).

Elementos da Arquitetura 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 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.

Mensagens SIP 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 SIP Forma 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 To t Via v

Mensagens SIP 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

Mensagens SIP CABEÇALHO - CAMPOS MAIS COMUNS: 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

Mensagens SIP CABEÇALHO - CAMPOS MAIS COMUNS: 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

Mensagens SIP URIs mais comuns em mensagens SIP Prefixo Significado sips Secure SIP URI tel Telephone URI pres Presence URI im Instant Message URI mailto E-mail URL http Web URL

Mensagens SIP CABEÇALHO - CAMPOS MAIS COMUNS: 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 : SIP/2.0/UDP proxysip.ufrn.br Mensagens SIP CABEÇALHO - CAMPOS MAIS COMUNS: 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

Encaminhamento VIA Resposta Recebida pelo servidor Descarte a mensagem O primeiro campo Via é o endereço do servidor? Descarte a mensagem Não Encaminhamento VIA Sim Remova a primeira linha VIA Há um segundo campo VIA? A mensagem é para este servidor. Encaminhe a resposta para o endereço VIA. Não Sim Não Existe o parâmetro maddr? Existe o parâmetro received? Encaminhe para o end. multicast maddr Encaminhe para o end. received Sim Sim Não

Mensagens SIP CABEÇALHO - CAMPOS MAIS COMUNS: 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

Mensagens SIP CABEÇALHO - CAMPOS MAIS COMUNS: 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).

Mensagens SIP 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;

LISTA DE CAMPOS QUE PODEM INSERIDOS OU MODIFICADOS POR PROXIES Mensagens SIP LISTA DE CAMPOS QUE PODEM INSERIDOS OU MODIFICADOS POR PROXIES Alert-Info Call-Info Content-Length Date Error-Info Max-Forwards Organization Priority Proxy-Authenticate Proxy-Authorization Proxy-Require Record-Route Reason Require Route Via 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.

Mensagens SIP Linha de início: pedido ou resposta Cabeçalhos Linha em branco Corpo da mensagem, se houver. Pode ser SDP limpo ou criptografado, MIME... 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

Mensagens SIP 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).

Mensagens SIP 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.

Mensagens SIP 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).

Mensagens SIP 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.

Mensagens SIP 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;

Mensagens SIP 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.

Mensagens SIP 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.

Mensagens SIP 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).

Mensagens SIP Requisições de outras RFCs Requisições RFC 3261 REFER SUBSCRIBE NOTIFY MESSAGE UPDATE INFO PRACK. Requisições RFC 3261 INVITE REGISTER BYE ACK CANCEL OPTIONS.

Mensagens SIP 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

Mensagens SIP 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).

RESPOSTAS Mensagens SIP Respostas 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ória 200-299 (2XX) :Sucesso 300-399 (3XX) :Redirecionamento 400-499 (4XX) :Erro no Cliente 500-599 (5XX) :Erro no Servidor 600-699 (6XX) :Falha Global

RESPOSTAS Mensagens SIP Status Code Cabeçalho da Resposta 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 Resposta Os campos Call-ID, To, From,CSeq são espelhadas em respostas para suportar o match (verificação) de campos entre requisição e resposta.

Mensagens SIP Categorias de códigos de status 1xx Informativo (Pedido recebido, continuando a processar o pedido) 100 Tentando 180 Chamando 181 A chamada está sendo retransmitida Colocado na fila 2xx Sucesso (a ação foi recebida, entendida e aceito com sucesso) OK 3xx Redirecionamento (uma ação adicional deve ser tomada para completar o pedido) 300 Múltiplas escolhas 301 Movido permanentemente 302 Movido temporariamente 380 Serviço alternativo

Mensagens SIP 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álido 401 Não autorizado 402 Necessário pagamento 403 Proibido 404 Não encontrado 405 Método não permitido 406 Não aceitável 407 Necessária autenticação do proxy Tempo para o pedido esgotado Conflito 410 Não mais presente 411 Necessário fornecer comprimento 413 Corpo da mensagem de pedido muito grande 414 URI do pedido muito grande 415 Tipo de mídia não suportado 420 Extensão inválida 480 Temporariamente não disponível 481 Transação ou leg de chamado não existe 482 Laço (loop) detectado 483 Excesso de segmentos (hops) 484 Endereço incompleto 485 Ambíguo

Mensagens SIP Categorias de códigos de status 5xx Erro de servidor 500 Erro interno ao servidor 501 Não implementado 502 Gateway inválido 503 Serviço não disponível 504 Tempo esgotado no gateway Versão SIP não suportada 6xx Falha global 600 Ocupado em todos os lugares 603 Declínio 604 Não existe em lugar nenhum 606 Não aceitável

Mensagens SIP Linha de início: pedido ou resposta Cabeçalhos Linha em branco Corpo da mensagem, se houver. Pode ser SDP limpo ou criptografado, MIME... 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).

Session Description Protocol SDP Session Description Protocol

SDP : 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.

SDP : Session Description Protocol 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.

SDP : Session Description Protocol 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 s= Nome da Sessão i= Informação da sessão opcional u= Uniform Resource Identifer e= Endereço de e-mail p= Número de telefone c= Informações de conexão b= Informação sobre largura de banda t= Tempo – início e fim da sessão r= Número de repetições z= Correções de zonas de horário k= Chave de criptografia m= Informações de mídia a= Atributos da mídia

SDP : Session Description Protocol 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

SDP : Session Description Protocol Informações de capacidade de Mídia (m=) Payloads RTP de 0 a 95 são estáticos, designados pela IANA (Internet Assigned Numbers Authority). Ex: m=audio 49170 RTP/AVP 0 Payloads de 96 a 127 são dinâmicos, negociados pelo protocolo de controle de conferência. Ex: m=audio 49170 RTP/AVP 98 a=rtmap:98 L16/16000/2 Tipo de payload Codec Á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 (Áudio estéreo com codificação de linear de 16 bits amostrado a 16 kHz)

SDP : Session Description Protocol Exemplo SDP v=0 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 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 23422 RTP/AVP 31 a=rtpmap:31 H261/90000

Mensagens SIP Linha de início: pedido ou resposta Cabeçalhos Linha em branco Corpo da mensagem, se houver. Pode ser SDP limpo ou criptografado, MIME...

SIP Operação do Protocolo

Operaçã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);

Operação do Protocolo 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 Operação do Protocolo Localização de Usuários

sip:aluno2@ufrn.br Invite 200 OK ACK SIP Stateless Proxy SIP Statefull Proxy 2 Invite 200 OK Caminho da Sinalização Invite 200 OK ACK SIP Statefull Proxy 1 Invite Moved Temporarily ACK SIP Redirect Server Invite 200 OK ACK sip:aluno@ufrn.br Mídia (RTP)

Operação do Protocolo

SIP x H.323 SIP H.323 Codificação em modo texto, fácil de depurar; Uso de url como identificador de protocolo / possibilidade de redirecionamento; Priorização de chamadas; Protocolo SDP descreve os tipos de mídia; Multicast possível na sinalização; Servidores com diferentes comportamentos: registro, proxy, redirecionamento; Protocolo de sinalização presença e mensagens instantâneas H.323 Codificação binária ASN.1, tamanho da PDU menor Uso de e-mail, mas presumindo que o protocolo é H.323; Não faz priorização de chamada; Sub-Protocolos: H.245, H225 (Q.931, RAS, RTP/RTCP), H.450.x. Recursos poderosos para controle de conferência; Servidor único Gatekeeper H.323

SIP 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 UDP; 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.