# Métodos e pedidos SIP

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

- URL canônico: https://www.broadnet.me/pt/reference/sip-methods-and-requests
- Idioma: pt
- Última atualização: 2026-07-18
- Editor: BroadNet (https://www.broadnet.me)

Cada método de pedido SIP e o que faz: os seis métodos centrais da RFC 3261 (INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS) e as extensões comuns (INFO, PRACK, UPDATE, SUBSCRIBE/NOTIFY, REFER, MESSAGE, 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étodos SIP centrais (RFC 3261)*

| 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étodos de extensão SIP comuns*

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

*O início de um pedido INVITE*

```text
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: 142
```

## Perguntas 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.

## Fontes

- [IETF RFC 3261 — SIP](https://datatracker.ietf.org/doc/html/rfc3261)
- [IETF RFC 6665 — SIP-Specific Event Notification](https://datatracker.ietf.org/doc/html/rfc6665)

## Relacionados

- [Visão geral do protocolo SIP](https://www.broadnet.me/pt/reference/sip-protocol-overview)
- [Códigos de resposta SIP](https://www.broadnet.me/pt/reference/sip-response-codes)
- [cabeçalhos SIP](https://www.broadnet.me/pt/reference/sip-headers)
- [fluxo de chamada SIP](https://www.broadnet.me/pt/reference/sip-call-flow)
- [Trunking de voz API & SIP](https://www.broadnet.me/pt/answers/voice-api-sip-trunking)