Exibir código-fonte para SIP Proxy

== Detalhamento  ==
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&nbsp; 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&nbsp; modificará o pedido de forma a tomar decisões de rotas a&nbsp; serem seguidas. A resposta do pedido seguirá exatamente a mesma rota do pedido, com sentido reverso.

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 === 
<pre>
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>
</pre>

= Fontes  =
[http://www.ietf.org/rfc/rfc3261.txt http://www.ietf.org/rfc/rfc3261.txt]<br />
[http://datatracker.ietf.org/doc/rfc2805 http://datatracker.ietf.org/doc/rfc2805]<br />