Esta seção introduz as operações básicas do SIP usando um exemplo simples. Vamos examinar a sequência de mensagens entre dois "agentes-usuário" mostrados ao lado.

As mensagens estão rotuladas na sequência. Neste exemplo o UsuárioA usa um telefone IP para se comunicar com outro telefone IP pela Internet. Para poder completar esta ligação são usados dois SIP Proxies. O UsuárioA chama o UsuárioB usando sua identidade SIP também conhecida como SIP URI. A URI é semelhante a um endereço de e-mail como sip:usuárioA@sip.com.br. O SIP também pode usar uma URI segura como sips:usuárioA@sip.com.br. Uma chamada feita para um URI SIPS garante um transporte de mensagens seguro (TLS) entre o originador e o destino chamado.

A transação começa com o telefone do UsuárioA enviando um INVITE (Convite) endereçado ao UsuárioB. O pedido de INVITE (Convite) contém um número de campos de cabeçalho. Campos de cabeçalho são atributos nomeados que provêm informações adicionais sobre a mensagem, eles incluem um identificador único, o destino e informações sobre a sessão.

A primeira linha da mensagem contém o nome do método. As linhas que seguem fazem parte da lista dos campos cabeçalho. Este exemplo contém o conjunto mínimo necessário. Estes campos são rapidamente descritos abaixo:

VIA contém o endereço para o qual o UsuárioA está esperando receber respostas a este pedido. Ele também contém um parâmetro "branch" que identifica esta transação.
TO contém um nome (display name) e um SIP ou SIPS URI (sip:usuárioA@sip.com.br) para o qual o pedido foi originalmente direcionado.
FROM também contém um nome (display name) e SIP ou SIPS URI (sip:usuárioA@sip.com.br) que indica o originador da chamada. Este campo cabeçalho tem um parâmetro etiqueta (tag) contendo uma string aleatória (1234567890) que foi adicionada ao URI pelo telefone IP ele é usado para propósitos de identificação.
CALL-ID contém um identificador globalmente único para esta chamada, gerado pela combinação de uma string aleatória e o nome do host ou endereço IP do telefone IP. A combinação da etiqueta TO, FROM e CALL-ID definem completamente uma relação SIP fim-a-fim ("peer-to-peer") também conhecida como diálogo.
CSEQ ou sequência de comandos contém um inteiro e um nome de método. O número CSEQ é incrementado para cada novo pedido dentro de um diálogo e é um número de sequência tradicional.
CONTACT contém um URI SIP ou SIPS que representa uma rota direta para contatar o UsuárioA, usualmente composta de um nome de usuário em um domínio totalmente qualificado (FQDN). Como nem sempre alguns sistemas têm um domínio registrado, endereços IP são permitidos. Enquanto o campo VIA diz aos outros elementos para onde enviar uma resposta, o campo CONTACT diz aos outros elementos para onde enviar requisições futuras.
MAX-FORWARDS serve para limitar o número de saltos que um pedido pode dar no caminho ao seu destino. Ele consiste de um inteiro que é decrementado por um à cada salto.
CONTENT-TYPE contém uma descrição do corpo da mensagem.
CONTENT-LENGTH contém uma contagem de bytes do corpo da mensagem.

Os detalhes de uma sessão, tal como o tipo de mídia, codec não são descritos usando o SIP. Ao invés disso o corpo de uma mensagem SIP contém uma descrição da sessão, codificado em outro formato de protocolo. Um destes formatos é o SDP (Session Description Protocol RFC 2327). Esta mensagem SDP é carregada pela mensagem SIP de forma análoga a um anexo de e-mail.

A sequência da figura fica como acima:

