SIP Proxy

Session Initiation Protocol (SIP) é um protocolo de controle da camada de aplicação usado para criar, modificar e terminar sessões com um ou mais participantes. Essas sessões podem ser de chamadas de telefone via internet, distribuição  e conferências multimidia.

Um SIP proxy ou Servidor Proxy SIP é um elemento da rede que roteia uma chamada SIP até o usuario de destino.

Um pedido pode passar por varios SIP Proxies antes de chegar aos destinatário, onde cada SIP Proxy  modificará o pedido de forma a tomar decisões de rotas a  serem seguidas. A resposta do pedido seguirá exatamente a mesma rota do pedido, com sentido reverso.

Detalhamento

Um SIP Proxy pode operar em dois estados:

SIP Proxy stateless: funciona apenas como um encaminhador de pedidos. Ele simplesmente envia os pedidos, descartando as informações da mensagem uma vez que tenham sido enviadas.

SIP Proxy statefull: retêm as informações de um pedido após o envio do mesmo, como também as informações de processamento do pedido. Ele usa essas informações para afetar processos futuros e decidir se é necessário "to fork" o pedido, roteando-o para multiplos destinos. Qualquer pedido feito para multiplos locais deve ser operado em modo statefull.

Sequência de Funcionamento

Validar o pedido

Nesta etapa checa se a URI está bem formatada, se a sintaxe do pedido está correta, entre outras coisas.

processar informações de roteamento

checa se a URI especificada possui um endereço ou domínio ao qual é permitido uma resposta.

determinar o destino para o pedido

nesta etapa calcula os destinos do pedido, este depende do tipo do pedido, ou então é obtido de um abstract location service. Cada destino definido é representado por uma URI.

encaminhar o pedido para cada destino

processar todas as respostas

Exemplo

This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with
both proxies record-routing. Here is the flow.

U1 sends:

INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com

to P1. P1 is an outbound proxy. P1 is not responsible for
domain.com, so it looks it up in DNS and sends it there. It also
adds a Record-Route header field value:

INVITE sip:callee@domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p1.example.com;lr>

P2 gets this. It is responsible for domain.com so it runs a location
service and rewrites the Request-URI. It also adds a Record-Route
header field value. There is no Route header field, so it resolves
the new Request-URI to determine where to send the request:

INVITE sip:callee@u2.domain.com SIP/2.0
Contact: sip:caller@u1.example.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>

The callee at u2.domain.com gets this and responds with a 200 OK:

SIP/2.0 200 OK
Contact: sip:callee@u2.domain.com
Record-Route: <sip:p2.domain.com;lr>
Record-Route: <sip:p1.example.com;lr>

The callee at u2 also sets its dialog state's remote target URI to
sip:caller@u1.example.com and its route set to:

(<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>)

This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its
dialog state's remote target URI to sip:callee@u2.domain.com and its
route set to:

(<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>)

Since all the route set elements contain the lr parameter, U1
constructs the following BYE request:

BYE sip:callee@u2.domain.com SIP/2.0
Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr>

Fontes

http://www.ietf.org/rfc/rfc3261.txt http://datatracker.ietf.org/doc/rfc2805/