Os pedidos SIP são nomeados por um método. A RFC 3261 define seis: INVITE (iniciar uma sessão), ACK (confirmar uma resposta final a um INVITE), BYE (terminar uma sessão), CANCEL (abortar um INVITE pendente), REGISTER (registar uma localização) e OPTIONS (consultar capacidades). RFCs de extensão acrescentam INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE e PUBLISH.
Os seis métodos centrais
A RFC 3261 define o conjunto central de pedidos que toda a implementação SIP suporta. O INVITE estabelece uma sessão e transporta a oferta SDP inicial. O ACK confirma uma resposta final a um INVITE — é invulgar por ser um pedido que completa o handshake de três vias do INVITE em vez de esperar a sua própria resposta. O BYE termina uma sessão estabelecida. O CANCEL aborta um INVITE que ainda não recebeu uma resposta final (uma chamada ainda a tocar). O REGISTER indica a um registar onde um utilizador está alcançável. O OPTIONS consulta as capacidades de um par e é amplamente reutilizado como keepalive leve.
| Método | Finalidade | Nota |
|---|---|---|
| INVITE | Iniciar uma sessão | Transporta a oferta SDP; cria um diálogo |
| ACK | Confirmar uma resposta final a um INVITE | Conclui o handshake INVITE de 3 vias |
| BYE | Encerrar uma sessão estabelecida | Enviado por qualquer uma das partes no diálogo |
| CANCEL | Cancelar um INVITE pendente | Somente antes de uma resposta final (o telefone ainda toca) |
| REGISTER | Registar a localização Contact de um utilizador | Atualizado periodicamente (Expires) |
| OPTIONS | Consultar capacidades | Comumente reutilizado como keepalive / verificação de integridade |
Porque ACK e CANCEL são especiais
Dois métodos centrais comportam-se de forma diferente dos restantes. O ACK não é um par pedido/resposta normal: confirma a resposta final a um INVITE e não transporta resposta própria. Para um 2xx é enviado de ponta a ponta como uma transação separada; para uma falha não-2xx é gerado salto a salto dentro da transação do INVITE. O CANCEL só tem significado enquanto um INVITE está pendente — assim que chega uma resposta final, use antes o BYE. Acertar nestes dois é o cerne de uma máquina de estados SIP correta.
Métodos de extensão comuns
Para além dos seis centrais, um conjunto de métodos de extensão trata de mensagens, eventos e atualizações a meio da chamada. SUBSCRIBE/NOTIFY implementam a framework de eventos (presença, indicação de mensagem em espera, estado de diálogo). REFER despoleta a transferência de chamada. MESSAGE transporta mensagens instantâneas / SMS-sobre-SIP. UPDATE modifica uma sessão antes de estar totalmente estabelecida (early media). PRACK confirma de forma fiável as respostas provisórias. INFO transporta informação a meio da sessão como DTMF. PUBLISH submete estado de evento a um servidor.
| Método | RFC | Finalidade |
|---|---|---|
| INFO | RFC 6086 | Informações durante a sessão (ex: dígitos DTMF) |
| PRACK | RFC 3262 | Confirmação confiável de respostas provisórias (1xx) |
| UPDATE | RFC 3311 | Modificar uma sessão antes da resposta final (early media) |
| SUBSCRIBE / NOTIFY | RFC 6665 | Assinatura e notificação de eventos (presence, MWI) |
| REFER | RFC 3515 | Solicitar transferência para outra parte |
| MESSAGE | RFC 3428 | Mensagem instantânea / mensagens em modo page |
| PUBLISH | RFC 3903 | Enviar o estado de um evento (ex.: presence) a um servidor |
Uma linha de pedido em trânsito
Um pedido SIP começa com uma request line: o método, o Request-URI (o destino atual) e a versão SIP. Os cabeçalhos e um corpo opcional seguem-se. O exemplo é o início de um INVITE em direção a um chamado; o Request-URI é reescrito pelos proxies à medida que o pedido é encaminhado, enquanto o cabeçalho To se mantém fixo como o alvo lógico.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.net;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=1928301774
Call-ID: a84b4c76e66710@host.example.net
CSeq: 314159 INVITE
Contact: <sip:alice@host.example.net>
Content-Type: application/sdp
Content-Length: 142Perguntas frequentes
Quais são os seis métodos SIP centrais?
INVITE (iniciar uma sessão), ACK (confirmar uma resposta final a um INVITE), BYE (terminar uma sessão), CANCEL (abortar um INVITE pendente), REGISTER (registar a localização de um utilizador) e OPTIONS (consultar capacidades). Estão definidos na RFC 3261; tudo o resto é uma extensão.
Qual é a diferença entre CANCEL e BYE?
O CANCEL aborta um INVITE que ainda não recebeu uma resposta final — uma chamada que ainda está a tocar. O BYE termina uma sessão já estabelecida. Use CANCEL antes de a chamada ser atendida e BYE depois; usar o errado deixa a máquina de estados inconsistente.
Porque é que o ACK não recebe resposta?
O ACK existe para confirmar a resposta final a um INVITE e completar o handshake de três vias, pelo que está definido para não ter resposta própria. Para um 2xx é uma transação separada de ponta a ponta; para uma falha é gerado salto a salto dentro da transação do INVITE.
Como é enviado o DTMF no SIP?
Mais comummente como pacotes RTP telephone-event (RFC 4733) no fluxo de média, e em alternativa via mensagens SIP INFO que transportam os dígitos no caminho de sinalização. O RTP telephone-event é preferido por ficar em sincronia com o áudio.
Que método transfere uma chamada?
O REFER (RFC 3515). Pede ao destinatário que inicie um novo pedido (tipicamente um INVITE) a um terceiro nomeado no cabeçalho Refer-To, implementando a transferência de chamada. As mensagens NOTIFY reportam depois o progresso da chamada referida de volta ao transferidor.
Especificações de origem
Os padrões publicados nos quais esta página se baseia. Abre num novo separador.