Como o telefone não conhece a localização do usuárioA ou servidor SIP do domínio sipB.com.br ele envia o INVITE para o servidor SIP que serve ao domínio sipA, este endereço é configurado no telefone do usuárioA, ou pode ser descoberto via DHCP. O servidor sipA.com.br é conhecido como proxy.
Neste exemplo o proxy recebe o pedido de INVITE e envia uma mensagem "100 (Trying)" de volta ao usuárioA indicando que o proxy recebeu o INVITE e está trabalhando em encaminhar o pedido. As respostas SIP usam um código de três dígitos seguidos por uma frase descritiva. Esta resposta contém o mesmo To, From, Call-ID, CSeq e o parâmetro "branch" no campo Via como o INVITE, o que permite que o telefone do UsuárioA correlacione sua resposta para o INVITE enviado.
O ProxyA localiza o ProxyB fazendo uma consulta específica ao servidor DNS para encontrar o servidor SIP que serve ao domínio B e encaminhar o INVITE. Antes de encaminhar o pedido o ProxyA adiciona um campo Via adicional que contém seu próprio endereço (O INVITE já contém o endereço de A no primeiro campo Via).
O ProxyB recebe o INVITE e responde com um 100 (Trying) "tentando" de volta ao ProxyA indicando que ele está processando o pedido.
O servidor Proxy consulta a base de dados, conhecida como serviço de localização, que contém o endereço do usuárioA. O ProxyB adiciona um outro campo Via com seu próprio endereço para o INVITE e encaminha para o usuárioN.
O telefone do usuárioB recebe o INVITE e alerta o usuário para a chamada vinda do UsuárioA e o telefone desta forma toca. O telefone indica isto com uma resposta 180 (ringing) "tocando".
que é roteada de volta através dos dois proxys na direção inversa. Cada proxy usa o campo Via para determinar para onde enviar a resposta e remove seu próprio endereço do topo. Como resultado, embora o DNS e a consulta ao serviço de localização sejam necessários para rotear o INVITE inicial, a resposta 180 (ringing) pode retornar ao originador sem lookups e sem que seu estado seja mantido por cada proxy. Isto também faz com que cada proxy que recebeu o INVITE veja todas as respostas do INVITE.
Quando o usuárioA recebe o 180 (ringing), ele passa esta informação ao telefone A que vai soar o áudio de "tocando" (ringback) e/ou mostrar a mensagem na tela do usuárioA.

Neste exemplo, o UsuárioA decide atender a chamada. Quando ele pega o handset, este telefone SIP envia uma resposta 200(OK) para indicar que a chamada foi respondida. O 200(OK) contém no corpo da mensagem com a descrição da sessão usando o protocolo SDP. Como resultado, existe uma troca em duas fases das mensagens SDP de A para B e de B para A. Este recurso do SDP possui uma capacidade básica de negociação dos recursos em um modelo simples de oferta/resposta. Se o usuárioA não quiser responder a chamada ou estiver ocupado, um erro será enviado ao invés do 200(OK). A mensagem 200(OK) é algo como aparece abaixo:

A primeira linha de resposta contém o código de resposta e a frase da razão (OK). As linhas restantes contêm campos cabeçalhos. Os campos Via, To, From, Call-ID, e CSeq são copiados do pedido de INVITE. Existem três campos Via, um adicionado pelo telefoneA, outro pelo ProxyA e o último pelo ProxyB. O telefone SIP de Bob adicionou em parâmetro tag (etiqueta) em ambos os pontos finais dentro do diálogo e serão incluídos em todos os pedidos futuros e respostas nesta chamada.

O campo Contact contém uma URI com a qual o usuárioA pode ser contatado diretamente no seu telefone IP. Os campos Content-Type e Content-Length se referem ao corpo da mensagem (não mostrado) que contém a informação da sessão SDP (mídia).

Além do DNS e do serviço de localização mostrados no exemplo, os servidores proxy podem decidir para onde enviar o pedido. Por exemplo, se o telefone SIP do usuárioA retornar um 486 (Busy here) "Ocupado", o proxyB poderia fazer um INVITE ao servidor de correio de voz do usuárioB. Um servidor proxy pode também enviar um INVITE para vários locais ao mesmo tempo. Este tipo de busca paralela é conhecida como "forking".

