Mudanças entre as edições de "Tipos de rotas"
Linha 214: | Linha 214: | ||
− | |||
− | |||
− | + | ==startup_route== | |
− | ''' | + | A '''startup_route''' é executada apenas quando o OpenSIPS é iniciado, antes do processamento de mensagens SIP começar, isso é útil se algumas ações de inicialização são necessárias, como carregar dados no cache para facilitar o uso para processamento no futura, veja que esta rota diferente das demais não é ativada pelo recebimento de uma mensagem, então a função pode ser utilizada aqui mas não fará o processamento de mensagem. |
− | + | * Ativado por (triggered by): Inicialização do sistema, antes dos listeners serem iniciado | |
+ | * Processando (processing): Funções de inicialização | ||
− | + | ||
+ | Exemplo de uso: | ||
startup_route { | startup_route { | ||
avp_db_query("select gwlist where ruleid==1",$avp(i:100)); | avp_db_query("select gwlist where ruleid==1",$avp(i:100)); | ||
cache_store("local", "rule1", "$avp(i:100)"); | cache_store("local", "rule1", "$avp(i:100)"); | ||
} | } | ||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | ==timer_route== | ||
− | ''' | + | As '''timer_route''' são como o nome sugere, uma rota que é executada periódicamente num intervalo de tempo especificado (em segundos), assim como a '''startup_route''' ésta rota não processa mensagens, você pode ter mais de uma 'timer_route' definida. |
− | + | * Ativada por (triggered by): ativado pelo time keeper | |
+ | * Processand (processing): Funções que atualizam ações | ||
− | + | Exemplo e uso: | |
timer_route[gw_update, 300] { | timer_route[gw_update, 300] { | ||
avp_db_query("select gwlist where ruleid==1",$avp(i:100)); | avp_db_query("select gwlist where ruleid==1",$avp(i:100)); | ||
$shv(i:100) =$avp(i:100); | $shv(i:100) =$avp(i:100); | ||
} | } | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | ==event_route== | |
− | ''' | + | A '''event_route''' é utilizada pela interface de eventos do OpenSIPS para executar uma função do script quando um evento é acionado, o nome da rota é o nome do evento que a mesma deve manipular. |
− | + | * Ativado por (triggered by): Módulo [[modulo_event_route|event route]] quando um evento acontece | |
+ | * Processando (processing): o evento ativado | ||
+ | * Tipo (type): stateless (recomendado) | ||
+ | * Ação Default: nenhum script é executado quando acontece um evento | ||
− | + | Exemplo de uso: | |
event_route[E_PIKE_BLOCKED] { | event_route[E_PIKE_BLOCKED] { | ||
xlog("The E_PIKE_BLOCKED event was raised\n"); | xlog("The E_PIKE_BLOCKED event was raised\n"); | ||
} | } | ||
− | |||
− | |||
− | [[ | + | [[OpenSIPS_1.9_Manual|Voltar]] |
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Edição das 23h29min de 6 de outubro de 2013
O OpenSIPS possue diversos tipos de rota, cada rota é acionada por um certo evento e permite que você process um certo tipo de mensagem (request ou reply)
Índice
route
O Bloco de roteamento de requisições (Request routing block) contém algumas ações a serem tomadas em uma requisição SIP
- Ativado por (triggered by): recebendo uma requisição da rede
- Processamento (processing): a requisição que gera a ativação
- Tipo (type): inicialmente stateless, mas pode ser forçada para tornar-se stateful utilizando as funções do TM
- Ação padrão (default action): Se a requisição ainda não foi encaminhada ou respondida a rota irá simplesmente discartar a requisição no fim
O bloco de roteamento principal é identificado por 'route{...}' ou 'route[0]{....}' e é executado por cada requisição.
A ação implicita após a execução do bloco principal é finalizar a requisição, para enviar uma resposta ou encaminhar a requisição as ações devem ser chamadas dentro do bloco de roteamento
Exemplo de uso:
route { if(is_method("OPTIONS")) { # send reply for each options request sl_send_reply("200", "ok"); exit(); } route(1); } route[1] { # forward according to uri forward(); }
Veja que se a 'route(X)' é chamada de uma 'branch_route[Y]' então a 'rota[X]' irá processar cada perna (lado) separadamente invés de todas as partes juntas como ocorre na rota principal (main route)
branch_route
O bloco de roteamento branch contém algumas ações que são processadas para cada perna (branch) da requisição
- Ativado por (triggered by): preparação de uma nova perna (da requisição), os lados (cada perna) está devidamente formado mas ainda não enviado.
- Processando (processing): a requisição sip (com as particularidade de cada perna como RURI e branch flags)
- Tipo (type): stateful
- Ação padrão (default action): se a perna não foi derrubada (via drop) a perna será automaticamente enviada
Este bloco é executado apenas pelo módulo TM após este ser definido via t_on_branch('nome ou numero da rota');
Exemplo de uso:
route { lookup("location"); t_on_branch("1"); if(!t_relay()) { sl_send_reply("500", "relaying failed"); } } branch_route[1] { if(uri=~"10\.10\.10].10") { # discard branches that go to 10.10.10.10 drop(); } }
failure_route
Bloco para roteamento de transações com falha, este contém uma série de ações a serem tomadas para cada transação que recebe apenas repostas negativas (>=300) para todas as pernas
- Ativado por (triggered by): recebimento ou geração (nterno neste caso) de um reply negativo para completar a tranasação (todas as pernas são terminadas com replies negativos)
- Processando (processing): a requisição horiginal (que foi enviada)
- Tipo (type): stateful
- Ação default: Se nao for gerada uma nova perna ou nenhum reply é forçado por padrão o reply será enviado de volta para o UAC
A 'failure_route' é executada apenas pelo módulo TM após este ser armado através da função t_on_failure("nome ou numero da rota").
Veja que a 'failure_route' é processada na requisição que iniciou a transação, não no reply.
Exemplo de uso:
route { lookup("location"); t_on_failure("1"); if(!t_relay()) { sl_send_reply("500", "relaying failed"); } } failure_route[1] { if(is_method("INVITE")) { # call failed - relay to voice mail t_relay("udp:voicemail.server.com:5060"); } }
onreply_route
Bloco de roteamento de resposta (reply), este contém algumas ações executadas para os replies.
- Ativado por (triggered by): receber um reply da rede
- Processando (processing): o reply recebido
- tipo (type): stateful (se pertencer a uma transação) ou stateless (se estiver no reply global)
- Ação padrão (default action): Se o reply não é descartado (apenas replies temporarios podem) então será injetado e processado pela engine de transação
Existem alguns tipos de rotas onreply:
- global: recebe qualquer reply recebido pelo OpenSIPS e não precisa de nenhuma definição especifica , apenas 'onreply_route{...}' ou 'onreply_route[0]{...}' é suficiente
- por request/transação: manipula todos os replies que pertençam a uma certa transação e precisa ser definida durante o request (via 't_on_reply()' , no script deve ser criada como 'onreply_route[N] {...}.
- por perna (branch): manipula apenas os replies que pertençam a uma certa perna (branch) da transação, precisa ser definida 't_on_reply()' durante a requisição, mas em uma BRANCH ROUTE, para processar quando uma perna é processada , o nome deve ser 'onreply_route[N]{....}'
Alguns blocos 'onreply_route' podem ser executados pelo módulo TM para alguns replies especiais, para isso a 'onreply_route' deve ser definida para a requisição cuja resposta deve ser processada dentro desta, através do t_on_reply("nome ou numero da rota").
Exemplos de uso:
route { seturi("sip:bob@opensips.org"); # first branch append_branch("sip:alice@opensips.org"); # second branch
t_on_reply("global"); # the "global" reply route # is set the whole transaction t_on_branch("1");
t_relay(); }
branch_route[1] { if ($rU=="alice") t_on_reply("alice"); # the "alice" reply route # is set only for second branch }
onreply_route { xlog("OpenSIPS received a reply from $si\n"); }
onreply_route[alice] { xlog("received reply on the branch from alice\n"); }
onreply_route[global] { if (t_check_status("1[0-9][0-9]")) { setflag(1); log("provisional reply received\n"); if (t_check_status("183")) drop; } }
error_route
A error route é executada automaticamente quando um erro de execução acontece no processamento de uma requisição, isso permite ao administrador decidir oque fazer em caso de erro, abaixo as ações.
- Acionado por (triggered by): Erro na rota
- Porcessando (processing): uma requisição que falhou
- Tipo (type): stateless (recomendado)
- Ação Default (default action): descarta a requisição
Na error_route as seguintes pseudo-variaveis estão disponiveis para acesso dos detalhes:
- $(err.class) - Classe de erro ( Atualmente '1' para tratamento de erro)
- $(err.level) - Nivel de severidade do erro
- $(err.info) - Texto descrevendo o erro
- $(err.rcode) - Reply recomendado para o erro
- $(err.rreason) - Frase com razão do erro recomendada para o reply
Exemplos de uso:
error_route { xlog("--- error route class=$(err.class) level=$(err.level) info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n"); xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n"); sl_send_reply("$err.rcode", "$err.rreason"); exit; }
local_route
A rota local é executada automaticamente quando uma nova requisição é gerada pelo módulo TM internamente. Esta é uma rota que tem a intenção de ser utilizada para inspeção de mensagens, accounting e para aplicação de últimas alterações em cabeçalhos, funções de sinalização e roteamento não são permitidas.
- Ativado por (triggered by): TM gerando uma nova requisição
- Processamento (processing): uma nova requisição
- Tipo: stateful
- Ação default: enviar o request pra fora
local_route { if (is_method("INVITE") && $ru=~"@foreign.com") { append_hf("P-hint: foreign request\r\n"); exit; } if (is_method("BYE") ) { acc_log_request("internally generated BYE"); } }
startup_route
A startup_route é executada apenas quando o OpenSIPS é iniciado, antes do processamento de mensagens SIP começar, isso é útil se algumas ações de inicialização são necessárias, como carregar dados no cache para facilitar o uso para processamento no futura, veja que esta rota diferente das demais não é ativada pelo recebimento de uma mensagem, então a função pode ser utilizada aqui mas não fará o processamento de mensagem.
- Ativado por (triggered by): Inicialização do sistema, antes dos listeners serem iniciado
- Processando (processing): Funções de inicialização
Exemplo de uso:
startup_route { avp_db_query("select gwlist where ruleid==1",$avp(i:100)); cache_store("local", "rule1", "$avp(i:100)"); }
timer_route
As timer_route são como o nome sugere, uma rota que é executada periódicamente num intervalo de tempo especificado (em segundos), assim como a startup_route ésta rota não processa mensagens, você pode ter mais de uma 'timer_route' definida.
- Ativada por (triggered by): ativado pelo time keeper
- Processand (processing): Funções que atualizam ações
Exemplo e uso:
timer_route[gw_update, 300] { avp_db_query("select gwlist where ruleid==1",$avp(i:100)); $shv(i:100) =$avp(i:100); }
event_route
A event_route é utilizada pela interface de eventos do OpenSIPS para executar uma função do script quando um evento é acionado, o nome da rota é o nome do evento que a mesma deve manipular.
- Ativado por (triggered by): Módulo event route quando um evento acontece
- Processando (processing): o evento ativado
- Tipo (type): stateless (recomendado)
- Ação Default: nenhum script é executado quando acontece um evento
Exemplo de uso:
event_route[E_PIKE_BLOCKED] { xlog("The E_PIKE_BLOCKED event was raised\n"); }