Neste caso, o 200(OK) enviado de volta é roteado de volta pelos dois proxies e recebido pelo UsuárioA que então para o tom de retorno e indica que a chamada foi respondida.
Finalmente o UsuárioA envia uma mensagem de ACK, para o telefone do UsuárioB para confirmar o recebimento da resposta final 200 (OK). Neste exemplo o ACK é enviado diretamente do telefone A para o telefone B evitando os dois proxies. Isto ocorre porque os pontos finais aprenderam os endereços uns dos outros a partir dos campos Contact durante o processo de INVITE/200(OK). Isto completa o ciclo INVITE/200/ACK também conhecido como "SIP three-way-handshake" usado para estabelecer sessões SIP.
Neste momento a sessão entre os usuários começa e eles estão enviam pacotes de mídia de um para o outro usando formato que eles estabeleceram usando o SDP. Em geral os pacotes fim-a-fim têm um caminho diferente das mensagens de sinalização. Durante a sessão, os usuários A e B podem decidir mudar as características de uma sessão. Isto é feito enviando um novo "convite" (re-INVITE) contendo uma nova descrição de mídia. Este re-INVITE referencia um diálogo existente de forma que a outra parte sabe que ela vai modificar uma sessão existente ao invés de iniciar uma nova sessão. O outro lado envia um 200(OK) com um ACK. Se o outro lado aceitar a mudança ele vai enviar um 200(OK) , o originador responde ao 200(OK) com um ACK. Se o outro lado não aceitar, ele vai enviar uma resposta tal como 488 (não aceitável aqui), que também recebe um ACK. Entretanto a falha no re-INVITE não causa a falha da sessão existente.
No final da sessão, o UsuárioB desconecta (hang up) e gera a mensagem de BYE. Este BYE é encaminhado diretamente para o softfone do UsuárioA contornando os proxies.
O UsuárioA confirma a recepção do BYE com uma resposta 200 (OK) que termina a sessão e a transação BYE. Nenhum ACK é enviado. Um ACK só é enviado como resposta a um pedido de INVITE.

Em alguns casos pode ser útil para os Proxies ficar no caminho da sinalização para ver todas as mensagens entre os pontos finais pela duração da sessão. Por exemplo, se o servidor ProxyB deseja permanecer no caminho da mensagem além do INVITE inicial, ele deve adicionar ao INVITE o campo conhecido como Record-Route que contém a URI do proxy. Esta informação será recebida pelo softfone do UsuárioB e (devido ao campo Record-Route será passada de volta na mensagem 200 (OK) para o softfone do UsuárioA e armazenado pela duração do diálogo. Cada Proxy pode de forma independente decidir receber mensagens subsequentes, e estas mensagens irão passar através dos proxies que elegerem recebê-las. Esta capacidade é frequentemente usada para proxies que estão provendo recursos usados no meio de uma chamada.

O registro é uma forma que o ProxyB pode usar para aprender a localização atual do UsuárioB. Na inicialização e em intervalos regulares, o softfone B envia mensagens do tipo REGISTER para o servidor no domínio B conhecido como "SIP REGISTRAR". As mensagens de registro associam o endereço SIP do UsuárioB (UsuárioB@sipB.com.br) com a máquina na qual ele está logado (Que vem como uma URI SIP ou SIPS no campo Contact). O servidor registrar escreve esta associação, também chamada de "binding", para um banco de dados, chamado "location service" onde ela pode ser usada pelo servidor Proxy no domínio sipB. Normalmente o servidor de registro fica junto com o proxy. O usuário pode se registrar de mais de um local e o servidor pode fazer vários tipos de busca para localizar o UsuárioB. De forma similar, mais de um usuário pode ser registrado em um único dispositivo ao mesmo tempo.

Finalmente, é importante notar que no SIP o processo de registro é usado para rotear as chamadas SIP e não tem papel na autorização dos pedidos de ligação. Autenticação e autorização são gerenciadas pelo SIP em uma base pedido a pedido com um mecanismo de desafio/resposta, ou usando um esquema de nível mais baixo como checagem de endereço IP.